Learning Scalaz 7 in 18 Days - A synopsis of eed3si9n's wonderful posts

Learning Scalaz in 18 Days was a wonderful series of posts on eed3si9n's blog; however, without a table of contents there I wanted a central place where I could access it and thus this.  I also threw in a few more related resources for good measure.  Besides, this allows me to add an updated post on my own blog without having to actually go to the effort of writing anything original! :-)

Prep/additional material

Ordesky's Scala book - Covers the basics and is a good reference.

Learn You a Haskell for Great Good! - irreverent/fun intro to Haskell and, more important in this context, learning about the concepts and terminology of functional programming.  So much of Scalaz concepts and terminology (not to mention the code itself) is based on a Haskell-centric view of FP that knowing at least the basics of the Haskell ecosystem is, in my opinion, crucial.

Scalaz Resources for Beginners - A good index to scalaz resources

Introduction to Category Theory and the follow-up, Applicatives are generalized functors

Scala In Depth - Great for understanding Scala's type system and standard collections library, functional programming concepts, and much more.  The best Scala book, IMHO

Functional Programming in Scala Early Access Book - Great background in functional programming with many of the examples and concepts mirroring Scalaz (appropriate since the authors are two of the main Scalaz committers)

Monadic Design Patterns for the Web  - Actually, I'd recommend reading this *after* absorbing the rest of the material on this page: it's not for the faint of heart and assumes quite a bit of knowledge around advanced functional programming, logic and abstract algebra concepts but it's really worth getting through.

High Wizardry in the Land of Scala - Daniel Spiewak's wonderful talk on typeclasses, types and kinds, and more.

Extreme Cleverness - Functional Data Structures in Scala - Daniel Spiewak's great talk on persistent data structures.

BASE Scalaz Talk - Bay Area Scala Enthusiasts talk from Adam Rosien of Box.

Scalaz Cheatsheet

Scalaz Scaladoc

Mike Pilquist's Scalaz Overview Presentation

Mike Pilquist's Scalaz State Monad Presentation

Advanced Stream Processing - A talk on advanced stream processing given by Scalaz commiter Paul Chiusano at NE Scala 2013

Debasish on Monad Transformers

Precog Blog: Monad Transformers with Scalaz

Stackless Scala with Free Monads

The Essence of the Iterator Pattern

Enumeration with the Iteratee

Runar on Scalaz (Infoq)

Precog Blog: Abstracting over Futures with Scalaz

Learning Scalaz 7 in 18 Days

Day 1 - Typeclasses 101

Day 2 - Functors

Day 3 - Types and Kinds

Day 4 - Functor Laws

Day 5 - Monads

Day 6 - for comprehensions

Day 7 - Applicatives and Applicative Builders

Day 8 - Monadic functions

Day 9 - Zippers and Tree

Day 10 - Monad Transformers

Day 11 - Lenses

Day 12 - Folding, Unfolding, Traversal and Iterators

Day 13 - Implicits and scalaz imports

Day 14 - Giving back: contributing to scalaz

Day 15 - Misc typeclasses (Arrow, Category, Unapply, etc.)

Day 16 - Memoization

Day 17 - IO Monads and Iteratees

Day 18 - Free Monads

"Private Pyle, you are definitely born again hard. Hell, I may even allow you to serve as a rifleman in my beloved corp."

Over the past year I feel like perhaps I too have been born again hard.  After nearly a decade of increasing "responsibility" and the white papers, power points, project management - I even joined the ranks of the PMP for god knows what reason.  After all that, the TOGAF cert and EA boards and buzzword central, I'd had enough and re-joined the ranks of the engineer, tossing aside the shackles of enterprise architecture.

Actually, I misspoke.  No choo-choos or cantilevers at my job.  Rather, I took my place again among the brotherhood of the developer. I'll admit I dislike the title of engineer as much as I do architect.  I'm not working on railroads, or crafting the next generation computer processor, just as I'm not designing buildings or bridges.  I'm developing software, which is still in its infancy and thus is still as much art as it is science.  That's what I love about it.  I'd forgotten what an aesthetically beautiful thing a well designed piece of software can be, even apart what it might do.  And I love it that I can look at what I wrote three months ago (or even three weeks ago) and see what a piece of shit it was.  It doesn't mean I'm a bad developer but that I'm continually becoming a better one.

