A short and colloquial introduction to Kanban, and/but mostly by comparing it to Scrum. If you're considering switching your shop to "Agile" methods,A short and colloquial introduction to Kanban, and/but mostly by comparing it to Scrum. If you're considering switching your shop to "Agile" methods, and/or are dissatisfied with the more traditional (!?!?) Scrum: give this a read. It's short enough that you can finish it in an afternoon; you could even skip part one and get the real meat of it from the case study discussion. (Also: it could use another pass with a red pen by the editors and proofreaders...)...more
If you're new to the world of REST APIs, and if you're looking for a good set of working rules on how to design them, then Mark Massé's REST API DesigIf you're new to the world of REST APIs, and if you're looking for a good set of working rules on how to design them, then Mark Massé's REST API Design Rulebook should live up to its title just fine. It's a short book (you could read it in an afternoon) and it tackles the subject matter in a direct and orderly fashion. It starts with a brief history lesson, quickly reviewing the history of the world wide web, of HTTP, and of the emergence of the whole notion of "RESTful" APIs and services. From there, he lays out the six constraints of the web's architectural style,  and how RESTful designs fit into that. The rest of the book is basically just a series of "rules" to follow when designing a REST API, along with use-cases, examples, and justifications for each of those rules. Many of these rules seem very common sense and sound a lot like every other bit of advice you've ever received about (for example) naming variables and methods;  other rules seem sensible but get boxed in by "real-world" difficulties  or else seem counter to the prevailing wisdom;  still others seem to be little more than evangelizing for Massé's own proposed WRML design/modeling framework.
For me, the highlight reel included: the first three chapters (on identifier design, interaction design, and metadata design), and some of the discussion in the final chapter ("Client Concerns") about security, and the overview (however brief) of JSONP and CORS as solutions for some otherwise challenging situations.
The two bits where it went off the rails a bit for me: (1) Any of the discussion of "hypermedia" and/or between-document linking--I haven't encountered this much (at all?) in the real-world and a lot of it seemed overkill to me, to go into that depth on how to link documents from within the API.  (2) WRML: what? Even after reading the whole book, I was still left wondering what exactly WRML was intended for, and what it would buy me as a developer. It seems that Massé wrote this book in part to evangelize this framework, but I could not quite get my mind sufficiently around it to say that I got it.
On the other hand, Massé does a great job with the "rules" (again: especially in the first half of the book) and I would recommend this to anyone that needs an introduction to REST API design. That being said, after absorbing this one, you'll probably want to explore further with one of the other O'Reilly books on the subject, and/or find yourself a couple of resources on OAuth.
(Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.)
 E.g., use singular nouns for documents; use plural nouns for collections and stores; use verbs ("and verb phrases") for actions, etc.
 In Chapter 2 ("Interaction Design with HTTP") Massé advises you to use the pedantically correct HTTP methods for performing the corresponding actions: e.g., if you want to delete a document, send a DELETE request to the document's URI. However, as most web developers already know, mainstream browsers will not respect any HTTP methods other than GET or POST--so you can forget trying to use PUT or DELETE as a form's method, and you're stuck using POST as a wrapper. (Here is a good Stack Overflow thread on the subject.)
 E.g., all those API URIs that have a '/v1/' in there somewhere? to specify the API version? Massé says: "Don't do that."
 And as an aside, it was very unclear to me how the rel (relationship) attributes were even suposed to be defined. Some central standard? Part of WRML? Do you make stuff up and furnish an end-point in your RESTful API to explain the rels?...more
