mx is currently certified at Journeyer level.

Name: Bruce Alderson
Member since: 2001-01-12 04:46:48
Last Login: 2007-04-03 03:26:04

FOAF RDF Share This

Homepage: http://warpedvisions.org

Notes:

  • IT Manager and Co-Architect at a local Educational s/w company
  • Perl is for hacking, Php for templates, Python is fun too
  • C/C++, driver development, and bad-assed back-end server s/w forms the bulk of my dev time
  • My roots are in Atari game hacking, my favorite geek memory (despite the fact that Commodores and Apples were really better)
  • Alton Brown, and his food-hacking ethic are way too cool
  • Devs need to learn how to write better, and places like Advocato are on that path

Projects

Recent blog entries by mx

Syndication: RSS 2.0

It's been a while since I sneezed here, almost a year! I guess I'm not the diary sort anymore. I write a few articles these days, between managing a small development team in Canuckia. A few recent musings:

Now I know that OO and FC aren't perfect, but I am really enjoying them on a daily basis. I read a rebuttle of OO performance recently, but really haven't seen that sort of madness with my deskop. OO isn't perfect, but it's damned reasonable (and better than Office in at least a few ways). I'm glad, at least, at the abundance of good, liberated wares.

Cold - Canada is cold today -- all of it. Damned cold!
6 Oct 2004 (updated 6 Oct 2004 at 20:08 UTC) »
Heavy requirements suck - I figured out last month that software development processes are a tool for managing the business of building software. Processes should really be orthogonal to the act of envisioning and crafting software, as when processes are coupled to the act of building software they trip up the focus on the end goal -- that of building quality software. Not that process themselves are bad, but they are an unbearable burden when tightly-coupled or overweight. In fact, a heavy set of processes attached to a software project will result in bad software, and likely project failure.

The problem is that the business of developing software is difficult. Processes are applied to mitigate the various risks, with the goal of optimizing the business and controlling various software qualities. The business of making software a business, though, makes it difficult to make the software itself (it gets in the way, obscuring the goal). This of course requires a careful balance between being a business and making software.

The concept of agile development is to decouple the process as much as possible. Use the good bits, but allow the crafting of the software to be done with minimal impediments. Agile development, and orthogonal processes require that the business can trust those crafting the software.

I think this makes the prospect of outsourcing development more difficult, as trust is harder to find. Interfacing two companies usually requires a great deal of business process, in addition to any mechanisms required to interface disparit software teams and product thinkers. All that process tends to get tangled into the craft of building things, to the point that software products become the output of the process.

It is a terrible thing for software, when it becomes the bastard child of business concerns. Applying techniques that are focused on business ideals, like symetrical decomposition (which makes traceability easier), makes it dificult to see the how particular features are meaningful to the end vision. In fact, the vision is usually lost in the retarded depths of detail.

Software development is complicated, and records of domain (and design) decomposition are useful -- but these things need to reflect the vision and passion of the application concept. Decomposing a problem using a process like the Unified Rational Process results in thousands of artifacts that all look the same. Any concept of importance is lost, passion is whitewashed away, and vision is lost.

There needs to be some balance towards making a good product, rather than meeting the busiess need of completing every point of decomposition (to prove completeness of a phase of a project). The whole point of decomposition is so that you can recompose the ideas into something that resembles the initial concept, so the further away from the idea the decomposition brings you, the more work you need to do to get back to it.

This is one of the reasons that the approach of Open Source Software is so productive: business concerns are removed from development. Many OSS projects apply various processes to their efforts, but they're generally agile, and used to improve various aspects of what they do ... and aren't often heavy.

Why I Hate US Politics

  1. A country is *much* more than its economy and collective greed
  2. A country is more than its liberations, war crimes, and power-mongering
  3. A country is more than its rich, corrupt, greedy elite
  4. A country is more than its sometimes-deserved scars
  5. One country is no more important than another (or all others combined)

I wish I wasn't such an optimist.

I don't write often enough, either here or at my always-in-development weblog. Maybe if I finish the software behind it, I'll write more often ;-)

Outsourced Hardware - More failures at work, this time with our main UPS. It has a dead cell, which will likely cost us over $1k CAD (arg). At least we know now what was causing the server reboots. It took a week of weird failures for us to catch it, as the UPS wasn't logging the problems.

So we're looking seriously at outsourcing our hardware. Not our IT, of course, but we're looking to rent rackspace and hardware somewhere (like at dreamhost or rackspace) ... as our fleet is aging, and we're more interested in writing great software.

Hardware/hosting has become a commodity, and the companies that are good at it are *really* good. I've worked with one host for 5+ years now, and they've got their stuff together, and they understand how it works. Our own IT guys will take years to get where most good vhost admins are at, in terms of planning hardware/network/configuration stuff.

It helps to work at the larger scale that the vhosts manage ... we only have ~30 servers here (and each running only a few services), which could really be replaced by a fraction of that. Most vhost farms have a dozens servers running thousands of users each ... which requires actually knowing what you're doing, or learning it. I've seen the difference between vhost farms who know their stuff and those who don't (and it ain't pretty).

BenderBlog - I'm getting closer with the current version of bender ... it's running my test site, and I'm hoping to switch it live soon. It won't be complete, of course, but it will do enough on the front-end to allow people to view the weblog, projects, linklog and articles. The back-end will still require some twiddling, but that's ok for now.

The docutils-style parser (magicmarkup) is coming along well too, and is part of the bender prototype. I ended up with a data-driven recursive-decent parser, despite aiming for something a lot simpler. The parser needed the context and depth (in the dom) to properly represent various types documents.

The data-drive part was fun too, and a future version will be able to load parts of it's parse tree on-demand (startup, or based on special document parts). This will allow the parser to be trained and customized on the fly, something that a lot of the plain-text -> formatted output parsers seem to miss. I'm hoping to support html, xml (for rss), and ps (or latex) for the first version. So far it's limited to html though.

The html renderer for magic-markup is hacked, but it is almost complete enough to use ... except for the special blocks (like meta data). I'll have to add a layer to the dom to handle meta-data, and document sections better (like comments, notes, etc.). Maybe on the weekend.

Hack, slash, refactor - Prototyping complete, working systems, based on first-order design is my current-favorite approach. Documenting a pass of requirements, decomposing the architectre/design (focus on capacity), and prototyping the initial design gives you something to prove a system. It validates requirements, design, capacity and architectural problems, and it makes it easier to complete remaining requirements/design. And, it results in something you can use.

78 older entries...

 

mx certified others as follows:

  • mx certified mx as Apprentice
  • mx certified i0lanthe as Apprentice
  • mx certified hadess as Journeyer

Others have certified mx as follows:

  • mx certified mx as Apprentice
  • i0lanthe certified mx as Apprentice
  • lerdsuwa certified mx as Apprentice
  • fxn certified mx as Apprentice
  • sdodji certified mx as Apprentice
  • beppu certified mx as Journeyer
  • sand certified mx as Journeyer
  • jhermann certified mx as Apprentice
  • ade certified mx as Apprentice
  • juancpaz certified mx as Journeyer
  • wspace certified mx as Apprentice
  • izham certified mx as Apprentice

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page