Grokking Simplicity by Eric Normand teaches the difference between actions, calculations, and data as a way to reason about mutation and side effects, and it works better as a vocabulary book than a technique book. If you’ve already internalized what map, filter, and reduce are for, and I mean really internalized it and not just being able to write the syntax, most of the core material is going to read as confirmation of things you already believe instead of new information. The higher-order function chapters and the copy-on-write chapters fall right into that bucket. They’re clearly and patiently explained, and useful for someone who’s never had the difference between mutating and copying spelled out, but they’re slow going if you’ve been burned by shared mutable state enough times to already distrust it on instinct.

The best material is outside that core. The architecture chapters cover both stratified design and the onion model, and they were solid and worth having read, though not so revelatory that I’m in a hurry to go through them again. The concurrency chapters were the standout. They introduce a diagramming technique for reasoning about timelines and ordering that I hadn’t run into before and thought was really creative, and it’s a lot different from the usual “just use locks or actors and hope” approach most books take. Those are the chapters I’d go back to if a project involving concurrency comes up, since it’s the kind of technique you have to actually apply before it sticks.

The biggest miss for me was the immutable data chapters. I went in hoping for advice on using immutable data structures in single-binding languages, the discipline of writing code where a name, once bound, stays bound. What I got was mostly copy-on-write technique, demonstrated with JavaScript objects that get rebound on every update. That’s a reasonable way to teach it in a language like Elixir where rebinding is idiomatic, but it doesn’t really carry over to the habit I was actually after, which is reaching for val by default in Kotlin, or treating a Haskell declaration as a one-time mathematical definition instead of a variable that just happens not to change. The chapter shows you how to build the immutable structure, but it doesn’t really show you how to live in a codebase that treats bindings as permanent.

Overall, it’s a fast, well-explained, easy read that’s clearly aimed at someone running into these ideas for the first time. If that’s not you, you’ll skim more than you expect, but the concurrency material deserves a second look, and the architecture chapters were worth reading once, even if they weren’t essential.

The best part of the book was section 2, where it described different architecture styles and gave each one star ratings across a variety of characteristics, which I’m sure come from the authors’ experience with each style. I also liked how it framed microservices as part of a trend pendulum, reacting against the reuse pain that SOA left behind, since I like noticing when a new trend is really just correcting for the last one’s mistakes. I’m not an architect currently, so I have no need for architecture decision records (ADRs), except maybe for technical decisions made on personal projects so I can go back and remember the thought that went into them. I may start using adr-tools on my own for that. Since I mostly listened to this on runs, my notes don’t really do it justice. I want to go back sometime when I’m not out of breath and write proper summaries of the ratings for each architecture style.

Full book notes.

I first read The Pragmatic Programmer years ago, and the 20th anniversary edition holds up really well. It isn’t just a nostalgia lap, since the updates feel necessary, folding in ideas like ETC (“Easier to Change”), functional-style data pipelines, and more modern concurrency patterns without losing the voice that made the original a classic. It reads less like a list of rules and more like advice from people who have actually shipped things and learned from what went wrong.

I listened to it as an audiobook, and it worked better than I expected for a book this dense with concepts. The narration keeps a good pace, and the material is conversational enough that it doesn’t need diagrams on every page to land. If you’ve read the original, it’s worth a revisit, and if you haven’t, this is the version to start with.

Full book notes.

Advanced Functional Programming with Elixir turned out to be a pretty good, easy introduction to functional programming concepts, and it uses good domain examples instead of math. It walks through Elixir’s protocol system with a DDD slant, using a theme park domain with rides, patrons, and Fast Passes instead of the numbers-only examples you get in most Haskell books. The code is built around a companion library called FunPark, a teaching-scale version of Koski’s real production package, Funx. The theme park was a good choice, and it paid off most in the Eq/FastPass chapter, where a real business rule (two Fast Passes with the same datetime conflict, but should still be equal by id) motivated contramap far better than an abstract definition ever could have.

The quality was uneven, but in a predictable way. Eq, Ord, and Predicates were a low bar that the book cleared easily. Monoid was the standout chapter, and the one place where all the abstract machinery (Eq.All, comparators built with contramap) paid off concretely enough to justify the ceremony. The monad theory was thin and abstract on its own and only came together once Maybe and Either gave it somewhere to land. The one real gap was motivation for Reader and Effect, which never quite sold me. The mechanics were fine, but no example was compelling enough to answer “why bother wrapping this?”

The Eq and Ord chapters are straightforward once you accept that Elixir protocols dispatch on struct type only, which forces workarounds like contramap and to_eq_map (comparators as plain maps, not just protocol implementations) the moment your domain needs more than one valid notion of equality for a type. That ties into DDD nicely, since equality isn’t structural, it depends on the bounded context, so the same type can have different valid comparators depending on which part of the domain is asking.

The Predicates and Foldable chapter introduced Foldable for Function (a predicate as a fold, with zero-arity thunk dispatch) with almost no explanation, and I had to do some real reconstruction before it landed. It turned out to be a catamorphism (one function per fixed shape) hiding under a name that sounds like list reduction. I also caught a bug in the protocol declaration there. defprotocol declared fold_l(structure, transform_fn, base), but every real implementation and call site used (structure, acc, func), so the protocol’s own docs had the argument names reversed. It’s harmless, since protocol callback names aren’t enforced, but it’s misleading on a cold read.

Monoid was the best chapter. Sum is the toy case, and Eq.All and Eq.Any are the real payoff, equality combinators as monoids, with && and || doing the combining. I caught one real typo there too (default_not_eq vs. default_not_eq?), and it confirmed a design tension worth remembering: this machinery is worth it once you have multiple domain-meaningful comparators that need combining and reusing, but not for a one-off comparison you could write with && directly.

The monad theory chapter is careful to say it’s “inspired by category theory, not a direct implementation.” The laws (left identity, right identity, and associativity) landed fine once I reverse-engineered pure, which shows up without explanation, as the same idea as Monoid’s wrap/empty, just Monad-flavored. There’s no dedicated Functor chapter, and map gets treated as a free consequence of bind and pure instead of getting its own build-up, unlike From Objects to Functions, which used Functor as the on-ramp to Monad.

Reader was clean mechanically (the environment as a deferred function, ask/asks, and run as the escape hatch), but the worked examples were too small to justify the ceremony over just passing an argument. The one clear win was swapping run(computation, prod_env) for run(computation, test_env), which is a real dependency injection payoff, independent of the toy examples around it.

Maybe and Either are where the book actually sold itself. You chain bind-based computations and only check for failure once at the end, instead of doing constant nil checks, which is a direct answer to how much Go’s manual err != nil checking grates on me. Either wins over Maybe when you need to carry why something failed. Choosing bind to fail fast versus ap to collect all the errors was the most concrete moment in the whole book where an abstraction proved its worth, since the same operations give you two different validation strategies with one shared vocabulary.

Effect never made a compelling case for why actions specifically need to be trapped in a monad, though the ride repository example was believable as a real pattern. It was the weakest chapter at justifying its own existence.

I’m not convinced the full ceremony is worth it over Kotlin’s null safety for the Maybe case, since that comparison feels close to a wash. Either doesn’t have an equally clean stand-in in Kotlin, though. Kotlin’s Result<T> is tied to Throwable, so a hand-rolled Outcome type or Arrow’s Either are the real equivalents, and that’s the one idea from this book most likely to actually change how I write Kotlin.

Overall, it’s a good, easy introduction to FP for someone with some prior exposure who wants examples grounded in a domain instead of math. I’m glad I had AI on hand to work through the parts the book left underexplained, especially the Foldable predicate case, since it would’ve been a rougher read alone.

Full book notes.

