Win a copy of Securing DevOps this week in the Security forum!

Tammer Saleh

author
Greenhorn
+ Follow
since Mar 02, 2011
Tammer likes ...
Ruby
San Francisco, CA
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Tammer Saleh

Thanks a lot, Galen! Glad you're enjoying it!
7 years ago
Katrina is right in that a lot of the reason for the lack of IDEs with features comparable to those in the Java world is due to the dynamic nature of ruby. It's technically difficult to know what methods exist, for example, when methods are often created at runtime.

On the other hand, this same dynamic nature makes a lot of the refactorings that IDEs traditionally offer less important. Ruby enables very DRY code, meaning there's very little boilerplate sitting around, and most refactorings are just as easy to accomplish with a good text editor.

My personal "workbench" is simply:
  • VIM in one window with custom configurations, and Tim Pope's wonderful Rails Vim plugin. I've also blogged about using pathogen to manage your vim configs.
  • Autotest running in another terminal. Autotest (part of the ZenTest gem) simply watches for changed files and runs the appropriate tests. Makes for a very fast TDD workflow.

  • Sprinkle in a browser or two for click-testing and viewing docs, and that's about it.

    7 years ago
    I'm very much a pragmatist, and Ruby on Rails appeals to that part of my nature.

    Rails does a great job of saying "yes, you could do this a thousand different ways, but this is the way we've seen to work the best. If you just follow our path, you'll be done much faster." Rails focuses on building a product, as opposed to spending time finding novel ways of architecting a system.

    While a framework like Rails on another language is still a boon, the dynamic nature of Ruby compliments it nicely. I can accomplish in 10 highly readable lines of Ruby what it would have taken me 100 lines in most other languages. I'm a firm believer that code is a liability, so being able to get things done with such a small codebase is a huge win.
    7 years ago
    Large refactorings are largely a mistake. The three important guidelines for dealing with any refactoring are:

  • Cover the existing behavior with integration tests. Simple smoke tests are a huge win for ensuring you're not breaking existing functionality.
  • Focus on a small part, one at a time. No matter how tempting it is to fix the whole application in one sweeping chunk, small iterations are always better.
  • Red, Green, Refactor. To avoid amassing a large chunk of technical debt, you should always be cleaning as you go.


  • 7 years ago
    Hi Alexander,

    I was still working as a Unix administrator when I started with Ruby. I knew I wanted to start building things, and it was clear to me that web development was the only good place to do that at that time. I jumped on Ruby on Rails as the only language and framework that seemed focused on helping me get things done as opposed to endless architecting. I started with the pragmatic books - Agile Development with Rails, and Programming Ruby. They were great places to start, but nothing teaches like doing. My time at Thoughtbot is what really helped me grow from a beginning Rubiest to an expert.

    Right now, I'm mostly interested in cloud technologies, which is why I'm working at Engine Yard. Just like before, I'm focused on helping developers get stuff done as quickly as possible. Having a platform to deploy to which takes care of all of the sysadmin stuff I used to have to worry about is a huge win for developers.

    Cheers,
    Tammer
    7 years ago
    That's a fairly well contested question, but I fall on the TDD line: I work best when I write tests before each line of code. Basically, it's more about tempo than knowing that I've got 100% test coverage.

    So, with that philosophy, I end up writing tests for everything, including the fact that a validation was setup.
    7 years ago
    We wrote the book aiming at Rails 3. While some of the solutions have become much simpler since Rails 2, none of the AntiPatterns have disappeared.
    7 years ago
    Hi Helana, and thanks for the kind words

    While the AntiPatterns are mostly Rails specific, there are a few that apply to web applications in general.

    Also, I'm clearly biased, but I firmly believe that Ruby (mostly because of frameworks like Rails) is the the language for modern web applications.
    7 years ago
    The AntiPatterns are all specific to Rails applications. If you're interested in integrating a rails app into a J2EE environment, you should take a look at JRuby (which can run Rails applications).
    7 years ago
    Chad and I have had a lot of exposure to "interesting" rails applications as consultants (Thoughtbot, and independently). These AntiPatterns are definitely issues we've actually seen - no armchair philosophy coding, here
    7 years ago
    It's aimed at all levels (up to and including seasoned pros), but it does assume you're familiar with the framework. Having built a single Rails app is about as much experience as you'd need.
    7 years ago