While doing a fresh pull of Merb edge this weekend I realized that all of my forms had suddenly just disappeared and I was also receiving some NoMethod errors; which is never a fun scenario. Just in case you like to develop on edge (and who doesn’t when it comes to Merb?) you should probably be aware of a few changes that went through this week.

There was a pretty big refactoring with the form_helpers. In fact, it’s still a little flaky at the time of this writing.

UPDATE: It has stabilized over the next couple of days and, according to wycats and GMFlash, should become more solid by the next release (0.9.5 at the time of this writing).

Previously in merb there were:

• “_control” controls* – These controls signified that it was going to be “bound” to a specific attribute on a model.

• “_field” controls* – These were controls which were not bound to a model.

This refactor completely eliminates all of that complexity. Now there is only one way helper for each control. One helper to bring them all and in the darkness bind them. Sorry I had to do it.

Here are a list of the new helper methods:

• form (previously this was form_tag)
• form_for (This helper will generate a form that is bound to a specific resource (model)
• button
• submit (previously submit_button)
• text_field, password_field, hidden_field file_field, text_area, select, check_box, radio_button, and radio_group

1. The ‘form’ and ‘form_for’ methods now render output so you’ll need to prefix it with a %= rather than % and = rather than – if you’re using HAML.

The way you bind specific attributes to a model is by simply passing a symbol in to the method. You can see this in the private bound? method in the helpers.rb file.

        private
      
        def bound?(*args)
          args.first.is_a?(Symbol)
        end
      

Thank you, sweet baby jesus and GMFlash, for this refactor. It really does simplify views that require forms and makes things much cleaner. Suddenly the form helpers just make much more sense to me.

At the time of this writing there are a couple patches in the pipe:

1. There a patch in the intertubes that changes the way ‘select’ works. Here is the ticket and the patch. UPDATE: This has been merged in to the refactoring.
2. Apparently there is a bug in the way the checkbox control sends it’s output that does not allow a checked checkbox to ever render a ‘true’ (1) value. UPDATE: My patched was merged in. You can see the ticket (and patch) here at Lighthouse.

Examples

Form Helper (not bound to a model)

      <%= form :action => url(:login) do %>
        <%= text_field :name => "login", :label => "Username" %>
        <%= text_field :name => "password", :label => "Password" %>
        <%= submit "Log in" %>
      <% end =%>
      

Form Helper (bound to a model)

      <%= form_for @post, :action => url(:posts) do %>
        <%= text_field :title, :label => "Title" %>
        <%= text_area :body, :label => "Body" %>
        <%= check_box :published %>
        <%= submit "Create or Update" %>
      <% end =%>
      

• Notice the %= at the beginning and end of the form and form_for methods.
• Notice the :symbol being passed in to the control helper methods to signify a “bound” control.

select helper (bound)

select :foo, :collection => [['0', 'Text Method 1'], ['1', 'Text Method 2' ]]

which should generate something like this:

        <select name="foo">
          <option value="0">Text Method 1</option>
          <option value="1">Text Method 2</option>
        </select>
      

The above code didn’t go through the Ruby interpreter at all. It was all hand typed so please forgive me if there are typos.

Important Notes

When using the new helper methods to bind to your models. Please note that your models are required to have an errors methods; This error method should be provided by your ORM of choice (DM or AR).

So, if your models have:

include DataMapper::Resource

then all you need to do in your init.rb file is:

dependency "dm-validations"

As always there is much more that these helper methods are capable of, but it will take some digging around to find. You can always check out the merb documentation, stop by the #merb channel, or dig in to the merb code yourself!

As many of you may have noticed I decided to roll my own blog engine in merb and I have to say the most annoying thing so far … is SPAM. My comments have just been inundated with the most absurd comments ever.

So, I apologize that the site has just been a spam hole for a week or so, but I finally implemented some spam protection via Mollom (which is a similar service to Akismet).

I’m not entirely sure how well Mollom is going to work yet, but a couple of the test comments that I’ve made have been blocked so that’s a good start. I’ll be adding in some more data so that Mollom can make some better decisions over the next couple days in hopes to eliminate as much spam as possible.

Anyways … just wanted to drop a quick apology for all the viagra and penis enlargement ads that have been flooding the site.

Well, I just got my new blog engine published … which I’ve tentatively code named “smerb”. It’s really nothing great right now, but it lets me post articles, provides a simple feed reader, allows for comments and has a simple administrative interface. It’s a nice jump away from WordPress and doesn’t provide all of the bells and whistles, but it’ll work for now.

The fun part? The technology behind it all! It’s all written in Ruby on the Merb Framework. Using DataMapper as the ORM, haml as the template language, jQuery for the javascript library and being hosted over on Slicehost. I think the best thing about it is how much I’ve learned about implementing everything.

There are still a lot of kinks I need to get worked out and transfer over some of the existing data from the WordPress site, but for the most part it’s working pretty well. I changed over my DNS entries yesterday so I’m sure it will take the weekend for it to propagate through the interwebs.

With sqlite3 you can pass in a few arguments to the sqlite3 command to initialize your session with some, in my opinion, better defaults. The sqlite3 command I typically use looks like this:

sqlite3 -column -header [database]

This simply puts sqlite3 in to column mode and displays the names of the column (headers) above the table. It reads a lot easier to me. A majority of the time I go in to the sqlite3 database I end up issuing the command:

      mode column
      header on
      

So what I wanted to do was something like this:

./script/dbconsole --mode column --header

Seemed easy enough … but keep in mind, this is just a personal preference, but the current implementation of the ./script/dbconsole command did not allow me to do this:

./script/dbconsole --mode [column, line, list, html] --header

I modified the dbconsole script a little bit to allow for this functionality. With this patch you can now issue these optional commands. Obviously if you don’t provide any of the options the script will just load you in to your default sqlite3 instance and you can go from there.

It took me about 30 minutes to put this together and I’m sure there are some things that I’m missing, but this should at least get you started.

Please let me know if you make any changes as I would be interested in seeing them.

I know this might sound strange coming from a developer and someone who feels that they don’t have an artistic bone in their body, but I still understand the importance of a taking care of your personal appearance as well as your virtual presence. I can’t stress enough how important it is for companies to take pride in the look and feel of their web site. This is especially true for companies that are looking for new clients or even looking to hire new employees.

Recently, I’ve been browsing through Rails job boards on the Ruby on Rails and Working with Rails sites. Typically, the first thing I do is read through the job description to make sure that they really know what they’re looking for and working on. After reading through a job description my next step is to go to their web site. Oddly enough, this has the most weight in the process for me. I consider your web site to be your first impression. To me this is no different than meeting someone in person.

If I meet someone in person and they’re rockin’ a mullet (as awesome as that would be), some old school Girbaud jeans, a tank top, Gucci sunglasses, and some Prada boots ... I’d be a little reluctant to sit down in a public area and discuss anything with you … let alone be able to take you seriously about your business.

Now, don’t get me wrong … this isn’t to say that you need to put on a Versace suit and stroll around town like you’re made of money either! Not at all. I don’t really care if you’re wearing Under Armour and just left the gym, have a faux hawk and just left a concert wearing your favorite bands t-shirt, or you really did step out of a board meeting wearing your work suit. The important thing is that you’ve put yourself together in a manor that depicts your personal style at that given moment. The web is no different and probably even more important than your personal style.

You’re doing it right

If I’m browsing your site and I somehow feel the need to crank up Firebug or the source code to look at the HTML behind the scenes to see how you’ve put things together … you can almost guarantee that I’m going to submit my resume to your company. Even if you’re not actively looking for a developer. In fact, I’ve been known to browse sites and send emails to their contact us address just to tell them how much I appreciate their site design. It really is that crucial for me.

Or if your site has a good flow to it, well laid out color scheme, good font spacing and size, and just looks like some thought was put in to the design then you’re on the right track.

There are so many things that can make a site unique and/or attractive and to me it’s worth the time, money, and effort to put it together correctly if you’re relying on your web presence to do any marketing for you.

You’re doing it wrong

On the other hand … if your site has that cookie cutter corporate feel with the standard navigational drop down menus, blueish or orangish color scheme, pictures of people standing around the printer smiling like they’re at their wedding, because they’re looking at a document that someone just handed them (seriously?), but you’re looking for a ‘laid back Ruby Rockstar to develop your hot new product management system’ ... you might be doing it wrong.

To me that’s like looking for a lead guitarist for your Metallica cover band at an Opera. Sure you have a chance of finding someone who is musically inclined, but are they really interested in slammin’ down Jager Bombs on stage with you screaming out, “Give me fuel, Give me Fire, Give me that which I desire!”? Chances are probably slim.

My blog is currently running on WordPress and I’ve really been satisfied with it for the most part, but when it comes to putting together your own theme … all I can say is, ‘ouch.’ What a hassle! I could be going about it all wrong, but I’m not really motivated enough to download the code and get it running on my local box to figure out the ins and outs of WordPress. So, needless to say … it was a bit painful.

But in an effort to bring my site in to the 21st century … I spent some time today working on a redesign. I’ve often doodled on paper and come up with little sketches for a design. But nothing beats grabbing a few Mountain Dews, cracking open Photoshop and TextMate, and beating the CSS/HTML creativity out of me.

Honestly, it wasn’t all that bad. The hardest part about it was trying to trick WordPress in to thinking I was its daddy. The templates are not the cleanest in the world and digging through old PHP code made me a bit nauseous, but reminded me how much I need to appreciate erb, haml, liquid and the other template engines.

I’d still like to consolidate the front page a little bit and reduce the amount of ‘junk’ that’s getting tossed out on the page. So don’t be surprised if you’re browsing around the site and run in to an issue or two. It should be resolved soon.

I’ve heard a lot about Twitter’s scaling problems (read: bad architecture) lately. Day after day after day people keep talking about why Twitter is constantly having issues, constantly ‘whaling out’, isn’t scaling, and I love reading all the technical aspects of what people think is happening. But, Twitter, it’s getting really old!

Need I remind everyone that we live in the 21st century? When did ‘scaling’ become such a HUGE issue? We’ve got servers that can compute complex algorithms that allow us to travel to distant planets. We’ve got search engines that handle massive amounts of requests every second. We’ve got servers that are handling money traveling through our economy, computers that are constantly supporting our basic way of life, computers and applications that appear to handle much more complex things than sending out millions or even billions (I don’t know Twitter’s statistics) of text messages a day.

Understand that I know I’m simplifying things, but when it comes down to it … Twitter is a simple messaging application. So … let’s see here. We have:

• MMORPG’s (Massive Multiplayer Online): Massive Multiplayer games out there that are pushing millions of users playing a single game online. They’re constantly pushing and pulling massive amounts of data from a server and to your computer, rendering graphics, processing commands, storing items, hit points, kills, and so on and so forth.
• YouTube: We’ve got sites that that are streaming video to millions of viewers a day.
• Facebook / Myspace: Social Networking applications are handling a LOT more users, functionality, and traffic than Twitter. Last year Facebook received 26 million visitors in August with a little more than 22 million end up signing in.
• Flickr: Handling god knows how much data being uploaded, downloaded, commented on, tagged, shared, linked to, viewed … the list goes on and on.
• Stock Market: Tons and tons of servers and computers out there requesting and sending massive amounts of data through our stock market every hour of every day.
• Online Banking: Millions of people do online banking. Posting checks instantly to their account, transferring money hourly from one part of the world to the other.
• And lets not forget the massive amounts of Porn being served up around the net! I can’t even imagine how many web sites out there are streaming God knows how much data of Jenna Jameson’s boobies to God knows how many people!

Seriously, Twitter. Seriously …

The list of incredibly useful and ‘scaled’ application is extensive! And you’re going to tell me that we’ve now run in to a problem with sending messages from one user to another? Come on now. Put your heads together and come up with a solution before someone else does! I can tell you this … as soon as another contender supports SMS. I’ll be showing Twitter the deuce.

I’ve really been trying to give Twitter the benefit of the doubt. I’m really not a hard customer to satisfy. I know sites have problems from time to time, but Twitter is slowly making it’s way on to my list of sites that I really just frustrate me. Right up there next to Myspace and eVite (I don’t even want to link to them I hate them so much).

Basically all this boils down to is that Twitter is not providing a very good service with either a) a very bad architecture or b) a very bad code base. Period.

