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:

  • Windows 10 Professional (fully updated)
    • .NET Frameworks active
    • IIS Installed
    • Dev-Mode enabled
    • Linux Subsystem installed
    • Windows Defender as Antivirus solution & default Firewall
      (no external security software)
  • Dropbox
  • 1Password
  • IE, Edge, Chrome, Firefox (for testing, yes, I do quite a bit web dev 🙂 )
  • Git for Windows for commandline usage
  • SourceTree as my graphical git client*
  • Beyond Compare as my diff tool
  • Cmder as my console of choice
    (my previous blog post is about using the Linux bash on Windows in Cmder)
  • Node Version Manager nvm for Windows, and as such a lot of node versions
  • Primary IDE: Visual Studio 2015 (with ReSharper Ultimate)
  • Secondary IDE: WebStorm
  • .NET Sourcepad: LinqPad
  • Primary Database: SQL Server 2016 Express
    other DBMS as required by projects.
  • dbForge Schema compare and dbForge Data compare
  • Office 365
    • OneNote for collaboration
    • PowerPoint for presentations
    • Outlook for e-mail comms
    • Word for occasional paperwork
  • Slack and TeamViewer for other comms / collab
  • VSCode as my main text editor
  • Atom as secondary text editor (i.e. large markdown files, where VSCode crashes)
  • Android Studio
  • Genymotion android emulator (quite a bit faster than the normal one)

In the list above, except for ReSharper, I am not listing additional addons / extensions to the other listed tools.

* – I also tried GitKraken, Tower for Windows and the GitHub client, but they are – in my opinion – not as usable as SourceTree. Especially Tower wastes too much screen estate.

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.

That said, under all static site generators Hexo is by far the most powerful one, and definitely worth a look at, as it is plain JavaScript, runs on Node and is very unproblematic to install both on Windows and on OS X.

Before I went on with my plan B I also tried a quick look at Sandra.Snow. Sandra.Snow is a .NET based static site gen. I looked at it and its source and also talked to its creator on JabbR. I did not really dig deeper into it. Again the problem was that it is totally intended to be a blog platform. Doing some more sophisticated website stuff with it is not really supported and seems very hard to do.

So, from my trip to the world of static site gens I am back with a finding. If you want a simple blog, concentrate on your articles, are fine with some predefined template you don’t want to make a lot of changes to and don’t want to do more sophisticated stuff like creating menus for all of your categories and tags on the start page, which involves knowing all posts metadata while generating the main page, it seems almost all static site gens are capable of delivering what you need. As soon as you want to do more fancy stuff, some fall apart sooner, some later.

If I wanted to move my personal blog (this one) away from WordPress to a static page, it probably would be Hexo.
But for now, I’m firing up my Visual Studio on my PC and Xamarin Studio on my Mac and build my website with ASP.NET MVC. That at least also allows me to implement a search functionality into the page.

Update: Fixed some of my mistakes. Thanks to Andreas H. for proofreading. 🙂

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.

Jekyll does not state that it would work under Windows. It is also not officially supported there. So this is not a great surprise. There were, however, some tutorials / manuals around that described how it should be able to run on Windows, which I wanted to follow. I installed ruby, and right from the the first try to install the Jekyll gem failed hard. So I could not even follow those instructions, as already the installation failed because of some strange SSL errors.

That’s when I looked for an alternative. I found the page Staticgen.com that lists a couple of projects related to this topic. This lead me to the next step.

Second try: Pretzel. TL;DR: Not stable. Crashes all the time.

As I am a developer that feels himself comfortable on the .NET platform, I looked for something compatible with Jekyll that, mabye, would run on Windows and on Mono on my Mac. Pretzel was the candidate. I installed Pretzel, and it worked with the template that ships with it.

Sadly, as soon as I started to throw in my own HTML, CSS and JS, the Pretzel preview server crashed at least at every second request. So it was changing files, restart Pretzel, preview. Change files, restart Pretzel, preview, and so on. I did this like half an hour when I became too annoyed to follow this path further.

