Opinion

As a reviewer…

One of the other things I spent time on last year was acting as a reviewer for a book that was recently published by Packt Publishing. I was approached by Packt early in the summer to volunteer to help review a work in progress called Enterprise Application Development with Spring and ExtJs. I was skeptical at first, so I did some research. Easily the majority of blog and message board content on the subject of being an unpaid reviewer, especially for Packt for some reason, was negative. This was an obvious red flag. However, I read a fair number of technical books, and I do enjoy writing, so I thought it might be an interesting thing to participate in, especially if I ever wanted to be an author in the future. In the back of my head I knew that if it became too much, especially given that it was volunteer time, that I could simply back out. I agreed to participate and off we went.

Here’s the basic deal: you get a couple of chapters to go through every 4 days. They give you a questionnaire to fill out with your comments. The publisher encourages feedback on many different levels – sentence structure and grammar, chapter-level organization and content, even the order of the chapters and higher level things. All fairly reasonable.

In all, I didn’t have a problem with the process. It was very interesting to see a book as a work in progress. By the time I was involved, it was clear the tools, table of contents and topics covered were fairly well set. Obviously, getting paid would have been nice, but I knew I was volunteering (well, I was getting a free ebook). I also knew the subject matter, which made things much easier. I was able to bypass the learning part of reading the book and focus on the content, how it was organized, and what type of an experience a reader would have with it.

On the book itself – it’s not bad, it’s just presented in a way that would be hard for me, personally, to digest. For a topic like this, I like to start with a clear goal – working through a project to learn a new technology. Additionally, I prefer consuming new information in small pieces and repeating that consumption, reinforcing foundational concepts while slowly increasing complexity, all the while verifying my progress with test cases. Some examples of books written in this fashion that I enjoyed: Agile Web Development with Rails, Grails in Action. This book is presented in a very waterfall-ish way in the name of Enterprise Application Development, and I think this is where I had the hardest time. Developing apps in the Enterprise does not require big up-front design or a waterfall development methodology. The reader is consuming huge new pieces of knowledge in each chapter, and we’re not doing anything to verify them as we go. The book has the reader waiting for a few layers of the application to be developed before performing integration tests. My concern here is that a reader will be trying to troubleshoot something they wrote two chapters ago, and that they just learned within the last few hours. That sounds frustrating!

Side note: I wasn’t a huge fan of the tools used in the book either. I feel like they are complex enough to be a distraction, that there are more modern/simple choices (Ivy, Eclipse, Spring Data) that would have possibly let the reader focus more on learning Spring and ExtJs.

In short, it was a great experience, I’m glad I did it, and I learned a lot, but if I ever do this again, I’ll make sure my own views and development/learning style are in better alignment with the author’s goals for the book.

Advertisements

On resolutions…

2013 came and went, and I definitely did not get around to learning much of what I planned to learn/write about.  I still have the books, and they’re electronic, so they’re not collecting dust, but instead of continuing to dig into new languages and frameworks for the JVM, I spent much of 2013 learning new technology based on client demand.  Not bad things, just unexpected.  I sharpened my javascript skills, and spent a few months in the .NET world. (pro tip – INSTALL ReSharper ON THE FIRST DAY)

This year I’d like to get through that Play/Scala exploration and check out the Reactor (the asynchronous app toolkit by the Spring team).

When will I stop thinking that putting it in writing will be motivation enough to actually do this stuff?

Book Report: JavaScript Patterns

Before picking up what I actually had on my list to learn this year, and finding myself writing more JavaScript than ever at my current client, I thought it would be wise to take a deep dive into the language, it’s lesser-known features, and it’s best practices. I knew a fair amount, but I was not prepared for what was contained in JavaScript Patterns by Stoyan Stefanov.

The book started with an overview of general best practice patterns in javascript – things like using a cached length in for loops, single var declarations, equality checks, namespacing, and quickly moved to advanced object creation patterns, functional patterns like memoization and currying, and coverage of most of the Gang of Four patterns. At each step along the way, examples and detailed explanations drove individual points home and provide good future reference.

While all of the information in this book is well-written and valuable, much of it is good in theory but probably wouldn’t see the light of day in most projects (Module pattern, Constructor patterns, Inheritance strategies), unless you are not using an existing framework or are rolling your own. It is very valuable to learn how things operate behind the scenes, and some of these patterns are now recognizable for me even in the ExtJs source, but I’m not sure I’ll have opportunities to use many of them while writing new code. That said, the items that will see the light of day – implementing best practice patterns, some of the GOF patterns, and explaining scope and other common misconceptions developers have with the language are absolutely critical – good for newbies and good refreshers for veterans. I know tools like JSLint encourage you to leverage most of these practices/patterns, but having a deep understanding of why you should leverage them is even better.

This is next-level JavaScript understanding that I previously did not have. I highly recommend this book, and I recommend keeping it handy if you’re writing JavaScript regularly.