A light and easy introduction to MongoDB. But what I really wanted was this. (That being said, it did help me get a few things straight w/r/t/ queryinA light and easy introduction to MongoDB. But what I really wanted was this. (That being said, it did help me get a few things straight w/r/t/ querying and updating prior to turning to that index.)...more
There were moments I did not believe that I would give it much more than a four star rating, and that that would be generous. But it comes together. TThere were moments I did not believe that I would give it much more than a four star rating, and that that would be generous. But it comes together. There's a twist that I felt I should have seen, and didn't. There's some HoL-esque typographic trickery (though substantially less of it). There are tricks of language. I'm told that there are parallels aplenty to make this a science fictional re-telling of The Count of Monte Cristo, but I'll admit that I don't that book well enough to say one way or the other. What I do know is that I found a surprisingly difficult, and surprisingly sophisticated story crystallized in what is otherwise a bit of high adventure. I believe I'll need to read it again, but I believe this one is well worth it.
Where the book becomes more interesting is in Parts II ("Programming Practices") and III ("Automation"). Again: the chapters that comprise Part II are going to seem like review for many seasoned JS devs: keep your JS and your mark-up loosely coupled; avoid global variables; keep configuration data separate from business logic; use feature detection instead of browser detection. As much of these may seem like review,  don't get cocky and skim it, either--there are some gems in there. (In particular I'm thinking of the chapter on Event Handling that spawned this interesting post by Ben Nadel.)
The chapters in the Automation section were my favorites. Zakas builds up a solid Ant-based  build system over the course of 7 chapters that includes validation and linting, file concatenation and gzipping, minification, documentation, and automated testing. As I've become highly interested in the build process, I was riveted by these chapters. Zakas at least touched on every topic in the automation/build topic that I would have wanted to see. But that being said: the operative phrase was "touched on"--I would have loved to see more on this subject. He provides a lot of excellent starter material, and Appendix B is a rich list of other jumping-off points, but it also seemed... shallow? Like he was just scratching the surface? This seemed especially true of the chapters on documentation  and testing.  
 Although, honestly, my first thought was: "Really? Ant?"
 Although I suppose I have lofty expectations for documentation. (A detailed glossary of what the different @keyword annotations are for etc.) This chapter is probably fine, it's my expectations that are messed up.
 I definitely think there could have been more on testing. There's like a page and a half on PhantomJS. Having played around with it a bit myself, I feel like it could have earned a chapter all to itself. Granted, I wouldn't want the whole book to be about testing (Grails in Action, I looking in your direction)--and since most JS books don't mention testing at all, I'm grateful to see it get at least the chapter that it did but... I could have used a little more.