At the end of the day, I want to build a website, and not debug a tool that will generate some HTML for me. So it was time to look for some alternative again. Since there weren’t any other alternatives on .NET that were Jekyll compatible, I thought about Node as a platform. I know that Node JS runs on Windows and my Mac, I had some previous experience with Node and Javascript is not that bad.

I did not go to StaticGen this time, because a handful of people on my timeline also started to use a Node based static site generator: Wintersmith. So without double checking the facts and blindly trusting my tech-colleagues, I downloaded it.

Third try: Wintersmith. TL;DR: Plugins don’t work and/or are too complicated. Not enough docs.

To be honest, I was totally turned off by the default template engine Jade. I have a full HTML template, and Jade is nowhere near HTML. Some people may find that cool, but it does not represent the way I want to work with my website.

Gladly, the template system can be changed, and I switched to Handlebars, as I liked the easy and lightweight mixin with HTML. Then the difficulties began.

The HTML template I was going to use requires Bootstrap (which requires jQuery), FontAwesome, I used two additional webfonts to match a certain website style, and alltogether I ended up with a few javascript and css files. I wanted them combined and minified, but the most promising Wintersmith plugin kelvin was not ported to Wintersmith 2.

Another plugin problem was wintersmith-tags. First of all, the plugin exposes methods to be called in the template. Something Handlebars is not capable of. Luckily the switch to Nunjucks for the templating engine was more or less done quickly without a lot of effort, but then I noticed that wintersmith-tags would not, despite the documentation stating otherwise, list all available tags on call of the corresponding method. I just got back an empty array.

That the plugins are mostly written in Coffescript, which I am not used to read, does not make it any better. The fact that wintersmith-tags was the only plugin with a rough documentation makes it even more difficult to work with. Up to the point where I gave up I had 11 plugins installed, none working as I intended them to.

Conclusion:

Fact is: I’m totally frustrated about the extremely poor experience I had over the last weekend.

I will give it a last shot with Hexo. It seems more active than Wintersmith, is pure Javascript (no Coffeescript, so for me better to read and understand), and it seems to have a larger installation base, so the chances are higher to get questions answered by the community. But if that does not work out too, I already came up with my plan B:

Let go of all these static site gens available out there. I’m probably going another route: I am a developer with deep knowledge in .NET. And .NET, especially ASP.NET MVC, Razor, Web.Optimization etc. has all the stuff required to built a great website, right at my fingertips. But I still want simple HTML delivered.

It is likely I’m going to grab ASP.NET vNext and built my own static site gen on top of it. Using the next .NET version it will also run cross-platform and I can use it on my Mac too.

This way I can make sure it works as I want it to, and since the guys using Wintersmith (and by the way are not really happy with it too) are also mainly former .NET devs, I probably have a good chance to get the first users except me, too. But I really hope Hexo is going to work out. Doing that much work just to get a simple but modern website on, is quite ridiculous. A decade ago it was a lot easier, but expecations have risen since then. A lot.

Update 2015-02-10: I will postpone my exploration of Hexo a little bit. It seems the project is still alive and just a few days ago release it’s version 3 RC. I can’t figure out if Hexo does support Nunjucks but I’m getting in touch with its creator and will find out.

Why FireMonkey is wrong, the second

I just stumbled upon a really, really great post on Steven Sinofskys Blog.

His article is about the challenges of cross-platform development in general, and he brings up some rather good points on why some approaches will eventually fail.

I’m pretty sure he doesn’t even know about FireMonkey, but this is what he has to say on cross platform libraries in general:

One of the most common approaches developers attempt (and often provided by third parties as well) is to develop or use a library that abstracts away platform differences or claims to map a unique “meta API” to multiple platforms. These cross—platform libraries are conceptually attractive but practically unworkable over time. Again, early on this can work. Over time the platform divergence is real.

And then he continues:

Worse, as an app developer you end up relying on essentially a “shadow” OS provided by a team that has a fraction of the resources for updates, tooling, documentation, ..
[…]
It is important to keep in mind that the platforms are evolving rapidly and the customer desire for well-integrated apps (not just apps that run).

The very last point is what I already stated in my own post on why FireMonkey is wrong. I didn’t even write about the even more important first ones. And this only are quotes from one paragraph where he thinks about cross-platform libraries.

