Blog

If you develop websites or software, you now that procedures and code fragments may be reused from time to time. As a developer you should always try to avoid those repetitions.

The first step is independent of what editor you use, or what kind of thing you develop. The first step should always be, to rethink your code. If you repeat parts of your code over and over, you should always ask yourself if that part shouldn't be better put in a method or function.

The more repetitions you have, the more inflated your code is, the more difficult it is to maintain it. If you then have to change something, you may need to this not only one time but again and again. And if you miss just one part, that may have uncertain consequences.

Well, okay… Sometimes you just repeat yourself. If you want to or not. For example when you start a new project. You need that html5 template, that javascript function or your personal css-template.

Because of this, the smart developer has a collection of those templates called snippets.

Snippets

You can organize your snippets in various ways. As a simple text file anywhere on your hard drive or dropbox folder. Using an application doing the work for you. And Sublime Text by itself has a snippet functionality included.

Sublime Text Snippets

Those snippets have a huge advantage, you can set shortcuts or use autocomplete to insert them. And you can use placeholders within snippets which are reachable via the tab key.

The big disadvantage: These snippets are stored in your Sublime Text user directory. You don't really have an overview. And it's hard work to sync them.

But I want my snippets to be available anywhere and regardless of what editor I use.

GitHub Snippets

GitHub has an own system for snippets, called Gists. If you have a GitHub account you can create and manage gists.

After trying several methods I sticked with Gists.

The biggest advantage: I can use them anywhere. I do only need a browser and access to the web. Simply login to GitHub and here they are.

And beside my own Gists I can also have a look at public Gists of other users. So if I need a snippet to solve a certain problem, I can just perform a search and (may) get a more or less long list of solutions. As known from GitHub I can star Gists or fork them to create my own version.

If I don't want to share mit snippet with others, I can create a private one. Nobody will be able to access it.

Sublime Text Gists

As we know, there is a Sublime Text Plugin for every possible scenario. Yes, you heard right! For EVERY scenario, don't argue with me! ;)

So there is a plugin for Gists: https://github.com/condemil/Gist

You need GitHub account (of course) otherwise you cannot create Gists. To use the plugin, you have to create an Access Token which is described in the README of the plugin step by step.

Setup

After you created your Token, you just have to add it to your Sublime Text Settings. Just go to: Sublime Text > Preferences > Package Settings > Gist > Settings User. And insert your Token:

{
    "token": "1234567890"
}

Using the plugin

You can use the plugin sublimelike via shortcut or cmd+shift+p. Just enter gist and you'll get a list of functions. Here you can create Gists (public and private), add Gists as new file or insert them into the currently open file.

If you choose Insert Gist you'll see a list of you own Gists and those you stared. You can limit the list by starting to type and/or you can navigation with the arrow-keys.

Creation of Gists

You can create Gists right from Sublime Text or via web. I prefer sublime text.

I always try to name my Gists clearly. For that I use a simple syntax: I start with the code language, like this:
[html], [sh], [scss] that way I can quickly see the kind of code and limit my search to a certain language.

Share

Sharing it great! Because of that, most of my Gists are public. Maybe you have some interesting Gists on your own. Post a link in the comments if you like or share them via Twitter.

Sublime Text offers, beside numerous plugins, a lot of themes, to customize the editor as you wish. These are my top3 favorite themes for Sublime Text 3.

Top 1: Cobalt 2

For me, this is the far best theme for Sublime Text. Beautiful colors which help you, capture the source code fast. The sidebar icons are really beautiful and are making it easy to determine file types pretty fast. The hightlight color is a rich yellow, a great color for the ui to focus fast.

By the way: There are also Cobalt 2 themes for Alfred and iTerm!

Get the theme

Top 2: PreDawn

I used PreDawn a long time, until I a stumbled upon Cobalt 2. The highlight color is a bright orange. The colors are chosen very well and make it easy to scan the code. Unfortunately the last version I used did not have a lot of sidebar icons.

Pro: There are a lot configuration parameters to customize that theme, like preferences for things like tab sizes.

