Last week was Strange Loop; this week was vacation. The original vacation plan was to get some rest, but Strange Loop is a conference that leaves you wanting to play. I wanted to play with combinators, and the easiest way to do that was to play with Haskell, but to really appreciate Haskell I needed to play with the lambda calculus and the Hindley–Milner type system. And this is just from two of the talks.

There’s also GraphQL to explore. Is it really better than REST? Giving up URLs feels weird, but GraphQL also addresses many frustrations. And with five tracks, videos for the other 80% of the conference still need watched.

Vacation turned into a week of exploration. If you can afford to take a week (or more!) after a conference, do it. That is your best chance to really dig into all the new information.

Since I have moved off of CDN hosting and onto a VPS and have more control over the tech stack, I decided to go ahead and set up HTTP/2. It only took a few minutes including research and implementation.

I was already running NGINX on Debian with TLS enabled. NGINX’s stable branch currently has version 1.8, and we need 1.9, so we have to change our apt sources from

deb http://nginx.org/packages/debian/ jessie nginx
deb-src http://nginx.org/packages/debian/ jessie nginx

to

deb http://nginx.org/packages/mainline/debian/ jessie nginx
deb-src http://nginx.org/packages/mainline/debian/ jessie nginx

Next we look for any TLS listeners—I’m not bothering with non-TLS since it just redirects to the secure version—and add http2. Here is a truncated example that leaves out things like certificate and file location configurations.

server {
    listen       443 ssl http2;
    server_name  www.thisoneplace.com;
}

Restart the server and you’re done. (Reloading might also work, but I restarted so I can’t say for sure.)

I’ve made a few under-the-hood changes to the site and thought you might like a quick update. The biggest change is switching to TLS. In addition to TLS, Web fonts have been removed, hosting is now done from a VPS and not a CDN, and a couple of CSS issues got cleaned up.

The switch to TLS was made because I kept reading that I should. Also, I’ve been thinking about playing around with Service Workers which require HTTPS. Hopefully your RSS readers don’t get tripped up.

Because I wanted a custom certificate and there don’t seem to be affordable options for secure CDN hosting, I switched to a trusty VPS. Having a dedicated IP means I can be friendlier to older clients that don’t support SNI. It’s actually quite nice running a traditional server again where things like serving up an index file for directories are handled pretty easily out of the box. It will also give me the flexibility in the future if there are dynamic bits I want to add to the site.

I’ve been thinking about removing Web fonts for a while. The typography does not look as nice, but the site sure feels snappy now. The main page is around 15 kB of HTML and 5 kB of CSS, both uncompressed. With no other changes, I’ve reduced the amount of data transferred by about 95%. Really, rethink those Web fonts. While we’re at it, let’s rethink all of those images and scripts and style sheets.

The last thing I did was set up Codeship to deploy my site automatically. After you’ve hooked up your repository, you’ll need to copy the SSH public key under the project’s general settings into ~/.ssh/authorized_keys for the user that will be doing the deploying. Since I’m using Jekyll, the following commands did the trick.

# Setup Commands
bundle install

# Custom Deployment Script
bundle exec jekyll build
rsync -avz -e "ssh" _site/ user@host:path/to/site/

Be careful with the trailing slashes in rsync—they can be tricky.

Finally, if you remember Day 51, I cleaned up a couple of the quicker CSS issues noted there. Eventually the others will be cleaned up as well.

Today I gave a “lightning talk” at OKC.js, Functional Reactive Programming with Highland.js. If the video turned out OK, I’ll post a link when it’s available. For now, you can look at the slides, speaker notes, and demos on GitHub.

I have come up with my next 100 days, and you will not be getting regular updates. The next 100 will not be as easy to measure and will be more challenging from an accountability standpoint.

In short, I will be developing a product for a side business. Each day will be a small step closer to a viable product.

I’ve had an itch to start a side project ever since attending 360|iDev, more specifically since attending Charles Perry’s talk, Succeeding Slowly: A Practical Guide to Going Indie. But a project isn’t something that will necessarily be viable commercially. A project is figuring out how to use OpenCL or painting a bedroom. I really want a side business.

The need to pursue a side business instead of a project became apparent after listening to audiobooks for two of Charles’s recommendations, Personal MBA and Start Small, Stay Small.

The tricky part was finding a niche. While not sharing yet which niche that is, I will share one that was ruled out: music education. Actually, make that all of education.

Music education as a market is attractive because it’s a field I know. I know which magazines educators subscribe to, which conferences they attend, and what types of problems I could help solve.

The problem with music education is marketing. With most programs being publicly funded and teachers being paid based on years of experience and not profitability, the value proposition must be much higher to sell to any individual program.

Coming up with a product that is appealing to educators at large is even trickier. Yes, the market is larger, but it’s pretty saturated for products that would be of use across disciplines. The attention of potential customers is also diffused across more magazines, conferences, and Web sites.

The niche I will target is an order of magnitude (or two) smaller than education, but it’s focus is more concentrated. They have real problems I can help solve, and their time is very valuable, so they should be willing to pay for a product that gives back hours each week.

Done! And ready for a break. My expectation was for this project to gradually become easier over the course of 100 days, and it did for the first couple of months. After that it started to feel like work, but I’m glad to have finished.

The plan is to do 100 days of something starting in September. I don’t know what it will be, and I might not announce what it is.

Thanks to Jeremy Keith for the inspriration for this project, and thanks to those who provided feedback. I look forward to the break but will miss the challenge.

For the next four days I’ll do my best to get my head out of Web development and into iOS. It will be weird, and I’ll have to do my best not to talk about the Web too much while at 360|iDev.

But first I need to rewrite a little code for work that I forgot to commit before leaving the house. It is my first attempt to integrate Hapi with Highland, and I would cautiously call it a success. The libraries we use are a mix of streams, promises, and callbacks, and now everything is just a stream.

This is mostly a teaser for what will be coming in a week or two, but I have found a JavaScript library that I adore. As you know, I’ve never been in love with promises, I like streams, and I’d like to be able to combine the two with a more functional flavor.

This is where Highland.js comes in. You can throw just about anything at it—arrays, generators, streams, promises, iterators, iterables—and it will convert it to a mappable stream. Now we have one interface to deal with synchronous and asynchronous code alike in a more composable manner.

Reading through The Language of Modular Design, there’s really not much to disagree with. Spending time as a team to develop a design language is useful and, if nothing else, helps remove ambiguity.

But whenever I read articles like this, my fear is teams will invent entirely new vocabularies when there are existing ones that are more interoperable. Don’t create a class when an element or well-defined attribute will do. Look at schema.org or microformats. Once you’ve exhausted your options, then add a well-considered class and put it at the highest level of your component that makes sense.

I agree with Marco Arment’s recent post, The Ethics of Modern Web Ad-Blocking, and would like to add to his argument. There is no agreement between the publisher and reader as to how Web content will be consumed. The reader may choose to browse without JavaScript, without images, in a terminal, with a screen-reader, with a refreshable braille display, or any other number of ways. I can choose to hide all <h1> tags if I want.

But publishers and advertisers, much like developers, crave control. They want to force you to consume their content the way they prescribe.