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

Horrendous cool software

Devices should work together. All devices. Also from different companies. They don’t.

A good example is the feature ‘USB Tethering’:

  • When I plug my iPhone in my Macbook it works.
  • When I plug my iPhone in my Windows notebook, it works.
  • When I plug my Google Nexus in my Windows notebook, it works.
  • When I plug my Google Nexus in my Macbook Air… I’m screwed.

I didn’t find a way to make it work. I always needed to open up a mobile WiFi Hotspot to tether when I’m on the road. That sucked. And it costs a lot of battery on my phone. And I need that for Ingress 😉

Then someone saved my day. It was Joshua Wise (@jwise0) by writing a cool piece of software. What he did was writing a driver for Mac OS X that understands Microsoft’s proprietary RNDIS protocol – that is used for USB tethering by Google’s Android devices. No, I won’t go on the topic ‘Google uses a proprietary Microsoft protocol for their relatively open Android platform’ now. That’s not my thing.

The software has the interesting name HoRNDIS (pronounced horrendous) and its source is also available on GitHub. He also have binary packages available on the projects homepage for a simple installation.

And, what should I say? It works like a charm. I installed the driver, plugged my phone in via USB, activated USB tethering through the menu and now I’m publishing this blog post USB tethered.

Thank you, Joshua. Very much.

The ‘Apache on OS X Mountain Lion’ problem

Whoah, I just dived into severe problems with the apache web server on my MacBook Air, running OS X 10.8 – Moutain Lion.

In preparation of my sessions “JavaScript” and “HTML5” at the EKON 16 conference in november I wanted to set up the web server that is in fact included in the OS X installation.

In previous versions of OS X there was a ‘Web sharing’ option in the system preferences, but this was removed in Mountain Lion. There are several posts out there in the wild showing how to manually enable apache and PHP. I found this instruction on the intertubes and read (but not exactly followed) it.

In my megalomania I went: “I already did that, it can’t be that difficult now. Lets go.” (several years ago I set up apache with PHP 3.something on a Linux system).

So this is what I did:
I skipped the first part of the instruction (starting apache) and directly went to the part where I enabled the user-specific /Sites directory. I set up the directory with all required options, allo/deny rules etc. and THEN I tried to start the web server.

Guess what? It didn’t work.

So the next thing was to look for the error logs (remembering I once had experience with Linux and error logs were a good hint on where to look for my stupid errors). Sadly, the error log folder was empty. So I double-checked the apache config for alternate log folder configurations – and found none.

A experienced apache administrator would guess that there is something wrong with the config file itself, so that apache would not even know about a configured error folder to put its logs into – but I again needed to search for starting problems with apache: Port already taken? Nope. Wrong host name? Nope. It was quite a bit of trial and error until I found this blog post about troubleshooting apache on Mountain Lion. It hinted me to this little command:

sudo bash -x /usr/sbin/apachectl -k start

Starting apache this way prints the messages directly onto the console – and so I could see where apache failed to start. It was in the user-specific /Sites config. The problem was a simple typo in the closing tag (I hacked in ‘diectory’).

So far, so good. Apache launched, my user website worked at my http://localhost/~Sebastian url – but it responded with a 403 – ‘Not authorized’ every time I accessed the folder. Strangely enough, it delivered files when I directly navigated to them (i.e. localhost/~Sebastian/test.html).

In several other attempts I found that the default configuration for the root folder disallowed directory listings and did not allow overwriting this, and how to enable PHP (that commented out entry was hidden very well).

Struggling with apache configs distributed to several locations, unix command lines, nano and a extremely bloated apache documentation I am really grateful that I usually work with IIS in my day to day business. Gladly I don’t have to set up mod_mono on my MacBook Air (yet).