I didn’t find a lot of the advice in this book terribly useful. It mostly seemed like common sense backed by a bit of research. The onboarding advice was probably the most useful part, if only because I’m senior enough now that it might come in handy with junior colleagues. The idea is basically to focus on single activities at first, starting with concrete code instead of diagrams, and remembering that everything is new to them. It is easy to forget once you’ve been steeped in a codebase for years.

The Roles of Variables Framework was new to me too. I actually paused my run to jot down the key ideas since it felt worth remembering, even though I wasn’t sure how valuable it would be in practice. Looking at my own code though, I mostly stick to “fixed value” variables over any of the other roles (vals in Kotlin, and I’m trying to do some Haskell on the side for fun). I also liked the advice on dealing with interruptions by offloading as much of your thought process as possible instead of trying to hold it all in your head. That’s basically what I use Obsidian for at home, and at work I’ve had the same notes.txt file open for ten years that’s probably 50 pages long by now.

Full book notes.

A perfectly good introduction to the Elixir language, although it didn’t have anything specific to learning functional programming in it beyond getting used to doing things the Elixir way. I guess it had more recursion than most introductory programming books… It feels like a terrible introduction in comparison to Dave Thomas’ Programming Elixir though, since it stops totally short of introducing the Actor model and OTP, which are unique strengths of Elixir, but that’s obviously a longer book to read.

Full book notes.

I picked up Build Websites with Hugo because I’m a PragProg loyalist with plans to revive my old blog, and if they have a book on something I’m using, I like to have an opinion on it. My opinion is that it’s fine, but barely. The book is from 2020, and Hugo has changed enough since then that half the examples either don’t work or generate deprecation warnings. I was running Hugo 0.164 against a book written for 0.68, and the scaffolding generated by hugo new theme is completely different now, so it actively conflicted with the book’s instructions at nearly every step.

Worse, the entire book has you building a custom theme from scratch, which is a reasonable way to teach, except that anyone graduating from this book is going to immediately throw that theme away for something maintained by people who actually know CSS, so you spend 200 pages building something disposable. What you do get out of it is an understanding of how Hugo thinks, with the template hierarchy, partials, taxonomies, front matter, and the asset pipeline, and that did turn out to be worth something, so just go in knowing you’re reading it for the concepts and not the site. Honestly, you’d probably learn as much in an afternoon of playing with Hugo directly and asking an AI assistant when you get stuck.

There wasn’t much else in it worth remembering, except maybe how to make a cool “This page will take X minutes to read” summary.

This was one of the better books I’ve read recently for actually changing how I think about programming. It combines domain-driven design, test-first development, and functional programming into one coherent story, which is pretty rare, since most books only tackle one of those at a time. Unlike some of my other recent reads, the Kotlin itself was well-structured and idiomatic throughout, not just functional-flavored Java.

The book builds a real app, a to-do list called Zettai, outside-in with TDD, starting from acceptance tests and working down to the domain core. It uses http4k, which the author picked specifically for its “everything is a function” philosophy (an HttpHandler is just (Request) -> Response), and Exposed for persistence. The book’s repo only has the start and end states for each step (step1 through step7, spread loosely across 13 chapters) rather than the intermediate changes, so I had to lean on the book’s prose to follow why the code evolved the way it did and not just what it ended up as.

The book starts with actor-based domain-driven testing and works its way through receiver-typed lambdas and extension functions, higher-order functions and purity, and a hub-and-spokes (ports and adapters) architecture before it gets into the theory. From there it covers monoids (with a door state machine example), functors, monads, and applicatives, then event sourcing and profunctors, and it finishes with a logging and JSON capstone that pulls everything together. The theory was mostly motivated with real code before the abstraction got a name, which I appreciated. Functors come out of Holder, List, and Outcome, and then ProjectionQuery deliberately breaks the container idea to push you into thinking of them as computations instead of containers. Monads come from a concrete TxReader<TxReader<T>> nesting problem instead of being introduced abstractly, and applicatives show up through error-accumulating validation with `!` and `*` operators, contrasted against the way monads short-circuit. The exceptions were the door monoid section and parts of chapter 7, where the vocabulary showed up before the payoff did. That was disorienting in the moment, even though the payoff did eventually arrive by the end of the chapter.

The Kotlin was the kind you’d want to see in a strong codebase, with extension functions, receiver types, sealed classes, and generics all used the way they’re meant to be used and not just as vehicles for FP theory. The actor-based test framework, Pesticide, was a neat pattern too, you write a test once and run it against the domain, a local HTTP server, or a deployed instance, even if I’m not sure I’d adopt the library itself over something mainstream like kotest.

The final third, especially the logging and JSON chapters, had a noticeably higher error rate than the rest of the book. Functions like storeEvents got used before they were shown, parameter counts didn’t match, and field names had typos. The JSON chapter has you build a hand-rolled JSON library that even the author admits he was “wary” of introducing, and it’s incomplete, since its own reflection-based code generation “seldom works right without manual intervention.” A thin adapter wrapping kotlinx.serialization in an Outcome probably would have served the book’s own goals better than building JSON parsing from scratch. There’s also an optional 50-page category theory appendix, which was a mixed bag. Functors, monads, and comonads mostly confirmed what the main text had already taught me, and Kleisli categories turned out to be bind with different notation once I decoded them, but profunctors and the Yoneda lemma were presented abstractly enough that I had to reconstruct them from the code examples myself before they landed.

Looking back at it now, after a stretch in Haskell, I remember a lot more about the DDD and TDD from this book than I do about the details of Kotlin. It was really into TDD, with the whole app built outside-in from acceptance tests, and I miss that now that I’m working through 1000 pages of Django 5 By Example without a single test in them. Anyway, it’s a dense book, but it was worth the length, and it changed how I think about combining DDD, testing, and FP instead of treating them as separate concerns. I’d recommend it to someone with some Kotlin under their belt and the patience for some rough editing toward the end.

Full book notes.

Better than initially assessed: Chapter 2 introduces collections, good variance coverage (with a Pet hierarchy), covers extensions and their role in the stdlib, two lambda/HOF chapters. Unusual ordering: generics before lambdas. map/filter/fold deferred to lambda chapters. Coroutines appendix exists but dated.

Head First Kotlin uses the usual Head First spiral approach - introduce a concept lightly, let it sit, circle back with depth later - which meant it deferred anything not strictly load-bearing to the appendices. Labeled breaks and enum classes, both things I’d consider core language features, got pushed all the way to Appendix C rather than covered in the main chapters. That appendix is even honest about it in the title: “The Top Ten Things (We Didn’t Cover)” - ten separate topics, including packages, visibility modifiers, sealed classes, and object declarations, that never made it into the twelve main chapters at all.

Compare that to Head First Go, which felt reasonably complete without needing to punt a top-ten list to the back of the book - but that’s not really a fair fight. Go is a deliberately small language by design (that’s Rob Pike’s whole philosophy. Minimal surface area, few ways to do anything), so a Head First treatment of it has a real shot at covering the whole language in the main chapters. Kotlin’s surface area is just bigger: null safety, data classes, sealed classes, extension functions, coroutines, object expressions/declarations, operator overloading. So a book aimed at teaching it from scratch in a similarly-sized page count is going to hit a wall and have to defer something. It’s less “Head First Kotlin did a worse job” and more “the two books picked structurally different-sized languages to cover with the same format.”

Full book notes.

Kotlin from Scratch is a project book, and the projects are mostly math and computation: Euclid’s algorithm, the Sieve of Eratosthenes, Fibonacci, physics simulations, fractals, sorting, and A* search. It was good typing practice, and some of the math and algorithms were really interesting, but it was disappointing as a source of good Kotlin code. The first two chapters covered the language fundamentals in almost as much depth as all of Head First Kotlin, but that depth never came back. Nothing after chapter 2 touches generics, sealed classes, delegation, or coroutines, extension functions never show up, and the language features stay limited. Chapter 3 was a whole detour into JavaFX that I didn’t ask for and won’t need for Android or Swift, though I don’t regret typing it, since the Stage and Scene boilerplate turned into a really cool spiral, and fighting the Gradle multi-module setup taught me more about the build system than the book itself did.

