Ahh, the case.  The Antec Fusion Remote.  A lovely case, it seems.  The construction feels fantastic, nice and sturdy, and the front looks wonderful.  But, man!  The thing is a beast!  I swear that it’s almost as big as my desktop PC.  The unit we have to put the HTPC on is just about big deep enough – so long as we don’t want any cables at all attached to the back!  It’s either that (and what’s the point of having the HTPC if we can’t hook it up to anything?) or have the case hover over the edge of the unit, which’d look sloppy.  No, the case, albeit probably very nice, is going back.  But what to do?  Every case I look at and like is about the same depth.  All the really slim cases would also require me sending back my PSU, probably the wifi card as well, and possibly wouldn’t accommodate the graphics card.  Thankfully I came across the Silverstone GD02 which will allow for a standard ATX PSU, a graphics card up to 11.5″ in length and still looks quite nice to boot.  Best of all, it’s about 8cm shorter in depth than the Fusion Remote!  I’m hoping that I didn’t need to go for the GD05 which is a further 4cm shorter than even the GD02, because I like the ability to have an external 3.5″ device on the case (for adding a memory card reader or similar further on down the line).

Now, the GD02 case doesn’t have a few things that the Fusion does.  It doesn’t have a display on the front.  To be honest, I’m coming around to the idea of that actually being a really good thing.  Do I really want to have a really bright (from what I’ve read) display on the front of the case while watching a movie?  No, I think that’d be distracting.  It also doesn’t have a remote.  Well, the diNovo keyboard with integrated touchpad should do the trick there.  And it doesn’t have a volume control on the front of the case.  OK, that’s only an added bonus and nothing I’d miss anyway.

So the new case was ordered yesterday from Scan (along with a 1.5TB hard drive), and bless ‘em, it’s already been dispatched and I should have it today!  Whoever I ordered the CPU from needs to get in gear because I want to get buildin’!

This is what we went and ordered this past weekend:

• Antex Fusion Remote case
  probably a little bigger than I wanted, but lots of people seemed to like it
• AMD Phenom II X4 955 CPU
  may as well have something that can encode reasonably well!
• Asus Micro-ATX M4a785 HTPC mobo
• LG Blu-ray reader/DVD multi-format burner
• 2GB Crucial RAM
• ATI HD 5450 graphics card
  even though mobo has the 4200 line built-in, I think it’ll be better to use a dedicated card
• Logitech diNovo Mini keyboard

Got a few other things as well, such as a wifi card, bluetooth dongle, etc.  The only thing I don’t currently have is a hard drive.  I’m thinking of a small, fast drive for the program partition and a couple large drives in RAID 1…  Actually, is that possible?  Can I have one drive in the computer not in raid and two others in raid?  Or is it a case of they all need to be in some format of raid or not at all?  Guess I’ll soon find out!

Very excited about all of this… Some parts have already been allocated and invoiced, so hopefully have everything within the next 10 or so days.

01022010

Cool.

On with the book review…

The book, as the title makes it plainly obvious, is about developing your team in relation to working with PHP.  It’s aimed at, well, pretty much anyone who has an interest in developing or working in a team, be it managers who need to set up and manage teams or developers working within a team who want to improve their work flow and procedures, or anyone in between.  It does this by giving an overview on several subjects, but doesn’t go as far as to tell you that you must do x, y or z.  This is understandable, though, as every team is different and the book acknowledges this.

Chapter 1 discusses the need for teams and the use of established software engineering patterns that can help as well as touching on some tools such as issue tracking, source control, etc.  This chapter is good if you’re not sure with a lot of terminology as the overview covers a few key topics such as continuous integration and regression, and also touches on software development principles.  It doesn’t go in to depth about any one thing, as they’re covered in further chapters.

Chapter 2 covers MVC (Model View Controller) design principles and how you might form you team to deal with different aspects of the MVC pattern.  To be honest, if you’ve dealt with MVC at all in your job then this chapter holds no surprises, as you will know how the pattern works and how you would give responsibilities to different team groups/members.  However, if you’ve not had any experience at all then it offers a nice little introduction to the pattern.  (Remember, though, that this is not about how you would code the MVC pattern or use it in your project – it’s about making the principles of the pattern known to you and how it may fit in to team working.)

Chapter 3 is about dealing with complexity.  That is to say, if you have a complex project or application then this chapter gives you an idea on how to manage that and implement things that will make your job easier.  Essentially, what this chapter comes down to is why it’s a good idea to use a framework.  Again, it’s nothing new if you’ve already used frameworks (generally by then you know all the reasons why it tends to be a good thing for complex projects), but if you’re contemplating using one, or sit in a more managerial role and want to know why your developers are using one, then it’s worth the read.  At the end of the chapter the author also gives links to a number of different frameworks – some of which I hadn’t heard of before – along with their license type and a brief description.  What I especially liked about this chapter is that the author came over quite framework agnostic.  He wasn’t saying that one framework is better than another or which you should use – he supplies a list of frameworks and arms you with knowledge of what to look for in a framework (commercial license, documentation, support, code quality, security, etc.) and sets you on your way.  It is, of course, up to you to choose a framework that best suits your project and then integrate that in to your team workings.  This is a Good Thing!

