Speeding up bash aliasing to speed up your Rails development

All good developers love the terminal, and spend many hours at the command prompt.

All excellent developers are masters of the shell.

All uber developers issue shell commands with obtuse aliases.

So, if you're uber, or at least becoming uber, and regularly spend time aliasing commands in your profile, here's a script to speed that up. It will open your Bash .profile in Textmate, and reload it in your Terminal once you're done.

The speedy way to create aliases that speed up your development.

And remember, keep it DRY.

The Facebook imperative cannot be stopped

Marc Benioff of SalesForce.com with his take on the next-big-thing in enterprise software - which will be more social, more mobile, more instant, and (hopefully) more productive.

We had an interesting conversation about this in Siyelo's daily stand-up meeting, and we tend to agree with Marc's outlook. Indeed many software applications could be improved with "social-networking" features/integration points to enable organizations to spread ideas and information.

Rails 2.3/Devise : changing your email content type.

Devise is a great rails authentication solution, with a very active mailing list and team of contributors. Given its modular, pluggable design, simple installation, I predict it will become the "standard" authentication module, (assuming someone steps up to the plate for MongoMapper/DataMapper support for Rails 3, anyone?).

A minor issue on Rails 2.3 is that Devise (v1.0) doesn't allow you to override the content_type of the emails it sends. (I believe its fixed for Rails 3.0). Given the content type defaults to 'text/html', unless you like to cause yourself (and your users) some grief with html emails, and plain text emails will suffice, then read on.

I've patched Devise 1.0 to enable you to override this default behaviour in your config/initializers/devise.rb file

UPDATE: Its been merged into Devise v1.0.2 http://github.com/plataformatec/devise/commit/23568bda82d04062615b79570949ed4ff18b039d

The gem on gemcutter

The github branch is here, and should be merged into the Devise trunk shortly: http://github.com/glennr/devise

Using Devise for authentication? How to upgrade from v0.8.2 to v1.0

We're using PlataformaTec's fantastic Devise for user authentication in our Rails projects, despite being long-standing supporters of Authlogic for a long time. We found Devise to be far easier to set up and you get great stuff right out of the box, the automatic authentication emails, password reset forms, and very simple to configure authentication strategies to name a few.

It also works great with Declarative_Authorization (if you are masochistic enough to use Declarative_Authorization in the first place).

On to the topic of todays insightful blog post: upgrading from 0.8.2 to v1.0. Jose, the big-man-on-campus @ Plataforma tells us we should upgrade cos of a few significant bugs. Ok, lets do this.

becomes


And after restarting the server, a barf.


So obviously my Devise resource, User in this case, is fubar.


Hmm nothing changed there. But wait, 'devise :all' is now conspicuously missing from the README, replaced by a more explicit statement of your authentication strategies in your model.

So it seems though that the old Devise way of defining :all strategies is no longer supported. Fix that, and the order of the universe improves a little.

Paperclip - attachment validations

Using Paperclip, if you need to check if your model has an attachment, you don't use the standard ActiveRecord validation helper i.e.;

  validates_presence_of :logo

Erroneous!

Instead you use Paperclip's helper

  validates_attachment_presence :logo

But be sure to put that after your attachment definition

  has_attached_file :logo
  validates_attachment_presence :logo

And if you're doing something tricky, like allowing your model to be saved without an attachment first, but enforcing that an attachment is present on update then; 

  validates_attachment_presence :logo, :unless => :new_record?

Programmer or Software Developer?

A software developer would not be worth his salt if he couldn’t put some code together, but there are a multitude of skills and attributes that separate him from just being a programmer.  In a world where hundreds are programmers are thrown at problems, software solutions are often not what they should be. Ultimately the quality of the work produced by good software developers is on a whole different plane, and it’s for some very good reasons.

Commitment to mastering a craft
The distinction between a job and a vocation is made clear by developers who push themselves in the following areas:

Keeping up with technology - The realm of possibility in software is constantly changing, and what may be a suitable way to solve a problem now may be replaced by something much better tomorrow.  In such a dynamic environment, a passion for learning and being up to date is invaluable.

Maintaining a good attitude - a good level of output cannot be achieved if developers are defensive about their work, and cannot handle a bit of constructive criticism.  Individual sections of work may be perfect, but may not fit together well with others.  Keeping an open mind and listening to other developers’ opinions facilitates learning, and can help to cut down the amount of time and effort needed for a project.