The author’s code quality was the real letdown. He leans on mutable vars constantly, and worse, on global mutable state. If anything, spotting all those vars helped remind me to use more vals. The genetic algorithm chapter had tournament() calls with no parameters that still returned different results every time, because they were secretly reaching into a global population plus some randomness, so there’s no referential transparency and no way to reason about a call site without reading the function body. The comments were often pure noise too, like // Run the genetic algorithm sitting right above runGA(). Project 16 was missing an entire function, which the errata later confirmed wasn’t my mistake, so I pulled that one from the GitHub companion repo instead of fighting a broken example.

The fold and map chapter was a letdown in a different way. It only reached for the classic textbook examples of summing a list, calculating a product, and concatenating strings, and nothing that shows off what the tools are actually for. I ended up chewing on a much better example on my own, finding all the subsets of a set (the power set). I worked that out mostly by instinct, keeping the subsets so far and, for each new element, adding a copy of every existing subset with that element in it, before I ever realized fold was the idiomatic way to express it. Even where the book does introduce a powerful construct, it plays it safe with examples that don’t show its range. One thing it did get right, which I wouldn’t have assumed coming from Java, is its package-naming advice to “join multiple words or use camelCase,” which checks out against the official Kotlin coding conventions, since they explicitly allow both.

I skipped typing the Modeling/Simulation and Fractals chapters, since they were more JavaFX and more of the same mutable-state pattern, and just skimmed them on GitHub instead. The sorting and searching chapter (chapter 7) had the cleanest code in the book, with fewer vars, and the ones it had were properly scoped instead of global. In-place sorting algorithms are supposed to mutate anyway, so that’s not really a knock.

The genetic algorithm (GA) chapter and the particle swarm optimization (PSO) and ant colony chapter were the highlight. I typed three GA variants by hand (a toy problem, a knapsack problem, and multivariate equation solving, by way of the “weasel program” Shakespeare quote demo), then took the GitHub shortcut for PSO and the traveling salesman ant simulation once I’d internalized the pattern. PSO actually beat the GA on the Eggholder problem, it took fewer generations, found a solution the GA never found in multiple runs, and didn’t get stuck in the same local optimum the GA kept falling into.

So it’s worth reading for the algorithms and the typing reps, but not for the Kotlin, and I wouldn’t recommend it as a “here’s good idiomatic Kotlin” reference.

Full book notes.

Sometimes it’s fun to read easy books, and this was an easy, fun book. It didn’t go into as much depth about Python as the Python Tutorial on the Python website, but it covered the basics, then went on a romping overview of using all sorts of libraries to perform tasks you might need to perform. Some of the tasks were pretty relevant, like loading an Excel file, working with JSON, or sending yourself an email; others were cool and could be put to creative uses, like driving a web browser with Playwright or working with a SQLite database; and some were kind of niche topics that I’d look back up if I ever needed to deal with them, like working with XML, OCR, or speech recognition. They were all kind of fun to play with, so I enjoyed reading this book.

Full book notes.

Some of it is more neutral than a selling point. I appreciate Go’s minimalism as a deliberate design choice even though it isn’t really my target use case. Google’s involvement makes me a little cautious. Binary size and startup time don’t matter much for what I build, and skipping a GC isn’t a selling point when I’m not doing systems programming.

I’m moving on from Go for now. Kotlin is more professionally applicable to me, and it works as a better Java without leaving the JVM. Real app development projects in Kotlin and Swift give me concrete motivation that Go doesn’t, and honestly my language list just needed trimming.

I might come back to it, though. Distributed Systems in Go looks like the most transparent way to see microservice patterns without Spring hiding the mechanics, and Learn Go with Tests looks good for picking up TDD patterns. The books will still be there, and Go isn’t going anywhere.

After trying ktlint in Kotlin, I’m even more impressed with how reliable and fast gofmt is. It’s a benefit of working with such a simple language. ktlint flags errors well but regularly gets stymied and unable to fix the file, so I have to either fix it manually or ignore the error. Formatting is more consistent in IntelliJ though, which is the main place I do Kotlin work. This is just something that bugs me when I type in book code in Vim, and Kotlin book code isn’t even formatted to ktlint’s specs either, whereas Go code everywhere looks pretty much the same. I still have to deal with Go’s odd capitalization rules for function names, but at least everything else looks reliably good.

This was a good way to see a number of non-trivial applications in Go. It tackled real projects like a Markdown Previewer and a Port Scanner and used production-grade libraries like Cobra for command-line arguments and Viper for configuration settings. The Markdown Previewer was probably good enough for me to consider using it. Honestly, Cobra and Viper were good enough libraries that it makes me start looking at what my options are for command-line parsing libraries early when studying a new language now. A lot of the examples were big to type, but that is good since it made me feel more comfortable with the language. They were also complicated enough that I made mistakes and got to deal with error messages from the compiler. I will say I was disappointed multiple times that Go’s compiler points out the first error it finds and then stops, so when you fix it you might just be greeted by another error. It’s not like Java or Kotlin where the compiler spits out 10 errors and 5 are probably caused by the earlier errors but the other 5 need to be corrected. The pomodoro app was actually quite usable after I got past the fact that it wouldn’t display correctly in tmux. That was a hard debugging session wondering what was wrong with my output from typing up the code before I finally pinned the blame on running it in a tmux session though, since having a tmux session is just getting so normal to me. Not only did I learn a lot about using Go for small to intermediate-sized projects, but I learned a lot about writing good command-line apps that I can take with me to other languages.

Full book notes.

Overall, it’s what I expect from a Head First book. It was a perfectly serviceable introduction to the Go programming language. Although it’s a Head First book, I feel like it treated me like an experienced programmer and didn’t waste a lot of time explaining how an if expression worked. Unlike Head First Kotlin which never got to a lot of things that it had to toss into Ten Brief Topics in the Appendix, it felt like it covered all the main topics that needed to be covered to understand Go. It even includes coverage of automated testing and a couple of chapters on web apps.

Full book notes.

Haskell

But let’s talk about the new title. It is “Senior Software Engineer Learns Functional Programming.” One of the last things I did but never blogged about was try to learn Haskell. I started with the venerable The Haskell Book. I read a bit over half and realized I still couldn’t program much of anything in Haskell. This was after spending previous effort learning functional programming. I learned some Scala and the syntax of Clojure and felt ineffectual with both aside from being able to use Scala as a better Java, so that’s what led me to Haskell to learn functional programming right. Well, I still want to do that. I didn’t think I wanted to really, but I spent some time reading Advanced Functional Programming with Elixir and it made a perfectly good case for why Haskell is a better programming language and featured a style that was not idiomatic Elixir but instead very Haskell inspired, and it got me interested again. So I’m not going to start over with The Haskell Book and try to re-learn programming from first principles. Instead I am going to read Haskell by Example which is more hands on and dip into the explanations of The Haskell Book whenever I need more theory. I’m also about halfway through Learn You a Haskell which I started over vacation, since I’m finding my intuition for working with linked lists has degraded.

Elixir

The subtitle of the blog is “With explorations in Haskell, Elixir, and Clojure”. I’ve already read two Elixir books on the basics of the language (reviews upcoming) and I have every intention of spending more time with Elixir. The books I read didn’t even touch on the cool Actor model and OTP stuff that makes Elixir unique. It’s not the best language for learning to deal with immutable values since it allows you to rebind variables, which feels a bit like cheating. Sure the data structure itself is immutable, but you just end up pointing the same variable at the updated copy. Haskell won’t let you get away with that. I understand since the variables aren’t global and are local to the Actors working behind the scenes it is safe even for concurrent code, but I intend to learn how to deal with immutable data structures bound once to a name. So I will definitely spend some time away with Haskell but eventually get back to Elixir. It overlaps my other goal of trying web frameworks thanks to Phoenix, so my two big projects (“Learn Functional Programming” and “Try Web Frameworks”) actually meet.

