The cost of small pleasures
7 August 2006 | 18:16 | Administration, Linux | No Comments
After reading this article linked to from slashdot (and popular enough to be backslashed), I realised that I too would be happy spending a number of hours reconfiguring my home network just to screw with anyone who had the poor judgement to try and use my wifi.
This as an alternative to leaving my network managed by my routers and its wifi secured with WPA seems like a good use of my time. Sure I need to reconfigure my whole network into multiple segments, install and configure a DHCP server, and setup rules for iptables – but dude – upside down images!
What is it that causes the (admittedly small) pleasures achieved by messing with people – regardless of whether or not you are able to see the effects directly – have such a high personal value that pretty much any effort seems well worth the time and cost it involves?
Maybe it’s just me.
Why I’m an MVC bitch
31 July 2006 | 13:44 | Design, Development | No Comments
With the popularity of MVC frameworks such as (or because of) RoR (Ruby on Rails) I decided to see what all the fuss was about. Well let me tell you, as is the case of life after the introduction of a Tivo – I cannot foresee going back!
I remember, back in the day, learning and using the various system development lifecycles, processes, and models. I remember even advocating completing a design before writing the first line of code. Ahh – those were he days…
In web development, release cycles seem to have been reduced to hours and being able to respond rapidly to changing needs and user feedback is now a critical element in the success of a project.
So how can we enable this level of agility on applications from the get go? In the past the mantra has been “reusable objects”. Surely leveraging the fact that 80% of all applications share the same functionality (statistic obtained using the well established development estimation practice of pulling a figure out of the air) tells us that abstracting and refining and reusing this common functionality will a) provide us with reliable code, and b) enable us to skip this development effort and thus allow us to produce more stable applications faster.
This is all true and reasonably valid except for a couple of points:
1) With the pace of changing technologies being as fast as it is, old (legacy) components are often no longer relevant and as such their “reuse value” is negligible
2) In projects following formal development lifecycles, the actual coding was generally less than 50% of the effort and as such the development savings have little impact to the overall project
3) The primary reason for project failure is a mismatch between the deliverables and expectations (be that functionality, usability, time, or cost)
Understanding this, a more effective way to improve the success rate of a project is to engage application users early and frequently. In addition to this you need to be able to respond to the changes/refinements requested.
This is where an MVC framework really shines.
Here is where I interject the caveat that my current framework of choice (and hence where my experience lies) is CakePHP and as such the features and experiences may not be available in all frameworks.
In the first 5 minutes you can install the framework and have the default page being delivered. From then on there is no required order of development – I can add functionality or design iteratively.
For functionality, once I create a database table I can produce a model with its relationships and validation rules in minutes and I automatically get the CRUD functionality provided for me. I can then decide on an action I want the application to perform and write a controller function to perform this functionality. If it requires interaction with the database, most of the work can be done by calling built in functions on the model(s) and as such the amount of coding required for each discrete piece of functionality is generally quite small. I will then route a URL to this function and hack up a basic HTML view to present the results. I now have a working piece of functionality on the site and can go on to the next piece. If I need to update the database and alter a table that I have already created a model for, all I need to do is update the database and give the model a quick once over in case I need to add, alter, or remove a relationship or validation rule. My controllers will now have access to the updated database structure.
At the same time if I have a designer (or at some point when I am feeling creative) attention can be put to creating HTML templates, styles and the other visual elements that comprise the views. Although there is a fair amount of coupling between the views and controllers (i.e. the controllers explicitly provide the views with data and as such the views need to know the names of the variables being offered), this binding can easily be put off until the controller is complete (or at least is passing all the variables the view expects) and added in later.
As a further enticement, good frameworks will provide a number of additional “tools” to facilitate rapid development. Scaffolding will automatically create CRUD forms to enable you to interact with your data. Helpers for HTML and form generation and validation provide a mechanism to simplify the standardising of experience so that (for example) the whole application reacts to errors in a common manner.
These are just some thoughts and experiences I have had making the (both technical and emotional) jump from n-tier object oriented development to MVC – and as a result I find myself more and more becoming a full-on MVC bitch!
Plasma vs LCD
19 July 2006 | 19:19 | Entertainment, General | 3 Comments
Whilst trying to discover the “correct” new TV for myself, I found I had to wade though lots of information in order to verify (or debunk) myths and identify the distinguishing points.
My conclusions are based on researching the following:
Plasma:
Panasonic VIERA TH-42PV60A
Hitachi 42PD8900TA
LCD:
Sony BRAVIA KLVV40A10
Samsung LA40R71BD
Myths:
1) Plasma TVs have better viewing angles.
It seems that current plasma and LCD TVs both have viewing angles in the range of 170 – 180 degrees.
2) Plasma TVs have less motion blur during fast moving footage.
While this is still correct, good LCD TVs tend to have at most 8ms response times, so this is only noticeable to the most attentive viewer.
3) LCD TVs have a longer lifespan.
This too is generally true but it is becoming much of a muchness. Good plasma TVs boast a comparable 50 – 60,000 hour lifespan these days; are you really going to be watching the same TV in 20 years time?
4) LCD TVs have higher native resolutions.
This is only sort of true. An HD plasma TV is likely to have a resolution such as 1024 x 768 or 1024 x 1080. Competing LCD TVs would have a resolution more like 1366 x 768. In pixels there is not much between the 1024 x 1080 plasma and the LCD, and even if there was this would only be noticeable if you are connecting a non-video source (such as a computer) to it. They will generally both handle 720p and 1080i content and more likely that not also handle 1080p.
Truths:
1) Plasma is susceptible to screen burn.
This is true, but can be mitigated with good management. Try not to leave static images on your screen for more than an hour, and don’t pause a DVD (for example) for more than 20 minutes. This is particularly important during the first 200 hours while the phosphors are still fresh. Try to watch 4:3 content in full screen so you have no black bars to burn in.
2) LCD is more expensive.
Once you reach the 42″ size, this is still true, however sometimes you can get a good deal on a 40″ LCD which brings it to a price comparable with a 42″ plasma.
3) Plasma has better colour/contrast.
This is generally true and people who like bright screens should see the next point. Common plasma contrast ratios range between 4,000:1 and 10,000:1 where LCD is more likely to give you between 1,000:1 and 5,000:1. Plasmas also tend to have more uniformity (evenness) in brightness and colour from corner to corner.
4) LCD’s provide better daylight viewing.
Both the fact that LCD’s are generally brighter than plasma’s and don’t have plasma’s reflective screens make LCD’s easier to see and less prone to screen glare than plasma.
5) LCD’s consume less power.
This would be truer if phrased as “LCD’s consume MUCH less power”. LCD’s generally consume anywhere between 30-50% less power than plasmas. As an additional consequence, plasmas get hotter than LCD and generally have cooling fans – some that are quite audible.
I’m confused – is there a winner?
In order to find the one that’s right for you, you need to do 2 things:
1) Compare the technologies
2) Identify the model with the features you need
Comparison Points:
Picture:
Are you likely to watch much in daylight? Do you generally watch with lights on that would reflect on the screen? If so you have to lean towards LCD – but remember you are sacrificing the colour and contrast when you are watching in optimal conditions. Would you rather the experience is great while watching in daylight/lights on and average in low light or average in daylight/lights on and great in low light?
Price/Cost:
Plasma is generally cheaper than LCD at the 40″ (LCD) – 42″ (plasma) size. This gap is even greater if you want to go to bigger (such as 50″). If price is a consideration (and let’s be honest – when isn’t it?), this should be acknowledged as a factor. Don’t forget that the price isn’t the whole cost though – with an LCD using 50% less power you may find this cost saving a factor.
Resolution:
Are you going to be using the TV to do more than watch video content such as act as a computer monitor? If so, this should only be a factor if you find an LCD TV with a much greater resolution.
Features:
Inputs/Outputs:
Does the TV have all the connections you need? Does it have HDMI? If so how many?
Tuner:
Do you need a tuner (i.e. are not going to feed it from a cable box/digital stb/media center)? If so what type (analogue/standard digital/HD digital)? Do you “NEED” 2 tuners?
Conclusion
These are just the facts. Personal perceptions and tastes should always weigh more heavily than technical differences.
For most people I believe it should be a simple 3 step process:
1) Identify the features you NEED from the Features list above
2) Determine how much you can afford / are happy to spend
3) Go to as many stores are you can and look at the TVs within your budget that have the features you need
I’m sure you will not be disappointed – and if you are it’s because your budget was set to low 
Back it up!
17 July 2006 | 22:38 | Administration, Linux | No Comments
Why are people (including myself) so lazy about backing up their data?
Do we assume the “managed” in the $4.95/month managed server takes care of this for us? Do we think the risk of failure is so small that it will only happen to other people? Do we think it will require a large and ongoing effort? Do we just not know where to start?
With the cost of hard disks being so low these days, these seems to be no reason not to have a copy of at least your most important databases and files on a separate disk to ease the pain when that dark day that you will forever call “the hard disk crash of {insert year here}” comes.
A combination of this thought and the inherent laziness that most programmers have prompted me to look into what this actually would entail. I believe that the end result was simplified by the fact that I run mostly Linux, but I’m sure with cygwin or something similar, the same can be pretty much achieved on windows.
The end result is a set of scripts for backing up MySQL and transferring data (both the MySQL backups, and other data such as my websites) to a remote server. If I create a new database that needs to be backed up, I just have to grant access to it for the backup user and restore user and it will automatically be included in the backup routine. If I want to backup a new folder, I need to add it to my backup script and it will be synced according to the next schedule. Alternatively, I could create a symlink for all top level folders needing backup inside a common “backup” folder and only need to backup that folder, but this reduces the flexibility of being able to backup my websites to machine1 and audio (for example) to machine2. Once a month each backup will be restored to a scrap table for verification. Finally, due to the magical default behaviour of cron, anytime an error is encountered, I will be notified via email.
Information including all scripts for the MySQL backup can be found on the wiki: http://wiki.accordingtokris.com/index.php?title=MySQL_Backup
Information including scripts for content backup can also be found on the wiki: http://wiki.accordingtokris.com/index.php?title=System_Rsync_Backup
Enjoy – and no more excuses if when you have a disk failure!