Subakva Teknika

Book Review: HTML5 Cookbook by Christopher Schmitt, Kyle Simpson

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.

Book Review: A Bug Hunter’s Diary by Tobias Klein; O’Reilly Media

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.

Book Review: Test-Driven Infrastructure with Chef by Stephen Nelson-Smith; O’Reilly Media

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

Temporarily Change the Rails Environment

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.

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

Only in Python…

I just imported code from the future. That famous XKCD comic is a lot closer to reality than you might have thought.

Clone My Fields, Please

The Introduction

I recently started using the SearchManager from the Mercury Tide white paper on using MySQL full-text search with Django. It’s been helpful, but I ran into a bug recently while trying to add a default filter to a SearchManager subclass.

The Boring Context

Rather than deleting objects from the database, my application sets a boolean flag to indicate that the content is not longer relevant. I wanted my manager to apply a filter to every query set to include only items that are not disabled. Here’s what the manager class looks like:

class SearchableItemManager(SearchMangager):
    def __init__(self):
        zuper = super(SearchableItemManager, self)
        zuper.__init__(('name','description',))

    def get_query_set(self):
        query = super(SearchableItemManager, self).get_query_set()
        return query.filter(is_enabled=True)

The Ugly Crash

When I made the change, I found that calling the search() method raised a TypeError: “‘NoneType’ object is not iterable.” The error occurred when the SearchQuerySet tried to construct the SQL for the MATCH…AGAINST clause. Somehow, the _search_fields tuple on the SearchQuerySet was None.

The Mystery Solved

This had me baffled until I had a look at the _QuerySet code in Django. It seems obvious now, but adding an additional filter to a query set returns a clone of the original with the new filter added. The _QuerySet object contains a _clone method that copies a hard-coded list of fields from the old QS to the new one. Naturally, that hard-coded list doesn’t know anything about my _search_fields, so the property has no value on the clone.

The Fix

Now, depending on how much of a zealot you are about modifying “private” functions, there are two ways to fix this. The easiest method is to simply override the _clone method and add the _search_fields tuple to the clone. The alternative is to override every method that depends on the _clone method, and copy over the _search_fields tuple for each one. I think that would be stupid, and will speak of it no further. Here’s the code I added to generate happiness:

class SearchQuerySet(models.query.QuerySet):
    # ... code from the original Mercury Tide class
    def _clone(self, klass=None, **kwargs):
        zuper = super(SearchQuerySet, self)
        clone = zuper._clone(klass, **kwargs)
        clone._search_fields = self._search_fields
        return clone