English keyboard layout hints for German developers

The German keyboard layout is great. It has everything you need, including all of the umlauts, the ß and also the µ. For programming, however, the German keyboard layout is 💩: The normal braces are on 8 and 9 with shift state, just off by one from the English ones at 9 and 0, but the square and curly braces are available only on Alt Gr combos left and right from that. Also the forward and backward slashes are Shift and Alt Gr combos. You can imagine that this slows you down.

So, to be more efficient when writing code, I tried and trained myself to use an English keyboard layout. This is, what I learned. Continue reading “English keyboard layout hints for German developers”

My developers toolbelt 2016

I cought a tweet a few days ago asking for your developers toolbelt, specifically on windows. And I gave a very short answer and mentioned I would blog about this:

So, this is a more elaborate answer to the developers toolbelt question. My default windows developer installation contains the following:

Continue reading “My developers toolbelt 2016”

Running Windows 10 Ubuntu Bash in Cmder

“Can you run Bash in Cmder?” – In the comments of my last post (install and run (Oh-my-) zsh on Bash on Ubuntu on Windows), I was asked whether it would be possible to run the Bash (or Zsh) also in Cmder. First I thought it was not possible, but then I got curious. After digging in a bit more it turned out that it IS, in fact, possible. And it’s not difficult too.

So, since I figured out how it works, I also want to show you how you can run the Windows 10 Ubuntu Bash (and/or Zsh) in Cmder.
Continue reading “Running Windows 10 Ubuntu Bash in Cmder”

How to install and run (Oh-My-) zsh on Windows

I run zsh on Windows. But why? Some time ago, when I was still using a Mac, one of my colleagues suggested to use zsh instead of bash.

Since then I switched to a Surface Book which I happily preferred over OS X mac OS and mainly use cmdr as my shell. Now the Windows 10 Anniversary update is out, and it comes with “Bash on Ubuntu on Windows“.

Now, while having bash on my fingertips again, my colleagues’ suggestion came back to my mind, and I tried to use zsh again.
Continue reading “How to install and run (Oh-My-) zsh on Windows”

Static site gens the 2nd: Hexo and Sandra.Snow

In my recent blog post I wrote about my experiences so far with static site gens in general. I said I was looking into Hexo before I go on with my plan B and this is what I did.

Hexo is very capable. If you really just want to a blog, then this is the way to go (imho). The main problem with Hexo is that it is a one-man-show from China and that this guy is currently in the middle of the process to release Hexo 3.0. Which is not a bad thing, but for one several plugins have not yet been updated, which makes it very hard to get things running. Then again, some plugins like the sitemap plugin that should generate a sitemap.xml do not have access to all entries for the tags and the categories. That said, I could probably write my own, but while the API is documented somehow I don’t got around configuring my WebStorm IDE correctly so that it indeed provides me with code completion on the Hexo API, which makes everything very tedious.
Continue reading “Static site gens the 2nd: Hexo and Sandra.Snow”

Ask a Ninja: Current state of static site generators

Over the course of the last weekend I tried to built a website for a side project of mine (gaming related). To broaden my horizon, and to be able to host the website cheap and fast, I wanted to use a static site generator for it.

First try: Jekyll. TL;DR: Does not work on windows.

Since Jekyll is directly supported by Github pages, and I wanted to host here, and a lot of other guys around on my Twitter timeline use Jekyll, I thought this is the way to go.
Continue reading “Ask a Ninja: Current state of static site generators”

Note to myself: Regular Expressions performance

This post is mostly as a reminder for myself, to not loose these important links again. But said that, it’s probably interesting for you too, when you care about performance and the .NET behaviour around regular expressions (Regex).

The common things

In the .NET world, some things are very common. First is, you are advised to use a StringBuilder whenever you concatenate some strings. Second is: If a Regex is slow, use RegexOptions.Compiled to fix it. Well… Now, in fact there are reasons for this sort of advise. String concatenation IS slow, for various, commonly known reasons. But still a StringBuilder has some overhead and there are situations where using it imposes an unwanted overhead.

The very same goes for RegexOptions.Compiled, and Jeff Atwood, aka Coding Horror, wrote a very good article about that a few years ago: To compile or not to compile (Jeff Atwood).

In one of the comments another article from MSDN (BCL Blog) is referenced, where the different caching behaviour of Regex in .NET 1.1 vs. .NET 2.0 is explained: Regex Class Caching Changes between .NET Framework 1.1 and .NET Framework 2.0 (Josh Free).

The not-so-common things

There is only a single thing that is true for each and every kind of performance optimization. And it’s the simple two words: “It depends.”.

With regular expressions, the first thing any performance issue depends on is, if you really need a regular expression for the task. Of course, if you really know regular expressions, what they can do and what they can’t, and for what they are the correct tool, you are very likely to not run into those kinds of problems. But when you just learned about the power of Regexes (all you have is a hammer) everything starts to look as a string desperatly waiting to get matched (everything is a nail). What I want to say is: Not everything that could be solved with a Regex also should be solved by one. Again, I have a link for me and you to keep in your Regex link collection: Regular Expressions: Now You Have Two Problems (Jeff Atwood).

Now, finally to performance optimization links.

There is a good blog article series on the MSDN BCL Blog (like the one above) that goes very deep into how the Regex class performs in different scenarios. You find them here:

And, besides those, once again a nice article on “catastrophic backtracking” from Jeff: Regex Performance (Jeff Atwood).

One more thing

There are three articles, that are not really available anymore. Three very good articles from Mike, that you can only retrieve from the wayback machine. I’m really thinking hard about providing a mirror for these articles on my blog too. But until then, here are the links:

Ask a Ninja: Is the “Googlevelopment” approach bad?

I stumbled upon a recent and very interesting blog post from Rick Strahl: “The Search Engine Developer“. Rick in turn was motivated by a post from Scott Hanselman who asked “Am I really a developer or just a good googler?“.

That inspired me to write this post, too. Mostly because this topic has to do a lot with self-improvement, learning and attitude.

What is it, what Ninja calls Googlevelopment?

We all know it: If we encounter something in our job we don’t know, it is very tempting to throw some words related to it into the search engine of your choice, sift through the results and if there’s a link to StackOverflow or to a blog from certain persons you know (like from conferences, book authors, via twitter, from others that pointed you to them earlier), these are your first stops. You don’t even look further, because your problem is most probably solved. You copy the code, paste it into your solution, make some adjustments, test it and don’t think further. There’s no problem anymore.

To the a point

Scott is just having so much keystrokes left, and because of that didn’t give a broad explanation on WHY he has the opinion he wrote down. Well, it isn’t even in fact an opinion you read in his post, but a call for action: Try to stop googlevelopment and do it the old fashioned way: Write it yourself, go to user groups, learn, do code Katas etc. One can easily guess that Scott thinks googlevelopment is a bad Hobbit habit, and you shouldn’t do it.

Rick, instead, was a bit more chatty. He mentioned that it “feels like [he’s] become a slacker at best and a plagiarizer at worst” sometimes. He summed up his experience, back to the days where there simply was no publicly available Internet – no chance to copy your code -, through the 90ies (some online manuals, discussion forums), through the millenium where blogs started to spread and up to now, where collaborative sites like StackExchange are flourishing.

Using libraries, for Rick, is “standing on the shoulder of giants“, and copying and adopting code from the intertubes gives him a rough feeling about the interior of the library, to be able to use it the right way, but not too deeply because, his example was a QR code library, that’s not his actual problem domain.

He, while being totally right on that matter, said that there is no need to re-invent the wheels others invented previously. And then, there’s this bummer: “It’s fun to wax nostalgic about ‘back in the day’ stories, but I don’t miss those days one bit. I don’t think anybody does…

Not missing the old days?

Rick, honestly? You don’t miss these days? I think this ‘back in the day’ time was the time that made you the developer you are today. Those were the days that made you learn your stuff.

Today’s younger developers, that didn’t went through this (more or less hard) school of learning by themselves, trying things, failing, learning from their failure, inspecting stuff, who JUST started as ‘search engine developers’ or googlevelopers, can’t really leverage the information they find on the net. Fiddling around with your platform, with your compiler, with sample sources (if any), with documentation is in the first place teaching you how to learn.

Rick then goes on describing that, because there are so much things out there, it could happen that you have a great idea and want to go on this. Then you might find finished implementations (even if not really ‘good’) – and just stick with them. Even if those implementations would deserve a new competing library from exactly you – because you could do better. But you left it alone.

Making this decision, re-implement or stick with a not-so-good solutions, is, of course, mainly driven by time / effort / money, but also by an educated analysis of risks and chances and the technical debt you’re taking when using a not-so-good solution. You also need to be educated to estimate whether a re-invention would benefit your (and maybe others too, talking about open source) solution.

You can’t, however, get that evaluation right when you haven’t learned the implications of doing it yourself vs. using existing stuff when you did not do a lot by yourself previously.

Ask a Ninja: Is Googlevelopment bad?

So, now it’s time for my personal opinion on that topic.

I already mentioned that I’m not with Ricks point of view. I think it’s sad that he does not miss the old days. I started developing software very early. I got my first PC when I was 9 and two to three years later just ‘using’ it got boring. With 14 I wrote the first program that I sold to a doctor to manage lists of his patients. The german health insurance card was just available and there were keyboards with an integrated card reader that would just ‘type’ in all the data from the card when it was inserted.

My program just stored the data in a flat file (I didn’t know that this format I chose was already known as CSV), and I had to invent and implement my own sorting algorithm. If I remember correctly, I did something like an insertion sort. I figured out ways to send that data to a printer when requested. And I spend a lot of time formatting the outputs of my program to look nice and present them in a beautiful way to its users (mostly young women that worked there and that I tried to impress back then, hell I was 14 🙂 ). So, I figured all that out. It took long. I learned a lot. And it was fun.

I’d love to learn new stuff all day. Fiddling with stuff. Trying to get things done by myself. I really miss that a lot. Sadly, in todays businesses this isn’t possible anymore. There’s just a tiny window of time available for that kind of stuff.

Conclusion

Finally Rick comes to this conclusion: “Search engines are another powerful tool in our arsenal and we can and should let them help us do our job and make that job easier. But at the same time we shouldn’t let them lull us into a false sense of security – into a sense of thinking that all we need is information at our fingertips.“.

Having all that information at our fingertips empowers us to build great stuff. It is information we can use to learn from it. And we have the power to decide to NOT use it. Rick linked to an older article from Scott: We need to Sharpen the Saw – this is us – on a regular base.

We should try to develop – not googlevelop – more stuff by ourself. This strengthens our skills and makes us more sensitive for when we have to use stuff others did. We need to find the right balance between “standing on the shoulder of giants” and trying to be the giant. This fine line, where you’re in balance, is a moving target, though:

  • Young Padawan, more fiddling on your own, not using the force you must.
  • Knight, use the force and learn from it.
  • Master Jedi, more fiddling on your own again you should.

This is my idea. Well, not really mine. I just adopted it. With some friends I share a maxime. In German: “Schau in Dich. Schau um Dich. Schau über Dich.” This goes for three steps of learning:

  1. “Schau in Dich.” – Look inside you. This is about self-awareness. You should learn about yourself, about your learning.
  2. “Schau um Dich.” Look around you. This is about learning not from yourself, but from others. And also about learning what your influence is on others, but that would go to far at this stage.
  3. “Schau über Dich.” Look beyond you. Okay, that is a very loose translation. The aim of this part is to make you think about things in a larger scale, and push the limits.

This is also, what the learning of an apprentice, journeman and master craftsman was back in the old days. The apprentice should learn to learn. The journeman travels around, this enables him to learn more from others of his craft. The master then knows the basics of his craft, but he also tried to improve his skills, to be able to compete. Masters also could leverage their skills to try our really new stuff on their own – and succeed with that. Masters usually also were eligible to join the guild, where there was a lot of exchange between them – also about new stuff they discovered.

There is a slight chance, that this, what was done for decades back then, had some truth in it. And we software developers, engineers or craftsmen, could (and should) try to map this to our daily learning again.

Bottom line

Well. This is just a line. At the bottom. For no reason. 🙂