Blog

Oct 06 2005

Comments

Pragmatic Ajax Beta Now Available

The Beta Book of "Pragmatic Ajax" is now available. Pick it up at The Pragmatic Programmer. I'm personally just thrilled with the beta process; I hope lots of you will take advantage of it, and help us along the way. With the beta program, the feedback from the readers helps shape the final version of the book. We've called it Agile Bookwriting here in this space before; now its time to put it to the test directly.

Hop on over and have a look!

Oct 04 2005

Comments

What's new in C#, or who do you trust most?

Ted Neward has written a nice summary of the language innovations that we can expect be in C# 3.0. Obviously the success of various dynamic languages is having an impact -- all five of the features that Ted highlights have obvious (and simpler) analogs in dynamic languages.

The argument that I infer from Ted's piece is "Look! now we can have (some of) the expressiveness of dynamic languages with (most of) the safety of a statically typed language." Let me be clear that this is a good thing -- I am always looking for ways to be more expressive in statically typed languages.

But just because C# now looks a little more like some dynamic languages, don't make the mistake of assuming that two worlds are converging. In the most important ways, they are as different as ever. Here's why: Languages like C# "bake in" specific and detailed rules for inheritance, encapsulation, delegation, how symbols are interpreted, etc. In dynamic languages, similar rules exist, but they are not part of the language core. Instead, they are idiomatic extensions built within the language itself. Development teams can follow these idiomatic rules. Or, they can build (and enforce!) their own rules, specifically tailored to their needs. This has huge implications for productivity. In dynamic languages, you get to build the language up toward your domain, while you build the solution down.

So why has the static/dynamic debate staggered on for so long? I think we could get closer to some answers with better choice of terms. "Static" vs. "dynamic" is highly misleading. I propose we use a new set of names: vendor-oriented vs. developer-oriented programming, or VOP vs. DOP.

So who do you trust most: vendors or developers?

Sep 27 2005

Comments

Pragmatic Ajax

We're extremely pleased to be able to announce the imminent release of the beta book of Pragmatic Ajax: A Web 2.0 Primer. Working with Ben Galbraith and Dion Almaer of Ajaxian.com, and of course Dave and Andy at Pragmatic Programmer, the book will be released as a beta within the next two weeks. Beta books at PragProg mean that you can buy the book now and read the chapters in PDF format. When the paper book finishes printing, it will arrive on your doorstep in the first wave. Plus, your feedback will help shape the book for final publishing.

As soon as we have a link to the official site for the book, we'll publish it here. Until then, I'll be heads down wrapping up the first beta.

Aug 26 2005

Comments

The Ruby on Rails Management Advantage

Rails changes the game for developers. That ship has sailed and we're (almost) all on board. Whether or not the masses believe in our mantra of "10x productivity", it won't change the fact that the meme has entered our collective conciousness. I'm not here to write about that, though. At Relevance, we believe very strongly in the change that Rails brings to web development. But we also have a firm belief that Rails changes everything for the managers, as well.

There's a certain amount of frustration going from dev to manager. Instead of knowing a problem inside and out, you have to rely on your devs to have that depth of knowledge. Rather than solving technical problems directly, you have to solve organizational problems to clear the path for the devs. Most importantly, you have to make sure that the appropriate feedback gets routed to the right people at the right time: is the app doing what it is supposed to? Is the code well written? Are we going to be on time?

There was something supremely satisfying about starting a consultancy where we didn't have to worry about chasing other devs around, and just focus on getting stuff done ourselves. But it can't always be that way, and it isn't that way for thousands of development managers who have real work to get done. We see Ruby on Rails as providing a gateway to a better kind of development manager, and a more satisfying one for those who get "promoted" out of dev and into management. It comes down to five main principles:

  1. The feedback cycles are all shorter
  2. Easy DSLs enable more direct knowledge of the product for the managers
  3. The target platform and its capabilities have a broader reach than ever before
  4. The stack is open source from top to bottom, and when I say "open" I really mean it this time
  5. Components Aren't Necessary (the CAN principle)

The feedback cycles are all shorter

Yeah, sure, Rails shortens the feedback cycle for developers. I wrote earlier about the benefit I get from a lack of compile-redeploy steps while developing; similarly, the way Rails crafts skeleton unit and functional tests for you as you work prompts developers to utilize those techniques more often. However, as a manager, the feedback we worry about is higher level. I want to know the overall status of my application at all times; I want to be able to get it in front of customers early and have them feel that the development team is responsive to their needs.

