Stuart Hacking

I just ordered one of these kits

Fuzebox Starter Pack

The mainboard is supplied unassembled.

The fact that computers contain hardware is something I can normally overlook. Hardware can spasm out of control, fizzle and burn in impressive colours or simply die slowly, bit-by-bit (if you’ll excuse the pun). I’d be happy to own a computer that operated by magic: no parts – just an abstract concept.

Nevertheless, I’m still fascinated by hardware and have always wanted to try a little project. Having read most of “Hackers: Heroes of the Computer Revolution” now, I’m aware that among the first home computers was the Altair 8800. A kit machine where you would, typcally, buy the components and build it yourself. This was the norm, and, Hackers is full of little accounts of people hacking together hardware into a semblance of what we know as Personal Computers. Steve Wozniak is a notable example: Inventor of the Apple. The next generation Apple II would becomes one of the most popular computers for games hackers in the early 80s.

It’s always struck me as a time now past – today, infinitely more complex machines are fabricated in computer controlled environments. Even if you try to gather parts from vintage hardware, for a novice enthusiast it would be difficult to put together and perhaps more difficult to find connectors to make it usable.

Then I came across the link to this kit.  It’s an 8-bit console kit that seems fairly simple for a starter project and has good instructions. It seems just right for getting into some hardware work. The console itself (although only 8bit) uses S-Video or AV connectors and flash memory (instead of archaic co-ax cables and cartridges)

I’m excited to get started into a new (different) project!

Self Computers, Console, Hardware, Project

I submitted my dissertation and software reports today. As usual on a deadline, I had the work mostly complete when I arrived in the morning, so I was able to get them out of the way and avoid the rush for printers and binding machines.

That’s two projects down (the other was a fairly tedious business module).  I have a presentation to give on Friday which should hopefully finish off the research. Following this, I have just the one exam on 21st May – plenty of time to brush up on the subject.

I have applied for two PhD positions; hopefully I will continue to call myself a student come September.

University, life Project, University

“Beware the IDEs of March” — Julius Caesar

My software engineering professor enjoys a joke at my expense when it comes to opinions about development. We frequently end up in informal discussions about Software Engineering practice and a subject that crops up a lot is whether or not to use an IDE (integrated Development Environment) such as Eclipse or Netbeans. Using an IDE does provide some merit, especially if it offers levels of collaboration, code management and updating that would be beneficial in a team scenario. However, the drawback I see from most IDEs is the amount of fluff I don’t need which insists on being there anyway. Sometimes I struggle to find my code behind all that UI.

Our conversation jumps back and forth between features such as code sense and inline documentation and he will make the case for refactoring tools ensuring that code is clean and he will readily admit that IDEs are fairly bulky but in the long run, text editors and command lines just don’t cut it for large projects. I don’t disagree (the aforementioned tools are very useful), but he has yet to convince me that a minimal environment cannot provide the features of an IDE. The other plus of a minimal environment is that resource use will be much lower- nothing will be running by default, it will respond to the programmers requests to do things.

My point is, while access to versioning systems, debugging, inline documentation, re-factoring and code sense are all very attractive features, I don’t need them all the time. IDEs rarely provide the ability to turn off those less frequently used features.

To make a case against IDEs I wish to propose a reasonably scalable command line based process (based on and extending the way I have been working on my own individual projects). In order to make an effective counter argument I need to address some of those ‘essential features’ of an IDE.

Pros for using an IDE (in no particular order):

1. Debugging
2. Source file navigation
3. compiles, links and runs at a keypress
4. auto-completion (codesense)
5. inline documentation
6. coding standards enforced
7. re-factoring facilities
8. trivial code generation (get/set)
9. Source control

In a series of posts I will outline (and refine) the way I work ensuring that I can effectively and elegantly satisfy the features given above. I intend to introduce the tools I use for editing code and testing and probably a few scripts to automate the tedious tasks. I work on OS X but expect this system will easily port to Linux or another UNIX based system running bash. I won’t explicitly guarantee success in using this on Windows but if you grab a copy of some UNIX command line tools I don’t see a serious problem.

Initially Expected Topics (which I’ll order according to complexity/work required to implement):

1. Setup and program execution
2. Source Editor
3. Debugger
4. Extracting Documentation
5. Source Control
6. Trivial Code Generation & Standards
7. Auto-Completion
8. Re-factoring

Computers, Development, Development Environment, Geek Programming, Project, unix