On Topic

A blog. Programming, Depression, Ethics, Stuff.

The Big Short

A movie hailing.

The Big Short is worthwhile to watch. The movie entertainingly condenses the issues around the financial meltdown of 2007. You can watch it without having a fucking clue about markets. Necessary terms are illustrated; see it just for those, and if you didn’t know them already, they’ll be worth the ticket on their own (though HAIL INTERNET you can find the info for free).

The scene on how derivatives work is first class. The story is told in terms of CDO, CDS, and point changes in the market; it uses real terms from the real world, not gobbledygook. This means, you can also watch the movie if you have some clue about markets. (Don’t know how it is if you’re an expert.)

Literary freedom is applied, of course, but for character sharpening, suspense, some minor political coloring, and in-movie explanations, but not for dumbing down. You can watch the movie for the emotional suspense, the critique against the greedy outbursts of capitalism and political involvement, but also for every single scene in itself.

In one scene, the risk managers (who are painted to think that the housing market is stable) are told to piss off. At that point, that feels so right (they are the messengers of the incarnation of naiveté of some bank departments; but it shows the dysfunctional risk management).

When, within the movie, it is said that the derivatives market is 20 times bigger than the market on the underlying assets. Craziness. But it also leads to the question, who are all those institutions are who trade in the derivatives of all those CDOs?

When a CDO “diversifies” risks, but the contained mortgages are all in the same suburban area, and most of them are for sale or empty, how diverse is it?

Are you part of the system if you work it?

The market is hungry for triple-A investments, especially conservative ones. Pension funds are explicitly mentioned. Why are pension funds so hungry for triple-A investements? Note that volatility and risk are intertwined, but depending on your time horizon they are not the same.

How much money do you need to play?

These small little issues paint a picture, and the movie takes its time to expose them.

Note to self: Learn how to write a review.

Jekyll, no Hugo

After writing pure html, I tested some bloxsom, started writing my own blog templating engine, abandoned that project for Jekyll, and recently learning about Hugo. While Jekyll served me well, its limited feature-set and Hugo’s promise for some relief made me attempt a switch.

Hugo advertises taxonomies, layouts and themes with partials, content with shortcodes, and better templates supporting some simple data-driven documents. Also, “install” with zero dependencies, and speed. While a first look revealed that I more or less had to port everything by hand, it seemed easy enough.

Then reality happened. It includes quirks of my specific site and mind, quirks of technology, and then a selection of concepts that lie between somewhat questionable and maybe wrong.

Sections provide separate feeds and section-indices. Manual action is required to removed those, and manual action is required to combine those across sections. I prefer my current, semi-curated way, with customized index pages (with custom content, not custom layout); fighting Hugo to not do it’s own indexes seems more effort than instructing Jekyll to create a default index page. But that’s probably my status-quo thinking speaking for itself.

A quirk of technology is Hugo’s datetime-handling. Hugo and Go are both underdocumented in that regard, and the interactions between Go’s type system and TOMLs datetime spec result in little surprises even for a programmer. The break from preexisting convention is sane, but results in subtle issues that I’d like to have had a reminder; the prime examples being that all datetimes must be specified either only as date (e.g. 2015-12-31) or down to the second. But whatever. Now I know to use 2016-01-03T15:12:31Z (see, seconds!). One time issue. Mission accomplished.

Another quirk of, uncharitably saying, the “Go mindset” is that many template functions are not designed for piping. Using pipes in templates (like "myvalue" | someFunction with 3 baseArgs | otherFunction) requires that the argument order for functions is specified such that the “work item” argument is the last one. Even stuff like Hugo’s string-replace does not work like that. When writing F# but using C# libraries such issues crop up all the time. Whatever. Just use one more pair of parentheses. Mission accomplished.

Slightly more questionable, though workable, is that a section also declares a default type. Every page you write in Hugo has a type, by default its type is of the same name as the section it resides in, mixing content hierarchy with article type. While I can see this working well for some use cases, it fails the orthogonality test. Hierarchy across several media types is an “off” case needing configuration, and the same layout across several sections requires either repeating partial includes or content type specifications; both trivial but commonplace papercuts. Of course, this just happens to run counter to how I organized my pages.

