Reading, Writing and Random Access Memory
There are certain important life skills that parents are obligated to instill upon their children. It's our responsibility to make sure that our kids have a have well developed I/O skills, a strong moral backbone, a social conscience and, most importantly, that they know how to program.
My 5 year old girl recently started inquiring about what I do for a living. More specifically, she wanted me to show her what I did all day and explain how I did it. Now, this would have been really easy if I was a bricklayer, as we have plenty of Bob the Builder DVDs lying around the house that I could have shown her. However, I'm not. I develop line of business applications for a living. So what exactly can you teach a 5 year old about programming, and how would you go about it?
Obviously I needed to start running through Charles Petzold's seminal book, Programming Windows, with her. The Windows Message Pump is an essential concept that all 5 year olds have to know. Or maybe not.
I decided to simply explain a few fundamental concepts that would enable her to "think like a programmer". I didn't want to push anything onto her, and I certainly want to give the impression that it was the only way to think, but at least she would be aware that the option exists.
We started out with boolean logic, introducing her to the idea of AND, OR and XOR. I used an example involving two entities that she would be familiar with, a cat and a dog, and ran through the various combinations (cat AND dog, cat OR dog, cat XOR dog etc). I was a little hesitant about doing this, considering that teaching the concept of the English Language definition of "or" to children is extremely difficult once you get into the specifics of the matter. She's not quite big enough to have a debate about disjunction, but we're working on that one. She was able to grok it straight away, and immediately started talking about how great it would be to have a cat.
Fortunately I was able to distract her by moving on to control flow, more specifically using the boolean logic skills she had just learned to discuss conditionals in an IF/THEN/ELSE form. I ended up scribbling a lot of pre-primary level pseudo-code down on a piece of paper for her to understand this. Drawing flow charts helped, too.
# I termed this as "If we had a cat and dog, we are happy,
# otherwise we're sad".
# Not exactly the most complex business rule in the world,
#but it gets the point across to a 5 year old.
IF (CAT AND DOG) { HAPPY }
ELSE { SAD }
I drew a quick flowchart of that code, showing the decision and then the two different results, and she immediately got it. The simple, one word results using terms that she was familiar with really seemed to click in her head. There's certainly something to be said for the universal appeal of a flow chart, too. Next time someone tells you that they don't understand your chart, tell them that a 5 year old can pick up the concept in a few minutes.
From there I was able to expand on control flow to include the concept of iteration and looping. By this point she was really into the whole cat analogy, and I was drawing pictures of cats under her strict direction. Pretty soon we had quite a few cats drawn on the page, so I said to her "what if you wanted to pet each one of those cats?". I got an enthusiastic response; apparently petting cats is a pretty popular activity amongst 5 year olds.
I initially made the mistake of trying to explain the concept of collections at the same time. We spoke about the cats living in a house, and how she might like to pet all the cats in the house. We ended up with the following scribble:
FOR EACH (CAT IN THE HOUSE)
{
PET CAT
}
This was great, but it lead to an off topic conversation about why there were no dogs in the house, and how if you had small babies then you might only want to have one cat or maybe even no cats at all, and if you had cats you might want some dolphins too because dolphins could live in a pool outside and dolphins are really cool. She was concentrating too much on the house and the endless possibilities of what could be put inside the house and less on the idea of the house being a container for cats. So I dropped the house concept, drew some more cats on the page, put a circle around the cats and pointed at them while running through the following example.
FOR EACH (CAT)
{
PET CAT
}
Removing a direct mention to the house cleared up the concept enough for her to focus on what I was saying. She could see the cats on the page, she knew that she wanted to pet each one, and she got the idea that she was going to pick up a cat, pet it, put it down, rinse and repeat until all the cats had been petted.
Then it was time to bring it all together. My daughter suggested that perhaps some cats might not be big enough to be petted. They might be babies that you need to be gentle with. Huzzah, we had our first business rule! Time to throw that in the mix.
FOR EACH (CAT)
{
IF (CAT IS A BABY) { BE GENTLE }
ELSE {PET CAT}
}
So now we had an example combining boolean logic, decision making and iteration/looping. It was almost like a mini JAD session, only with a 5 year old inventing random business requirements relating to cats. None of it went over her head, and I found that as long as I kept talking about something she was interested in then she'd quite freely discuss the topic and want to talk about more things that we could do to the cats. The interest was there, so she wanted to naturally evolve the conversation and learn more.
The two main ideas that I hope to tackle next are variables and the concept of ownership. Ownership will be a big one, as it will (hopefully) be a starting point for some basic OO concepts. This should lead on to separation of concern and a few other ideas. Now I just have to pick a language to demonstrate some of this stuff in. Oh look, KTurtle is installed on my machine!
Your Application is CRUD!
How many times have you heard that a tool will save you heaps of time because it automatically generates some sort of CRUD layer for you? Depending on how good you've been for Santa you could get a generated data layer, service layer or even an entire application. Great! More time for coffee!
Well, yes and no.
Most of the CRUD frameworks organise themselves around the concept of creating, reading, updating and deleting a record in a database table. Administrative functions that exist to keep the actual line of business operations ticking over tend to fit this scenario perfectly. So now we have a bunch of frameworks and tools that can help us generate our generic record administration (users, customers etc) and reference data maintenance modules. What about the rest of the application?
Deciding to develop a CRUD Orientated Application (I can't believe I just coined the acronym "CRUDOA") lets you off the hook with regards to many important design decisions. You don't have to care about user experience or business process improvement, because your approach has already been decided. One thin facade around the database coming right up!
Most business users are concerned with performing business functionality. This usually takes the form of some sort of operation or work flow step that forms part of a larger process. They don't care whether the operation creates a record in 1 table or 40. This is usually where the aforementioned business process improvement and user experience analysis is required to make sure that your users don't end up throwing their monitors through the window in frustration.
Obviously if you have any desire to avoid having rotten fruit pelted at you by disgruntled users then you're going to want to put some thought into how they use the system. A generated framework that only has one paradigm (that of editing a row in a database table) greatly restricts your ability to do this. This effectively puts a generated CRUD layer out of the running for any part of the system that is not solely concerned with record maintenance. Then again if you're a developer working on Toad or SQL Server Management Studio then your entire system may consist of record maintenance, and you can probably stop reading this post as large portions of your system will be orientated around exactly that.
So if the real meaty bits of line of business applications are not suited to CRUDOA then why are we constantly looking for ways of aligning our architecture along that path? Why would be use a CRUD data access layer if we rarely perform CRUD operations? Why would we generate a CRUD service layer and UI to feed into that CRUD data layer if it's not a suitable paradigm?
We do this because the tools generate the code for us, and generated code is awfully tempting to use. After all, it's sitting right there and all you had to do is press a button to get a large section of functionality for free. Only it's not actually free, because our requirements often force us to stray from the golden path offered by the CRUD tools, meaning we then have to spend a large portion of our time trying to shoe horn a domain operation or cross entity transaction script into a CRUD approach.
The good news is that a lot of the tools only generate CRUD as a default. There's no reason you can't create an operation-orientated Rails site. You also don't have to accept the default SQL that is generated by your favourite data access layer. The defaults may be attractive at first, but unless we're happy to stay on the golden path (and end up with a mediocre application that has no user buy-in) we are going to waste time trying to stick a square peg into a round hole by modifying the CRUD framework to be, well, not CRUD.
Enterprising Solutions
I recently conducted an architectural review that involved talking to some guys who spend a lot of time in the Java space. I'm usually only in able to mix with people from the Microsoft side of the tracks, so this was a great opportunity for me to see how "the other half live". Plus they were genuinely smart, interesting people who were alot of fun to work with, which is always a good thing.
We were discussing various third party frameworks, and the topic of object-relational mapping came up. ORM is a relatively new phenomenon in the .Net world, with things only picking up around 2004/2005 when NHibernate came of age. The Java guys, however, have had production quality ORM systems for a lot longer than folks in Microsoft-Land. Product's like Oracle's Toplink have been around forever.
I often get the feeling that using an ORM is perceived as being more effort than the really, really horrible Microsoft example code and the recommended practice. Your average .Net developer working on Line of Business applications most probably thinks of the practice as a high brow solution that should only be used when you have time (and money) to spare (all while adjusting your monocle and having several hearty guffaws over the latest developments in the Lisp community). Of course, not everyone is of this opinion, but the chances of hearing "that's too much work" or "that sounds hard" at a developer round-table on an average .Net project are still pretty high.
The interesting thing about this is that the Java guys I was talking with had a polar opposite view. To them, most ORMs were the quick and dirty way of getting a data access layer up and going. They even mentioned that any serious work would probably have them looking at writing custom code.
The "build over buy" mentality is not really something that I'd like to see the .Net community aim for, but the juxtaposition of opinions does highlight the relative immaturity of the platform. The Java guys have been using some of these techniques for so long that they're sick of them, while an unfortunate number of .Net developers haven't even heard of them. If this is the impression I'm getting from guys using Java, which itself is a fairly young platform, then I'd be really interested to hear what a Smalltalk developer would have to say on the subject.
You could almost silence an entire room of average .Net developers by asking about taboo subjects such as "unit testing", "layering" and "domain driven design". The lack of (comparative) platform maturity and the relatively low barrier of entry could have a lot to do with that.
It's a shame that some other platforms that don't necessarily play in the enterprise space have had several of these generally accepted best practices available out of the box (complete with strong community support) for quite some time, while the Microsoft space is only just catching up. Not that you haven't previously been able to implement best practice in .Net, but it just generally hasn't been encouraged. "If it's not coming from Microsoft then I don't want to know about it" is an all too common attitude in the community.
Things are getting better, but we've still got a long way to go before strong software engineering and development principles filter their way down into small to medium sized projects, which is where the majority of .Net developers spend most of their time.
Who’s Afraid of the Big Bad SQL Statement?
I had a rather interesting conversation with Chris Birmele of Microsoft at the recent Heroes Happen launch event here in Perth. We were talking about which version of Visual Studio 2008 Team Suite would be the most appropriate for development teams in Perth. I was lamenting that Database Edition had some killer features for us, such as source control for the DB, but it would still be nice to have the class diagramming feature from Development Edition.
Chris was explaining that the Database Edition of VSTS was meant to be used by the DBAs on our projects, so the rest of the guys in the team could just use Development Edition.
The thing is, I've never seen or heard of anyone in Perth running a .Net development project with a dedicated, T/SQL cutting DBA. Any SQL work is almost always done by the same guys doing the C#/VB.Net code.
Perhaps it's a Perth thing. Over here, DBA seems to mean "makes sure the nightly backup runs" rather than "writes stored procedures all day and fixes indexes". They tend to work for infrastructure companies and aren't involved in designing databases, doing performance tuning or anything like that. We don't really have guys that just specialise in T/SQL for applications. Maybe it's the size of our projects, or just a general lack of demand for someone who cuts SQL code all day. I have no idea.
The number of people who know about things such as proper normalisation, indexing and techniques for maintaining referental integrity is dropping. If you look at the Tiobe Index you'll notice that PL/SQL is only number 13 in the list (remember that this will include Oracle Forms etc), while T/SQL is only number 29. Those figures don't seem all that impressive when compared to Java (number 1) and C# (number 8), the two languages of choice for enterprise application development. Perhaps the popularity of ORM tools such as NHibernate has something to do with it? Regardless, it's getting harder and harder to hire people with good SQL skills, let alone people with good SQL skills AND good .Net skills such as those needed by a large number of teams here in Perth.
This means that any move away from SQL by the general developer population hits us where it hurts. We still need our C# programmers to fix database performance problems. We still need them to do data migration. We still need them to do database design. We still need them to write reports. We still need them to do most of the database related activities that are required when developing any enterprise application.
So by all means keep using Ibatis, NHibernate or whatever ORM you prefer, but please don't be afraid of, or forget about, SQL. It doesn't bite, and if you're in a town like Perth then chances are you're going to need to know quite a bit about it sooner or later. Maybe not today, maybe not tomorrow, but someday, as soon as there's a performance problem or data integrity issue on your project, you're going to have to knuckle down and bust some SQL related moves.
Standing on the Shoulders of Giants
Last year I was working on a fairly large windows forms project that was heavily reliant on displaying large sets of information in grids. Most of the functionality in the system was exposed through buttons that had to sit somewhere near a grid. There were multiple main forms, each built around a central grid that displayed contextual information to the user. Basically, the users were going to be spending a lot of time staring at grids, so we had to get them right.
Now, grid related operations tend to fall into two categories:
- Grid Level Operations, which are sort of like a class level, or static, actions that may act on a collection of items, add an item to the grid, or do something else that's not directly related to a particular item. Sometimes these can be married up with a means of multiple selection, perhaps through a secondary screen or allowing multiple selection on the original grid (although I tend to avoid the latter, as it has a whole bunch of other implications like not being able to change your selection if you prompt the user for additional inputs etc). e.g. You may be looking at a list of current orders and want to add another order. This would be a grid level operation.
- Item Level Operations , which act on a single currently selected item. e.g. If you have picked a particular order record from a grid you may want to edit that record. This would be an item level operation.
Other applications that the users were being exposed to simply shoved all the commands together in a seemingly random order and placed them above or below the grid. This created a huge usability problem, as users were unable to tell whether a button performed a grid or item level action. Will the delete button delete the current item, or will it prompt for a list of items that you may want to delete?
I hit upon a solution fairly quickly: split the commands up, placing grid level actions on the left hand side of the grid and item level actions on the right. It worked extremely well, and we got a lot of feedback from the users about how easy our application was. I was really proud of myself for about 5 minutes, then I realised that I had seen it before.
In fact, I had been staring at an application that implements that very design paradigm nearly every day for several years. What application was I subconsciously channeling? Why none other than Valve Software's Steam. So much for my great original idea.
At the very least it was a validation of my design choice. After all, if it's good enough for the company responsible for Portal then it's good enough for me.
It also proved that inspiration can come from the most unlikely sources. I try not to think of it as being doomed to never have an original idea; that's just way too depressing to comtemplate. It's more that our thoughts will always be informed by the past and our surroundings. Besides which, if it's been done before then there's a good chance that users will be familiar with the concept, and familarity in UI breeds comfort, not contempt.
Won’t Someone Please Think of the Graduates?
Has anyone else noticed that the example source code given on MSDN and in most books is really, really bad?
Even Fowler's seminal Patterns of Enterprise Architecture shows direct use of ADO.Net Command objects and string based SQL in the code behind file of an ASP.Net page. Check out the Page Controller Pattern on page 333 of Patterns of Enterprise Architecture for an example of what I'm talking about.
How can the industry expect to produce quality work when the information being used as guidance contains absolute worst practice? Should we have disclaimers on all sample sites stating that the code contained within is not best practice, or even something remotely approaching it? Perhaps even graphic slogans and images like those found on cigarette packets. "Writing software like this could cause mass headaches and a loss of budget related continence."
We could even go one step further. Microsoft have a Northwind database, why not a Northwind data access object and Northwind business services layer? Then the examples could stick to what they actually want to talk about (e.g. data binding) instead of having to show horrible code.
Is there really a need to explain how a table adapter works just to illustrate binding collections to a DataGrid? Wouldn't it be better to see something like:
List<Customer> customerList = NorthwindBusinessService.GetCustomerList();
in a data binding example instead of another direct call to the database using a SqlCommand object? They could have a series of MSDN articles explaining how the DLLs were built, and maybe even install them in an examples directory when the Northwind DB gets installed.
It doesn't even have to be deeply layered or highly testable. I'm not asking for something that has appropriate hook points for Unity or that I can use with NMock. Just something nice and simple that everyone recognises as being an example business layer or data layer call.
This issue is especially important given how reliant people are becoming on "the Googles" to provide exact solutions to their problems. How many of you know someone who has cut and paste from CodeProject or MSDN directly into a bound-for-production project? How many have done it yourself?
Don't laugh, it's more common place than you think. Just wait till you see a web application that consists of one form and 15 thousand lines of code in the code behind file. After staring into that particular pit of darkness you begin to realise just how dangerous these examples really are.
Walking the Line
Consultancy is a hard gig. Most companies walk a very fine line between body shopping and offering professional services.
An organisation favouring body shopping usually hires consultants for a particular contract; with no long term view on how that employee could be best utilised to grow the company. The organisation often charges clients per hour, and usually has little to no control over the running of the projects that their staff members are working on.
The employee is often placed out a client site with little or no exposure to the goings on in the larger organisation. Eventually boredom sets in or the contract runs out, and the employees move on to the next body shopping firm in a hope that the grass will be greener on the other side.
Organisations offering professional services tend to be more interested in providing highly skilled resources to perform a particular task. The entire project or service is usually managed by the consulting firm, and employees are often seen as important resources that can benefit the company in the future.
In reality most consulting firms tend to flip-flop between the two. Some companies favour one style over the other, but most of the time you can find elements of both in an organisation.
If you think being a consultant is a lonely an unfulfilling job then congratulations, you probably work in a body shop. The lack of employee focus encouraged by this approach leaves many guys in the business asking why they bother getting out of bed in the morning. The good news is that it's not body shopping per se that is causing this dissatisfaction; it's the approach to staff development and corporate culture that normally goes along with body shopping.
Succession planning is often spoken about in terms of how to better position a company to replace key resources in the event of unexpected staff turnover. What many people don't realise is that the core principles of succession planning (mentoring, training and job rotation) can often help fight the feeling of stagnation that goes along with working in a consulting firm, in turn helping to increase retention rates.
Any developer worth his salt is looking to improve his skills, and training and mentoring are two great ways of helping a developer do just that.
A formal training program with links to industry based certification always helps, but it's also expensive to implement. Maintaining a library of recommended reading and encouraging staff to read them can often be enough to show that the developer's personal growth and career development is important to the company. Staff training has the nice side effect of giving the consulting firm access to an increased skill set that can be on sold to clients.
Another way to create a positive learning environment for is to get developers talking amongst themselves. This could be through one on one mentoring, a group based discussion forum or some other means. It is often good to encourage this amongst groups who would not normally mix, e.g. two different project teams working with different clients. This is even more important for the employees out on client sites, as it lets them know that they are part of a larger company and gives them something to belong to. It gives the impression that they are part of a larger practice that has goals outside of their current engagement.
It's my belief that job rotation is the most important practice that a consulting firm can take from the book of succession planning. Sure, it mitigates risk by ensuring that more than one person knows how to do a particular job, but it also helps to fight boredom, and, above all else, it increases the exposure a developer gets to other areas of the company. This exposure is vital to negating the "cubical drone" effect usually brought on by long term client engagements.
Keeping everyone fully billable reduces organisational agility, and even encourages body shopping. If there is no one available to take on new work then the temptation exists to hire in resources just to cover specific projects. Maintaining a strong, healthy bench reducing expected chargeability rates can help enable all the benefits of succession planning. Staff working back at base camp could be busy training, mentoring or helping with pre-sales work, all while being available to take on new work should it arise. This can help to maintain a happy workforce who actually want to come into work every day, which can only be good for the company.
How I Learned to Stop Worrying and Love my Phone
There was a time when I didn't care for mobile phones. I was one of the last amongst my group of friends to get one, and I didn't do so until it was absolutely necessary. My first phone was a hand-me-down from my sister who is 4 years my junior, which shows just how long I left it.
The phone was a Bosch. I had no idea they even made phones. It could send text messages (BUT ONLY IN CAPS, funnily enough. Someone forgot to include the full ASCII character set on their phone..), and had about 10 minutes of talk time on a full charge. Needless to say, it didn't exactly convince me that a phone was an essential piece of equipment.
My friends and co-workers were starting to get sick of being told by a monotone voice that my phone was unavailable or switched off. Then one day in late 2002 I heard that an electronics store was selling off the Nokia 5510, a phone with a full qwerty keyboard that could play MP3s, all for only AUD200. It even had 64MB of storage. Remember, this was pre-iPod when you could spend AUD200 on a 32Meg Mp3 player that ran on AA batteries that lasted around 3 minutes before needing to be replaced. I could fit a whole album on there if I was conservative with the bit rate. Finally I had found a device that appealed to my gadget loving side without being too new and scary. There would be no reason to learn how to do that silly predictive text stuff, so I'd be typing up a storm in no time.
Finally I was starting to like the idea of having a mobile phone. There was only one problem: I was still on a terrible pre-paid plan, so I could only type so many SMS messages on my wonderful keyboard before I simply ran out of credit. I spent too much time thinking about how much each message or call was costing me, so I could never actually enjoy using the phone. I found myself cutting people off and sending abrupt messages in an attempt to get a conversation to end quicker. I started to view the phone as a money pit that sucked up disposable income whenever I tried to talk to my friends.
After a period of time I cracked the screen (it was in my pocket and I bumped into something made of steel) and had to go get another phone. At this point I was sick of having to think about how much it was costing me to ring friends and family, so I ditched the pre-paid account and switched to a post-paid plan with Virgin. Seeing as most of my calls were to my partner, I bought two new phones, a Nokia 6230 for myself and a Nokia 7250i for her, and signed up for a plan that gave really cheap calls and messages to phones on the same network so we could ring each other on the cheap.
So I had partially solved the problem of worrying about making a call or sending a message. I was still reluctant to ring anyone not on the Virgin network, as I could eat up my minimum spend amount very quickly, but at least I felt free enough to frequently ring home or send messages to my friends who were also on Virgin.
My new 6230 still played music, had a removable MMC card that could be used to store files, was much faster than the 5510, had a camera (only VGA, but still, this was 2004) and as an added bonus it even supported GPRS. There were just two problems: Virgin didn't (at the time) have an internet capable access point for GPRS (you were limited to accessing their Virgin Mobile site) and my brand new phone was missing a feature that I had dearly loved in my previous phone, the qwerty keyboard. I was horrified, as I'd now have to learn how to send text messages using a numeric keypad.
Ok, I lied. There were three problems. Tack "had to take the battery out to change the MMC card" on to the list. Worst. Design. Decision. Ever. But I digress.
I started off slowly. I didn't use predictive text, because I had somehow convinced myself that it was cheating and I truly deserved RSI. No, the proper way to type a message is to cycle through letters until you get the one you require. That makes much more sense than letting the phone figure out what word you're probably meaning to type. *cough* To be fair to myself I did initially give predictive text a go, but I found myself having to enter every second word into the dictionary anyway. This constant interruption was enough to make me give up on predictive text for about a month. Eventually the pain in my thumbs lead me to tough it out with predictive text until the dictionary had learned enough to make the phone relatively pleasant to use.
One of my co-workers at the time purchased a Nokia 6600, one of the first semi-decent Series-60 phones (Series 60 being the mobile OS developed on top of Symbian OS). The phone had a lot of great features, and it even played N-Gage games (although the battery lasted all of 30 minutes when doing this), but it was as slow as a dog. My Series-40 6230, while not having all the features of the Symbian based OS, seemed like the fastest phone in the world next to the slothful 6600.
The 6600 was the first Series-60 phone I had seen or used, and it didn't make a good first impression for the platform.
While my partner and I were awaiting the birth of our second child, the microphone on my trusty 6230 decided to stop working. I could hear the caller, but couldn't talk back. Considering I was expecting a "take me to the hospital NOW!" phone call at any moment I decided it would be a good idea to replace the phone.
I was in a hurry to get something, anything, and was only half way through the contract for my 6230. I wasn't about to put in weeks of research to find a really decent phone, nor did I want to sign up for another contract and end up paying two off at a time. So I did the only thing that made sense at the time; I bought the cheapest Pre-Paid Nokia I could find on the same network (so no network locking issues) and figured that I'd sort it all out later. The model I ended up with (I was going to say "chose", but that's not exactly the right word) was the Nokia 6030.
I had been spoiled with the 6230. At the time of purchase it was basically Nokia's top of the line business phone, and here I was downgrading to something that didn't even have a camera. I made a decision to stick it out until my contract for the 6230 ran out, but when that happened I couldn't find a phone that was worth buying. The N70 and N73 were out, but I still had the bad memories of Series-60 from the 6600, and I had heard terrible things about the performance of the N70.
Then something wonderful happened. Three were giving away the Nokia 6288 on their $29 dollar cap. The 6288 is a fairly decent Series 40 phone with a Mini SD slot on the side of the phone, a 2 Megapixel camera and 3G support. I picked up two of them and transfered both of our numbers from Virgin over to Three. I also signed myself up for the 10 MB capped internet package that Three were offering and downloaded the GMail client.
Now I had mobile email. If you've never had mobile email then you may not understand, but it truly does change the way you work. You become connected and available wherever you may be, and email becomes a first class communication medium just like regular phone calls and SMS.
The capped plan was also a huge change for the way I mentally approached making a phone call. I had free minutes to ring other Three mobiles, which took care of communicating with my partner, but I also had AUD120 worth of cap to use as I saw fit. Now I could ring people on other networks without feeling like I was pouring a cup full of 2 dollar coins down a drain.
Apparently Three were not done being awesome, so they decided to release their X-Series range. For those who haven't heard of it, X-Series is effectively a product that you can subscribe to that gives you between a 100MB and 2GB internet quota to play with every month, with prices ranging from AUD12 to AUD40. You get a bunch of other Three services, but their usefulness pales in comparison to the fact that you can now have a broadband internet connection in your pocket that doesn't cost the earth.
X-Series was important because it changed the face of mobile data access in Australia. It effectively started a price war in the mobile broadband market. As a result, companies such as Virgin now offer obscenely cheap mobile broadband packages, both standalone and bundled with a phone.
Technically Three would only offer X-Series on certain phones that have been "certified for X-Series". Unfortunately my 6288 wasn't one of these phones. It is possible to sign up for X-Series with a non-certified phone, but it is highly dependent on the sales person you talk to. The 4 different customer service representatives from Three that I spoke to wouldn't let me do it, so I decided to see about getting another phone.
While all this was happening, the Nokia N95 was in the process of being certified by Three. Some of the other phone companies had already released it, but there were apparently several major issues with the first versions of the firmware. The N95 seemed like a dream phone. HSDPA, VoiP, 802.11G and a number of other features put the phone firmly on my radar. There was only one slight problem; the N95 is a Series-60 phone.
After spending days on the web I could only find one type of non-firmware related complaint about the N95, and that was the backlash against the battery life. I was willing to resign myself to a life of charging my phone every night, so this wasn't such a big deal. Then I discovered that the N95 has video out. That was pretty much made up my mind. I got one as soon as they were released on Three, and immediately signed up for X-Series Silver (500MB of traffic a month for AUD20).
I've been using the N95 since mid-2007, and I have to say that it, combined with having a proper broadband connection in my pocket, have changed the way I work, think and generally access information. Just think about how having mobile access to Google would change the way you operate. You can read movie reviews while trying to select a DVD to rent, or check out the type of RAM your motherboard can take while waiting in line at a PC store.
I won't go into detail about the feature set of the N95, but here's a quick overview of things that I use every day. I'll include both inbuilt features and things that I've installed:
- VoiP client that I can integrate with iiphone
- A 5 megapixel camera that also doubles as a near DVD-quality video camera
- The Gmail Mobile Client
- A GPS that integrated with Google Maps for Mobiles
- HSDPA network access
- The built in web browser
- Opera Mini
- GooSync (Syncs your Google Calendar with your mobile)
- Using it as a modem for my Eee PC
The key thing about most of these features is that they would be useless without a proper internet connection. If I didn't have a mobile broadband plan then I'd have a chunky phone with a nice camera and GPS that happens to need charged every night. Instead I've got a mobile office in my pocket.
So after 7 years of mobile use I'm totally turned around on the subject. My mobile is no longer an annoying piece of plastic that I carry around as an obligation to other people who complain that they can never contact me. It is an integrated part of my life that I'd quite frankly be lost without.
At least 3 of my close friends now have N95s, and I've seen 4 of them in the office, so I must be on to something. I know quite a few of them are using Three's X-Series or an equivalent mobile broadband plan, too. It costs more than my old phone did, but I think the advantages more than outweigh the cost. The only down side is that people jumping on the bandwagon now get to pick up the N95 8GB, and there's no way I'd ever be able to justify getting one of those. Ah well, only a year and bit left on my contract...
Free as in Books
As I've previously mentioned, my recent purchase of an Eee PC has resulted in an increase to the number of eBooks that I've been reading. This horrible new addiction has lead to a general shortage of reading material that comes in the format I need.
Here in Australia we're a tad behind the times, so I doubt we'll be getting the Kindle or any similar "buy books on the go" service any time soon. Besides, I still can't bring myself to pay full price for an eBook. Can you imagine paying US160 for Don Knuth's Art of Computer Programming series and getting 3 PDFs? I don't think so. How can I let guests know that Knuth is my homeboy if I don't have a huge boxset sitting on the shelf for all to see?
So where does that leave my insatiable thirst for PDF files? Well, it turns out that there are a number of decent eBooks available for free online, the only trouble is finding them.
Googling for "Free eBook" will bring up a number of bogus resources, mainly proxy sites set up to collect Amazon referrer fees or sites that are offering up copyright infringing material. Unless you have a specific subject or prior knowledge it is very hard to sift through the junk.
There are a few legitimate free collections of eBooks, some specialising in technical books, others in classical literature that has fallen into the public domain, but in general these sites are very hit and miss.
The real gems are found scattered over the web, sitting as a reference on someone's blog or a random website. In the technical space there are a few well known books that are well worth a read, such as Mark Pilgrim's Dive Into Python, and Domain Driven Design Quickly. These books are popular for a reason. Then you have books that are not so popular but are written by a well known author, such as Charles Petzold's .Net Book Zero: What the C or C++ Programmer Needs to Know about C# and the .NET Framework.
Sometimes decent reading material just falls into your lap while you're busy trying to do something else. Take Dr Paul Carter's PC Assembly Tutorial, for example. It's a fascinating refresher on x86 Assembly and broader topics such as name mangling and compiler linking, and it was a totally unexpected find on my part. I'm sure I was searching for Pokemon at the time.
At other times you can find something worth reading in an unusual place. Things that are not necessarily "books" can make for good bus fodder. The Sun ONE Architecture Guide is a good example. It is remarkably well written, and also available in PDF format. In fact, manuals and guidance can be a great source of reading material. The SVN book, OpenGL Redbook,
TFS Branching Guidance and TFS Team Development Guide are all available online for free, and are all worth a look (especially the OpenGL Redbook).
With a little effort and a lot of luck you're bound to find something that's work reading. Just be sure to avoid sites advertising "Fr33 3B00kz 4 J00". They may infact try to hack your gibson or something equally scary.
(Browser) Window Shopping
I love buying PC games on Steam, so much so that I haven't bought a physical copy of a PC game since Battlefield 2 came out. However, I still prefer to purchase DVDs, CDs and books from brick and mortar stores. Why the discrepancy?
It's simple: I can still enjoy shopping for DVDs, CDs and books in a physical store. I can easily lose an hour browsing in Boffins, and don't get me started on JB-HiFi or even 78 Records (back in it's heyday, at least). To paraphrase Barney Gumble, If they didn't close, I'd never leave.
The online equivalents just don't hold the same appeal. Sure, I like looking through Amazon, but it's nowhere near as fun as visiting a real book store. iTunes is the same. I like the idea of flipping through a large range of stock and happening upon a rare gem that I wouldn't normally think of buying. I also value having the physical copy, as I can rip the songs at a much higher bit rate than iTunes offers, but that's just me.
Games are a totally different story. In Perth the vast majority of games stores are Electronics Boutique franchises, and walking into one of these stores is an assault on the senses. Idiotic self promotion bombards your eyes and ears at every turn, which, when combined with the crowds and a sales approach that is geared towards pre-sales and trade-ins, makes for a terrible user experience.
Compared to that, shopping on Steam is bliss. No sales push, and no requirement to pre-order before you can buy anything released in the last year. There are obviously down sides, with bandwidth and the lack of a physical copy to on-sell being two that immediately come to mind, but the convenience combined with the currently insane AUD-USD Exchange rate more than makes up for any shortcomings. Besides, I tend to be a hoarder, so I never trade-in anyway.
The bandwidth issue is the only major downside. I am still hoping that iinet will team up with Valve to offer free Steam traffic much like they do with iTunes, but I won't hold my breath. My tiny 10/10 cap can cope with at least one Steam purchase a month, so that's enough for me to get a regular gaming fix.
There is potential for me to change my shopping habits. I'm not totally against the idea of buying physical copies of games, it's just that I've found the experience to be somewhat lacking. I have been hearing good things about Game Traders, so I'll have to give them a trial run to see if I can be weaned off of Steam. You have to love a place that stocks retro consoles/games, and even goes so far as to devote a significant amount of shelf space to the display of their retro stock. Perhaps an improved UX in a brick and mortar games store will be able to convince me to ditch the online purchases?
Headshot
About Garry
Me On The Web
User Groups
Post Calendar
Tags
Who's Online
5 visitors online now
0 guests, 5 bots, 0 members
Map of Visitors
Blogroll
- Coding Horror
- Cup(Of T)
- Haacked
- Joel On Software
- Otaku Software Blog
- Rands In Repose
- Scott Hanselman’s Computing Zen
Archives
- April 2011 (7)
- March 2011 (4)
- July 2010 (1)
- May 2010 (1)
- January 2010 (1)
- July 2009 (1)
- April 2009 (1)
- February 2009 (1)
- January 2009 (6)
- December 2008 (2)
- October 2008 (1)
- August 2008 (1)
- July 2008 (3)
- June 2008 (4)
- May 2008 (5)
- April 2008 (12)