Good enough is not enough - a good developer comes back to what they’ve done, and looks at it critically, wondering if there are any areas which could be improved.  Critiquing work can be good for future projects, and ensuring that all solutions are always of a high quality.

Knowing where their limits lie - there is a definite benefit to knowing where your strengths lie, and asking for advice or help in areas where you may be lacking some skills.  No developer can know everything, and acknowledging that is a strength, as is knowing where to go to ask for help. 

Gaining experience - there is a lot to be said for having a strong technical background, but it’s often in the application of knowledge that a developer comes into their own.  Having said this, the experience needs to be relevant and varied, as doing the same thing over and over again doesn’t necessarily mean you’ve been doing it the right way, or that you’d be able to tackle other challenges well.

Planning before coding - a good developer should be doing more than just writing good code, he should have a good idea of the various system components, data repositories, data flows etc before he even starts coding.  Having an overview of the solution means that when coding starts it will follow a design, and the project can move more efficiently towards completion. 

Test, do some testing and when that’s finished, test it again - testing should occur from the outset, and time should be put aside for it.  The assumption should never be made that code works, testing should be done to prove that this is the case.  A good software developer acknowledges this and incorporates testing at all phases of programming.

And then when all this achieved?

"Just as importantly - and this is where a lot of developers fall short - a good developer possesses excellent soft skills - communication; time management; awareness; tactical and strategic thinking (detailed planning with an eye on the big picture); an ability to identify risk, weigh-up options and make decisions quickly; objectivity and pragmatism. He also has the courage of his convictions. A good software developer has the ability to 'think' in different dimensions."  (1)

Well said.

The real cost of bad software

The decision to pay someone to develop new software for you is almost always a big one, and jumping into bed with the wrong software developer can be an expensive mistake.   All projects have an element of uncertainty, but software related projects can be especially hard to predict, and the end result can leave the customer with considerably less in the bank.

Below are some of the general characteristics of a software project
Objectives - what is the scope and what are the deliverables
Resources - people/finance etc
Finiteness - there is a fixed time scale
    and lastly
Quality, which can be measured in terms of customer satisfaction and the organisation’s image. (1)

Bad software
So how much is this going to cost you?  Let’s say that bad software is lacking in quality, which means that customer satisfaction is affected as is the organisation’s image.  

Let’s have a look at some of the associated costs 

Initial development cost (IDC)
Consider this as spent, a sunk cost, and if the output is unsatisfactory there are costs that arise as a result  

Continuing maintenance costs (MC)
If rework is not included in your contract you may find yourself paying for bugs to be fixed.  If the scope of the project was not clear and agreed upon you may find that you’re not covered for any additional work.  This can be pricey and above any formally agreed maintenance costs.

Time (T)
A lot of time would have been invested in the initial software development, with meetings to discuss the objectives, identifying deliverables etc.  If there’s bug fixing to be done you can be sure that this will result in more time being spent running backwards and forwards between supplier and customer.  Time should be an investment, but taking time out to fix bugs is just an unnecessary expense.

Effort (E)
It’s hard to allocate the cost of stress, frustration and bad relationships that result from deliverables not being met, but they’re there and they’re material. 


Rework costs (RC)
It’s unlikely that you’d pay the same supplier to do the work over again from scratch, but the possibility is there that you find yourself contracting someone new.  

Opportunity costs (OC)
If your business depends on the software to run, then you are losing out every minute when it doesn’t work.  If you have made promises of your own which depend on functioning software you could be damaging your customer relations, and there is a potential to hurt your brand image.

Unforeseeable costs (UC)
Impossible to anticipate, but glitches in software can be catastrophic.  Errors which end up paying someone $100,000 instead of $10,000 can cripple a company.   

Total cost (TC):

TC = IDC + MC + T + E + RC + OC +UC

If the software that you are handed results in any of the above costs (MC, T, E, RC, OC, UC) then that makes up the cost of bad software.   And these costs are the reason why you need to ensure that your software developer is able to provide you with quality, and that quality is one of their core values.  As with all things in life you get what you pay for, and spending a bit more upfront can potentially save your entire company later on.

1 Integrated Management, Ann Norton, Elsevier, 2008