The wording is perfect – little wink to the airline industry seems far better than „premium”, „paid ”or „pro plan”.

We use Trello on a daily basis throughout every section of the company – from IT management, administration and accounting to keeping track of our digital library and book requests. Yet there was a little fear in the back of my head: we rely on it so much but we don’t pay for it.

Agreeing fully with „Don’t be a free user”, the news about Trello giving its users a way to pay for the software was something I wanted to share with the team instantly. And so I did.

Dominik replied: what does it mean for us, non-admins?
My reply was simple: it’s paid and it won’t disappear overnight (or at least leave us without data, as pointed on HN).

We don’t need the pro features. We simply appreciate the safety and want to support the product.

Git features

Comparing to its predecessor, Subversion, Git stays young and fresh. More importantly, it’s a much more complex tool. Chances are that you’re still looking for good practices or better understanding of a few concepts.

• Git Best Practices by Seth Robertson is a long list of… best practices of using git — recommended if you still feel a little uncomfortable working with it.
• Merge vs. Rebase by Mislav Marohnić will help you understand the difference between these two, and provide you with tips on each.
• Keeping Passwords in Source Control by the JavaScript guru and creator of jQuery, John Resig, comprehensivley describes how to store passwords inside source revision control like a Git repository.
• Did you know that GitHub exposed public ssh keys for its users? Hat tip from Adam Stackoviak. We think it’s better to use GitHub API for such things, but it’s worth knowing there’s an alternative way.

Adjust your Vim

Probably only pure vimists can take pleasure in using Vim without any plugins or .vimrc customizations. Here are some hints on adjusting Vim to your needs:

• Lay Out Your .vimrc Like a Boss, because growing .vimrc can easily turn into mess. Doug Ireton proposes a nice and clean way of organizing your config.
• Vim After 11 Years — Ian Langworth shares his experience: what he likes, what he learned, and how he extends his Vim. It’s such a broad topic that there’s even a sequel to the article, Everything I Missed in “Vim After 11 Years.”
• Stop the Vim Configuration Madness by Alex Young leaves you with a valuable warning that there is a thin border between improvement and incomprehension of Vim philosophy.
• VimShell is a nicely looking shell solution with the power of vim. If you love Vim, this project is worth checking.

The undiscovered land of SPA

We’ve got tons of frameworks, ideas and hot discussions on available paths to follow. SPA is a still fresh and hot topic with lots of white gaps on its map.

• Tomasz Nazar of Gameboxed shares his experience on how they do single page apps. Worth reading, since these guys basically write only SPAs.
• Building Huuuuuge Apps with AngularJS by Brian Ford — if you’re a fan of the framework like our Tymon is, you should read these tips on building a complex Angular-based applications.
• Rant: Backbone, Angular, Meteor, Derby — Tyler Renelle pays tribute to Backbone for making a revolution in the JavaScript world, but the world goes forward and — as he says — today you should choose something better.
• Introducing Hexagonal.js — our local community works hard on different approaches to SPAs. Jan Filipowski presents basic ideas and how you can contribute to the project.
• Preventing Backbone.sync Firestorms – if you use Backbone.js, chances are that you’ve met the issue of firing too many events. Nate Hunzaker suggests how to deal with such.

Power of HTML5

One way of learning something new is to read others’ code. Here are some amazing demos and articles:

• Find Your Way to Oz — watch this and you’ll start wondering about beautiful adventure games in your browser. Just awesome.
• 10000 Stars will take you on a trip around the stars and planets right in the browser. Feel like Neil Armstrong!
• Pointer Lock and First Person Shooter Controls — if you plan to write FPS game in a browser, this introduction to Pointer Lock API could be a good start.
• Creating 3D worlds with HTML and CSS — another cool example how to start with FPS games and 3D world in a browser.

See you next time!

To give you some context: at the moment we’re focusing on designing our organisation. In the first three years of running the company we’ve experienced some growth – not very rapid, but enough to put us into a little chaos after getting from 3 to 15+ people. 2013 is the year of getting steady and making ground for more growth.

Make the robots do the lazy work

We have four people that are included in our sales process. Utilising a CRM – Highrise being our choice – was a necessity.

The problem? Nobody was using it.

It seemed redundant and the friction of the system outweighed it’s advantages. To make the process as smooth as possible, we improved our contact form a bit so that every message is automatically creating a contact in Highrise. The process got a little less annoying.

Measure

We’ve been forecasting our incomes using a spreadsheet. It turned out to be too simple in terms of the data and too complex when it came to putting the numbers in. Not to mention that the data was mostly duplicated from our accounting software.

