The problem with this approach was that getting feedback on the project was more difficult. Either people were;

• Long time friends of mine, in which case though I trust them to be honest, an outsiders opinion would give me something different.
• Not interested in Git because, being a technical book, it has a far narrower audience than a fiction book.
• Intimately involved in the project, in which case they are going to be biased towards it.

To overcome these issues, I decided to find someone in the open source community that used Git extensively and who has also been known to give rather good advice in the past. During the development of the book, I began listening to “The Changelog“, a podcast all about open source, and in particular the web and ruby. It’s a fairly well known fact that many Ruby developers use Git. I decided to send the book to Wynn Netherland, co host of “The Changelog” to see what he thought about it.

I could not have hoped for more useful feedback. I had been focusing the book towards a very specific subset of the Git community and I was exceedingly glad when Wynn summed up his thoughts on who the book would be geared towards.

Corp devs who cling to non-distributed source control and designer-y type folks that are intimidated by SCM (probably scared off from SVN)

Which was my exact target audience. Though the book is easily readable by anyone, the format of the book takes you through, week by week, as Tamagoyaki Inc. decide to implement Git in their workplace.

Another comment was pretty interested too.

I like the writing style. I think it makes a technical topic approachable. What i found difficult was scanning.

Wynn is exactly right. In my efforts to make the book kinda quirky and approachable, I used pun-like headings to each chapter section. Whilst this worked well for someone reading the book cover to cover, it made the book very difficult to navigate if you wanted to dip in and find out information on a specific subject. I do currently have an index and was pleased to see that it had been implemented well.

…but your index is solid

So, my major change to the book will be to include kind of dip-in guide, so that people can just jump to a chapter to get information on a particular topic. Wynn seemed to like the list of topics on the back and the idea of using that as a base for the dip-in index was well received.

I have to say I am pretty pleased with the end result.

…all in all, superb job.

So just a few more tweaks here and there and I’ll be ready to release this baby to the masses. A bit thank you to everyone who has helped out with the book so far and an extra big thank you to Wynn for taking the time out of a very busy schedule to look over the book and offer me suggestions.

1. it will keep it under version control
2. it will allow me to keep using Git (yay!)
3. it will allow people to submit spelling/grammer fixes

Of course the downside is that people may read a section and then see that it has changed, or that certain events are cut/moved/revealed at a later date.

I guess it’s a risk the reader takes, but in all honesty, I rarely go back and change things. My books/stories are like films and I generally write them from start to finish. Except in this case, I can see it being a multi-book story. Which both pleases me and terrifies me to the very core. With time at a premium it takes a large push to finish a book. OK, so I did write about 150,000 words in a little under two months, but that was HARD GOING!!!

Well, we’ll see how it turns out

Pete

Rest assured even once complete it will remain free on GitHub so enjoy.

http://github.com/cbx33/gitt

I thought the project was pretty damn impressive from the outset, but then I saw more information about how Paul was planning to implement the legs. Not just simple zero joint legs, oh no! That would be far too simple. These leg joints are going to allow the little beast to walk like either a mammal or an insect, depending on how the servos are set up. Highly impressive!

I have to say this is going to be absolutely awesome, especially as all the programming and controlling is going to be carried out using a little Arduino board, not dissimilar from the one I posted up a few weeks ago. Right now Paul is having a few 3D printer issues, that’s right folks, he’s even printing all the parts himself, so why not head on over to his blog and give him a little more encouragement.

Git In The Trenches is a breath of fresh air for me, as it allows me to combine together a little fictional work with technical work, both things I enjoy writing a lot.

I took the work I have done so far and asked the gitolite author, Sitaram Chamarty. As well as some very constructive comments about points in the book, he also had this to say about how GITT is shaping up.

Your writing style for the trenches part is awesome — you have all the makings of a real fiction writer! I particularly loved the bit about the guy who vowed never to eat pizza again — nice touch!

All I can say is that it does look nice so far, and once it is polished up it should be quite useful to newbies, especially in the corporate world.

I’ve also had some other great feedback from people who have read it so far – I know I still have a lot to do, please keep your comments and scenarios coming in. You can fine the project here.

I’m really excited for the future of the project and almost everyone who has read the premise of the book has commented that it sounds like a very good way to present the material. I know that a few people who have read a little further into the book itself have liked the style.

We still have a long way to go and have to explain some pretty complicated topics, but I’m confident that with Git users behind me, we’ll win through.

Thanks to all who have contributed so far

https://github.com/cbx33/gitt

The aim of the book isn’t to be a definitive guide. It isn’t supposed to be the most elite technical reference either. What I am going to try to do is show how to use git in a practical sense, using real world examples. The aim is to follow a group of developers through their daily lives using a version control system. This way, I intend to come across the same issues and problems that normal everyday people do.