With Rails, every Rake file comes stocked with tasks for running the unit tests and giving you performance and composition metrics for your codebase. The composition metrics are surprisingly informative, quickly giving you LOC information and ratios of tests to code. What's best about these metrics is that they are part and parcel of the build file for every Rails project; no extra installation needed. There are certainly other metrics I'd like to see as part of the process (code coverage, for example) but, for my money, I usually just want to check the pulse of the project, not do a complete workup. Whenever I need it, I just checkout the latest version and fire up Rake.

Perhaps best of all, though, is the rapid prototyping (scaffolding) capabilities of Rails. As soon as a customer sketches out the broad outlines of a project, my team can have it built. Sometimes, it can happen during the meeting where we are hashing out the details. I can't overstress the power of getting a whole site in front of the customer within such a short amount of time. Customers never, ever know how to tell you what they are thinking. Customers are like Justice Potter Stewart: "I may not know how to define my application, but I'll know it when I see it." The most effective way to separate what they say from what they mean is by showing them working code. Rails' scaffolding (and the ease with which you can override it) gives my teams more time in front of the customer to find out what they really want. As a manager, I feel much more comfortable with the end product as a result.

Easy DSLs

The hardest part of moving from front-line developer to technical manager is having to understand every thread of the tapestry that is your application. As front-line devs, we can narrow focus. As managers, we've got to know what everybody is doing at all times. Generally, we don't have to know every detail, but we need to know enough about what everybody is doing to keep everyone moving in the same direction.

I've often found myself in this situation. The problem isn't that I can't understand what everybody is doing, its that I don't have the time to ferret it all out. One of the beautiful features of Rails (mostly due to its foundation, Ruby) is the ease with which you can create abstractions within the codebase that look, for all the world, like regular Ruby syntax. We like to talk about these abstractions as "domain specific languages" -- that is, functional syntax that looks and acts like other generalized programming syntax but accomplish domain- or even application-specific goals. Now, as a manager, as I'm looking through the code, I see easy-to-read abstractions, well integrated into the "mainline" code flow. If I need to dig deeper, I can, but again, often I just want to see how my devs are coming along.

The target platform has greater reach

When new projects are coming down the pipe and you have to build a team to meet the requirements, you're often faced with the eternal question: where does it have to be deployed and who do I have around here that can work on that platform? If it has to be a rich client app, then you have to work with the deployment platform. If it has a clusterable server component, then you have to choose the flavor you want. Java has done a good (but not great) job of solving the two prongs of the problem. Rails+Ajax goes a step further.

With Ajax, the browser becomes a target platform for real rich applications, with dynamic content, asynchronous server callbacks, dramatic effects. With Rails on the server, you get fantastic Ajax frameworks built in, allowing you to use a single authoring environment (Rails) to craft robust server-side code AND full, rich client applications. The difficult decisions between Windows and everything else, WinForms and Swing, Swing and SWT, etc., melt away.

The stack is OPEN source

Rails gives my team a single unified stack from top to bottom, all of it open source. The Rails stack includes MVC support, an O/RM, a Web Services integration layer, rendering support, everything I need to build a web application. I don't have my team devoting any of its time to integration techniques; since the frameworks are already integrated, I don't have to worry about which layer's configuration settings are going to mess up the O/RM's transaction processing. I no longer have to care about how to get my model objects out of my backend framework and into my render tool.

And since the framework is built in Ruby, Rails isn't just open source. It is truly *open* source. I've been involved in multiple development efforts where we were using an open source project as part of the solution and ran up against a brick wall. Either there were bugs, or promised features that weren't real yet, or the tool just didn't target our problem space the way we wanted to. I can say that we never, ever cracked open the source of those tools to modify them. We either waited for a patch, or just worked around it.

Rails (and Ruby) make it dead simple to extend the framework in interesting ways. The main reason for this is the fact that you can modify base framework types (and, for that matter, base platform types) without modifying the source at all. My environment.rb file is littered with extensions to base types in all my projects. When I need full query ability on persistent types, I just extend ActiveRecord::Base to have some new fields and methods that enable that for me. If I can't get away with the default pluralization rules, I override the default behavior without touching the original source. I compare this to being able to prepend classes to the bootclasspath in Java; you get targeted, custom behavior without actually mucking up the baseline framework. Its reusable, without mandating reuse.