I understand the fact that it’s a big service and you blew up way it was ready. I understand that it has a LOT of users and a LOT of throughput. I understand that the problems multiple exponentially and I really don’t know anything about the internal architecture or code base … but let’s get things together! Twitter isn’t exactly rocket science here and you’ve received $15 million in VC funding (probably more) ... and you can’t solve this scalability problem? What going on?

Before I start … I’d like to state that I’m not against plugins at all. So please don’t think that I’m knocking them in any way. There’s no doubt about it … plugins are one of the things that makes Rails great. But as the saying goes, “With great power … comes great responsibility.” So please keep that in mind while reading the article. I’m not telling you to completely ignore plugins all together or just write your own code all the time, but just understand that plugins don’t have to be added in to your application on a whim just because the plugin claims it does X functionality.

It’s my personal preference to write my own models and controllers for an application before adding a plugin. There are obviously some exceptions to the rule: restful-authentication, acts_as_state_machine, will_paginate, exception_notification, rspec (obviously) and a few others are in my list of mandatory plugins for pretty much any application I write. To me, these plugins provide site-wide functionality that allows me to focus on my application rather than the unnecessary bits.

I’m sure the question many of you are asking now is, “Bryan … why would you write the code yourself if someone else has already done it for you?” And it’s a perfectly valid question! I’m sure there are tons of arguments for and against it. I’m a firm believer of the 37signals book Getting Real. It’s an excellent read and it talks a lot about keeping things simple and not just adding in functionality just because. The reason I believe in writing the code myself is that it let’s me keep things real (to a certain extent). It forces me to look at how simple I can make my models and controllers to start out with and then if I need something more elaborate take that route.