But hey, we’re a bunch of coders. We can build the tools we need. (It was one of the rare moments during which I felt real power coming from our profession).

I quickly prototyped two simple tools  - one called Norman, used to gather the data and expose it to the second one – Norman’s Dashboard, as seen below.

Measure. Measure. Measure.

Here’s what the dashboard looks like:

The data is updated in real time. If somebody updates his timesheet in Harvest, we see the numbers go up. If somebody puts a new invoice into Norman, the dashboard updates the income and profit forecasts in seconds. (The tool we used for the dashboard is Dashing – huge kudos to Shopify’s team for making it open-source)!

Income forecasting and the timesheet reports are only a proof of concept – we have huge plans for the dashboard: notifying about new leads that we haven’t responded to yet, displaying numbers from Google Analytics and KPIs (that we’re going to most likely measure in the app).

Positive side effect

We’re getting more conscious about what happens in our company.

Ultimately, a quick glance at the dashboard will give us an overview of the whole organisation. Most importantly, our thinking process is getting more and more data-driven.

Measuring a new part of the company doesn’t mean that we’re going to get our hands dirty working in a spreadsheet – it means that we have to code it once and then just look at the beautiful representation of the data.

Take the risk

Our data-driven automatization revolution started by one small thing – automating a simple part of the sales process. Seeing how this improved our daily work made us see new ways of doing things: we started to wonder if something can be automated out of the box. We spent a few hours on improving the sales process but we got a lot more from it: the first-hand knowledge that it’s worth it.

There were no more „okay, this seems like a good idea, let’s put it in the never-ending backlog of low priority tasks” discussions. We transitioned to „yeah, let’s do it!” – driven by the confidence from previous experiences – even as small as the one described above.

Start simple. Do small stuff. Experiment. Sometimes it’s not worth putting stuff into context and weighing the ups and downs: just do it. Trust your guts – the outcome can positively surprise you.

We’ve all been there. We’ve gone through all existing tools and, this way or another, found our best shot. Heard of kanban? It’s as easy as 1–2–3 to tear it into pieces, take what fits, and call yourself agile. Daily inertia inside a busy software house hive has proved it all right.

In our line of business, we work on various projects simultaneously and have to stay ABC at all times, therefore well-optimized workflow is a must. It’s also a moral boost and sanity check for developers. Top-down and bottom-up — both have to meet.

Because there is as much to it as a human factor is concerned as it is to a business requirement. And yet, maturity of the workflow defines the team. We almost take it personally. We’re still in the process of getting the most out of ourselves. And we’ve come to a milestone where we are happy.

We use Trello for project management. We’ve developed a management workflow that is spread across different boards and more or less kanban-like. Sounds familiar?

Lords of the boards

Lots of inspiration for our workflow comes from the approach described by the makers of UserVoice. As it did for their team, the openness of Trello allowed us to figure what was best for us. At the same time, it still allows for some small organic changes throughout different projects — small enough for anyone within the team to immediately grasp what is happening in the project even if he’s never worked on it.

That is why it’s more like a template that proves best.

Product/planning board

Product planning board example

This is the place where stories are gathered and requirements get written down. A meeting point for product owner and project manager. The board features the following columns:

• Ideas and feature requests,
• Story is considered useful, required specs are being created,
• Specs are approved, designs are being prepared, estimates required,
• Finished user-stories,
• User-stories for a next sprint.

Development board

The board is specifically created for developers with clear order of priorities:

• To do — tasks in current sprint ordered by priority.
• In progress — when I start working on something I move my card here. Only one card assigned to one person. Does this ring a bell?
• Ready to test — a story that has been delivered to staging server.
• Tested and ready to be deployed to live — party that is at the end of the pipeline moves the card here (the QA process).
• Live v[x] [date] — for each live release with a date attached. We keep up to 3 versions, the rest is archived.

How it works

All stakeholders have access to all boards: The client, project managers, developers, designers. This has obvious advantages. First and foremost — cards can be moved freely across boards, and the whole history is visible to everyone. Turns out that a requirement isn’t specified precisely enough to be implemented? Take the card back from the development board to the planning board for more feedback. Having two transparent boards also gets some burden off the client’s head — he does not necessarily have to be involved in development process, however he can check the progress of each story any time.

Cards represent stories. Simple. We’re not nazi in this regard, but whenever possible it’s best to create cards as stories. If a story turns out to be too big — split it into multiple cards.

Describe stories by checklists. Each card has a checklist that represents specific tasks to be accomplished to finish the story. Each item on the checklist mentions the person responsible for each part of the story. We found it is sometimes a good idea to group the checklists e.g. into front-end tasks and back-end tasks, especially if there are lots of them.

