I just released version 0.2.0 of Timecop this evening (morning).
The primary feature added was the distinction between “freezing” and “rebasing” time. In 0.1.0, Timecop.travel would actually freeze time. This is no longer the case. Rather, a time offset will be calculated, and a running clock is simulated by always offsetting the time returned by Time.now (and friends) by the original offset.
(Note that time can still be frozen with Timecop.freeze.)
This past weekend I released v0.1.0 of the Timecop gem. Timecop makes it dead simple to travel through or freeze time for the sake of creating a predictable and ultimately testable scenario.
The gem is derived from a plugin I wrote a while back to achieve more or less the same functionality for an extremely time-sensitive application. My goals for the gem included:
The gem is hosted on RubyForge and can be installed by simply running:
sudo gem install timecop
Have you ever opened 4 terminal windows, SSHed each one into a server, and ran tail on all of them to watch 4 log files?
Have you ever had a terminal window open whose sole purpose was to run “tail my_log” over and over again to look at the output of a file?
It’s a pain, isn’t it?
Introducing “Watch Me” a simple ruby script that allows you to watch multiple log files simultaneously.
go from this:
Using multiple terminals to watch logs
to this:
Using WatchMe to watch logs
We are currently working on a project that involves Flex and active resource + will_paginate and we needed to be able to paginate the xml transactions easily. Unfortunately, will_paginate and to_xml don’t play nicely when it comes to adding the current_page, total_pages, and page attributes to the xml. After many failed attempts I went looking around github and found in a few forks of will paginate that some people had solved this problem but, I didn’t want to install another version of the gem to risk breaking other apps on the server so I did it the rails way!
I started by creating a module that opens up the will_paginate collection class and includes ActiveResource and alias method chain the to_xml method to include these values. Example code below.
#enviroment.rb ... require 'to_xml_extensions'
#lib/to_xml_extensions.rb module WillPaginateHelpers include ActiveSupport::CoreExtensions::Array::Conversions def to_xml_with_collection_type(options = {}) serializeable_collection.to_xml_without_collection_type(options) do |xml| xml.tag!(:current_page, {:type => ActiveSupport::CoreExtensions::Hash::Conversions::XML_TYPE_NAMES[current_page.class.name]}, current_page) xml.tag!(:per_page, {:type => ActiveSupport::CoreExtensions::Hash::Conversions::XML_TYPE_NAMES[per_page.class.name]}, per_page) xml.tag!(:total_entries, {:type => ActiveSupport::CoreExtensions::Hash::Conversions::XML_TYPE_NAMES[total_entries.class.name]}, total_entries) end.sub(%{type="array"}, %{type="collection"}) end alias_method_chain :to_xml, :collection_type def serializeable_collection #:nodoc: # Ugly hack because to_xml will not yield the XML Builder object when empty? empty? ? returning(self.clone) { |c| c.instance_eval {|i| def empty?; false; end } } : self end end WillPaginate::Collection.send(:include, WillPaginateHelpers)
This now gives me the proper xml when I call to_xml
<?xml version="1.0" encoding="UTF-8"?> <time-cards type="collection"> <current_page type="integer">1</current_page> <per_page type="integer">25</per_page> <total_entries type="integer">108</total_entries> <time_card> <approved type="boolean">false</approved> <billable type="boolean">false</billable> <created_at type="datetime">2008-10-10T14:04:13-04:00</created_at> <date type="datetime">2008-10-10T14:04:13-04:00</date> <has_been_billed type="boolean">false</has_been_billed> <has_been_paid type="boolean">true</has_been_paid> <hours type="float">2.0</hours> <id type="integer">98</id> <is_overtime type="boolean">false</is_overtime> <task_id type="integer">6</task_id> <updated_at type="datetime">2008-10-10T14:04:13-04:00</updated_at> <user_id type="integer">1</user_id> </time_card> ... </timecards>
I’ve found myself on a benchmarking kick these last couple of weeks. Sometime last week, I dug up the better-benchmark library written by Pistos. Pistos’ library is basically just a wrapper for the rsruby gem, which is more or less an interface to R (similar to what rmagick is to ImageMagick).
Combining these tools together, we can do some pretty nifty code performance analysis in very few lines of code, e.g.
require 'rubygems' require 'better-benchmark' result = Benchmark.compare_realtime(:iterations => 10) { |iteration| save_the_world() }.with { |iteration| save_the_world_and_save_the_girl() } Benchmark.report_on result
I have forked better-benchmark and wrapped the library up into a RubyGem.
If you need to process 1000 items independently, the simplest thing to do is to handle them one-by-one. But what if there is a large delay that is not caused by your application when you handle an item? What if you need to make a 100ms web request per item, only to do about 10ms of processing on that item? This would take 1000 x 110ms (100ms to wait, 10ms to process)!
So what do we do?
I love YAML. It’s portable. The majority of languages I work with already have libraries built to read/write it. It’s more lightweight, more expressive, and easier to read than XML. I really love YAML.
Unfortunately, it turns out that Ruby’s YAML library is a little incomplete for some edge cases. I just discovered that YAML.dump fails to generate valid YAML for certain multi-line strings. The specifics are very difficult to explain, and we’ll summarize them at the end after trying out some examples. Fire up irb and give the following a try.
require 'yaml' s = "\n Something embedded.\nAnd on a new line." YAML.load(YAML.dump(s))