Federal Reserve Bank of Boston (Taken with instagram)

Summary

HTML5 Cookbook provides an overview and examples of new HTML 5 features and related JavaScript APIs. The cookbook series aims to provide short, targeted chapters that solve real world problems, and for simple use-cases, this book provides that.

Most of the material in the book could be found in online tutorials, but it provides a good overview of the available technologies in a single place. I wouldn’t recommend this for developers who are already using/familiar with HTML 5, but it could be a great foundation for newbies who want to absorb a lot quickly. Personally, I felt that I had a solid foundation to start working with HTML 5 technologies after reading through the examples.

In a Nutshell:

• Good compilation of intro material for HTML 5 and friends.

• Filled with useful internet references.

• Recipes are rather basic, but complete and well-written.

• Great coverage of accessibility issues.

• Probably less useful once the basics are understood.

Summary

A Bug Hunter’s Diary describes the technical details of how the author identified and analyzed software security bugs. It doesn’t get into exploiting the bugs because, as the author points out at the end of every chapter, it’s illegal to publish exploits in Germany.

I expected a light treatment based on the cute title and cover, but it was mostly C code, debuggers and assembly. I was a little out of my element, but it was interesting. The appendices explaining how stack overflows, etc. can occur and how they can be exploited (roughly) were helpful and interesting. The bug diaries were a little repetitive, but they at least covered a range of platforms.

Other Notes

The book is lacking one major piece of the puzzle: details on exploiting these security bugs. After all the work understanding the bug and the details, it was always a bit of a letdown when their was no working exploit as a payoff. According to the author, his home country, Germany, passed a law making it illegal to publish exploits for bugs. Given the ease of finding that information on the internet, I’d guess that the single major effect of that law is to make this book less useful, which is a real shame.

In addition to the technical details, the author outlines the process of reporting and resolving bugs. It was interesting to see that commercial software vendors seem to be consistently orders of magnitude slower in releasing patches for security issues. I suppose one could argue that means that open-source software is safer, but at the end of the day, it’s always up to the end user to keep their software updated and patched.

Bottom Line

You’ll need some understanding of assembly, c, and how memory allocation works. But that background, the book and a bit of Googling to learn more about how the exploits work make for a solid, entertaining overview of the life cycle of security bugs.

Summary

Test-Driven Infrastructure with Chef describes a rationale and an approach to developing automated tests for system infrastructure. It includes an explanation of behavior-driven development, and detailed instructions for setting up a testing system using cucumber-chef on EC2.

Audience

Surprisingly little time was spent talking about cucumber-chef and how to use it. The majority of the book is spent explaining BDD and why you’d want to apply it to infrastructure, and then explaining in minute detail the process to get RVM, EC2 and Chef configured. The last portion of the book covered the process of using cucumber-chef to set up a server with multiple user accounts.

Being already familiar with the supporting tools, I found this disappointing. The teamserver example was too simple and unrealistic. It would have been more useful to see some examples using cucumber-chef for a more realistic use-case, such as setting up a web server.

Unfortunately, I suspect the text isn’t likely to be helpful to a reader who isn’t familiar with the tools either. The instructions were already outdated when I read them, shortly after the book was released. A reader who is new to Cucumber, Chef, Ruby or EC2 will be in danger of getting lost before they even get to the point where they can run a test against an instance.

Practicality

In the course of working through the examples, I was continually frustrated by the amount of time it took to get feedback. The tests are really slow. It’s hard to imagine actually developing red/green/refactor-style at this pace. I like the concept of being able to test the infrastructure, but it doesn’t seem practical with these tools.

I’m not convinced that it would really be worth the time involved to write tests at this level anyway. Writing integration tests against the full application stack might be a better use of your testing time. The true test of the infrastructure is how well it supports needs of the application and it’s users.

Neither BDD-style infrastructure tests nor full-stack integration tests will help you with the most difficult and interesting infrastructure challenges: scaling and stability. Simulating all the wonderful ways that a server can crash (used up disk space, hung connections, etc.) would be a complex, difficult, slow, and inevitably incomplete endeavor. It’s possible that server ops really is fundamentally different than application development.

Bottom Line

• Good explanation of BDD and how it could be applied to infrastructure

• Short on useful examples for readers familiar with the supporting tools

• Thorough instructions for setting up EC2, Chef and RVM, but likely to have a short shelf-life

Available from O’Reilly: Test-Driven Infrastructure with Chef

The Mother of All Interview Questions - raganwald’s posterous

“Does your process involve invention? … ” This is a great interview question. It’s a conversation starter, and it’s both relevant to evaluating a candidate and, hopefully, an interesting question for the interviewee to consider.

Making applications scalable with Load Balancing

Old but useful article about load balancing issues by the author of HAProxy

Jay Fields’ Thoughts: The High-Level Test Whisperer)

Two key takeaways from this post:

• Sometimes it’s better to clobber an unmaintainable test suite and start over with something simple and focused on maximizing value.

• Maintenance of high-level tests might be a sensible place to break from the shared code-ownership principle.

A helper method to change the Rails environment within a block. I use this for testing isolated, environment-specific methods. Obviously, I wouldn’t suggest using this outside of test code. You could easily do something very stupid.

<code>
def with_rails_env(environment, &block)
  begin
    original_env = Rails.env
    Rails.instance_variable_set(:@_env, environment)
    yield if block_given?
  ensure
    Rails.instance_variable_set(:@_env, original_env)
  end
end
</code>

Shady Characters - The secret life of punctuation

Proving once again the breadth of my geekdom, I’m really enjoying this blog about the history of punctuation.

Whenever I create join tables, I’m always tempted to add an ID column, in case I want to upgrade it to a :through association at some point. I’m also tempted to timestamp columns, so that I can know when the association was created.

Sadly, it just doesn’t work with has_and_belongs_to_many.

• If you add an ID column, Rails will choke as soon as you try to access it. IDs are not allowed!

• If you add timestamps, Rails will make all of your association records readonly.

If you want to have an ID and timestamps, you’ll just have to bite the bullet and create an association model and a has_many :through relationship.

Maybe now that I’ve written about it, I’ll remember it next time and save myself debugging mysterious "ActiveRecord::ReadOnlyRecord: ActiveRecord::ReadOnlyRecord" errors.