Cards are attached to people involved in the task. Remember to keep those people actively involved in the card who assigned to it. If someone finished his part, he detaches himself from the card.

Mention! There is never too much to stress that mentioning is powerful both on system as well as on human level. Calling someone directly means they will get a notification. You need a specific person to pay attention at some specific point. Finger pointing when things are on the move, not after a failure.

Where the wild things are

The above are the foundations. There are more quirks.

For example, we came up with a “Release tasks” label. It should be applied on a card that needs some extra work to be done during the release, like “execute a server script.” The release checklist should be created next to it with all the activities to be performed listed.

You can get creative. Give it some thought. Describe your internal processes and apply that in Trello. You can use labels and titles of the cards as metadata carriers. They are ambiguous enough to always feel natural. In the end this is what matters the most: to keep it real.

Hopefully, some of these can be helpful to anyone out there struggling with the development process. Some of these may as well become outdated in a year from now. And that’d be fine — it would mean we’ve evolved again. And you could expect to hear from us about what we’ve learned on our way, too.

If you like the series, subscribe to our newsletter so you’ll have a similar digest delivered right to your mailbox once a month.

But for today, we’ve got some free e-books, and a couple of security and tests-related links. Enjoy.

Something to read

If you are a regular developer, chances are that occasionally you need to transform yourself into a sever admin. To make this less painful, I recommend diving into The Debian’s Administrator Handbook.

Building a single page app is still a hot topic. Mikito Takada recently wrote a fresh e-book on the topic that’s available for free. Should you be interested in developing such app with Backbone, go through Developing Backbone.js Applications by Addy Osmani as well.

An interesting piece revolves around Mozilla’s infant project—it’s on Rust, but from a Rubyist’s perspective, written by Steve Klabnik.

Next up, the DOM Enlightenment. Our JavaScript developers—myself included—wish we had found this book during our learning phase years ago. It really makes it easier to understand how DOM and JavaScript play together.

Another pieces that we collected for front-end guys and designers: Web Design and Mobile Trends for 2013.

Security is hard

The last weeks were full of new security fixes for Rails. I think it would be good to know why all that happened. Read about problems with YAML and secure your app from… your own mistakes.

It’s also worth knowing why security is such a difficult topic: where most problems lie or how to secure less known holes like Rails session secret.

When talking about errors, consider including better_errors in your project’s Gemfile. Apart from its output being much nicer than the default, the gem comes with some additional features.

Improve your tests

First of all, make them more pleasant for your eyes to read, and easier to parse for the mind.

