More thoughts on Digital Transformation success:
An article I contributed to:
An article from ACM (Association for Computing Machinery) I shared a thought for: https://cacm.acm.org/news/226414-devops-momentum-in-the-enterprise/fulltext
Not trying to totally neglect this blog, so here are some links to various publications I’ve been included in or have contributed to in the last few months:
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.
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?
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.
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.
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.