Acts_As_Conference: My First Rails Conference
Be the 1st to comment!

Wow, what a weekend. My friend and I left at 8:30am Friday morning, and thanks to his wifi enabled cell phone, I was able to code in Rails for the entire two hour drive up to Orlando and the two hours back. In all, I put in 27 hrs logged on to my laptop in Rails in two days! (Yes, my wrists are sore).

It was a real joy to be around members of the Rails community; hearing tips and debates on various patterns and solutions using the Rails framework. I met some great people too, many of whose web sites I have followed over the last year of my personal Rails adventure.

Robert Dempsey was the organizer and he did a great job of putting this thing together. The hotel had wifi issues (is there a hotel that doesn’t…how hard is it to get wifi working in a hotel?), but the conference went very smoothly and was filled with great teachers.

Here are some of the tips I picked up:

Netbeans for Rails
When I first got into Rails I tried Aptana. However, it seemed so slow and clunky that over time I went back to using a text editor and the command line. But Sun was at the conference and discussed Netbeans, so I downloaded it on the spot and tried it out. I really like it so far. Sun provides a version of NetBeans which is only for Ruby, so you aren’t loading an IDE that covers every development language in existence. Thus, a smaller footprint. Its snappy, and provides all the extras one would expect from an IDE.

Best Practices for Rails Teams
Luke Francl discussed some helpful tips for working in Rails teams. While I’ve never worked in a Rails team of greater than two, I’ve been working in teams of 4-8 in Java for 8 years now, and I’m very familiar with the need for good processes and tools. In fact, this has been one of my personal areas of focus. Everywhere I’ve gone, I’ve worked to bring that Internet Software department into a good development model, from creating design/development processes, to using Maven, to developing internal Project Management applications. So this subject was of special interest to me.

Luke recommended some solutions for the db migrations clashes that can occur (more on that in a later post), managing third-party code, security, source control, bug tracking, continuous integration and more. It was a great summary of all of these elements. He’s posted a summary of the talk on the blog Rail Spikes.

Simple Web Development
The Friday keynote was by Dan Benjamin. Dan spoke the words I’ve spent so much time trying to teach at my places of work. Here are three quotes that sum it up nicely:

  • As simple as possible, but no simpler
  • Develop for one scenario, not for ten
  • Good code does not impress users

He said a lot more than that, but I was listening so intently I forgot to take notes!

Testing Rails Apps
Bryan Liles gave a great overview of the state of testing Rails software. His session was titled, BDD With RSpec, but he scratched out the RSpec. When he signed up for the class he was a fan of RSpec, but during that time he moved away from it. He instead focused on the overall concepts and importance of proper testing, and that the testing be from the standpoint of the functionality the user is expecting and that the test cases be written first (also known as Behavior Driven Development) and then write the code needed to fulfill those tests. This goes along great with the concept of keeping your application simple and to the point.

He recommended trying Shoulda for a little extra functionality on top of Test::Unit. I am now using Shoulda for my current application and it does add some nice helpers, textual test names, and contexts but without the need to learn a full replacement for Test::Unit.

Also thanks to RailsMachine for the great party on Friday night. The food and giveaways were great and so were the many Rails discussions. I am certainly looking forward to the next Rails conference, and if Robert does another one of these, I highly recommend it. When I find time I plan to write some posts with more detail on some of the topics I quickly reviewed in this post.

Internet Software Development: Choosing the Right Tool for the Job
Be the 1st to comment!

Rarely does a day go by, that I do not receive an article in my email or among the many RSS feeds I monitor, that compares various Internet software development tools and frameworks. Inevitability, the comments following the comparison turn into a war of words between the two camps compared. Each believes its framework or tool is the best. What strikes me is that rarely are the project requirements included in the discussion. It always seems to be based on the concept that there is one right framework for everything, and I cannot disagree with that more. Over my thirteen years of developing Internet applications I’ve used Perl, PHP, ASP, Javascript, XML, XSL, and Java (using JSPs, Servlets, Struts, WebWork). Now I’m learning and writing a applications with Ruby on Rails. Though Java has been my focus for the last nine years, I recently changed the title I prefer to use. No longer do I refer to myself as a Java Developer/Architect. Instead, I identify myself as being in the industry of Internet Software Development and Design. While the difference in the terms may seem insignificant, it is actually quite substantial.

