Thursday, October 07, 2010

Install Python 2.6 on ReadyNAS NV+

Just a few steps that worked for me. I can't be certain all the dependencies are listed here as I've been trying different things. If you come across anything that doesn't work let me know and I'll try to think if I've missed anything out.

If you're trying to install Python onto a ReadyNAS you'll find that the version you can get with "apt-get install python" will be around 2.3.something. If you need a later version you need to build it from source yourself. I only needed 2.6 and I found examples of other people being successful with building that version, so I haven't tried anything newer.

The instructions that follow are mainly from a post on the ReadyNAS forums and an article linked from that post. These may contain all the information you require without me setting out the steps again:
Ignore the fact that both of these are targeted at the DUO, the instructions work for an NV+ as well.

The instructions assume you have already installed the ToggleSSH, EnableRootSSH and APT addons (all listed under the ReadyNAS addons), and you know how to SSH to your NAS. I'm connecting from a Windows 7 box, so I just use PuTTY.
  1. SSH to your NAS
  2. Install the dependencies to build Python:
    • apt-get update
    • apt-get install libc6-dev
    • apt-get install gcc
    • apt-get install gdb
    • apt-get install libtag1-dev
    • apt-get install uuid-dev
    • apt-get install libssl-dev
    • apt-get install zlibc
    • apt-get install zlib1g-dev
  3. Make a directory to save the source to:
    • mkdir /root/src/
    • cd /root/src/
  4. Patch the "uniq" program (the wget command should be on 1 line, and note the dot at the end of the dpkg-deb command):
    • wget
    • dpkg-deb -x coreutils_5.2.1-2_sparc.deb .
  5. Build Python:
    • wget
    • gzip -d Python-2.6.6.tgz
    • tar xf Python-2.6.6.tar
    • cd Python-2.6.6
    • ./configure --build=sparc-linux
    • make
    • make install
Be aware that the last 3 commands in step 5 each take quite a while to complete.
And that's it. "python --version" should give "Python 2.6.6".

Saturday, November 22, 2008

Agile Fail?

Slashdot has had links to When Agile Projects Go Bad at, and James Shore's post on The Decline and Fall of Agile this past week, and it's raised a couple of interesting points for me--mainly concerning the manner in which it is adopted in a business.

The CIO article opens with a piece describing how most people aquire new skills:
In the first stage, people need to follow a recipe. In the second stage, you say 'That's all very nice, but I need more,' so you go off and collect recipes and ideas and techniques. And in the final stage—if you ever get there—is a level of fluency and intuitiveness where you can't say what you're doing, but you kind of borrow and blend.
Introducing Agile as a methodology tend to lead to people in the beginning conforming to a checklist culture. The article then goes onto describe why this almost always has a negative impact on the process of building software.

Some people just assume that by incorporating the practices defined within a particular Agile methodology that makes their business agile. Anyone who has been within a team where this has happened can quite clearly say this is not the case: Weekly releases? Check. Pair programming? Check. Test driven development? Check. Requirements as stories? Check. How does going through the motions of applying these techniques lead to a better product?

Answer: it doesn't. I'm being quite absolute on this: if you're in a team that claims to be "agile" just because you are using some techniques you read in Extreme Programming Explained then think again.

Agile is a mindset you have to get into. It's about trust and professionalism. It's about seeing a problem as a series of stages, and tackling each one separately. It's about communicating with your team and customers constantly. It's about change.

It's not about processes, and yet the processes have become the poster children for the entire movement. Read the original Manifesto for Agile Software Development. Read the Principles behind the Agile Manifesto. There are no concrete techniques there at all.

These ideas are what Agile is about, but its abstract nature is proving to be its downfall. By being so abstract people bought in to the likes of XP and Scrum, where techniques were laid out. And it's always the techniques that are going to take precedence over ideas.

You can see that members of a team are pair programming. You can monitor the amount of tests that developers are writing. You can see requirements listed in story form. But how do you monitor Agile's ideas?

How do you tell if your team is motivated? How do you tell if you team is self-organised? How do you tell if your team is keeping a constant pace? These things are much harder to keep track of, but they stand at the heart of what pure Agile is about.