Keeping It Old (Pre) School – The Show & Tell Post

I have young children, including one in his second year of pre-school.  He seems to enjoy it.  He especially enjoys when it’s his turn to bring home the Sharing Bag.  The Sharing Bag is his school’s version of Show & Tell – bring something from home to share with the class that you think is interesting or cool or whatever.  
 

Like most other consultants at Redpoint, I’m on a small team at a client site.  Many of us are working on interesting projects.  We’re encouraged to keep our skills sharp and continue to learn.  Many of us have personal projects or side projects as a way to do this.  Some of these projects are commercially successful while others are just for fun.  In our ranks are folks who put on conferences, lead user groups, and are leaders in their disciplines and various technologies.  We come from a variety of backgrounds and have a variety of interests.  I am fortunate to work with a lot of very bright people from whom I can learn a lot.  Unfortunately there aren’t very many opportunities for us to get together as a group and get into any of this stuff.

 
Enter the Show & Tell.  
 
Earlier this year, we put out our first call for participants for a Show & Tell and got quite a few responses.  We had no set meeting format. We only knew we would get together in some open workspace in our office after hours and do what we learned how to do in pre-school: get up in front of everyone and share.  Anything even remotely relevant to our work as developers would qualify.
 
We saw many very interesting projects during our first session.  Among them were a social media aggregator, a couple of mash-ups using geolocation data from the City of Chicago, a video game, a side project for a restaurant, and an arduino-based DIY Segway clone.  A second session was held last week.  There we saw an interesting and possibly first-of-its-kind solution to a complex problem for a client project, an overview of some emerging technologies, and a web sockets-based presentation server.
 
More importantly, at these sessions, each of us got an opportunity to share a skill or an interest that we have that we might not normally get to use at work, and through that each of us was exposed to a wider variety of technologies and real uses for those technologies – all of which makes each of us more effective at our craft.  Any of these projects could provide a starting point or influence a solution for a client, or inspire a new project from any one of us.  
 
So, why re-invent the wheel?  Something that many of us learned when we were just starting to attend school and interact with our peers continues to be an effective way to share interesting material with and learn from each other, benefitting everyone involved.   

Kind-of-a book review: Design Patterns in Ruby

It has been many years since I have read this much information on Design Patterns, and in those days the language the book was based on was Java. While the concepts still apply, Design Patterns in Ruby does a great job of walking through the classic patterns. First, the way we learned them – with abstractions and interfaces – followed by iterations toward the ‘Ruby’ way.

Moving between languages and development styles effectively can be difficult. It’s not just syntax, either. At the basic level, most languages function the same way. Conditionals are conditionals and loops are loops. Personally, getting into the “culture” of the language is the important part. In my opinion, culture is not just defined as the language, but also, language feature usage, development styles, etc. Switching projects and being productive on the first day is possible, but really hitting your stride takes a week or two. After the first week or two, you’re remembering the syntax better, you’re remembering and using language features appropriately, etc.

That is the thing I think I’ll like about this book more than anything else. This book does a good job of spelling out the cultural differences between a language like Java and a language like Ruby; how to get your brain from thinking in Java to thinking in Ruby. The original GoF book on patterns for Java was a set of recipes that solve common problems – in this case, we get the same, along with the transition between the two, as well as patterns that can be uniquely addressed using Ruby.

The one line summary of this book: “Language features and the dynamic nature of Ruby make common design patterns easier to implement clearly with fewer lines of code.”

A quick refresher with a book like this before my next Ruby project will be in order.

I resolve, version 2.0

2011 is gone and with new year comes new resolutions. Some of last year’s resolutions got resolved, others fell to the wayside, and now I’ve come to write down a few more.

I never got back into grails – although I still feel like I want to. That one stays on the list!

Revisited some old text books, but I still have more to revisit. I forgot a lot about design patterns. Some of that is interview fodder, but still among the things I like to know.

The tracker app never went out, but an equally cool side project did – http://alianosbatavia.com – an implementation of a turn-key restaurant web app. Fairly successful so far, gave me a reason to write a production rails app, learn more about SEO, etc. Still not sure what my next idea is, but I want to get another app out this year…

Is Java still relevant? I go back and forth on this. I am thinking of either learning Play! or Scala/Akka. Not sure I care about either one. I think this is at the bottom of the list.

Lastly, I need to write the posts I talked about writing last year, including my favorite anonymous inner class mock madness.

Hopefully, I’ll be back soon.

I resolve

* Finish reading The Rspec Book
* Get back into Grails, learn the new features of GORM and checkout plugins that have been created/updated since Grails 1.3 first came out
* Get back to basics and re-visit some old textbooks on algorithms
* Learn some new testing frameworks (spock, mockito, etc)
* Write a post defending mocking with anonymous inner classes in java
* Finally write my show tracker app – this time in Rails

The real question is whether or not making this public will help these get done.