After that, consider the following improvements for Mocks thanks to Surrogate (#2), which gives you more feedback when your application happens to fail.

At last, but not least, make sure you test everything. And I really mean everything.

Visit this year’s website.

Just check the list of the speakers, and be sure that the last year was just a warm-up. New conventions, talks fully loaded with meat, and long run of before and after parties. A lot of important mind-changes that will result in hot discussions will strike again, with fresh additions and surprises.

Last year’s discussions were intense and very informative.

Find, talk and grab a beer with us during the conference! If you’re reading this blog, then you definitely should.

You can follow wroc_love.rb on Twitter and Facebook. Keep an eye on the blog for the next batch of tickets if you still don’t have one.

Here’s the story of what we did to reduce the load time.

The dashboard

Humble beginnings

The first version of the dashboard was dead simple: call remote APIs during the request and render the results. It quickly turned out it won’t work—a few of API calls took quite a lot of time to respond, and making them in parallel via Rails’ action is difficult and error-prone.

Obviously, if you have to wait such long time for the homepage to load, it’s very poor user experience. You might even wonder that something’s wrong.

The second take was much better. If the homepage is requested, let’s return its layout only and then use AJAX to fetch data. Unfortunately, due to browser limitations and the amount of containers to fill with the data (usually 7), it was still insufficient: long-running spinners and AJAX calls’ timeouts.

Faye to the rescue!

Another idea was to use Faye for pushing data into the browser, so that there would be no more timeouts during HTTP requests.

Right after the loaded homepage layout, the browser subscribed to specific Faye channel and triggered the processing of API calls. When one of the them succeeded, its results were pushed to the browser.

The solution was quite satisfying, yet we wondered if we could have done it even better.

Why? Look at the timeline, there’s still the unnecessary delay—API jobs could have been started much sooner. Due to Faye channels architecture, the client receives only the messages that were sent after having subscribed to the channel.

As you can see, the earlier the jobs are started, the earlier they finish and they could be able to push the results before the client subscribes to the channel which would result in message loss. In this case, API Job #2 Faye push happens before Faye subscribe.

If only there was a way to save those message somehow when the client is not yet connected and send them when it’s connected…

Redis Faye back-end

Turns out it’s possible using a bit modified Redis back-end for Faye. Consider the following code:

module Faye
  class PersistentRedis < Faye::Redis
    DEFAULT_EXPIRE = 60 # default expiration timeout for awaiting messages

    def subscribe(client_id, channel, &callback)
      super
      publish_awaiting_messages(channel)
    end

    def publish_awaiting_messages(channel)
      # fetch awaiting messages from redis and publish them
      @redis.lpop(@ns + "/channels#{channel}/awaiting_messages") do |json_message|
        if json_message
          message = Yajl::Parser.parse(json_message)
          publish(message, [message["channel"]])
          publish_awaiting_messages(channel)
        end
      end
    end

    def publish(message, channels)
      init
      @server.debug 'Publishing message ?', message

      json_message = Yajl::Encoder.encode(message)
      channels     = Channel.expand(message['channel'])
      keys         = channels.map { |c| @ns + "/channels#{c}" }

      @redis.sunion(*keys) do |clients|
        if clients.empty?
          key = @ns + "/channels#{message["channel"]}/awaiting_messages"
          # store message in redis
          @redis.rpush(key, json_message)
          # set expiration time
          @redis.expire(key, @options[:expire] || DEFAULT_EXPIRE)
        else
          clients.each do |client_id|
            @server.debug 'Queueing for client ?: ?', client_id, message
            @redis.rpush(@ns + "/clients/#{client_id}/messages", json_message)
            @redis.publish(@ns + '/notifications', client_id)
          end
        end
      end

      @server.trigger(:publish, message['clientId'], message['channel'], message['data'])
    end
  end
end

# Faye::Logging.log_level = :info
faye_server = Faye::RackAdapter.new(
  :mount => '/faye',
  :timeout => 30,
  :engine => {
    :type  => Faye::PersistentRedis,
    :namespace => "faye",
    :expire => 60 # one minute
  }
)

A part of publish checks if there any clients subscribed to the channel—if not, the message is stored in the list:

/channels/$channel/awaiting_messages

When the clients eventually subscribes, the stored messages are removed from the list and pushed.

Importantly, there is a possibility that the client never subscribes to the channel. To prevent storing the ever-increasing amount of messages in Redis, expiration time is set to one minute on the same key.

The final solution

The full resultant stack consists of Rails, Sidekiq, and the modified Faye server.

When the first request takes place, API jobs are queued in Sidekiq. Then the finished jobs are pushed to Faye and saved in Redis when needed. The browser loads the layout and subscribes to Faye channel that retrieves both the messages that were already stored and those new ones that are being created.

Background

I didn’t join the awesome Monterail guys as a complete novice. I was working in the industry since 2007, mostly as a PHP programmer. As the world was moving forward, I felt like PHP kept standing in the same place, and to stand still is to move back.

While I was looking to switch, I glanced off at Python which I was already familiar with. My colleague convinced me that I should check the programming language called Ruby, which was similar at first sight. So I put all one’s eggs in one basket, bought Programming in Ruby 1.9 and… actually fell in love with it.

Jumping on the bandwagon

I learned a little about Ruby itself, Rails and a few other popular gems.

After two or three months of working at Monterail, I felt like a fish in the water. I spent a lot of time on reading before, so I already knew about the two paths for everything (even developed some preferences) and was able to omit the biggest headache during the real work.

To make things more complicated, Rails 3 was still quite fresh subject at the time. It was quite controversial because of its asset pipeline or including CoffeeScript by default. Blogs were flooded with laments that Rails wasn’t for beginners anymore.

From my point of view, diving right into the version 3 was an advantage. Improved structure and modularity, Bundler, and all that hot additions weren’t really invasive, even though they were problematic for many. I could feel the difference when I was fixing something in an old project based on Rails 2—it even felt like hitting the wall in couple of places.

The community

I don’t need to tell you about differences between Ruby and PHP language, but I’ll compare their communities.

The most impressive thing to me was thinking about an architecture and patterns: DCI, Service Layer, Active Record madness, modularity, the rules of writing clean code… I’ve read about dozens of articles on the topics—all of them came from the Ruby community. It really impress me that whole community loves to learn new things and evolve constantly. On the other hand, things that the PHP world offered were just tips and tricks or practical advices for specific cases and tools.

Open Source is another big subject. PHP gave birth to many well-known free products: phpBB, WordPress, Joomla… Comparing them and the rest of open source PHP projects to Ruby’s, they might look like a midget. Thanks to GitHub, sharing source code became really easy; the Ruby community spread over it and the boom started. In result, we have better tools, better code, better skills, and—of course—the boost over our competitors that write in PHP.

When talking about sharing skills, I can’t just not mention RUGs and conferences. I’ve known about just one PHP conference and I’ve never heard about any local user groups. Wrocław has the awesome DRUG and we know many other RUGs in Poland. Yet, I’ve visited three Ruby conferences so far: RuPy, wroc_love.rb, and EuRuKo), but you can find them everywhere, every month!

