Blog

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

Sublime CodeIntel

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.

Get the plugin

Emmet

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>

Read more about emmet

GutterColor

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.

Get the plugin

MarkdownEditing

I already wrote about my markdown-setup here. The Plugin offers some extended markdown-functions and a nice style.

Get the plugin

SCSS

Because I like using scss/compass, I installed this Plugin to get the syntax-highlighting.

Get the plugin

Handlebars

I use Handlebars as a template-engine for a lot of my JavaScript-projects. To get propper highlighting I use this Plugin.

Get the plugin

jQuery

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.

Get the plugin

DocBlockr

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.

Get the plugin

Gist

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.

Get the plugin

PreDawn

The theme of my choice is PreDown. You have to take a look at it, because it's hard to describe.

Get the theme

Installation

All packages can be installed via Package Control. You can read here how to do so.

And you?

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.

I 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

1. have to create the base-directory for a new project and set needed permissions all the time
2. have to modify the deploy-configuration by myself.

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.

addProject Bash-Script

So I wrote a little Bash-script, which helps me.

• It creates the base-directory of the project in the document-root.
• It modifies the deploy-config with standard-parameters and adds the correct path and project-title.

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

How to run

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.

How it works

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.

Maybe 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.

So it works better (for me)

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.

Some 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?

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.

WebHooks?

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.

The solution

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.

1. I have to copy the script for every repository and edit the included Path and URL to the repository.
2. It might happen, that I am working on branches, which do not need to be transfered to the webserver. Particularly when working on bigger projects there might be various branches which are merged from time to time, but must not be available on the webserver.

My modified solution

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.

Trouble?

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

Download

if you are interessted in the script, you can take a look at GitHub.

Update

I wrote another article about how to automate your deploy-configuration with a simple bash-script.

I'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.

Setup

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