Also called weblog (/ ˈwɛb.lɔg /). Here I take the freedom to write about everything that interests me. These topics may also be outside of my usual areas of focus. My blog, my rules.
I don't know how I survived before knowing Sublime Text. For me, there is no better editor. It's slim, fast and incredibly adaptable. Not at least because of the thousands of packages available. These ones are my favorites
The holy grail for Sublime Text. Autocomplete of functions, methods and variables spread over files. Direct jumps to definitions and function call tooltips. A sublime text project is required for that.
Emmet was known as "zencoding" before. It allows you, to use abbreviations to create lightning fast HTML- or CSS-Code. A line like:
"https://maurice-renck.de/en/tags/tag:myId">\#myId>ul.classname>li*4
will create the following HTML-Code:
<div id="myID“>
classname
">
<li>li>
<li>li>
<li>li>
<li>li>
ul>
div>
Whenever you define a color in your css-file, GutterColor will show this color right next to the linenumber. I am eagerly awaiting support for sass and less variables.
I already wrote about my markdown-setup here. The Plugin offers some extended markdown-functions and a nice style.
Because I like using scss/compass, I installed this Plugin to get the syntax-highlighting.
I use Handlebars as a template-engine for a lot of my JavaScript-projects. To get propper highlighting I use this Plugin.
I think I do not need to tell you a lot about this. This plugin offers a lot of snippets which will help you working with jQuery.
To document my sourcecode, I use DocBlockr (yet). If you type in the shortcut for DocBlockr right before a function, it will create a dummy-documentation-comment and fill in variables needed by the function automaticly.
There are always little code-snippets, which can be used in different projects. To store those, I use Gists on GitHub. Gists can be private or public available. This plugin helps you creating and receiving them. It also allows you to search through plubic gists.
The theme of my choice is PreDown. You have to take a look at it, because it's hard to describe.
All packages can be installed via Package Control. You can read here how to do so.
You also use sublime text and know some really good plugins? Post your list in the comments or send me a link to your blogpost. I will link them here.
Read full postI thought about how to optimize my project-creation-progress and wrote a little script for that.
In my article about GitLab-Webhooks, I wrote about how to simplify your deployprocess with a few simple steps. If someone pushes to a GitLab-project, a webhook will be run which updates your stage- or production-server.
In my solution I use a PHP-script, which reads a config-file to determine if the project which runs the webhook is a known one and if so, which branch has to be deployed.
I still like that solution, but I do not like, that I
Because, in my case, the deploy-config is the same most of the time (of course the path to and the name of the project differs), I tried to automate these steps.
So I wrote a little Bash-script, which helps me.
To prevent doublications and make sure the script does not overwrite exisiting files, the script checks if the new project already exists.
#!/bin/bash
cd /var/www/
if [ ! -d "$1" ]; then
mkdir -p "$1/logs"
chown YOURUSERNAME:www-data $1-$2
chmod -R 775 $1
cd /var/www/DEPLOYSCRIPTDIRECTORX/
head -n -2 deploy.json > temp.txt ; mv temp.txt deploy.json
printf "\t},\n\t\"$1\": {\n\t\t\"path\":\t\t\"/var/www/$1\",\n\t\t\"limit\":\t\"master\"\n\t}\n}" >> deploy.json
else
echo Project already exists!
fi
exit
To execute the script, you type:
/path/to/script.sh projectTitle
In my script there is a second parameter, which is a running number of the job. I want that to be part of the directory-name. I didn't include it in my sample here, but you can add more parameters by using the vars $2, $3, $4 …
The command above will create the directory projectTitle in /var/www.
First the script changes the current directory to the apache-document-root, that's /var/www for me, it may also be /srv/http for example. You should modify that for your needs in line 3 and 10 (I modified it a bit, because my client-works are in a subdirectory).
After that the script checks if the project-directory does exist. If so it will exit with a warning. If not, it will continue.
The directory will be created and the needed permissions will be set. The group of the directory will be set to www-data and the group gets write-access, so the deploy-script can write into the directory later.
If the deploy-script or your webserver runs as another user, you may want to change the group-name.
Then the script changes the directory of your deploy-configuration to extend it. First it will strip off the last two lines, which are the closing brackets of the json and of the last project.
Then the last projects gets its bracket back appended by a comma (so the next entry can follow).
After that the new entry will be written, the projectname and the path will be set. As default, the master-branch will be set for automatic deployment. If you want all branches to be deployed, you can change master to null or whatever branch you want to by deployed.
Finaly the closing bracket of the json is written.
So, with that the project ist set up and can be used. I put my script in my GitHub-Repository, hope it helps. If you have tips our questions feel free to comment below.
Read full postMaybe some of you have noticed, I am trying to write bilingual. So I wrote some helpers for that.
My last posts here could be read in english (surprise!), too. Although my written english is a bit rusty, I will keep translating my posts in the future and will try to translate the older ones step by step.
I am not that enthusiastic by the possibilites which come with Kirby, but it works, as you can see. I wrote a little snippet to switch languages and added a translation-detection I am using in my blog-header.
The problem is, Kirby will show the german text under a /en/-URL if there is no translated file available. I don't want that. You should not be able to click on the link for a translation which isn't there. So I modified the default-code for switching languages a little bit.
First I try to figure out, which template is used by the current article. The templatename matches the first part of the filename. With that information I can look for a translation of the text. If a translation is available the language-switch-link is clickable, if not, the link is not clickable.
Have a look:
foreach(c::get('lang.available') as $lang) : ?>
if($lang != c::get('lang.current')) : ?>
if($page->files()->find($page->template().'.'.$lang.'.md')) : ?>
To prevent manual modifications of the URL from "de" to "en" I am using a translation-detection in the header-file. If I would not do so, you could change "de" to "en" in the URL, but you would see the german text, if no translation is available. And I don't want you (and searchengines) to do so.
$lang = c::get('lang.current');
$other = ($lang == 'de') ? 'en' : 'de';
$template = $page->template();
if($page->files()->find($template.'.'.$lang.'.md') == NULL) {
header ('HTTP/1.1 303 See Other');
header('Location: '.$page->url($other));
}
?>
First I look which language is choosen and see what its counterpart is. Then again the test if a translation is available. If not, I am redirecting to the german version (which changes the URL).
I am not sure, if the 303-header is really correct, but it semed the best solution for me. This whole solution only works, if you are only bilingual. If you would like to support more than two languages you need to modify it.
My snippets can, as always, be found at GitHub.
Read full postSome versions ago, I think it was version 5.2, GitLab introduced Webhooks. I didn't like them at first but that changed since I found a great PHP-script, which I slightly modified.
I am a big fan of GitLab (even though the updateprocedures are pure horror) and I am using it for all the jobs and projects I am working on. I think GitLab is a great alternative to GitHub.
To get a smoothly running workflow and because I don't want to copy or pull files after pushing them to see the Changes on the websites, I use hooks.
Hooks are little scripts, run at a certain time. For example when changes where pushed to a repository. You can use these hooks to update a website automagically after a push, or take a stupid looking picture of yourself with every commit.
Now there are those webhooks. Principle they work the same as normal hooks. With every push a script is run. Until now, in my case, those scripts where simple BaSh-scripts. But those webhooks are working a bit differnt. You don't create a BaSh-script for every repository, you just tell GitLab what URL to open.
With every push, this URL will be opened and the relevant data will be submitted as JSON-string.
The big advantage is, you can execute different scripts by adding additional URLs.
The disadvantage is, you cannot use BaSh-Scripts anymore, because those normally aren't reachable via an URL.
So I looked around on the web and found a PHP-Script which seems to fit my needs.
The script evaluate the JSON and updates the corresponding branch. It even creates a folder for branches which didn't exist before.
So, whenever I push something to my master-branch, the URL (PHP-script) will be opened and the directory "master" will be updated or created if it doesn't exist.
So far, so good.
There are two things, I didn't like.
So I took the script and thought about, how to improve it. And this is how my solution works:
The PHP-script has to be copied to the server on which the webserver is running. I use a vhost for it, so I have a nice domain for that. The script has to exist once only.
Also I created a config-file. A simple JSON-file which has the following structure:
{
"repoName": {
"path": "/path/to/folder",
"limit": null
}
}
The name of the repository as to be the exact name as set up in GitLab, because the name will be submitted within the GitLab-JSON and can be referenced that way.
path is the directory in which the subdirectories for each branch will be created. In most cases this will be within document-root.
limit can be null, then all branches will be cloned and updated. If you whish just to update certain branches, you can give limit a comma-separated list of branch-names.
"limit": "master,testing"
You do that for each repository.
In this way you just have to maintain two files. The PHP and the config-file. If you make changes to the PHP you do not have to make those changes several times.
To get the script running, some basic steps have to be done before (creating deploy-key etc.). I will not explain those here, because they are explained in the blogpost of the original script very well.
Attention meridimus was so nice to give us a tip in the comments. In step 7 of the original article, the directory also needs the execution-flag so the known_hosts file can be created. Do it like so:
$ sudo chmod -R 0600 /var/www/.ssh
$ sudo chmod 0700 /var/www/.ssh
$ sudo chown -R www-data:www-data /var/www/.ssh
if you are interessted in the script, you can take a look at GitHub.
I wrote another article about how to automate your deploy-configuration with a simple bash-script.
Read full postI'm formatting my blogposts in markdown, For that, I set up my Sublime Text installation a bit.
As I wrote here (sorry, german only), my website runs on Kirby as CMS. And I am still satisfied with that solution.
Because Kirby is entirely based on MarkDown, I took a look at some applications, to write my MarkDown a bit more beautiful. But in the end I am using Sublime Text for that. The applications had great functions, like syncing around in the cloud and stuff like that. But weren't even able to open a regular file und I had to export my changes all the time. That was a bit annoying.
So now I am using Sublime Text again. I installed a little Plugin named MarkDown Editing and because I am a industrious guy and have nothing to do all the day, I wrote my own color-theme. I was inspired by some the apps colors and re-used them.
And that's it concerning Sublime Text.
To have the ability to see my changes without reloading my browser all the time, I bought a little app. Marked does that job for me. When I am saving my markdownfile, Marked shows me a preview. And I can hide all the YAML Front Matter stuff, Kirby needs. Which is pretty nice. To get a preview which looks nearly as my blog here, I set up my CSS as a theme.
Of course it would be much cooler, if all that magic would happen in my browser. So I get a preview in there, every time I save. Maybe I'll try to write a javascript for that, if I ever have the time.
If you would like to have a look at my sublime-color-theme, feel free to download it on GitHub
Read full post