But a majority of the plugins that I add in provide me a whole bunch of cool functionality and features that I just don’t need. Granted, they add in great features that any customer would love to have, but I find that when I keep things real … I don’t need a lot of the stuff that the plugins provide. Remember though, this is not a concrete statement about all plugins. There are plugins out there that are extremely helpful and let you focus more on your application rather than writing code to get you started writing your application.

Some examples of plugins that I would start coding myself before I dropped in a plugin:

1. Social Networking. If I’m writing an application that requires some social networking capabilities … why use lovd-by-less, insoshi, or community engine? Talk to your customers, figure out exactly how they want their users to interact with each other and then write the code yourself! Often times, the code is much simpler to write, because the customer does not really require a full socially networked site like Facebook. They probably just want their users to be able to send messages to each other or view another users profile. That is if you don’t tell them you can just ‘drop in’ Facebook like functionality … or at least tell them the repercussions of doing so.
2. Tagging. There are a lot of tagging plugins out there that are excellent. They let you generate tag clouds, find different objects tagged with similar content, etc … but does my application really need that stuff right now? Maybe. Maybe not. I typically find that my tagging requirements are always simple at first and adding in a plugin is just not worth it at the time.
3. Blogging. Adding my own simple Blog or Post model with simple tests around it should be plenty to get me started. As my application evolves and I realize that I need a more functionality … then explore other options. Writing more of my own code or looking around at plugins. This allows me to start at square one and “Get Real” with the functionality of my application.