Chapter 4 is about the process to get from the concept of an application to the end product and the steps in between.  There are a number of flow charts throughout this chapter that help you understand the process, and for someone like me who generally goes from being told someone wants an application,  to getting a brief functional requirements set and then making the thing, I can see that I have room for improvement!

Chapter 5 is about Agile development, and probably the chapter I was looking forward to the most.  Agile development was something I’d heard about, had an ever-so vague idea of what it was, but wasn’t too sure.  this chapter tells you what the principles are behind Agile development, how is works when dealing with the customer and a wide general overview.  The chapter then goes on to cover Extreme Programming (XP) a bit, and how Agile and XP can work in the team, pair programming, sustainable working styles for the developers, stand-up meetings, and so on.  It was good to find out a lot of how I work falls under Agile/XP, even though I didn’t know it at the time!  I learned a lot from this chapter and know a number of things I want to try to implement in to my working practice.

Chapter 6 is about collaboration among the team.  Basically it covers how source control is helpful, bug control and reporting, and ways developers can communicate (mailing lists, for example).  Useful stuff if you don’t know about it already, but pretty much any developer I know already uses source control in one form or another, as well as bug reporting, mailing lists, IRC, and everything else.

Chapter 7, the final chapter, is about continuous integration – what happens when your project needs to change, how does the project evolve, how to ensure team success and more.  Even though this is a distinct chapter in itself, I did get the feeling that it was more like a summary chapter of everything that you had just read.  But this was probably just because the author was referencing a number of his earlier chapters because they relatedto what he was taling about at the time.

Conclusion

This book is only 160 or so pages in size and it tries to cram a lot of information in to it.  There are times I wish the author could have gone in to more detail, but could also very much appreciate that the author didn’t have enough room to do so.  I actually quite liked that it was a really high-level overview for the most part, because it gave me a lot of ideas of things I want to investigate further and can now go and find resources that covers those bits in much more details.

Because I know quite a number of principles this book covered, such as the MVC chapters, source control, etc., I didn’t take quite so much away from it as another person may – and I’m sure other developers would feel the same – but I did still learn a lot from it, such as the agile development, and a number of keys principles that mayhelp me manage my time better as well as have a more integrated team.

However, this book wasn’t all roses and there were a number of things I really didn’t like.  The first thing is the authors style of writing.  I honestly didn’t gel with it very well and actually struggled to get past the first couple of chapters.  There was an overabundance of commas – sometimes breaking up the sentence in odd places – and it because a little repetitive and word for no reason.  My wife accuses me of using commas too much, which I probably do, but the amount in this book just caused me a headache!  The writing style I could get over (as mine’s not the best, but then, I’m not trying to sell you a book!), but the one thing that really pissed me off was that fact that the credits included a proof reader!!  WHAT?!  I lost count of the times ‘form’ was used when it should have been ‘from’, or the spelling mistakes, grammatical errors, or missing words entirely!  A couple of my favourites is when the author was discussing the use of functional programming vs. OOP, and then goes on to say, “Be it fictional programming you are using or object-oriented programming…”  Fictional programming!  And this highlights the commas quite nicely, “…we might be about to deal with estimates that are off the mark for some time, in the long run, both, the development team as well as clients and users will become frustrated…”  I don’t so much blame the author for these mistakes – I can’t imagine the pressure of writing a book and trying to get it spot on – but isn’t that why you employ proof readers and editors??

All in all I’d say that if you’ve been developing for a while and had any team experience then this book wont be of much use to you.  However, if you’ve never worked in a team environment, or don’t have much development experience, are a manager or something like that, then you may find this book quite beneficial to you for an overview of working in and establishing team working principles.

Hopefully have a bit of a review posted up here some time soon!

The plug-in is called tablesorter (found at tablesorter.com), by Christian Bach.

As I mentioned, it’s really simple to implement:

    $("table.sortable").tablesorter();

But also gives you the ability to add extra functionality by the use of ‘widgets’. One example of a widget from the tablesorter site is to add headers every number of rows. Here’s my rather paltry contribution to the widgets – highlighting rows when you hover over them.

$.tablesorter.addWidget({
    id: "highlightOnHover",
    format: function(table) {
        $("tbody tr.highlight", table).remove();
        $("tbody tr", table).hover(
            function(){ $(this).children("td").addClass("highlight"); },
            function(){ $(this).children("td").removeClass("highlight"); }
        );
    }
});

?!