I strongly suggest that you take a few minutes and read what Sinofsky wrote about cross-platform development. And then, if you currently feel that FireMonkey could be the right tool for you, try to understand his points and re-think your position on cross-platform tooling. I’m sure you will see that FireMonkey can’t be the right tool for you – or anybody.

Why FireMonkey is so fundamentally wrong in every aspect of it’s being

A short time ago I had a harsh twitter argument with Nick Hodges (@NickHodges) about the FireMonkey framework in Delphi XE4 (you may know that I had the start of my professional career with Delphi and started as a speaker at Delphi conferences).

It all started with the definition of ‘native’ or – even worse – ‘true native’, but let’s start at the beginning. I know the audience of my blog is mostly .NET focused, so let me get you all set with the required background information.

FireMonkey

So, let’s start what FireMonkey is – or aims to be. FireMonkey is a application development framework (or platform, as Embarcadero likes to call it) and contains components that should enable the developer to build cross-applications with a singe code base for Windows, Mac OS X, iOS and soon to come Android. FireMonkey is written for Delphi and can also be used from C++ within Embarcaderos C++ Builder.

So the main idea is, that you design your forms with FireMonkey components and controls, double-click on buttons to add your business logic like Delphi developers did this for the last decades and then be able to compile the application for Windows, for Mac OS X and for iOS without changing it anymore.

And indeed, this works technically…

Architecture

…but this is also already the point where it starts getting wrong.

FireMonkey, by it’s RAD approach, encourages the developer to click his user interface together, double-click on controls and put all the logic onto the form – where it doesn’t belong. I’m not going to argue with anybody about decoupling, testability of code and all the other Clean Code aspects and concepts. A good developer should have the inner urge to produce code at a certain minimum quality level and putting everything on the form is nothing that helps here. So, the basic concept that FireMonkey encourages is wrong.

New and not-so-advanced developers tend to adopt this bad style and start running into a direction that will end up in fatality. Good developers instead will start by building up a good architecture for their application. Most probably working with tests, that makes the usage of some DI container a no-brainer. This most probably also lead to a good decoupled architecture on the application frontend, perhaps introducing some MVC concept for their GUI. Only this enables them to take a good approach to real and thoughtful cross platform development, but more on that in a minute.

Cross-Platform

Let’s talk about cross platform development in a general way, before we go back to FireMonkey.

Every platform has its specifics. And a user – that is, in fact, our customer we want to sell our application too – chooses his platform for some reason. There are multiple approaches to make the user happy, and the most simple thing is, to integrate the app seamlessly into the environment (platform) the user chose to please him.

Let’s talk a little about UX. I’m thinking about the overall user experience with your application here, not only the look & feel of the GUI. It’s the whole full package including a good guidance through the workflow, helping the user to not enter crap into your app, assisting him to solve problems when he does, make everything accessible for everyone, especially impaired users, and of course also response times and stuff. As said, the whole package.

All platform vendors have thought about how their platform / devices should behave, how software should behave on the platform and what they expect from an application. They offer UX guidelines that describe what fits into the environment and how applications can fit seamlessly into the platform, providing an overall exquisite user experience to the guys you want money from.

Comparing just Apples (iOS and the Mac) and Googles (Android), which are the current relevant platforms for FireMonkey besides Desktop-Windows, UX guidelines shows you how different the platforms are. They are fundamentally different in how the control flow in applications is expected from the user. Leave alone Windows RT for tables and Windows Phone, which have a radical new approach to interacting with applications. But since Windows RT and Windows Phone are not (yet ?) supported, we don’t need to get into those details right now. Just so far right now: Delphi is marketed as the best/fastest/most productive dev tool for Windows. Why can’t you target Windows RT? Or write Windows Store applications for Windows 8 with it? Well, thats another topic. But still taking into account, that the main target audience for FireMonkey are Delphi (and as such mainly Windows-) developers, this leads into a fatal direction:

FireMonkey encourages the following: The Windows-Developer designs his FireMonkey form for Mobile Devices just as he would design a Windows-Application form. This for Windows designed UX is ported in a one-size-fits-all attempt onto the Mac (not so extremely terrible bad), but also to iOS and later Android (overly extremely bad).

Why is this bad? Because the user chose his platform with something in his mind. This something is the overall user experience with the device and of course with the applications he gets from the store within the platform itself. It’s a closed ecosystem for his needs. He expects his iPhone/iPad-Applications to come in his loved iOS style or he expects his Android-Applications to come in an Android-Style. So again, we need to please our customers because they are the ones buying our applications and giving us their money. So how can we make them happy? Give them, what they expect.

Users expectations, and a sub-plot

That can be done only in one way: To embrace the platform and behave like a good citizen on that platform.
Developing a ‘native’ application is not the only way, but whatever technology you choose, the result should still integrate seamlessly into the environment.

A good example is Exfm. They have a music sharing service, and used to publish a ‘native’ iOS application. Native as in written in Objective-C with XCode. It had a 4-star rating. Still they did a rewrite of the app – with HTML5 and JavaScript – based on PhoneGap. During the rewrite and despite the fact that they were actually programming a web application that runs in a UIWebView browser, they incredibly focused on iOS detail behaviour like the scroll bounce thingy or the possibility to scroll-bounce elements that don’t need to be scrolled because they are not larger than the area displaying them. They even mimicked the iOS behaviour that you can tap and hold on a button, move away from it, slide over the button again and lift your finger to trigger it. They did that with HTML 5.

They did that for one reason: To behave like a good citizen on iOS. To please their users.

And now they have a HTML application that you can’t tell apart from a native application that uses the native UI controls of iOS. The new app now got a 4.5 star rating and more downloads than ever. Here’s an article with a lot of more detail information about the little iOS details that make the app feel ‘right’ on iOS.

Now let’s get back to FireMonkey.

Einheitsbrei

I’m trying to introduce a new word to my english speaking friends: ‘Einheitsbrei’. You already use some german words like Zeitgeist and Kindergarten, and now it’s time for ‘Einheitsbrei’.

Einheitsbrei is a word that could be translated with ‘boring standard mash’. Is used deprecative and describes things that are boring, common, and don’t have any specific characteristic or outstanding elements.

FireMonkey apps are Einheitsbrei. They are sub-standard on every platform and don’t take into account the little, loved by users, elements of the platform they are running on. And in some cases they don’t even get the basic things right.

Architecture, the second: Doing it better

In the first architecture section I described that a good application architecture very probably involves some sort of DI and MVC on the GUI part.

Nick said on twitter:

So, let’s take this for granted. When I can call ‘any API I want’ with Delphi for iOS, then I would have full access to all native UI controls on iOS. When I already have MVC in my application, then there is nothing that would hinder me as a developer to use the DI container to instantiate a view for iOS that is using the iOS native UI controls, and to instantiate a view for Android that makes use of the native Android UI controls there.

With just a little bit more effort on the views using the platform APIs, bypassing FireMonkeys UI controls, your app could behave like a good citizen on the very specific platform my customer chose for himself for a reason. Remember: that customer guy is the guy I need to make happy because I want him to give me his money.

Conclusion

Yes, it’s more effort. Yes, it will take longer. Yes, it will require you to learn about the platforms UX design guidelines and about the platforms native UI controls. But it’s worth it. Like extfm, who re-wrote an existing app with the goal to their iOS users more happy and another one that makes their Android users happy.

FireMonkey instead encourages you to produce Einheitsbrei. And this is just so wrong. You will find out, when you don’t get the ratings required to have enough sales for your app. Users are cruel. They buy your app, and rate it down when they don’t like it. And they tell other users to not buy your app, when they are not happy with it. They will, however, rate your app up and tell others to also buy when they really like it. But just when the app’s buttons are so good, that they want to lick them.

Your app needs to be outstanding, of high quality and provide a well designed user experience to be successful and to be able to compete against other applications. Einheitsbrei doesn’t sell. And FireMonkey, by design, encourages Einheitsbrei. You won’t do yourself a favor by using it.

This is my opinion on why FireMonkey is just so wrong.