Mendable.com – Essential Reading for Ruby on Rails Developers
February 7th, 2010
In case you haven’t heard, Rails 3 is now in Beta.
Just a quick post to say, if you haven’t already, check out the Rails upgrade plugin, this will quickly show you what bits of your code need to be updated to work with Rails 3.
Also, check out the full release notes, lots of juicy stuff in there.
Categories: Rails
February 6th, 2010
Over the life cycle of a project many features may be developed, sometimes just to account for one variation or tiny use case, get used once, and are then not used again for the next 5 years (if ever).
One of my personal pet peeves is overly complicated software with too many redundant, old, unused features. This sort of redundant complexity increases the learning curve for new developers coming into the software project and creates extra work in maintaining the software,
I often think the best way to create and maintain software, is to periodically remove all the old crap not being used any more. Some people do not like the idea of loosing a feature in their application, as in “OMG, you can’t take that away, I was planning to use that one day”, and maybe they were. But often, you have to look at what they say they are going to do, and compare that with what they actually do.
I am sure this is some sort of psychological effect where the fear of loosing a feature has more of an emotional impact on the end user / client than the prospect of faster software development and the addition of new features, as well as cheaper maintainance.
If the feature works, can’t it just stay?
Hypothetically yes, but sometimes the part the end user sees is that the old features only continue to work because when adding new features we are able to test we have not broken the old features, and in some cases that means a ton of work when a big structural change is occurring.
Also consider the development of a new software project, or a big addition to an existing project. The number of proposed features grows exponentially with the number of people involved. In reality, only 20% of the features will may 80% of the software, but you may end up coding 80% of the features to make up 90% of the functionality, just because people don’t get agile, or the business structure around you does not allow for it to happen so easily (extensive budgeting approvals, waterfall methodology), or of the HiPPO effect (Highest paid person’s opinion).
This post has been a bit of a rant, but the points are these:
* Don’t develop crap you don’t need
* Remove old crap you don’t use any more
Do points 1 & 2 and you will get:
* Faster software development
* Software that is easier to maintain
* Easier to bring in new developers to a project
* Happier developers
* Reduced costs all round
Categories: Productivity
January 15th, 2010
There is a nice little tool over on tmto.org that allows you to decrypt (or should I say, reverse) MD5 or SHA1 hashes. Essentially, someone has forward hash’ed all a-z letters, put them in a database, then matches your hash against what is in the DB to find what the original string was. This is somewhat limited, it only currently does a-z by the looks of things, but a very nice idea. Should also re-enforce the benefits of double-salting your passwords with a per-size and per-user based salt as well.
Categories: Uncategorized
August 6th, 2009
I think autotest is one of the best things about developing in Rails. If you don’t know, autotest runs in the background watching all of your application files. When you edit any of them, it automatically runs the sections of your test suite that apply to the modified file, and can then give you feedback as to if your tests are passing or failing. This means more time developing, less time switching windows to run rake test!
I thought I would post a note about how to correctly install autotest, as some of the other documentation is out of date.
sudo gem uninstall ZenTest sudo gem install ZenTest sudo gem install autotest-rails
Something that is missing in a lot of other online documentation is the fact that you have to install the autotest-rails gem as well, if you don’t do this, you will get an error any time you try to run autotest:
Autotest style autotest/rails doesn't seem to exist. Aborting.
Another note, if you want to get desktop notifications working, this page has details of how to achieve that using Mac OSX, KDE, Gnome, etc.
Categories: Productivity, Rails, Testing
July 25th, 2009
A really useful way to mockup your applications before coding is to use wire framing software to create the screens and layout of your application. By doing this, you can ensure everyone working on the project can help to decide upon what the first version should functionally look like, and everyone will know what the end goal should approximately look like.
With this sort of discussion, you really need a tool that will just let you focus on the functional aspect, and avoid too much discussion about colors, branding, etc, all of which can come later.
A really useful tool I have been using is Balsamiq Mockups, it allows you to quickly create screens for your app and includes all the standard page controls you would expect. Here is an example of what you can produce:
There is a nice video demo on the site as well.
Categories: Uncategorized
http://www.mendable.com /