What I would like is for people who read it to identify with the scenarios presented, therefore, when the same situation occurs whilst they are using git, they are not reduced to reading man pages necessarily, or jumping in an IRC channel. Rather, they should be able to go, “ahhh, I remember this exact situation was presented by that fictional group of developers”

To this end, I am asking for anyone that uses git on a regular basis, or even not so regular, to give me some ideas/scenarios that they themselves have faced. Did you have to do something funky in git? Was there more than one way to do what you did? These are the types of questions I want to answer.

So please help me out, anything you can contribute will be acknowledged and appreciated.

Thanks

Pete

The interest sparked off from the fact that I spent a considerable amount of time tuning Windows 7 to look and feel like my current Windows XP setup. I then realised that I had done the same on Windows XP to make it look like 98. But why? Is it because I am an old fuddy duddy now? Is it because I am unable to embrace change? Is it because I can not take the time to learn something new? I hope not!

I’m forced to think about the other side of the fence, the Linux world. I have used a large variety of Linux distros, Ubuntu, Fedora, RedHat, CentOS, Knoppix, BackTrack, Foresight and Puppy, to name the ones I have used regularly. I have had no problem adjusting to these, and to newer versions of these. So what’s the problem with Windows 7? Why do I constantly feel the need to live in days gone by? I guess the ultimate question is in the title of the post. Did we already hit a desktop Nirvana?

This is all very interesting. Going all the way back to Windows 3.1, and the change we encountered moving to Windows 95. The difference was vast. It changed the entire way we used the desktop. Now let’s move from Windows 95 to 98, no real major differences in the design of the desktop or layout, again from 98 to XP, save for a few updates to the startbar and grouping. Now we go from XP to 7, and I have to say for me it’s kind of more of the same. There is nothing really new, the groupings work a little differently, but I missed having the text labels for programs. I usually work with more than 40 windows open at a time, call me messy, but it’s just how I work. The nature of my work means I flit from task to task all day every day.

So have we seen the last of the desktop development? Of course not! I’m not for one minute saying that there will never be any more advances in desktop development. What I am saying is that all of the “nice” new features, the ring switching, the window previews and all just “nice to have” eat resources. We should be making improvements to the desktop that both offer us better workflow, more enhanced capabilities, but without the need for a machine that is three to four times as powerful as it’s predecessor. I still recall that the compiz engine when it first came out, at the time when I bought a GeForce 7300 GT OC, still ran acceptably on an old MX440. I was stunned.

You have to wonder about the real motivations for change here. Call my cynical, but the Linux desktop seems to move and evolve with the demand from the users. We ask for things to change, and when that volume hits a critical mass, change happens. OK, it’s not always this way, and sometime design leads take the bold decision to try something new, but for the majority it seem to me that this is how the development happens. Now let’s take a look at the Microsoft way of thinking and it’s a little different, but then so is their business model. They thrive on people buying new versions of the software, so it’s in their best interest to get people “hooked” on these new features.

Microsoft sell training, they sell certifications, and so a portion of their revenue is directly dependent on how good a job they do at changing things sufficiently enough to require more training. Look at the shift from Office 2003 to Office 2007. As I said, call me cynical, but this change in thinking also benefits the PC manufacturers also. It enables them to push bigger better and faster machines, which ultimately will all run at the same speed, once they become loaded with the next generation of system hogging operating systems.

I digress. Apologies. Going back to our idea of a desktop nirvana. The ultimate root notion of a desktop hasn’t changed in many many years. True, the mobile market is starting to make us rethink things, but it is still rooted in the idea of windows, files, folders, icons and desktops. It amazes me that in all this time we have not really come up with a single new methodology for using a computer that has been accepted and implemented. Cue some references to project X, Y and Z. I understand people have probably tried, but I’m forced to consider the fact that for the foreseeable future, the desktop is as good as it gets. Yes, we’ll get things like wobbly windows, snappy left and right thingies and the like, but the fundamental desktop model doesn’t look like it’s going anywhere just yet.

But maybe this is all stemming from the fact that the whole files and folders, the root method by which we store information needs an overhaul.  It’s based heavily on the model of an office in days gone by, where you would have reams of paper files, in folders and that made sense, whilst we were still in a transitional period.  Now though, it’s causing issues.  People can’t get to their information quickly enough.  I personally want a tag based file system.  I want to be able to write in something like, “iso, 6 months ago, ubuntu” and for it to instantly bring back an iso image of ubuntu that I had 6 months ago.  What I don’t want however is a tracker system that has to use up system resources to keep an index of the files.  I want this built in.  I want the world I know.

Let me know what you guys think?