Let me take this one step further … when thinking about adding some functionality to a Rails application; Typically, the first thing Rails developers do now-a-days is ask Google with the assumption that someone else has already done it. rails networking plugin they’ll enter in and not surprisingly Google responds with a whole slew of social networking plugins. Repeat this process 5 to 10 times and suddenly we’ve pieced together an application with no effort, no thought, no planning, and probably worst of all … no specs!

I also think it gives customers a false sense of how easy it is to develop in Rails. If your customer is constantly asking you to add functionality and your response is, “Sure, we can do that really quickly” purely because you can drop in a plugin … to me, this is bad, because I don’t think we’re truly ‘developing’ anything as much as we are gluing pieces of different puzzles together.

In the .NET world I have a word for developers who live inside of Visual Studio; using the Designer to piece together their applications. I refer to them as “Drag and Drop Developers.” These are the developers who think that development is all about dragging objects on to a form, double clicking on them, and hooking up events with some of their own code and some snippets from Google. And things can work out when writing small applications using this approach, but if you’re writing any sort of production level code then things can (and often do) go horribly wrong. This “drag and drop” mentality is the same feeling I get from Rails plugins.

Sure, things might work pretty well for a while, but the minute I have to start thinking about how to do something to my application that is truly original … I’m going to have to jump in to plugins and attempt to couple some new model (or a model in another plugin) to another model; which in turn is going to cause me to add some new relationships in to the models inside the plugins, and before I know it I’ve got a rubber band ball of code with no specs all. Which is not good. Not good at all.

