Jim Weirich gives a cool example of using Rake to automate searching your source code. The example even includes Emacs integration. But I live in TextMate these days, so here’s the TextMate integration for Jim’s fic.rb:
#!/usr/bin/env ruby
#fl2tm.rb converts 'file:lineno context' into HTML for TextMate
require 'rubygems'
require_gem 'builder'
base = Dir.pwd
title = ENV["TITLE"] || "Stdout 4 TextMate"
lines = []
xml = Builder::XmlMarkup.new(:target=>STDOUT, :indent=>2)
xml.html do
xml.head do
xml.title(title)
end
xml.body do
xml.h1(title)
while line = gets
lines.push line
# doesn't handle whitespace in path names
if line =~ /\s*([^:]+):(\d+):(.*)/
(file, line, context) = [$1,$2,$3].map {|i| i.chomp}
xml.li do
if file =~ %r{^/}
href = "txmt://open?url=file://#{file}&line=#{line}"
else
href = "txmt://open?url=file://#{base}/#{file}&line=#{line}"
end
xml.a "href" => href do
xml.text! "#{file}:#{line}"
end
xml.text! context
end
end
end
xml.hr
xml.pre(lines.join())
end
end
This little script converts the output of
fic into
HTML with TextMate links, so that you can click on the links to navigate TextMate. To add to TextMate, create a command that looks like this:
#!/usr/bin/env ruby
$: << ENV['TM_SUPPORT_PATH'] + '/lib'
require "dialog"
Dialog.request_string(:title => "Find in Code",
:prompt => "Extensions Then Res",
:button1 => "Find") do |line|
Dir.chdir(ENV['TM_PROJECT_DIRECTORY'])
path = ENV['TM_RUBY_SAMPLES']
system "#{path}/rake/fic.rb #{line} | #{path}/rake/fl2tm.rb"
end
In the TextMate Bundle Editor, set Input to ‘None’ and Output to ‘Show as
HTML.’ You’ll have to replace the TM_RUBY_SAMPLES with your path to
fic.rb and
fl2tm.rb-I haven’t had time to package this (and other goodies) into a TextMate bundle yet. You will need to have RubyGems and Builder. I hope Jim has those installed. :)
People are often vague when they use the term “Enterprise,” so let me offer two characterizations.
- Enterprise software implies bigness: lots of $, or very large servers, or very high throughput, or very low response time. People often use the word “scalable” here. I am fine with that, so long as they mean “resource expandable” and not “high performance.”
- Enterprise software implies flexibility: multiple data formats, disparate systems, changing requirements, backward compatibility, legacy integration, etc. Ruby is great for these challenges because it is the glue that doesn’t set.
It is amazing what a good programmer can accomplish with Ruby, and quickly. At the Enterprise Ruby Studio, we are going to show how, by connecting everything to everything else in no time flat. The picture says it best.
Yakov Fain thinks that Ajax is a flash in the pan. I met him last weekend at the New York NFJS and immediately bet him a beer on this.
I should point out that if you follow the link where Yakov described the bet, you won’t be able to read about the beer until you click past the Ajax conference ad. I guess Yakov’s advertiser base is more sold on Ajax than he is. :-)
We have quite a few speaking engagements coming up this fall. On the Spring and Ajax front, Justin and I are alternating weekends at the No Fluff, Just Stuff Java Symposiums. I will also be doing an Ajax tutorial at OOPSLA in Portland on October 22.
Justin and I are particularly excited to be co-presenting the first Enterprise Ruby Studio in Boston, September 11-13. That is where most of our day job work has been for the past 12 months. And of course we will be talking about Streamlined.
Justin and I are also both speaking at the inaugural Rails Edge in Denver, November 16-18. It is a real treat to be included among such a great lineup of speakers. I’m also psyched about the single-track format, with all the presenters involved throughout.
On Friday of last week, I was onsite with a customer. This is a huge multinational company with an enormous internal development staff. We’ve been working with them for a while, bringing Ruby and Rails into the production environment. Up until Friday, everything was going very smoothly.
On Friday, we had a meeting with representatives of other development teams in the organization. They’d been sold on Rails; they were ready to start writing their upcoming web apps in it and didn’t need me to help them along. But they had a lot of questions, which all boiled down to this: Rails seems nice for web apps, but we can’t really do anything else interesting with Ruby, can we?
So for a couple of hours, we sat in a room while they threw questions at me. What do we do about our messaging infrastructure, can we take advantage of it? What about non-Rails db access? We’ve got some unsupported databases here, what do we do? We rely on certain acceptance testing frameworks, can we still use them? We have huge XML files, can we process them? And on and on.
I can happily report that the answer to every single question was “yes”. As we delved deeper into their needs and what they were looking for, they began to see that Ruby isn’t just Rails. There’s a lot of other capabilities there, and a lot of power waiting to be taken advantage of. Perhaps best of all, they realized that choosing to adopt Ruby didn’t mean abandoning their previous investments in Java, .NET or anything else. It meant they had a new arrow in the quiver, and if they fire it at the right targets, they’ll get better accuracy.
This is exactly what we believe. Ruby strikes a sweet spot between powerful features and recognizable syntax. It has momentum, a great feature set, and a great interop story. And it doesn’t have to take over every piece of the infrastructure to be useful; just the opposite, in fact. This is what we’ll be talking about at the Enterprise Ruby Studio; how to build on the momentum generated by Rails and get Ruby working for you in the rest of the enterprise. Come check it out! First run is in September, and seats are filling up.