Disclosure: I got a free copy from O'Reilly in exchange for writing a review as part of their blogger/reviewer program......more
H. found this at the library and we picked it up on a whim. Never heard of Bob Kolar before, but this book is a cute story with some fun rhymes and deH. found this at the library and we picked it up on a whim. Never heard of Bob Kolar before, but this book is a cute story with some fun rhymes and delightful illustrations. Everyone can love this book....more
The short version: Lehrer draws together some interesting ideas, but I feel like his rhetorical flourish sometimes gets in the way of the point he's tThe short version: Lehrer draws together some interesting ideas, but I feel like his rhetorical flourish sometimes gets in the way of the point he's trying to make. His main point here is that creativity and innovation arises when we freely mingle within diverse ideas, but sometimes it seems like he's too busy boosting for entrepreneurs and big cities, and he lets that get in the way of his central thesis. (Side note: I waffled between 2-stars and 3-stars.)
In Imagine: How Creativity Works, Jonah Lehrer presents a series of experimental findings and narratives, and draws them together to into an optimistic thesis on creativity and innovation. But there are two books here: there's the successful book, the book where Lehrer is a capable wordsmith with a knack for describing and synthesizing these scientific findings and their implications in a way that is accessible to a lay-audience; and then there is the mediocre book, the book where Lehrer substitutes anecdotes for evidence, where he lets latter points undermine positions formerly established, where he allows his rhetorical flourish to obfuscate the point he is trying to make. And it is with that in mind that I closed the covers with mixed feelings.
Lehrer's optimistic thesis in a nutshell: Creative Genius  is not some rare gift that only a remarkable and privileged few are born with; instead, Creative Genius is the product of exposure to diverse ideas,  the synthesis of those diverse ideas to form novel innovations, and the diligent pursuit of those novel innovations in the face of challenges, setbacks, and outright failures.
For most of us, this is fantastic news. We don't have to win the genetic lottery to be Creative Geniuses. We're still at the mercy of other privileges (e.g., we still need to be situated such that we can be exposed to diverse ideas; we still have to have the financial and emotional resources to withstand the failures that stand between our ideas and seeing them to fruition; we still need to live in a culture or society, and live under the aegis of a government that does not have draconian intellectual property laws and/or censorship laws and/or lots of other apparatuses set up for maintaining the status quo at all costs) but assuming all those other things line up, we may all be poised to become Creative Geniuses and change the world.
Imagine contains a lot of evidence (anecdotal, scientific, and in between) to support this thesis. Lehrer talks about the research that went into the development of the Swiffer, and about the almost-random inspiration that led to its conceptions. He talks about how a burnt-out Bob Dylan retreated to Woodstock, NY, with the intention of never again picking up a guitar, only to write the best music of his career literally days later. He writes about how 3M has been doing "that Google thing"  with their engineers for over 70 years. He writes about Broadway productions and what the right mix of "old friends" and "new blood" is necessary to make a hit. He talks about when to take a project and put it in the drawer for a year. He surveys studies (some shrewd, some dubious) from neuroscientists, and on the next pages there are yarns spun through interviews with advertising professionals, urban planners, musicians, magicians, graphic artists, and everyone in between. And all the while, Lehrer's narrative style weaves this all together, and makes it easy for just about anyone to comprehend. But...
An accessible narrative style, the style required to reach a broad lay-audience, too often becomes... reductionist? Overly simplified? That kind of style can muddle some of the nuance that is otherwise necessary for a meticulous scientific discussion.  Some have argued that Lehrer is drawing conclusions that simply aren't there,  but I don't know if I fully agree with that. It's more subtle than that. It isn't that he doesn't have a point, or that his conclusions are unfounded or banal, or even that he is interleaving scientific evidence and colloquial anecdotes with equal significance. That's not the problem.
The problem is that he keeps slipping (ever so slightly) and undermining his own prior arguments as he enthusiastically works himself up to support whatever argument he is shaping in that chapter and on that page. The problem is that he tends to contradict himself. Nowhere is this more obvious than in the book's penultimate chapter. Lehrer fetishizes big-city-living  so much that he begins to celebrate this concept more than anything else   and in doing so, he comes close to compromising many of the points he made before. In the preceding chapter, he beats the drum of travel as the critical path to gaining diverse experiences and gaining exposure to diverse ideas, but when he gets around to talking about big cities... Well, you may as well just move to New York City and call it a day; who needs to travel when you can just live in the place where everyone is going to (or through) anyway? Granted, this is not explicitly stated, but therein lies one of my gripes--that this seems to be such an obvious conclusion and such a clear cognitive path between the two discussions, that I am led to believe that he did not fully explore the implications of some (many? most?) of these critical concepts he was exploring to benefit his thesis. If he did not make the link between those two points, then what else did he miss? what else did he gloss over? what other connections were not made?   Worse, there is a clear case of reverse causality happening here. Given the research cited, there is clearly an intriguing feedback mechanism taking place in these large and vibrant metropolises, but to say that the city itself causes the creativity is spurious and misleading.
These criticisms aside however, Lehrer's thesis remains strong, and it is refreshing to see someone grapple with the subject matter in such an optimistic fashion. It seems that we too often treat the "creativity" of "innovators" as this scarce natural resource. There is romance in the mystery of Creative Geniuses, but it is not a helpful romance. You need not be born "that way"; being a Creative Genius (or even just Sufficiently Innovative) is something that you can work toward. All we need is the right climate:
We need to be willing to risk embarrassment, ask silly questions, surround ourselves with people who don't know what we're talking about. We need to leave behind the safety of our expertise.
The right kind of stubborn temperament helps, too:
In fact, most of us see perseverance as a distinctly uncreative approach, the sort of strategy that people with mediocre ideas are forced to rely on.
Lastly: Lehrer isolated this brilliant quote from Yo-Yo Ma:
If you are only worried about not making a mistake, then you will communicate nothing.
...which just about sums up everything in the book, and everything I feel about the book.
 "Creative Genius" being a phrase that I do not recall being called out (nor Initially Capitalized) explicitly in the text, but it was used rather prominently in Matthew Francis' review on Ars Technica, so I've decided to incorporate it similarly here.
 And we use "ideas" here in a very broad sense. "Ideas" are challenges, concepts, customs, dilemmas, facts, hypotheses, memes, problems, stories, superstitions, suspicions, theories, traditions, words, and every other thing that you might pick up from interacting with another person.
 "That Google thing" being that their engineers get (by anecdotal accounts, at least; I couldn't find anything official) upwards of 20% of their time to spend working on pet projects.
 Granted: I was raised in a household where scientific rigor was de rigueur... And as such, my bias tends to lean toward "more rigor and less rhetoric". Take that as "full disclosure"; take that for what you will. I just always assume that everyone else is looking for that same kind of exactness in the text.
More worryingly, Lehrer’s weightier confusions cast doubt on his glib interpretations of brain experiments.
And the comment thread is filled with similar indictments. (Though you're not missing much if you skip the comment thread on the Chotiner article.)
 He really enjoyed using the word "superlinear".
 Why else would they positioned in the text as they are? if not to culminate with entrepreneurs in big cities?
 There is also some fetishization of entrepreneurs going on in that chapter, which made me bristle a bit--but I can't say that that undermined his point. There was plenty of room left-over for engineers and artists.
 At which I note: there is some embedded irony there.
 Yes, I should have kept better track of these contradictions. But by the time I'd gotten to this point, I wasn't about to go back and start cataloging them for the sake of this lowly document.
Note to self for future real review: Wallace's genius echoes in how Ethan's story is basically Gately's story (to an extent, anyway) (and with awareneNote to self for future real review: Wallace's genius echoes in how Ethan's story is basically Gately's story (to an extent, anyway) (and with awareness of how physical genius is still genius)...
It isn't that I'd never heard of this book... but I had no interest in reading it until I was re-reading Infinite Jest for the 5th (??) time and realized that it must be in some way important to Gately. (And but so even though Gately never finishes it.)...more
**spoiler alert** Last year I read Patrick Rothfuss' first novel, The Name of the Wind. I read it in about a week  and immediately added it as an**spoiler alert** Last year I read Patrick Rothfuss' first novel, The Name of the Wind. I read it in about a week  and immediately added it as an all-time-favorite. I had complicated feelings about this book. I don't generally like "fantasy", but here was a fantasy novel that blew me away. It was witty and clever, gripping, familiar and fully foreign, and weirdly inter-textual in ways that tickled my inner liberal arts lit nerd.
So I was crushed that I needed to wait a year for the sequel to come out in paperback. 
Yesterday, I finished that sequel: The Wise Man's Fear.
The Wise Man's Fear did not immediately earn a place on the all-time-favorites list, but I was glad that it did not let me down,  even if it was also a little tedious in places.
There seemed to be two major themes running through this novel.
The first that appeared to me was one of Consequences. Poisons, harm from afar, side effects of all kinds. Symbolically speaking, the text of Kvothe's tale is beset on all sides by this stuff: sympathy and slippage; the harmful chemicals in the Fishery; grudges held over the wrong thing said to the wrong person at the wrong time... Dealing in consequences helps make the story move, but it also seemed to me to rather strongly inform the second major theme:
Yes, our bookish (and rakish) narrator manages to compromise himself repeatedly by simply not paying heed to what ought to be obvious. Sure, his feud with Ambrose is mostly a matter of spite and hubris  but after Kvothe et al. (covertly) set fire to Ambrose's room... Well: Elxa Dal was doing him a monumental favor by practically spelling it out for him: Take a leave of absence from the University and let the whole thing settle down.
Perhaps more illustrative of that theme, and a scene which informs my opinion of more/less the whole book: Master Elodin, in his class on Naming, tells his students (Kvothe among them) that he is going to throw a ball. He tells them to perform their calculations, to determine exactly where to place their hands such that they can intercept the ball at that exact moment that he throws it. They (the students) all scribble formulae furiously, working their way through it, damning him for this impossible task. With so many factors at work, who could possibly calculate such a thing--to say nothing of calculating it in just a few short minutes. Just as time is expiring, with these Re'lar level students griping, a young messenger boy arrives with something for Elodin. Just as the boy is about to leave, Elodin tosses the ball to the boy, who--without thinking at all--raises his hand and catches the ball mid-flight.
There's much to love in The Wise Man's Fear. And it's a worthy (if somewhat long-winded ) sequel. 
 Which is actually really fast. For me. Even if I was on vacation. Especially for an almost-700 page book. Stop looking at me like that.
 I'm a cheap bastard.
 Seriously: I had no expectation that it could possibly be as good as The Name of the Wind. That book is one of a kind, and special.
 Which (again): where's the common sense?
 But I blame his time in Severn for that.
 Post-script: I'll admit that I didn't really know what to write about this book. It's a good sequel to a phenomenal book, and I'm sure it has set us up nicely for #3. And the part I wrote about are mostly the parts I took notes about. But there was so much more, especially in the latter third of the book, that I didn't really get into. All the stuff with the Adem, and murdering the false Edema Ruh... But I didn't want to get too scholarly on what's otherwise something I was reading just for fun....more
• "Indians." • Like with Farmer Boy: there's some heavy shit going on in this story. But The Boy handled it pretCo-reading with A., for H.
• "Indians." • Like with Farmer Boy: there's some heavy shit going on in this story. But The Boy handled it pretty well. • Talk your way through this one. Try to help The Boy discern the differences between the historically colorful narrative, and the... colorful history. ...more
Not as good as We Are In A Book (if you ask me) -- but still cute. A nice taste of dramatic irony for the kids, in a way that makes it easy to explaNot as good as We Are In A Book (if you ask me) -- but still cute. A nice taste of dramatic irony for the kids, in a way that makes it easy to explain irony to a 3 year old....more
Code Simplicity by Max Kanat-Alexander (published by O'Reilly, 2012) is the kind of book you might give to a junior or journeyman programmer and say:Code Simplicity by Max Kanat-Alexander (published by O'Reilly, 2012) is the kind of book you might give to a junior or journeyman programmer and say: "Read this over the weekend, and then on Monday we'll talk about your design." There are many quotable passages, pithy aphorisms, and axioms that take the form of definitions, facts, rules, and laws. Kanat-Alexander uses a conversational tone that takes this already common-sense study on the subject and makes it even more approachable and straightforward. And just what is the subject here? As the title dictates, the subject of the book is code simplicity: dealing with complexity, identifying areas where complexity is likely to creep in, and strategies for eliminating or reducing that complexity.
At a high level, Kanat-Alexander's discussions of the component parts of this subject are deft and lucid. He is able to evoke familiar situations and scenarios (e.g., coding under a deadline; e.g., dealing with large legacy code bases) and uses those to frame and present his recommended methodologies for keeping code "simple". A lot of the techniques and suggestions will all seem like common sense to anyone who has been programming for a non-trivial interval: reduce maintenance effort before trying to reduce implementation effort; the larger your change, the more likely you are to break something; don't "fix" things unless you know that you have (and have evidence of) a problem -- and so on. Again, to experienced programmers (and, arguably, also to someone who has just sat in on 4+ years worth of computer science lectures?) these suggestions will all seem like conventional wisdom, like the elements of craftsmanship that they perform and preach every day. To those programmers, I say: Give it a whirl for the sake of the reminder, and if nothing else, at least be familiar with it so you'll know whether it is a good tract to hand out to your young and eager recruits.
Again, the book has a conversational style and is filled with pithy aphorisms and witticisms that make it easy to absorb and retain Kanat-Alexander's message. I found myself frequently transcribing passages into my notebook for later reference and for sharing with peers. Many stand out, but two in particular that I wanted to share. First:
Having good comments in code is a big part of making it readable. However, you generally should not add comments that say what a piece of code is doing. That should be obvious from reading the code. If it isn’t obvious, the code should be made simpler. Only if you can’t make code simpler should you have a comment explaining what it does.
I felt this was worth calling out because it was highly illustrative, and emblematic of the theme. Every programmer has had in-depth discussions about comments; and every programmer has committed code that should have been commented, and wasn't; and every programmer has committed code that was commented unnecessarily; etc. This is something that we've all done, and that we'll all do again. Thus, it is easy to identify with the message embedded in this lesson. But what makes it particularly demonstrative of the book's theme is that Kanat-Alexander is trying to teach you first how to do without the comments. "If it isn’t obvious, the code should be made simpler. Only if you can’t make code simpler should you have a comment explaining what it does." And yes, he does immediately go on (in the next paragraph) to state that comments are really more about capturing the ephemeral why of a piece of code, but again the message remains: Consider first what you may add in value by taking away what is written and committed. 
Kanat-Alexander's take on the comments is interesting one to me because it underscores the book's message about taking the time to engage with the code, to execute on thoughtful designs, and to take the time to understand what you're "doing" -- the problem you're trying to solve, the technologies that you've chosen to use, the sacrifices that you're making by choosing one approach instead of another, etc. He talks quite a bit about understanding, about taking the time to read and fully comprehend code before changing it; about taking the time to engage with the problem space and design a solution instead of simply stabbing at one.  Not taking the time to arrive at that understanding is (he asserts) a disastrous source of recursive complexity:
Programmers who don’t fully understand their work tend to develop complex systems. It can become a vicious cycle: misunderstanding leads to complexity, which leads to further misunderstanding, and so on.
Which reminds me of a joke we have going at the office:
Anger leads to hate. Hate leads to suffering. Suffering leads to re-factoring. 
But this is a point which seems to prove itself: that "of course if you don't understand [the problem domain / the programming language / the library / the requirements / the legacy code / the customers / etc.] then of course you're just going to create an at-best mistake-riddled solution." And to those "experienced programmers" out there, stroking your beards and condescendingly shaking your heads with your unspoken "I told you so": I've seen you do it, too.
As for Code Simplicity itself: I do not actually have all that much in the way of critique. As I have said, it is a short text, pithy and aphorismic -- but this is indicative that it has accomplished its goal. So what would I have liked to see, or see more of? First off, there is effectively no code presented at all; not that Kanat-Alexander promises us any -- just the opposite, he eschews code to drive home the philosophical points. Perhaps specific code examples would detract from that -- but there is a part of me that would liked to have seen something concrete in this area. My other nit to pick was that the book's sub-heading is "The Science of Software Development", and though Kanat-Alexander presents things as "facts" and "laws", I didn't exactly see... science. I read a lot of anecdotes, but I didn't see too many experiments of empirical methods. Given Kanat-Alexander's pedigree, and given the common-sense nature of so much of the advice contained in the book, I'll grant him a pass on this -- but I cannot in good conscience call it all scientific, even if I find myself vigorously agreeing with (say...) 99% of it.
So where do I land on this one? I'd heartily recommend it to any junior or journeyman programmer that is looking for some insights into how to improve their craft and how to cultivate simplicity in their designs. I know I'll likely be recommending it to folks that I mentor in the future -- again: as a quick weekend read, but with the caveat that you'll want to keep a notebook and jot down those really good parts.
 Which of course immediately brings to mind this quote: «The more code I write, the more code I get wrong. Therefore, it behooves me to write as little code as possible.» ...which I saw tweeted by @al3x, and is attributed to "Pony" in a piece called "Why Haskell?" and/but the original source link has 404ed for as long as I've known about it.
 It is worth noting that there is a tacit acknowledgment in the text that you cannot "waterfall" your way through designing your solution. He doesn't come right out and use that phrase, nor does he come out and admit that Agile-style rapid iterations are the way to go either. That isn't the subject of the book, and he is wise to stay away from "going there" -- but it's in there, at least a little bit. (No one could help that.)...more
Eric Sarrion's jQuery UI (published by O'Reilly) is a beginner-to-intermediate level overview of the jQuery UI library and its widgets.  Sarrion waEric Sarrion's jQuery UI (published by O'Reilly) is a beginner-to-intermediate level overview of the jQuery UI library and its widgets.  Sarrion walks through these widgets one-by-one, chapter-by-chapter, offering a description for each, elaborating on the UI problem that each is designed to solve, and then detailing the API for each of these widgets. Each chapter is constructed after this pattern, illustrating how to setup your mark-up to best work with these widgets, how to initialize and interact with each widget type, and then showing some example implementations of varying degrees of sophistication.
» Sloppy mark-up. Sarrion mentions that Internet Explorer needs a doctype, but then does not go on say what a doctype is, or why it's necessary or what the consequences of omitting the doctype are... And/but then he doesn't quote the attribute values in his sample HTML either. Even a footnote or two on such subjects would suffice.
 Sarrion's jQuery UI covers version 1.8, but I noticed that it does not cover the position utility. As the position utility is currently flagged on the website as "new", then I presume that the book went to press before that utility's release.
 Though I was disappointed that there was no associated Github repo.
 I'm tempted to go as far as to say they're "superior" to the official documentation, which I've always felt were sort of tacked on. It isn't as though jQuery UI has a terribly complex API (it doesn't, though it is quirky and idiomatic-unto-itself (which: "I guess it's internally consistent, at least")) -- it's just that the official docs focus more on the examples and bury the actual documentation "down there" below the fold, like an after thought. "Minus one to that", if you ask me.
 Turns out that you can. But: !?!?!?
 A thing I don't like, but whatever.
 Doubly dangerous because they're missing their curly braces.
 As opposed to feature detection.
 Table 8-9, I'm looking in your direction.
 E.g., a junior or mid-level dev in an organization that is already using jQuery UI; e.g., an e-commerce shop that is heavy on back-end devs and just wants to put some quick polish on their site.
 This is only partly true. I give Sarrion some big-time bonus points for the calculator example at the end of chapter 5 where he builds the thing up as a one-off, then re-factors it into a plugin-style widget. ...more
I just wrapped up reading  Theresa Neil's Mobile Design Pattern Gallery (published by O'Reilly), and I am happy to call it a worthwhile survey. I sI just wrapped up reading  Theresa Neil's Mobile Design Pattern Gallery (published by O'Reilly), and I am happy to call it a worthwhile survey. I say "survey" because that's exactly what we have here: Neil takes a look at the dominant patterns (and anti-patterns) in the application interface designs that are targeted at mobile devices, and casts a wide net to cover as many of the major patterns as possible. The book does not take a particularly deep dive into any of the specific patterns--or even any one constellation of patterns--but it does hit the high notes for the critical interface paradigms that an application interface developer will face.
Neil covers these patterns as befits the survey style: by presenting each one (categorized/grouped accordingly), giving a short description of what characterizes the patterns, what situations present a good fit for that pattern, as well as pointing out the most common risks associated with that pattern. Each pattern then gets a series of screenshots from actual mobile applications which serve to demonstrate a successful or particularly illustrative example of that pattern. Neil covers: primary and secondary navigations (chapter 1); all kinds of forms and form elements (chapter 2); tables and lists (chapter 3) and charts (chapter 6); searching, sorting, and filtering (chapter 4); on-screen tools (chapter 5) and providing user feedback (chapter 8); as well as how to create accessible help messaging (chapter 9) and "invitations" within the application to draw users to those other elements (chapter 7). There is some repetition of patterns across chapters, but that helps to impress upon you how valuable these patterns are, and why they work the way that they work in those contexts.
The final chapter on "Anti-Patterns" was a particularly useful (and fun!) read, as well. Neil presents five anti-patterns in mobile UI design,  along with explanations on what makes them anti-patterns, and then suggestions on how to work within the previously discussed best practices to improve those designs. These case studies are useful because Neil is careful to break down each example into atomic mistakes, to identify the (likely) motivation behind those design choices, to explain why those design choices fail, and then to illustrate more sensible designs that accomplish the same thing but in a more intuitive fashion.
Though generally well composed, there are a couple of places where the book falls down a bit. First, the text and the images don't always match up--or, rather: the images that follow the text too often follow the text on the next page. Several times (especially early on) I found myself reading something, doubling back to look at the image, and being confused for a moment or two before advancing and "putting the name with the face"; this is an artifact of the medium, but it was a little jarring. Second, there are a couple of spots in the book that could have benefitted from another pass through spelling/grammar editors (e.g., "robust productivity tools t usually include tables", and "state-full buttons" (emphasis mine). Third, I could have used a concluding chapter to bring it all together--the "Anti-Patterns" chapter (sort of) does this implicitly, and there is a nice appendix , but I got to that final page and thought: Where are the parting words? Lastly,  the mobile space is moving so rapidly that this book may wind up feeling out-of-date in the not-too-distant future. There are several screenshots from several apps that are already out of sync with what's out there "in the wild"; this is good--because it means that those developers are innovating and changing their applications to improve their experiences, but it also seems to make these examples... less potent.
That being said, there are some important take-aways from Neil's book--whether you're doing mobile-specific development (her target audience for this book), or just designing/developing interfaces on any platform. Having big "tap" targets is critical for mobile apps, and though it's less important for a desktop application, the lesson about giving "more visual weight" to your primary call-to-action button? You'll carry that with you in all of your UI designs. With that in mind, I did find myself writing down notes that said things like: 
• an axiom:Be deliberate when introducing novelty. • an axiom:Make it finger-friendly. • an axiom:If you cannot be native, be neutral and not novel.
The images were there--sometimes as screenshots, and sometimes in the illustrations--to capture these sentiments, but sometimes I felt like there needed to be pithy sayings like those to drive the point home. Something... sound-bite-size. Does the book suffer because it lacks these? No, it does not. Perhaps they were even left out intentionally, as an exercise for you (the reader) to digest and internalize the lessons.
 Is "read" the right word for a "gallery" book like this? When you effectively have more pictures than words?
 Though these anti-patterns are easily extended to interfaces on any device.
 Which is really just more of a quick-reference sheet anyway.
 And this is probably obvious, and probably true of any technology book.
 I just got done reading The Joy of Clojure, so I think I got the idea from the "Clojure aphorism" sidebars in there....more