So Rails is open source in the traditional sense as well, which means that the development decisions being made are open to the world. Maybe TOO open, as DHH is quite the public figure and wears his heart on his sleeve. Regardless, as a manager, I can know what challenges my team is going to face using this framework just by tracking the Rails team's day to day blogs and the Rails mailing list. I can look into the current state of the code by keeping up with the Subversion trunk. Nothing new here; I get all those benefits with Hibernate, or Spring, or NHibernate, or what have you. But with Rails, all my layers are wrapped up in the same place -- my controller code, my rendering tools, my O/RM layer, all of it. Managers love this; if that wasn't true, Microsoft wouldn't still have the development market share it does. Choice is great for a developer. For a manager, choice is sometimes the wrong value to stress. Instead of framework churn and tensions between the directions of multiple OSS frameworks, Rails offers the benefits of both worlds: full OSS, but more structure around your choices. And if that structure doesn't suit your needs, just override and modify.

The CAN principle

Reusability. Let me say it again, in case there wasn't enough wailing and gnashing of teeth. REUSABILITY. As an industry, we've spent countless millions of person hours chasing after universal reusability. There's binary reuse, there's copy-n-paste reuse, endless component development frameworks (gimme a C...gimme an O....gimme an M...whaddya get? A hundred thousand confused C++ developers) and promise after promise of component marketplaces. Heck, VB was supposed to be the gateway drug to a global bazaar of interchangeable rich components. Modern software development is still rich in component-based development promises: anybody who describes their product as a "platform" that lets you extend it through "plug-ins" (WordPress or Eclipse, for example), and anytime you hear the word "software factories", you're talking about component reuse and development.

I don't want to seem dismissive of the effort. I just mean to say that not everything needs to be reusable. And it has been my experience that teams can actually move faster on most web projects starting from scratch with Rails than trying to cobble together existing components of some other platform. Part of it is the generalization inherent in a true component-based system. Those components, by default, are overly generic. They have to be. But it turns out that quite often, you'll need to tweak the behavior. Now, you can chase down the configuration options that allow the component to behave the way you want, or extend it or the framework in some way, or just live without the perfect solution. This is the norm. With Rails, you build exactly what you want, and stop when you have enough.

That "stop when you want" part is also key. Generic components tend to be rich in features (to be as many things to as many people as possible). When running down that road, you have to bite off a lot of features to get the set you really want. Bruce Tate refers to this as "eating the whole elephant" when talking about EJB. The problem isn't nearly as bad in the component-based development world, but it exists. When I have developer hours spent reducing the feature set of my application, I'm just burning dollar bills. Ted Neward said it perfectly when talking about "best practices": its all about the context. Genericized plug-n-play components are great in certain context, but unfortunately, I rarely work in those contexts.

Let me put it as a value proposition: if everything is genericizable, what possible value does my development team bring to the table? I happen to believe that most project require actual programming, not just assembly, and therefore I'd rather have my team working with programming tools than plug-in platforms.

Just another framework?

What's the purpose of all this, anyway? After all, isn't Rails Just Another Framework? In a sense, yes. Rails IS just another framework, and we shouldn't get too giddy with delight as we think about adopting it. There be magic, here, but there be dragons as well. It represents a platform switch, a new language to learn, and a reduction in the available libraries that make the Java community so attractive. I'm not convinced that Ruby will ever catch up to Java for the wealth of libraries available. I'm not convinced of the opposite, either.

I AM convinced, though, that dynamic languages and the metaprogramming strategies they enable offer new and lasting value to the development world. We've finally matured as an industry enough to recognize the inherent power of these kinds of tools. Instead of scoffing at JavaScript and VBScript, we have "real" languages like Perl, Python, Lisp and, yes, Ruby, to hang our collective hats on. These languages aren't Java Light™, they are intensely powerful (mostly object oriented) languages and runtimes. They lack certain features of the managed space that we have come to depend on (a security manager, as one giant example) but have a lot of the benefits (garbage collection, deep reflective capabilities).

As these languages and platforms now permeate our collective consciousness, they will necessarily infect the dominant players with their ideas. We're seeing all the major dynamic languages being targeted at the JVM and CLR (JRuby, IronPython, Jython, etc.) or being given their own managed runtime (Parrot). We've seen development languages created specifically for the runtimes (Groovy, Comega, etc.) We've seen a hundred Rails-like frameworks pop up (Trails, MonoRail, Grails, Django, etc.) Perhaps best of all, the success of Rails is causing people to rethink existing but unfortunately overlooked frameworks that offer a lot of the same value propositions (WebWork2, for example).

