Application Architect at ThoughtWorks, Inc.
Neal Ford is an Application Architect for ThoughtWorks. He is an architect, designer, and developer of applications, instructional materials, magazine articles, and video/DVD presentations. Neal is also the author of Developing with Delphi: Object-Oriented Techniques (Prentice Hall PTR, 1996), JBuilder 3 Unleashed (SAMS Publishing, 1999), and Art of Java Web Development (Manning, 2003). His language proficiencies include Java, C#/.NET, Ruby, Object Pascal, C++, and C. Neal’s primary consulting focus is the design and construction of large-scale enterprise applications. He is also an internationally acclaimed speaker, having spoken at over 30 developers’ conferences worldwide.Presentations by Neal Ford
Dynamicizing Your Day Job
This session shows you how you can introduce dynamic languages like Groovy and JRuby into you day job without making anyone nervous.Introduction to JRuby
This session describes JRuby, the 100% pure-Java implementation of the Ruby programming language. It covers the basics of programming with JRuby and examples of how to integrate it into existing Java projects.Comparing JRuby and Groovy
Rather than stand around and sling mud between the Groovy and JRuby tribes, this session delves deep into the similarities and differences between the two, allowing attendees to make informed decisions about their next Java dialect.Productive Programmer: Canonicality & Focus
Getting work done in modern office environments is a daunting task. This session tackles 2 of the things that drag down developer productivity: lack of focus and creeping repetition.The Productive Programmer: Mechanics
Developers from the 1980s would be shocked at how inefficiently developers use their computers because of the advent of graphical operating systems. This talk describes how to reclaim productivity afforded by intelligent use of command lines and other ways of accelerating your interaction with the computer and bending computers to do your bidding. Stop working so hard for your computer!Building DSLs in Static and Dynamic Languages
This session discusses building Domain Specific Languages and DSL-style code in Java, Groovy, and Ruby. It discusses the different types of DSLs, details on how to implement them in Java, Groovy, and Ruby, and example problem domains where DSLs make sense.Test Driven Design
Most developers think that "TDD" stands for Test-driven Development. But it really should stand for "Test-driven Design". Rigorously using TDD makes your code much better in multiple ways.Meta-programming JRuby for Fun & Profit
Ruby is the revenge of the Smalltalkers. Not since Smalltalk has a language had such powerful meta-programming facilities. While this may seem like a minor feature, it turns out that surgical meta-programming allows solutions to problems that are clearer, more concise, more maintainable, and take orders of magnitudes fewer lines of code.The Productive Programmer: Practice (10 Ways to Improve Your Code)
No one writes perfect code: even the best developers fall into bad habits and traps. These topics from The Productive Programmer illustrate blind spots and helps you write better code."Design Patterns" in Dynamic Languages
The Gang of Four book should have been entitled "Palliatives for Statically Typed Languages", because the recipes it provides are cumbersome solutions to the problems it poses. Using powerful languages makes the solutions in the GoF book look hopelessly complicated. This session shows how to solve the same problems concisely, elegantly, and with far fewer lines of code using the facilities of dynamic languages.Code Metrics & Analysis for Agile Projects
What does code + methodology have to do with one another? Everything! Agile projects focus on delivering working code, and tools exist to allow you to verify some quality metrics for your code. This session is a survey of tools and metrics that allow you to determine the quality of your code and strategies to "wire it" into your agile project.Pragmatic Extreme Programming
This session talks about how to actually get XP done in the real world (and what to tell your boss).Evolutionary SOA
This session demonstrates that "Agility" and "SOA" complement each other quite well. Just because SOA is buzz-word compliant doesn't mean that you should throw good practices out the window. This session demonstrates how you can apply the principles of agility to building highly complex distributed enterprises.Regular Expressions in Java
Regular expressions should be an integral part of every developer?s toolbox, but most don?t realize what an important topic it is. Regular expressions have existed for decades, but many developers don't understand how to take full advantage of this powerful mechanism, either through command line tools and editors or in their development.Keynote: Ancient Philosophers & Blowhard Jamborees
It turns out that ancient philosophers knew a lot about software -- did you know that Plato defined object-oriented programming? This keynote applies old lessons to new problems and old problems to new lessons. It describes why SOA is so hard, and why people in your company make bone-headed decisions. What other keynote includes Rube Goldberg, Aristotle, Dave Thomas, and Chindia?Agile Project Management (With Just a Bit About Mingle)
You can read books about Agile projects, but you must consult real-world experience to really understand the dynamics of agile project management. This session discusses agile management topics including estimation, project tracking, and useful metrics (and how to obtain them). And just a little about Mingle, the agile project tracking tool from ThoughtWorks.Productive Programmer: Acceleration & Automation
Developers from the 1980s would be shocked at how inefficiently developers use their computers because of the advent of graphical operating systems. This talk describes how to reclaim productivity afforded by intelligent use of command lines and other ways of accelerating your interaction with the computer and bending computers to do your bidding. Stop working so hard for your computer!Rails for JRuby
This session explains all the hype surrounding Ruby on Rails, in a context familiar to Java developers. It covers convention over configuration, ActiveRecord, controllers, views, Ajax, scaffolding, testing, and deployment...on the JVM, using JRuby.Books by Neal Ford
by Neal Ford
-
A guide to the topics required for state of the art web development, this book covers wide-ranging topics, including a variety of web development frameworks and best practices. Beginning with coverage of the history of the architecture of web applications, highlighting the uses of the standard web API to create applications with increasingly sophisticated architectures, developers are led through a discussion on the development of industry accepted best practices for architecture.
Described is the history and evolution towards this architecture and the reasons that it is superior to previous efforts. Also provided is an overview of the most popular web application frameworks, covering their architecture and use. Numerous frameworks exist, but trying to evaluate them is difficult because their documentation stresses their advantages but hides their deficiencies. Here, the same application is built in six different frameworks, providing a way to perform an informed comparison. Also provided is an evaluation of the pros and cons of each framework to assist in making a decision or evaluating a framework on your own. Finally, best practices are covered, including sophisticated user interface techniques, intelligent caching and resource management, performance tuning, debugging, testing, and Web services. - Available At: http://www.amazon.com/exec/obidos/tg/detail/-/1932394060/qid..
Meme Agora
Wednesday, July 16, 2008
OK, it's finally here. I got my copy of The Productive Programmer in the mail last week, and today Amazon updated it's status to "In stock". For all those who have been patiently awaiting this book, it's finally here. Finally! The first glimmer of this book started in 2005(!), so it's taken upwards of 3 years to convert what David Bock and I were talking about into actual tree-ware. Because it took so long to produce, I suggest that, if you are going to buy one, you should go ahead and buy 2, in case you lose one. And, of course, nothing says loving to your spouse like an O'Reilly book. A great gift for anniversaries, birthdays, bar mitzvah's, etc. Even if you don't buy the book (and can ignore my bitter tears) and you still have an interest in developer productivity, you can head over to the Productive Programmer wiki and contribute.
Thursday, July 10, 2008
Back in January of 2007, I wrote about my impressions of the Good, the Bad, and the Ugly of the Sony eReader electronic book reader. I thought I���d update that, given my time with the device and the eBook service. And the news isn���t good.
One of the major annoyances of the eReader is the inability to reflow PDFs. That���s a complex problem, so they get a pass on the actual reflowing part. The solution they offered was the ability to view PDFs in either of two formats: either the entire page or just the width of the text on the page. The latter worked reasonably well for most PDFs when viewed in the landscape mode of the eReader. But here���s the fatal bug: when you switch pages in the PDF view, it restores the ���width of text��� view to the ���width of page��� view, but doesn���t update the mode on the reader. Thus, you must hit the button to actually get it back to what it thinks is officially ���width of page��� view, then hit it again to actually get back to ���width of text��� mode. Page refreshes on the eReader are very slow, which isn���t a big deal when reading a book because you only have to do it occasionally. But forcing the multiple page switches just to restore it to the mode it says it���s on is deadly. It effectively made reading PDFs on the device unpalatable. I reported this back in my original review, and predicted that it would be fixed in a software update (leaving aside for the moment how the device could have ever shipped with such an obvious bug).
It never happened. The new version of the reader came out with no software update in sight for this killer bug. I don���t know if they���ve fixed it in the new version because, frankly, I wouldn���t take one if they gave it to me. They did offer to sell me a new one when my original died. I turned it on one day in December and the screen was a garbled mess. I contacted their support who told me that, since mine was out of warranty, my best course of action was to purchase another, new version. That���s never going to happen.
In fact, the whole experience has soured me on Sony. They used to compete in mind share at least with Apple for delivering innovative products, with a modicum of understanding things like design and aesthetics. Apparently, they���ve abandoned that. I still own a single Sony product, the PSP Portable, which embodies many good features and design touches. But seeing how they treat their customers for an admittedly small, trivial market is enough for me to cast all their products in doubt. They clearly don���t have any concept of quality assurance (given the original bug) or responsibility (never fixing it). It���s a shame too because reading actual eBooks on the reader wasn���t bad. I probably read about 40 books on it, and liked it a lot. But, given that you can���t read PDFs on it, and their eBook format is proprietary (another annoying characteristic about Sony ��� memory sticks anyone?), I won���t buy another one.
I���ve looked at the Kindle but haven���t taken the plunge yet. I want a killer user experience, and it doesn���t look like it. I wish Apple (or someone who understands design like Apple) would release an eReader so I could read the Neal Stephenson Baroque Trilogy without herniating myself!
One of the major annoyances of the eReader is the inability to reflow PDFs. That���s a complex problem, so they get a pass on the actual reflowing part. The solution they offered was the ability to view PDFs in either of two formats: either the entire page or just the width of the text on the page. The latter worked reasonably well for most PDFs when viewed in the landscape mode of the eReader. But here���s the fatal bug: when you switch pages in the PDF view, it restores the ���width of text��� view to the ���width of page��� view, but doesn���t update the mode on the reader. Thus, you must hit the button to actually get it back to what it thinks is officially ���width of page��� view, then hit it again to actually get back to ���width of text��� mode. Page refreshes on the eReader are very slow, which isn���t a big deal when reading a book because you only have to do it occasionally. But forcing the multiple page switches just to restore it to the mode it says it���s on is deadly. It effectively made reading PDFs on the device unpalatable. I reported this back in my original review, and predicted that it would be fixed in a software update (leaving aside for the moment how the device could have ever shipped with such an obvious bug).
It never happened. The new version of the reader came out with no software update in sight for this killer bug. I don���t know if they���ve fixed it in the new version because, frankly, I wouldn���t take one if they gave it to me. They did offer to sell me a new one when my original died. I turned it on one day in December and the screen was a garbled mess. I contacted their support who told me that, since mine was out of warranty, my best course of action was to purchase another, new version. That���s never going to happen.
In fact, the whole experience has soured me on Sony. They used to compete in mind share at least with Apple for delivering innovative products, with a modicum of understanding things like design and aesthetics. Apparently, they���ve abandoned that. I still own a single Sony product, the PSP Portable, which embodies many good features and design touches. But seeing how they treat their customers for an admittedly small, trivial market is enough for me to cast all their products in doubt. They clearly don���t have any concept of quality assurance (given the original bug) or responsibility (never fixing it). It���s a shame too because reading actual eBooks on the reader wasn���t bad. I probably read about 40 books on it, and liked it a lot. But, given that you can���t read PDFs on it, and their eBook format is proprietary (another annoying characteristic about Sony ��� memory sticks anyone?), I won���t buy another one.
I���ve looked at the Kindle but haven���t taken the plunge yet. I want a killer user experience, and it doesn���t look like it. I wish Apple (or someone who understands design like Apple) would release an eReader so I could read the Neal Stephenson Baroque Trilogy without herniating myself!
Tuesday, July 1, 2008
Last weekend, I spoke at the Agile Experience in Reston. It was a great conference, lots of interesting topics, and a different crowd than most technical conferences. Half the attendees were managers, and everyone was enthused about Agile development. The experience level with Agile was diverse too, so it was fun to get out-of-the-blue questions. My first talk was Real-World Agile, and I start that talk by soliciting the agenda from the crowd (I open up a text editor and make the group tell me what they want to talk about). That was great here because it let me understand the actual pain points for the attendees, and it makes for a more interesting presentation for me.
On Friday night, we had a wide-ranging expert panel discussion which ranged from methodology to soft skills to cultural fit. And it was recorded. Come hear me stereotype all Americans as assholes!
On Friday night, we had a wide-ranging expert panel discussion which ranged from methodology to soft skills to cultural fit. And it was recorded. Come hear me stereotype all Americans as assholes!
Friday, June 27, 2008
I noticed the other day that lots of states now ban talking on cell phones while driving, yet they don���t outlaw talking to a person sitting on the seat next to you. Why is that? I have a suspicion: talking to someone on a cell phone takes a lot more concentration. Many studies place accident rates for drunk drivers and cell-phone talkers evenly. The implication is that talking on your cell phone robs you of as much concentration as drinking!
But my experience with software development bears this out. I���ve worked on several geographically diverse projects, where the communication channel is reduced to phone calls in conference rooms. This is a terrible communication medium because you can���t see the other people, can���t see their facial expressions and body language, and don���t understand the subtleties of their vocal inflections. Humans are social animals (even developers who don���t interact well with other humanoids). We don���t realize how much we rely on those non-verbal communication channels until we notice how much concentration it takes to talk on a cell phone in a car.
Alistair Cockburn has a great diagram in his book Agile Software Development.
He has modeled communication effectiveness to temperature dispersal from a heating source. The further away from the source, the colder you are. This is a great metaphor because it takes into account the subtle communication channels upon which we depend but don���t realize are there until they���re not.
The importance of this for software development shouldn���t be ignored. If you engage in distributed development, insist on warmer communications, like video conferencing. Even Skype video, while crude sometimes, beats the phone-call-in-crowded-conference-room anti-pattern. On one of my projects, we had serious cross-ocean communication gaps because we���d never met in person. The results aren���t surprising: personality clashes, misunderstanding about technical problem resolution that cost us time, and general stand-offishness between the teams. Wisely, my project manager invoked the XP ���Move people around��� principle, and we shuffled developers from the US to India and vice-versa, for a couple of iterations each. This was on a fixed-bid project, so we incurred the cost for the travel ourselves. And it was the best thing that ever happened to the project. Once you���ve met people and spent time with them, it makes even conference call communication better, because you can pick up on subtle clues in people���s voices that indicate a facial expression you���ve seen for yourself. One of the developers on our US team was widely loathed by the developers in India (so much so that, when I went there, they had drawn an ���X��� over his face in the team photo we had on the wall!). But, when he went there himself, he became fast friends with many of the developers. Some personalities must be experienced in person before they are tolerable, especially to different cultures.
So, the next time you are driving and talking on your cell phone, do 2 things: keep an eye out for the police in your rear view mirror, and notice how much more mental energy it takes to talk on the phone rather than to a person sitting with you. This to me is the proof that Cockburn nailed it.
Tuesday, June 17, 2008
I have a cool job. The opportunity to travel to interesting places is one of the coolest parts. Recently, I had the chance to go for the first time to Seoul, Korea, speaking at the Entrue Developers Conference.The conference was very well organized, but it was a conference like any other. The interesting things for me were the observations I made while I was there.
First up, phones and Internet. I proudly carry an iPhone (one of the first purchasers, don't you know), and smugly rub it in the face of all the poor phone 1.0 owners. In Korea, their cell network is far more advanced than ours. So advanced, in fact, that they aren't even backwards compatible with our phones. None of my other co-worker's phones worked either, except the one that had a special phone for Korea. The other notable technology difference was the speed of the Internet connections. The Internet in my hotel room was one of the fastest I've ever used! Stuff that takes 45 minutes to download here takes 7 minutes in Seoul. Unfortunately, I didn't actually measure the speed, but it was blindingly fast. And that was just my hotel room connection!
Second, business in Seoul is much more formal than here. Before travelling there, I asked my co-worker from China meeting me there about the dress code. I try to remember to do that when I travel so that I minimize the ugly Americaness that leaks through anyway. He said "Oh, don't worry -- it's business casual. Slacks and button up shirt is fine." Well, I get there, and I'm the only one there without a suit. One of the nice things our host did for us was an invitation for a lunch with about 200 corporate CIO's in Seoul. My co-worker (the same one who advised me) leaned over and said "See that guy over there -- he isn't wearing a suit, so you aren't the only one." Thanks! In general, business is much more formal. Developers wear suits and ties to work, which is increasingly rare here.
Third, I was asked to give a presentation at one of the local companies, to their enterprise architecture group (SOA is big in Korea). The only snag: they don't speak english, and I don't speak Korean. The local guy there who invited me to speak at the conference volunteered to translate for me. This was a first: I would discuss the contents of a slide or example, then pause while he translated the entire thing to Korean. He was extremely knowlegable about technology, so I have high confidence in his translation. It was just weird: speak, pause, speak, pause...for almost 2 hours!
Fourth, they have different technology priorities there. While a lot of big companies in the US have embraced the run-away accidental complexity that is SOA, they have taken it to a manaical level. We sat through a presentation of an SOA Goverance Framework. They have every detail nailed down to the tiniest degree. It looked great on paper, but it was absolutely unworkable in the real world. Can you really tell the business that they must slow down their pace of innovation because the SOA goverance framework keeps all IT at a snail's pace? Developers spend more time filling out forms and consulting the thousands of pages of documentation on how to govern their SOA than they do actually writing code. I asked during the presentation how this impacts the business and got blank stares: business? What does the business have to do with our enterprise architecture? It was the most elaborate, meticulous, detailed, unworkable framework I've ever seen.
My fifth observation is the dichotomy of their IT priorities. On the one hand, they've embraced SOA (particulary the bad parts, in my opinion) whole-heartedly. The important priorities for their enterprise development seems to be to lock down all variability (and therefore flexibility, evolvability, and adaptability) from their enterprises. They have state of the art SOA fetish there, building meta-SOA frameworks. Yet, you ask them about some of the things considered interesting in the states (like the rise of dynamic languages), it's not even on their radar. It's not that they have looked at it and disregarded it. They haven't even heard of most dynamic languages. Ruby? Groovy? Python? The only one they've even heard of is Perl, and they have a poisionous disdain for it. They have of course heard of JavaScript, but it's a toy language for visual effects in browsers. They treat it like an extension of CSS.
Of course, the best part of traveling is the people: I met so many friendly, gregarious, funny, open people there. We had several great meals, lubricated either by fine wine or Soju, the Korean version of Sake. It's wonderful stuff: it tastes like mild Sake, but it packs almost the punch of vodka. We talked about lots of stuff, both technical and non-technical. The last speaker's dinner had geeks from Korea, the US, China, Japan, Singapore, Malyasia, and lots of other places. Travel does indeed broaden you, often in unexpected ways.
First up, phones and Internet. I proudly carry an iPhone (one of the first purchasers, don't you know), and smugly rub it in the face of all the poor phone 1.0 owners. In Korea, their cell network is far more advanced than ours. So advanced, in fact, that they aren't even backwards compatible with our phones. None of my other co-worker's phones worked either, except the one that had a special phone for Korea. The other notable technology difference was the speed of the Internet connections. The Internet in my hotel room was one of the fastest I've ever used! Stuff that takes 45 minutes to download here takes 7 minutes in Seoul. Unfortunately, I didn't actually measure the speed, but it was blindingly fast. And that was just my hotel room connection!
Second, business in Seoul is much more formal than here. Before travelling there, I asked my co-worker from China meeting me there about the dress code. I try to remember to do that when I travel so that I minimize the ugly Americaness that leaks through anyway. He said "Oh, don't worry -- it's business casual. Slacks and button up shirt is fine." Well, I get there, and I'm the only one there without a suit. One of the nice things our host did for us was an invitation for a lunch with about 200 corporate CIO's in Seoul. My co-worker (the same one who advised me) leaned over and said "See that guy over there -- he isn't wearing a suit, so you aren't the only one." Thanks! In general, business is much more formal. Developers wear suits and ties to work, which is increasingly rare here.
Third, I was asked to give a presentation at one of the local companies, to their enterprise architecture group (SOA is big in Korea). The only snag: they don't speak english, and I don't speak Korean. The local guy there who invited me to speak at the conference volunteered to translate for me. This was a first: I would discuss the contents of a slide or example, then pause while he translated the entire thing to Korean. He was extremely knowlegable about technology, so I have high confidence in his translation. It was just weird: speak, pause, speak, pause...for almost 2 hours!
Fourth, they have different technology priorities there. While a lot of big companies in the US have embraced the run-away accidental complexity that is SOA, they have taken it to a manaical level. We sat through a presentation of an SOA Goverance Framework. They have every detail nailed down to the tiniest degree. It looked great on paper, but it was absolutely unworkable in the real world. Can you really tell the business that they must slow down their pace of innovation because the SOA goverance framework keeps all IT at a snail's pace? Developers spend more time filling out forms and consulting the thousands of pages of documentation on how to govern their SOA than they do actually writing code. I asked during the presentation how this impacts the business and got blank stares: business? What does the business have to do with our enterprise architecture? It was the most elaborate, meticulous, detailed, unworkable framework I've ever seen.
My fifth observation is the dichotomy of their IT priorities. On the one hand, they've embraced SOA (particulary the bad parts, in my opinion) whole-heartedly. The important priorities for their enterprise development seems to be to lock down all variability (and therefore flexibility, evolvability, and adaptability) from their enterprises. They have state of the art SOA fetish there, building meta-SOA frameworks. Yet, you ask them about some of the things considered interesting in the states (like the rise of dynamic languages), it's not even on their radar. It's not that they have looked at it and disregarded it. They haven't even heard of most dynamic languages. Ruby? Groovy? Python? The only one they've even heard of is Perl, and they have a poisionous disdain for it. They have of course heard of JavaScript, but it's a toy language for visual effects in browsers. They treat it like an extension of CSS.Of course, the best part of traveling is the people: I met so many friendly, gregarious, funny, open people there. We had several great meals, lubricated either by fine wine or Soju, the Korean version of Sake. It's wonderful stuff: it tastes like mild Sake, but it packs almost the punch of vodka. We talked about lots of stuff, both technical and non-technical. The last speaker's dinner had geeks from Korea, the US, China, Japan, Singapore, Malyasia, and lots of other places. Travel does indeed broaden you, often in unexpected ways.
