Our Blog

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?

Loading mentions Retweet
Posted by Glenn Roberts 

Comments [0]

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.

Loading mentions Retweet
Posted by Vivi Walsh 

Comments [0]

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

Loading mentions Retweet
Posted by Vivi Walsh 

Comments [0]

What makes a good website?

Your website is often the first point of contact for so many people and most people who have found their way to your site will navigate away too easily if there’s not something there to hold their attention.  Good graphics are important of course, but what else helps to hold the attention of your reader?

Make your homepage feel like home

This is your opportunity to make a good first impression, making it too flashy or with too much content on it could result in an information overload.

Some guidelines as to what information you should have:

  •  An outline of what is on your site, and where the reader can find it
  • Contact details
  • Why they should explore the rest of your site 

Your homepage needs to be able to load quickly.  If your audience has to wait a minute before they see anything, they’re probably going to go elsewhere.

Get people to come back, and back, and back

Once you’ve managed to get someone to come to your website once, you have to have something attractive to the reader to make them come back again. 

Content

Make sure your content is credible and original.  Try to provide new relevant content on a regular basis, so that there is something new for your reader when they come back to your site.  Your content also determines the strength of your presence on search engines, and with so many people using search engines every day it’s important to make your presence felt. 

Here are some ideas for keeping your content up to date:

  • Providing a news digest (or blog), which keeps people updated on the relevant subject matter.  
  • Offering objective analysis and feedback on current events in your industry
  • Listening to and offering feedback to your customers’ comments, concerns and ideas
  • Inviting informed contacts to write articles for you
  • Avoid using Flash extensively - its not as search-engine friendly as a clean, css-driven, standards-compliant website (like the ones Siyelo design) 

Navigation

Link positioning should be logical, and when you click them they should redirect you to the right place.   Siyelo does extensive testing to make sure that what your website does what it promises, and your software developer should offer this service too.  The layout should be intuitive, and there should be a flow through your site which makes your audience feel instantly comfortable.  Try not to litter your pages with hundreds of links.  

Try to view the website from the customer’s perspective - if you were a customer how would you want to interact with the site?

Design

The visuals of a site are important, but unless they are supported by compelling content, easy navigation and good solid coding, visuals on their own won’t be able to attract people to your site and keep them coming back.  

There are some annoying things that can make people navigate away immediately:

  • Poor, dated or cookie cutter designs. Invest in a professional web designer.
  • Intros designed in Flash
  • Too many pop-up or pop-under boxes
  • Autoplay music. Let your customer choose to play music, if offering it strengthens your message
  • Busy backgrounds.

 Your website is a sales team on constant duty.  Make sure your team is informed, informative and of good quality.

Loading mentions Retweet
Posted by Glenn Roberts 

Comments [0]

Full text search on Heroku with Texticle

We just spent some time investigating some alternative to full text search on Heroku. The initial solutions were either ThinkingSphinx (with a remote sphinx daemon, and another copy of the app running - yuck), or one of the paid options like WebSolr. None tickled our fancy. Free and simple tickle our fancy

Along comes Texticle. Not sure about the name, but it simple, and works a treat.

He's even sporting a mullet in his github avatar. Bonus points for that.

Loading mentions Retweet
Posted by Glenn Roberts 

Comments [0]

Are Agile Projects Doomed to Half-Baked Design?

The answer is no.

An excellent presentation from Alex & Leslie from PivotalLabs and GetSatisfaction respectively tells why;

 

Loading mentions Retweet
Posted by Glenn Roberts 

Comments [0]

Design Chunking with Scrum

I stumbled across a great article which outlines how to deal with User-Experience/graphic design in the context of an agile project.

The problem: coming up with a consistent user interface design across a website while working iteratively and incrementally.
  * Attempt 1: Fully agile - out of the book Scrum
  * Attempt 2: Upfront IA and graphic design
  * Attempt 3: Post skinning
  * Attempt 4 - "Design Chunking". The winner. i..e. Iteration Zero begins with design, design stays 1 iteration ahead.

Design Chunking is essentially how our projects at Siyelo have naturally evolved to-date. WIth 1-week sprint lengths, we are tending to use a 1-week planning & design concept phase ("iteration zero") before starting development (though you can start doing non-UI features during this time too).

Loading mentions Retweet
Posted by Glenn Roberts 

Comments [0]

Using Git? How to know what branch you're on, and if its dirty.

Do you lie awake at night dreaming of a way to save your fingers from typing 'git status' too often? Ever wish you could just have an asterisk (*) on the command prompt to tell you that the working directory is dirty? No more insomnia for you;

Terminal 2014 bash 2014 108ճ4
Uploaded with plasq's Skitch!

Paste this code into your .bash_profile and off you go.

Loading mentions Retweet
Posted by Glenn Roberts 

Comments [0]

Fix for annoying bug in EmailSpec

EmailSpec with Cucumber is a great combo. How else could you get such nice BDD syntax such as;

Scenario Outline: Register new user
Given I am on the signup page
And I fill in "Email" with ""
And I fill in "Password" with ""
And I press "Create My Account"
Then I should
And I should receive an email
When I open the email
Then I should see "Please activate your new account" in the subject
When I click the first link in the email

And if you happen to be using EmailSpec 0.3.5 and you're getting an error like this, I may have a solution for you;

You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.include? (NoMethodError)
/Users/glennroberts/.gem/ruby/1.8/gems/glennr-email_spec-0.3.5/lib/email_spec/deliveries.rb:45:in `mailbox_for'
/Users/glennroberts/.gem/ruby/1.8/gems/glennr-email_spec-0.3.5/lib/email_spec/deliveries.rb:45:in `select'
/Users/glennroberts/.gem/ruby/1.8/gems/glennr-email_spec-0.3.5/lib/email_spec/deliveries.rb:45:in `mailbox_for'
/Users/glennroberts/.gem/ruby/1.8/gems/glennr-email_spec-0.3.5/lib/email_spec/helpers.rb:138:in `mailbox_for'
/Users/glennroberts/.gem/ruby/1.8/gems/glennr-email_spec-0.3.5/lib/email_spec/helpers.rb:48:in `unread_emails_for'
./features/step_definitions/email_steps.rb:52

I fixed the offending bug - grab the code either at Gemcutter

gem install glennr-email-spec

or via GitHub

http://github.com/glennr/email-spec

If you're reading this Mr Mabey, please include in the next email-spec patch :-)

Loading mentions Retweet
Posted by Glenn Roberts 

Comments [1]

Browser market share: Applying the 80:20 rule

80% of the effort in many web development projects we've done was spent making the site work on ~20% of the browsers out there. Thats why its worth explaining to clients about standards-compliance, and focusing on making their sites work in those web browsers.

Axiis came up with this clever visual representation of browser market share based on the W3C usage stats.

Its great to see browsers like IE6/7 losing their grip on the market. Its good news for web developers, and for their clients. Save time. Save money. Go Firefox.

Loading mentions Retweet
Filed under  //   browsers  
Posted by Glenn Roberts 

Comments [0]