Question For Mike: I Finally Thought of One

[Gregg Bolinger]

I finally thought of a question that hasn't already been asked.

I do a tad bit of development where I work but I am the lone gun. I have recently built a CVS Server and a Web Testing Server using Tomcat. Before, I just tested everything on my workstation with a local install of Tomcat and no CVS. I was just doing manual backups every now and then.

I am wondering if your book benefits those few of use having the luxury (relatively speaking) of working alone on projects? Or is directed more at those working in multi-developer projects?

And on a side but related note - How important is project automation and the information in your book in my situation?

Thanks.

[Bear Bibeault]

And a very good question Gregg. And one thay could benefit me as well.

By day, I'm a lead architect on a large financial sector web application with a team of about a dozen developers and half a dozen QA staff. (Tools: Ant, Perforce, DEVOS: Linux)

By night, I am (like Gregg) Mr. Sole Developer on various web projects that I develop and maintain for a small client base. (Tools: Ant, CVS, DEVOS: Mac OS X).

How do the techniques differ for these two very disparate environments?
[ September 22, 2004: Message edited by: Bear Bibeault ]

[Ilja Preuss]

Well, I'd think that when working alone, you probably don't necessarily need a continuous build server like Cruise Control.

But besides that - why would you *not* want to automate everything you can???

[Mike Clark]

Indeed, it's a great question.

Although the Scheduled Build chapter focuses on continuous integration for multi-person teams, the spirit of the book is focused on using automation to save time and money, improve accuracy, and ensure repeatability of project chores. As a result, more of your time is freed up to do exciting and challenging stuff. And if you're the only person on a project, then your time is at a premium. You can only scale so far with one person, so to do more work you have to look to offload some of the automatable chores onto the computers around you. That's what the book is really all about -- putting computers to work doing what they're good at so we have more time to do what we're good at.

I think you'd get a lot out of the Monitoring chapter, for example. It offers various techniques to put computers to work watching your back. More important, readers have commented that reading the book in general gave them ideas for other things that could be automated. So although you may not use all the techniques in the book, I think it will give you insights into ways to tailor the automation to your project.

I hope that helps. I'd love to hear what readers of the book might have to say on this topic.

Mike

[Bear Bibeault]

put computers to work watching your back

For my home business this is one aspect that I find particularly intriguing. While I'm at my "real job", I can't be constantly monitoring the various web apps and have to rely on clients reporting problems. Granted, such occasions have been few (small self-pat on the back there) but I know I'd breath easier knowing something was looking out for me -- especially after a new version has been pushed out.

How suitable are such monitoring techniques to Servlet-based web applications?

[Gregg Bolinger]

Thanks Mike. Typically, the old saying "If it ain't broke, don't fix it" is something most developers probably try and adhere. At least I do. But I am also one that loves to try new and exciting things. I have the advantage of being the only developer in this situation which means I don't have to sell and idea to anyone else. If I want to try it, I just try it.

What I worry about sometimes though is the pitfalls associated with trying to implemenet new things. Including project automation. I worry about putting too much effort into trying to automate something that was working perfectly well the day before. Does your book cover any of these pitfalls and/or discuss when automation is good and when it might be overkill?

[Mike Clark]

Originally posted by Bear Bibeault:

How suitable are such monitoring techniques to Servlet-based web applications?

I find simple screen-scapers to work well for monitoring web applications. I give an example shell script in the Monitoring chapter that checks a dynamic web page to see if it's available or it's showing an error message. If things have gone bad, it sends a message to your cell phone. You can do a lot of automation with this simple technique.

If monitoring your web app requires drilling into pages and such, you can automate it with a Java program that uses HttpUnit to traverse HTML pages, push buttons, and the like. Or, for a bit more fun and adventure if you're on a Windows box, you can programmatically drive IE with Ruby:

http://www.rubygarden.org/ruby?IeController

Mike

[Bear Bibeault]

if you're on a Windows box

Nope, OS X. Maybe there's a bunch of AppleScript in my future!

[Mike Clark]

Originally posted by Gregg Bolinger:
Does your book cover any of these pitfalls and/or discuss when automation is good and when it might be overkill?

I agree that you can go overboard with automation. Knowing when to stop is just as important, if not more important, as knowing when to start.

In the book, I recommend that automation is best used when you've grown tired of doing something manually. Errors naturally follow from boredom. So if a project procedure needs to be done correctly each time, it's best to codify the steps in a repeatable format, such as a script. Then, of course, the script needs to be tested because this silly computer has no idea whether the automation is correct or not.

I also use automation to keep a check on procedures that I'm likely to forget, or just don't want to have to remember. For example, if it's important to fix a web site as soon as it crashes, then I'd like the computer to watch it for me so that I don't spend my days being a slave to the site.

Finally, don't spend more time developing an automated solution than the time the solution will ultimately save. That's just being pragmatic. :-)

Mike

[Mike Clark]

Originally posted by Bear Bibeault:
Nope, OS X.

Me too! Although I've yet to fully wrap my head around AppleScript, it's intended to be a language for automation, as far as I can tell. Automator, coming in the Tiger release, pushes it to the next level. Good stuff there!

Mike

[Bear Bibeault]

I've yet to fully wrap my head around AppleScript

Same here. I know it's something I should grok to make my life simpler, but haven't had the time to really delve into it -- though I tend to prefer cross-platform tools (something the UNIX roots of OS X makes SO easy) since at "the day job" I use Linux and Windows (just can't convince the boss that I need a G5).

So I tend to do a lot of shell scripting instead, but that doesn't help automate the GUI tools.

Definitely looking forward to Automator.
[ September 22, 2004: Message edited by: Bear Bibeault ]