For now, I'll leave the houses to Frank Lloyd Wright.

Fear of a Paren Planet

Is there a technical term for fear of excessive parentheses?  If so, I am so afflicted.  These decease has kept me from embracing Lisp and Lisp-derived languages, including the latest hot commodity, Clojure.  I really admire a lot of what Clojure is all about, especially its use of Software Transactional Memory, tight integration with Java / runs on the JVM, etc.  I'm a big fan of functional programming, having fallen in with a Scala crowd for a good chunk of 2010.  I've always been a fanatical immutability nut with my Java code, driving people nuts with my incessant use of final (and am happy to report my current client's technical leadership is similarly mad in this regard).  The stock of functional programming and immutability will only rise as highly, even massively concurrent programs become norm in our multi-core world as Moore's Law gives way to Amdahl's Law.  All of which should lead me to Clojure's door.  These parens, after all, are just syntax, only surface.  In a way the minimalist nature is beautiful.   So maybe now is the time to get over my irrational fear and take the plunge.  I don't think Clojure could take the place of Scala as my favorite functional language, though (even if Scala is in fact less pure in that department).  I'm also, in the end, an object snob and like the dual nature that Scala provides there: objects in the large and functional in the details.  But perhaps even that wall could come crashing down.

Those who can do sometimes can still teach

I just finished Martin Fowler's new opus, Domain Specific Languages.  Years in the making, it's a good read.  It's Fowler, so that's not a surprise: even if I disagreed with everything he wrote, I'd still enjoy reading his work.  I don't want to regurgitate it here but suffice to say that the book is laid out in a form familiar to Fowler fans (the first half is a narrative and the second, a reference).   You may not think DSLs affect what you're currently into but if you're involved with technology at all, you'd be wrong.  You might also be surprised at what Fowler considers DSLs and his ideas around fluent interface driven APIs (fluent APIs are generally a bad thing from a design perspective when viewed purely in an imperative light but are essential in the context of a DSL).

Speaking of good writers / communicators, I've been lucky enough to have been introduced to James Iry's blog in recent months, now that I've down deep into the Scala rabbit hole at work.  I'm into my third month of every day Scala coding and loving it more having had a chance to develop in anger with the language.  I was off put by Scala when first playing around with it last year, thinking a hybrid Object/Functional language was a Bad Thing.  It most certainly can be a bad and overly complicated thing, but that's true more or less of any language in the wrong hands.  But with the right infrastructure built up around the scala core (maven plugins, the right libraries, Spring, Scala IDE plugins - Eclipse, Intellij and Netbeans all have working versions that are everyday getting better), it's the simplicity that I'm left with.  And I love the Object/Functional bifurcation (OO in the large and functional in the small tends to be the best approach for most things, I've found).  Anyway, back to James.  The key of success with Scala (or any functional language) is to understand the basics around FP.  One of the key concepts is the Monad.  The concepts and properties around Monads can be a tad intimidating to the uninitiated but like many things, at their core, Monads are pretty basic.  James has some of the best blog posts around such topics, laid out in such a way even us mere mortals finally get it.   His 4-parter on Monads are a case in point.  Check it out.

Continuous Continuum

There are classics in technology literature, much like there is in any other category of writing.  Many classics are at least superficially dated and for more than a few, this runs deeper.  While this might be true for other forms, the rapid pace at which technology evolves means that a software engineering tome is much more susceptible to obsolescence than a novel concerning the folly of war.  And, of course, the pace at which something can attain "classic" status tends to be much quicker in the tech world as well.    I think there are at least a few books out there (and more every year) that I keep coming back to, and not just as a novelty (like when I pick up one of my original X Windows books from the 80s for a chuckle).    Fowler's  Refactoring, Brian Goetz's Concurrency in Java and Joshua Bloch's Effective Java are books that don't get old for me (and the later two are not great only within the context of the Java programming language).