short version: A bit dogmatic, but these dudes have done their homework, and if you can tolerate the preachy "seriously, you need to do exactly what Ishort version: A bit dogmatic, but these dudes have done their homework, and if you can tolerate the preachy "seriously, you need to do exactly what I'm describing" tone of it all, there are lots of valuable gems buried within. The bad news: you're going to need support from management to make all this work, and even with that support, it could be hairy in a big organization and/or with a lot of legacy code behind you.
Also... ALSO:Kanban gets mentioned in here several, albeit not by name--and I felt kind of put off by that.
The good news: not every valuable lesson requires that support. I'm going to be generous here and give it 4-stars rather than 3, but mostly because I support the attitudes that underlie their take on Agile/XP, if not their take on Agile/XP.
Not strictly a review, but: you should check out my blog post "Agile for the Introvert", wherein I discuss and critique specific contents of The Art of Agile Development rather extensively. (Also: it's complete with a comment from the author -- which had me more/less totally chuffed.)...more
The H-bomb loves this book. Strangely? He enjoys the idea of all the letters living together in a big house. He also seems to like the idea of "O" staThe H-bomb loves this book. Strangely? He enjoys the idea of all the letters living together in a big house. He also seems to like the idea of "O" standing in for "E" and how it makes me stumble over the words for ≥ half the book. To his credit, I'm a fan of any kids book that annihilates the 4th wall for this kind o trickery. Well played....more
I close the covers of this book with a sense of foreboding and uncertainty. The narrative is a kissing cousin to Dhalgren, and is a city only a littI close the covers of this book with a sense of foreboding and uncertainty. The narrative is a kissing cousin to Dhalgren, and is a city only a little less shifty than Bellona. It isn't per se dystopian (too anarchic?), nor is it really "apocalyptic" (there's been no obvious end of the world) but it's disturbed and disturbing and turned upside down. It's an epistolary novel, and as such conjures up comparisons with The Handmaid's Tale, but less linear. It's harder to guess where this goes next.
It's lyrical, and beautifully written. I'll need to re-read it, I think.
A solid "A-" cookbook. We're not a strictly vegetarian family, but we do try to "eat vegetarian" at least four times a week -- and this cookbook has bA solid "A-" cookbook. We're not a strictly vegetarian family, but we do try to "eat vegetarian" at least four times a week -- and this cookbook has been a great way to expand the options. One of the other things that I enjoy about this cookbook is that it clearly marks vegan meals while also embracing "flexitarianism" and offering ways of adapting certain meals to include a little meat if you'd prefer to do so....more
Running Lean is a handbook for practicing entrepreneurs who want to increase their odds of success.
Which, fAsh Maurya describes his book as follows:
Running Lean is a handbook for practicing entrepreneurs who want to increase their odds of success.
Which, for me, was originally off-putting. Why? When I was reading the blurb, I focused in on the words innovate and iterate and blocked out venture and bootstrapping. I came at this book as an engineer, not as an entrepreneur. And my initial enthusiasm quickly waned: is this going to be one of those self-important business books? But pretty quickly, I figured out that it was not; Maurya was about to lay out a plan for (in essence) applying the scientific method to your business plan. 
Again, as an engineer by trade, I caught myself thinking: this is not what I came here for, I came here for ideas about effective agile development. That's in there, but it's just one of the many lessons that is embedded in Running Lean. Maurya writes lucidly about how to take your product/business idea and shape it; about how to organize your team to focus on The Problem and The Solution; about how to reach out to customers and interview them, to help them help you define the problem space; about how to pull out real information from those interviews and test releases, and learn real lessons instead of just confirming how great you think you are. The lessons of Running Lean help you to create a real solution for a real problem, and not just be a clever solution looking for the right problem.
But what about us engineers? What about folks like me that were looking for strategies on development iteration? Those lessons are in there, too -- if you can get past the entrepreneurese and pay attention to the content.
There's a quote in there:
Not only does this approach delay validation of one of the riskier parts of the model (because it’s too easy for a user to say yes), but a lack of strong customer "commitment" can also be detrimental to optimal learning.
And it made me think of this recent post by Gus Mueller (of Flying Meat Software). In that post, Mueller talks about what his historical pricing model has been for VoodooPad (one of his flagship products), and in particular what the pricing model has been for folks on an upgrade path; and then he goes on to talk about how the Mac App Store has disrupted that. In discussing all of this, he breaks down a number of different approaches he could take in the face of this new reality for his business. He is concerned about price, and naturally he is concerned about product quality; but he is also concerned about the relationships that his customers build with his products. Mueller writes:
I can already hear someone saying "just charge less and you'll get four times as many customers- which is twice as much money!". This will also multiply the support burden (and probably by more than 2x). Lower price means more people will buy a product on a whim. I'd rather have fewer customers that have done the research, compared multiple products, and is willing to pay a higher price for a product that fits their needs.
Fewer but more committed customers. Customers that have done the research. Customers that have decided that this is a product that solves (in a very real way) a very real problem for them. This sentiment dovetailed with Maurya's lessons from Running Lean, and it resonated with me in a big and very important way. In a way, this is exactly the sort of thing that Maurya is writing about -- about not chasing "vanity metrics" like hits or downloads or installs or sign-ups, but instead focusing on asking hard questions and finding real answers, and ultimately building real solutions for real problems for real people. But make no mistake, what Maurya posits is no easy task -- it requires discipline, and there is a sanguine optimism that underlies his implicit assumption that you can do it.
 : And by extension: to your product development lifecycle....more
I can't really explain why I didn't like this one more than I did. I did some vigorous head-nodding with the message, and it's an at-least-decent showI can't really explain why I didn't like this one more than I did. I did some vigorous head-nodding with the message, and it's an at-least-decent showing for a first novel, and there are moments that seem downright prescient for something written 60 years ago. So why did I keep nodding off in the middle of it? Why did I entertain thoughts of abandoning it? It's a 2-star book with several 4-star moments, but not enough to average out to 3-stars. Not for me. Were my expectations too high? Was I spoiled by Slaughterhouse-Five and Breakfast of Champions?
Read aloud with H. Most parts read aloud work, but some spots needed adjusting. The story has a touch of magic to it, and is fantastic for kids and adRead aloud with H. Most parts read aloud work, but some spots needed adjusting. The story has a touch of magic to it, and is fantastic for kids and adults alike....more