Cross domain font woes – part 2
July 4, 2012 § 1 Comment
A few months back we looked at issues related to showing custom fonts in firefox (see Cross domain font woes in Firefox). Since then we have also started hosting more and more sites on heroku where you have no control over nginx. Obviously this makes the previously proposed solution hard to implement…plus who can remember all of that config?
Monitoring a site after launch (part 1)
February 6, 2012 § Leave a comment
A lot of effort goes into launching a project, but often they can be found neglected after launch. We see this more in client projects with a launch date, than with start-ups or any of our internal proprierty work, but the ideas here should apply to all.
It is niave at best, to assume that once launched the project is done – to this end we always encourage clients to budget for work *after* launch. Sometimes this can be a hard sell, because people assume that once something is launched it is done, however argubly this is the most important work to be done. Before launch you are essentially working on educated guesses and experience (or hopefully user testing), but after launch you can see how real users interact with your work and even ask them for feedback.
« Read the rest of this entry »
Why we use unicorn
January 20, 2012 § Leave a comment
Recently a colleague asked me why we used unicorn, obviously I answered “because its awesome”, however this didn’t seem to suffice. So rather then explaining I thought I’d write this post:
In the almost 6 years that I have worked at Mint we have ran our rails applications using a variety of software. Back in the dark early days we used fast_cgi under apache, luckily we moved on quickly to thin, behind nginx, a web server we have since stuck to. However from thin we moved to mongrel when Zed showed us the awesome and then finally to unicorn. I miss out a brief stage where we entertained the idea of using passenger, but fortunately this never made it onto our production servers. Unicorn has been part of our stack for longer than all of the others put together and this in itself is interesting.
Don’t build that feature.
August 25, 2011 § 1 Comment
Are you building a new feature right now or are you building bloat? Please stop.
Seriously, I can’t be bothered to write yet another feature. At least not one that will spend 4 weeks to build out and then leave unchecked until a redesign/rewrite. Is this feature being used? Has it made an impact to the signups/purchases?
I want to know if people are using that search box i’ve added on products/show, or if the favourites are being used.
I want to know if 80% of my usage is coming from 20% of the code/features and I want to kill that 80% of resource sapping bloat.
The second spoiler resulted in a 200% increase in LOLz, good work.
I need two things :
a) WHO is using my feature/url and their behaviour as well as the total % of users visiting a url.
b) When adding a feature of any kind I need to how and when it will be judged, e.g. if after 4 weeks this search box makes no difference to the number of users going to a search page then kill it.
Too often I develop an application blind and I don’t want to anymore.
Of course what i’ve outlined is a problem, I need to create my solution. I’m building something to make sure that I have the right tracking to create a lean codebase (rubygem coming soon), and most importantly only having features make a real difference. I look forward to sharing it with you soon.
Using Vim with Pathogen
July 18, 2011 § 7 Comments
Vim is my editor of choice. Vim is everywhere and has hundreds of plugins to allow you to do pretty much anything a text editor can possibly do.
The problem is, setting up Vim to use plugins is not the simplest thing to do. Enter Pathogen.
Pathogen is written by Vim plugin guru Tim Pope, it lets you isolate plugin scripts under their own directories. This means easy installs, uninistalls and upgrades.
Here’s a walk through about how to get this up and running: