Oh My Zsh gets an auto-updater

I wanted to publically thank everyone for helping me get Oh My Zsh out there and continue to improve it. Many of us spend a lot of time in our terminals throughout the day and I firmly believe that having a well-working shell is nearly as important as having a well-working texteditor.

While Oh My Zsh isn’t a large project, it is my attempt to share what I’ve learned about using zsh with others… but honestly, my goal is to learn from you. I don’t have a lot of time to really dive into the deepend of the zsh-pool so am relying on others to share their tricks, hacks, functions, themes, etc. So, I thought that if I created a basic framework with outlined some conventions so that others could contribute, that perhaps I’d end up with a kickass shell.


So far&#8230; Oh My Zsh has been <a href="http://github.com/robbyrussell/oh-my-zsh/network">forked on github <div class="post-limited-image"><img src="http://img.skitch.com/20091001-gsgeh75peiebfs8y6146xuu7r8.preview.jpg" alt="Terminal 2014 zsh" /></div>

Continue reading “Oh My Zsh gets an auto-updater”

Oh My Zsh gets an auto-updater

I wanted to publically thank everyone for helping me get Oh My Zsh out there and continue to improve it. Many of us spend a lot of time in our terminals throughout the day and I firmly believe that having a well-working shell is nearly as important as having a well-working texteditor.

While Oh My Zsh isn&#8217;t a large project, it is my attempt to share what I&#8217;ve learned about using zsh with others&#8230; but honestly, my goal is to learn from you. I don&#8217;t have a lot of time to really dive into the deepend of the zsh-pool so am relying on others to share their tricks, hacks, functions, themes, etc. So, I thought that if I created a basic framework with outlined some conventions so that others could contribute, that perhaps I&#8217;d end up with a kickass shell.


So far&#8230; Oh My Zsh has been <a href="http://github.com/robbyrussell/oh-my-zsh/network">forked on github <div class="post-limited-image"><img src="http://img.skitch.com/20091001-gsgeh75peiebfs8y6146xuu7r8.preview.jpg" alt="Terminal 2014 zsh" /></div>

Continue reading “Oh My Zsh gets an auto-updater”

Oh My Zsh gets an auto-updater

I wanted to publically thank everyone for helping me get Oh My Zsh out there and continue to improve it. Many of us spend a lot of time in our terminals throughout the day and I firmly believe that having a well-working shell is nearly as important as having a well-working texteditor.

While Oh My Zsh isn’t a large project, it is my attempt to share what I’ve learned about using zsh with others… but honestly, my goal is to learn from you. I don’t have a lot of time to really dive into the deepend of the zsh-pool so am relying on others to share their tricks, hacks, functions, themes, etc. So, I thought that if I created a basic framework with outlined some conventions so that others could contribute, that perhaps I’d end up with a kickass shell.

So far… Oh My Zsh has been forked on github 25 times and is being watched by over 100 people.

Last week, I pushed out an update that introduces an auto-update feature. I’m quite keen of desktop applications that can auto-update themselves, so our initial version of this feature will ask you no more than once a week if you want to check for updates. This means that as we continue to extend and improve Oh My Zsh, you can keep up-to-date.

Terminal 2014 zsh
Uploaded with plasq’s Skitch!

It’s the beginning of a new month… are you still using Bash? Perhaps you’re using your own zsh configuration but want to see what else zsh can offer you? I invite you to install Oh My Zsh today. 🙂

Just run this in your terminal and you’ll get setup. Don’t worry… you won’t lose your existing configuration. 🙂

wget http://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

For more infromation, visit http://github.com/robbyrussell/oh-my-zsh/

It’s Here: iPhone SDK Development 3.0

iPhone SDK Development, for the latest 3.0 iPhone SDK is now in print and shipping.

scribe client

I've released Scribe 0.1, a Ruby client for the Scribe
remote log server.

sudo gem install scribe

Usage is simple:

client = Scribe.new
client.log("I'm lonely in a crowded room.", "Rails")

Documentation is here.

about scribe

