Posts Tagged‘documentation’

Our RepRap Longboat Prusa and The State of DIY 3D Printing.

My followers on Twitter will be aware that for the past few weeks I’ve been working with a couple other guys on building a 3D printer, namely a RepRap Longboat Prusa. I’ve been interested in them for a long time, mostly because they tickle my sci-fi nerd side just right, but apart from endlessly fantasizing about them I hadn’t really pursued them further. One of my long time gamer friends asked me late last year if I’d be interested in going halves for a kit. After I mentioned the idea to another friend he jumped on board as well and the 3 of us waited eagerly for the kit to arrive.

In total we’ve spent about 48 man hours total over 3 days putting it together, getting the wiring done and then troubleshooting the software and interfaces. It’s been an eye opening experience, one that challenged my electronics knowledge like it hasn’t been in quite a few years, and the result is what you see below:

We decided not to attempt to print anything since at this point it was getting close to midnight and we didn’t want to keep the Make Hack Void space open any longer than we already had. But from seeing it do the dry run it appeared to be functioning correctly (it’s printing a small cup in the video) albeit a little stiff at some points. We think that’s due to 2 things, the first being that the large gear on the extruder platform is warped slightly and sometimes hits the mounting hardware near it. Secondly we were running the steppers at a low voltage to begin with so with a little more juice in them we’ll probably see them become more responsive. We’ve still yet to print anything with it but the next time we get together you can guarantee that will be pretty much all we’ll do after we’ve spent so long on getting it running.

What this project opened up my eyes to was that although there’s a torrent of information available there’s no simple guide to go from beginning to end. Primarily this is because the entire movement is completely open source and the multitude of iterations available means there’s near endless numbers of variations for you to choose from. Granted this is probably what a lot of the community revels in but it would be nice if there was some clear direction in going from kit to print, rather than the somewhat organized wiki that has all the information but not all in a clear and concise manner.

The software for driving the machines is no better. We started off using the recommended host software which is a Java app that for the most part seems to run well. At the moment though it appears to be bugged and is completely unable to interface with RepRap printers, something we only discovered after a couple hours of testing. RepSnapper on the other hand worked brilliantly the first time around and was the software used to initiate the dry run in the video above. You’ll be hard pressed to find any mention of that particular software in the documentation wiki however which is really frustrating, especially when the recommended software doesn’t work as advertised.

I guess what I’m getting at here is that whilst there’s a great community surrounding the whole RepRap movement there’s still a ways for it to go. Building your own RepRap from scratch, even from a kit, is not for the technically challenged and will require you to have above entry level knowledge of software, electronics and Google-fu. I won’t deny that overcoming all the challenges was part of the fun but there were many road blocks that could have been avoided with better documentation with overarching direction.

All that being said however it’s still incredible that we were able to do this when not too long along the idea of 3D printing was little more than a pipe dream. Hopefully as time goes on the RepRap wiki will mature and the process will be a little more pain free for other users ,something I’m going to contribute to with our build video (coming soon!).

How To Make Your System Admin Go Postal.

So you’re a large company or government organisation with a decently sized IT department. Everything is running smoothly as far as you can tell but there’s something missing. You can’t quite put your finger on it but there’s just no “buzz” or “synergy” or any of those other words you heard other middle managers use at that conference you went to last week. You can’t let this go on too long or something terrible will happen, so what can you do?


  1. Have one of your system administrators design or redesign a system. Make sure its business critical.
  2. After several long meetings with that administrator get them to start implementing it.
  3. Ensure that no documentation is created regarding the design, implementation or required maintenance.
  4. Make sure everyone knows about it but not enough to be able to figure it out.
  5. Halfway through them implementing it give them another high priority task.
  6. Let the system stagnate for about 6 months. This ensures that everyone who was working on will no longer have any idea how it was implemented and if you used a contractor for it they’ve either moved on or been fired (they were useless anyway, right?)
  7. Bring up the unfinished project at some meeting and tangle it up with another project that’s less than a month away from its final deadline.
  8. Now here comes the great part, find your target and dump the system on them. Make the costs of the project failing so high that they’ll have no choice but to complete it on time or be fired.
  9. Additionally get them to redesign the system. This means that you can instantly go back to step 1 and repeat the process on another target should you so wish.
  10. Sit back and relax. Your little worker bee is now a couple weeks away from going completely postal on your entire company!

Using this secret technique you to can ensure that none of your projects are delivered on time, your staff overworked and most importantly none of the blame will ever reside with you. Also you will get RIPPED IN 4 WEEKS!!!!#()*$)#*$)(#$*)#$*


Reading the passage above you may be lead to believe that I’ve gone completely bonkers after an incident at work. You’d be right to since I’m here at work on Australia Day thinking up a plan of action for something vaguely approaching what I described above. Sure I was probably going to be in here anyway but I was going to get a lot of work done that was really quite interesting and fun. Instead I’m now going to be spending the next 3 weeks unravelling yet another mess of what can only be described as fire-fighter¹ architecture. I’m beginning to question how sane I was taking the extension in the first place.

Sure there are benefits to doing something like this as I’ll be learning a bit of tech that I’ve only dipped my toes into previously. Still when I get given something like that I don’t like having to dive in head first into it without the proper information which is, of course, no where to be found. I’ve never left a workplace without documenting all the inane crap I did to make sure someone else doesn’t end up in this situation. It seems more and more I’m amongst a minority in this case.

