I did an 8-day sprint to launch my Build a Ruby Gem email course and documented my progress through this series of blog posts.

Day 1 | Day 2 | Day 3 | Day 4 | Day 5 | Day 6 | Weekend Update Summary

Alright, back at it! I didn’t quite hit the 5:00am goal I had, but was early enough to accomplish what I was shooting for. (Setting my alarm for 11:58pm because namecheap.com had hourly Cyber Monday coupon codes didn’t help…).

What I Accomplished today

Today I wrote the first post out of 5 and it went relatively smooth. Yesterday I created a rough outline for the course content using Evernote. I’ve used it mainly as a place to spew out the ideas that are not necessarily organized, but just general notes about things I want to make sure get covered (imagine that, using Evernote for notes?!?!).

continue reading →

I did an 8-day sprint to launch my Build a Ruby Gem email course and documented my progress through this series of blog posts.

Day 1 | Day 2 | Day 3 | Day 4 | Day 5 | Day 6 | Weekend Update Summary

JFDI

Living outside a major metropolitan area has made it hard to surround myself with other entrepreneurs. Fortunately, the internet has made the world a smaller place. Last week I joined JFDI.bz, a community for solo-founders launching their own thing.

My goal for joining this community was to have access to other motivated entrepreneurs that I could use as a sounding-board. I also figured it’d be great opportunity to peek in to other solo founders launch process and motivation for a particular product.

Week of Hustle

Week of Hustle is an 8-day sprint to launch something. Anything really…could be an existing product that you need to put the finishing touches on, or a brand new idea. It was one of the things that attracted most to JFDI.

Launching any kind of product is time consuming. And with a family and other full-time responsibilities, life can get in the way. I feel like I’m pretty good at managing my time efficiently, but when accountability is involved, it’s much harder to put it off.

continue reading →

Setting up a CDN to host assets is one of the first performance improvements I make to a production Rails application. The first time I attempted to host assets from a different domain, I quickly realized that Firefox won’t download fonts from a different domain without specific headers.

Nginx Fix

At the time, our system was using Nginx to serve assets that were fronted by a Amazon Cloudfront CDN. In order to make it work with this setup, I had to add to the following to our Nginx configuration:

location ~* \.(ttf|ttc|otf|eot|woff|svg|font.css)$ {
    add_header Access-Control-Allow-Origin *;
    expires 1M;
    access_log off;
    add_header Cache-Control "public";
}

Update: I’ve since added a post on serving fonts for Firefox with Fastly.

Implementing a CDN to serve compiled assets in Rails is one of the most significant performance enhancements I’ve seen. Having done so for 2 fairly large applications, it’s hard for me to imagine serving assets locally anymore.

The Asset Pipeline

The addition of the Rails asset pipeline has reduced both the number of assets served and the size of these files. Users on slow connections have been the biggest beneficiary of these changes.

The Problem

Even with the asset pipeline, content is transmitted to the end user over their, sometimes slow, connection. Distance plays a role in the speed at which data can be delivered. Because of this, users further away from your servers get a sluggish experience. This decreases both the users’ patience and your ability to effectively engage them.

Rails Rumble

The 2013 Rails Rumble concluded last week and like in previous years, Dwellable analyzed the Gemfiles of the submitted projects.

While it’s not an indication of the only gems used in the Ruby community, it’s a pretty good summary of the most common needs in a typical Rails app.

• The majority of the projects used Rails defaults of Coffeescript, Sass, jQuery, and ERB

• Only 37% of the projects used Bootstrap. I thought this number would be higher. It feels like every MVP out there starts with bootstrap.

A variation of this post originally appeared on the Rails Masterclass newsletter.

Learning new technologies can be a challenge. With books, forums, videos, blog posts…where do you start?!?! I’ve used all these resources in the past and only one thing has reliably led to me to really learn the concepts - building something REAL!

How I learned Ruby and Rails

Several years ago, I was learning both Ruby and Rails and trying to figure out which books were worth the time. I ended up starting with Agile Web Development with Rails, which was a fantastic introduction to the features and benefits you’ll get from learning the Rails framework. However, like many other books, it guides you through building a website with little real world value - an e-commerce shopping cart (you’ve heard this one before, right???). The concepts in the book generally apply to other products built with Rails, but it was sometimes hard for me to see their value elsewhere. I found that the books and articles often skipped over things that were fairly trivial for a more experienced developer, but essential to get a real world application out the door.

I’m writing a book on building a Ruby gem. If you’re interested in sample chapters and a 20% discount code when the book launches, sign up here . The book will include tips for managing and contributing to open source projects.

Towards the end of 2012, I began feeling like a had a good grip on the Ruby language. As mentioned in a previous post, I felt confident enough in my skills that I could make a positive contribution to the open source community.

I learned a lot by watching certain projects and getting involved with others and hope that my notes are helpful for you and your endeavors.

1. Fix a bug in an existing gem because it affects you

My experience with Meeteor and Spokely caused me to move FAST and break a lot of things along the way. Because of the pace, when I did find a bug, I wasn’t great at contributing code back to the source repository. In many cases, my fixes were brute force monkey patches or something else that I would probably be pretty embarassed about today.

Last weekend, I finished an Ironman. The training consumed valuable time with both family and friends that I’ll never get back. However, the support and love that I received on the days surrounding the race have given me an increased appreciation for the people that are in my life and the unwavering support they offer.

Finishing the race was an incredible experience. The day of the race had its share of extreme ups and downs, both of which I’ve come to value now that it’s over. Since I no longer have to worry about waking up at 5 a.m. to get to gym, I’ve spent a fair amount of time replaying the past 30 weeks and the sacrifices involved.

For the past few years, I’ve spent most of my waking moments either reading about or writing code. For me, it’s about the constant pursuit of learning and getting better at my craft. In hindsight, I can say that that mentality has helped me have a leg up on the competition (for reasons I will detail in future posts).

Rewind 4 years

Four years ago I was writing PHP on the side for startups and just getting into software products as both a profession and hobby (more on this too…). I had reached a level of comfort with PHP where I knew I could solve just about any business problem thrown at me. This feeling was not only comforting, but empowering. Shortly after, I helped create Meeteor, which was written in Rails and my world took turn for the better.