Clojure

I have also bought the most recent edition of Programming Clojure and Clojure Brain Teasers and plan to spend time with it again. I read Getting Clojure and Living Clojure and Clojure for the Brave and True years ago, and I felt pretty comfortable with the syntax of the languages and all the parentheses, but I never was able to use it for much. So after I spend some time writing code with Haskell, I’ll spend some time with Clojure again and see if I can do anything cool with it. I’m a Java developer by trade, so its position on the JVM feels quite welcome, and once I learn idiomatic functional coding in a language where I can’t back off and call Java code, maybe it will be accessible to me. I’ll probably spend a while with Haskell and then Elixir first though. I do want to play around with Ring to try writing my webapps with a minimalist Clojure library.

Web Frameworks

Back to the web frameworks though… I was going to dive into Agile Web Development with Rails 8 and try Ruby. Then I will read through Django 5 by Example. This builds up four sizable projects which I plan to steal. I don’t really like any dynamic language all that much, but I do normally prefer Python to Ruby for its usefulness with AI and its sensible stance on one way to do things and lack of going crazy with metaprogramming. I have every intention of stealing the Django projects to reimplement in other frameworks to serve my own curiosity. First in Rails, then move on to the next stop. So then I can read Programming Elixir and Programming Phoenix Liveview to try doing a web framework. How do I plan to make time for all this? Well, I think I can wrestle with Haskell for at most 30-60 minutes a day, so my time beyond that can be spent toying with web frameworks which requires less cognitive load. After Phoenix, there’s other options. I can try writing a typed API in Haskell with Servant or do something with Yesod. I also wouldn’t mind reading Distributed Services in Go and trying the same projects as microservices. I happen to like Go for being so simple that you can’t hide anything behind the language. I’ve recently read two books on it (reviews forthcoming) and feel pretty comfortable with it. Aside from that, I wouldn’t mind trying an Angular frontend with a backend in another language, since we actively use Angular in the new project at work. And I’m not opposed to trying React to just see the difference. Obviously, all JavaScript Single-Page Applications are more the rage now than old school web frameworks like Rails, and it fits my interests of seeing different ways to do things. I also have been toying around with Kotlin and would love an excuse to go back, so I would like to try Spring with Kotlin for the big enterprise way of doing a web framework along with Ktor for a lighter weight framework in the same language. I could code Spring in Java, but I do like not coding in Java when I’m away from work and find Kotlin a fun alternative. Spring and Angular are probably the most professionally relevant interests that I’ll be pursuing, but it’s obvious that I’m not trying to maximize for utility. I do really think it very clever that the new project at work is leaning into a modern Angular UI with a Java backend instead of using any of the trainwreck front end projects available on the Java platform. JSF was bad enough to make me never want to see a Java frontend again. Anyway, that’s as far as I’ve thought these two projects through, but if I make it that far with them, I’ll have a better idea of what I want to do next. Put together, they should keep me busy for a while, and assuming I don’t give up blogging for ten years or so again, it will give me something to blog about.

Why Now?

Why do I think blogging will catch on this time? Well, what made me give up my side projects and blogging before was primarily being burnt out on spending all day coding at work to get off and do more of it at night. Now that my kid is older and I’ve got more time to focus on personal development, I figured why not fire the blog back up so I can shout my book reviews and whatnot into the void. Aside from that, work has us leaning a lot more on AI for writing code these days, so it’s as good an excuse as any to keep my own skills sharp with some side projects. I’ve also been rather good lately at putting my mind to stuff and keeping it going. I lost about 40 pounds and run 10K every day I don’t lift weights. So maybe I can stay focused on something intellectual too. Also, I still run over an hour most days a week, which gives me a great opportunity to listen to a history audiobook or fictional work, so it isn’t like I’m giving up my hobby reading. I’m just cutting into other spare time with a new project. As a busy dad, I really get 1-2 hours of free time that I’m not working out most days, so it’s easy to spend 30-60 minutes on Haskell and the remainder if there is any on something else. Or so I think. We’ll see if this blog rebirth lasts. So far, I’ve read about 8 technical books that I’ll end up posting reviews for, so I already have more content than I had last time before discontinuing it, and it seems something fun to do. I’ve already been reading a minimum of 30 minutes a day for over a year, and often for hours, so I’m just going to read different stuff.

I didn’t put this in the first draft, because it feels kinda silly to get inspired by a book about a famous person, but there’s also another thing that motivated me to do more programming on the side. I listened to the audiobook on Steve Jobs while I was running. Really, I don’t care that much about Steve Jobs and still don’t after listening to his life story. He definitely had vision and did good things with Apple, and I’m writing this on a Mac so can’t complain about the results, but I consider him more of a visionary businessman than a real hacker. I liked Isaacson’s biography of Benjamin Franklin and figured Steve Jobs would be another accessible work by him for my runs. But you can’t read about the founding of Apple without encountering Woz. A true engineer that would’ve gladly made computers and gave them away, because he loved tinkering with circuitboards. I don’t really care about circuitboards either; I’ve always been a software guy. But being exposed to a story with that type of passion reminded me I used to be passionate about computers.

I’ve always had a bit of a love-hate relationship with Apple. I still have Linux on my desktop PC and am a proud member of the Columbia Linux User’s Group despite not attending meetings all that often. The early Apple computers were toys with no CLI and one button mice because multiple buttons are confusing. But after OS X was reborn with BSD under the hood and a full fledged terminal, I found that having a computer that mostly worked with the default configuration and actually looked pretty good made it easier for me to focus on writing code and not spend so much time tinkering around with Linux. I learned from the Steve Jobs book that the first Macs were expandable because Woz thought people should be able to tinker with their own computers. Maybe I would’ve liked those better than the Macs at school.

Anyway, back to passion, I didn’t take my computer apart and hide all the pieces because I thought it would be faster when I put it back together hours later. I did it because I wanted to learn how a computer was put together (I didn’t know I wasn’t really a hardware guy back then; I honestly prefer buying them off the shelf now). I also didn’t learn C and relational databases because I thought they would be profitable (although database knowledge is the gift that keeps on giving). I loved solving problems in C in the middle of the night on my hand-me-down computer. I didn’t found an ISP in the 90’s to get rich quick, I founded it to have fast Internet access and to have cool problems to figure out. Likewise, I didn’t make straight A’s in school because I expected it to help my job prospects. No one cares about my GPA. I loved the material! It was fascinating to learn about algorithms, operating systems, and, after programming so long, compilers. Somewhere along the way, it just became work like any other job. So it’s a combination of factors: having more free time now that my kid’s a little older, work leaning harder on AI for the actual code these days so I want to keep my own chops sharp on the side, a refound passion for programming inspired by a rather unlikely source, and the fact I’ve been reading every day over a year anyway, so why not make it technical. I still don’t know functional programming beyond how to apply a good map and filter, and I still haven’t tried a lot of different web frameworks. They’re all likely to be better than the Java EE/Spring hybrid monstrosity that I work on most of the time. Almost anything beats JSF.

And as an aside, this will probably be my last time trying to learn “functional programming”. If I try to learn the secrets of Haskell again and bounce off, I am just going to adopt Go as my programming language of choice and write lots of simple procedural code with structs and err checks every other line. As an old school C hacker and Perl scripter before they bolted on OOP, it feels quite natural to write straightforward procedural code, but I’m trying to work outside my comfort zone even if I think the benefits of functional programming might be overpromised.