The primary benefit of Scribe over something like syslog-ng is
increased scalability, because of Scribe's fundamentally distributed architecture. Scribe also does away with the legacy
syslog
alert levels, and lets you define more application-appropriate categories on the fly instead.

Dmytro Shteflyuk has good article about installing the Scribe
server itself on OS X. It would be nice if someone would put it in MacPorts, but it may be blocked on the
release of Thrift.

Ruby IDE RubyMine 2.0 Beta Released

rubymine2.pngRubyMine is a Ruby and Rails IDE (for Windows, OS X, and Linux) by JetBrains, the guys behind the popular Java IDE IntelliJ IDEA. We’ve previously posted about how much people seem to like RubyMine, and it looks like things will get even better, as they’ve just released the beta of RubyMine 2.0. Notably, RubyMine 2.0 will be free to existing 1.0 users as it falls within the year allowed for free updates!

The New Stuff

RubyMine 2.0 was initially meant to only be RubyMine 1.5 but Eugene Toporov of JetBrains told me that they’ve considered 2.0 to be more appropriate given the number of updates and additions. Updates include:

  • Ruby 1.9 support
  • Rails 2.3.3 support
  • Rails i18n (internationalization) support and spell checker
  • UI improvements
  • Cucumber and Shoulda support (in addition to the existing, and now improved, RSpec support)
  • Built-in HAML and Sass support

JetBrains’ RubyMine 2.0 beta overview page gives full examples of the changes and improvements.

20% Discount Until General Availability

JetBrains are offering a 20% discount on purchases of RubyMine from now until the general release of 2.0 – due sometime in the next few weeks, so this is a great time to try it out and, if you like it, buy a copy. The offer price is currently $79 to US users or £57 in the UK. Not bad considering the parent product, IntelliJ IDEA, weighs in at hundreds of dollars!

Still A Bit Flaky To Me, But A Strong Step Forward

I’m not typically into IDEs and find the lack of a truly native OS X Ruby IDE a little jarring. RubyMine 2.0 does seem to have a somewhat improved interface, though, but I still find it flaky. For example, when you press backspace when filling out fields in the preferences dialogs, it doesn’t work, and instead you see characters being deleted from your open code in the background! When filling out other dialog boxes, when I pressed Enter it added lines into my code in the background too rather than close the dialog.

RubyMine isn’t a native OS X app from what I can tell (you can reskin it from the preferences pane!) and dialog and UI behavior is not really up to OS X standard in much of the app. Despite reservations about using it myself, though, other users on Twitter are raving about how good it is so it’s certainly worth a try. It’s certainly improved enough that I’m going to give it a proper try this time.

Disclosure: JetBrains, creator of RubyMine, is a sponsor of Ruby Inside. This post is, however, not contingent on that and I have no other relationship with the company (and, sadly, don’t get a cut of any sales – ha!).

Ruby Enterprise Edition 1.8.7 Released – Lower Memory Usage, Increased Speed

ruby-enterprise-edition.pngToday Phusion has announced the release of Ruby Enterprise Edition (REE) 1.8.7 (more specifically, 1.8.7-20090928). Once considered a bit of a joke, given the name, REE has proven itself to be anything but, with significant memory usage and speed improvements over the stock “MRI” Ruby implementation. The key development with this release is compatibility with Ruby 1.8.7, rather than the 1.8.6 of previous versions.

While REE has shown itself to be a good performer compared to MRI before, this week Evan Weaver of Twitter revealed how a release candidate version of REE 1.8.7 has resulted in a significant throughput increase on the same codebase. He also noted that Ruby is faster when compiled with optimization for size rather than speed due to the benefits of being able to fit more of Ruby into the CPU’s cache. REE 1.8.7 is optimized for size by default, so you get the same improvements out of the box. For information on other optimizations and changes from MRI, Phusion’s release post has more details.

Installing REE is pretty easy (instructions here) but the latest version of RVM (Ruby Version Manager) already has support for it if you want to seamlessly run multiple versions of Ruby.

Disclaimer: The REE “logo” shown above is not official and was designed by Ahmad Galal. It’s CC 3.0 licensed.

