RSS
 

Archive for the ‘Ruby’ Category

Rails Nested Forms with jQuery

29 Jul

If you've gone through the "Complex Forms" railscast by Ryan Bates then you may be interested to know that the latest version of the code is on github.  Something that wasn't immediately obvious, but was very helpful for me was that Ryan has many branches that use different technologies.  A branch using jQuery helped me a lot, since I was removing prototype from my project and most of the examples of complex forms use prototype.

 
No Comments

Posted in Ruby

 

Coding Presentation Tips

14 Feb

Last night I presented an implementation of a calendar in ruby with Grant. I reviewed Grant’s code while he reviewed mine.

It was a lot of fun and I really enjoyed the experience. Almost like a roast, but with code. I struggled a bit through the presentation with how things were being implemented and with relaying the problem that we were solving to the audience.

Afterwards Scott informed me that a better way to begin this presentation would have been to start with the client code, the use of the solution. What is your code allowing to happen. How is it being used. This information will at least let people up front know what is up and why you have written your code. Tests can do this for you, but if you could show this in the context of a real world example it will stick in their mind.

I thought about this and think that it is how I will begin technical demonstrations for the foreseeable future. Give people the reason, give them the why and then show the how. Otherwise the audience will lose patience and just start twittering.

 
No Comments

Posted in Ruby

 

ZenTest autotest is now autospec for rspec

14 Nov

I spent a long time tonight trying to figure you why I couldn’t make autotest work with rspec.  I was eventually able to make it work, but when reading the rspec changelog I noticed this tidbit. 

Version 1.1.5 / 2008-09-28
IMPORTANT: use the new ‘autospec‘ command instead of ‘autotest’. We changed
the way autotest discovers rspec so the autotest executable won’t
automatically load rspec anymore. This allows rspec to live side by side other
spec frameworks without always co-opting autotest through autotest’s discovery
mechanism.

This of course means that the rspec gem distributes autospec and that you should use that to find your _spec files. Anyone using this in their terminal “RSPEC=true autotest” should now use “autospec”.
 
2 Comments

Posted in Ruby

 

New Blog New Focus

06 Jun

Over the past year I have grown quite a bit as a developer and realized that I should talk more about being open to expanding your knowledge outside of the technologies you are currently comfortable with.  One year ago I was a ASP.NET C# webform developer that didn't know exactly why people didn't like ASP.NET and considered it a leaky abstraction.  

I really wanted to get better with testing my software and the path that lead to developing testable websites brought me to the View-Presenter pattern.  This pattern worked wonders to be able to test a webform site and really allowed me to focus on the TDD experience.  During this work I felt that I was finally writing some rock-solid code that was doing what I thought I wanted it to, and with the testing would keep doing it through the changes.

After getting comfortable with this I started to look into Ruby on Rails since there was so much talk about it and how completely agile it was.  The first couple of months that I sat down and used ruby I was not sure that it was worth looking at.  Some of my posts here show my skepticism that I felt.  I thought that without a compiler and with the looseness of the language that "real" applications weren't possible and that it was more the realm of the casual developer that didn't have to make a serious professional program.

After struggling for a couple of months I started to see the light.  Once I was writing tests and really understanding what I could do with Ruby, using C# started to become frustrating.  To get software written in Ruby you really can just go and have a great amount of ease in re-factoring your code because everything isn't tied down so tightly that you had to expressly expose all aspects to being extended or overridden.  In Ruby if you want to replace functionality of a class you can, no special keywords or design considerations.  With C# the style of code that you have to write to become testable changes from what you would write even with good OO principles.

I was learning Ruby so that I could create Rails applications.  What I have enjoyed about Rails the most would be the guidance and ease of developing an application.  Testing is required practically and supported to an extent I had never seen.  The design of the system made sense, it is put together by people that used it daily.  It is added to by people using it and the community was very helpful and exciting to be around.  I was very excited, but thought there must be something that makes Rails development not as easy as it seems.  Otherwise why isn't everyone developing using it?  So far I have not run into frustration.  The only aspect that I am hesitant of is running the web servers using rails.  At the start of my experience there seemed to be quite a bit of memory usage and a need to do frequent server resets.

Worried about this I didn't feel comfortable pushing the technology to co-workers since I didn't want to recommend a system that may not be as solid as what we were used too.  Then Microsoft announced that they would be making a version of ASP.NET that is built with an MVC architectural pattern.  Initially this was somewhat exciting.  All of the benefits of rails I thought, but with the stability of .NET.  

So far this has been a good direction for Microsoft, but it feels to me like I know that the people writing it aren't thinking about using it first.  They are driven by the desire to make maintaining the software easy.  This has led to pain in my experience.  Releases aren't very easy to use with testing.  There are side projects that have been created to ease this, but it is obvious to me that these solutions could have come from the actual framework creators.  To me there is still this we will make the framework you figure out if it works for you mentality.  Usually this isn't a problem if that attitude is from people that are working with the technology, but here I don't believe this is the case.  

I have more and more felt that Ruby on Rails is the best way to develop web based software.  I am more intrigued every day and have yet to run into a decision that I thought was made without the first priority being a benefit to the usage of the framework.  Now with this experience I wonder what other languages and skills would help me solve problems better.  This will be my focus on this blog so that I can chronicle my experience and hopefully meet more people that enjoy solving problems the best way they can.
 
 

Tulsa Ruby Workshop

17 Mar

The Tulsa.rb group will be hosting a workshop on April 28th, 2008 from 10:00 AM to 4:00 PM. They are going to be covering some great topics especially for people extremely new to ruby.

 
No Comments

Posted in Ruby