atom.xml

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

  <title><![CDATA[Whitethunder]]></title>
  <link href="http://thewhitethunder.com/atom.xml" rel="self"/>
  <link href="http://thewhitethunder.com/"/>
  <updated>2011-12-19T10:35:02-07:00</updated>
  <id>http://thewhitethunder.com/</id>
  <author>
    <name><![CDATA[Matt White]]></name>
    
  </author>
  <generator uri="http://octopress.org/">Octopress</generator>

  
  <entry>
    <title type="html"><![CDATA[Time Zone Sensitive Code in Rails]]></title>
    <link href="http://thewhitethunder.com/blog/time-zone-sensitive-code-in-rails/"/>
    <updated>2011-12-19T09:56:00-07:00</updated>
    <id>http://thewhitethunder.com/blog/time-zone-sensitive-code-in-rails</id>
    <content type="html"><![CDATA[<p>At <a href="http://www.goldstar.com">Goldstar</a>, we help people go out more to live entertainment across several time zones. When we list a new show in New York City and it&#8217;s supposed to be displayed on our site at midnight on December 1st, we want it to be displayed when it&#8217;s midnight in New York City on December 1st, and not wait until it&#8217;s midnight in Los Angeles. Rails hasn&#8217;t done a great job of making it obvious how to do this, so I hope to make it obvious how we&#8217;ve done it successfully using Rails.</p>

<p><strong>TL;DR:</strong> if you&#8217;re doing time zone sensitive stuff, use <code>Time.zone</code>, followed by <code>.now</code> or <code>.now.to_date</code>; or use the Rails helpers like <code>1.hour.ago</code>.</p>

<p>Since we are based in California, we use Pacific Time in our app. This is set in our app&#8217;s config/environment.rb (config/application.rb for Rails 3.x):</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>config.time_zone = 'Pacific Time (US & Canada)'</span></code></pre></td></tr></table></div></figure>


<p>Our time zone is now set to Pacific Time, which is evidenced by:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
<span class='line-number'>2</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>  &gt; Time.zone
</span><span class='line'> =&gt; #&lt;ActiveSupport::TimeZone:0x1c865d0 @tzinfo=#&lt;TZInfo::DataTimezone: America/Los_Angeles&gt;, @utc_offset=-28800, @current_period=nil, @name="Pacific Time (US & Canada)"&gt;</span></code></pre></td></tr></table></div></figure>


<p>However, Time.now and Date.today use the OS&#8217;s time zone. Since I am in Mountain Time, I get -0700. Pacific Time folks wouldn&#8217;t think anything was amiss:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
<span class='line-number'>2</span>
<span class='line-number'>3</span>
<span class='line-number'>4</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>  &gt; Time.now
</span><span class='line'> =&gt; Wed Dec 14 09:52:36 -0700 2011
</span><span class='line'>  &gt; Date.today.to_time
</span><span class='line'> =&gt; Wed Dec 14 00:00:00 -0700 2011</span></code></pre></td></tr></table></div></figure>


<h3>How to Use the App&#8217;s Time Zone</h3>

<p>If you want a date or time in the app&#8217;s current time zone, use Time.zone.now or the Rails helpers like 1.hour.ago:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
<span class='line-number'>2</span>
<span class='line-number'>3</span>
<span class='line-number'>4</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>  &gt; Time.zone.now
</span><span class='line'> =&gt; Wed, 14 Dec 2011 08:52:36 PST -08:00
</span><span class='line'>  &gt; 1.hour.ago
</span><span class='line'> =&gt; Wed, 14 Dec 2011 07:52:36 PST -08:00</span></code></pre></td></tr></table></div></figure>


<p>You can switch Rails&#8217; time zone if you know the right incantation (for a full list, <a href="http://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html">look here</a>):</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
<span class='line-number'>2</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>  &gt; Time.zone = 'America/New_York'
</span><span class='line'> =&gt; "America/New_York"</span></code></pre></td></tr></table></div></figure>


<p>You&#8217;ll notice that Time.zone.now uses Rails&#8217; time zone correctly when you&#8217;ve changed it:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
<span class='line-number'>2</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>  &gt; Time.zone.now
</span><span class='line'> =&gt; Wed, 14 Dec 2011 11:52:37 EST -05:00</span></code></pre></td></tr></table></div></figure>


<p>In case you&#8217;re curious, you can change the OS&#8217;s time zone if you know the right incantation as well:</p>

<figure class='code'><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
<span class='line-number'>2</span>
<span class='line-number'>3</span>
<span class='line-number'>4</span>
</pre></td><td class='code'><pre><code class=''><span class='line'>  &gt; ENV['TZ'] = 'EST'
</span><span class='line'> =&gt; "EST"
</span><span class='line'>  &gt; Time.now
</span><span class='line'> =&gt; Wed Dec 14 11:56:23 -0500 2011</span></code></pre></td></tr></table></div></figure>


<p>One problem we kept having at Goldstar was a failing build after certain hours of the day, since our app and CI server run in Pacific Time but some of our tests test shows in other time zones.</p>

<h3>Homework</h3>

<p>So with your new-found time zone knowledge, here&#8217;s an exercise for you. Can you spot the bug with this spec:</p>

<figure class='code'><figcaption><span></span></figcaption><div class="highlight"><table><tr><td class="gutter"><pre class="line-numbers"><span class='line-number'>1</span>
<span class='line-number'>2</span>
<span class='line-number'>3</span>
<span class='line-number'>4</span>
<span class='line-number'>5</span>
<span class='line-number'>6</span>
<span class='line-number'>7</span>
<span class='line-number'>8</span>
<span class='line-number'>9</span>
<span class='line-number'>10</span>
<span class='line-number'>11</span>
<span class='line-number'>12</span>
</pre></td><td class='code'><pre><code class='ruby'><span class='line'><span class="n">describe</span> <span class="s2">&quot;thinger&quot;</span> <span class="k">do</span>
</span><span class='line'>  <span class="n">before</span> <span class="ss">:each</span> <span class="k">do</span>
</span><span class='line'>    <span class="vi">@event</span> <span class="o">=</span> <span class="no">Factory</span><span class="p">(</span><span class="ss">:event</span><span class="p">)</span>
</span><span class='line'>  <span class="k">end</span>
</span><span class='line'>
</span><span class='line'>  <span class="n">it</span> <span class="s2">&quot;should return the thinger for this event if its thinger_on is today&quot;</span> <span class="k">do</span>
</span><span class='line'>    <span class="no">Time</span><span class="o">.</span><span class="n">use_zone</span><span class="p">(</span><span class="vi">@event</span><span class="o">.</span><span class="n">timezone</span><span class="p">)</span> <span class="k">do</span>
</span><span class='line'>      <span class="vi">@thinger</span> <span class="o">=</span> <span class="no">Thinger</span><span class="o">.</span><span class="n">create!</span><span class="p">(</span><span class="ss">:event</span> <span class="o">=&gt;</span> <span class="vi">@event</span><span class="p">,</span> <span class="ss">:thinger_on</span> <span class="o">=&gt;</span> <span class="no">Time</span><span class="o">.</span><span class="n">now</span><span class="o">.</span><span class="n">to_date</span><span class="p">)</span>
</span><span class='line'>    <span class="k">end</span>
</span><span class='line'>    <span class="vi">@event</span><span class="o">.</span><span class="n">thinger</span><span class="o">.</span><span class="n">should</span> <span class="o">==</span> <span class="vi">@thinger</span>
</span><span class='line'>  <span class="k">end</span>
</span><span class='line'><span class="k">end</span>
</span></code></pre></td></tr></table></div></figure>


<p>ANSWER KEY: :thinger_on is using Time.now.to_date, which after a certain hour of the day, depending on your OS&#8217;s time zone, will fail. Totally lame. Time.zone.now.to_date is what was intended here.</p>
]]></content>
  </entry>
  
  <entry>
    <title type="html"><![CDATA[Attracting Talented Rubyists]]></title>
    <link href="http://thewhitethunder.com/blog/attracting-talented-rubyists/"/>
    <updated>2011-08-25T08:28:00-06:00</updated>
    <id>http://thewhitethunder.com/blog/attracting-talented-rubyists</id>
    <content type="html"><![CDATA[<p>Chances are that if you work with a team that does <a href="http://www.ruby-lang.org">Ruby</a> development, you don&#8217;t just have trouble finding <em>good</em> Ruby programmers, you have trouble finding available Ruby programmers <em>period</em>. I attend 2-3 Ruby programming related conferences per year, and at each one it seems that everyone is employed, most of them happily, and every other presentation someone announces, &#8220;I&#8217;m from X company and oh by the way WE&#8217;RE HIRING OMG PLEASE COME WORK FOR US!!!&#8221;</p>

<p>As a Rubyist, this is awesome. We&#8217;re in high demand, even in a bad economy. As someone that has assisted in searching for good Rubyists, it&#8217;s terrible. You spend many weeks and even months searching for just one person who is a cut above the rest. And when you find someone, you know they have many options so no ordinary job offer will do.</p>

<p>I&#8217;ve been a full-time Rubyist for a few years now. I&#8217;ve worked in circumstances that were awesome and in circumstances that had me looking for any available opportunity to find something better. I want to share what these things were, more or less in order of importance. And while this list is written with the Rubyist in mind, these principles for the most part apply to hiring programmers and retaining them in general.</p>

<h4>Trust and Ownership</h4>

<p>A Rubyist doesn&#8217;t want to be confined to strict orders and processes. He wants to be creative and own his work. Don&#8217;t micro-manage. It&#8217;s not going to improve anything. If the thought of a programmer taking creative freedoms is frightening to you, consider how it would feel to have your management style dictated to you. Encouraging programmers to collaborate and solve problems together ought to be enough to alleviate your fears and produce the results that you both want.</p>

<h4>Profit Sharing/Bonuses</h4>

<p>Let&#8217;s be honest, businesspeople. That great idea you have won&#8217;t go anywhere without someone to market it, sell it, and <em>build it</em>. You have this great dream of getting rich off of your marvelous idea, but you&#8217;re not going to do it alone. So share the wealth and a Rubyist will be happy to build awesome things for you. You could try setting up a profit sharing arrangement. You could offer bonuses tied to good performance. You could offer awesome perks like overnight getaways for 2, restaurant gift certificates, bring in a masseuse, etc.</p>

<h4>Sane Hours</h4>

<p>Don&#8217;t make a Rubyist work more than 40 hours a week. If he does it of his own accord, that&#8217;s probably ok, but make sure that your expectation is limited to 40 hours. You might think to yourself, &#8220;Well I&#8217;ve had this guy writing code for me for a year now and he always does 60-80 hour weeks.&#8221; And then one day he tells you he&#8217;s taking a job somewhere else, and the likely reason is because he&#8217;s burnt out. We may be a little socially awkward sometimes, but we do have lives outside of work, even if that life is playing Starcraft or even watching videos of other people playing Starcraft.</p>

<h4>Keep them Challenged</h4>

<p>Along the lines of getting burnt out, a Rubyist wants to be interested in what he&#8217;s doing. A good way to do this is to give him new challenges. It doesn&#8217;t have to be constant glamourous work, but if you&#8217;ve got him spending a lot of time cleaning up messes in production or fixing the CI server on a regular basis, you ought to give him a break from it, even if he&#8217;s the best at it. Let him have a chance at being a project or team lead. Let him refactor or rewrite a poorly-written section of the app between projects. Just don&#8217;t let him get stuck in a rut that he can&#8217;t get himself out of or chances are he won&#8217;t be around very long.</p>

<h4>Talk to Them</h4>

<p>When was the last time you asked your developers if they love what they do? Do you have any idea what gets them going each day or what frustrates them? Do you give them regular feedback on their work? Building a relationship where you talk about things like this will go really far with a Rubyist. You can help them improve and they can help you manage better.</p>

<h4>Be Agile</h4>

<p><a href="http://agilemanifesto.org/">Agile</a> methodologies are much more programmer-friendly than Waterfall. It also delivers better results faster when followed correctly. If you aren&#8217;t already Agile, get someone to train you and your team.</p>

<h4>Training and Conferences</h4>

<p>Speaking of training, Rubyists want to learn. We don&#8217;t want to be working the exact same job with the exact same skills for the next 10 years. We&#8217;re passionate about what we do. We want to get better every day and sending us to trainings and conferences will help us do that and make us happy. Let your team choose what conference they most want to go to and pay for them to go. Your team will learn, bond, get away from the office for a few days, and come back refreshed with new insights.</p>

<h4>Good Equipment</h4>

<p>Don&#8217;t be cheap with the equipment you buy them. Get really good laptops. Get big monitors. Let them choose their preferred peripherals. Get them nice headphones. It&#8217;s best if you let them choose all their own stuff but if you need to standardize, make sure you standardize on something good.</p>

<h4>Allow Work-from-home</h4>

<p>Commuting is a waste of time. We&#8217;d rather be writing code. I&#8217;m not suggesting that all Rubyists want to work from home all the time, but working from home a day or two a week is a nice break from the commute, or even that annoying PM who always wants to pretend he fits in with the geeks. If you find it a little inconvenient, only allow it on days where it&#8217;s more convenient.</p>

<h4>Make Open Source Contributions</h4>

<p>The Ruby community is all about sharing and giving back. You&#8217;re using software that is open source at your company. Well, that software didn&#8217;t magically appear one day. Some generous people gave their time and effort to create it, and now you&#8217;re benefiting from it financially. Unless you&#8217;re sending money their way, the best way to pay them back is to open source some of your code. If your company won&#8217;t or can&#8217;t do that, then let your Rubyists spend some time making open source contributions to worthy projects of their choice.</p>

<h4>Don&#8217;t Use Phrases Like &#8220;Rock Star&#8221; or &#8220;Code Ninja&#8221;</h4>

<p>When you post a job listing for a Rubyist, don&#8217;t use lame cliche catch phrases. As soon as you start using the average strategies that everyone else uses, you get average Rubyists. Quality Rubyists want to see and do things they haven&#8217;t done before. Give them a programming challenge or a puzzle to solve or something interesting.</p>

<h4>Conclusion</h4>

<p>You might think that a lot of this is expensive or unrealistic, but you&#8217;re wrong. One great Rubyist can do the work of 5 average Rubyists, but I bet you wouldn&#8217;t pay him the salary of 5 average Rubyists. He probably wouldn&#8217;t expect it either, so it&#8217;s well worth it to do what it takes to make him happy. And once you have a team of happy Rubyists, when you need to find another one, it will be easier to do because we talk about our jobs all the time to other Rubyists. And <a href="http://www.terrencebrown.net/the-law-of-crappy-people/">awesome Rubyists tend to talk to other awesome Rubyists</a>, so your recruiting efforts will become much easier down the road.</p>
]]></content>
  </entry>
  
</feed>