Of course, you can develop applications this way. I’ve done it before and I’m sure I’ll do it again, but I think if you’re serious about developing an application you need to take the time to think about whether or not you just want to drag and drop plugins in to your application or if you should spend some time thinking about your domain model, thinking about what your application needs, determine which models need to interact with other models and write that code yourself!

I think if you continually drag and drop plugins in to your application without thinking about exactly how things are fitting together then you, your application, and worst of all your customer(s) are going to suffer the consequences. I don’t think that plugins are a substitute for taking the time to think about the design of your application, about the models you’ll need, about interactions that will need to occur in those models and while doing that … writing specs!

An example of plugins that I feel are just a little too much are the new ‘social networking’ plugins (Insoshi, lovd-by-less, acts_as_community, etc) that have started cropping up around the Rails community. Again, I think these plugins are great. I love the fact that they’re sharing their code and that they allow developers to quickly get something up and running, but to me this is Rails scaffolding code taken to another level. Scaffolding is great for demonstrations and showing people how quickly you can get things working, but when it comes to actually using scaffolded code … 98% of the time I end up killing it off, because it is not useful in a real situation.

Now, don’t get me wrong … I understand that plugins are open source. If you don’t like something about it or it doesn’t fit my applications needs … than I’m more than welcome to hop in to the code and tweak it to meet my applications needs and I’m all for that! But more often than not things don’t work out for the better when doing this. Developers end up with an untested hack here and an untested hack there to get things pieced together and slowly but surely (“Don’t call me shirley” – Michael Scott. ha, sorry) your application ends up as a Jenga puzzle. Just waiting for that one piece of the puzzle to knock everything out of place.

Agree? Disagree? Leave a comment and let me know.

