Actually, the manufacturer has some ways of making money off a used car. Service and parts.
Possibly, but not necessarily. Do you take your car to the dealership for service after the warranty expires? Even then, the manufacturer isn't getting money because you chose their dealership. The simply get dealerships with more resources for supporting their warranties.
And again, unless you are going to a dealership you probably are not buying parts from the manufacturer. You're buying from the OE supplier.
And what have all these wonderful shuttle missions brought the general public?
I'm not sure how you isolate the benefits of just the shuttle program. For NASA in general, there are a lot of spin off technologies that we might not have if it weren't for NASA's need to overcome a space related problem.
DS9 is the Star Trek with the most unrealized potential. The concept worked, just look at B5. Unforntunately, after the first season or two the only thing it excelled in is working faster than Ambien.
Voyager wins the prize for being lamest. That's why they brought in 7of9, the show needed something to make it interesting. (and yes, I hated Janeway)
Surely thats a bug. We can't edit comments posted.
Good, I despise those boards where people come back and edit their posts. It ruins the thread. They'll post something, get responses to it, then go back and edit it. Then all the responses don't make sense.
We've got this nice preview feature. If you don't use it, you should have to live with your mistakes.
I picked up a new (but old stock) APC 2000 a few years ago, and tried this solution until the batteries died. When it came time to replace them, I found it was much cheaper to just buy APC 1000s for each machine I wanted to stay up. My server will run for ~45+ minutes on it's UPS, and having a smaller (%) load on the system makes the batteries last longer. I ran the 2000 for a year with no problem, but by the end of 2 years the batteries were useless. I've been running the 1000 with my server for well over a year and no sign of losing capacity. For longer outages I bought a 5k generator, but since I bought it the longest outage has been 2 hours. Maybe it will work like insurance and I'll never need it.
One thing I would recommend, if you have the capability to do it, is run a separate circuit for your office. I did that when I replaced my service panel and haven't regretted it once.
As for the complexity of the business rules, EDI has got to have the simplest set of business rules ever created.
Well, I'm not going to argue with you. I work and consult with the programmers who write the code for our EDI every day. We are in the middle of a migration from an VMS system to Axapta, so all of our EDI work is being redone. Despite the fact that we use Gentran for the actual packaging and transmission.
Here are some examples that you might run into: a 210 for Yellow Freight may not work as a 210 for USF. You can properly format an 810 (invoice), but still have it kick out of your customer's system. Which means you don't get paid. Does your customer want your part number on the 810 or their own? Some customers are going to send an 850 (PO) and 830(s), some will just send an 850. BTW, an 830 can change order qtys and ship dates. One very important business rule cannot be part of a canned EDI system, what is the freeze period on order changes. Again, your part number or your customers? Each individual customer decides if they want 862s (ship schedule) and 856s (ASN). Does the customer require their ASN to be sorted by po/line item, part number, or container id? Do they just require equipment numbers or container details? Does your customer require consolidated shipments or must they be kept separate?
You can write your EDI 100%, to the spec, but if it kicks out of GM's system it's worthless. You fix it to match their system or you don't do business with them. The realities of business are; you can tell your vendors they aren't following the specs, but the customers' system is never wrong, it's your reference platform.
BTW, using the term lusers shows you have little respect for the people who you are paid to support. You have missed the whole point of your job.
Ok, in this discussion I've learned that what I thought was an old mainframe is really a minicomputer.
To our users, our Alpha VMS machine is still the 'mainframe'. Even though we probably have laptops with more computing power. And our SQL server leaves it in the dust all the way around (memory, CPU, storage). IMO, mainframe has become more about the experience. They don't know the difference, so why confuse them. Just as long as we know.
As far as ripping out legacy, it comes back to 'if it works...' You see an AS/400 as legacy. Someone else might see Netware as legacy, although NDS is just as powerful as ActiveDirectory. Running a windows network without AD? Come out of the dark ages. It would be very easy to churn away your entire budget killing the legacy beast. Fortunately, most businesses won't allocate the money unless there is a measurable benefit to the business. If you're not a technology company, your customers don't care about the shiny kit in your computer room.
But tell me, why are other programmers so scared of a well defined set of business rules, no matter how large it is?
Because rarely are the business rules 'well defined'. Assuming they have ever been written down, the process has probably been changed several times since the documentation has. Recreating the process means reading the documentation, analyzing the existing code, and talking to the stakeholders. You'll probably end up with three different 'rules', and all of them might be wrong.
But lets say you want tackle it anyway, and you get the $$ allocated. If the stakeholders don't currently see the process as broken, your best result is going to be it does the same thing the old system did. Sure, it might be faster, have new features, and be extendable. But they weren't asking for that. The risks OTOH are that you could break it, your new system might not work or not work right.
Most of us have plenty of other work to do without tackling projects no one wants. That means when you need to add non-core functionality, like EDI, changing the existing system isn't your first choice. Can you buy a package the integrates with your current system? Can you buy a package that bolts on the outside? Can you write mods for the current system? Can you write a package that will bolt on to the current system?
No, the point is that it's not a hardware issue. It can be done on AS/400, it can be done on VMS, it can be done on windows, and I would assume that it can be done on Linux.
It's like someone asking you how to do a mail merge, and you telling them to rip out MSOffice and Windows and install Linux and OpenOffice.
And no, it's not 'drop dead simple' to go from SQL to x12 EDI. Because there are going to be a lot of business rules in there. Most EDI is legacy, and companies are not using XML yet.
I don't rely on Debian's classification to decide what packages I'm going to install on my servers. I don't do dist-upgrade. If I'm worried about a security update, I'll do that package individually.
I actually run my systems at 'testing'. And occasionally pull some unstable packages. Personally, Apt is why I run Debian. But Apt needs a little work. For instance, if you get Apache, you will get the Apache 1 (which is what I wanted). But if you do an 'apt-get install apache', there is no where to tell what version you are getting. And there is no Apache1 to match Apache2. PHP; there is a PHP4 and a PHP5. PHP5 requires Apache2. In cases like that where it doesn't matter, why not have Apache1 and Apache2 and have them both set the Apache dependency. Then PHP5 could depend on simply Apache. Mysql... If you apt-get Mysql-server you get everything for version 4. But you can't 'apt-get install mysql', there is no MySQL package. Firefox; remember to get mozilla-firefox.
And my favorite; set unstable and pull KDE. You will get KDE, but no KDM. Although you'll get every kgame ever written. It won't check to see if X is installed. Then you can install xserver-xorg, and when you start it you find that you have no fonts. Where are those dependencies?
I don't know, it just seems like there should be packages for common names; apache, samba, php, mysql, etc that would get you the version for the environment you use. But you should be able to simply 'apt-get install kde34' from stable and expect a package.
BTW, one little gotcha from the DCC install. The only thing in sources.list is the CD. Personally, I'd like to see some real repositories in there that I could just uncomment. And the installer, which I suspect is Debians, is primitive.
Now, back to the stable thing... Until just a few months ago (June), Woody was the stable release. Woody was released in July 2002. Up until June, someone considering Debian would see that and think, "this distro is OLD". And everything in the descriptions of testing and unstable lead people to stay away from them if they aren't well versed in Debian speak.
I think with Linux distros it's going to come down to two things. How good is your installer, and how complete is your repository.
Or, they could install a cheap Intel server and run something like Gentran to handle the actual EDI. This lets you map EDI data to file formats that your existing software can import/export.
Regardless, unless you find a package that handles EDI and communicates directly to the software you already run (which is rare), there is still going to be time required to learn how to create the proper maps. And if you deal with any large companies, you will find that many use their own 'flavor' of certain datasets.
Ok, this REALLY should have been one for google- even I admit that and I'm usually on the other side. Just how many hackers on slashdot do you think have even messed with EDI?
There are a few of us. Actually probably quite a lot of us.
Still, given IBM's movement to bladeservers,
Obviously you haven't, EDI is not about hardware. You should have googled too....
Simply put, EDI is a set off transactions for communicating B2B. (Business to Business) Electronic orders, invoices, advanced ship notices (ASN), electronic Bills of Lading. They are flat text files with tokens (slashdotters will love that, it sounds like a config file).
The problem with Debian stable is that it went so long in between releases that it has a reputation of being out of date. Everyone I know running Debian (or one of it's children) is running either testing or unstable. Of course, they would probably stick with stable if it was easier to pull specific packages out of testing/unstable while maintaining Apt at stable.
And I looked at Ubuntu, but noticed that there were Ubuntu specific versions of packages. I got sick of that years ago with RedHat and Mandrake. If DCC, or any of these derivative distros, wants to make a real difference, they need to push their fixes back up to Debian rather than creating new packages.
(for example, we spent our first two years working with C, and we never even touched the new.Net stuff)
I'm not sure you've missed much. I remember when Java was going to rule the world. Write once, run everywhere. Right? And how many years has the largest software company in the world been pushing.NET? Get a cheap/free version of Visual Studio and learn it yourself. The odds are much better that you're going to start out maintaining older source than.NET development anyway.
For a major like computer science, colleges need to hire more people who've actually held jobs in the industry.
Absolutely. Over the years I have taken courses at a technical school, community college, two colleges (both now universities), and a university. And those part time instructors teaching night courses at the community college are some of the best I have had. OTOH, I've had some PHD instructors I wouldn't trust to write Hello World. My C Instructor (PHD, department head) at the first university I attended used cobol as a reference to explain C memory allocation and started every program 'while (1 == 1)'.
Which is fastest for comparing two strings (ignoring case):
Guess what, it probably doesn't matter. A recent experience as an example; with a new ERP system we are implementing we were experiencing excessive times during invoice batch runs. We suspected table locks. It turns out that it was doing a credit check whenever it created an invoice. In the base system it didn't seem to be a problem, but once we added our additional rules it became one. It turns out that the system checked a customer's credit balances when an order was entered, when the picking ticket was printed, when the packing slip was printed, and when the invoice was created. Not only was that causing a locking problem when more than one process was running, but there is absolutely no reason for us to check credit during invoicing. The order has already shipped, a credit hold would mean that we had shipped product but couldn't bill for it. Moving the credit check knocked 75% off of the invoicing time. There are hundreds of other things we would look at in the system design before we'd care about about which compare is more efficient.
Some people sugggested MIS as a better academic path for programmer. I don't know. At my University, the MIS curriculum involve a lot of business bullshit such as marketing or finance. I know these are good to know from the organizational point-of-view, but if you expect to produce decent programmers, you need to keep some focus.
It depends a lot on what type of job you are looking for. I would guess that the majority of programming jobs are for managing in-house applications. Companies writing software to manage their own business. In those jobs, it's just as important to understand the business as it is to know how to write a program. Maybe more so, since advancement above a certain level will generally be into management.
In various classes over the years, I have taken Cobol, RPG II, Assembler (s360), BASIC, C, C++, and Java. And over my career I've mostly worked in Delphi. OTOH, everything I learned in accounting and economics applies pretty much the same today as it did 20 years ago. With computer curriculums you have to be careful and make sure you are focusing on teaching how to be a programmer and not how to use a particular language. That's why classes should focus on data structures and SDLC. And sadly, proper GUI design is nearly universally ignored.
You missed an important step. Under Windows I've always had to set old-passwords in MySQL's INI file to get it to work with PHP. And you should do it before you set your root password in MySQL. I always wait just long enough between installs to forget that.
It's can be a real problem to set up Apache on Windows.
Actually, with the current installer, installing Apache on Windows is brain dead easy. Getting MySQL (4.1) running under windows isn't rocket science, but getting PHP (5) to talk to MySQL in that environment is a pain the first time or two.
But why would you go all windows with the OS if you didn't intend on using IIS?
Why does using Windows necessitate IIS? If Windows and Apache is a problem, please don't tell my systems. My Windows/Apache/SOAP CGI/MSSQL have been running flawlessly for years. I'd hate to think they're incompatible.
From my experience, Apache's 'experimental' is like Google's 'beta'.
My Mac (mini) drove me nuts. Instead of clicking on the X to exit an app you had to hunt down the Exit command. But of course, that wasn't consistant. I unplugged my mini a month ago, and haven't really had a desire to turn it back on. Instead, I hooked up a cheap terminal and use my debian box. $150 RDP/X term vs $500 mini, accompishing the same thing.
I mentioned this annoyance once before here, and the response was I shouldn't expect the X on the main form to exit the app because it was a Windowsism. Whatever, it doesn't work as expected, and that's the whole thing about HCI. I'll eventually put debian on the mini too.
I not sure what type of content patches you're used to from other games, but the amount of content that has been in the patches thus have have been very large, at least compared to other most other mmorpg patches.
Some of us were spoiled by monthly updates in Asheron's Call. I don't expect to buy the WoW expansion any time soon. But then again, I unsubscribed last spring because I didn't have time to play, and don't plan to restart until around November. Oddly, over the years I maintained two AC accounts, and never unsubscribed until I changed to WoW. A friend tells me he gets bored with WoW. I'm not sure whether his problem is lack of new content or lack of community.
If you feel the need to limit the number of instances running, set focus on the one already running. If that's not a requirement, or the user turns the option off, then launch another instance.
There are legitimate reasons for only wanting one instance running. Some IM networks will drop your existing connection if a new one is connected. I can't think of a reason to run multiple versions of GAIM. I have other apps that don't have a problem running more than one instance, but I would prefer that they didn't because it slows down my system when I accidently click the wrong icon.
Putting everything (by everything I mean business logic) in the DB is the only sane way to keep your data consistent across multiple access methods.
This is certainly true in an environment where there are several developers working on separate projects accessing the same database.
But something I have run into over the last few years with large enterprise applications is that some closed source systems put database rules/constraints in code to lock you into their suite. In many cases you can run queries against the data in the SQL server, but if you wanted to dump your data, for instance to migrate to a new system, you won't know the constraints and triggers to export it properly. And if the database is sufficiently normallized, those details are incredibly important.
One thing I have always hated about Postgres is how it handles case sensitivity. If you're going to be case sensitive, compare it to exactly what I gave you. The user shouldn't have to take extra steps to maintain case. Even better, look at MS-SQL. When you turn off case sensitivity, it actually turns it off.
Or at the very least, if you're going to upper/lower case the SQL statement, do the same thing with the schema and data.
Ok, that's a silly review. For MySQL they claim to be comparing the features of 4.1.x, and yet under features: views, schemas, subselects, stored procedures, triggers - yes (>=5.0)
If they're going to compare releases, compare apples to apples. Either pick stable releases or development releases. And FWIW, nobody that I know personally has been able to get MySQL 5.0 to run reliably, if they can even get it to launch. If we use MySQL for a project, it's 4.1.
Slashdot Mirror
Actually, the manufacturer has some ways of making money off a used car. Service and parts.
Possibly, but not necessarily. Do you take your car to the dealership for service after the warranty expires? Even then, the manufacturer isn't getting money because you chose their dealership. The simply get dealerships with more resources for supporting their warranties.
And again, unless you are going to a dealership you probably are not buying parts from the manufacturer. You're buying from the OE supplier.
Shuttle astronauts did. IIS had nothing to do with it.
That's because it was too busy serving their web pages.
And what have all these wonderful shuttle missions brought the general public?
I'm not sure how you isolate the benefits of just the shuttle program. For NASA in general, there are a lot of spin off technologies that we might not have if it weren't for NASA's need to overcome a space related problem.
DS9 is the Star Trek with the most unrealized potential. The concept worked, just look at B5. Unforntunately, after the first season or two the only thing it excelled in is working faster than Ambien.
Voyager wins the prize for being lamest. That's why they brought in 7of9, the show needed something to make it interesting. (and yes, I hated Janeway)
Surely thats a bug. We can't edit comments posted.
Good, I despise those boards where people come back and edit their posts. It ruins the thread. They'll post something, get responses to it, then go back and edit it. Then all the responses don't make sense.
We've got this nice preview feature. If you don't use it, you should have to live with your mistakes.
I picked up a new (but old stock) APC 2000 a few years ago, and tried this solution until the batteries died. When it came time to replace them, I found it was much cheaper to just buy APC 1000s for each machine I wanted to stay up. My server will run for ~45+ minutes on it's UPS, and having a smaller (%) load on the system makes the batteries last longer. I ran the 2000 for a year with no problem, but by the end of 2 years the batteries were useless. I've been running the 1000 with my server for well over a year and no sign of losing capacity. For longer outages I bought a 5k generator, but since I bought it the longest outage has been 2 hours. Maybe it will work like insurance and I'll never need it.
One thing I would recommend, if you have the capability to do it, is run a separate circuit for your office. I did that when I replaced my service panel and haven't regretted it once.
As for the complexity of the business rules, EDI has got to have the simplest set of business rules ever created.
Well, I'm not going to argue with you. I work and consult with the programmers who write the code for our EDI every day. We are in the middle of a migration from an VMS system to Axapta, so all of our EDI work is being redone. Despite the fact that we use Gentran for the actual packaging and transmission.
Here are some examples that you might run into: a 210 for Yellow Freight may not work as a 210 for USF. You can properly format an 810 (invoice), but still have it kick out of your customer's system. Which means you don't get paid. Does your customer want your part number on the 810 or their own? Some customers are going to send an 850 (PO) and 830(s), some will just send an 850. BTW, an 830 can change order qtys and ship dates. One very important business rule cannot be part of a canned EDI system, what is the freeze period on order changes. Again, your part number or your customers? Each individual customer decides if they want 862s (ship schedule) and 856s (ASN). Does the customer require their ASN to be sorted by po/line item, part number, or container id? Do they just require equipment numbers or container details? Does your customer require consolidated shipments or must they be kept separate?
You can write your EDI 100%, to the spec, but if it kicks out of GM's system it's worthless. You fix it to match their system or you don't do business with them. The realities of business are; you can tell your vendors they aren't following the specs, but the customers' system is never wrong, it's your reference platform.
BTW, using the term lusers shows you have little respect for the people who you are paid to support. You have missed the whole point of your job.
Ok, in this discussion I've learned that what I thought was an old mainframe is really a minicomputer.
To our users, our Alpha VMS machine is still the 'mainframe'. Even though we probably have laptops with more computing power. And our SQL server leaves it in the dust all the way around (memory, CPU, storage). IMO, mainframe has become more about the experience. They don't know the difference, so why confuse them. Just as long as we know.
As far as ripping out legacy, it comes back to 'if it works...' You see an AS/400 as legacy. Someone else might see Netware as legacy, although NDS is just as powerful as ActiveDirectory. Running a windows network without AD? Come out of the dark ages. It would be very easy to churn away your entire budget killing the legacy beast. Fortunately, most businesses won't allocate the money unless there is a measurable benefit to the business. If you're not a technology company, your customers don't care about the shiny kit in your computer room.
But tell me, why are other programmers so scared of a well defined set of business rules, no matter how large it is?
Because rarely are the business rules 'well defined'. Assuming they have ever been written down, the process has probably been changed several times since the documentation has. Recreating the process means reading the documentation, analyzing the existing code, and talking to the stakeholders. You'll probably end up with three different 'rules', and all of them might be wrong.
But lets say you want tackle it anyway, and you get the $$ allocated. If the stakeholders don't currently see the process as broken, your best result is going to be it does the same thing the old system did. Sure, it might be faster, have new features, and be extendable. But they weren't asking for that. The risks OTOH are that you could break it, your new system might not work or not work right.
Most of us have plenty of other work to do without tackling projects no one wants. That means when you need to add non-core functionality, like EDI, changing the existing system isn't your first choice. Can you buy a package the integrates with your current system? Can you buy a package that bolts on the outside? Can you write mods for the current system? Can you write a package that will bolt on to the current system?
No, the point is that it's not a hardware issue. It can be done on AS/400, it can be done on VMS, it can be done on windows, and I would assume that it can be done on Linux.
It's like someone asking you how to do a mail merge, and you telling them to rip out MSOffice and Windows and install Linux and OpenOffice.
And no, it's not 'drop dead simple' to go from SQL to x12 EDI. Because there are going to be a lot of business rules in there. Most EDI is legacy, and companies are not using XML yet.
I don't rely on Debian's classification to decide what packages I'm going to install on my servers. I don't do dist-upgrade. If I'm worried about a security update, I'll do that package individually.
I actually run my systems at 'testing'. And occasionally pull some unstable packages. Personally, Apt is why I run Debian. But Apt needs a little work. For instance, if you get Apache, you will get the Apache 1 (which is what I wanted). But if you do an 'apt-get install apache', there is no where to tell what version you are getting. And there is no Apache1 to match Apache2. PHP; there is a PHP4 and a PHP5. PHP5 requires Apache2. In cases like that where it doesn't matter, why not have Apache1 and Apache2 and have them both set the Apache dependency. Then PHP5 could depend on simply Apache. Mysql... If you apt-get Mysql-server you get everything for version 4. But you can't 'apt-get install mysql', there is no MySQL package. Firefox; remember to get mozilla-firefox.
And my favorite; set unstable and pull KDE. You will get KDE, but no KDM. Although you'll get every kgame ever written. It won't check to see if X is installed. Then you can install xserver-xorg, and when you start it you find that you have no fonts. Where are those dependencies?
I don't know, it just seems like there should be packages for common names; apache, samba, php, mysql, etc that would get you the version for the environment you use. But you should be able to simply 'apt-get install kde34' from stable and expect a package.
BTW, one little gotcha from the DCC install. The only thing in sources.list is the CD. Personally, I'd like to see some real repositories in there that I could just uncomment. And the installer, which I suspect is Debians, is primitive.
Now, back to the stable thing... Until just a few months ago (June), Woody was the stable release. Woody was released in July 2002. Up until June, someone considering Debian would see that and think, "this distro is OLD". And everything in the descriptions of testing and unstable lead people to stay away from them if they aren't well versed in Debian speak.
I think with Linux distros it's going to come down to two things. How good is your installer, and how complete is your repository.
Or, they could install a cheap Intel server and run something like Gentran to handle the actual EDI. This lets you map EDI data to file formats that your existing software can import/export.
Regardless, unless you find a package that handles EDI and communicates directly to the software you already run (which is rare), there is still going to be time required to learn how to create the proper maps. And if you deal with any large companies, you will find that many use their own 'flavor' of certain datasets.
Ok, this REALLY should have been one for google- even I admit that and I'm usually on the other side. Just how many hackers on slashdot do you think have even messed with EDI?
There are a few of us. Actually probably quite a lot of us.
Still, given IBM's movement to bladeservers,
Obviously you haven't, EDI is not about hardware. You should have googled too....
http://www.x12.org/ would be a good place to start.
Simply put, EDI is a set off transactions for communicating B2B. (Business to Business) Electronic orders, invoices, advanced ship notices (ASN), electronic Bills of Lading. They are flat text files with tokens (slashdotters will love that, it sounds like a config file).
Then of course there is XML EDI.
The problem with Debian stable is that it went so long in between releases that it has a reputation of being out of date. Everyone I know running Debian (or one of it's children) is running either testing or unstable. Of course, they would probably stick with stable if it was easier to pull specific packages out of testing/unstable while maintaining Apt at stable.
And I looked at Ubuntu, but noticed that there were Ubuntu specific versions of packages. I got sick of that years ago with RedHat and Mandrake. If DCC, or any of these derivative distros, wants to make a real difference, they need to push their fixes back up to Debian rather than creating new packages.
(for example, we spent our first two years working with C, and we never even touched the new .Net stuff)
.NET? Get a cheap/free version of Visual Studio and learn it yourself. The odds are much better that you're going to start out maintaining older source than .NET development anyway.
I'm not sure you've missed much. I remember when Java was going to rule the world. Write once, run everywhere. Right? And how many years has the largest software company in the world been pushing
For a major like computer science, colleges need to hire more people who've actually held jobs in the industry.
Absolutely. Over the years I have taken courses at a technical school, community college, two colleges (both now universities), and a university. And those part time instructors teaching night courses at the community college are some of the best I have had. OTOH, I've had some PHD instructors I wouldn't trust to write Hello World. My C Instructor (PHD, department head) at the first university I attended used cobol as a reference to explain C memory allocation and started every program 'while (1 == 1)'.
Which is fastest for comparing two strings (ignoring case):
Guess what, it probably doesn't matter. A recent experience as an example; with a new ERP system we are implementing we were experiencing excessive times during invoice batch runs. We suspected table locks. It turns out that it was doing a credit check whenever it created an invoice. In the base system it didn't seem to be a problem, but once we added our additional rules it became one. It turns out that the system checked a customer's credit balances when an order was entered, when the picking ticket was printed, when the packing slip was printed, and when the invoice was created. Not only was that causing a locking problem when more than one process was running, but there is absolutely no reason for us to check credit during invoicing. The order has already shipped, a credit hold would mean that we had shipped product but couldn't bill for it. Moving the credit check knocked 75% off of the invoicing time. There are hundreds of other things we would look at in the system design before we'd care about about which compare is more efficient.
Some people sugggested MIS as a better academic path for programmer. I don't know. At my University, the MIS curriculum involve a lot of business bullshit such as marketing or finance. I know these are good to know from the organizational point-of-view, but if you expect to produce decent programmers, you need to keep some focus.
It depends a lot on what type of job you are looking for. I would guess that the majority of programming jobs are for managing in-house applications. Companies writing software to manage their own business. In those jobs, it's just as important to understand the business as it is to know how to write a program. Maybe more so, since advancement above a certain level will generally be into management.
In various classes over the years, I have taken Cobol, RPG II, Assembler (s360), BASIC, C, C++, and Java. And over my career I've mostly worked in Delphi. OTOH, everything I learned in accounting and economics applies pretty much the same today as it did 20 years ago. With computer curriculums you have to be careful and make sure you are focusing on teaching how to be a programmer and not how to use a particular language. That's why classes should focus on data structures and SDLC. And sadly, proper GUI design is nearly universally ignored.
You missed an important step. Under Windows I've always had to set old-passwords in MySQL's INI file to get it to work with PHP. And you should do it before you set your root password in MySQL. I always wait just long enough between installs to forget that.
It's can be a real problem to set up Apache on Windows.
Actually, with the current installer, installing Apache on Windows is brain dead easy. Getting MySQL (4.1) running under windows isn't rocket science, but getting PHP (5) to talk to MySQL in that environment is a pain the first time or two.
But why would you go all windows with the OS if you didn't intend on using IIS?
Why does using Windows necessitate IIS? If Windows and Apache is a problem, please don't tell my systems. My Windows/Apache/SOAP CGI/MSSQL have been running flawlessly for years. I'd hate to think they're incompatible.
From my experience, Apache's 'experimental' is like Google's 'beta'.
My Mac (mini) drove me nuts. Instead of clicking on the X to exit an app you had to hunt down the Exit command. But of course, that wasn't consistant. I unplugged my mini a month ago, and haven't really had a desire to turn it back on. Instead, I hooked up a cheap terminal and use my debian box. $150 RDP/X term vs $500 mini, accompishing the same thing.
I mentioned this annoyance once before here, and the response was I shouldn't expect the X on the main form to exit the app because it was a Windowsism. Whatever, it doesn't work as expected, and that's the whole thing about HCI. I'll eventually put debian on the mini too.
I not sure what type of content patches you're used to from other games, but the amount of content that has been in the patches thus have have been very large, at least compared to other most other mmorpg patches.
Some of us were spoiled by monthly updates in Asheron's Call. I don't expect to buy the WoW expansion any time soon. But then again, I unsubscribed last spring because I didn't have time to play, and don't plan to restart until around November. Oddly, over the years I maintained two AC accounts, and never unsubscribed until I changed to WoW. A friend tells me he gets bored with WoW. I'm not sure whether his problem is lack of new content or lack of community.
If you feel the need to limit the number of instances running, set focus on the one already running. If that's not a requirement, or the user turns the option off, then launch another instance.
There are legitimate reasons for only wanting one instance running. Some IM networks will drop your existing connection if a new one is connected. I can't think of a reason to run multiple versions of GAIM. I have other apps that don't have a problem running more than one instance, but I would prefer that they didn't because it slows down my system when I accidently click the wrong icon.
Putting everything (by everything I mean business logic) in the DB is the only sane way to keep your data consistent across multiple access methods.
This is certainly true in an environment where there are several developers working on separate projects accessing the same database.
But something I have run into over the last few years with large enterprise applications is that some closed source systems put database rules/constraints in code to lock you into their suite. In many cases you can run queries against the data in the SQL server, but if you wanted to dump your data, for instance to migrate to a new system, you won't know the constraints and triggers to export it properly. And if the database is sufficiently normallized, those details are incredibly important.
One thing I have always hated about Postgres is how it handles case sensitivity. If you're going to be case sensitive, compare it to exactly what I gave you. The user shouldn't have to take extra steps to maintain case. Even better, look at MS-SQL. When you turn off case sensitivity, it actually turns it off.
Or at the very least, if you're going to upper/lower case the SQL statement, do the same thing with the schema and data.
Ok, that's a silly review. For MySQL they claim to be comparing the features of 4.1.x, and yet under features: views, schemas, subselects, stored procedures, triggers - yes (>=5.0)
If they're going to compare releases, compare apples to apples. Either pick stable releases or development releases. And FWIW, nobody that I know personally has been able to get MySQL 5.0 to run reliably, if they can even get it to launch. If we use MySQL for a project, it's 4.1.