Command Line Recipes √Ä la Stitch Fix

Here is a list of command line recipes that make day to day life a little easier at Stitch Fix.

http://technology.stitchfix.com/blog/2015/04/09/stitch-fix-heart-unix/

Maybe you will find some of these useful for projects you are working onūüôā

Color Rspec Output for All Projects

Ran into an issue today where I wanted rspec to use color output regardless of whether or not the project had it set up in the .rspec or spec_helper.rb files.

A super simple way to do this is to update your .bash_profile and override the rspec command with the colour switch:

vi ~/.bash_profile

Add the following to .bash_profile and save:

alias rspec='rspec --colour'

Reload the file:

source ~/.bash_profile

And you should be all set! Just run rspec as you normally would and the colour switch will be added automatically via the alias.

Five Benefits to Remote Work You May Not have Thought Of – A Review of Remote – Office Not Required

I’ve just finished Remote – Office Not Required, a book by 37Signals founders Jason Fried and David Heinemeier Hansson (also creator of the web framework, Ruby on Rails). Jason and David run the Basecamp project with great success using a small army of remote workers. downloadThis success has made them prophets who declare¬†the benefits of remote work to companies who do not see its value, or fear it altogether.

As a remote worker myself, who spends three days a week working from home, and two days in the office an hour and a half away in Cleveland, Ohio, I wasn’t sure if Remote would offer any nuggets about remote work that I didn’t already know and agree with.

I was only partly right.

Jason and David’s analysis of remote work gave me a greater appreciation for the paradigm and also for those companies that have embraced the¬†remote workplace ideology, such as where I work at Within3.

Here are five of my favorites.

1. Eliminating the Commute – Sure, I am acutely aware that removing a commute is a huge benefit to remote work, but for someone like me, who is smack dab in the middle of nowhere between job hubs like Cleveland, Columbus, and Pittsburgh, Remote reminded me of how awesome the ability to mitigate such a commute really is. Without the advent of remote work, an hour and a half drive back and forth every day for five days a week would have seemed daunting (even for someone like me who loves driving). But that drive two days a week is just right, enabling me to enjoy other benefits of working from home, along with the benefits of working in a bigger city a couple times a week, especially lunch at great restaurants with my co-workersūüôā

2. Health – So I mentioned I love eating at restaurants. Food is definitely a passion of mine. But if I worked every day in a restaurant hub like Cleveland, my belt would be snapping off in a few weeks! Plus, the long commute would not offer me much time to exercise in the morning or evening during a work day. But since I work from home three days a week, after work, I can trade in what would be a long ride home in for a run (at least in the summer, winters in NE Ohio¬†are awful!). That way I have more room to eat on the days I’m in Cleveland!

3. Time Flexibility РRemote work gives you the ability to get your average forty hours a week in any time during the workweek. My wife and I just had a baby, so that time flexibility really pays off when you are juggling work with visits to the midwife or pediatrician.

4. Productivity Analysis¬†– When you are working remotely, you must be judged primarily on your ability to produce, not just where you are sitting from nine to five. It’s extra motivating to know that your project success rate is how¬†¬†your company will perceive your value to them. It forces you to manage your time appropriately to get the job done!

5. The Ability to Hire Talent Anywhere – For years, companies have been restricted to offering employment exclusively to home town boys and girls, or try to woo outside talent into the home office city. If the talent didn’t want to move, the company was out of luck. Now, with remote work options, great people can be hired from all over the world! And an added benefit is that if a current employee needs to move out of the home office city for whatever reason, the ability to work remotely could may keep them with the company, saving that company time and money in finding a replacement.

Remote РOffice Not Required is a book with a clear mission Рto convince companies that currently do not offer remote options, or are skeptical of remote work, to embrace dramatic shifts in their thinking. It is also a rallying cry for those workers who are trying to convince their current employer to offer remote work options. But for people like me, who are currently enjoying those benefits already, it is valuable reminder to appreciate what you already have, the company leadership that makes that remote work possible!

The Lean Startup – Deep Insights into Startup Best Practices