{{{ Things are wrapping up here at RailsConf 2008 and I’ve only had about 11 hours of sleep over the past 3 days so you’ll have to forgive any incoherent or fragmented sentences. Thank God for caffeine and advil though.

Anyways … I just wanted to put together a quick synopsis of the lessons that I personally attended as well as put a little information about some of the people that I met and experiences I had while hanging out at RailsConf 2008.

The Sessions

A lot of the talks have been very good. I was a little disappointed on Friday when I was kicked out of a couple sessions due to some crap about a fire safety code? I mean seriously … who cares about fires, anyways? Yeah … but they got it sorted out on Saturday and even got some of the speakers to agree to redoing their sessions on Sunday as well. Very nice.

Friday

Entrepreneurs on Rails

Some very interesting discussion points about getting a company together and moving forward with going out on your own. The most important thing I took out of this was that you really need to have the energy, dedication, and passion to work on whatever it is you’re doing. This rang true for me, because after a full day of doing ‘real’ work during the day I also need to have the drive to spend another hour or two on a project that I’m interested in.

10 Things I Hate about Web Apps

I’ve already written a bit about this one and really wasn’t too happy with sitting in on it. I’m sure there were a lot of helpful things for certain people, but it just wasn’t doin’ it for me.

Lightning Talks

After leaving the “10 Things I Hate about Web Apps” I walked over to the lightning talks. Unfortunately, I only caught the last 4 or 5, but there were some neat ideas that people were working with and it was a nice change of pace from the typical sessions.

Faster, Better, ORM with DataMapper

This was actually one of the more interesting ones for me. I’m extremely motivated to give DataMapper a try now that I’ve seen it in action. I’m not entirely sure I’m going to go against the grain with using it in a Rails application. So I think I’m going to do something with Merb using DataMapper as my ORM of choice. I’m still trying to think of a decent application to kind of use for testing the ORM waters though … feel free to leave a suggestion.

The Profitable Programmer: Creating Successful Side Projects

I was kind of torn in this session. This talk included Geoffrey Groesenbach interviewing 4 very notable people: The creators/developers of GitHub, FamSpam, Gravatar, and PeepCode. All of which I’m extremely happy for … but a piece of me got a little frustrated. I want to be them. I want to build something good. I want to be known in the community, but it’s not an easy thing. There are hurdles and it’s hard coming up with those ideas and even harder to act on them. But again … I’m truly happy for them and their success … I just want some of it. Which is actually motivation to do work harder on getting something I believe in put together.

Remote Pair Programming

I actually ducked out of the Profitable Programmer a little early and caught the tail end of this session. I really didn’t get a whole lot of information from it, but heard talks about setting up web cams and using some of the more obvious tools: SSH, Emacs over TextMate, using WebCams, VNC.

They admitted that there was no perfect way to go about Remote Pairing, but that technologies were there to make it easier. I tend to agree, but it’s still very difficult.

UI Design on Rails

This was geared a lot towards Designers, but it was given by Ryan Singer, of 37 Signals, and it was nice hearing things from a Designer stand point. Ryan gave a very good presentation and it was nice seeing a designer who is really knowledgeable of certain development processes. It’s nice to see someone going above and beyond their role and step in to the development world just enough to understand how to better work with them. Excellent talk and the questions session was even better.

Side Notes on Friday

I wasn’t able to attend the session, but I heard extremely good things about “MagLev: Ruby That Scales.” I plan on doing some reading up on it over the next week or two.

Saturday

Working the Way You Want To: Mingle 2.0

I’m a huge fan of Mingle and even more so of Mingle 2.0. Their software just seems to fit so well in to the agile development process. I really didn’t take a lot out of the session as far as technical things go or Agile methodologies, but it was very cool seeing some of the new features.

I’m eagerly awaiting their integration with Git SCM and trying out the concept of creating tasks for stories. A great feature that was not available in 1.x and is extremely welcome in the 2.0 version.

Advanced RESTful Rails

I think my hangover and lack of sleep were in full effect on this one, because I can’t say as I remember a whole lot about it other than, “Use REST. It’s good.”

Fast, Sexy, and Svelte: Our Kind of Rails Testing

Loved it. I’m a huge fan of BDD/TDD and having quick feed back on your tests using mocks/stubs over database interactions. This was a great presentation on how to structure your tests and I’m glad I got to see it.

Integration Testing with RSpec’s Story Runner

I’m a huge fan of rSpec and Behavior Driven Development so this talk was great to be in. David Chelimsky started out with a nice quick introduction to what RSpec is, where it started, and about BDD in general. If you’re not real familiar with BDD and/or rSpec … I highly recommend giving it a shot.

The story runner demonstration was good … things kind of hopped around a lot and I think if you weren’t a little familiar with rSpec and the basics of the story runner already you might have gotten a little overwhelmed with using it, but I was able to come out with a couple new ideas for writing integration level tests and will be giving them a try this week.

Metaprogramming and Ruby Internals for Rails Programmers

This presentation is incredibly intense. There is a lot of C level code and low level information about Ruby. Patrick does a very good job at keeping the C code interesting and presenting it in a way that is understandable. Unfortunately, Patrick’s computer gave out about 1/4 of the way through the presentation and it was taking a while to get it up and running again so I moved on to hang out and write some code in the hall with everyone else.

Sunday

The Worst Rails Code You’ve Ever Seen (and How Not to Write It Yourself)

Overall I think it was a good presentation. It had a lot of bad code examples; some that were just absolutely hideous pieces of code and then others that just seemed like one of those pieces of code that you get to work and just move on. I think a lot of the time it really just depends on the situation you’re in when writing the code.

My personal opinion is that when you’re writing code for a client who is not very technical and is relying on you, the developer, to make sure the plumbing is done correctly … there is some of the “Worst” code ever … that, unfortunately, just is the way that it is. Most clients are more worried about progress on the front end. They want to see ajax calls, images, functionality, etc … but, as a pragmatic or passionate developer I think it’s our job to make the decision on when and where refactoring needs to occur. And when the refactoring does need to happen I think your battles need to be chosen wisely. Different developers prefer different things and certain refactorings can take a lot of time and money that isn’t going to provide any visible feedback to the client.

De-Railing: Smashing the Rails Stack

Personally this presentation didn’t do it for me. There were a lot of good points about how to make sure that your application is as secure as it can be, but security is just one of those things that has never really piqued my interest. I understand that it is vital to write a secure application and I know enough about security to make sure that my servers and code are secure, but there are DEEP DEEP levels that can be applied to securing an application. And I admit freely that it’s just a personal lack of knowledge and interest on my part.

Oh, the Fail I’ve Known

To be honest … I haven’t really paid a lot of attention. I’ve been typing up this blog post and I feel bad for doing it, but … Adam just hasn’t caught my attention yet. Oops. I’m going to chalk it up to my lack of sleep though.

Meeting People

I’ve been fortunate enough to meet a lot of really good people while I’ve been here. Also got to catch up with some people that I’ve met at previous conferences. I have to say that meeting developers at the conference is, personally, the most satisfying thing for me at these conferences. There are so many smart people who are just eager and willing to talk about their development experiences and help you grow as a developer as well.

I didn’t get a chance to hang out with Patrick Reagan – which is disappointing, because he’s a good guy and one of the few people I’ve stayed in touch with from the LoneStar RubyConf. But I at least got in a few words with him and met some of his team over at Viget Labs. Good guys.

I also got to spend some time chatting with David Chelimsky from the rSpec Project. He’s an awesome guy to talk to and just has a fountain of useful information.

I was pretty excited that I got to meet David Heinemeier Hansson, Obie Fernandez, Jay Fields. It was very cool getting a chance to talk and/or hang out with each of them and just realizing that they’re really down to earth people is a nice thing to.

I was also able to meet a lot of the HashRocket Team. People like: Veez, Zach Inglis, Rein, Ben McDonald, Jim Remsik (Tiger), Sandro Turriate ... all very cool guys. A few of us traveled around downtown Portland and I’m pretty sure we drank a majority of the beer. Then stumbled back to the hotel for a few good games of Werewolf. Good times.

All in all, it was an awesome trip. There was tons of good information from the sessions and a lot of good people to meet. Hope to see everyone again at RubyConf and next years RailsConf. }}}

{{{I sat in on the 10 Things I hate about Web applications session and I had to step out in the first 15 minutes. I’m sure it could have been useful to some people, but it seemed to be one of those obvious things that you’ve just got to deal with as a developer. A web application developer complaining about all the different technologies, to me, is kind of like an auto mechanic complaining about all the different types of wrenches, screw drivers, ratchets, and the different sizes that are needed to fix a car. Come on.It discussed the standard things that every web developer has problems with when it comes to web development: * HTML* Browser Compatibility* CSS* JavascriptThese have been “problems” with web development since the dawn of time and a lot of steps have been taken to actually reduce the frustrations: Haml, Javascript Librares, CSS 3 (soon to come), but I just don’t really see the use in discussing why you hate the tools and languages you have to learn to be a master of your craft.Anyways … I sat outside with Wynn for a bit and I think he was going to spend some time working on the TickStart application we’ve started developing internally and I walked over to the lightning talks; which was a little more interesting that then 10 Things I hate about Web Applications session.I’m also keeping my twitter up to date so if you want more information: http://twitter.com/bryanray—follow along.ps. I’m not spell checking or editing these posts, because I don’t have time … so please forgive the poor sentence structure, grammar, and spelling.}}}