Get the theme

Top 3: Spacegray

Spacegray is, as the name may say, not that colorful as the other two. But the color choice is great, too. The theme as two modes you can choose from, dark and light. Unfortunately there are no sidebar icons. But beside that it is clear and good to use.

Get the theme

Hint, hint

If you just want to try a theme and don't want to download it for that purpose, you should have a look at ColorSublime. The plugin works like the package manager. The great thing is, you can browse through the theme list in sublime and see a live theme preview with your current code open.

Get the plugin

All images are from the repositories of the themes

In Germany there is that cheeky term „Internetausdrucker“ - internet printer - which is particularly addressed to politicians. But shouldn't we take care of those printing people?

That's exactly what I thought about, when I was looking at my site some time ago. To be honest, I did not care if my page is looking good when printed. So I just tried it and had a look at the print preview.

It did not look very well. Many elements of the page, which are unimportant for print, would have been printed. For example the sidebar or the comments.

Hide unimportant stuff

So I decided to create a print stylesheet and started hiding all the things which are not usefull on a print. That's the sidebar, the comments and the navigation. The print view should be the raw text only.
As a foundation for my new css, I used my css for the mobile breakpoint which reduces the site to a minimal view. And I additionally hided the navigation.

To add a stylesheet for printing, you just need to add something like this within :

<link href="print.css" rel="stylesheet" media="print">

Fonts

Looking at the raw text, I immediately saw, I had to reduce the font size. So I set it to 12pt and added some paddings and margins.

Links on the page

You cannot print links. I could add the full links at the bottom of each article and everybody who is printing my text could type them in, if needed. But that is no good solution.
So what if somebody takes a look at the printed article some days after printing (or gives the text to a friend) and wants to visit a link?

Finaly QR codes have a right to exist!

In print view I add a QR code below every article. So if someone prints one of my articles, he/she/it just needs to scan the code and will be redirected to the original post.

To create the QR code, I use a JavaScript library, which just needs an URL and (in my case) a size of the code-image.

Opinions?

I am curious what you think about that topic. Did you optimize you website for printing? Tell me in the comments or send me a message on twitter.

If you provide source code, may it be as an application or as an open source tool, you might want to ship a changelog with it. Using git and gruntjs, makes it easy to create such a changelog fast and automatically.

We don't want to care about the creation of a changelog by our own. We better invest that time to develop our tools. Because of that, we need a simple bashscript, which does the work for us. Thanks to git, such a script is written easily.

Getting the last changes

To get the last changes on my code, I use:

git log

As you can see, the output is pretty extensive. We do not need so many details. So we'll limit the output a bit, by shrinking the format:

git log --format="  * %s"

Now the output is just the message with a * as prefix:

* switched to grunt

Limit the output even more

Our changelog should only include the most important commit messages, not every commit is interessesting enough to make its way into our changelog. So, at first, we'll get rid of the merge messages:

git log --format="  * %s" --no-merges

Now we just want to see really relevant commits. To do so, we need a syntax for our commit messages. Some tools like Stash or GitHub come with such a predefined syntax. You can point to issues or stories by using hashtags, like so:

ISSUE-123 "https://maurice-renck.de/en/tags/tag:resolve">\#resolve nasty IE Bug
STORY-456 "https://maurice-renck.de/en/tags/tag:close">\#close do those fancy css-transitions

Of course eventually you can define the syntax. But it is important every collaborator knows and uses it. So, now we know our syntax we can use it to limit the output even more:

git log --format="  * %s" --no-merges --grep=#resolve --grep=#close

This way we'll only see commit messages including one of the tags. You can, of course, define more or less tags, if you want to.

Limit the time period

Okay, we do have our output as we want to, only the most important messages will be shown. But there still is way too much output, right? We also want to limit the period of time:

git log --since="2 Weeks" --format="  * %s" --no-merges --grep=#resolve --grep=#close

Now we'll get the most important commit messages of the last two weeks. Good, isn't it? But not good enough. We do not want a fixed period. What we need, are all changes since the last creation of our changelog.

