Monthly Archives: August 2013

Nice presentation for refactoring and agile development. Many of the topics may have been discussed in somewhere, but this type of passionate and insightful presentation works well.

Refactoring or any types of refinements involves certain efforts. As discussed in the presentation, small iterative steps of code improvement would be required, rather than a large “refactoring” which can be taken as “throwing away” the chunk of codes without adding new features.

Good programmers follow decent habits on a daily basis. It’s not about the fancy techniques or “clever” codes. Simple and clean designs are good for any kinds of artifacts. Software, hardware, documents and any kind of them requires artistic sense for refining them. Especially, software development is often described as an art, and simple and beautiful codes are advocated. An artifact becomes complete when nothing can be taken further out of it. It’s not when everything is added. Redundancy or duplication can ruin its beauty.

Notes

Agile: Code quality matters, in order to be agile, and in order to quickly respond to the change.

Clever Code: Don’t write a clever code. It causes troubles. Make the code simple and clear. Your code should do just one thing well. One important indicator is having the single level of abstraction in one method.

Dependency: Remove dependency before trying to invert the dependency, etc. Instead of mocking, knockout the dependency.

Comments: Good code is self documenting. Try to avoid using comments. Commenting is redundant and it’s like explaining a joke. Working tests (examples) worth 1000 comments.

Code Smell: One good metaphor of “code-smell is evil” is coming from the physical smell. After certain time, you can easily get accustomed to it, and becomes unable to feel it anymore.

An introduction for event-based programming in ruby. It’s mainly about EventMachine, but it nicely describes the behaviors of event-based model, about where or when I/O blocking is happening. Also, it talks about the importance of hiding the complexity of process-handling from the usage interface. For example, faraday http library can switch its handler to EventMachine with the same interface.

EventMachine is a nice library, which is simple enough to program.
But, as indicated in the presentation, it would have smaller community compared with node.js one, which leads into lack of information. Also, built-in event-based paradigm in node.js enforces all the libraries works on this model. In ruby, single event-unaware component of the stack can block the process which becomes the bottleneck.

Recently, many languages and libraries are advocating on the non-blocking concurrency models. This kind of tutorials would be great to understand the backgrounds and how to use them appropriately.

It’s about refactoring. There have already been many refactoring related videos/documents, but interesting point of this presentation is the “Refactoring is Math” statement.
It iteratively follows through the small set of logical conversions to reshape the code structure.

For example, flattening the multiple layers of if/else statements and re-order them to make it easier to move around. Then, remove the duplication appeared through this process. It’s like mathematical conversions of formula.

In the refactoring process, it’s common to use unit tests to verify the original behavior is being maintained and doesn’t break anything. However, unit tests is not the perfect solution due to the nature of its lack of coverage.

Therefore, minimizing the change of each step would be important, and this kind of mathematical (logical) break-down of modification is interesting approach to reduce the risk of breaking change during the process.

This session talks about the testing in Facebook. This kind of insights-talk from the actual engineers are pretty much useful. I don’t have much experience on the mobile development, but testing framework would be crutial factor for verifying on various devices. I didn’t know the Robolectric, and it seems interesting testing library. When I played around Ruboto, slow testing was a little tough.

At facebook,

Team is structured on features, rather than platforms like android or iOS for maintaining consistency.

Basic structure of git is “master” and “stable” branches. The master is the latest, and the stable is the one test-passing is confirmed.

Own building system called BUCK is used. It supports parallel and incremental building. If you want to encourage developer to use the system, it needs to be fast, ideally instant.

There’s no testing-specific department. It works on “some people are passionate about testing and some people are passionate about database” type of roles.

There has been some buzz around RubyMotion. I wanted to learn some, but I didn’t have chance previously. Finally, I took some time looking around the framework. The 1st one in the above is an introductory presentation from the author of RubyMotion, and 2nd one is tutorial screencast from pragmatic studio. Both are nice presentation.

RubyMotion advocates the ruby’s concise and powerful programming capability and native-code performance by statically compiling the code into machine language through LLVM. I don’t know much about LLVM, but according to the official site, LLVM provides a “collection of modular and reusable compiler and toolchain technologies”. It seems to provide a byte-code which is neutral from the specific OS architecture, and also provides optimizations around it. I remember some buzz around emscripten for a while ago.

The above screencast describes a workflow to create a simple iPhone application. Though it requires certain understandings of iOS’s cocoa touch, it pretty much simplifies the basic programming workflow. Especially, ruby’s concise rake tasks assists the powerful application building process, and lowers the boundary to go over the heavy Objective-C + Xcode infrastructure, nice.

It’s a little old one, but I happened to watch it, and taking some notes here, as it was nice.

This session advocates collaborating appropriately rather than trying to be a genius. There’re definitely some geniuses around the world, but it’s fewer than you think, and many of the great works are coming from the set of collaboration work in the team. As noted in the summary (around 41:54) collaborate “early and often” are generally recommended. But, also “Pay attention to timing” is also important. Exposing a project widely at the concept stage can impose large efforts on aligning directions among members. Having working prototype or clear goal beforehand is better.

The threshold to contribute to a open-source project is pretty much lowered along with the popularity of online code-repository like GitHub. Still, small set of leaders are actually committing codes in many of the active open-source projects, but the system of ‘pull request’ is widening the gateway. This type of semi-flat network may work well on the software projects, which regularly requires certain decisions on direction of the projects. Inherent flexible nature of the software needs ‘gentle dictator’ to organize, and it may require some structure rather than ‘genius programmers’.

It talks about Kata (kind of “format” or “regime” or “style”) on programming, using the TDD-style live coding. This session follows though the typical incremental development guided by tests. The topic is to convert arabic numbers (1, 2, 3…) to roman numbers (I, II, III…). It’s concise and well structured example to present some set of practices to follow, during the development.

It covers good insights like the following (summary starts from around 37:00).

Where to start and continue: start from simplest example and let them grow guided by tests.

To recognize duplication: recognize the redundant patterns to do refactoring, but avoid over-simplification, as it reduces readability.

When to explore: if there’s some unknowns, do some experiments out of TDD style using some tools like irb, and then get back.

etc.

Sometimes it’s being said that good programmers keep following the good habits, rather than manipulating exceptional tricky skills. Acquiring the decent habits are the way to becomes an experienced programmer, and it involves sliming down rather than getting new skills. It’s more on learning the balance. Avoiding fancy extra meta-programming may be one example, which I liked being indulged into…