And it's this that leads some people to believe that Agile is a failure. In many ways it is, and I won't sit here and defend some implementations of it, but at its heart the set principles are sound.

But it's not for everyone. For Agile to make an impact you need a good team. A trusted team with experience and who aren't too jaded to try new things. A team that communicates, and where mistakes aren't chastised but taken in as just another problem to solve.

Communication and team work are key to making a success with Agile. It takes a good team to pull it off, I admit that. Some teams won't thrive under its ideals, but when you put the right people together it gives them all the help they need.

Just don't get too focused on the techniques you read about.

Sunday, November 16, 2008

JQuery - How Javascript should be

I go for months without posting and then drop 2 in one night...

Let me first get something straight: I'm a focused lazy developer. If there's something already written that I can use to solve a problem I'll use it. As long as it's half decent and does what I need. But this has a flip side in that I code my own stuff with reusability in mind. Why spend hours solving a problem only to revisit it in another project a month down the line?

So I must say that for a long time I didn't really get Javascript. There didn't seem to be many opportunities for code reuse: each animation or validation check I did seemed wholly connected to one particular purpose. I struggled to generalise my solutions to enough of a degree so that they could be reused.

The impact of this was that I shied away from Javascript whenever I could: so when Microsoft came along with the AJAX Toolkit I was in heaven. Here was a collection of cool controls I could just drop onto a form and get a popup div, or a water mark on a text box, or a whole bunch of other stuff.

But at the back of my mind I couldn't help thinking this was all overkill. If I want a div to popup when I click a link, surely all I need is a CSS style on it, and swap the display style from javascript? So why have that as a control? Simplicity of implementation. It's easy. The lazy part of me liked that.

The focused part didn't. The focused part wanted to come up with a library that contained a load of these common functions so I didn't have to re-invent them on every project.

JQuery does just that, and more. I won't pollute the web with yet another JQuery tutorial (go see Rick Strahl if you want one) but I will say this. If you're a developer who likes to separate their concerns, take a look.

We're all familiar with layering applications: View-Model-Controller, Interface-Business-Data access-- it all amounts to the same thing. We're separating each element of the application so that we have structure. Structure eases maintainability. It removes bad smells. It increases orthogonality. For want of a better term--It Just Feels Right.

So why stick Javascript code in HTML? Isn't that polluting the structure of the document with behaviour?

