Jon Galloway : //TODONT:

//TODONT: Use a Windows Service just to run a scheduled process

Jon Galloway — Mon, 24 Oct 2005 22:42:00 GMT

A common requirement in business application is a scheduled process - call a webservice, process the data, and FTP the results to a business partner, for instance. Developers kick around possible solutions - BizTalk's overkill, DTS won't handle it well, what to do?

Invariably, someone suggests a Windows Service with a timer. Just as invariably, when you try to talk them out of it, they'll condescendingly tell you that Windows Services are easy to write in .NET. "Trust me, it's not hard - we'll write a simple service with a timer which will do a simple time check..."

A Windows Service is the wrong solution to scheduling one-off custom processes. The right solution for scheduling simple processes is the Windows Task Scheduler.

Let's look at what Windows Services are designed for. From the Windows Help documentation:

Service

A program, routine, or process that performs a specific system function to support other programs, particularly at a low (close to the hardware) level. When services are provided over a network, they can be published in Active Directory, facilitating service-centric administration and usage. Some examples of services are the Security Accounts Manager service, File Replication service, and Routing and Remote Access service.

Web servers qualify as services, databases qualify as services, and the above Windows system features qualify as services. The Task Scheduler qualifies as a service. Possibly, custom server applications may qualify as a service if it needs to run round the clock and is written with the greatest sobriety, responsibility, and respect. Your scheduled file FTP doesn't qualify as a service.

A Windows Service which runs a timer needs to run Automatically, which means it will start up before you can log onto the machine and churn away until the machine is shut down. If they hang or have a slow memory leak, they'll continue to be a drag on the system until the service is restarted (or they crash the machine). I can't tell how many times I've heard the following in production meetings: "The cause of the outage was the WhamoInhouse Service. The resolution was to restart the service." Or, worse, application servers need to be restarted regularly because they're hosting poorly written services, but the IT shop blames the operating system.

Windows Services do offer sophisticated Recovery actions (on first, second, and subsequent failures you can specify that a program to be executed, or that the service or computer be restarted), but they're geared towards hard failures of the executable rather than business process failures, and they don't respond to things like memory leaks or hanging network connections. They offer absolutely no scheduling, because services are designed to run all the time. On the other hand, Windows Scheduled Tasks have advanced scheduling features which can be accessed administratively. If the business requirements for my scheduled FTP task change two years down the road so the FTP should happen twice a day every Monday, Wednesday, and Friday, the change can be made by an administrator. The task schedule has been tested across leap years, daylight savings time, and clock changes; most custom timer routines I've seen haven't.

Scheduled console applications are easier to design, build, test, deploy, and install - especially compared to a professional service which can run reliably for weeks end. This wouldn't by itself be a compelling argument if a Windows Service were the right solution by other criteria, but since it's not, this is another nail in the coffin. Consider, then, that your extra time spent building a service is wasted development time. Maybe fun "I am a bigtime coder now" development time, but not of any business value.

Scheduled console applications are easier to run in an ad hoc manner when necessary. Let's say the webservice vendor calls three hours after our process ran to inform us that he had a data corruption problem which has been corrected and we should re-run our process. In the case of a Windows Service with a timer, we'd be scratching our heads; with our console application we can run it manually whenever we want.

Finally, running separate Windows Services with their own timers is just plain inefficient with server resources. Ignore for the second the fact that we're hogging CPU and memory space 24/7 for a process that runs occasionally; multiple independant timers which check the time every few seconds is dumb.

If I kept writing Windows Services with timers, eventually I'd start to think about writing a single host system with a timer. Then I'd want to add in some more advanced scheduling features; perhaps even some logging. Eventually, I'd have a Windows Service that handles scheduling of child processes, and if I devoted years to enhancements and testing, I'd eventually arrive at... the Windows Task Scheduler.

If you're writing a Windows Service that runs a timer, you should re-evaluate your solution.

isIE=document.all; //only kind of true

Jon Galloway — Sun, 07 Aug 2005 12:23:00 GMT

Internet Explorer 4 used document.all['elementName'] to refer to document elements while waiting for the W3C standard, which turned out to be document.getElementById('elementName'). IE 5 and above, plus all other modern standards based browsers, all support document.getElementByID(). IE 4 usage was below .5% in 2002 and isn't even being tracked anymore, so there's no good reason to be using document.all anymore.

Firefox developers decided to partially support this non-standard syntax since so many pages are still using it. It was probably a good decision - if they didn't, people would decide that Firefox was no good since it couldn't run their favorite pages, even though real problem was buggy webpages.

On the other hand, they didn't want to encourage use of non-standards compliant code, and they certainly didn't want to break all those poorly written scripts that (incorrectly) assumed the following:
isIE=document.all;

So Firefox supports document.all, but says it doesn't. That means it can evaluate document.all['elementName'], but alert(document.all) shows false.