For me, Ruby on Rails represents the best of breed for this new way of thinking. I don't really feel like waiting around for everybody else to catch up. When I think that my technical problems can be solved in Rails, the choice is easy, because I *know* my management problems can be solved there.

Aug 26 2005

Comments

Relevance, Ajaxian Offer Rails+Ajax Training

(Purposefully short self-promotion post)

Relevance is extremely pleased to announce our new slate of Rails and Ruby training courses. Plus, through our relationship with Ajaxian, we're offering Ajax training as well. We're very excited about the new courses, and hope to see some of you in class soon.

Aug 19 2005

Comments

Ted gets Rails, doesn't get me

Ted has spoken again. I'll skip ahead to the end of his post for the tit-for-tat (check out Dion's response and what Glenn says for more).

Quoth Ted:

This, then, is interesting to me--is Rails only interesting because of "the fact that the 80% case is to only configure 10% of your app"? Or, is it that Rails' sole contribution is that it helps bring the pendulum back away from the layers-upon-layers default approach in Java projects? If that's the case, then I get Rails entirely, and I'll quite happily put the Rails book back on my shelf, because it means that it's major contribution is one of influence, and not one of "need to know for consulting practice". But that's NOT what I'm hearing the Rails-buzzers say, so I'm not convinced that Justin's identified what is is I missed.

Look, guys, at the end of the day, if Rails is about Ruby and the things that a scripting language can do that a compiled, statically-typed language can't, then Rails definitely has a place in the world and I'll take the time to learn it. If Rails is about bringing sanity back to the web framework space, then I'll wait for the Java and .NET Rails-influenced projects to ship and stick with something that has BOTH the sanity AND the support of managed platforms.

Of course Rails' "sole contribution" isn't convention over configuration. That's just one contribution, but the one that is infecting the world of Java web frameworks. The reason that this is the most infectious part of Rails is that this is the easiest part to emulate in Java. Most of the rest of what Rails brings to the table is harder to achieve, which is why it is harder to find on the Java side of the garden wall.

Glenn has pretty similar views, but I'll reiterate here. Rails' value proposition is:

  1. Ruby
  2. DSLs
  3. POWA
  4. Convention
  5. Speed

Ruby

Pretty clearly, Rails' biggest benefit is Ruby itself. Ruby is the engine that drives the train. Dynamic languages like Ruby provide for eloquence of expression and compile-/run-/deploy-time extension of the core framework abstractions. The ActiveRecord model is a clear example of this; extending classes at runtime to provide strongly-named property-bound finders (blogpost.find_by_title_and_author("Ted doesn't get Rails", "Dion")) is powerful, and hard to do in a statically typed language.