But I really kinda understood the point of functional programming with Advanced Functional Programming with Elixir, and all those err checks in Go grated at my nerves, so the beauty of being able to chain a bunch of calls together then deal with errors or results at the end was quite appealing to me. Monads aren’t really the Elixir way though. Your average Elixir programmer would do some simple pattern matching to catch :err and deal with it instead, but Advanced Functional Programming with Elixir featured a Haskell inspired functional programming library and monads. And while I wasn’t ultimately convinced of the utility of the Reader or Effect monads (I’m open to learning more about those in Haskell, and I will have to anyway if I spend time with it), I really liked Maybe and liked Either even more. Even Java has Option, but Either is a lot more useful. Plus parallel validations with Applicative were kinda cool. They weren’t a reason to re-learn programming, but I’ll take them along with my Either and roll with it a bit.

Conclusion

So that’s it. The blog is reborn. I’ve got one project that meshes with the title of learning functional programming. I have another of trying web frameworks that has some limited overlap built in and picks up where the blog left off. I transferred my old posts over and rebuilt the site in Hugo and moved over what I could from the old Jekyll files. And I’ve written a very long coming back post plus already have a stash of book reviews in my Obsidian. So I guess I’m back and doing this for now and we’ll see where it goes. I may get tired of posting updates here and just read the books, but I like having somewhere to collect my thoughts and review what I read.

So, these videos are going to focus on the core Spring Framework. So we won’t be getting back into Spring Data or even Spring MVC in this video series. It says that it will talk a little about Spring Boot, since that’s the general way to get projects started these days. “One thing that you’ll notice about the Spring Framework, is that they never met a class or package name too long.” Tell me about it. Spring makes you appreciate autocomplete. He uses gradle to manage projects, which is fine. Maven or gradle are both fine options.

He did a fine demonstration of basic injection in XML, annotations, and Java config setup and quick intro to aspect oriented programming that included an example of the @Around advice. Then he gave a quick introduction to Spring testing. Finally someone that doesn’t ignore testing. It turns out you can annotate you test class with @RunWith(SpringJUnit4ClassRunner) to have Spring aware tests, and you can add the @ContextConfiguration(classes = AppConfig.class so that you have a cached ApplicationContext shared between tests in the class and the ability to @Autowire any of your beans. You can even @Autowire an ApplicationContext ctx variable to inject a reference to your ApplicationContext to use in tests to fetch beans you don’t autowire. The fact that @ContextConfiguration takes a classes argument lets you have a different configuration class for tests than the running application if necessary. You can also add the @Transactional annotation to your test class to make all your tests occur in a transaction that gets rolled back after test completion. His toy app that he used to demonstrate early principles didn’t have any database interaction to show-off transactional tests, but this is the part of the course that he switches from a toy app to something a little more complicated. He also mentions that the Spring pet-clinic demo app makes good use of transactional tests.

The new application has a Service and a Repository interface. Instead of using Spring Data, he does all the database operations with an in-memory and a JDBC implementation. Everything is marked @Transactional at the Service level. He had to make a “transactionManager” Bean and use an @EnableTransactionManagement on his Configuration class, neither of which I recall being required when doing a Spring Boot app with @Transactional. The JDBC is using the Spring JDBC Template and is a lot cleaner than straight JDBC. The JDBC Template does a lot of work for you. For example, the following one-liner works for getting a count: int rowCount = this.jdbcTemplate.queryForObject("select count(*) from t_actor"), Integer.class); I like the way he looks up what he is talking about in the online API, the same way you likely would when programming with the various API elements. He shows off using “test” and “prod” profiles to differentiate between an H2 in-memory database and an Apache data connection pool backed by MySQL. Each repository method with the JDBC Template ends up being two to four lines long, depending upon what he’s try to do. Pretty simple, but not as simple as not defining implementation methods with Spring Data JPA.

Yay! More testing. This time we’re testing repositories. Just set the annotations on the test class and annotate the test profile, then autowire the repository and you’re good to go. Each test is transactional, so they roll back changes at the end of each test. He uses Hamcrest matchers, so he can make assertions like assertThat(accounts.size(), is(3));, which flows a bit better than standard assertEquals. He points out that since he is using gradle he can show the really cool gradle test report. The tests he ran were all quick, even with firing up and setting up the in-memory database. First one took half a second, but the all six of them took less than a second total. He succeeded in exercising all his repository methods and making sure they worked as expected.

I was wrong that we weren’t going into Spring Data. He reimplements his repository using Spring Data JPA for the next project. Spring Data JPA repositories are just interfaces. You get queries generated for free based upon how you name the methods in the interfaces. You can also use the @Query annotation above a method in the interface to give it a custom query if the autogenerated language can’t handle what you’re after. He defined the JpaVendorAdapter and LocalContainerEntityManagerFactoryBean manually in the Java Spring configuration file, which normally weren’t require with Spring Boot. It’s interesting to see how this is all done by hand, and it isn’t that much in total lines of configuration. He didn’t use the feature of Spring Data JPA to allow repository autogeneration of methods and just defining an interface. Instead he defined a JpaAccountRepository that implemented its various methods directly through an EntityManager. He does use @PersistenceContext annotation to inject his EntityManager. Most of the methods now are one or two lines long. He did have to add JPA annotations to his entity class, but most of them defaulted through good name selection for class and fields. Only @Entity on the class and @Id on the primary key field actually needed to be added to the domain object. He shows that you can use the same service with the JPA repository as was used with the JDBC Template repository, since he designed the methods to take the same arguments. He uses the same tests also, which makes sense as the interface and expected outputs are the same.

I forgot to mention it earlier, but this presenter uses IntelliJ for everything. Always nice to see! Oh, he was just using JPA in the last project. The next project is where he’s adding in Spring Data to get the free implementations of DAO methods. So, it turns out he uses Spring Data for the last 12 minute segment of the presentation, and then switches to showing the same app with Spring Boot for the last 15 minutes of the presentation. The app keeps getting simpler each time he introduces more Spring features. He actually extended JpaRepository for his repository, where I am more accustomed to seeing CrudRepository or PagingAndSortingRepository extended. JpaRepository extends both. He had to change the method names in his service and tests to match the ones freely given by having an interface extend on of the Spring Data interfaces, but got to delete a lot of code that was the repository class implementation and previous repository interface which was more complicated. Interesting to see that his tests run quicker now too, taking a little under 0.4 seconds. He’s still using an H2 in-memory database for testing and setting it up with the same sql scripts. He points out that all his earlier work really was unnecessary. The final project is to show how much of his configuration he can get rid of also by using Spring Boot. It’s still interesting to know how to do it by hand, since everything we’ve seen is still happening under the hood in Spring Boot.

So, at the end, he claims that a Spring Boot focused course is coming. I don’t see it as available yet. He had mentioned earlier this video course would be the start of a series. I really enjoyed Ken’s presentation, and would definitely watch more in this series by him. It was a neat change seeing Spring used for non-web apps. I hope in the future videos he shows off Spring MVC though, because Spring makes some nice web apps too. He recommends the book Spring Boot in Action at the end, but I found that book fairly worthless. The source code for it didn’t match up with what was described in the text. Maybe now that I actually have a grasp on some of this stuff, it would be useful and I could figure out why the sample source code and the text don’t match up. Anyway, despite his poor book recommendation at the end, I really enjoyed this video series. It’s worth a watch if you’re looking for something to view with your Safari Books Online membership.

This course moved a lot quicker than the last course I took from Udemy. It covered basic dependency injection in Spring in probably an hour or less, where the last class focused on dependency injection fundamentals for the entire time. I appreciated the faster pace, as there’s a lot of stuff to cover with Spring Boot. It handles autoconfiguring all the main projects that make up Spring… Spring MVC, Spring Rest, Spring Data, Spring Security, etc.