Linking to a CSS file allows us to separate styling information from our HTML (or ASPX if you're into ASP.Net like me), and we all know you can link to Javascript files in the same way. If you're anything like I was though, all those Javascript files will contain is common "utility" functions. You'll still have "onclick" attributes in your HTML calling Javascript methods.

JQuery allows you to get rid of these onclick calls. Here's what I do:
  • Have a JS file per page in your application
  • Link to this JS file in your page as you normally link to script files
  • Do not include any script in your page what so ever
  • In the page's JS file, make use of the $(document).ready call to wire up your event handlers
For example: you have a floating div ("helpDiv") where you want to toggle the visibility based the click of a link ("lnkToggleHelp"). I used to add an onlick attribute to the anchor tag calling a Javascript function that would toggle the visibility.

In JQuery you can do this in your page's JS file:
Which separates the behaviour of the page from the structure: leaving you with 3 separate but linked strands of a page: Style (CSS), Structure (HTML), and Behaviour (JS files incorporating JQuery). To me it's a whole lot neater.

That and all the effects and manipulation that you can do with JQuery means I can't see myself writing Javascript in the future without using JQuery.

Building a PC - easier than I thought

Last week I ordered a Shuttle G5 from along with a processor, memory, HDDs, and a DVDRW drive. I've never assembled a PC of my own before, but I've installed enough cards and memory to know enough about what makes one work--so I reckoned I knew enough to take the plunge and go for it.

And I must say it was relatively easy. There were a few stumbling blocks, like I'd ordered 2 SATA HDDs and a SATA DVDRW drive and the case only came with 1 SATA cable, but I salvaged cables from my old PC so I didn't have to take a trip to Maplins yesterday afternoon. Only other problem was smearing the thermal paste onto the processor. I've fitted procs once before but that came with a template that you stuck onto the bottom of the heatsink and filled. There wasn't anyhting like that so I just used a piece of an old business card that seemed flexible enough.

Must be working though because it hasn't over heated yet and its been on all day. Very quiet too, although my last PC sounded like a jet engine because of all the fans in it. I like the compactness of it too--it's smaller than the subwoofer that I had with my old PC.

I was going to post a step by step guide to how I assembled it, but there doesn't really seem to be much point. The case comes with instructions on what to plug in when, and if you've got all the cables you need you're fine.

Only things I would say if you've looking to do the same is:
  • Make sure all the parts will fit into the chassis you're ordering
  • Don't use too much thermal paste as it can go everywhere if you put too much on
  • Buy extra SATA cables if you've chosen more than 1 SATA drive
  • If you're not using IDE drives, you can take out the IDE cable to make room
  • Your processor may come with a heatsink and fan, but the Shuttle includes one, so use it because it's quieter
  • If you go with the G5 make sure you mount the DVD drive close enough to the front so the button opens the tray (you'll understand when you get there ;))
But apart from that, it's not too difficult. I wouldn't recommend it to an absolute novice as there's some things that aren't covered in the instructions, but if you know how PCs work you should be fine. And you'll end up with a pretty PC at the end of it.

Wednesday, July 02, 2008

An Open Letter to M1 J26-J28 Drivers

Work is currently under way to widen the motorway between these two junctions, both north and southbound. As part of this work a 50mph speed restriction is in place due to narrow lanes that allow the work to take place.

Could I please remind everyone (or inform, if you haven't realised already) that the outside lane is much narrower than the other 2 and to keep your vehicle in that lane if you choose to drive in it?

I have lost count of the number of vehicles (well, cars mostly as van drivers seem to be aware of the road they are taking up) that have nearly hit me from drifting towards the middle lane. That stretch of road is congested enough during rush hour: for God's sake don't add to it by causing a pile up.

So please folks, stop fiddling with your sat nav. Stop farting about with your car's onboard computer. Put the phone down and stop nattering into your hands free kit. Stop trying to read a god damned book while doing 50mph in a narrow busy lane (yes, I have seen someone doing this). Stop doing anything that takes your attention away from staying in the lane. It's not difficult.

Saturday, June 21, 2008


Friday night/Saturday morning, and I'm killing time until I'm tired enough to sleep. The cat on my lap has his white paw resting in an empty shot glass that did have a neat JD in about half an hour ago. Got the house to myself but there's nothing on TV worth watching so I'm doing what my girlfriend hates me doing. Flicking through the music channels until I find a song I like, then flicking around again when it finishes.

Whatever happened to Sade? Can't say I ever liked that kind of music but it'll always scream mid 90s to me. My sister seemed to loop that CD when I was in secondary school and it looks like it just stuck.

Same with The Bangles. I remember a girl in primary school singing Eternal Flame (think her name was Carla) and the teacher (Mrs Bettison?) saying she wanted to be sent tickets to her concert when she was famous. That was probably 20 years ago now but that song triggered that memory off as well any smell could.

No Doubt's Don't Speak is on now, and I'm instantly at school again doing my GCSEs wondering what my life will hold and why Hayley chose to wear a black bra under a white top for the last exam of the year. But as soon as it hits it's gone again, and I'm dragged back to now with a cat padding my leg and me wondering where any of this is even going.

I don't really think it's going anywhere actually. Probably shouldn't be writing blogs at gone midnight after half a bottle of wine and JD but there you go.

Oh, Black Hawk Down's on

Friday, June 20, 2008

Creating Mock Web Services in .Net

So, a situation arises where your code needs to make a Web Services call out to a different system. Chances are you'll go through the usual stages of adding a Web Reference to your project in Visual Studio, and then use the generated code to make your call. Simple, right?

Well, yes, and Visual Studio goes out of its way to simplify the creation of this client code, so you can get on with calling the service rather than concern yourself with the plumbing that's required.

But what if the service you are calling charges you for every call you make? What if you can't guarantee that you will be online during the development of your code? What if that service is currently under development and you don't know whether it will be available when you are doing your testing?

If any of these apply you need to remove the external call to the web service from your code. In a unit test scenario you would probably use something like NMock and architect your code to use a dependency injection pattern: injecting an NMock created object that matched an expected interface.

In other cases what you can do is create a mock Web Service. One that matches the interface of the live one, but which you control.

You can easily create interfaces that match a WSDL file by using the WSDL.exe program. I have a sneaky suspicion that this tool is used to create the client code from Visual Studio when you add a new Web Reference, but it can also perform the other way around.

First, obtain the WSDL of the Web Service you want to mock up. (If you are calling a .Net Web Service, then the path will probably end .asmx. To get the WSDL, just append ?wsdl to the path and you'll get the WSDL XML). Save this to your local machine.

Open up the Visual Studio Command Prompt and type wsdl.exe. You should get a heap of text explaining the command line switches, but if you don't your paths aren't mapped correctly. The wsdl.exe file should be somewhere on your machine though :)

Once you've found the tool, type

wsdl /language:CS /namespace:Your.Namespace.Here /out:Directory\To\Save\To\ /protocol:SOAP /serverinterface finally-your-wsdl-file-here.wsdl

There are other options too if you need them, like setting proxy username and passwords, but the one shown is what I've used and it works fine.

This will create a .cs file in the /out directory that contains a number of classes that match the object definitions in the WSDL. It will also contain one interface that you must implement in order to complete your mock Web Service.

To do this, create a new ASP.Net Web Application. (I guess you could create a Web Site, but I've not tried that as I don't like them). Add the code file you generated above to the project, then add a new Web Service.

In the code behind for this Web Service, change the class definition so that it implements the interface in the generated code. Visual Studio should help you out by generating method stubs so the class matches the interface.

And there you have it, place code in the method stubs to do what you want.

You now have your mock web service. Run the application to make sure that it works, and then make a note of the address of the new mock service. Enter this as the URL of the web service you want to call in your App/Web.config file in place of the live one, and your application should now call your mock instead of the live one.

A little tip though. I've noticed that (at least Visual Studio 2008) doesn't like attaching to 2 IIS processes for debugging. If you are calling your mock service from an ASP.Net application and you want to debug both, you'll need to start one of the applications up in the Visual Studio Development Server, instead of running under IIS. If you do this, make sure you assign an explicit port value rather than an auto generated one, otherwise your calling code won't be able to call it :)

Monday, May 26, 2008


I've currently got a post on ice about using CLR functions in SQL Server 2005 using LINQ (don't worry Paul, I've not forgotten), but while I mull that over I'll just make a short point about refactoring code.

Regular readers (and Google Analytics tells me that I do have some, at least), might have picked up on a few complaints I've had about VB.Net. Personally I wish I'd never have to use it, but sometimes rewriting an entire app in C# isn't cost effective so... needs must, and all that.

Well, I was recently in the midst of a ton of VB.Net code, thinking "I could do with some IDE refactoring support here," after needing to extract a code block into its own method. Except I can't find any such support in Visual Studio 2008 for such an option.

Using C# in Visual Studio (2005 and 2008), we have a neat little context menu option called Refactoring, and while it doesn't offer the depth of features that something like Resharper offers, it at least allows you to Extract Method, which was the refactoring technique I needed to use.

Long story short, I found this post from the VB.Net Technical Lead:
I’d never even heard of refactoring until C# added the feature to their IDE. I’ve never bought a copy of, much less read, Refactoring: Improving the Design of Existing Code.

I let out an audible sigh after reading that. In a way it explains a great deal about VB.Net.

Refactoring should be something that every professional developer knows about and practices every day of their working lives. It is an integral part of the development cycle, and one which even graduates should at least be aware of.

If we do not refactor we end up repeating code needlessly. Although this might produce a working application that passes all current tests, put yourself 6 months, or 6 years down the line where you have to add a new database table, or a column to a table, or a new page to your web application.

If you've essentially been copy and pasting code, how many places in the code base do you have to change to add that small piece of new functionality? Answer: unknown, especially if you weren't involved in the initial project. How do you know that you've caught all the places without executing every branch of the application?

Answer: you don't, not until you get irate customers yelling at you, and your managers asking why such a small change resulted in the entire app breaking.

And it's such a simple thing that I have difficultly believing that any developer worth their salt wouldn't see the benefits that it gives. So if you don't know, then read up and get using it. Your code can only get better.