[ad] railsjumpstart.pngJumpstart Lab is offering Rails Jumpstart, an introduction to Ruby on Rails, on 10/31-11/1 in Washington, DC. Save $30 with code “rubyrow“!

We’re Hiring!

Thanks to the continued support of the fantastic Ruby community, Heroku is rapidly growing.

We’re determined to keep improving our service for our ever expanding user base, and to that end we’re looking for a few fresh faces to join our world-class team in San Francisco.

First up, we’re hiring our first full-time Heroku Evangelist. This lucky person should have a serious passion for Ruby and cloud computing, along with the enthusiasm and ability to communicate to our audience how Heroku can make their lives easier. There will be lots of presentations to make, conferences to visit, and ample room to engage our developer community – including open source projects.

Second, we’re looking for a Ruby Cloud Platform Support Engineer to work with our amazing customers to make their Heroku experience as awesome as possible. We’re looking for someone with solid Ruby coding chops who really gets a kick of out helping customers solve real problems.

If either of these positions sound like just the thing for you, head on over to our jobs site to read more and apply.

#181 Include vs Joins

The :include and :joins options for the find method can be a little confusing because they are so similar. In this episode I show specifically when to use which option.

#181 Include vs Joins

The :include and :joins options for the find method can be a little confusing because they are so similar. In this episode I show specifically when to use which option.

TweetStream: Use the Twitter Streaming API from Ruby

twitter-stream.png A couple of weeks ago, popular micro-blogging service Twitter unveiled a beta “streaming API.” Twitter’s nature means they get hammered with polling requests so they’ve begun to experiment with the concept of streaming relevant data within a single HTTP request (in a Comet style). TweetStream (or GitHub repo) is a new Ruby library by Michael Bleigh to handle interacting with Twitter streams from Ruby.

TweetStream is available as a gem from both GitHub and Gemcutter (which, incidentally, got a fresh design today) and installation instructions are given in Michael’s blog post about TweetStream. Once you’re all installed, though, reading the live stream becomes as simple as:

require 'tweetstream'  

TweetStream::Client.new(TWITTER_USERNAME, TWITTER_PASSWORD).sample do |status|
  puts "[#{status.user.screen_name}] #{status.text}"
end  

Beyond basic functions, though, TweetStream also include daemonization features that allow you to create scripts that run in the background “out of the box.” You could add these features yourself with the daemons library, sure, but having this at hand to quickly throw together Twitter scripts is pretty cool.

Other related stuff: If you’re more interested in using Twitter from Ruby generally, check out John Nunemaker’s Twitter library. If you want to build a Twitter bot in Ruby, check out Twibot. And, lastly, if you just want to follow some Rubyists on Twitter, check out Satish Talim’s list of 50+ Rubyists to Follow on Twitter.

[ad] lapsusss.png Time Tracking without Timers: Lapsus runs in the background and knows what project you’re working on. Find out how long that last project took without the hassle of updating a timer. Watch the screencast or sign up for the Beta.

The best camera is…

We periodically like to highlight some of the great applications people are building on Heroku. This week, a new web site and iPhone app for shutterbugs launched, and it’s getting great press and feedback around the web.

Chase Jarvis, a professional photographer, has been singing the praises of the iPhone camera as creative outlet. As he points out, the best camera is the one you have with you. To back that claim up, he’s launched a new project combining an iPhone application and community website.

When I saw that this was running on Heroku, I knew I had to find out more. I reached out to the developers behind this project: Übermind. I dropped the mad geniuses over there a quick email, to find out how and why they are using Heroku.

Ben Sharpe, their Senior Web Services Architect responded:

“When it came down to production deployment, we investigated several alternatives — but we felt that Heroku was the best balance between features, ease of use and value.”

And these guys are getting some traction:

“In the first day we absorbed 5000+ new users and 150k impressions while updating the code throughout the day.”

It looks like that’s just the beginning, with users and traffic shooting up today too. As of Sept 25h, the iphone app is already #11 on the Top Paid App list!

They’re serving up both the iphone backend and web site with a Crane DB + 16 dynos. Go check it out!

(unofficial) RubyConf 5k Run