For that, we need to know when we created the changelog the last time. You could also use release-tags as an idicator, if you're working with those. We'll use the date of the changelog file. We'll start creating an empty one:

touch changelog.txt

Now we can read the modification date of the file and format it the way we need, to get it work with git log:

ls -l changelog.txt | awk '{print $6,  $7}'
> 16 Sep

The date output can vary a bit according to the system you use, but in most cases, you'll be fine with that.

Getting the authors

What would our changelog be without the authors of the code? I'll be honest, I didn't find a solution I like a hundert percent, yet. I use the following for now:

git log --format='-- %aN' | sort -u 

This way we get all the names and remove doublicates.

Getting the version number

Now let's have some fun. We also want a version number to be part of our changelog. I use the version number set in my package.json, which I use with grunt:

{
  "name": "Mein Beispiel",
  "version": "1.2.3",
}

So, somehow we need to read that version number. I use a function I found here(https://gist.github.com/cjus/1047794). I modified it a bit, so I only get the values not the keys as output.

Combining everything

So we limited our commits to a certain subset and we can determine the date of our last changelog-creation, so we can use that date as starting point.

If you want to, you can modifiy the script for your needs. But I think it's a good foundation and creates a nice, usable changelog. You can run that script with a git hook or in a build job, so you'll get a fresh new changelog all the time.

You can find the script in my repository on GitHub.

If you are a developer, you should use some sort of time tracking, especially when you are a freelancer. Tracking your time can help you improve your workflow and calculate realistic proposals.

Why I track my time

If I want to plan my time realisticly, I need a kind of measurement. Not only when I want to write a proposal, this relates to all aspects of my work. After all, as a developer, I am responsible for getting my work done, even if two jobs are running parallel.
For that I need to know how long certain tasks take. This, of course, varies a bit from time to time. But I need at least a clue. In addition, I want to know, where I lose time. That is why I track things which are not directly related to my work. For example, when I read an article or have a look at my twitter-timeline.
So, at the end of the day, I do have a pretty good overview of how productive I have been and can optimize things if applicable.
Beyond that, I can see repetitions, which I then can bundle or maybe even automate.

My problem with time tracking

Actually one can summarize this briefly: Staying tuned.
Missed to turn on tracking in the morning? Then it is not worth to turn it on now. Don't behave like this. It's a trap!
Another problem is, not every mac-application has a mobile app, too. So I have to insert the data afterwards (i.e. when I was at a customers office).
It is also difficult to determine how detailed to track. Should I track every single Task? Or groups of tasks? It's a decision I do case by case. And sometimes it's really hard to decide.

What software to use?

I tried several application. Starting with a simple textfile, where I wrote down, when I started and ended tasks. In principle I can say: the more time I have to invest in time tracking, the more unlikely I will continue to use it.
I used Timings for a long time, and I liked it very much, especially after the last major update. Recently I use Tyme, because I really like the statistics (and that's what it is all about for me).

Both application share one disadvantage: I must activly tell them, what I do. That's not very difficult, both apps are easily accessable via the menubar. But why not make even more easy?

WakaTime

Some time ago, I found WakaTime and I really liked the idea. WakaTime integrates itself in your editor (for example sublime text) and tracks everything you do there. It dertermines programming languages, filenames and project titles. And whenever you use your editor, WakaTime tracks your time. So at the end of the day, you have really good statistic of what you were working on.

Disadvantages

You must keep in mind, that all that information is sent to the WakaTime Servers. Filenames, project titles, programming languages etc. Make yourself clear, that this data may make it possible to draw conclusions on what you are working on for what client. And that this may collide with a NDA!
Another disadvantage is, as a developer you also answer e-mails, work in the terminal etc. All that won't be tracked.

Conclusion

WakaTime is a nice idea, but it just tracks a small amount of my workday. If you really want to improve your tracking and your work, you should use a "classical" approach of time tracking.

Links

Timings
Tyme
Mite
WakaTime
Timely
Timecamp