PsyPhi Group urn:uuid:

Really can't wait to get to the <a href="http://www.futureofwebapps.com/">Future_of_Web_Apps</a> tomorrow (nice and early of course, though I'll be crossing Londinium on the tube during rush hour - joy).<br /><br />I've just been circling sessions on the schedule and find myself mostly in the developer track on day 1 but with an even split between developer and business tracks on day 2. I'm almost wishing Carson hadn't packed so much goodness in so tightly.<br /><br />I have to say I'm a little torn between developer sessions which are appropriate for work and business sessions which are slightly more useful for the special things I do out of hours but almost justifiable under the 'strategy' heading...<br /><br />Anyway, email screwups aside it's shaping up to be a great show. More to come...

2007-10-02T22:05:13Z urn:uuid:1574bddb75c78a6fd2251d61e2993b5146201319

The gist of this presentation was to perform accurate, scientific benchmarking of front- vs. back-end overheads up-front as a developer. This should be common-sense but I don't know *anyone* amongst my colleagues who does this proactively. It's almost always reactive as a result of performance problems post-release.<br /><br />Steve presented a series of guidelines on streamlining content with the aim of improving performance. Some of these conflict a little in terms of common design practices (e.g. use of javascript/css frameworks). These guidelines are more-or-less what the YSlow Firebug plugin incorporates and in a nutshell look something like this:<br /><br />fewer http requests<br /><br />use a cdn<br /><br />add an expires header<br /><br />gzip components<br /><br />put stylesheets at the top<br /><br />move scripts to the bottom<br /><br />avoid css expressions<br /><br />make js and css external<br /><br />reduce dns lookups<br /><br />minify js<br /><br />avoid redirects<br /><br />remove duplicate scripts<br /><br />configure etags<br /><br />make ajax cacheable<br /><br />split static content across multiple domains<br /><br />reduce the size of cookies<br /><br />host static content on a different domain<br /><br />minify css<br /><br />avoid iframes<br /><br />Ref: YSlow firebug plugin! Book: High Performance Websites Blog: YUIBlog, YDNBlog

2007-10-03T12:13:23Z urn:uuid:9e6a55b6b4563e652a23be9d623ca5055c356940