Did I mentioned testing? Well… let’s not hit somebody when he’s down.

The future

I’m looking forward to the following months: Rails 4, wroc_love.rb 2013, DataMapper 2, discussions about concurrency, single page apps or making model layer thin. Even if I quit this community one day, I would always think fondly about Ruby, Rails, and whole community just for fun, some fresh air and to push me forward.

Thank you, Monterail’s founding fathers, for making me the part of the team and making me work in this awesome community.

The exploit could potentially tamper with some gems, therefore all of them are assumed to be unsafe to use at the moment. Which means that any deployment involving downloads of any gems from RubyGems.org should be carried out with extreme caution. All downloaded gems have to be verified in order to remain on the safe side.

The Ruby community reacted quickly— it’s now possible to compare checksums of downloaded gems with the checksums of their known-to-be-safe versions hosted on mirroring sites.

We use Capistrano for deployment, so we created a recipe to automate the verification process. It internally uses the validate_gem_checksums script (originally posted by James Tucker, then adjusted to our needs). It validates gems’ checksums after bundle install and aborts the deployment in case of any mismatch between the checksums.

namespace :bundler do
  task :setup, :roles => :app, :except => { :no_release => true }  do
    run "mkdir -p #{shared_path}/.bundle"
  end

  task :create_symlink, :roles => :app, :except => { :no_release => true } do
    run "if [ -d #{release_path}/.bundle ]; then mv #{release_path}/.bundle #{release_path}/.bundle.old; fi"
    run "if [ -f #{shared_path}/.bundle ]; then ln -nfs #{shared_path}/.bundle #{release_path}/.bundle; fi"
  end

  task :bundle_new_release, :roles => :app, :except => { :no_release => true } do
    bundler.create_symlink
    run "cd #{release_path} && bundle install --path #{shared_path}/bundle --without development cucumber test"
  end

  task :validate_gem_checksums, :roles => :app, :except => { :no_release => true } do
    run "curl -s https://gist.github.com/raw/4682614 -o /tmp/validate_gem_checksums.sh"
    run "bash /tmp/validate_gem_checksums.sh #{shared_path}/bundle/ruby/**/cache"
  end
end

after "deploy:setup" do
  bundler.setup
end

after "deploy:update_code" do
  bundler.bundle_new_release
  bundler.validate_gem_checksums
end

The usage of this validation script is quite straightforward:

bash /tmp/validate_gem_checksums.sh gem_cache_path

You need to pass the path to the cache directory of your gems, which is bundle/ruby/**/cache in our case. Yours may differ, so adjust accordingly.

Please note that it downloads the validation script from Gist every time it’s executed. For safety reasons, you should fork it and use own version.

The story

It’s amusing how seemingly trivial things can lead to the most exhaustive discussions and disagreements.

Just before pushing the new theme for the blog, we had a debate on the notorious social media buttons and whether or not we should include them on post pages. Half of the participants, under the shield of Oliver Reichenstein’s loud article, defended their ambivalence towards Like, Tweet, and +1 plague on the Web before the other half that was represented by actual users of the widgets—people who show their appreciation that way.

Our blog stats were somewhere in-between.

The solution

We eventually decided to create our own inconspicuous heart-shaped widget and hide all the social stuff at first. If a reader would like to express her enjoyment of the content in a way other than linking to Codetunes, she could still do it.

Custom “Love it” widget inspired by Behance’s “Appreciate this” sticker.

After the user action, we have more ground to assume that the reader might be willing to also use one of the social media buttons, so the third-party widgets appear next to the heart.

“Love it” after user’s action.

And all that is served with the juicy animation. I dare you to try it.

The response

Looking at our stats and adoption of the gizmo, we’re happy to report that the feedback has been veritably positive. We’ve noticed a slight bump in usage of the actual social media buttons too!

The lesson

If you can afford the time, just analyze. Even the smallest issues.

Remember that designing user experiences means making trade-offs and that you can’t blindly follow any advice without thinking it through. Not every pro tip is suitable for your project. It’s because, when doing stuff on the Web, the answer for “should we do X?” is almost always the same. It depends.