There was a time when I believed Java was the only language anyone should use to write Internet software, but eventually I realized you can’t make that claim for any development framework. They all have their pros and they all have their cons. I don’t pick what is latest and greatest, because the latest is never guaranteed to be the greatest. Neither do I ignore the latest in defense of what I currently feel comfortable with. I do choose what fits my personality, what I enjoy working with, and what is best for the project at hand, including the ability to meet very tight deadlines. The key is: matching the language and the framework to the project. Many factors contribute to this selection. Here are some situations and the frameworks I generally use for each.

Read More »

Seth Godin's How to Create a Great Web Site
Be the 1st to comment!

Seth Godin is a best-selling author and entrepreneur and writes very insightful books on the topics of marketing, entrepreneurs, and personal success. In this article Seth outlines ten very simple components of a great web site. The list is well thought out and what amazes me is how many of these items I routinely see ignored on the Internet and how many of these points have been ignored by clients and/or companies I’ve worked with in developing web sites over the years.
The good news is that while there are over 50 million new web sites every year, the majority of them are the exact opposite of this list and become complete failures. You can still stand out in the crowd by creating a truly great web site.

Read Seth Godin’s, How to create a great website.

Monitor Your Browser and Javascript Performance
Be the 1st to comment!

I’m a big fan of Firefox, and over time I tend to collect a rather large number of plugins. The problem is, despite all the great functionality they provide, you can get carried away and seriously impact browser performance. As well, not all plugins are created equal as far as performance goes, and not all play nicely together.

My long time friend and fellow Internet Software Developer, Steve Pothoven, has posted a test on his blog which measures your browser’s processing speed. It can be used in two important ways:

1) to address the issue I mentioned in the first paragraph and help you check from time to time how your browser is performing after you’ve added more plugins, and

2) to determine just how much Javascript you may want to place into a user’s browser. His blog post lists a sampling of various computers and browsers so you can see how much various combinations can handle.

As for adjusting your Firefox to improve performance, when I first ran the test on my laptop, I had a .08. I disabled all my plugins and jumped drastically to almost .20. I began re-enabling the plugins one by one, and in the end determined that all were acceptable except two: Firebug and Yslow (which requires Firebug). Those two plugins destroyed my browser performance. For now, I’ve turned them both off, and enjoy a healthy .15 rating. Note: leaving Firebug enabled as a plugin, but disabled within the Firebug’s preferences does NOT improve performance.
Visit Steve’s test page and see what your performance is and where you fall within the sample numbers. Try disabling any plugins you have and testing again to see the difference.

Tip: If you have a large number of plugins, it may be time consuming to disable them all, so start Firefox in safe mode, by doing Run -> CMD and then entering ‘firefox -safe-mode’

Writing code to be readable over time
Be the 1st to comment!

At the Rails Way blog, Koz has posted an example of refactoring Ruby code to make it more “human” readable. He states this opinion:

It’s far more important for code to be human readable than incredibly concise.

I agree with the statement, but think its important to define “human readable”. In the example, both the before and after are clearly human readable by the human developer who wrote it. In fact, at the time of writing any piece of code the developer clearly is able to read it, or would not be able complete it.

The reason to create more readable code is not for the benefit of reading it easier at the time of development, it is so you can more easily dive back into it six months later, after you’ve forgotten why you did it the way you did it. There are so many solutions to every development situation, and six months from now you might not being using the same patterns for your development as you were then. Or, a different developer, with different preferences for coding style and patterns, may need to read your code and understand it very quickly.

It’s not that the future developer can’t understand it either way, but simply the reduced time to jump right to the matter at hand and focus in on the solution. As I said in the comment on the post, this particular example shows how to break up the various tasks of the activity of validating this Expense object, so that you can jump right to the validation issue that may be causing the problem. You don’t have to weed through a possibly very lengthy validate method, reading every single line until you find the one that might be at issue. Instead, you can read the descriptions of each validation step at the top (the pseudo code method names serve as descriptions) and thin pinpoint the validation step or steps that need a fix or expansion.

Taking the time to do this type of code refactoring at the point of original development, when you understand what is going on because you are fully involved in it, will save you and/or other future developers massive amounts of time and grief when readdressing the code months from now.

Page 21 of 35« First...10...1920212223...30...Last »