Recently, I decided to take quick read of the Russ Olsen’s Design Patterns in Ruby just in case the book had interesting ways of solving common problems. The book tends to digress into type safety (the lack of it) and other gizmoz that Rubyists defend and evangelize. Hence, I decided to write this article that will simply show you the code for the most important patterns. I have just covered the most elegant way these can be used. For what its worth, this is really the only reason you would want to read this book.
Having said that, I assume that you can take a judgement on when these patterns are to be used. That will truly determine whether/if it solves a problem for you. This post is just about doing it the Ruby way.
With libraries like Robotium, it has become a lot easier to unit-test Android applications. Here is a talk given by Thiyagu, Krishnaswamy Subramanian, Soundararajan and Ashwin Raghav at xconf bangalore.
We focused on some fundamental tools and some factors that can help you understand what factors to consider while building apps on the Android stack for enterprises. It feels a little outdated now with Robotium coming in. However, it covers a lot of important fundamentals.
Recently, at xconf, I had the chance to present some work that Dr.Jane and I had done in college. Its really a simple, application oriented research paper. I had a chance to present this paper at MOMM in Kuala Lumpur previously. This is more of a repeat performance. One for the books…
Recently Mark Needham and I spoke at an internal conference at ThoughtWorks on a tool that we built. When your interview process involves a coding round where the candidates are given a problem to solve and judged based on how objective and communicative the code is, it makes sense to bring code metrics into the picture. Here is how….
I believe that a white box approach to testing things is very significant. I believe in this especially since this can help you cost-effectively target ares of the application that you think are weak. Once you get some systems-thinking in place, white box testing can really replace what manual/ black box testing can do. If that statement sounds too open/radical, think again