Well, there's a new book in town.  Too early to tell if it'll take its place among those other tomes in my pantheon, but I have a feeling it'll make it to the second tier (along side such notables as Sam Ruby's RESTful Web Services, Kent Beck's Test Driven Development, Peter Coad's Java Design and Martin Ordesky's Programming in Scala).  The book?  Continuous Delivery by Jez Humble and David Farley.  It doesn't have anything ground breaking in it (technology books rarely do - the industry moves much too fast  while the publishing industry lumbers along much too slowly for that to happen).  But the subject itself is, to my mind, one of the most fundamental pieces of the IT pie, growing ever more fundamental as an organization grows.  It's also fundamental if utility computing is ever to approach its potential and become the underpinnings of a real enterprise level transformation (cloud everything hype aside).  

I've been consulting for the better part of 10 years now and have probably spent about half that time in trying to bridge the gulf between development and operations (and the other half helping to automate bits and pieces of the build/deploy/provision/configure puzzle or troubleshooting problems when some manual portion of that death march went haywire).    So it's a subject near and dear to my heart.  The book's well written and I'm liking it thus far (I just hope enough people who are not already members of the choir get their hands on this religion).    Let's pray that it does.

Deck Lifting

I'm cutting code on the deck and recovering from a wicked sunburn. I know better than to venture outdoors without SPF 10000 plastered head to toe or a space suit. But apparently not better enough. I'm attempting to learn the lift framework by knocking out a pet store (hey, I'm relatively old school). All part of my year-long scalification. Lift is a nice web framework, not that we needed another to choose from. I wouldn't pick it to use for a real world app, probably, but it suits my immediate needs. It seems that even with all the fancy frameworks and increasing choice of languages, the LAMP stack still rules for large scale web apps, at least on the front end. As it should be, though I personally haven't, living mostly in the world of enterprisey applications, except for the past three years when the large scale ecommerce platform I was a part of was Flash, JavaScript and Spring MVC. Now I'm in the telecomm world and it's Flash/Flex and Spring MVC. I try my best to stay out of the front end's hair for the most part (I'm not very good at it and prefer integration and backend server side challenges. Which is where Scala shines. So why then Lift? First, it's well put together. I'm always a sucker for well architected frameworks, whatever layer they serve. Second, it provides a means by which a great deal of the language can be exercised in interesting ways.

So, gotta get back to my light lifting. And hiding from that evil sun.

thinking about thinking

Despite my best intentions, I've neglected this blog.  I've been spending whatever spare time I've had on my other non-techie blogs and frankly haven't been taken with anything on the technology front that's inspired me much lately.  

One thing I've noticed that certainly isn't inspiring has nonetheless been on my mind lately: thinking, or rather the lack of it.  It  has been an unfortunate constant to greater or lesser degree over the quarter century I've been making a living writing software: we too often as both developers and managers forget to include in time estimations what might well be the most important thing: time to think.

Estimates might include the time it takes to "design" (usually, the time to type up the design or sketch it out), the time to type in the code and tests, time to debug, refactor, adjust, and time for documentation (user doc, examples, etc.).  Each of these activities as described are necessary things but are in the end essentially documenting the results of thinking.  The code documents your thinking so that the machine understands and can execute it, the debugger helps you figure out where your thinking has gone wrong (so do, obviously, your tests).  It seems to me, though, that the actual thinking itself is never raised as a formal activity.  Ideally, it shouldn't need to be (it should be assumed as the primary driver for everything else).  But in my experience that isn't always the case. All the rote things you have to do take time as well, and often if something doesn't fit into that vein, it's not considered.  Of course, you still have to do the thinking, but because no time has been allocated for it, it often gets rushed and relegated to a supporting part where it really ought to be the star.  Maybe it's just me, but I have a feeling in this case, it's not.

Of course, this malady has been noted over the years by a number of folks.  Check out Andy Hunt's Pragmatic Thinking and Learning for a great read that touches on this (among many other things).