Musings about Entrepreneurship, Technology and Software Development
I’m sure everyone saw this already, right? In case you didn’t then it’s worth a look.
It amazes me (though it shouldn’t) how far a community of developers can take something vs. a software giant like Microsoft. It looks like open source wins against corporate. Sure, the results are not exactly scientific but interesting all the same.
The life of the web developer never seems to be easy, always a new problem cropping up.
One such issue surfaced when a client wanted to begin accepting credit cards. As most Internet users assume, they land on a web page asking for credit card information and it’s secure, I wouldn’t enter my credit card information without seeing the friendly little lock. Another telltale sign is seeing the https: in the browser address bar.
Many sites today make use of outside CSS and JavaScript files host on a content delivery network (CDN) somewhere on the interwebs. This has tremendous benefit for web developers and users alike, giving applications better performance. The problem arises when we have a secure page (https) which pulls in assets from non-secure CDNs, where requesting assets securely will fail to return successfully and ruins the user’s experience.
This application happens to be a Ruby on Rails application but that fact is irrelevant. The scenario is likely common today; we have a secure checkout page but our site contains menus and links to pages which are not sure but just plain http. When the users visit the site with their browser of choice they are presented with various messages or maybe none.
The problem was mainly centered-around the Yahoo YUI JavaScript and CSS assets and how they were included. This application uses the Yahoo content delivery network (CDN) to serve the assets, which is a great way to serve the assets.
I decided to do what every self-respected web developer does when facing a problem, Google for someone else who had the same problem and successfully solved it. I ran into one very insightful post from Dan over at CollectiveIdea. The post lays out a very similar problem with some good ideas for the solution.
Dan points out a URL like this:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js" type="text/javascript"></script>
Will cause Mixed Content warnings when included from a secure page. Some of the suggested solutions include downloading all of the assets locally and the problem goes away. Although this is true, we lose the benefits of using a CDN.
What works is both elegant and simple; two qualities that make my day. Referencing your CDN-based assets this way is only a slight change:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js" type="text/javascript"></script>Notice how we are referencing the GoogleAPI URL, we leave off the http: and the https:. By using two forward slashes only the request will resolve itself and work brilliantly.
Maybe I am the last web developer to find out this tidbit of information but I wanted to document it so the next one faced with this could find the answer here.
Simplicity is a beautiful thing. I love a simple tool which makes my life as a developer easier.
Ruby on Rails has made the life of the web developer much more pleasurable over the years but even so there are some things which could be made better. One such thing is running your Rails applications locally when developing. Every Rails developer is familiar with the script/server command if you are in Rails 2.3 and earlier or the rails server command if you are using Rails 3. The next step would be to fire up the browser and enter localhost:3000 into the address bar. Most of the time this works fine, but a bit tedious. The real problems appear when your application supports subdomains like myaccount.myapp.com, which has been hard to do up until this point.
Pow is a Rack server developed by the folks at 37Signals to help alleviate the pain of serving local Rails applications. Using Pow allows the developer to go from accessing their local Rails application using localhost:3000 to something like myrailsapp.dev. For example, my expense tracking software, Expens’d uses subdomains quite a bit, so we get URLs like rbazinet.expensd.com and when using Pow I can simply use the URL rbazinet.expensd.dev. This is perfect and simplifies the process.
Installing Pow is pretty easy and shown on the Pow web site but for those not interested in heading over there you can open up a terminal session and enter the following:
$ curl get.pow.cx | shEach application has to have a symlink defined. The Pow web site says to:
$ cd ~/.pow$ ln -s /path/to/my/appWhen I setup Expens’d to use Pow setting up the symlink this way didn’t work for me. I had to add the application name after the path, like this:
$ ln -s ~/rails_apps/expensd expensdSince Expens’d is currently a Rails 2.3 application, a config.ru file is needed and placed in the application root folder. The file should contain the following:
# RAILS_ROOT/config.ru
require "config/environment"
use Rails::Rack::LogTailer
use Rails::Rack::Static
run ActionController::Dispatcher.newIf Expens’d was a Rails 3.x application, I would not have had to create the config.ru file.
Your mileage may vary. Once the symlink is done heading to the browser you can just enter the domain for the application with the .dev extension, like expensd.dev. This works just perfectly.
One of the first things I wondered about when using Pow was a need to restart the “server” when I make changes to a routes.rb file. It turns out we treat this the same way we restart Passenger.
$ [APP_ROOT]/touch tmp/restart.txtUsing Pow provides us with the typical development.log file in the [APP_ROOT]/log directory. Keeping an eye on the log can be done from a terminal window.
$ [APP_ROOT]/tail -f log/development.logThis provides a nice way to see what’s going on. There is also a raw log file produced from Pow that gives some additional details.
$ tail -f ~/Library/Logs/Pow/access.logWhen I setup Pow on my Mac Pro it all worked perfectly from the get-go but on my MacBook Pro I ran into a problem when I tried to browse a URL served by Pow such as expensd.dev. DNS seemed to think I wanted to go to the Internet to find the site and I received a 404 error when I tried. The problem was known and is outlined on Rob Conery’s site. The first part of the solution involved running the scutil to see if .dev resolver was being used:
$ scutil --dnsYou should see a bunch of entries and one should look something like this:
resolver #8
domain : dev
nameserver[0] : 127.0.0.1
port : 20560I don’t know if Pow uses the same port all the time, so that may change. The key here is the domain, indicating dev. If this resolver is missing the solution is pretty simple, open the file /etc/resolver/dev and simply save it. Worked like a charm for me. Run the scutil –dns command from above and see if the resolver is now listed.
I think Pow is pretty awe some just as it is but it seems someone has stepped up to make it even better with a gem named Powder. I haven’t had the chance to play around with this tool yet but a blog post by one of it’s creators says they wanted to make Pow “ridiculously easy”. The commands supported help make Pow that much easier:
$ powder applog
=> tail the log of the current app
$ powder config
=> Get Pow's current configuration information
$ powder list
=> List all the current apps linked in ~/.pow
# aliased as powder -l
$ powder log
=> Tails the pow log.
# Not the application log, but the pow log, available at
# ~/Library/Logs/Pow/apps/#{app-directory}.log
$ powder open
=> Opens the pow link in a browser
# aliased as powder -o
$ powder open bacon
=> Opens http://bacon.dev in a browser
# if you have set up alternative top level domains in .powconfig,
# then the first listed domain will be opened.
$ powder restart
=> Restart the current app
# aliased as powder -r
$ powder status
=> Get Pow's current status information
$ powder version
=> Returns the current powder version
# aliased as powder -vSince Pow is serves up Rack apps the possibilities are pretty endless. I found one bit to share where someone is using Pow to serve his PHP apps, pretty clever. I would imagine this technique could be used in many applications like this.
The only thing I can say is I love Pow. It has made my life so much easier. Thank you 37Signals.
Today the great team led by Wayne Sequin (rvm fame) and Luis Lavena (RubyInstaller fame) and initiated by Dr. Nic Williams of Engine Yard released RailsInstaller.
RailsInstaller is really what Instant Rails brought to Windows developers wanting to write Ruby and Ruby on Rails code, but now evolved. RailsInstaller takes Ruby and Rails to their current versions and add some other niceties to give the Windows developer the ability to create real Rails applications today. Included is:
I would expect that we would see a Ruby 1.9.2 at some point but imagine there must be some technical hurdles to get beyond before it makes sense to release.
Installation is a breeze by just following the simple installation wizard all Windows users know all about. A nice video has been created to show how to install and get started:
The video is very clear and the installation wizard really simple, just follow the directions and keep the defaults for the best experience.
The installer explains clearly what is being installed in this particular version.
The default is to add to the PATH statement. I would recommend keeping this so your system knows where to find all the needed executables.
You should notice a nice shortcut to a Ruby and Rails prompt all setup to use.
The Ruby version as well as the Git version are cleanly shown. You are good to go.
I was lucky enough to have a prerelease build of the tool and even in a prerelease state, they guys did a great job. It was easy to create Rails apps and have them running in no time. Keep in mind that not all Ruby gems will yet be compatible with Windows. If you encounter issues you are best advised to contact the person in charge of the gem project you are trying to install.
I encourage everyone to who is interested in Rails on Windows in a clean package to download the installer now and give it a go.
Ruby on Rails 3 was released just a short time ago and is a fairly big changed to previous versions of the Rails framework. People are starting to put together some great content to help developers come up-to-speed on Rails 3.
I began looking around for some Rails 3 content for my own use, even though I use a variety of beta books for the purpose, I found these resources really useful. This brought me to the realization some readers may find value.
This is such a great resource; offering a range of content that includes a Ruby on Rails Tutorial book as well as a set of videos with material from the book. The book is available to read on-line, purchase as a PDF or the dead tree version available from Addison-Wesley.
The videos are a real sweet spot in my opinion, with 15 hrs of video training for $85. Try to get 2-days of training from anyone at that price.
Table of Contents
- Rails installation (OS X/Linux) (13m)
- Git .bashrc lines
- Rails installation (Windows) (8m)
- Lesson 1: From zero to deploy (46m)
- Lesson 2: A demo app (1h11m)
- OS X testing setup (8m)
- Lesson 3: Mostly static pages (57m)
- Lesson 4: Rails-flavored Ruby (1h45m)
- Lesson 5: Filling in the layout (1h10m)
- Lesson 6: Modeling and viewing users, part I (1h30m)
- Lesson 7: Modeling and viewing users, part II (1h40m)
- Lesson 8: Sign up (1h22m)
- Lesson 9: Sign in, sign out (1h36m)
- Lesson 10: Updating, showing, and deleting users (2h25m)
- Lesson 11: User microposts (2h03m)
- Lesson 12: Following users (2h19m)
I have gone through both the book, Rails 3 version, and the screencasts looking for nuggets of information I may not be aware of in Rails 3. The screen casts are presented in a such a well-thought-out manner that makes them easy to follow and will not put you to sleep.
Michael covers a lot of great basic topics but also includes specific coverage of such things as setting up and using Devise for authentication. He also covers Test-Driven Development (TDD) very well using RSpec. There are a lot of how-to tips with TDD alone to save you hours.
I always love the content put out by PeepCode and Geoffrey Grosenbach and his recent Meet Rails 3 Part 01 was no exception.
This screen cast covers the beginning aspects of getting into Rails development both on Mac and Windows. I was pleasantly surprised to see my blog post Running Rails 3 on Windows was used as a reference for users to setup and use Rails 3 on Windows.
PeepCode has been providing screencasts for a long time and is likely to the first to offer those covering Ruby on Rails.
The Dive into Rails 3 screencasts put out by Gregg Pollack were probably the first series focused on Rails 3 right around the time Rails 3 was released.
Gregg covers many of the hot topics emerging in Rails 3 today:
These are screencasts talk about what is new in Rails 3, so some knowledge of Rails 2.x would be helpful to get the most out of these.
Ryan Bates has been making the weekly release of a RailsCast what seems like forever now. Currently there are 240 episodes up on the site, and by my precise calculations..that’s around 4 1/2 years of great content. Most episodes range between 10 and 15 minutes of focused content on a particular topic.
At last count Ryan had 25 screen casts covering different aspects of Rails 3 from the basics to new validations to implementing Devise. These episodes are laser focused to they are best used with some prior knowledge first, possibly go through the Tekpub or RailsTutorial first.
The Rails 3 series from TekPub currently has 6 episodes running 5+ hours. The typical series from TekPub is one that starts off with a single episode with more added over a few weeks.
I have been a Tekpub subscriber since it first opened in October 2009 and love the format of their training.
This series is promoted as:
In this series Rob Conery shows you Rails 3 and the core concepts involved. The focus of this series is a bit more practical than theoretical – with the goal of showing you not only Rails, but many of the tools to help you get your site up and running quickly and effectively.
Rob has a been doing screencasts for a long time and has really honed his voice to be the soothing voice you hear on each episode. Each episode is on a different topic and covers it very well in the 1 hour dedicated. As I write this, Rob has 6 episodes:
Long-time Ruby and Rails community member Jeremy McAnally has written up this great handbook on how to take your pre-Rails 3 application into the Rails 3 world.
So many projects exist out in the wild that his handbook is invaluable.
Unlike the other resources I have listed, this is not a screencast but is available as an ebook. I felt is was just such a great resource for Rails 3 and it tied in so well with coming up-to-speed on Rails 3 and the likelihood you might be upgrading a Rails 2.x application to the latest.
The guide is a beauty, it really covers the pain points a developer will face when upgrading their application to Rails 3 and shows how to get around them. He includes use of his gem to help with the process as well as checklists for deprecations and the upgrade process itself.
Moving your application to Rails 3? You need this guide.
Well, the long-awaited release of Ruby on Rails 3 is now out and all of the Mac and Linux junkies are busy gem-installing the latest version of the framework. What about all the lonely Windows developers out there looking through their windows (pun intended) and wondering what it’s like on the other side of the fence?
Good news! It is actually pretty easy to setup and run Rails 3 on your Windows system. I mainly run on Macs these days but have a couple Windows systems still kicking around and thought I would give a go. It is actually pretty straight-forward now and works really well. Follow the steps:
Rails 3 requires at least Ruby 1.8.7 and is happy using Ruby 1.9.2, I opted for the latest and greatest.
Running the Ruby version command from a new command prompt:
ruby -v
If you get a file-not-found or some other undesirable result then the path setting isn’t likely correct or you may want to try closing the command prompt and opening a new one.
This is a tough one:
gem install rails
UPDATE: A reader points out of issues with installing Rails as pointed out by a post on the Ruby Forum. The issue was solved by simply adding a –pre to the gem command to install Rails.
gem install rails --pre
Everything you need to run Rails 3 gets installed with the exception of the SQLite3 Ruby gem which Rails uses as the default database provider:
gem install sqlite3-ruby
You should see a message similar to this:
I use SQLite3 for most of my local development unless I need a database like MySQL or PostgreSQL. Installing is trivial.
If you look at the above message when installing the sqlite3-ruby you should notice the gem relies on the sqlite3.dll and it is recommended to use version 3.6.23.1, which you can download form here. I grabbed 3.7.2 and it seems to work fine, your mileage may vary. If you’re interested, get the latest from the SQLite3 downloads page.
Now with the sqlite3.dll in hand (unzipped from the download), copy to the bin directory of the above Ruby installation. In my case that’s C:\Ruby192\bin, and that’s it.
Now it’s time to test the new Ruby and Rails installation. Pick a location to create the new application and run the new Rails command from a command prompt:
rails new testapp
This command creates a new directory called testapp and spits out a bunch of text along the way, looking something like this:
Once done, change directory into the new testapp directory and run:
rake db:migrate
This will test your SQLite3 installation and create a new development database in the testapp\db directory called development.sqlite3. If you get any errors it is likely the sqlite3.dll is not in your Ruby bin directory, check and come back.
Now from the testapp directory, fire up the Rails development server from a command prompt:
rails server
WebBrick fires up and looks like this:
If there are errors reported than something has gone wrong. If you see this screen, fire up your browser and browser to the address http://localhost:3000. If all goes well, you will see this screen:
Click on the link below the title that reads “About your application’s environment”. This gives a lot of detail about your Rails application configuration.
Congratulations! You have the latest and greatest Ruby and Ruby on Rails running on the Windows platform.
Now go out and read Mike Hartl’s Ruby on Rails Tutorial for Rail 3 and create some applications.
RailsConf 2010 was this past week in Baltimore, MD. I decided to make the trip down from CT since it was only about 5 hours by train. Many people have already covered the conference around the interwebs and I am not doing it here.
I had a great time, meeting many new friends and catching up with some old ones. I arrived on Sunday evening and attended the Ignite RailsConf event. This event had excellent content and was well attended with about 200 people coming out.
Monday came and we had a full schedule of 3-hour tutorial sessions. These were good but the unfortunate thing about multi-track events is missing some sessions I would like to see. It appears the keynotes were the only sessions being recorded, which is too bad.
The keynotes were really one of the highlights of the event for me. I get the most out of these as they are typically by members of the software development community which are not necessarily Ruby or Rails related. The exception here was really Gary Vaynerchuck, which I missed because I was traveling home. Thankfully, O’Reilly was recording these sessions and I can watch when I have the time.
Anyone who did not attend RailsConf should check out the recorded keynote sessions from DHH, Yehuda Katz, Derek Sivers, Robert Martin, Gary Vaynerchuck, Michael Feather, Neal Ford and Evan Phoenix.
The sessions were overall pretty good and I enjoyed the ones I attended, but I wish I could see other sessions than just the ones I attended. I think we should petition O’Reilly to record all talks.
Attending all these sessions during the week were really exhausting. As I write this on Saturday I still feel tired and imagine I won’t feel rested for a few days.
I have come to learn that the real value of any conference is not the knowledge acquired while attending the sessions but the friends and acquaintances we see and the new relationships formed.
I met many people who I knew only from the online world, interacting on my blog or Twitter. I was fun to see how the people looked different than their Twitter pictures, many look very different.
I did have a good time at RailsConf but it was exhausting. As I write this today I am still really tired from the 5 days I was away.
I find it interesting how people take in a conference, how they spend their time. As I attended talks I looked around the room to see a sea of Apple logos of the MacBooks in the audience. I noticed people with their MacBooks spending the session writing code, surfing the web or using Twittering. I repeatedly wondered why people make the effort to attend a session yet do something other than pay attention to the speaker.
I have been to both large and small conferences and especially after this RailsConf, I keep think that smaller single track conferences are the way to go if you want the chance to have a richer environment. I missed several people I wanted to meet but never ran into them, which goes to show the size of the group. Smaller conferences typically have 100-200 people and gives attendees a better chance of seeing everyone.
I am looking forward to attending more computer science and engineering related conferences this year as well as some business-specific ones such as BizConf. I think these are the types of conferences I will gain more value from, rather than simply Ruby-specific. I hope to see you at a conference soon.
The release of the web framework, Ruby on Rails 3, may lead to some pretty interesting decisions for current Rails developers.
The description of Rails 3 from the Agile Web Development with Rails 4th Edition (beta) book from the Pragmatic Programmers web site sums it up pretty well:
Rails 3 is a major release—the changes aren’t just incremental, but structural. So we decided to follow suit. This book isn’t just a mild reworking of the previous edition to make it run with the new Rails. Instead, it’s a complete refactoring.
Rails 3 introduces many new things, many new conventions. Version 3 looks more like a new framework, rather than just a version upgrade. Previously, the amount of effort to move from one Rails version to another was pretty small and unit tests helped reveal problems. We still rely on our unit tests for this purpose but the effort is not as small.
Rails 3 does offer many fantastic new features and the new architecture attempts to fix problems and areas where the current Rails framework falls short, but at what cost? I have heard people say over and over, moving to Rails 3 is difficult. Will this prevent migrating projects to Rails 3?
Jeremy McAnally has written a great ebook titled Rails 3 Upgrade Handbook where he outlines the tasks developers will face when moving existing Rails applications from version 3. To quote Jeremy from the book about moving applications to Rails 3:
The new features, performance improvements, and API changes aren’t incredibly drastic, but they do present great opportunities (and challenges) to those looking to upgrade existing code to the newest version.
Jeremy also has a plugin that became an official Rails plugin that helps guide the developer through the upgrade process.
I know with certainty there are Rails developers concerned up moving existing code to a new Rails, new conventions. One of Rails strengths are the convention it employs and as developers we learn the intricacies of our framework the hard way. Rails 3 will require an education to learn the new conventions.
Could this be a point in time where faithful Rails developers move on to a different framework? I doubt devotees won’t, but maybe some.
Case in point, Microsoft Active Server Pages.
I have witnessed and been involved with this before when Microsoft created a web framework named Active Server Pages, referred to ASP. After a much successful growth of ASP developers, Microsoft decided to create ASP.NET which is their current web framework based on webforms.
The problem was that even though the product names were very similar, the truth was they were drastically different. Developers were faced with:
Developers were faced with making the jump to ASP.NET or deciding to move on to something else, leaving behind the gripes of Microsoft. Some moved to PHP, as it resembled ASP more than ASP.NET. Some moved to legacy ASP project to Rails, the views looked more like ASP than ASP.NET
Up until this point, Rails has been a pretty smooth transition from version to version, even when applications were running older versions of Rails such as 1.2.x and moving to 2.x was pretty straightforward. I moved many Rails 1.2.6 applications to 2.x and faced little major issues, certainly not a rewrite.
This is not the case when moving to Rails 3, there is no smooth upgrade path and users will be forced to rewrite significant parts of their applications.
The architecture of Rails has changed in a big way, mostly by Yehuda Katz of Merb fame. Rails 3 takes the good from Merb in many ways, as I would expect. The view from 50,000’, Rails 3 does not closely resemble Rails 2.x as we know it today.
As was the case with Classic ASP, I think developers either bit the bullet and rewrote their applications with pain and learning, stayed put and are still there today or moved to a different web framework, maybe Rails, maybe PHP.
I think we are at this point with Ruby on Rails. Developers are faced with the task of moving to Rails 3 and making that technical leap, not to a new programming language as with ASP.NET, but a new framework. Rails 3 is different enough from any previous version that moving existing application will not be a rewrite but a change enough to be a considerable effort. Rails developers are well versed in how the framework functions, Rails 3 is very different.
This may be an opportunity for other frameworks to gain some traction. New developers considering Ruby on Rails 3 have a bigger challenge with the framework, it is not exactly the framework DHH developed only a few years ago.
Other frameworks worth considering:
I could be wrong here but I think the advantage Rails had with an easy-to-learn framework, great productivity and easy upgrades will be a bit strained in Rails 3.
This will surely be a great opportunity for developers well-versed in Rails 3 to start or expand consulting career helping companies with existing Rails code bases upgrading to Rails 3. I think these folks will be in high demand.
So what will happen? I don’t know. Rails is a great framework but converting a large code base is going to be a challenge and Rails 3 is the future, not the 2.3.x code base.
I know I have asked more questions than I have answered. I hope the powers that be in the Rails leadership understand the concern.
UPDATE: As comments have pointed out, if this sounds Rails-negative, it is not meant to be. I see this a call for people with knowledge of Rails 3, bits of experience with upgrading projects of any size to share the knowledge. Blog about what you did, even the most mundane details and share what you know so jump ship DOES NOT happen.
The second annual Acts As Conference 2009, a regional Ruby conference, dates and venue has been announced. The event will take place February 6 & 7, 2009 in Orlando Florida at the Ramada Orlando Celebration Resort & Convention Center, located near all things Disney. One of the best parts about the event is the cost…only $125.
The venue is different than last year and has the capacity for 175 attendees. The line-up of talks will include lightening talks as well as more talks than last year. Robert Dempsey, event organizer, says a call to for papers is coming soon, so get your talk ready.
Keep up with what is going on with this conference on their mailing list. You can also help spread the word by putting a badge on your web site like the one at the top of this post.
I attended the last acts_as_conference, had a great time and met many people. I intend on heading down this year as well to enjoy some more mingling and the warm Florida weather after enduring winter here in New England.
I was supposed to be at RailsConf this year covering the event for InfoQ, but I am not there. Sometimes higher priorities overtake the things we would like to do and well, I am home. 
One of the announcements I thought might be coming at the event was the release of Ruby on Rails 2.1 and sure enough, it was released. The details are covered on the Riding Rails blog:
Rails 2.1 is now available for general consumption with all the features and fixes we’ve been putting in over the last six months since 2.0. This has been a huge effort by a very wide range of contributors helping to make it happen.
Over the past six months, we’ve had 1,400 contributors creating patches and vetting them. This has resulted in 1,600+ patches. A truly staggering number. And lots of that has made it into this release.
New features
The new major features are:
- Time zones (by Geoff Buesing): Tutorial | Introdction | Railscast
- Dirty tracking: Introduction (partial updates) | Railscast
- Gem Dependencies: Introduction | Railscast
- Named scope (by Nick Kallen): Introduction | Railscast
- UTC-based migrations: Introduction | Railscast
- Better caching: Introduction
Thanks to Ryan Daigle for the feature introductions and Ryan Bates for the Railscasts. It makes writing the release notes so much easier :).
As always, you can install with:
gem install rails…or you can use the Git tag for 2.1.0.
None of these features actually stand out as the killer feature for this release but is instead a bunch of steady, solid improvements. Installing the update went without a hitch and my applications on my development system all ran without issue.
Notice the Railscast that accompanies the bulleted points above, they make a nice touch.