I was decidedly more livid about this whole situation yesterday when trying to voice my concerns (and possible solutions) and having them fall on deaf ears. Today however I’ve decided to isolate what I can and can’t do and start hacking away at it. If this bit of work is going to be my downfall I’ll go down swinging, but I would’ve still preferred to have not been put in this situation in the first place.

So ends this little foray into crazy rant world. Hopefully tomorrow I’ll be back to my regularly scheduled blogging and we can all put this behind us.

That or I’ll find those 10 steps above on a management website and I’ll just have to give up on the IT industry completely 😉

¹I use this term to describe something that arose out of an immediate problem. One example I was unfortunately responsible for was copying files from a Unix share to Windows. The program that needed the files couldn’t read the share directly, no matter what we or the vendor tried. So I made a script that copied them from the Unix system to a Windows share. This of course was a band aid solution on a much bigger issue and of course anytime the system broke down they instantly blamed it. I put out the fire with a quick solution, but it became a critical part of the architecture.

Sysadmins Gone Wild.

Us system administrators are territorial people, especially when it comes to systems that we’ve set up ourselves. In fact I bet you’ve even run into someone who’s the only one who knows something about a certain system or policy, and heaven forbid if you ask them to tell you how it works. I can’t say I’m innocent of this kind of behaviour either as there’s been more than a few times when I’ve built something to what I consider perfection only to have it sullied by others. I like to call this the baby syndrome, as when something is your baby you’ll do everything in your power to make sure no harm comes to it.

Now I’d be lying if I said that this kind of behaviour was detrimental to people like me. Many of the places that I’ve worked in hired me as the other person was leaving, usually leaving a trail of systems that were usually not documented, except for in their head. My first couple months of any of these kinds of jobs is to get the systems to a state where anyone could come in and work on them which I believe is a good exercise when bringing new people in. Not only do they figure out how everything works they also usually break something in the process, and you never know a system well until you break it in some odd way.

However this kind of behaviour is exactly what leads to IT departments spending 90% of their time playing catchup with the routine issues of their environment and 10% trying to innovate. The issue for the system administrator however is justifying their existence to their employer. It’s pretty easy to keep your job when you say “I”m the only one who understands the mission critical business systems” but the more reasonable “As long as they follow my documentation anyone could do it” is likely to make you an easy target when it comes time to cut the fat, as it were. It’s this strange dichotomy of wanting to make everyone’s lives easier and making yourself irreplaceable that causes many IT shops to end up not caring one way or the other. That is, until something like Gershon comes around.

There’s another side to this coin however, and that is no matter how good you document your system there’s guaranteed to be some uncanny situation that works its way out of the woodwork that you could never plan for. If you’re still working with the system its pretty easy to start tracking the problem down, however if you’ve moved on the person in charge of the system you created is up the proverbial without a paddle. I’ve been in this situation a couple times before and it usually ends up with them calling me. Now it’s tempting to be a complete ass to them and tell them where to go, but for someone like me working in a small area like Canberra that’s career suicide, and I’ll usually spend an hour or two working it through with them. I wish I could say the experience was the same for me calling other ex-employees, as the majority are more than happy to give me the metaphorical middle finger.

In other words stop off loading your boring work onto others, you selfish gits 😛

Passing the Torch.

After just over a year at my current position I will now be moving onto greener pastures. I don’t think I’ve mentioned it before but I’ve been working as a contractor for the Australian Maritime Safety Authority, and that website is on part of the infrastructure I helped maintain. I’ve done a lot here over the past year and it was a great first contracting gig. The combination of a small yet extremely innovative environment let me accomplish things that I’d never saw myself doing before, and gave me a taste for the technical solution architect in me. On Wednesday I will be moving onto another contract at the Australian Trade Commission, working in a much larger environment with a completely different mindset. I’m very excited.

So the last month of my time here has had me finalising everything that I’ve done over the past year and it has been quite an interesting experience for me. Most of the organisations I’ve worked with prior to here haven’t had me solely responsible for a large section of their IT infrastructure and I realised that without a proper handover I’d be leaving these guys without a leg to stand on. It was good to note however that they loved my idea of spending the last week and a half handing everything over, and I’m sure they’ll be able to keep the whole show running whilst they get other staff trained.

This was probably one of the common challenges I’ve faced in small organisations. With such environments its very hard to get all the skills you need to ensure you’ve got full primary and secondary coverage on them. It usually ends up that if the person who knows a system is sick or incognito you’re pretty much up the proverbial creek without a paddle. In high turnover environments your even more likely to suffer from this and that’s when documentation and handover become critical, and it’s something that I noticed when I left my last position.

Whilst I wasn’t responsible for as much in my last position I was still a key player in a lot of projects. I had requested that I got the people in my team (the projects guys) for a couple days to do some detailed hand over. Instead I got about 3 hours on a Thursday afternoon, which was barely enough to cover everything that needed to be done. Needless to say I knew that something would go wrong and I was called by them no less than 3 times the week after I left and spent a good few hours explaining to them what was going on and why. They were lucky in that respect since I’ve tried that in the past and been told that they did not have the time nor inclination to speak with me. Harsh but completely understandable (from a professional point of view anyway).

So these last few days I have here will be spent making sure they’ve got everything they wanted to know out of me and giving my heart felt goodbyes to everyone. The CIO has said that I’ll always have a place here at AMSA and I must say, it’s the first time in a long while that I actually feel like coming back would be a good idea.

Maybe I’m just becoming soft in my “old” age 🙂