This behavior makes some sense, but can result in some weird behavior. Scripts that were written for IE only (using document.all[] syntax) will work in Firefox, but scripts which test for IE with document.all but don't include proper handling for non-IE browsers don't work.

There are some much better solutions to the document.all mess:

1. Obviously, the best is to convert from document.all[] to document.getElementById(). It's standards compliant, works in 99+% of browsers, has a great beat, and is easy to dance to. Usually it's a simple find / replace exercise. However, it's sometimes not practical when you've got legacy scripts or browsers to deal with.

2. If you have to support IE 4 David Emmerson came up with a great work-around: add document.getElementById support to IE4 with this little script:

if(document.all && !document.getElementById) {
    document.getElementById = function(id) {
         return document.all[id];
    }
}

3. If you absolutely have to write browser dependant code, use a decent browser detection script. This one is pretty solid: http://webreference.com/tools/browser/javascript.html

The best general approach is to check for support of a feature rather than to sniff IE and apply IE / non-IE logic. If you need to determine if you're looking at IE, you can just ask nicely (does navigator.appName = 'MSIE'?).

Of course, cross browser Javascript is a complex subject. Here are some good references:
http://www.stopbadtherapy.com/standards.shtml
http://www-128.ibm.com/developerworks/web/library/wa-ie2mozgd/ powered by IMHO 1.2

Joel got it wrong - Why learning C is a waste of your college time and money

Jon Galloway — Wed, 16 Feb 2005 15:47:00 GMT

Back in January, Joel Spoelsky wrote a Career Advice column. It gave some generally good advice to college students, the main points being:

Learn how to write before graduating.
Learn C before graduating.
Learn microeconomics before graduating.
Don't blow off non-CS classes just because they're boring.
Take programming-intensive courses.
Stop worrying about all the jobs going to India.
No matter what you do, get a good summer internship.