David Chelimsky and I were chatting a couple of weeks ago about my recently acquired running hobby and he asked “Why don’t you organize a 5k race at RubyConf?”

Then I said something like “heh”. Then we both thought about it some more and thought it might actually be a fun thing to do.

In a previous email, Jarkko Laine had volunteered to coordinate some morning exercise sessions at RubyConf, so we’ve pulled him in as well.

So now, David, Jarkko, Kelly and I are organizing some kind of 5k race for one of the mornings of RubyConf.

Can you run 3.1 miles?

If so, be on the lookout to sign up and have some fun.

If not, even better! Chances are even if you don’t run at all right now, you can practice and get ready to run (or mostly run) 3.1 miles by RubyConf. Check out a program like Couch to 5K for an easy progressive schedule that will get you to running the distance without feeling like you’re killing yourself.

We’re still getting our collective act together, but I wanted to share this to get you thinking about trying to run 5k if you haven’t before. There might be some fast people in the crowd but I’m hoping for a greater ratio of people who have never been able to run just trying to finish it.

So start training and see you there!

There is no magic, there is only awesome (Part 2)

This is the second article in a series titled “There is no magic, there is only awesome.” The first article introduced the “four cardinal rules of awesomeness”.

If you’ve ever watched someone make string figures, it’s pretty obvious that the tool set includes a loop of string, and your fingers. But if you haven’t played with string figures much, you might be surprised to learn that you’ve got a lot more than string and fingers at your disposal.

There are figures that require the use of your wrists to hold the string. Some require you to use your lips, teeth, tongue, or nose. I know a few that use the neck. There are some that use the elbow, knee, foot, or toes. A few require you to set the figure down on a flat surface to manipulate it.

There are many figures that require the use of another person, or several people. Some figures actually require multiple strings. Some require additional props, such as sticks.

Different figures might require different types of string. Some, like Eskimo figures, work best with a thicker, shorter, stiffer string, while those of the Pacific islands tend to prefer longer, more supple and slippery strings.

With so many variables, and so many ways of combining them, how then does one ever excel at string figures? Is it hopeless?

Of course it isn’t. As with any other activity, there are simply a set of tools to be employed, and the expert will be well acquainted with them. It’s rule #1 of being awesome: know thy tools.

Knowing vs. Knowing

But what does that mean? It certainly doesn’t mean just “knowing what your tools are”, otherwise you’d all be on your way to string figure mastery, just by reading the above paragraphs. Knowing your tools necessarily means knowing, deeply, how to use a tool. It means knowing the strengths and weaknesses of each tool, knowing why a particular tool is best in any given situation, and knowing how to learn more about them.

In fact, those statements can be generalized into four questions that can be used to gauge the depth of your knowledge about most anything:

  1. What does this do best?
  2. What does this do worst?
  3. Why should I use this in particular?
  4. When was the last time I learned something new about this?

We’ll hit those four questions in each of the articles that follow, but for now, I’m going to apply them specifically the tools of my own professional domain: writing software.

The tools of computing