Scaling platform:<br /><br />88m global uniques 1.5m blogs 215m pageviews/day<br /><br /> - 7 boxes, $1500/mo.<br /><br /> - 2 balancers, 2Gb memory, any disk, pound+wackamole+spread.<br /><br /> - 2 databases, 4Gb+ memory, fast disk (RAID), master+slave mysql, split read/write.<br /><br /> - 3 webs, fast cpu, 2Gb memory, litespeed or well-configured apache.<br /><br /> - Everything in subversion.<br /><br /> - Be stateless (shared nothing)<br /><br /> - Memcached<br /><br />geo-targetting of dns, might as well use a CDN<br /><br />single box 300 req/sec 29.5m/day<br /><br />Scaling community:<br /><br />Ref: sxsw presentation<br /><br />Scaling business:<br /><br />Tie revenue streams to cost scaling, e.g. pageviews rather than bloggers. Ads scale revenues with pageviews, effective CPM, low outlay. VIP class of users with advanced features, customisation etc.<br /><br />Scaling people:<br /><br />Hire people as good as, or better than you. Great people = Rich environment + worthwhile problems. 5 things to look for:<br /><br /> - Personality fit (when the shit hits the fan)<br /><br /> - Ability to learn (curiosity)<br /><br /> - Taste (can't be taught)<br /><br /> - Passion for the space<br /><br /> - Familiarity with current technologies<br /><br /> Don't put out too easily - don't hire if doubts exists<br /><br />It's fun to know that the folks at wordpress manage deployment with ssh scripts running svn up.<br /><br />I disagree with Matt's QA response suggesting that you should never do your own hosting. In principle that's ok for the large faceless mass of current web sites & traffic but under special circumstances it's the only way. I build web apps on top of bioinformatics pipelines supporting (today) 320Tb data and there's no way on Earth this would be possible to outsource.

2007-10-03T15:18:05Z urn:uuid:12c6fc06c99a462375eeb3f43dfd832b08ca9e17

Caught Matt's talk this morning at the weekly informatics group meetings - <div style="width:425px;text-align:left" id="__ss_156920"><object style="margin:0px" height="355" width="425"><param name="movie" value="http://static.slideshare.net/swf/ssplayer2.swf?doc=what-can-bioinformaticians-learn-from-youtube-1194351542661140-4"/><param name="allowFullScreen" value="true"/><param name="allowScriptAccess" value="always"/><embed src="http://static.slideshare.net/swf/ssplayer2.swf?doc=what-can-bioinformaticians-learn-from-youtube-1194351542661140-4" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="355"></embed></object><div style="font-size:11px;font-family:tahoma,arial;height:26px;padding-top:2px;"><a href="http://www.slideshare.net/?src=embed"><img src="http://static.slideshare.net/swf/logo_embd.png" style="border:0px none;margin-bottom:-5px" alt="SlideShare"/></a> | <a href="http://slideshare.net/mza/what-can-bioinformaticians-learn-from-youtube" title="View this slideshow on SlideShare">View</a> | <a href="http://www.slideshare.net/upload">Upload your own</a></div></div><br /><br />There were general murmurings of agreement amongst the audience but nobody asking the probing questions I'd hope for as a measure of interestedness.<br /><br />Matt touched upon microformats in all but name - I was really expecting a sell of <a href="http://bioformats.org/">http://bioformats.org/</a> , websites as APIs and RESTful web services in particular. <br /><br />Whilst I'm inclined to agree that standardised, discoverable, reusable web services are largely the way forward (especially as it keeps me in work) I'm not wholly convinced they remove the problems associated with, for example, database connections, database-engine specific SQL, hostnames, ports, accounts etc. <br /><br />My feeling is that all the problems associated with keeping track of your database credentials are replaced by a different set of problems, albeit more standardised in terms of network protocols in HTTP and REST/CRUD. We now run the risk that what's fixed in terms of network protocols is pushed higher up the stack and manifests as myriad web services, all different. All these new websites and services use different XML structures and different URL schemes. The XML structures are analogous to database table schema and the URL schemes akin to table or object names.<br /><br />At least these entities are now discoverable by the end user/developer simply by using the web application - and there's the big win - transparency and discoverability. There's also the whole microformat affair - once these really start to take off there'll be all sorts of arguments about what goes into them, especially in domains like Bio and Chem, not covered by core formats like hCard. But that's something for another day.<br /><br />More over at <a href="http://www.greenisgood.co.uk/">Green_Is_Good</a>

2007-11-06T22:46:13Z urn:uuid:761f22b2c1593d0bb87e0b606f990ba4974706de

It seems to be the wrong time to be reading such things, but over on <a href="http://www.infoq.com/">InfoQ</a> there's a <a href="http://www.infoq.com/articles/vinoski-erlang-rest">nice_article</a> introducing web development of <a href="http://en.wikipedia.org/wiki/Representational_State_Transfer">RESTful_services</a> using <a href="http://erlang.org/">Erlang</a> and the <a href="http://yaws.hyber.org/">Yaws</a> high performance web server.<br /><br />I say "the wrong time" as this week has kicked off the "Advancing with Rails" course by <a href="http://dablog.rubypal.com/">David_A._Black</a> of <a href="http://rubypal.com/">Ruby_Power_and_Light</a> fame. The course is fairly advanced in terms of required rails knowledge so it's a bit of a baptism by fire for me and a few others having never written any <a href="http://www.ruby-lang.org/en/">Ruby</a> before.<br /><br />Rails is proving moderately easy to pick up but as I've remarked to a couple of people, it doesn't seem any easier coding with Rails than with Perl. Perhaps it's because I've never done it before but I reckon it's a lot harder spending my time figuring out what the heck DHH meant something to do than it is doing it myself.<br /><br />Even though it's nowhere near as mature, I do reckon my <a href="http://search.cpan.org/dist/ClearPress/">ClearPress</a> framework has a lot going for it - it's pretty feature-complete in terms of ORM, views and templating ( <a href="http://www.template-toolkit.org/">TT2</a> ). It has similar convention over configuration features meaning it's not designed for plugging in other alternative layers but it is absolutely possible to do (and I suspect without as much effort as is required in Rails). I still need to iron out some wrinkles in the autogenerated code from the application builder and provide some default authorisation and authentication mechanisms, some of which may come in the next release. But in the meantime it's easy to add these features, which is exactly what we've done for the new sequencing run tracking app, <a href="http://www.sanger.ac.uk/Software/production/npg/">NPG</a> to tie it to the WTSI website single sign on (MySQL and LDAP under the hood).<br /><br />

2008-03-31T23:47:19Z urn:uuid:2e01e17467891f7c933dbaa00e1459d23db3fe4f

Latest release of <a href="http://search.cpan.org/dist/ClearPress/">ClearPress</a> (v146) out to the CPAN yesterday. The ClearPress data model now implements belongs_to_through, belongs_to, has_many and has_many_through entity relationships for all you ActiveRecord lovers.<br /><br />Two ClearPress-derived projects are using a half-decent test fixture system. It's really making a big difference to the development of both <a href="http://decipher.sanger.ac.uk">DECIPHER</a> and <a href="http://www.sanger.ac.uk/Software/production/npg/">NPG</a> so I'm planning to bundle what can be bundled with an upcoming release.

2008-04-29T23:15:41Z urn:uuid:a9334987ece78b6fe8bf130ef00b74847c1d3da6