With the first version of Ruby 2.0 comes many of the much anticipated and sought after improvements and refinements. Also included is a feature called refinements that is basically like controlled monkey-patching.
To get started with Ruby 2.0:
rvm install ruby-2.0.0-p0Then in your rails project directory:
gem install bundler —preThen to get going with your gems:
bundle install
The most likely animals to be left alive after a nuclear war are cockroaches, because they’re so hard to kill. Instead of a beautiful but fragile flower that needs to have its stem in a plastic tube to support itself, [startups better] be small, ugly, and indestructible.
The word diet usually is taken to mean a change in food consumption that is undertaken to cause change in weight. “His diet did not work as she craved cake.”
However, when diet is used in the conventional (sciencey) sense means the sum total of the food and food-like products that one consumes. “Her diet consists of meat, nuts, fruit and vegetables.”
I have been experimenting with different combinations of food over the past year and have found many correlations between diet and mood. I have experienced the ups and downs of grains, the need for coffee as well as the complete liberation from the post-meal itus.
The feeling that a hot breakfast (eggs/bacon), leftover centric lunch and a dinner made from high quality ingredients has this intangible benefit that pervades nearly every aspect of life.
Keeping your application readable, extensible and simple ensures that the engineers working on a project can maintain an effective grasp on the complexity. However I often see that complexity is managed by doing important and complex things enclosed in a monolith classes/methods. When those classes implement functionality that executes on an asynchronous queue, it can be dangerous.
Your app won’t catch fire on the basis of monolith classes or methods, but it does tend to cause more harm then good. You never know when someone will use one of those classes as a template for others, mistakenly adhering to patterns that are not well formed.
To ensure that this situation doesn’t arise in your application, worker classes should be simple, transactional, idempotent, and concise. Simplicity will help you manage the complexity by separating out concerns.
Transactional makes sure that you won’t create inconsistent state when running this work. Idempotent means that when failures and subsequent retries happen (and believe me they happen), you ensure that the action only happens once. Writing concisely (in any context) helps document the exact functionality you care about, and in the case of workers, help the developer split multi-stage tasks into multi-step processes.
A prime example of this is when updating content from a social network, and some data (invariably) is either not found or not available at the time requested. Based on the error that was generated, one can assume that the content was destroyed or otherwise removed from the network. At the point. To handle these errors, you decide to remove them from your datastore. Two options are:
1. Handle the error, and subsequent verification in the update worker.
2. Delegate the work to another worker class that verifies the posts’ status and acts on it accordingly.
Choosing option 1 mixes concerns and unnecessarily couples two pieces of functionality. The obvious benefit is that the number of workers that run is still the same as before this problem was identified. On the other hand, option 2 leads to a more generic set of workers who only need to care about a very specific behavior set.
Different use cases often call for creative implementation, but in the case of worker classes, maintaining separation of concerns at the cost of a few extra messages hitting the queue has great benefit.
When developing a new Rails app you have to consider how you will do some of the admin work that cames along with the new application. I’m talking about sending welcome email, fetching user information from social networks and generally doing things that don’t need to block the user experience. This is called message processing (to distance myself from the term background processing).
Enter the classic background queue, a separate instance of your app that has to be started, re-started and maintained as if it were another web-server instance of your app. You now have at least two application instances to maintain and to verify, and all just for email…
If the idea of scale weren’t so pervasive, developers might opt for something simple and easy instead of the thing that they’ll need in 6 months. Let me be the first to tell you to hold off on the thing that scales until you need it.
If message processing is the goal, then drop the message on a queue and forget about it.
This is where I tell you about a new way to process messages. Maintain a set of threads on each of the processes that run your application. Its that simple. You start your messaging processing system from code. The simplicity of this concept is what makes it so powerful. Let me reiterate - you configure, start, enqueue, and perform messages all from the context of the same process. You effectively harness the extra cpu time that your web-server has to process the messages created by that application instance.
Think first of asynchronous and not of background.
This idea in code: http://github.com/bnorton/micro_q
When considering the type of developer experience that you want to have, you must consider three main things.
I want to mainly focus on the third item - it has the most profound impact.
There are only two forms of testing, automatic and manual - period, that’s it, only two - you either run tests via a testing framework or you run tests in the browser/console by hand. One is repeatable and the other is based on feature context.
In the case that you verify manually you are leaving the guarantee of functionality (present/future) in the hands of the people who know what the application should be able to do. Enter the QA team (or the developer) - who are charged with making sure that the application functionality is still available. They are the gate-keepers of the release.
In the case that your verification is automatic the guarantee of functionality and documentation lies within the tests and in turn the code. Others can make changes simplify, refactor, and extend knowing that if you break things a test will fail. You are the gate-keeper of the release.
The freedom this gives you as a developer is phenomenal. This is what you stand to gain.
The end result of all physical engineering endeavors is a product that can then be used without major modification for it’s entire life. If the product was good at the beginning then it is good near the end. The process that produces finished products is known as waterfall. The main challenge of engineering the physical world is that you cannot (easily) update the components which has entered the marketplace.
There are no partially completed bridges or buildings that we deem safe for transit or occupancy. The field of physical engineering it is all or nothing.
You wouldn’t use an alpha stage bridge, but you would use alpha software.
The realm of software is fundamentally different. The software can be a mere shell and still it will satisfy a customer need. It does not need to be complete nor fully functional to improve the efficiency and happiness of its users. Future improvements to the user experience will be immediately available to current customers and offer selling points for potential customers. “We have 10K new users per/month” is more convincing that all the slide decks and take aways’ combined. It seems that tangibility in an intangible world is paramount.
The fact is that more people care about traction than features, because traction indicates features but the promise of features indicate nothing.
When you give someone a product they will eventually know how it all works and become bored; when you give someone a minimal product and expand the functionality over time, the user is more likely to feel satisfied with the product. In the field of software engineering, agility is king.
True agility is a release early, release often - test-driven - product centric approach that promotes user experience, engineer happiness and doesn’t introduce premature optimizations. True agility disregards all things the don’t provide immediate business value.
People are impatient and will not wait for the promise of future implementation. Your customers only care about how your product improves their lives now.
As an engineer in a waterfall world - stick to the simplest thing and steer clear of premature optimizations.
A redwood grove on campus is a welcome study location (Taken with Instagram at Redwood grove)
