Marcel Wichmann accidentally expresses my exact feelings toward the new third party keyboards in iOS8:
One of the things I looked most forward to in iOS 8 were custom keyboards. SwiftKey, Swype, Fleksy, Minuum and so on. They’re as cool as I wanted them to be and one of my main reasons to potentially switch to Android is therefore gone.
So here’s my prediction: I’m not going to end up with one of them. They’re nice, they do what they promise but at the same time they feel a bit strange, somehow like I’m losing control over something that was absolutely predictable in the past.
But let’s wait and see what I’ll be using in a few weeks. The bigger iPhone 6 screen might change my opinion. Who knows.
I personally hope we aren’t even close to hitting the full potential of new keyboards. Fleksy is so innovative, but while the predictions are really great most of the time, they are completely ridiculous some of the time, and the actual keyboard is not that great if you really want to type (instead of just mashing on the bottom half of the screen and hoping for the best). SwiftKey is okay, as long as you don’t plan on using punctuation, and Swype is the best I’ve tried so far.
Maybe it’s all a matter of adjusting to something new, and maybe the new keyboards just aren’t there yet (Fleksy didn’t even deliver on their promise of a DVORAK keyboard layout), but I’m looking forward to see what the future holds.
This article should hold some interesting revelations for everybody, but I’ll also go into some things that may be specific to Uberspace, because that’s where all my things run.
Okay, so you know the feeling: You push to master, you ssh into your server, you pull, you preprocess your new files for production, you’re done.
Well, my rule of thumb is: If you have to spend twenty seconds for a task, more than three times, it’s time to automate the whole thing, and if it takes all day.
I actually spend decades perfecting the following workflow (that’s not true) and I am happy to share it with you (that’s true).
Create your Shellscript
Create a script like pull-project.sh inside your cgi-bin folder.
Make it executable with chmod 755 pull-project.sh.
Put the shell commands you’d normally need for happiness in there. We’ll start with just the following and come back to this later.
echo "Content-type: text/plain"
Attention: The first three lines are important. cgi-bin is really really basic, and if you don’t put these lines there, the server and your browser won’t know what to do. The first line tells the server with which language it should run the script, and the next two lines tell the browser what kind of “file” it gets.
Configure your Webhook
Before you get into the GitHub configuration, you may want to test if the script actually runs by visiting http://your-domain.com/cgi-bin/pull-project.sh. There should be some plain text output like Already up to date or some other kind of git status message.
If everything works, you can go into your repository’s settings, to Webhooks & Services. There, you create a new webhook and enter the URL you just tested as the Payload URL. You can leave the other settings as they are, and you don’t have to enter a Secret.
This should now basically work. Whenever you push a new commit to GitHub, it will notify your script, which will pull the latest changes. Awesome. But maybe you want to go further. Read on.
This article doesn’t have the space to really explain what Gulp is and does. If you haven’t heard of it yet, you can just google and look at the Gulpfile for my portfolio.
Keep in mind that you don’t have to use gulp – you could probably just solve everything with shell scripts. But gulp is quite nice.
Run Gulp via git hook
Not only does GitHub offer webhooks, but Git itself does also provide hooks. This is how I always imagined living on a pirate ship – hooks everywhere. (Sorry.)
Long story short: You can execute shell scripts after git actions. There is a quite exhausting list of available hooks, but we’ll just use post-merge. You see, there is no post-pull hook, but every pull that actually changes things is also a merge. So that’s fine.
The configuration is quite simple. You just have to create an executable (chmod 755) file ~/project/.git/hooks/post-merge (without an extension). In there, you put your stuff. In my case, it’s something like
In my experience, it’s important to set the USER and HOME variables, because sass won’t work without them. If you don’t need sass, I guess you can skip these lines.
So? What’s going on? What have I just done?
Simple. Whenever you push code to your repo, GitHub will notify your shell script. It will pull the changes and merge them into your local repository. After that, it will execute the post-merge shell script, which will in turn run all your gulp tasks (and other things, if you, for example, want to restart Gunicorn).
You might argue that it’s not very safe to give basically everybody in the world the opportunity to run a shell script on your server. To that I say: You could always implement the secret token, or use .htaccess, or choose some really obscure filename, or just leave it be. My stance on the issue is: Even if someone calls the URL, the worst thing that could happen is that the script does a git pull, but does not find any new changes. The git hook will not be called, and none of your other tasks will be executed.