I've been working on a lot of non-Rails projects lately. At some point during the buildout process, I start spending a fair amount of time uploading my changes to one of our testing servers. I love Panic's Transmit FTP program to death, but repeatedly FTPing files gets dull after a while.
I needed a better system. So I wrote one.
Continue reading "Simple Command Line Deploy Scripts for Non-Rails Projects"
Bundler is a great tool to have in the Ruby toolbox, but it's also a bit mysterious to some developers. "Oh cool, I put my gems in this file, bundle install, and that's it. Wait, what's this Gemfile.lock thing? Should that go in my repo? What's the difference between bundle install and bundle update? How do I install my gems when I deploy? Where are my pants?" Let's take a tour of Bundler and find the answers to some of these questions.
As web developers something we often have to implement is handling file uploads. With Rails there are a number of plugins and gems for helping with this. The one I use most often is Paperclip. Out of the box, Paperclip does exactly what you want, and you don’t have to think about any configuration. But, as your application matures, your needs often change and some custom configuration is often required. One thing you’ll notice is that you can customize where the file is stored. The way that you do this (for those new to Paperclip) is:
has_attached_file :asset, :url => "/system/uploads/:class/:attachment/:id/:basename_:style.:extension"
On a recent project the client wanted us to store uploads in a very specific path structure. On the surface this seemed a simple enough request. As we dug deeper, though, it became clear that one part of the path needed to be based on the attribute of a model that was related to the model on which the file data was being stored. By default Paperclip only allows a limited set of values to be used in the path: filename, timestamp, rails_env, class, basename, extension, id, fingerprint, id_partition, attachment, and style. These predefined interpolations are all you need most of the time, but our case was the exception.
Blocks are one of Ruby's defining features, and though we use them all the time, a lot of developers are much more comfortable calling methods that take blocks than writing them. Which is a shame, really, as learning to use blocks in a tasteful manner is one of the best ways to up your Ruby game. Here are a few examples extracted from a recent project to give you a few ideas.
I’ve been heads-down for the last few weeks developing the web site for the new PUMA Social campaign. A major part of this site is a web-based game that rewards users for performing activities on various sites across the internet, and as such, I’ve become intimately familiar with the APIs of several popular web sites and their various — shall we say — quirks. I’ve collected the most egregious here with the hope that I can save the next developer a bit of anguish.
at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.
Future Insights Live -
April 29
to May 4
Future of Web Apps, Future of Web Design, Future of Mobile, and Future of Web in the Enterprise have joined forces to bring you our most comprehensive event EVER!