My friend and fellow Rails developer John Lannon, lead developer at http://resonantvibes.com, was mugged last night while picking up dinner for his wife. He didn’t have anything on him to give to the robbers and they shot him point blank in the chest.
His friends and teammates at Resonant Vibes are raising money to help with his recovery. Please consider helping a fellow developer and a remarkable individual who (not that anyone does) really does not deserve to be in the predicament he’s in now.
Thanks
Today we opened the RailsConf Call For Proposals. So we soon begin the several-month process of putting together the program for RailsConf 2010 (in Baltimore!).
I’m particularly excited to start the process this year, because we’ve made a very positive change to the team. We’re bringing on Ben Scofield as program co-chair this year. In case you don’t know Ben, he’s the author of Practical REST on Rails 2 Projects, Technology Director at Viget Labs, organizer of the roving Developer Day conferences, and a fantastic speaker (he helped created speakerrate.com too).
So please join us in welcoming Ben, and start working on those RailsConf proposals!
See you in Baltimore!
If you only have the budget to travel to one regional Rails conference this year, this might be a good choice:
...for obvious reasons.
Next up in my series of RailsConf speaker interviews is Mike Subelsky, co-founder of OtherInbox and avid SproutCore developer. (SproutCore was used, among other things, to develop Apple’s MobileMe UI and presents a Cocoa-like environment for developing Rich browser-based user interfaces.)
Mike will be presenting both a tutorial on SproutCore development and a session on cloud computing gotchas at RailsConf in a couple of weeks.
We wanted to solve our own email overload problem—many people receive heavy volumes of “gray mail” or “bacn” and increasing volumes of more important email like receipts, social networking notifications, confirmations, etc. The other founder of the company, Joshua Baer, had the idea to build a product that would elegantly organize and make sense of this kind of mail, something we would use ourselves that would also help the average person.
This was my first startup; I knew Josh from a project class we had taken together at Carnegie Mellon and was lucky that he invited me to be the cofounder. I had been dabbling and freelancing as a Rails developer for the previous 18 months, and had always been hacking on side projects for my whole career.
Coming from a consulting background, there have been two big hurdles:
SproutCore lets you build real client-server applications, delegating a lot of GUI work to the client that servers currently perform (like rendering HTML views or serving up cached HTML pages). The framework takes concepts that desktop developers have used for a long time and reimagines them for use in web applications. For example, key-value observation and bindings help you eliminate a lot of buggy, ugly glue code, saving a lot of time and aggravation).
It’s special to me because I think this technology has the potential to dramatically change application development in general. The core team has a strong point of view about how Internet clients should be built, and how to make JavaScript and web browsers perform. Writing SproutCore code reminds me of the feeling I got the first time I picked up a book about Rails—“using these tools is making me a better programmer”.
Also, I’ve never liked the feel of Flash, and I love how SproutCore uses only web-native technologies to do amazing things in the browser. PaperCube and MobileMe are examples of SproutCore apps that feel like desktop apps, but don’t require any plugins whatsoever.
I think so—you can point a SproutCore client at any kind of server you want, but I think there’s probably a sweet spot for these two frameworks. Rails makes it easy to write a robust, easily extensible REST API, which makes it really easy to write web clients. SproutCore makes it easy to write robust, easily extensible web clients.
In OtherInbox, our Rails app has to worry about doing is sending back JSON as quickly as possible. The SproutCore app handles most of the user interaction (except for things like the signin page, which we’re keeping server-based for now) and focuses on making the browser experience as fast and fluid as possible. We don’t need to run as many web servers to keep up with our recent growth, because the servers aren’t bogged down generating HTML or RJS updates.
As a happy side-effect, since we built our app this way, someone has reverse engineered our JSON API to make an Android app.
Rails developers will also find many cultural similarities such as emphasis on unit testing and use of generators.
I think if you’re building an app where you need to add just a little dynamic behavior here and there, SproutCore is too much. Toolkits like Prototype and jQuery are much more appropriate. But if you’re making something like MobileMe, PaperCube, or OtherInbox, where the users expect desktop-like fluidity or where the client software can’t always rely on the server for everything, SproutCore will be a big win.
One thing that could help SproutCore catch on generally will be its support for multiple platforms. The 1.0 release candidate includes preliminary mobile support, so we should eventually be able to take the same code base and build it for web browsers, iPhones, Androids, etc., without having to change much. I think that will really turn some heads.
That’s tough, because there aren’t yet a lot of blogs or books to guide you. One of my goals for 2009 is to start contributing more tutorials, because I was lucky to be mentored by Erich Ocean. My best advice would be to get some familiarity with Cocoa because that will illuminate the parts of desktop development that are really different from web development. If you understand key-value observation, key-value coding, and bindings, it will be much easier to learn SproutCore.
Also, the #sproutcore IRC channel and Google group are really friendly places to get guidance.
Continuing my series of RailsConf Speaker Interviews we have Neal Ford and Paul Gross of ThoughtWorks.
Neal and Paul have been working on some huge Rails applications at ThoughtWorks and will be talking about how they do it in the session, Rails in the Large:How We’re Developing the Largest Rails Project in the World, at RailsConf.
Neal: I think the opposite is true: Java is good for small applications and Ruby is better for large, strategic projects. For small Java projects, there are tons of libraries and frameworks available to kick-start the project. The inherent limitations of Java don’t bite you as much because you’re building a small, simple thing. For large projects, you need a powerful language that doesn’t get in your way at every turn, and you need a framework that allows graceful extension. In fact, for large projects like this, the purposefully leaky abstraction of AciveRecord allows for smarter tuning.
If you pull the string on the back of my neck, I’ll say “Scaling is hard”—no matter what technology you choose. For our current project, we would be able to get better raw execution speed from using Java, but that’s only a small part of what needs to happen to build scalable systems. Lots of things go into building scalable systems, they are just different things depending on technology.
Paul: I actually think Rails is better for both small and large projects. It is incredibly easy to spin up a small Rails project and get going. We have had teams release Rails sites into production in only a couple of weeks. On the other end of the spectrum, the flexibility of Ruby and Rails means that the framework stays out of your way. When Rails is doing something that we don’t want, we can easily extend to get new behavior. For example, we work around ActiveRecord to write better SQL, we work around the MVC pattern to write Presenters when the display logic is sufficiently complex, and we even wrote our test runner to distribute work to make our test suites faster.
In general, however, many of the problems are the same on a massive project, regardless of Java or Rails. For example, we have to constantly strive to keep build times low, database performance high, and consistent patterns throughout the codebase with 20 developers hacking away.
Neal: When we first started recommending Rails to clients, we had to bring it up. Now, we have companies that ask us to do Rails projects. As for the types of companies, it’s all over the map: trading firms, auction sites, insurance, even a touch-screen jukebox! I don’t think that the type of company makes any difference, it’s their attitude about their software development. Companies that view software as an important strategic advantage tend to be closer to the cutting edge, and are more tolerant of innovative solutions. Companies that view software as purely overhead always stick with the status quo.
As an example of this, we have one client who created a “standard” Java-based stack for all their software. After spending 1.1 million dollars building a huge Portlet, EJB, Spring, Hibernate, Cocoon, XSLT, etc. application to service 5 users, they realized the unsustainability of that model. That company has since changed their “standard”: all applications must be written in Rails unless suitable justification exists for a different solution.
Paul: Ditto Neal.
Neal:It depends (hey, I’m a consultant!). Really crazily scalable sites (ala Amazon) would be difficult to build in Rails; a lot of attention would have to be paid to lots of things to get it right. We have chosen not to use Rails on some projects where it was on the table, but it was for sites like media sites, with huge numbers of concurrent users, streaming media, and other characteristics. We try hard to ThoughtWorks to not become religious about tools. Some tools are better suited to some jobs.
However, having said this, based on my experience on multiple Rails projects, I have expanded my ideas on where it would be suitable. I’m quite impressed at how linearly Rails can scale up to large-scale projects, as long as you have technical leadership that knows that they are doing.
Paul: For me, the biggest factor against Rails would be the corporate environment. If the company has a policy that everything must be deployed on IIS and use MS SQL Server, perhaps Rails isn’t the best choice. If the company has teams of Java developers who aren’t willing to learn a new language, it is probably best to stick with Java.
Neal: Beyond measure. The only way our code base maintains sanity is through rigorous testing. In fact, this project has spawned several open source testing tools in the Rails community: dust, Selenium Grid, and deep test. Testing is ultra important, and the tech leads on this project have created a really nice workflow around tests. We want unit tests to run really fast, so we use dust and forbid database access during unit tests (we use mocks instead). For functional tests, we enforce the rule that tests do hit the database and you can’t mock anything. For a long time, all the pairs on this project were using Mac Minis, which are underpowered for running lots of tests, which spawned the birth of Deep Test. Deep Test allows you to spawn multiple remote threads to run functional tests. Because our functional tests run inside of a transaction, all our tests are completely orthogonal to one another. When the functional tests start, it spawns multiple processes on several BAMs (Bad-ass Machines) to run the tests. Recently, the whole project was upgraded to 8-core Mac Pros, and we switched Deep Test to use the local processors. Instead of taxing one processor, it pegs all 8, running the entire suite of tests in about 6 minutes.
You have to have testing on all code bases. Period. But it’s even more important in dynamic languages, and especially as you scale up the size of the code base. Insanity would ensue if this code base had no tests; it would collapse in a matter of weeks of trying to maintain it.
Paul: In addition to what Neal said, we use tests to enforce processes that would be forgotten otherwise. For example, if someone forgets to add a translation to a set of files, we have a test that will fail. If someone accidentally creates some bad HTML, we have a test that will fail. Furthermore, on a large team with a large codebase, developers come across code on a daily basis that they know nothing about. Tests act a description of what the code should do and why. It’s a living piece of documentation.
Neal: Convention over configuration is one of the “obvious in hindsight” features in Rails that has really impacted the whole industry. How many frameworks now brag about this feature? In the Java world, we went down kind of a bad path for a while, where we came just short of building configuration entries for what planet the code was written on. We still use convention over configuration heavily, and not just the Rails version. As much as possible, we try to create everything with sensible, overridable defaults. I don’t really see any end to how much this particular aspect of Rails will scale.
Paul: The obvious answer is sometimes :). One of the great things about Rails is that when the opinions do not scale, they are easily worked around. We can use plugins and gems to radically alter the behavior of Rails, or just do it ourselves.
For example, one opinion of Rails is that all tests hit the database. This opinion does not scale well to the size of our test suite, so we use gems like UnitRecord to cut off the database for unit testing. Another opinion of Rails is to split up tests by models/controllers/etc. We wanted a further split of test type (unit/functional/externals/acceptance). To accomplish this, we simply made our own test folder hierarchy and reworked the standard rake tasks. It was not difficult.
Yesterday, I asked Twitter:
Rails programmers: what's an example of one thing you find in other people's Rails
code that you (almost) always consider to be wrong?Quite a few people responded, and several asked if I’d post the aggregated answers. Here’s an attempt. I don’t necessarily agree with everything here. I’d love to hear more of these in the comments.
@briandoll’s response was particularly interesting:
extensive logic in views. If the erb would be ugly and harder to pull off in
haml, it's likely a code smellThis is something I always liked in Java about XMLC:http://www.enhydra.org/tech/xmlc/index.html. It was really hard to end up with a mess of co-mingling code and views, because you would have to work harder in XMLC to even make that possible. Amrita used to have that same characteristic, but I’m not sure it still does (or if it is even maintained).
I’ve been resistant to HAML but maybe it’s time to give it another look.
Also, as @mbleigh points out, any code in views is suspect. CSS should be in CSS files. Javascript should be in Javascript files.
Enough said.
@seancribbs singles out auto-generated tests. I’ll have to agree with him.
@alancfrancis says simply “rspec”. Certainly not a religious topic. I’m sure if you could somehow see in the code which editor someone used, we’d see a lot of TextMate, vi, and emacs in the responses.
@brendanbaldwin says “I’ve seen Polymorphic Associations and Single Table Inheritance abused to absurdity.”
As have I. I’ve also abused them to absurdity myself. The storage of a column called “type” which holds a class name is a pretty good indicator that something fishy is going on. It’s fishy but not always bad. I think, though, that any time you use it you should ask yourself more than once if it’s the right solution. Databases don’t do what they do best as well when you have lots of STI and polymorphic associations.
I once had to debug a problem with a commercial, Java-based portal product. The mail module was failing, saying it couldn’t connect to the mail server. In fact, what was happening was my login credentials were incorrect. Guess what the offending JSP looked like (pseudo-code)?
try {
// do everything here
} catch (Exception e) {
out.println("Unable to connect to the mail server") ;
}Exceptions are one of the only places in Ruby where you rely on checking the classes of objects to do useful and interesting things. Never rescue Exception unless it’s at the end of a stanza in which you’ve already handled one or more other exception types.
UPDATE: from the comments, Phil didn’t mean what I typed here:
That’s not actually what I meant. Never rescue Exception unless you’re working with code that abuses the
exception hierarchy. In normal circumstances you should be rescuing StandardError instead. If you rescue
Exception, you won’t even be able to ctrl-c your way out of your code(!) among other problemsMore info on his weblog here
class Potato
attr_accessor :size
end
potato = Potato.new
potato.instance_eval do
size = 123
end
p potato.size
# => nil
Ruby’s assignment to method-call syntax sugar only works when there’s an explicit receiver (such as self.size = 123)
Always run with -w. Fix any warnings you see. A good place to see them is when running your application’s comprehensive test suite.
RJS, render, nested named routes, and ERb are the targets of these criticisms.
validates_uniqueness_of is a strange critter. It’s so easy to use, that it’s tempting to slap it into your code and consider it good enough. But even the documentation for it warns you:
Using this validation method in conjunction with ActiveRecord::Base#save
does not guarantee the absence of duplicate record insertions, because
uniqueness checks on the application level are inherently prone to race
conditions.Here are some rules of thumb:
If you create your own configuration file and have to check RAILS_ENV, you’re not using a built-in facility of Rails.
OK, so this isn’t really what he meant. But it’s a good thing to think about. If you find yourself writing a lot of code to do something simple, you might be missing something Rails (or a plugin) provides. I’ve seen a whole lot of wheels re-invented inside models, controllers, and helpers. Part of Rails mastery is learning to ask yourself, “Shouldn’t somebody have already done this for me by now?”
Seems like if you find yourself manipulating Ruby’s load path in your Rails code, you’re doing something strange. If you don’t know you’re doing something strange, then you’re probably doing something wrong.
As Dave Thomas likes to say “Don’t not use positive logic” (or something like that).
Can someone tell me where the use of ”!!true” crept into the Ruby vernacular? Sure, it’s syntactically valid to do:
!!!!!!!!!!!!!!!!!!ok?
But why?
It’s April 1st, so my mind wanders to the hypothesis that someone introduced this and started spreading it as an elaborate joke. If so, well played. Is there a good use of this idiom I’m missing?
ActiveRecord migrations define a simple API/DSL for doing schema manipulation. But when they run, they’re just Ruby classes and methods executing within the Rails environment. So you can do anything you like in that context.
Sometimes people use migrations to load seed data. Pratik doesn’t like this.
I’m on the fence on this one. In small doses it doesn’t strike me as a horrible practice. That being said, I don’t tend to do it. I’d be interested in hearing opinions.
I guess it depends on what you’re doing with the parameters. Sometimes long parameter lists on GET requests are a sign that there are two actions’ worth of work happening in a single action. Or that you’re doing something that belongs behind a POST or PUT. This one doesn’t bother me as much as it does @Adkron.
if foo.save && bar.save
if bar fails to save, foo doesn’t. Oops. I’ve seen this more than once in the wild.
Obtrusive Javascript and RJS are the themes here.
What’s the worst use of RJS you’ve seen? I love RJS. I may be one of the offenders. Doesn’t feel like it (usually) though.
Smalltalk people, as a collective culture, seem to get this right. Kent Beck documents a simple pattern in his Smalltalk Best Practice Patterns called “Compose Method”. He says that one way to determine whether a new method is required is whether all of the code in a given method operates at the same level of abstraction. That’s a simple but powerful rule. Think about it next time you’re coding and I think you’ll agree.
I agree with Mike on this one. I don’t tend to write any comments, so I may be on the anti-comment side to a fault. My goal is always to write code that is clear enough that comments don’t add anything. If you name everything well and keep your classes, modules, and methods short, you’re already going to make comments redundant in a lot of cases.
Whenever I see a comment inside a method definition, I consider it a bad sign. In most cases, whenever you encounter a comment inside a method, it’s a marker for where code should be extracted into a new method.
If you’re writing a framework, the rules are different. But most of the time as a Rails developer, you shouldn’t be writing a framework.
Next up in my series of RailsConf speaker interviews is Michael Bleigh, who is Creative Director and Open-Source Activist at Intridea in Washington D.C.
Michael will be presenting Twitter on Rails at RailsConf this year, highlighting a small but growing trend of applications using Twitter as a communication platform.
I wasn’t a super-early adopter of Twitter; I honestly think it’s something that takes some time to “get.” Then one day I woke up and realized that without even trying I was getting all kinds of news and information that I might not even have heard otherwise. The beauty of Twitter (and Present.ly for teams and organizations) is that it’s a fast, passive medium: you don’t have to make an effort to keep up to date, it just sort of happens. It works with two-way communication, too; on our team if I have a quick syntax or sanity check question about my code, I post it up on Present.ly and get five responses within three minutes. Micro-updates excite me because I feel like I’m getting smarter just by glancing at growl notifications for a few seconds every couple of minutes while I’m working. It’s effortless.
It’s hard to pick out just a few; from a client perspective I’ve been using EventBox lately. It’s integrated Twitter search feeds are really useful for keeping an eye on all of Intridea’s brands (as well as my plugins and open-source projects). While I don’t think anyone has nailed it perfectly yet, aggregators like TweetMeme are interesting in their attempts to bubble up content from the noise. Honestly, I don’t think there are just a couple cool apps; I think that Twitter’s true strength is this really energetic ecosystem around creating cool stuff with the API. That’s what my talk is all about: lowering the barriers to people making cool stuff with Twitter. With the hundreds of apps currently available I still think we’ve only scratched the surface of the utility that Twitter-based applications can provide.
As the “Open Source Activist” I’m basically just trying to push people to package up what they’re doing and share it with the community, whether it’s through a Ruby gem, a plugin, or just a blog post. My colleagues are making cool stuff all of the time, and sharing that cool stuff with the community is absolutely beneficial for the company, the individual, and everyone who finds it useful. We’ve had clients come to us and when they’re vetting our work it’ll be “Oh yeah, I’ve used that plugin! You guys wrote that?”
I think that every company needs someone who is pushing for that community involvement. Pushing for us to blog more often and release more open source doesn’t just yield intangible reputation benefits: I’ve learned really cool techniques from other people at Intridea that they used for a project on which I’m not currently working. I’m always excited to foster that kind of sharing environment because the rewards are just great. I could go on for hours and I strongly encourage that every company working with Ruby or Rails try to release at least a few open-source libraries and write some blog posts to share your knowledge and expertise with the world at large.
We really believe in putting our money where our mouth is on the open-source front. When we wrote mobile applications for Present.ly on five different platforms it was a no-brainer to me to release them all as open-source. Open source, open APIs and open communication foster innovation in amazing ways, and anything I can do to make that happen more often I will.
Twitter Search is special because it’s intrinsically a different beast than Google and other search engines. It’s not indexing information, it’s indexing conversation, and it does it in real time. If I’m trying to find information about something that happened in the last 24 hours (like who was that old woman on Lost?), I don’t use Google anymore; I turn to Twitter because it will have up-to-the-second information that just isn’t available anywhere else. Obviously it doesn’t replace the usefulness of other search engines, but it opens up whole new channels of information discovery. Honestly search and Twitter are such a natural and amazing fit that it’s surprising that it took a third party (Summize) to come along and realize that potential. I really look forward to where they (and third parties) are going to take the technology in the next year or two.
The balance actually works really well. We have a few people full time on products and then we rotate in services people either part-time or full-time depending on our client engagements at the time. I think it’s been great for both sides of the company to have both services and products: we can try really bleeding edge and experimental things on the products and then bring that knowledge to the client work we do. Likewise, everyone at Intridea on the services side has an almost inhuman work ethic and an ability to juggle several projects at once so when they come on to the products they can pick it up fast and get things done. Consulting has also allowed us to try a number of products without ever having to accept outside funding.
A number of our products also grew out of needs that clients would have again and again. For instance Scalr is a great piece of software (don’t ask me about how it works, it’s over my head!) that gives us the ability to provide amazing scalable cloud hosting to our clients. MediaPlug similarly provides an easy infrastructure that saves our clients time and money. We scratch our own itches with our products and that usually means that there are benefits for the consulting side of our business with every product we make. I’m honored and privileged to work with so many brilliant people and be allowed to pursue so many amazing ideas.
Continuing my series of RailsConf speaker interviews, next up is Obie Fernandez
Obie started and runs the Rails consultancy Hashrocket and is the author of the best selling The Rails Way.
At RailsConf, Obie will be presenting a Blood, Sweat, and Rails, which if it’s anything like his talk at last year’s Rails Summit Latin America will no doubt be educational, thought provoking and entertaining. It might even include some Def Leppard music if we’re lucky.
I started at least half-a-dozen real businesses between the ages of 15 and 21. Those experiences taught me that I didn’t know enough, either about business or just in terms of plain ole life experience to successfully run a business. So I waited, and waited, almost 15 years until trying again in earnest. All the while wishing I was my own boss, but not feeling ready to make the leap. Fear of failure was a big part of that, as well as many other fears, like not being able to pay my child support obligations.
As for overcoming the fear, I’m guessing that everyone is going to have different tipping points. One commonality though, is probably to give yourself distance from the culture of fear that permeates our world. I did away with my “normal” television watching habits a long time ago—nowadays our television goes weeks without being turned on —most commercials prey on pervasive fear culture of our society. Fear of death, fear of getting sick, fear of accidents, of not being successful enough. Get rid of it!
If you really want to succeed, you have to distance yourself from whiners and low-achievers too. We all have toxic people in our lives, you gotta put space between you and them if you want to overcome the fear and negativity that they breed.
My tipping point to success was building a solid reputation online via my blog and getting so good at what I was doing that I didn’t have to particularly worry about going back to fulltime employment if I happened to fall flat on my face as an independent.
I think fixed-bid contracting for custom web applications is a horrible idea, overall. I slept on this question for a few days and dug back in my memory over the last dozen years of consulting: I’ve never heard of anyone being happy with the outcome of a fixed-bid project.
The fundamental problem with fixed-bid is the fluid and living nature of all but the tiniest single-purpose webapps. Once you start development, there are going to be changes necessary. A lot of those will feel “easy” and/or “logical” as if they should have been included in the requirements to begin with. Pressure will be on to include those changes in the original budget, especially if you’re focused on customer service and keeping that client happy. Doubly so if the client is on a tight budget and simply doesn’t have more money to pay. Your hands are tied and odds are you’re going to suffer the consequences.
I don’t think there’s a “right” way to do fixed-bid. You’d have to have a really awesome and understanding client and implement a very rigorous change-control policy that I suspect would encumber the whole development process to a large and unenjoyable degree.
If possible, invest the time in helping your client to understand the nature of variable scope and why it’s in their best interest.
(Note: Obie recently covered this topic on his own weblog here)
No, not right now. I’m very focused on being the best of the best in one particular niche: large-scale, custom web application development. And I don’t think that there’s any technology that even comes close to what you get with Rails for that. There’s always lots of cool and exciting new things going on, the latest craze seems to be iPhone development. We have a number of people interested in that, but I will not take the company in that direction. It would be detrimental to lose focus from what we do best.
Unless you’re independently wealthy, when it comes to landing a good job and keeping it, you’re always going to have to hustle to promote yourself. Lessons in sales and marketing apply whether you’re selling a product, a company’s services or your own services. What are you doing when you prepare a resume? When you go on an interview? Selling! Get good at it, or suffer the crappy jobs and work environments that you will get otherwise.
As for client relationships, if someone is paying you, they’re your client. Doesn’t matter if you answer to another company or to a manager. The skills of maintaining a healthy relationship and knowing how to properly set expectations apply to everyone.
That’s an interesting distinction. Passion is undeniably necessary for success. Without passion, without the ability to inspire others, via your words and/or actions, you’re not going to get very far in life. I believe that Agile software development “just is” and I’m very passionate about that. It just is the way that you do quality software. Not doing quality software? That’s fine, but I won’t work with you. Nowadays Agile is far enough along in mindshare that I don’t feel I have to sell it very much or get anywhere near dogmatic about it. As in everything, I try to keep an open mind and if a better philosophy evolves, maybe it’s “Lean Sofware” or maybe it’s something else, I’ll go with the flow. Until then, I stick to my principles. Passionately.
I guess I’d have to say travel, more than anything else. Last year I was blessed to be able to take my kids on a few good vacations, including a fancy three-week trip around the world with stops in South Africa and Far East. This year it’s looking like I’m going to be spending a lot of time in Europe and South America, so I’m definitely excited about that. It’s a big world out there. Get out and see it while you still can!
We’re closing the RailsConf call for proposals in just over a week, so if you’ve been procrastinating (certainly my M.O.), now’s the time to start putting something together.
We’re keeping the CFP open longer this year than we have in years past, which is great for the content (Rails 3!!) and hard for the logistics. I think it’s a good trade-off.
If you’re tracking and/or working on Rails 3, we’d especially love to see a proposal. If you don’t have anything solid yet but have a good idea you’d like to try to slot in later, I’d love to hear from you.
We already have a number of talks and tutorials selected, as well as keynotes by Bob Martin, the Rails Core team, and of course DHH.
Both CabooseConf and our code drive were popular hacking sessions last year, so we’re excited about the fact that this year CabooseConf will be run in conjunction with RailsConf this year, providing a free group hacking area (but you have to contribute to an open source project for admission). With the economy sucking the way it is now, hopefully this will give some people an affordable way to join the fun without spending as much money. Thanks to Courtenay and the caboosers for making that happen.
Ron Evans will be organizing a music session this year. If all goes well, we’ll have more equipment than last year (sound system—maybe drums?), so if you’re a musician watch for it and come by to make some noise.
I’m looking forward to holding RailsConf in Vegas this year. The venue is awesome, and Vegas is an easy location to get in and out of. All in all, things are shaping up for this to be yet another in a string of better-than-last-year RailsConfs.
Mike just reminded me that the Early Bird discount is soon to expire for our January Rails Studio in Denver. If you’ve been thinking about attending a Rails Studio and work for a big company, here’s a tip I learned the hard way: corporations usually budget for training and then when it’s time to “save some dollars” in later quarters, they cut the training budget first. In my big corporate days, that bit me more than once, stopping me from going to conferences (OOPSLA) and training (XP Immersion, which I later eventually made it to).
So if you’re interested in doing any training this year, I’d recommend that you do it in the first quarter before the budget is pulled out from under you. Unless you work for an enlightened company with a healthy revenue stream.
The Rails Studio has the added advantage (for me) of being held at a beautiful, resort-like hotel with a bunch of really nice fitness facilities and excellent food. Last time we taught there, I was actually sad to go back to our full service gym at home.
If you’re coming and either into getting in shape or music, let me know. Maybe we can arrange some after-hours activities.
Being an organizers of Ruby conferences myself, I always enjoy going to the regional conferences. I’ve been to the Mountain West RubyConf, Ruby Hoedown and Rails Summit Latin America. Each was excellent in its own unique way. It’s also a great pleasure for me to attend a conference I’m not organizing.
So I’m looking forward to the upcoming Scotland on Rails in March. Marcel and I will be presenting a tutorial for charity at this year’s conference.
I’ve heard great things about last year’s Scotland on Rails, and I trust my friends in Scotland to put on an excellent show. If you haven’t been to Edinburgh, you owe yourself a trip. It’s an incredibly beautiful city.
What better way to explore new lands than to do it by invitation as a speaker? Scotland on Rails has opened its Call for Proposals (it’s been open for a while, but I’m slow). The CFP closes in 2 weeks (December 1st), so if you’re interested in speaking don’t be late. From what Alan tells me, they are especially interested in hearing how to do BIG projects with Ruby and Rails.
Hope to see you there.
This spam post reminded me that I haven’t reminded you that the Rails Studio is coming soon here in Denver. It’s happening in September, but early registration ends tomorrow.
This is my first time teaching the public Rails Studio with Dave. We do Advanced Ruby and Ruby Studio, and Advanced Rails together. I got to sit in on a Rails Studio he and Mike did together last year in Seattle and had a great time. It’s really fun watching people experience the “aha” moments for the first time. Reminds you of how you felt the first time you watched the 15 minute intro video.
Apart from all the fun of learning a great framework for the first time, Colorado is a really nice place to be in September. So if you are coming, try to plan a couple of days before or after (I’d say after….let your mind unwind after a few days of hard thinking and head up to Rocky Mountain National Park for the weekend.
The spam post I linked above put it best, I think:
Self’ll broaden the mind he how on route to amplify tall idea-experienced programs.I’m looking forward to amplifying tall idea-experienced programs. And teaching Rails.
We had a great time this year at the RailsConf Community Project Code-Drive. Among other things that happened, Evan, Rich, and I created and released gitjour, which is steadily becoming standard Ruby conference must-have software.
So we thought we’d do it again in Europe. If you have an idea for something you’d like to work on, visit the signup page and list it there. If you don’t have an idea, just show up on the tutorial day with a laptop and an open mind.
Also, don’t miss Early Registration, which ends on July 15 and saves you up to €150.
Congratulations to Evan and the Rubinius team. Rubinius runs Rails!
By this time next year, we’ll see production deployments of Rubinius, with Rubinius quickly becoming the defacto standard Ruby implementation after that. You won’t want to try to deploy your Rails application on it today, but it’s definitely time to give it a look if you haven’t yet.
I’m always looking for ways to get humans together for meaningful (potentially lasting) interactions at our conferences. So we’re trying something new this year during the tutorial day. It happens on the first (or 0th?) day of the conference on purpose: so the work can continue for the rest of the conference. My hope is to bring project owners/committers together with aspiring contributors and bring more people into the fold of projects which need help. Think of it as a room full of code sprints happening all at once. Here’s the description:
Project Owners: Do you have a project you’d like to work with other people on? Maybe it’s an established Open Source project. Maybe it’s a new idea. Come find like-minded developers and spend the day hacking together.
Developers: Are you looking to get involved in an Open Source project but need a bootstrapping session to get you started? Looking for chances to meet other developers and establish collaborative working relationships? Looking to learn by collaborating with others? Come find a project and spend the day sitting side-by-side with one or more of its developers learning the ropes and contributing code.
RailsConf is the largest physical gathering of Ruby and Rails developers internationally. Let’s take advantage of all being in one place at the same time AND take the chance to give something back to the projects and community which we so greatly benefit from.
In the morning, project leaders and representatives will have a chance to make a short pitch for their projects and the work they hope to get done. For the rest of the day, groups will self-organize and write code! Roll up your sleeves and prepare to learn, teach, and most importantly, contribute.
Go to this page and add your project or idea to the list of projects likely to be active in the Code Drive.