:neil_middleton

Ruby on Rails, Web Application Development and bollocks extraordinaire 
Tags


Filed under

BoxFile

 
May 17, 2010
 

It's amazing what people want signed off

So, it's now been a month or so since Boxfile launched into beta, and it's been a busy one.  We've been getting a fair few signups, but what is more interesting is what people have been getting signed off.

Aside from the usual suspects of requirements documents, invoices, and designs, we've had a fair few interesting use cases so far.

For instance, we've had some timesheets that someone needed their employer to sign off. We've had a couple of TV ads that someone was posting on YouTube as part of a viral ad campaign.  We've even had the entire floor plans for a local hotel signed off as part of a redevelopment.

It's been really interesting talking to people and finding out how they've been using the tool and what ideas they have for the future.  I've already got a list of things that people have fed back on that will only serve to make the application better in the long run - hopefully I'll be able to post about those soon.  In the meantime, if you've not checked it out, please do so, it might help you out with some other use case I'd never even thought of.


Filed under  //   BoxFile  

Comments [0]

April 26, 2010
 

Using Memcached with Rails

Recently, during the development of BoxFile, I decided that I needed a nice caching layer on the site to alleviate unnecessary load on the server, but to also speed the application up on some of the more intensive pages such as the document view.  After a couple of minutes research, it transpired in Rails that this is actually pretty easy.

Enter Memcached (pronounced memcache-dee).  Essentially Memcached is a heap of key value pairs stored in a nice high performance service that available over the network.  Given that memcached is cluster-able, this means that you can practically have a infinitely big network cache for your application, which is great news.

However, most apps don't need anything like that amount of stuff, a cache of a few megabytes is ideal (and the heroku memcache makes it insanely easy to setup too).

But how do you use it?

Well, it's as easy as you could imagine.

Let's say I have a bit of view that I want to cache that contains a render of a blog post article.  In order to cache it with memcached, I simply need to install the memcached gem, tell Rails I'm using Memcached for my cache store,

and then mark out what needs caching with a block:

What Rails does here is spot the @post object, and generate a key based off that and it's updated date.  This then forms the key that gets used in the cache.  When the post changes, so does the key, which means no cache item is found and the item with re-generate and cache itself in the process.
Let's say for instance that the view thats, say, specific to a user in it:

works just as well, as does

Basically, if you can generate a unique key then that cache item can be found again.  If you need a new version, use a new key (hence the use of updated dates), and Memcached will automatically worry about expiring the old fragment when it needs to.

However, note that there's a catch in Rails 2.x.  If you're caching a view, remember that any code in your controllers will run regardless as the SQL itself will be cached.
There's a few ways around this given that Memcached doesn't only store Strings, but also hashes and so on.  ActionController::Caching::Fragments is your friend here.

In Rails 3.x this isn't an issue as queries are only executed by ActiveRecord when the query result is iterated over (and if it's cached, this won't happen)
So, all in all, it's pretty simple this caching game, to the point where I was able to implement all the caching I need for now in an hour or so, and whats more, I know it'll scale, unlike file system or database based caches.  For proof, read up on the Facebook implementation.

For more information, check out the screencast over on NewRelic.


Filed under  //   BoxFile   Rails  

Comments [0]

April 20, 2010
 

Why sign off sucks...

It's a fact of modern life that projects don't always go the way they should, be it for lack of time, budget or a scope that's too large.  Another major reason for projects going awry is that of misunderstanding.  It happens every day, and every single one of us at some point has generated some work for someone without fulling understanding what was required, and thus having to waste time doing more work to make things good again.

And if that's not happened to you, you're a dirty liar ;)

So, what do we do to get round this?  Well, for starters we collectively hold a belief that a signature will make everything good.  We believe that a note from a client saying "Yes" makes it all good, and we'll never waste time farting about getting things wrong.

Unfortunately that's not what happens.  Most small business get their agreements in a completely haphazard way.  Those that have a process for sign off are by far and away in the minority.

So what?

Well, put yourself in the position of a client.  You've been dribbled some designs and requirements from your agency, but notice that something you need isn't explicitly mentioned.  You recall that the only agreement you've given was as a side comment on phone call so you go for broke.  You phone up your agency, and proclaim that you DID want your site to support IE6, and yes, it is a definite requirement that's been mentioned lots of time.  

Bugger

You the agency don't have anything explicitly stating IE6 would or would not be supported so what do you do?  Do you refuse and ask the client for more money, and potentially risk pissing them off and losing them, or do you take it on the chin and bear the cost of the work, because you can't prove the client never asked for it?

All this costs money.

Well, imagine this.  Imagine that you were able to store documents in a location, and know that when the client has signed off that you have a read-only store of what the client has agreed to.  Imagine that you can turn round to a client and say "Sorry Bob, that's not mentioned in the documents you've signed off, so that's an extra charge...".  Imagine being able to take that snapshot that a particular user agreed to a particular set of information and be able to prove that to anyone that's interested at any time.

This is where BoxFile comes in, and where I've primarily focused the application.  If you find that sign off is a bit of a problem for you, please, have a look, have a play and use it for a bit.  There's already a fair few people using the system and loving it, but I would be directly interested in your own feedback.  As a reward for getting involved, all sign ups in this beta phase will be awarded a 10% discount for life once the application comes out of beta (there will still be a free version if you don't fancy that).  Beta accounts are free and unlimited, so it's a great time to have a try.

What's more, if you like BoxFile and blog about it, send me a link  (neil [at] theskunkworx [dot] com) to the blog post with your BoxFile account details, and you'll be set for a 25% discount for life.


Filed under  //   BoxFile  

Comments [0]

April 15, 2010
 

BoxFile - My Latest Creation

For any of us working in an agency, clients can, quite frankly sometimes be a complete pain in the backside.  Most of the time they're fine, but every now and then something happens that just muddies the whole relationship in some way.  From my experience, this tends to be the good old we said / you said scenario surrounding your requirements or some previous agreement.

And it's not just us.  Having spoke to people about this it seems to afflict nearly every industry out there.  Every company seems to have a time where they find themselves fighting over agreed details, and who should pay for changes, purely because the initial sign off was badly managed.  Overall I believe this costs companies hundreds, if not thousands of pounds every year, whilst people decide who's paying for what changes, and also the money lost when you need to satisfy requirements that weren't previously mentioned.

And it's because of this I decided to scratch my own itch and build a tool to try and solve this problem.  Enter BoxFile stage left.

BoxFile is an attempt at solving this issue.  BoxFile is a tool for managing project document sign off, and ensuring that that sign off is reliable.  What's more, once a document has been signed off (by a signatory that you choose), it stays signed off, and cannot be changed, thus giving you the ammunition you need to protect yourself from the cost of having to implement new requirements and 'emerging features'.

BoxFile is currently in beta and therefore is free for anyone to use.  The only cost is that people use the system and give feedback on how it could be improved or made more useful.  Longer term, the product will become a subscription based tool.

So, check it out, have a play, even use it with your projects, and let me know what you think.


Filed under  //   BoxFile  

Comments [0]