Its dynamism isn't just for DHH and the Rails team, either. Because of the way Ruby works, I can reach into the framework and tweak it to do just what I want without having to go and muck around with DHH's source code. Need more tools in ActiveRecord::Base? I just open the class in my environment.rb file, and add (or replace) what I need. And, since Ruby is interpreted, it sports the nifty no-compile-redeploy as well, which (as I've said earlier) is surprisingly important as I am developing an application.

The beating heart of Rails is Ruby.

DSLs

Lots of people have written about Ruby's suitability for creating DSLs. When it comes down to it, Ruby's extensibility and flexibility put it in a class with Lisp, Python and Perl and separate from byte-code-language-X for creating custom syntax. For me personally, extending the base constructs of Ruby to support new, app specific capabilities, makes my job 40 times easier.

For example, I have a customer for whom I had to develop a custom query builder based on an (unfinished and ever changing) complex domain model. I quickly realized two things; first, it was impossible for me to determine through purely reflective means how to search on each field in the data table. Sometimes, I wanted to search a foreign key column as a straigt-up value, sometimes as a join to another table, and there is nothing about the field (other than the requirement from the customer) to tell me which was which. Secondly, in the generalized result set, I needed a way to create links to display each row of the table. The problem is that I won't know ahead of time what type of object each row will represent, nor which action of which controller to invoke to display it. Enter my custom search dialect, which allows me to decorate my model classes thusly:

  class ModelObj < < ActiveRecord:Base
                                search_as_join :other_table_id, :yet_other_table_id
                                shows_with :my_controller, :my_show_action
  end

This is hardly the end-all-be-all of DSL design, but it is enormously powerful for me because it just becomes part of the language, and as the model changes and grows, the language supports the new complexity. With Java (or .NET), I have this power, but it is through bolt-ons to the core language. I've got AspectJ and AspectWerkz and AOPAlliance, or I've got annotations and metadata. With AOP, I can do everything I want, but I have to do it through an externalized syntax, a pre- (and/or post-) compiler, or a bunch of synthesized proxies and their attendent XML markup. With custom metadata, I can get most, but not all, of what I want, but in a more natural, built-in (at least as of Java Tiger) way.

POWA

As I said last time, and as Ted agreed, it is high time for web apps to act like web apps. I want my framework to deliver the HTML over HTTP experience as though that's what I intended all along to deliver. If it gives me nice ways to bridge the server and client that make it feel a little more tightly integrate (AJaX, anybody?), the more the better. What I DON'T want to forget about is that I'm on the web. Rails strikes, for me, the exact right balance between abstraction and transparency.

Convention

Rails' convention-over-configuration is a startup-enabling technology. By startup, I don't mean a new company, I mean a new project. Part of the Agile methodology's premise is that you get the framework of the app up and running as fast as possible (during the first iteration). Then, add on the features. Rails' convention based approach makes this an absolute lead-pipe cinch. I never question any more how long it will take me to get the front-to-back chassis in place. Rails all but guarantees I'll be finished in the first iteration, often in the first couple of days. Will I keep that chassis as is for the rest of the project? Of course not. The scaffolding is just that -- a shell that allows you to visualize the general shape of the application before you've put in all the foundation and walls and pretty siding. As you fill that stuff in, the scaffolding comes down, and you are left with real, working code. Yet all along, you've been able to demonstrate to your customer what the final thing might look like. Might be a little fuzzy along the way, but the end product won't be a total surprise.

Speed

Lastly, but certainly not least, Rails gives you speed. I simply have never worked in a web app framework that enabled me to move at such a controlled velocity. I may have moved faster in the past (particularly using generated ASP.NET pages) but I never had the tools built in to ensure I was doing a decent job. Not only is Rails a highly productive environment, but it almost forces you to take a test-and-prove approach to development, if through nothing more than guilt. (Hey, look, you just generated a new controller, and I put all these handy tests down here for you to use! What, you aren't going to use them? What kind of lame-o are you?!?!)

At the bottom of all of this is my core belief that Rails is for building web sites and web applications, not Enterprise Applications That Happen To Have a Browser-Based View. For those of us who are tasked with building those latter applications, I'm pretty much positive, given today's landscape, that I'll stick with Java. Through Java, I get three major things I don't get in Rails: JTA, JMS, java.security.manager. (Though, Brian seems to be solving the JMS issue...) Since my Fortune100 clients are pretty darn sure that all three are vital to their ongoing success, Rails (and its Ruby underpinnings) just aren't going to cut it for them yet. For everything else I do, which is the bulk of my work, Rails delivers productivity, value, rapid feedback, high quality, and code that not only delivers the customer's needs, but if they read it, LOOKS like it is delivering their needs. On top of it all, its fun to boot.

I think that Ted will end up putting the Rails and Ruby books back on his shelf, if for no other reason than he's never thrown away a book in his life. However, I believe that Ted really values technologies that offer something new to developers and their customers. Rails is clearly, for me, one of those technologies, and I think that Ted believes it too, really. He just likes to have blog-offs.

Aug 16 2005

Comments

Ted REALLY doesn't get Rails... ;-)

Ted Neward, a great friend, colleague, and all around smart-guy, just really missed the boat on Rails this last weekend. Dion pretty much hit the nail on the head on the technical response. Rails is a web framework that doesn't make me think I'm writing a Swing app, or that I'm writing an EJB app. It pretends to be nothing; it is, rather, a powerful framework for writing an app that delivers HTML over HTTP. Hell, what with the ASP.NET/JSF render kit wunderland, I'm starting to wonder if we need a new acronym: POWA (Plain Ol' Web App).

Regardless, he also whiffed (sorry big guy) in his musings about managed versions. There is, of course, Trails, a mighty attempt to make the Spring/Hibernate/Etc. stack as easy to configure and use as Rails, and MonoRail, an open source .NET equivalent as well. What fascinates me about MonoRail is that it is one of the first attempts to move away from the standard ASP.NET design pattern; the MVC crowd has just not found a great way to own that space. Maybe MonoRail will be the ticket. (By the way, check out the other stuff going on at CastleProject; DynamicProxy is a great little tool for making synthesized proxies a la Java, without all that Reflection.Emit() hassle.)

When I say he whiffed, it isn't because he couldn't tick off the various projects off the top of his head. Its because he missed that Rails is already influencing everybody else. The "small" feature he mentions, convention over configuration, is catching on like wildfire, and I don't think it would have unless Rails had highlighted the fact that the 80% case is to only configure 10% of your app. We're also seeing some folks revise their commitment to web components; with Rails, parameterized partial templates give you most of what you get with web components, and at a fraction of the compexity.

In short, next time I see Ted, I'll have to hose him down with the Kool-Aid. Clearly, he didn't get enough last weekend. ;-)

Aug 10 2005

Comments

Fowler on Rake

Martin Fowler has written a really nice intro to Rake. His exploration of Rake from first principles is good reading even for Ant and make users. I agree heartily with his final statement, that Rake is a powerful entry into the world of xmake tools and can easily be used in non-Ruby contexts. Certainly it has become my default tool for building just about everything but my existing Java projects (in which I have an investment in Ant).

Aug 06 2005

Comments

Are you (Spring) experienced?

The No Fluff, Just Stuff tour and Interface 21 have put together the (hopefully inaugural) premier Spring event, The Spring Experience. I've been graced with an invitation to speak; you really can't argue with the lineup: Rod and Juergen will of course be there, as well as Rob Harrop, Colin Sampaleanu, Keith Donald, Alef Arendsen, Ben Alex, Jim Clark, Bruce Tate, Matt Raible, Craig Walls, and Dion Almaer. It will be my first speaking engagement after the birth of my son (he's due in on Nov. 17, everybody knock on wood for me). I hope I'm coherent and awake when the time comes.

In any case, I'll be speaking on Spring Security, Spring MVC and (assuming it all works out) Spring and Mule. The show is a great lineup, and, c'mon, Bal Harbour in December? Who WOULDN'T want to be there? I'm looking forward to meeting all the folks I haven't met yet and trying not to embarrass myself with all the other fabulous speakers. Check it out, and we hope to see you there!

For those in the Boston area, you can get a taste of what's coming as I'll be giving a Spring overview at the NEJUG meeting on August 11th.

Jul 29 2005

Comments

Rails in the Enterprise

I've recently been teaching Java programming at a large, enterprise-y software company. Its an ongoing series of Intro Java, Advanced Java and Struts in rotation. The students have been uniformly wonderfuly; engaged, interested in learning, excited about the possibilities of Java.

This company also offers a series of, essentially, lunch-n-learn symposia whereby speakers from inside the company and out are invited to present on a topic for an hour. The presentations are filmed and distributed internally as webcasts for those who couldn't make the presentation. In the past, I'd done a few of these (focusing on unit testing and exploration testing). Each time I did, the turnout was roughly 10-12 students.

This week, during my Intro Java course, I gave a new presentation: Ruby on Rails. I told my Intro Java students that I'd be spending the lunch hour one floor up, presenting on a new, dynamic web app framework written in Ruby, and that they were welcome to come upstairs and have a look. Only one of them took me up on my offer. However, that wasn't too bad, as ~40-50 others came. The room was packed to the gills, with folks sitting on the floor against the walls at the edges of the room. The person who handles the series later told me that it was the best attended session in the (multi-year) history of the program; I've since talked to a lot of folks who watched the webcast as well.

After the presentation, a group of attendees gathered around, and their comments all were of a single theme. I'll quote one of them: "Thanks for bringing Rails here; its a dose of fresh air just to see some alternatives to what we normally do around here." I was, to be honest, trepedatious leading up to the presentation. I didn't know if anybody would show up at all. I'm stunned, really, at the turnout and the reception the topic received. It wasn't due to the presenter, that's for sure; it was the framework the brought them and the framework that hooked them.

Does this mean that Rails is suddenly going to replace this company's product line? Not in a million years. The primary software solutions they sell aren't really suited for Rails or even Ruby. But as a large company who themselves have to build and support a software infrastructure, they have tons of need for a framework that allows them to quickly build robust web apps to serve internal, and even external, customers. And Rails is a great tool for that job. Judging by the response it got at this one session, and the conversations I had with the attendees there, it will be quickly and widely adopted at at least one major software company this year. I bet it isn't the only one.

Popular Tags