But whatever. This complicates layout search paths, and causes some repeated one-liners, But it’s a trade-off across use-cases, and my dislike is probably caused by my static-quo thinking repeating itself.

Finally, and this one hurt: There is no use of templates in content files. For me, templates are not just for layout. I intermingle content with some data to create data-driven content, and not data-driven layout. Even though the hugo-homepage declares otherwise, Hugo really only does the latter. Shortcodes are restriced in their environment access, and so for customized indices Hugo fails me, without a workaround.

The last issue was the literal deal-breaker. Most issues might just be artifacts of me using Hugo incorrectly, or could go away as I get familiar with Hugo. While I assume that I can fix this final problem with some more time, it would not be worthwhile for this little site (unlike for a larger project). For now, I hope that this is somebody else’s problem as well and they will fix it for fun, and then I can revisit Hugo with one hurdle less.

Hugo however reminded me of some potential for improving my layout templates. There might some refactoring be in the happening. Sadly, it also reminded me that the default pagination mechanisms are not perfect. (Also, Jekyll can do more than I remembered.)

Summary: I am very bone headed and like my site like it is, and because of that Hugo’s defaults make my life slightly difficult, and break some minor (but important to me) build results. So I decided to keep using Jekyll for the time being, even though Hugo is cool, and will be revisited.

Improving basic pagination

The still-unsolved-problem, pagination: Hugo, like Jekyll, comes with an underdesigned paginator w.r.t. blogs. It’s a first world problem, but a problem nevertheless.

Immutability Heaven

Reasonable blogs only add articles at the most recent end of the timeline, so all old pages remain the same, minus errata and force majeur. Consequently, pagination of blogs should keep almost all old pages the same. Starting pagination from the newest page, and keeping ten (or any other number of) items per page, causes each new article to modify all pages. It will not only renumber all pages (bad enough) but even change every single page ever generated.

A blog is not a search engine. Adding a chapter at the end of a book does not renumber previous chapters. Neither should your blog pagination.

There are some resonable ways to do this, and for static websites the low-effort low-tech solution is to use a scheme similar to /before-2015-11, containing ten (or any other number of) items, then continuing to /before-2015-03 or similar.

Every page is a permalink now! It helps you when you send out links. The advantage is that any existing link keeps working, even in your IRC or browser history. And it will directly help your followers using Twitter or Google+, your friends and aquaintances on Facebook and WhatsApp, your family like your grand-ma via E-Mail, especially if they don’t give a shit about tech. Links are not an easy concept! It even improves Google’s search results, because the time between content-update and accurate search-results for older pages is zero, and zero is lower than any positive number.

Paging, Browsing, Searching

How is it that searching blog or newspaper articles in a browser usually takes more time than you feel it’s supposed to, why does it feel heavy? How would you feel if you had to use a dictionary, but you must start at either the beginning or the end, and then always turn only a single page?

You would burn that thing and search on Wikipedia. Via Google.

Most blog paginations (here I mean the UI, what you as user see as clickable links in your browser) allow you no more. Some allow you to fast forward by paging through five pages at once.

I rarely see simple pages allowing for a bisect.

Page    Link          Sane
  1     Start         2010-01
 20     <<<           2012-03
 40     Fast-Back     2015-08
 49     Previous      2015-12-31
 50       Here        2016-01-03
 51     Next          2016-01-03
 60     Fast-Forward  2016-04
275     >>>           2025-11
500     End           2084-08

This allows paging, fast-forwarding, starting from the front or the back. And it even allows for highly efficient binary search, like you would do in a real-paper dictionary. Still not as cool as the feel of paper under your thumb, but much better then even the default scrolling behavior of all (all!) mobile browsers.

I agree such a navigation scheme can still be tremendously improved. But like Chess and Go, sometimes you play the best move that you can come up with on the clock, and then work from there.