The London Continuous Delivery meetup group had its first session of 2013 on 17 Jan. We were fortunate to be able to use the offices of [my employer] thetrainline.com in central London, and doubly fortunate to be joined by Andy Hawkins from Opscode, who ran what turned out to be a brave demo showing how Chef can work with CI tools to provision EC2 instances.
Continue reading London Continuous Delivery meetup with Opscode Chef
I have been writing technical blog posts since 2002, but decided in late 2011 to change my writing style after undertaking various web content and SEO projects for clients and seeing the effects of good (and bad) writing. After 14 months of applying my new blogging ‘rules’, I am pleased with the results: over 11,000 page impressions between December 2011 and today (January 12th, 2013), which represents significantly higher traffic than previously; monthly impressions are increasing at a higher rate, too, which suggests that the content is useful. So here are my ‘rules’ for writing a good technical blog post.
Update: I now run a workshop/tutorial Technical Writing for Blogs and Articles for engineers.
The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.
Here’s an excerpt:
600 people reached the top of Mt. Everest in 2012. This blog got about 10,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 17 years to get that many views.
You have an installation of Graphite, a desire to learn more Ruby, and some festive spirit – what emerges?
An xmas tree drawn using proper metrics via the Ruby graphite gem, of course!
The magic happens with the Graphite::Logger class, because we can log metrics at specific points in time:
logger.log(when,{"Branches1" => 3})
I calculated the points to plot on paper, and found decent Graphite rendering settings by experimentation:
The code is on Github here: https://github.com/matthewskelton/GraphiteGreetings – fork away!
| require 'Graphite' | |
| require 'Logger' | |
| # Change these as needed for your environment | |
| server = "my.graphite.server.url" | |
| log = Logger.new(STDOUT) | |
| prefix = "Test.Me.XmasTree." | |
| # Create the logger to send stats to Graphite with specific timings | |
| logger = Graphite::Logger.new(server,log) | |
| # Define the offsets | |
| # | |
| # Use Now as a starting point, | |
| # or set a specific time e.g. Time.utc(2012,12,22,19,10,30) | |
| # We need a 20-minute window to plot | |
| t = Time.now | |
| t0 = Time.at(t.to_i - (20 * 60)) # 20 mins ago | |
| t1 = Time.at(t0.to_i + (60 * 1)) # Left base of tree | |
| t2 = Time.at(t0.to_i + (60 * 3)) # Lower tinsel2 | |
| # etc. | |
| # Inject the stats - the order is determined by the default Graphite colours | |
| logger.log(t21,{prefix + "Tinsel1" => 3}) | |
| logger.log(t18,{prefix + "Tinsel1" => 6}) | |
| # etc. |
I’d love to hear or see any suggestions for improvements to the script. Candles? Snowflakes? Reindeer?! Also, as my Ruby-fu is limited, if there are better ways of interacting with Graphite, I’d love the hear about them (I tried and failed to get activesupport to work on my machine, for example).
This article first appeared in Software Development Practice, Issue 1, published by IAP (ISSN 2050-1455)
When raising log events in code it can be difficult to choose a severity level (such as Error, Warning, etc.) which will be appropriate for Production; moreover, the severity of an event type may need to be changed after the application has been deployed based on experience of running the application. Different environments (Development (Dev), User Acceptance Testing (UAT), Non-Functional Testing (NFT), Production, etc.) may also require different severity levels for testing purposes. We do not want to recompile an application just to change log severity levels; therefore, the severity level of all events should be configurable for each application or component, and be decoupled from event-raising code, allowing us to tune the severity without recompiling the code.
A simple way to achieve this power and flexibility is to define a set of known event IDs by using a sparse enumeration (enum in C#, Java, and C++), combined with event-ID-to-severity mappings contained in application configuration, allowing the event to be logged with the appropriate configured severity, and for the severity to be changed easily after deployment.
Continue reading Tune logging levels in Production without recompiling code
Matthew Skelton 