This author made it really hard to code along with him. He did things like restart a project with unknown initializr settings in between videos. He also copied and pasted a lot of code, so you couldn’t really type along with him. As long as you don’t mind pausing and typing something in, it wasn’t unworkable, but it got a little old. I ended up checking out his repo of code samples and following along with them. He does have exercises at the end of each section, which are a good chance to code some stuff up on your own. He doesn’t mention specifically when he changes projects from the repo either, so it’s a little hit and miss making sure you’re looking at the right code that he’s working on.

One nice thing is this guy used IntelliJ instead of Eclipse. He admitted that you need the paid for version to work with Spring, but just told people to sign up for the 30 day trial. Fortunately, I still have my student license, so I had all the features to play along. It might be annoying to people that have already done the IntelliJ trial, since it makes it harder to follow along. Of course, he’s pretty hard to follow along with as it is, so using STS or Eclipse wouldn’t be that much worse. Anyway, I was excited at first that he used IntelliJ, but then he switched to Eclipse STS halfway through the videos. I kept following along in IntelliJ.

I liked the Spring Boot way of doing apps. It felt like convention over configuration brought to the Java world, the way it autoconfigures so much stuff based upon what it finds loaded in your class path. I really liked Spring Data, which allows you to pair up standard JPA entities with Repository interfaces that automatically generate the implementation with queries based upon the names of the method defined in your interface.
For example, if you make a method called findByLastName(String lastName) in your interface, you get the query you would expect for free. The instructor didn’t go into this, but it also works with QueryDSL predicates to fill in the queries, which is pretty cool since I use QueryDSL at work. He also showed how to do everything by hand with JDBC, but I liked the JPA approach better. He also showed that you can drop in mongo DB and swap out Entity annotation for Document pretty easily in an app with very little changes. It was a weird choice doing JPA backed by a Microsoft SQL Server database, and since I didn’t feel like signing up for an Azure trial, I just kept using H2.

I really liked the Dev Tools with live reload. He showed that you have to change a few settings in IntelliJ. In the registry you check compiler.automake.allow.when.app.running and in the Preferences->Build, Execution, Deployment->Compiler you check the Build project automatically. Then you install a browser extension from http://livereload.com/extensions/ and it will reload automatically when anything changes in your code. It isn’t that much work really to save hitting refresh all the time. He doesn’t use that in most of his projects, but I kept it turned on in all the ones I did by hand.

I like Spring Security, but found the course’s presentation of it to be a little light. It does explain how you get free security headers, some XSS prevention, and CSRF tokens just by including Spring Security, and in his example he works up to a custom login form backed by a database (this time MySQL) of users, but he stores the passwords in plain text, so his app wouldn’t be that useful a model to look at if I ever wanted to do this for real.

The REST presentation was more thorough than it needed to be. It seems like every talk about REST has to go over what the different status codes mean first thing. Why not just link out to HTTP Status Cats website. I want to know how he gets his JSON formatted so pretty in the browser. I’m sure it’s a plugin, but it isn’t one I already have. Oh, he finally mentioned what it is during the REST videos. “JSON Viewer” extension for Chrome. Nice. Anyway, I thought REST frameworks were easy to setup when we were doing them the hard way (RestController annotations and services), but it turns out you can get rid of your controllers and services and directly expose your repo through a default build REST API if you don’t need a lot of custom logic. There’s even a built in HAL Browser for discovery and interaction with the API, if you choose to include it. HAL Browser dependency comes from org.springframework.data and not org.springframework.boot. That tripped me up for a minute in the exercises.

For the final series of lectures, he expects you to work along with him starting from an initial setup. We’ll see if this works any better… Nope! He still does a lot of stuff off-screen between videos. Anyway, the final project is a blogging website. It uses bootstrap to look good, thymeleaf for the templates, spring data jpa for the database interaction, and spring security to enforce editing only by those with admin level privileges. I still need to read the docs on thymeleaf templates to feel like I know much about them, since he always provides the templates and doesn’t explain much. They look pretty simple. Extra attributes to HTML tags causes you to override content that is present in the source and do other modifications. Like <span sec:authentication="name">Guest</span> will default to Guest, but will override that value with the name of whoever is currently authenticated. Judging from the upcoming titles, he’s going to throw in some validation, which is a topic he hasn’t covered in the previous sections.

I couldn’t get his instructions for customizing validation messages to work at all. I got validation working pretty good with the default error messages at least. He claims you just need to put your custom messages in a messages.properties file, but I did that and they didn’t get picked up. I assume I have to do something to get it to look in message.properties. Everyone on stack overflow with a related problem seems to be running WARs, so those questions don’t seem to apply to my setup. I’ll dig in the documentation later and see what’s going on.

Chapter 3 - The Architecture of Rails Applications

Chapter 3 jumps into explaining MVC. It’s a pretty simple concept. MVC stands for Model, View, and Controller. The model is responsible for the state of the application, often the data you store in a database. It’s also more than data; it enforces the business rules that apply to your data. The model is both a gatekeeper and a data store. The view is responsible for generating some type of user interface. The view’s job is done once the data is displayed. Multiple possible views of the same data are a common case. The controller orchestrates the application. Controllers receive events from the outside world, interact with the model, and display the appropriate view. The book provides a simple diagram:

There’s a fine introductory article on Wikipedia if the concept is new to you. One of the main advantages is that each concept or action can be expressed in a single, well-known place. Like many modern web frameworks, Rails is designed with MVC in mind. Rails first sends your request to a router, which then maps it to a method of a controller (called an action), and then the action looks at data in the request to decide how to interact with the model and ultimately it prepares information for the view, which renders the result.

The request contains a path (/line_items?product_id=2) and a method (GET, POST, PUT, PATCH, DELETE). By default rails takes the first part of the path, line_items, as the controller name and the product_id as the ID of a product, which it passes to the create() method of a LineItemsController if we assume this is a POST request. Different types of request are routed to different methods of the controller.

Rails handles a lot of the low level details of an MVC app, so you can focus on the core application logic. One example of this is in its ORM (object- relational mapping) libraries which map database tables to classes. If you have a class called Order, you know it maps to a database table called orders. The Order object has methods to set all the data fields in the orders table. The Rails classes also wrap our database tables with class-level methods that perform table-level operations. For example, you might want to look up an Order by ID. Code to do so might look like:

order = Order.find(1)
puts "Customer #{order.customer_id}, amount=$#{order.amount}"

Or you could have a class level method that searches by a where clause and returns a collection of objects:

Order.where(name: 'dave').each do |order|
  puts order.amount
end

In addition to accessing field values, you can set values via the object and then save it to the database:

Order.where(name: 'dave').each do |order|
  order.pay_type = "Purchase order"
  order.save
end

So an ORM layer maps tables to classes, rows to objects, and columns to attributes of those objects. Class methods are used to perform table-level operations, and instance methods perform operations on individual rows. Active Record is the ORM layer provided by Rails. It relies on convention over configuration and starts with sensible defaults to minimize manual configuration by developers.

Action Pack is the part of Rails that supports the views and controllers. At its simplest, the view is a chunk of HTML code that displays some static content, but you normally want dynamic content generated by templates. Rails offers templates in three flavors:

1. Embedded Ruby (ERB), which is the most common, embeds snippets of Ruby within an HTML document
2. ERB used to construct JavaScript fragments on the server to execute in the browser to form the view
3. an XML builder to construct XML documents using Ruby code.

The controller acts as the logical center of an application, coordinating interaction among the user, the views, and the model. It’s responsible for routing URLs to actions, it manages caching, it manages helper modules, and it also manages sessions. The way Rails handles most of the interaction behind-the scenes makes controller code easy to develop and maintain.

Chapter 4 - Introduction to Ruby