If you write software, step back for a minute and think about the tools you use every day. This includes your operating system, your text editor, your command shell, your SCM. It’s your web browser, your terminal client, your email and IM clients. It includes command-line utilities you probably use without thinking, every day: grep, sed, awk, find, ls and cd, to name a few. It’s even your hardware: the keyboard you use, your mouse, your monitor, your computer. It probably includes many other things that I’ve completely overlooked! (Note, though, that programming languages will be covered separately; they are certainly tools of the trade, but they’re such spectacularly important tools that they deserve their own rule of awesomeness. More on that when we hit rule #2.)

So, now it’s your turn. Go ahead and grab a scrap of paper. Make a list, right now, of the tools you use every day. I’ll wait.

Done? Okay, awesome. Now, go through each item on your list and ask yourself each of the four “knowledge gauge” questions:

1. What does this do best?

Compared with similar tools, what does this tool do best? Don’t use a pre-recorded, generic answer. Think about it. Consider it carefully. Be specific. For particularly powerful or flexible tools, there may be multiple answers, and that’s okay. Your answer may quite possibly be debatable, and that’s okay, too. The point here is that you need to have an opinion. If someone asks you why in the world you choose to use Vim instead of Emacs, don’t let the silence stretch awkwardly. Know your mind!

2. What does this do worst?

Related to the previous question: At what is this tool particularly bad? Again, this is in comparison with similar tools. And there is no such thing as a perfect tool, so there’s no point trying to skip this question. That’s a cop out. If you don’t have a few pet peeves for each tool in your toolbox, then chances are you aren’t familiar enough with your tools. Have an opinion.

3. Why should I use this in particular?

Given all possible alternatives, why am I using this tool in particular? Was it recommended to you? Are you using it “by mandate”? Perhaps it was it a gift, or a hand-me-down? Have you personally tried any of the alternatives? The real test of this question is having someone ask you for a recommendation. If you were to recommend this tool, and they were to ask “why” in return, what would you tell them? Similarly, if someone were to ask you about one of the alternatives, would you be able to give them an educated opinion? (You do have one, right?)

4. When was the last time I learned something new about this?

In many ways, this is the most important of the four questions. It’s purpose is to make you aware of potential stagnation. Certainly there is a point at which you say can that you know a tool “well enough”. It gets your job done. It suffices. Perhaps you’re even something of an expert, with deep knowledge about the tool. But no matter how well you know a tool, if you stop learning and instead put your expertise on “cruise control”, you’ll stagnate. Expire. Rot. Guaranteed. To be exceptional, you must be active.

Don’t stagnate. Seriously, just don’t. If it’s been a while since you learned something new about one of your tools, take a good look at that tool. Look at its documentation. Find tutorials or blog articles. Books, videos, podcasts, whatever. Try to find something new about it, something that you didn’t know before. Perhaps it’s a feature you weren’t aware of. Maybe it’s just a new application of the tool. Perhaps-now, don’t freak out here-it’s another tool altogether! Never be afraid of replacing your tools when something better comes along. (It’s actually really, really valuable to continually experiment with similar tools, even if you’re satisifed with what you already have. It’s like learning a foreign language: it gives you a new perspective, and can introduce you to things, to which you might otherwise have never been exposed.)

Keep in mind, too, that “something new” does not have to mean “something mind-blowing”. In fact, such discoveries will be the exception. The point here is to simply be proactive, regularly flexing your knowledge muscles. And then, you must apply that new bit of knowledge in your workflow. Otherwise, it’s not really learned, is it? It’ll atrophy if you don’t exercise it.

Try to find at least one new thing per day. It may be cliche, but it’s also true: “practice makes awesome.” Or something like that.

Have an opinion.

These questions are intended to make you think about your tool set. It can be hard, at first, to step back and “meta-analyze” yourself and your habits, but you really can’t have a meaningful opinion if you don’t think about things. And trust me, you want to have opinions. People without opinions are, frankly, boring. They’re pretty much the opposite of awesome. Blindly accepting recommendations, mindlessly reciting others’ claims, and cargo-culting others’ solutions might be an okay place to start, if you must, but it’s always a lousy place to finish.

Get first-hand experience. Learn. Expose your hidden assumptions. Ask “why”. Have an opinion.

Know thy tools.

Watchr: A Flexible, Generic Alternative to AutoTes

watcherWatchr is a continuous-testing tool by Martin Aumont in the vein of Autotest (part of the ZenTest package).

At its heart, Watchr basically watches any (or all!) of your project’s files, then executes arbitrary Ruby code of your choice when things change.  Watchr configuration takes such a form:

watch('pattern') { |match_data_object| command_to_run }

For example, to produce Autotest-like functionality, you’d just specify Watchr to run the tests whenever a test or some library code changes, like this (taken from Martin’s blog post):

watch('test/test_.*\.rb') { |md| system "ruby #{md[0]}"}
watch('lib/(.*)\.rb')     { |md| system "ruby test/test_#{md[1]}.rb"}

…but Watchr can be used for much more than just testing. You could use it to automatically generate documentation, build your gem or any other tasks that you can script in Ruby.

To get started with Watchr, just install the gem (from Gemcutter), and run the watchr command from your project root, passing the location of the configuration script:

$ gem install watchr --source=http://gemcutter.org
$ cd to/your/project/root
$ watchr path/to/script

The source and some documentation (including example scripts) is available on Github, and you can read more on Martin’s blog too.

If an even more simplistic route appeals to you, Ruby Inside’s editor, Peter Cooper, has a basic Rake task that can run a script of your choice when files change within a project.

devver-icon.gifAlso.. Got a slow Test::Unit or RSpec suite? Run them up to three times faster on Devver’s cloud! Setup is simple and requires no code changes. Sign up now!

ree

We recently migrated Twitter from a custom Ruby 1.8.6 build to a Ruby Enterprise Edition release candidate, courtesy of Phusion. Our primary motivation was the integration of Brent's MBARI patches, which increase memory stability.

Some features of REE have no effect on our codebase, but we definitely benefit from the MBARI patchset, the Railsbench tunable GC, and the various leak fixes in 1.8.7p174. These are difficult to integrate and Phusion has done a fine job.

testing notes

I ran into an interesting issue. Ruby is faster if compiled with -Os (optimize for size) than with -O2 or -O3 (optimize for speed). Hongli pointed out that Ruby has poor instruction locality and benefits most from squeezing tightly into the instruction cache. This is an unusual phenomenon, although probably more common in interpreters and virtual machines than in "standard" C programs.

I also tested a build that included Joe Damato's heaped thread frames, but it would hang Mongrel in rb_thread_schedule() after the first GC run, which is not exactly what we want. Hopefully this can be integrated later.

benchmarks

I ran a suite of benchmarks via Autobench/httperf and plotted them with Plot. The hardware was a 4-core Xeon machine with RHEL5, running 8 Mongrels balanced behind Apache 2.2. I made a typical API request that is answered primarily from composed caches.

As usual, we see that tuning the GC parameters has the greatest impact on throughput, but there is a definite gain from switching to the REE bundle. It's also interesting how much the standard deviation is improved by the GC settings. (Some data points are skipped due to errors at high concurrency.)

upgrading

Moving from 1.8.6 to REE 1.8.7 was trivial, but moving to 1.9 will be more of an ordeal. It will be interesting to see what patches are still necessary on 1.9. Many of them are getting upstreamed, but some things (such as tcmalloc) will probably remain only available from 3rd parties.

All in all, good times in MRI land.

Pair programming isn’t right for all projects

My hat’s off to Obie Fernandez for his recent article 10 Reasons Pair Programming Is Not For the Masses. I don’t actually agree that only the elite are cut out for pair programming, but I do think he’s on target with his list of obstacles to effective pairing.

There’s another axis to consider for fit, however, and that’s the suitability of the work itself for pair programming. I don’t mean the product domain or the kind of application being written, but rather the technology and tools used to build it.

I started pair programming when I was a freshman in college. My CS10 lab section had 20 students and only 10 computers, so we had to pair up. No one told us anything about how to pair; we just did it. It wasn’t really a big deal since students are used to helping each other with class assignments. I think the pairing was valuable for learning, but there was a problem. The problem was Pascal. Specifically, the length of time spent compiling the code every time we made a change. We’d write some code, then fire up the compiler and play Pascal (the game of seeing how many dots you can generate before you get a compiler error). Compiling took a long time, anywhere from 5 to 20 minutes, depending on how big the program was. So what do you do with your pair during that time?

There are all sorts of reasons we hate long wait times during development, whether from compiling, running tests, deployment, or whatever. While it can be nice to take an enforced break now and then, the disruption to flow is a significant obstacle to productivity and quality of work. A five minute interrupt to your flow is murder to your mindset and caustic to your collaborative bond.

After college I worked at Xerox, programming in Smalltalk on a team of about 8 developers. We tended to pair a fair amount, maybe a quarter to half of our time on average. But at other places I worked, we paired a lot less. I’m sure some of that was cultural, but I think a lot of it was because of the technology. Programming in the Smalltalk environment really good for keeping the flow going. Do some coding in a method and save the code, and a second or three later you can see the results. This made pairing so much easier because we could keep our focus on the coding. It’s hard enough to keep the pair in a good mode when things are going well, but to have to stop for a few minutes every few minutes adds too much frustration, and the easiest place to direct that frustration is onto your pair.

So if your project is not amenable to a rapid, incremental development cycle, it’s going to be a lot harder to keep people pairing on it. I guess that leaves two options. You can punt on pairing, or you can fix the technology so that you get the fast development cycle necessary for maintaining flow. Can you guess which one is going to be better for you?

#93: Sorry about that.

Episode #093. Dan Benjamin (Playgrounder, Hivelogic) is back this week. We’ve got a ton of news this week and just maybe an awkward moment or two. Also, I mis-pronounced John Mettreaux’s name wrong, calling him Jake. Sorry about that.

Update: We’re now accepting stories and feedback to @railsenvy on Twitter. You know, if you feel like letting us know about something.

Sponsored by New Relic
The Rails Envy podcast is brought to you this week by NewRelic. NewRelic provides RPM which is a plugin for rails that allows you to monitor and quickly diagnose problems with your Rails application in real time. Check them out at NewRelic.com.

Subscribe via iTunes – iTunes only link.
Download the podcast ~19:45 mins MP3.
Subscribe to feed via RSS by copying the link to your RSS Reader

Show Notes

  • 5 Things to Look for in JRuby 1.4

    Nick Seiger posts on the Engine Yard blog about 5 things we should be expecting to see in the next version of JRuby.

  • Not Using IPAddr Should Result In You Being Mauled By A Bear

    “mrkris” abuses you in to using the IPAddr class to store ip addresses as integers in the database.

  • Scout and Rails Log Analyzer

    This is a simple command line tool to analyze request log files of both Rails and Merb to produce a performance report. Its purpose is to find what actions are best candidates for optimization. Scout now supports this with just the path to the log file.

    http://github.com/wvanbergen/request-log-analyzer
    http://scoutapp.com/tour/rails_monitoring

  • Watchr is watching you

    Watchr is a new gem by Martin Aumont that is similar to autotest but works in any Ruby environment and watches files and directories for changes.

  • friendly_id

    FriendlyId is the “Swiss Army bulldozer” of slugging and permalink plugins for Ruby on Rails. It allows you to create pretty URL’s and work with human-friendly strings as if they were numeric ids for ActiveRecord models.

  • Rubber

    Rubber’s aim is to make it as easy as possible to deploy a rails app to EC2 _without_ sacrificing ones ability to scale that application into a multi instance cluster.

  • Learnivore

    Learnivore is a screencast aggregator focusing mostly around Ruby, Rails and iPhone development screencasts. You can sort by site and tags as well as free/paid screencasts.

  • Create Your Own Programming Language

    Have you ever wanted to create your own programming language? Marc-André Cournoyer, the creator of Thin, has a new pdf out telling you how.

  • Swallow nil

    Dan Croak posts about a function called swallow_nil on the Giant Robots blog.

  • Ruby on Hadoop Quickstart

    Phil Ripperger put up a blog post walking through getting Ruby working on Hadoop on EC2. Literally, every step of the way.

  • Railscasts: Finding unused CSS

    Ryan Bates has a RailsCast out about using the deadweight gem to remove unused CSS from your apps.

  • GIS on Rails

    Simon Tokumine writes about the different Ruby projects you can use to approximate GeoDjango in Rails.

  • GeoKit 1.5.0 Released

    GeoKit 1.5.0 has been released with fixed JRuby compatibility and some small additions.

  • Reek 1.2.0 Released

    Reek, the code smell detector, version 1.2.0 has been released. This release is Ruby 1.9 compatible and has a couple of new smells added.

  • Rufus Tokyo 1.0.1 Released

    Rufus Tokyo 1.0.1 has been released and the biggest change is search/union/intersection/difference for tables.

  • 12 Interesting Upcoming Ruby and Rails Events

    Peter Cooper posts about some Ruby and Rails events that are not sold out.

Rails Envy Podcast – Episode #093

Episode #093. Dan Benjamin (Playgrounder, Hivelogic) is back this week. We’ve got a ton of news this week and just maybe an awkward moment or two. Also, I mis-pronounced John Mettreaux’s name wrong, calling him Jake. Sorry about that.

Update: We’re now accepting stories and feedback to @railsenvy on Twitter. You know, if you feel like letting us know about something.

Sponsored by New Relic
The Rails Envy podcast is brought to you this week by NewRelic. NewRelic provides RPM which is a plugin for rails that allows you to monitor and quickly diagnose problems with your Rails application in real time. Check them out at NewRelic.com.

Subscribe via iTunes – iTunes only link.
Download the podcast ~19:45 mins MP3.
Subscribe to feed via RSS by copying the link to your RSS Reader

Show Notes

  • 5 Things to Look for in JRuby 1.4

    Nick Seiger posts on the Engine Yard blog about 5 things we should be expecting to see in the next version of JRuby.

  • Not Using IPAddr Should Result In You Being Mauled By A Bear

    “mrkris” abuses you in to using the IPAddr class to store ip addresses as integers in the database.

  • Scout and Rails Log Analyzer

    This is a simple command line tool to analyze request log files of both Rails and Merb to produce a performance report. Its purpose is to find what actions are best candidates for optimization. Scout now supports this with just the path to the log file.

    http://github.com/wvanbergen/request-log-analyzer
    http://scoutapp.com/tour/rails_monitoring

  • Watchr is watching you

    Watchr is a new gem by Martin Aumont that is similar to autotest but works in any Ruby environment and watches files and directories for changes.

  • friendly_id

    FriendlyId is the “Swiss Army bulldozer” of slugging and permalink plugins for Ruby on Rails. It allows you to create pretty URL’s and work with human-friendly strings as if they were numeric ids for ActiveRecord models.

  • Rubber

    Rubber’s aim is to make it as easy as possible to deploy a rails app to EC2 _without_ sacrificing ones ability to scale that application into a multi instance cluster.

  • Learnivore

    Learnivore is a screencast aggregator focusing mostly around Ruby, Rails and iPhone development screencasts. You can sort by site and tags as well as free/paid screencasts.

  • Create Your Own Programming Language

    Have you ever wanted to create your own programming language? Marc-André Cournoyer, the creator of Thin, has a new pdf out telling you how.

  • Swallow nil

    Dan Croak posts about a function called swallow_nil on the Giant Robots blog.

  • Ruby on Hadoop Quickstart

    Phil Ripperger put up a blog post walking through getting Ruby working on Hadoop on EC2. Literally, every step of the way.

  • Railscasts: Finding unused CSS

    Ryan Bates has a RailsCast out about using the deadweight gem to remove unused CSS from your apps.

  • GIS on Rails

    Simon Tokumine writes about the different Ruby projects you can use to approximate GeoDjango in Rails.

  • GeoKit 1.5.0 Released

    GeoKit 1.5.0 has been released with fixed JRuby compatibility and some small additions.

  • Reek 1.2.0 Released

    Reek, the code smell detector, version 1.2.0 has been released. This release is Ruby 1.9 compatible and has a couple of new smells added.

  • Rufus Tokyo 1.0.1 Released

    Rufus Tokyo 1.0.1 has been released and the biggest change is search/union/intersection/difference for tables.

  • 12 Interesting Upcoming Ruby and Rails Events

    Peter Cooper posts about some Ruby and Rails events that are not sold out.

360iDev is next week in Denver…and it’s nearly sold out!

360iDev is around the corner and if you know the organizers or have been to 360flex then you know Denver is the place to be starting next Sunday if you are or wanna be an iPhone developer. The conference starts with a day of tutorials on Sunday then kicks in full gear Monday through Wednesday with three tracks of 80 minute sessions covering all angles of iPhone development from some of the best authorities in the fields.

You can find the schedule as ical or download a pdf

Here is my schedule:

On Sunday I’ll attend the “Hands-On with the Appcelerator platform.” session.

Monday

360idev_monday.png

Tuesday

360idev_tuesday.png

Wednesday

360idev_wednesday.png

If you are not signed up yet…you better hurry.

I hope I’ll see you there!

Daniel