December 13, 2009 by John Ragan
I finished Michael Nygard’s “Release It!”. Having discussed some of the anti-patterns and best practices for stability earlier, I am going to discuss capacity anti-patterns (some of them anyway – buy the book!):
- Resource Pool Contention. When the ratio of threads and resources in a pool are out of balance, the more time the threads waste in contention for the resource. On the flip side, if you have an app server farm with large database connection pools, the number of open sessions on the database server may simply overwhelm it.
- AJAX Overkill. AJAX can improve your user experience, but it does have a cost associated with it. The requests that will be hitting your server will be more frequent. Some of the automated polling that is done can overwhelm your server in high usage situations (effectively limiting capacity). The proper balance needs to be found.
- Overstaying Sessions. The java default is 30 minutes, which is often way too long (the book shows normal times for things like retail sites vs. travel sites). These unused sessions take up memory and other app server resources, limiting your capacity. Thus, you want to get rid of old sessions as soon as possible without visibly impacting your users. Your sessions should be small, only hold non-transient data, use keys instead of values where possible, and leverage soft references where supported by the language. In the end, that means more potential sessions and a capacity constraint elsewhere.
- Excessive White Space. These seem innocuous as browsers ignore extra white space in HTML, right? You are using more CPU cycles, more bandwidth, and more RAM to serve those pages up – put them on a diet.
- Data Eutropification. Your site may be zippy at first, but if you don’t have a strategy for expunging old data, you site will get slower and slower. It is certainly a bad practice to be doing data mining against the production database. Lack of partitioning as well as lack of indexes for ORM relationships can also have a big impact.
In the next post, I will follow up on the capacity best practices.
Posted in Architecture | 1 Comment »
December 8, 2009 by John Ragan
In my last blog I discussed some of the stability anti-patterns of Michael Nyguard’s excellent but tragically misnamed book “Release It!” I finished reading the patterns and best practices portion, discussed below:
- Timeouts. Traditionally a thread blocks until the resource is ready, but this can be destabilizing if the resource is never ready. Thus, a thread needs to be able to time out. A mechanism for delayed retries should also be set up.
- Circuit Breakers. The author gives an example of early real-world circuit breakers where with too many items plugged in (resulting in too much current and heat), the circuit breaker breaks the circuit instead of the house burning down. He introduces a logical circuit breaker where too many failures breaks the circuit, rejecting the next series of requests until the system is ready to try again (see the book for the actual algorithm).
- Bulkheads. A ship’s hull is divided into different watertight bulkheads so that if the hull is compromised, the failure is limited to that bulkhead as opposed to taking the entire ship down. By partitioning your system, you can confine errors to one area as opposed to taking the entire system down. These partitions can be hardware redundancy, binding certain processes to certain CPUs, segmenting different areas of business functionality to different server farms, or partitioning threads into different thread groups for different functionality. I remember how a previous company’s server would run out of threads, and there were no other threads dedicated to admin functionality to allow an admin to interact with it.
- Handshaking. By asking a component if it can take on more before asking it to perform that work, the system has a way to introduce throttling. If the component is too busy, it can tell the clients to back off until it is able to handle more requests.
I am now moving on to reading the Capacity anti-patterns and patterns and will blog on that later. Once again, I STRONGLY recommend purchasing and reading this book!
Posted in Rails | 1 Comment »
December 5, 2009 by John Ragan
I am 110 pages into Michael Nygard’s “Release It!”. I ignored this book earlier because I pictured some namby, pamby book on release best practices, but this book is absolutely fantastic and fascinating to read!
The book focuses on anti-patterns then best practices for stability then capacity in production systems (typically focusing on web commerce). After that, it delves into system level design best practices. I am currently up to stability anti-patterns.
Once again, I am tempted to list all of them, but that seems unfair to the author so I will cover only a few. I will follow-up on this post as I get further into this book (352 pages). Here are some:
- Integration Points. This is the number one point of failure as engineers code the interactions expecting the systems to always be up, and when they are not, the resulting cascading failures bring the entire system down. Making an HTTP request without a specified timeout? Not a good idea when all your threads block waiting for a request that will never return and new requests are starved. A properly structured system will expect these types of failures and handle them appropriately to protect the other layers.
- Third Party Libraries. These little block boxes of functionality are not as robust as you need them to buy, and offer not as configurable as they need to be to handle failure scenarios. This can be a huge weakness in your production system.
- Scaling Effects. Your system works well, but as you begin to scale certainly aspects of it out horizontally, the other elements are not matched appropriately and then crash. This is particularly true with shared resources.
- Unbalanced Capabilities. Your overall system has a small percentage of its resources appropriately dedicated to handling home installation for your eCommerce web-site (e.g., like Best Buy). But your marketing department commits an Attack of Self Denial by offering a free installation promotion without coordinating with production. Suddenly, the home installation component cannot handle all the requests, and the cascading failures bringing down your site which can normally handle it due to the expected models (even including Black Monday).
All in all, this book is AWESOME! I hope to play with some of the patterns and anti-patterns in Java and Ruby and report back on that also. I will follow up by discussing Stability Best Practices in my next blog.
Posted in Architecture | 2 Comments »
December 1, 2009 by John Ragan
I finally finished this book and summarized it in Evernote. As much as I would like to share those notes, it wouldn’t be fair to the author.
I read some of the comments on Amazon, with one person complaining about the book not being meaty enough for the price. I paid $4.99 to buy this as an iPhone application, supported on the Stanza engine underneath. It was definitely worth the price, and a great book to read on the iPhone given its lack of figures.
Another title of this book could have been “97 Soft Skills Every Architect Should Have” – mastery of these skills would certainly help any architecture be more successful.
The following are some of the key things that stuck out for me:
- Michael Nygard talks about how everything will ultimately fail and the need to architect accordingly. I listened to him recently on the Pragmatic Podcast, and bought his book “Release It!” last week which deals with this topic (I’ll discuss that one once I finish reading it)
- He also talks about how software architecture has ethical consequences. For example, how you do that thing which makes development easier but causes millions of users to spend more time doing their task, and the overall amount of time wasted (among other issues).
- Craig Russell talks about how “it’s all about performance” along a number of new avenues – such as developer performance, overall time for a user to accomplish their end goal, etc.
- Eric Hawthorne talks about how to “choose frameworks that play with others” – I particularly liked his utility to baggage ratio. Other authors also make points in this area.
- Dave Quick and Michael Nygard offer great advice on formally tracking risks as you would bugs, and various strategies to stretch risk out to make it more digestible
- Timothy High offers great advice on recording the rationale for your architectural design before everyone forgets why particular decisions are made.
Of course, there is a lot more content covered in the other 91 entries.
I was particularly struck by how much soft skills play in the role of an architect in ratio to technical skills. Another book I am glad to have read!
Posted in Architecture | Leave a Comment »
November 23, 2009 by John Ragan
I very recently took a new job working in an Enterprise SOA environment after having been out of this space for the last three years. Even back then, I had been working on developing an ESB product set (at webMethods), which is different than being a consumer of an ESB. For this reason, I thought it would be a good idea to read SOA for Dummies.
I needed a refresher on SOA. The book was free at Software AG’s (which acquired webMethods) website. At 100 pages, it would be a quick read. Finally, I had recently run into Jignesh Shah (one of the authors) who I had not seen in some time.
Apparently there are a lot more politics in an IT organization than I had been aware of (I have had different software jobs, but have never worked within IT). This book covers a lot of the real world politics around rolling out an SOA organization. This is not as applicable to my situation given the maturity of SOA at my new job.
A couple of points:
- Start small, preferably with a single but key project
- Align reward systems with expectations, above and below, in order to be successful
- Though written by a lot of SoftwareAG/webMethods people, this book did not seem to be particularly oriented toward webMethods
- It does not deal with SOA architectures (as it clearly states up front)
Overall, I was not the target audience for this book, but if I was looking to move my organization toward SOA, it would have been a very valuable book.
Posted in Architecture | Leave a Comment »
November 20, 2009 by John Ragan
I had previously been blogging about this book.
I like the way Steve Krug uses the analogy of Sears department store signs and clerks to web navigation and search. He also discusses how important these are to retention and giving you a sense as to where you are in a site.
Web navigation conventions are very important in making users comfortable with your site and able to navigate without thinking. He lists a number of those conventions. Good site branding plays a psychologically calming role, as well as good page naming approaches. He also explained why having that home link is so important – effectively acting as a reset button for the user when lost.
He talks about effective ways to indicate where the user is, the why of breadcrumbs, and finally why tabs, used properly (such as with Amazon), is such an effective metaphor.
He goes into great depth on the home page. Before this, I really did not appreciate all a home page is, how it differs from the rest of the site, and why it is so important to get right. There are numerous goals one is trying to accomplish with a home page, all of which must balanced. As I am currently working on refining someone’s web-site (starting with the home page), it gives me concrete criteria to judge the page against, refine, and then repeat this process until I get it right.
Finally, he kills the myth of the “typical user” and discusses increasing or decreasing good will in terms of interacting with your web site.
What I like about this book is that it gives you a more quantitative way to look at the web sites you are creating, as opposed to it “just feeling right”. Yet it does not simplify to the silliness of “only 2 clicks” – you also have to apply thought on top of the criteria.
To be honest, I struggled writing this section up because I want to convey all the notes I captured from this book, but what would be left? For more details, buy the book – it’s worth it!!!!
Posted in Usability and Design | 1 Comment »
November 18, 2009 by John Ragan
I earlier reviewed my experience thus far with this book at http://johnragan.org/2009/11/12/practices-of-an-agile-developer/. Now, I have finished reading it.
All in all, even though a lot of things weren’t new to me, I would have to recommend this book. I went through and summarized the contents in Evernote for later review, but I can’t share that with you (it would not be fair to Venkat)! However, a couple of things did stand out for me:
- Criticize Ideas, not People. Doing the opposite kills the cohesion of an Agile team in short order.
- Invest in Your Team. We used to each study and present technologies or hold recurring group brown bags – what a difference it made!
- Know When to Unlearn. Earlier I thought of the people I knew programming in C++ but still doing it as C. However, as I drove home listening to an old Pragmatic Programmer Podcast on Version Control with GIT by Travis Swicegood, I realized I had learned the GIT syntax for my GitHub account, but I was still using it as a substitute for Subversion as opposed to learning and embracing the GIT philosophy. No wonder younger developers often use newer technologies more effectively because they are not encumbered with the older ways of thinking. I have some more studying and unlearning to do it seems!
- Communicate in Code. It seems we often code as if we are balancing a house of cards. You coded a certain statement a certain way, but no one would never know why that way was important later on. I have always (well, not always) strived to comment why I did things a certain way in these gotcha situations to help the next person come along.
- Keep a Solutions Log. Why wasn’t I doing this earlier?! This summer I started summarizing all the technical books I read in Evernote, but I will still not doing this for problems and solutions (until now).
- Schedule Regular Face Time. Daily stand-up is not all that complicated, but doing it every day, at the same time, and keeping it short made a tremendous difference for previous teams I worked with.
- Review Code. I was never a fan of this due to my earlier work on an SEI Level 5 environment on the Space Shuttle’s flight control software. Lots of checklists, checking of the checklists, and so forth. Between tools like FindBugs and PMD, as well as Peer Programming, I figured that was sufficient. However, the latest research seems to show conclusively that this can really makes a huge difference. I am currently unlearning my old opinion…
There are a number of other agile approaches covered in the book, with great ways to gauge how things are going and tips for implementing. Hats off to Venkat!
Posted in Agile | 1 Comment »
November 16, 2009 by John Ragan
I write SQL queries (and joins) every once in a while, but never had to deal with such things as “left outer joins” or “full outer joins” and so forth. I always found this a little confusing and could not remember the differences after reading about them.
Today I had a crazy idea – why not actually TRY using the different queries and see what happens? Consider these tables:
Table A
| id |
common |
name |
| 1 |
a |
Name 1 |
| 2 |
b |
Name 2 |
Table B
| id |
common |
title |
| 1 |
b |
Title 1 |
| 2 |
c |
Title 2 |
Here is what I found when I do various joins of table A to table B on a common column:
- Inner Joins are the same as the regular joins you have been doing for a while. I replaced my query’s ‘join’ statement with ‘inner join’ and got the same result (as well as reading that these were the same). Note that this means that any rows from either table which do not intersect are not part of the result. The remaining joins address this.
The query: select * from table_a inner join table_b where table_a.common = table_b.common;
Inner Join A and B
| a.id |
a.common |
a.name |
b.id |
b.common |
b.title |
| 2 |
b |
Name 2 |
1 |
b |
Title 1 |
- Left Outer Joins are the same as an Inner Join of A and B, PLUS all the rows from A that did not match a row from B, with all the fields from the B side set to NULL for those rows. Think of A as being on the left side.
The query: select * from table_a left join table_b on table_a.common = table_b.common;
Left Outer Join A and B
| a.id |
a.common |
a.name |
b.id |
b.common |
b.title |
| 1 |
a |
Name 1 |
NULL |
NULL |
NULL |
| 2 |
b |
Name 2 |
1 |
b |
Title 1 |
- Right Outer Joins are the same as an Inner Join of A and B, PLUS all the rows from B that did not match a row from A, with all the fields from the A side set to NULL for those rows. Think of B as being on the right side.
The query: select * from table_a right join table_b on table_a.common = table_b.common;
Right Outer Join A and B
| a.id |
a.common |
a.name |
b.id |
b.common |
b.title |
| 2 |
b |
Name 2 |
1 |
b |
Title 1 |
| NULL |
NULL |
NULL |
2 |
c |
Title 2 |
- MySQL does not support Full Outer Joins natively (there are some work-arounds). However, it is roughly like the union of Left Outer Joins and Right Outer Joins according to what I have read. See http://www.xaprb.com/blog/2006/05/26/how-to-write-full-outer-join-in-mysql/
Full Outer Join A and B
| a.id |
a.common |
a.name |
b.id |
b.common |
b.title |
| 1 |
a |
Name 1 |
NULL |
NULL |
NULL |
| 2 |
b |
Name 2 |
1 |
b |
Title 1 |
| NULL |
NULL |
NULL |
2 |
c |
Title 2 |
Posted in Database and SQL | Leave a Comment »
November 13, 2009 by John Ragan
Posted in Linux/Unix | 1 Comment »
November 12, 2009 by John Ragan
I have been reading “Practices of an Agile Developer” by Venkat Subramaniam over a few lunches. At 200 or so pages, it is a quick read (I am 2/3 through).
The problem? I have not been learning anything new.
But is that really a problem? The book is excellent, pragmatic, and full of good tips and ways to gauge yourself. In other words, I strongly recommended it!
I was blessed with a team that really tried to incorporate a lot of agile practices. I incorporated a lot of their suggestions into how I ran the team (back when I was in management), and as much as I could into the overall Engineering Process I was leading for the company. Later at another company, I studied Scrum only to discover that I already doing 90% of its methodology.
Why? Because I had been doing what works, and Agile is really about doing what works (as opposed to what should work in theory).
My belief is that when you are leading an Agile team and agile methodology, the emotional intelligence of the manager is a key factor. Agile is really about the kind of relationship that exists between you and the team, and between team members. It takes a certain kind of sensitivity.
Within the overall team (including the manager), the other key factor is trust. It takes on a “everyone has everyone else’s back” mentality. The manager has the responsibility to foster this kind of environment (incentives and soft skills play a major factor here). The team members have a responsibility to act as team players, which is where humility, sharing, integrity and trust really come into play.
I am reading this book to help me continue to work as effectively as I can as a developer. Once I finish the book, I will blog about the points that I felt really stood out for me.
Posted in Rails | 1 Comment »