All of Chapter 4 is focused on a quick review of Ruby. I’d recommend a refresher at learnxiyminutes if your Ruby is a little rusty or checkout the zenspider quickref.
The one thing those don’t cover that is relevant is YAML (YAML Ain’t Markup Language). YAML is used to define configuration of things in Rails.

development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

Indentation is import in YAML, and the above snippet defines four key-value pairs.

Chapter 5 - The Depot Application

Chapter 5 focuses on the design of the application that is being built in the upcoming tutorial chapters. We’re going to build a basic bookstore, based upon the Pragmatic Bookshelf website. It approaches the problem from a mindset of incremental development and starts out from basic back-of-the-napkin style sketches of functionality. It points out that Ruby on Rails shines for this style of development, because it doesn’t heavily penalize changing your mind about something mid-development. It also points out that we’ll be building tests as we go. Yay!

To start with, we want an outline of how the application will work at a high level. We identify two roles: the buyer and the seller. The buyer browses for products, selects some to purchase, and creates an order. The seller uses the application to maintain a list of products to sell, to determine order awaiting shipment, and to mark orders shipped. Here is a first sketch of the buyer flow:

It’s a pretty traditional and simple flow. There’s also the seller flow:

In both cases, we’re not overspecifying things we are unsure about, like details of the shipping method or payment methods. We also need to think about what the data is going to look like:

There’s obviously some questions left, like what goes in cart, but this is enough to get started, and we can figure out the other details once we’re in a better position of knowledge later after we’ve started. With these diagrams in hand to get us started and an imaginary customer to show our progress, we’re ready to get started on the book’s tutorial application.

I’ve read several things since finishing Agile Web Development with Rails 5.1. One I might dedicate multiple blogposts to: “Practical Object-Oriented Design in Ruby”. It was really good, and I highlighted large sections of the book that are worth talking about. Some of the stuff I had seen before in places like “Clean Code” and in my Software Engineering class, but it had a lot of good direct advice on designing things properly from an object-oriented perspective. The examples were in Ruby, but it didn’t linger much on language specifics.

Speaking of Ruby, I’ve been refreshing my Ruby skills after spending time with the Agile Web Development in Rails 5.1 book and before delving into some other Rails books (primarily Hartl’s “Ruby on Rails Tutorial: Learn Web Development with Rails” which I read in an old version and the new rough cut of “The Rails 5 Way” ). I re-read the 10th anniversary edition of the Pickaxe , since I had a hardcopy of it on the shelf. That link takes you to the fourth edition, rather than the 10th anniversary edition. It was focused on Ruby 1.9. Then I re-read Why’s (Poignant) Guide to Ruby. It’s a little dated, but still relevant. And finally for something a little more up to date, I started reading the latest edition of “The Ruby Way”.

I like the Pickaxe best for a fast moving introduction to the language that is worth a couple of reads, paired with detailed chapters on various topics relating to Ruby in its setting. Why’s guide is classic, and gets into some neat metaprogramming topics, although it has a lot of charmingly weird stuff in it and not so much code. “The Ruby Way” is starting to feel like a bit of a slog to make it through reading from cover to cover. It feels like it would be a handy desk reference, but from a reader’s perspective, do I really want to read how to build a GUI using five different libraries back-to-back. It was good for establishing a comparison of several different ways to do GUI stuff at least. I think I’ll try out Shoes. Anyway, so now I feel like I know Ruby again, and I’ve been using it for Code Wars to get lots of practice with toy problems.

Oh, I’ve also signed up for a MOOC that teaches Software Engineering concepts with Rails. Agile Development Using Ruby on Rails - Basics. I signed up for the matching advanced course too. So, if you want more Rails material, I have some coming up to write about at least. I’ll write my opinion of the MOOC after I get a chance to watch through the videos and try the exercises. Between the MOOC and the other Rails books I have on my reading list, I should get a couple of nice blogposts that have some code blocks in them. Now that I have syntax highlighting working, might as well use it. There’s also an Infinite Skills video that I have access to through Safari Books Online that I wouldn’t mind trying out. Hands-on with React and Ruby on Rails. I don’t have much React experience past doing the Tic-Tac Toe tutorial, but I can probably manage it as the video doesn’t claim you need React experience. Anyway, I’ll get back to reading and watching and coding stuff now, and come back with some blogposts that include code soon.

So, I fixed my mistake from last time. I had originally installed ruby via homebrew, but now that I’ve read up on rbenv, it seems a lot nicer than the old rvm, and I might want multiple versions of Ruby on my home PC. So I uninstalled Ruby 2.4 and went with brew install rbenv and then used it to install the latest Ruby. I see why the book authors prefer it over RVM now. It’s a lot less invasive than the old RVM.

Anyway, on with Chapter 2, “Instant Gratification”. I went ahead and completed the code for this chapter and the exercises. Both were fairly trivial. I checked it in at demo51. If you clone that and run bin/rails server from the directory, you’re greeted by the site at http://localhost:3000/. You get a lot for very little with Rails. The site you get just from running rails new demo51 looks like this:

It also looks like the default server has changed from WEBrick to Puma now. But a page with a picture isn’t all that impressive. I must say that I find it pleasant how fast the server starts. I’ve become used to my Java EE servers with multiple minute startup times before you can see changes, but not only does this server start fast, it loads changes on the fly when in development mode, so you seldom have to restart it. What is also impressive is how easy it is to modify with a new route. What is slightly intimidating is that the rails new command actually generated forty-six files spread across thirty-four directories. The nice thing is that everything is in its proper place, and hopefully by reading this book and working with the applications a bit more we’ll come to understand the logic behind it.

The whole application in this chapter is a Hello World modified with a timestamp to show something dynamic. To do this, we need to generate a new controller. Going to the directory of our app and running bin/rails generate controller Say hello goodbye will generate a controller named Say with methods (in Rails terms, these controller methods are called actions) hello and goodbye that will respond to requests to /say/hello and /say/goodbye. It puts the say controller in demo51/app/controllers/say_controller.rb. This is the controller that contains methods for all the /say/ routes. Its starting code that was generated is simply:

class SayController < ApplicationController
  def hello
  end

  def goodbye
  end
end

Those methods obviously don’t do much. Because it inherits from ApplicationController, our SayController automatically gets all the default controller behavior. Even though the controller methods don’t have any logic, they still return a site when you navigate to the URL, because by convention they are associated with certain views.

The route informs of the file it is currently serving app/views/say/hello.html.erb, which was also automatically generated when we created our controller with the command above. If we edit the file it points us to, we find what looks like a normal html file body:

<h1>Say#hello</h1>
<p>Find me in app/views/say/hello.html.erb</p>

This is the view that was generated by our command. The views for the SayController we created by default are placed in the app/views/say directory, and there is a view for each of the hello and goodbye methods. The book has us change this view to instead say:

<h1>Hello from Rails!</h1>

If we refresh our browser window (without restarting the server), we see the new output:

So far, we’ve learned the place two things go. Controllers go in app/controllers and views go in app/views. The book shows it with the diagram:

The book goes on to add the time display to the page directly, then refactor it to have the time generated by the controller and displayed in the view. We’ll just skip to that. We modify say_controller.rb to generate the time:

class SayController < ApplicationController
  def hello
    @time = Time.now
  end

  def goodbye
  end
end

and modify the view to display the variable set for it by the controller:

<h1>Hello from Rails!</h1>
<p>
  It is now <%= @time %>
</p>

The time is data, so it is supplied to the view by the controller. The book forewarns us we’ll see a lot more of this once we introduce models. It goes on to explain the step-by-step process of what the server goes through when responding to a request, at a very high level. We then customize our goodbye page, but you can checkout the git repo if you want to see that or the results of completing either of the chapter’s two exercises. The one remaining item of interest it does in the app is add a link from the Hello page to the Goodbye page and vice versa. It does this using built in helper methods rather than hardcoding URL’s. The new hello.html.erb looks like:

<h1>Hello from Rails!</h1>
<p>
  It is now <%= @time %>
</p>
<p>
  Time to say
  <%= link_to "Goodbye", say_goodbye_path %>!
</p>

The first parameter in the call to link_to() is the text to be displayed in the hyperlink, and the next parameter tells Rails to generate the link to the goodbye action of the say controller.

Finally in this chapter, they display what happens when things break. As the authors put it “the true test of the developer friendliness of a framework is how it responds when things go wrong.” First, they ask what would happen if we misspelled Time.now as Time.know in our controller. Rails not only tells you the exact spot of the error, it also asks if you meant to type “now” and offers an interactive debugging console:

And before you start worrying, the web console is only shown if you’re on the same machine as the web server and running in development mode, so there shouldn’t be any chance of anyone getting into it in production unless you specifically whitelist more ips and run the server in development mode. Likewise, if you attempt to go to http://localhost:3000/say/h3llo instead of /say/hello, you get:

It gives you a list of possible routes along with what controller and action they are associated with and a helpful search box to trim it down.

Altogether, the app presented here is totally trivial, but in this chapter they did manage to cover:

• How to create a new Rails application and how to create a new controller in that application
• How to create dynamic content in the controller and display it via the view
• How to link pages together
• How to debug problems in code or the URL

Looks like the next chapter covers a bit of MVC theory, and chapter 4 is a Rails review. I’ll probably comment on both in one quick post. Then in Chapter 5, we dig into building a bigger application.

The obvious question is why rails when I could play with the hot new Javascript framework. Well, I’ve played with React some, along with Ember, and Angular. I might go back to messing with them and blog about the results later. Right now, I’m just in a Ruby/Rails mood. I’ve always liked how the Ruby community seems to emphasize good programming practices that carry over to any language you work in, and I recall the Agile Web Development book being a good source of sound programming advice. As a side note, I understand that the book now includes information on doing a Javascript front-end with a Rails backend, so I’ll get in some Javascript before I’m through.

The introduction is well paced. The parts I feel worth mentioning are its argument that “Rails Simply Feels Right”, which I am inclined to agree with. I’ve always thought of Rails as the cadillac of web frameworks. There’s a lot of ways to do the same old CRUD in other frameworks, it’s just rails has polish and a certain thoughtfulness of layout that makes it all click. It achieves a level of conciseness thanks to “Convention over configuration”, adhering to the philosophy of DRY (Don’t Repeat Yourself), and the natural conciseness of the Ruby programming language (a trait that I miss a lot now in my job, where my Java code tends to include a lot of boiler plate by necessity).

The introduction shares a link to the guiding philosophy of Rails, the Rails Doctrine. It can be argued that the Rails Doctrine is what makes Rails continue to be a strong choice as a web framework, even though it’s no longer the new darling on the block, and as an aside is also one of the reasons I favor Ember of the Javascript frameworks, since the Ember community were obviously heavily influenced by the Ruby/Rails community. The number one item on the Rails Doctrine is “Optimize for programmer happiness”. This is lifted straight from Ruby, but is still something that many languages don’t put among the considerations, much less as a guiding principle. I forgive them for taking a shot at one of my other favorite language mottos, Python’s “one and preferably only one way to do something”, which I also believe has it’s place. But I get their meaning that having a choice of ways to express a solution and being able to choose among them adds a certain bit of artistry to the craft of programming.

I really appreciate the 2nd principle of the Rails doctrine, “Convention over Configuration”. Right now, my primary day job is working on an app that’s been around for 15 years, and it seems for every problem encountered the people came up with a way from scratch for how to handle it. There’s no conventional way to do anything. But as the author says, “Part of the Rails’ mission is to swing its machete at the thick, and ever growing, jungle of recurring decisions that face developers creating information systems for the web.” Sane defaults make a lot of things possible with little effort, as is shown by the demo app in the next chapter. Just like the Principle of Least Surprise, it begs the question of “Sane (or least surprise) to who?”, but in general the framework itself is built with enough consistency that once your steeped in its general way of doing things, they make sense as a whole. I endorse the idea that freedom from choice is sometimes exactly what is needed, rather than freedom of choice to do it a different way. “A place for everything and everything in its place. Constraints liberate even the most able minds.” This is the same type of consistency that Python’s motto helps provide, but with some wiggle room left for expression in implementation.

I could go on analyzing tenets of the Rails Doctrine, but let’s get back to the book. I will argue that I sometimes feel “monkey patching” is more power than programmers need, even if it allows some cool tricks. But I haven’t used it much. It just seems a nightmare that you might end up having to look at someone’s legacy code down the line where they completely misused it and nothing makes sense. But then again, I like having sharp knives in my kitchen too. I just don’t have to cook after many other chefs. Even good programmers sometimes make questionable decisions when pushed for time assuming the language allows certain shortcuts. It’s the sharp knives offered by Ruby and Rails that sometimes make me want to stick to the easy consistency of Python and Django, even if they require a little more boilerplate to accomplish similar tasks.

I did promise to get back to the book. It points out also that “Rails is Agile”. It’s too easy to forget the core tenets of Agile development; they become easily lost to a focus on the ceremonies of Agile. The book restates the four preferences of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As someone who works at an organization that is permanently mid-transition between doing things waterfall and approaching them with more agility, I like to remember the core philosophy of the Agile Manifesto and ask if the particular procedure we’re seeking to follow embodies those ideas. It’s too easy for the core ideas to get lost in the ceremony of scrums and sprint planning meetings and the artifacts of burndown charts.

Who is this book for? It’s aimed at application programmers who want to build and deploy web based applications. It’s fine if you’re new to Rails, and it might be fine even if you’re new to Ruby. My Ruby is rusty enough that I had to review at Learn X in Y Minutes, but that’s a good sign I should be alright. I have a whole catalog of Exercism problems that I worked in Ruby to review with too, in the worst case. This book is more about how to get things done, and doesn’t attempt to act as a detailed reference book. There’s online API references for that type of stuff.

That was just the introduction! We’ll be a bit quicker now. Especially since the first chapter is all about getting setup. It has useful instructions for a variety of platforms, including working from a vagrant box or using the cloud9 online IDE. I figure that I like having a recent version of ruby around at the command line anyway, so I followed the OS X instructions and used homebrew (which I already had installed). I’m tempted to try Cloud9 sometime, especially since a quick Google tells me that it does have Vim keybindings. Maybe some other time. It looks like in addition to rails, we need yarn and chromedriver. I don’t have yarn installed yet, as I’ve just used npm for packages, and I’m looking forward to using chromedriver from Ruby. I use selenium and chromedriver at work to do end-to-end testing of some of my applications, so I’m used to working with chromedriver in Java. I needed to uninstall rvm to get the new version of ruby on my OS X box. It seems that rbenv is the book’s preferred way for managing multiple Ruby’s these days.

On an unrelated note, when did OS X get the ability to remap Caps Lock to Escape without addons? I always used to use Seil and Karbiner, but they quit working in the latest version of OS X. I was about to try Karbiner Elements, but when I checked modifier keys under Keyboard in System Preferences, I saw that it had Caps Lock there and an Escape option. Sorry to toss this in the middle of everything else, but it’s really been bugging me in Vim to not have my Caps Lock act as Escape. Unless I stay on a Ruby kick, the next book I review might be Practical Vim. I believe I saw the second edition was on Safari Books the other day. Sorry for the aside, but I got distracted while waiting for homebrew to update all my packages.

Back to the book. After covering installing in the environment of your choice, along with some advice for when/if things go wrong, we get to Chapter 2, “Instant Gratification”. In this chapter, we’ll make a quick demo app to get our feet wet with Rails. I’ve put the demo app with completed exercises up at demo51. I’ll cover Chapter 2 next blogpost, this one is already getting pretty large.