If you work for a startup in any sense, or have entrepreneurial visions of grandeur, The Lean Startup by Eric Ries will make an excellent addition to your bookshelf. Eric Ries, a seasoned entrepreneur and co-founder of IMVU (an 3D avatar based chat room), has crafted an excellent introduction to startup best practices. From inception to maturity, any startup, whether a seedling or an The Lean Startupoffshoot from a well established business sequoia, can gain valuable information on how to use lean startup methodologies to help eliminate wasteful activities and instead focus on the projects and techniques to help break through the bonds of linear growth and achieve the exponential.

What I found most interesting about these best practices was the initial focus on a minimal viable product to test customer interaction and appreciation of a particular business idea. By building a rough draft of a product or feature, and unleashing it into the wild (even in perhaps an imperfect state), a company can gain valuable insights into whether or not the feature will gain traction with customers. Through the use of real life startup stories, Ries demonstrates how spending many months of careful planning, only to release¬†a product that is ‘not quite’ what the customer is looking for, can cost a great deal of unnecessary time and energy. If instead, products and features are built to be ‘just good enough’, valuable customer data can be gathered, and utilized to either enhance the minimal viable product to make it more production worthy, or pivot onto something else that may be more valuable to the customer.

This customer-centric approach permeated the entirety of the book, which, coming from a developer’s standpoint, is not something I feel¬†we generally¬†think about enough. Developers are often extremely code-centric in their thinking. This is certainly important (don’t want to build complete junk, even if it is only the minimal viable product), but we also should not be oblivious to the business needs of our customers. Ries emphasizes that in a startup, all employees and stake-holders, regardless of roles, should be in constant communication with each other to ensure the system being built is indeed for the customer. And while participating in business thought and discussion, developers can gain deeper insight into customer needs, helping them avoid rabbit trails and design the most appropriate system for any particular feature. At Within3, the startup I currently work for, company and product managers, business development, and customer support weekly share goals and practices which I definitely appreciate. It helps me feel more integrated into the company as a whole, and offers the engineering team the opportunity to better understand both the in-house and customer needs for our business.

While reading The Lean Startup, I did feel some of the points were hammered home a little to hard, and I found myself zoning out in a few places where the information¬†seemed overly redundant or was presented like a college lecture. But thankfully, Ries would toss a real life startup story my way and re-engage me. I found the stories by far the most interesting and helpful aspect of the book and the most effective tool in validating¬†Ries’ suggestions.

All in all, a good read and a valuable looking glass into the moving parts of the startup engine and how to make them churn along as efficiently, and powerfully, as possible.

Three Alternatives to Objective C for iOS Development

Are you interested in building an iOS¬†app,¬†but not¬†eager to learn Objective-C? You’re not alone! Objective-C is¬†chained by¬†the bonds¬†of C compatibility, and when¬†compared to dynamic languages and their frameworks, such as Ruby and Rails, it is not the most pleasant thing to jump into. Although the power C based languages¬†offer can be¬†extremely useful, it seems that in the modern age of software development, iOS¬†development could be made more pleasurable.

Thankfully, iOS software developers have choices!

Continue reading

Nokogiri and the Ruby SAML Toolkit

I ran into a problem today while working with the Ruby SAMLToolkit, an open source project by the OneLogin Identity Provider. This toolkit offers a relatively easy way to implement SAML authentication into your Rails application. Ratified in 2005 as an OASIS standard, SAML is definitely a great protocol to use for single sign on solutions in your application.

Since SAML is an XML based protocol, I’m sure you can image that in the Rails world, the nokogiri gem would prove useful in implementing SAML single sign on inside a rails app, since nokogiri enables robust document parsing, which is needed for the XML used by SAML.

And sure enough, the Ruby SAML Toolkit utilizes nokogiri!

But there’s a gotcha here. Nokogiri has a¬†Nokogiri::XML module with a few constants:¬†XML_C14N_1_0,¬†XML_C14N_EXCLUSIVE_1_0, and.¬†XML_C14N_1_1. These constants are utilized depending on the¬†standard serialization of the SAML XML being processed during the single sign on handshakes between your application and the identity provider. Continue reading

Tagged , , , , ,

System Tests vs. Unit Tests

System Tests vs. Unit Tests

A very interesting article by¬†David Heinemeier Hansson¬†Describing the greater value of system tests over granular unit¬†tests. I’ve definitely seen some of David’s¬†points¬†play out in web systems more concerned about users interacting with the interface than intricate calculations. Although, for those web applications where one small bug might cause significant monetary loss, like in financial related software, seems unit tests would still be extremely relevant.

computerbug