[update: note that Joel's advice is to college students in general, not just to computer science majors]

I agreed with everything but (2). I believe learning C before graduating may help some, but hurt just as many. While it might have helped Joel, I don't think it's universally good advice. It's been bugging me for a month now, so it's time to get it in writing. In the interest of hopefully getting comments from someone other than my pals at www.online-cheap-meds-4u.ru and www.poker-gambling-casino.net , I aim for the nearest windmill and present:

Jon's 6 reasons why learing C is a waste of your college time and money:

It's not a skill you'll use in most of the software development jobs you'd want to have

It can give you a false sense of control

It can teach you to get in the way

It can make it hard for you to love famework based development

It can teach you philosophies which will prevent you from really understanding modern programming

It can teach you divert your problems from the real challenges of software engineering

1. It's not a skill you'll use in most of the software development jobs you'd want to have

Without trying to offend anyone who's into this kind of stuff (weirdos!), here are the kind of things you might use C for these days - writing some kind of device driver, maintaining extremely old applications, embeded development on very limited hardware, or maybe writing an operating system or compiler or something. I guess you could like hack away on the Linux (or is that GNU-Linux) kernel.

Hey, if that sounds fun then off to the races. Consider this though - you're not really going to be solving any new problems. If you want to do web development, database development, desktop applications - you know, stuff you can talk about at a party - you're probably not going to be working in C.

2. It can give you a false sense of control

Quote from Joel's article:

I don't care how much you know about continuations and closures and exception handling: if you can't explain why while (*s++ = *t++); copies a string, or if that isn't the most natural thing in the world to you, well, you're programming based on superstition, as far as I'm concerned: a medical doctor who doesn't know basic anatomy, passing out prescriptions based on what the pharma sales babe said would work.

That sounds good on the surface, but does his code sample really tell you how the string is being copied? It's a symbolic representation of a process which is moving memory, sure, but still several levels of abstraction away from shuttling the bits through memory. Why is this the magic level of abstraction that gives you the edge? Why not assembler?

Worse still is that it can make you think that programming is about telling the computer what to do with its registers and memory. Oops, wait, that memory was magically paged from disk without your knowlege. The compiler applied some optimizations behind your back. Your code is running on top of an operating system, which is rationing out the CPU cycles between tens of processes, and yours gets a measly 10% timeslice. And, hey, what CPU are you on? Any sneaky little tricks going on with your 64 bit hyperthreaded chip? What about two years from now, when you run your app on a virtual server on a multicore chip?

Thinking that you're in the pilot's seat because you're handling pointers is silly. Better to understand that you're asking the CPU(s), through multiple levels of abstraction, to copy a string. Do it politely - this ain't no rowboat anymore, it's a durned space ship.

3. It can teach you to get in the way

That false sense of control I mentioned before can lead to outsmarting yourself. Some examples:

Trying to pool database connections or holding a global connection, not knowing that the data layer is automatically pooling if you let it

Overriding the .NET Garbage Collector, assuming that Java / Micro$oft doesn't know how to manage memory nearly as well as you can

In both these cases, a little bit of knowledge is (as rumored) a dangerous thing. If all you learned from C is that you are the boss, you will most certainly write code that plays poorly with others.

4. It can make it hard for you to love framework based development

Moderns programming languages run on top of frameworks. .NET apps use the .NET framework, Java uses J2EE (et. al.), and arguably web apps run on top of a browser / communication communication that constitutes an application framework. The list could go on (GTK, XUL, web service, Flash). Most good frameworks are standards based, and all of them host your solutions so you only solve new problems.

C code, by and large, is not about frameworks. At its best, it uses some libraries and links to some API's. C gives you a toolset that can solve just about any problem, but requires that you solve each and every problem every time. Frameworks were created to obviate solving the same problems in each program you write. Software development has made a steady progression from code to libraries to components to frameworks. Thankfully, you don't need to retrace this path just as you don't need to experience the dark ages to live in the post-renaissance world.

To be productive as a programmer these days, you either need to be learning to get the most out of existing frameworks or helping to build tomorrow's frameworks. To learn to be a productive programmer, you need to learn how to work with frameworks.

Learning to work with a framework takes work. You need to learn research skills that go far beyond fixing syntax errors. You need to learn how to optimally integrate with our environment, what the environment will provide for you, and what's expected of you.

Thankfully, learning to work with a framework is a transferable skill, so the exact framework doesn't matter so much as that you learn how to use a framework - pick an environment and get going.

5. It can teach you philosophies which will prevent you from really understanding modern programming

C code is procedural. That means you describe an exact set of steps you want your program to accomplish. If you want to find a value in an array, you write code that loops through each element in the array - a house to house search.

Modern programming is often declarative, meaning that you describe what you want and thing else decides the best way to get it. Databases, for instance, respond to "Queries" - a request for information in a descriptive language. The database maintains indexes to find the data without looking at every line, and the good databases self-optimize based on the questions they're asked most often. To continue the analogy from before, we replace the house to house search with a 411 call. Cursors in database queries are just about always a failure on the programmer's part to describe the problem rather than limitations of the database engines.

A surprising amount of work in current software is described rather than prescribed. HTML, for instance is a markup language that describes content and layout to a browser, which does the hard work of wrapping text, applying styles and enforcing user-defined security settings. XPath and regular expressions some more current technologies which implement declarative programming.

The point here is that modern programming is moving towards Domain Specific Languages (DSL's) which efficiently communicate programmer intent to CPU cycles. C is not a good prototype for any of these DSL's.

6. It can teach you divert your problems from the real challenges of software engineering

There is significant work to be done today in software engineering that requires fresh, energetic minds. Some examples:

We are on the verge of ubiquitous AI - self organizing systems (software and hardware) that will collaboratively solve problems for us. We're still figuring out how to manage them.

We've got a lot of disparate systems that still don't communicate well.

We are being bombarded by more information than we can currently process. Fixing the U.S. intelligence system to the point that pre-9/11 dots could have been connected requires storage and analysis of 36 Terrabytes per week ongoing (quote from recent IT Conversations - Accelerating Change audiocast). RSS and e-mail volume continue to grow.

Computer users need both security and privacy. Neither is relible today.

Our current methodologies routinely result in failed projects. (Examples - recent failed $170B FBI project, Mars mission software errors, etc.)

Bob in accounting needs a report on recent payment orders to office supply companies, but the data is stored in Excel files on Mary's desktop. Mary is on vacation.

Walt in IT just gave two weeks notice. He justtold you that he's been managing several daily FTP transfers of critical company data. He manually inserts into the production database using some scripts his roommate helped him figure out.

Marketing promised product X by June. Management budgeted for product .25X by June 2025. You are the developer for product X.

Etc.

The point is, today's software development environment is dynamic, evolving, and extremely challenging. If you're going to be of help, you need to do something more productive with your time than learn a 20 year old language. There's plenty to learn - if you're going to take one computer class, make it HTML, Java, C#, VB, SQL, XML, Javascript... anything but C! I've personally interviewed over 100 people for programming positions. I would personally take skills in any of the above technologies over C in my hiring decisions.

Epilogue

In the movie Real Women Have Curves, the main character is a Mexican American girl who's been offered a full scholarship to Columbia. Her mother won't let her accept, giving some bogus reasons about needing to stay near her family. When her father challenges it, she tells him the real reason: she's had to work in a sweatshop her whole life to provide for the family, and there's no way her daughter is going to skate from school to college to the easy life without some time in the sweatshops. It's her turn to work.

When an experienced programmer tells you to learn C nowdays, they're either trying to apply their out of context life experiences to yours, or they're trying to throw you in the sweatshop because that's what they had to do.

There's plenty to learn in computer science circa 2005. Don't waste your time on history unless you want to be a historian.