Although, IIRC there wasn't originally a command key associated with it... you had to go to the menu.
"Command-Z" was chosen to match with the existing command keys of "Command-V" (paste), "Command-C" (copy) and "Command-X" (cut). All the major editing command keys were in the one location.
Nearly all of the calls I get (in Australia BTW) are of the form "Would you like to come to our free seminar" or something like that. Mainly real estate or investment groups. All the others tend to be "non-profits" soliciting donations.
Since they're not trying to complete a sale in the call, they wouldn't be excluded.
A pretty piss-weak "do not call" list if you ask me. This legislation makes about as much sense as US foreign policy.
(Good) Bayesian filters - spambayes and bogofilter - work on both spam and non-spam (ham) indicators.
If your message has more and/or better ham indicators (e.g. it comes from a known good email address) then it is highly unlikely to be classified as spam.
I prefer to say that I've *forgotten* most programming languages I've ever used, but give me a week to get back up to speed on any of them and I'll be fine;)
As a general estimate, I probably use about 5-10 programming and scripting languages at any particular time. For example, at the moment it's Python, C, C++, VBScript, DOS batch, bash shell scripts, makefiles, and I'm probably missing a couple. Within the last 6 months I've also used Java, (Transact) SQL and PHP. Different tools for different tasks.
In my life I would estimate that I've used over 50 languages, but most of them aren't current (but see my first statement). I started with Logo; moved onto BASIC; spent a year or two on Pascal. Moving into university I started with things like Modula-2, C, C++, Lisp, Prolog, a couple of assemblers (including one I wrote myself for a Nova II simulator we wrote for my final-year project)... the list goes on. I've worked with a multitude of languages in my professional career, and a lot of them I don't even remember I've used. I certainly wouldn't bother putting things like "makefiles" in a resume.
And I'm not quite 30;)
Getting back to the meat of the article... there tend to be more jobs searching for "Java" and "C/C++", etc for a couple of reasons. Most of them have to do with which terms HR and recruiters are familiar with. In particular, recruiters tend to maintain an internal database independently of what is actually advertised. If your resume matches any of those terms (e.g. Java, Visual Basic, etc) you will be put forward for *any* programming job. Yes, there are some recruiters who are more scrupulous about doing their job, but most aren't. HR knows this is how recruiters work, and so they tailor their requirements to match.
While I was contracting it was rare to go to an interview and not be told "actually, we need this, this and this, but no one puts that on their resume so we can't put it in the requirements".
It's a vicious circle.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Long-living ActiveX controls (on a single page) - as in 10+ minutes for a single page to be generated.
Initially the control was meant to live across page requests, but there proved to be no way to hold onto the the control reference. In the end, doing everything on a single page proved to be a better design anyway.
As for the control in question... it's a Microsoft application that was never meant to be used in this way...
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Nah - it's more of a design failure:( It can be really hard to close everything down on a Windows machine - by design everything is open (urgh). Nimda used about 6 different attacks on different technologies to propagate...
Security is the #1 argument I have against IIS.
In any case, if *I* had set up those machines, they would have been less vulnerable, since I don't let indexing server be installed... (one less point of attack).
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Nah - there's absolutely no database access involved in this application. As I've stated, we're doing some fairly unusual stuff;)
The simple fact is, I cannot estimate for you. I can only estimate for me.
Of course, you would need to get a group together to use it. You may be able to use some of the basic principles however.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Actually, it was the very first thing that occurred to me. I spent a lot of time investigating the possibility.
The point is though, that *random* crashes are a Windows trademark - not crashes which appear to be random in how you provoke them, but consistent once they start happening.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
No real OO involved in the PHP stuff... except interacting with COM objects.
In any case, I would have much preferred a Python solution, but most of the decisions were made before I came onto the project. In particular, Zope had been thrown out for being too "heavyweight".
Unfortunately, the timeframe of fixing it did not give me enough time to set up a mod_python solution.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
I hate IIS and ASP. It sucks. I avoided recommending it for as long as I could as I evaluated other alternatives. The fact that I was willing to recommend it told everyone exactly what a shitty situation we were in, as they knew I would only do such a thing if it were the only viable alternative given the time frame and available skillset.
Does that sound like a promo to you?
I've posted a lot on this topic - more than I've ever posted on a topic before. Why? Two reasons.
1. To clarify some misunderstandings about the situation (what technology was used, and when).
2. Many people seem unwilling to accept that *sometimes* an open-source tool is less suitable for a particular purpose than a proprietory tool.
I'm not saying that IIS and ASP were *good* tools. But they were more usable for our needs.
If it had not been for that one single showstopping bug the web site would be using PHP right now, despite the other flaws we found.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
How many times do I need to state this? The problems were manifested with Apache 2.0.40 and PHP 4.23 (and 4.22 and 4.12) running as a CGI module on Windows 2000 (Pro for development, Server for testing - never got to production).
If it had been loaded as a long-running process (Apache module or IIS ISAPI module), I doubt I would have seen the consistent error - instead I would have seen much more random errors as different things would happen in different ways. By running as a CGI module, I was ensuring that the exact same sequence of events was occurring each time... executable was loaded (and memory space assigned), script was read, and somewhere along the line something bad happened.
What you are doing sounds exactly as I described - you are doing the *normal* things with PHP - primarily serving pages generated using data from a database.
I *expect* that my case is unusual - otherwise all these PHP sites would be failing left, right and centre.
However, the fact that I did indeed encounter these problems, plus the general immaturity of much of PHP (for example, the session-handling) means that I cannot recommend the technology.
Not to mention that it was almost as much of a horror to program in as VBScript:(
My immediate thought upon reading the "crashing computers" comment was, naturally enough...
These guns are unlikely to be controlled by a full-blown operating system. Embedded systems anyone? The test cycle for such systems tend to be much more stringent.
Of course, whilst I applaud this move (it's something I've talked about to friends many times, esp. concerning cases of kids "somehow" getting hold of Daddy's "unloaded" gun), it still doesn't deal with the root problem of too many people both owning and using guns. Reduce the number of gun owners, reduce the potential for accidental gun deaths and the *ease* of killing in "crimes of passion" and suchlike. Deaths will still occur, but it's a lot harder to kill or seriously maim someone with a knife than a gun.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Not in the slightest. Please stop trying to suggest that I'm a moron. Chances are I know more about such things than you, but I'm not going to get into a pissing contest with an anonymous coward (or anyone for that matter).
5 machines - 3 development machines, 2 servers (rack mounts, very high quality control). All exhibited the problem in different ways, but the problem was consistent when it happened.
If it had been a hardware problem, the results would have been inconsistent (happening not just in PHP, and not in exactly the same way each time on the same machine, across reboots). Whilst I would normally expect more inconsistency with a memory problem, due to differences in the order of things happening, it is actually not surprising that this is consistent. PHP performs exactly the same steps each time it loads up and runs the offending page. As CGI, it has its own memory space, so it *should* hit the problem in the same way each time.
No problems (other than general windows and specific application ones;) have been noted with any of those machines since the changeover. One is the machine I've been using every workday for the past two years.
The most likely explanation is a bug in the PHP 4.x codebase, which has been exposed because I'm doing something unusual. Most people simply do the usual things with PHP... display pages with data extracted from a database. Since these are the most common things to do, bugs in those code paths have already been found and fixed.
No, and if I were not agnostic I'd thank God that we don't.
All a codification does is make it easy for some people to argue that anything not explicitly covered in the "Bill of Rights" is not a right at all.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
It's not something I can prove (since I couldn't get any of the 4.x versions to build... bits appeared to be missing from the MSVC projects, and I've never used MSVC).
However, the symptoms I was getting were extremely indicative... in particular that a single space or newline (which should be insignificant) could either show or hide the problem. It was most likely a buffer overrun... but not for sure, since I could provoke it on very short files (buffer overruns tend to be on larger chunks of data), and *adding* stuff to files could hide the problem. Plus it was consistent across reboots (which implies it was in the PHP memory space).
As I said, not mature enough for use to rely on. We might have had it work on all our dev and test machines, but then fail on the production machine. We couldn't know.
Whilst we have the same problems with IIS (can't know for sure that it works) we at least haven't had it *fail* anywhere. Cracked yes (Nimda) but not a basic technology failure.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Hmm... strange that I said I was running PHP under *Apache*... and using CGI no less (in another post).
So where did you get the impression that I was running PHP under IIS?
Ignoring the "millions of people" bit, don't you consider 5% (a figure that is probably way higher than reality) having issues that pop up out of nowhere being way too high?
The simple fact is, the site was developed in PHP over the course of about 2 months, during which time a number of issues came up, but nothing that couldn't be worked around.
Until finally a major failure in PHP occurred, at a time when we could not dedicate the time to hunting down and fixing it.
The rewrite in ASP took 5 days. It would have taken considerably longer if it was being done from scratch, but of course we had worked out the problems with the other technologies involved whilst working with PHP - similarly all the design and structural work was done. The rewrite was essentially a translation (taking into account VBScript's flaws).
I'm sure PHP is fine for many things - but it proved to be unsuitable for what we were doing, and I am unable to recommend it for another project when there are so many better things out there (and no, I don't in general consider IIS and ASP better).
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
The site was originally specced to use Zope (which I would have been very happy to use... been wanting to have a look at the ZPT for some time).
However, the decision was made by someone (I'm not sure who - it was before I came onto the project) that Zope was too heavy-weight for what we wanted.
By the time PHP failed, it was too late to go to Zope... the approaches to web development are just so different between the technologies.
Basically, ASP was the one technology where I could (almost) guarantee having the site in an equivalent state to the PHP version in the time frame. A purely risk-management decision (including the risk of bugs in IIS, etc).
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Unfortunately not. Going back to a completely clean install of 4.2.2 and 4.1.2 for example failed to fix the problem.
It appears to be a long-standing bug.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
Whilst you *can* use JScript, it really isn't as well supported as VBScript. VBScript is the "native" ASP language, and everything else is a second-class citizen.
One of the reasons for moving to ASP/VBScript was familiarity - much to my dismay, I have written extensive amounts of it:(
I've also used PerlScript before... for a single project. I gave up on Perl once I started looking at the so-called "object-oriented" aspects. Python is so much nicer.
Re:One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 2
I was indeed using the CGI module (the ISAPI module looked *way* too flakey for me to consider).
The COM stuff isn't surprising, as we're doing fairly unusual stuff with something that wasn't really designed for it.
One person's experience with PHP ...
on
PHP5 Coming Soon
·
· Score: 4, Interesting
... and why I won't go back.
PHP 4.2.3. Windows 2000.
90% of the way into a decent-sized project, I started experiencing somewhat random crashes. Somewhat random in that there seemed to be no consistent way to provoke them, but once they started happening they happened in precisely the same way, consistently.
Simple changes, such as adding a single character to a script, would "fix" it on a particular machine... and sometimes expose it on another machine. I'm talking about adding a blank line to a script. It seemed likely that there was a memory error of some kind in PHP.
Downgrading to earlier versions of PHP 4.x didn't fix the problem. Downgrading to 3.x was not feasible... transferring to a 3rd-party session system that was incompatible with the 4.x sessions and completely untested by us was not possible by that time.
Of course, I attempted getting the source code and finding the problem myself. Unfortunately, none of the 4.x versions would compile. The 3.x versions would - but 4.x wouldn't. Obviously, some black magic was required. Sacrifices failed.
Time was running short. Faced with a very short deadline, I made the only decision I could... I dumped PHP. I was in a situation where I could not trust the underlying technology.
As an indication of what dire straits I was in, the technology I eventually recommended to replace PHP and Apache was... IIS 5.0 and Active Server Pages. Believe me... if there had been any other viable option, I would have taken it. mod_python looked viable at first, but I didn't have time to go through the cycle of building a single-threaded python, and verifying the underlying technology. With ASP there was a fairly direct translation from PHP.
I hate that this application has been written in VBScript. The shenanigans I had to go through to get a particular COM control to load and be controlled by IIS - it's system of impersonation doesn't work very well if the COM object isn't specifically designed to be used with it. Under Apache it was able to run as LocalSystem... which was acceptable since the users are trusted. Under IIS I eventually needed to create an administrator user which a single page uses - all other pages use a Guest user.
Obviously I was doing something outside the norm, since there are thousands of web sites which use PHP as the underlying technology. I suspect most of them are running 3.x. But the sheer number of issues that I found with PHP during the relatively short development cycle convinced me that it was in no way mature enough for us to trust our work to it.
And most importantly, historically most anime is *not* pornographic.
A large amount of what was originally imported to the US was pornographic (e.g. Urotsukidoji/Legend of the Overfiend and sequels).
However, the vast majority of anime is not pornographic, and never has been. There may be scenes of nudity at times (very often comedic), and they often deal with adult situations (not necessarily sex).
Many animated Japanese shows are mature. There are also many that are aimed at children. And many aimed at teenagers.
Anime covers the entire spectrum. Anime is a style, not a genre.
The system engineer's job is primarily to translate between techies and customers. Note: this is a properly-trained person, with experience working both with customers and developers. I've seen good system engineers come from both sides - primarily developer, or primarily working with customers.
So, it is the system engineer who produces the requirements for the product, based on talking to the customer. The development team talks to the system engineer, and develops the requirements analysis together.
There are times that the development team should talk to the customer (it's incredibly valuable), but there should always be someone there who understands both groups.
Slashdot Mirror
Although, IIRC there wasn't originally a command key associated with it ... you had to go to the menu.
"Command-Z" was chosen to match with the existing command keys of "Command-V" (paste), "Command-C" (copy) and "Command-X" (cut). All the major editing command keys were in the one location.
That's right people ... Apple did it first (at least in a consumer machine).
The original Macintosh had "undo" functionality in its applications, right from the start.
The Apple IIGS also had "undo" functionality.
There may have been one or two individual applications before it (I don't know) but the Mac made "undo" ubiquitous.
Nearly all of the calls I get (in Australia BTW) are of the form "Would you like to come to our free seminar" or something like that. Mainly real estate or investment groups. All the others tend to be "non-profits" soliciting donations.
Since they're not trying to complete a sale in the call, they wouldn't be excluded.
A pretty piss-weak "do not call" list if you ask me. This legislation makes about as much sense as US foreign policy.
(Good) Bayesian filters - spambayes and bogofilter - work on both spam and non-spam (ham) indicators.
If your message has more and/or better ham indicators (e.g. it comes from a known good email address) then it is highly unlikely to be classified as spam.
I prefer to say that I've *forgotten* most programming languages I've ever used, but give me a week to get back up to speed on any of them and I'll be fine ;)
... the list goes on. I've worked with a multitude of languages in my professional career, and a lot of them I don't even remember I've used. I certainly wouldn't bother putting things like "makefiles" in a resume.
;)
... there tend to be more jobs searching for "Java" and "C/C++", etc for a couple of reasons. Most of them have to do with which terms HR and recruiters are familiar with. In particular, recruiters tend to maintain an internal database independently of what is actually advertised. If your resume matches any of those terms (e.g. Java, Visual Basic, etc) you will be put forward for *any* programming job. Yes, there are some recruiters who are more scrupulous about doing their job, but most aren't. HR knows this is how recruiters work, and so they tailor their requirements to match.
As a general estimate, I probably use about 5-10 programming and scripting languages at any particular time. For example, at the moment it's Python, C, C++, VBScript, DOS batch, bash shell scripts, makefiles, and I'm probably missing a couple. Within the last 6 months I've also used Java, (Transact) SQL and PHP. Different tools for different tasks.
In my life I would estimate that I've used over 50 languages, but most of them aren't current (but see my first statement). I started with Logo; moved onto BASIC; spent a year or two on Pascal. Moving into university I started with things like Modula-2, C, C++, Lisp, Prolog, a couple of assemblers (including one I wrote myself for a Nova II simulator we wrote for my final-year project)
And I'm not quite 30
Getting back to the meat of the article
While I was contracting it was rare to go to an interview and not be told "actually, we need this, this and this, but no one puts that on their resume so we can't put it in the requirements".
It's a vicious circle.
Long-living ActiveX controls (on a single page) - as in 10+ minutes for a single page to be generated.
... it's a Microsoft application that was never meant to be used in this way ...
Initially the control was meant to live across page requests, but there proved to be no way to hold onto the the control reference. In the end, doing everything on a single page proved to be a better design anyway.
As for the control in question
Nah - it's more of a design failure :( It can be really hard to close everything down on a Windows machine - by design everything is open (urgh). Nimda used about 6 different attacks on different technologies to propagate ...
... (one less point of attack).
Security is the #1 argument I have against IIS.
In any case, if *I* had set up those machines, they would have been less vulnerable, since I don't let indexing server be installed
Nah - there's absolutely no database access involved in this application. As I've stated, we're doing some fairly unusual stuff ;)
... is worth looking at. We've used it successfully on multiple projects.
http://www.google.com.au/search?q=wideband+delphi
The simple fact is, I cannot estimate for you. I can only estimate for me.
Of course, you would need to get a group together to use it. You may be able to use some of the basic principles however.
Actually, it was the very first thing that occurred to me. I spent a lot of time investigating the possibility.
The point is though, that *random* crashes are a Windows trademark - not crashes which appear to be random in how you provoke them, but consistent once they start happening.
No real OO involved in the PHP stuff ... except interacting with COM objects.
In any case, I would have much preferred a Python solution, but most of the decisions were made before I came onto the project. In particular, Zope had been thrown out for being too "heavyweight".
Unfortunately, the timeframe of fixing it did not give me enough time to set up a mod_python solution.
I hate IIS and ASP. It sucks. I avoided recommending it for as long as I could as I evaluated other alternatives. The fact that I was willing to recommend it told everyone exactly what a shitty situation we were in, as they knew I would only do such a thing if it were the only viable alternative given the time frame and available skillset.
Does that sound like a promo to you?
I've posted a lot on this topic - more than I've ever posted on a topic before. Why? Two reasons.
1. To clarify some misunderstandings about the situation (what technology was used, and when).
2. Many people seem unwilling to accept that *sometimes* an open-source tool is less suitable for a particular purpose than a proprietory tool.
I'm not saying that IIS and ASP were *good* tools. But they were more usable for our needs.
If it had not been for that one single showstopping bug the web site would be using PHP right now, despite the other flaws we found.
How many times do I need to state this? The problems were manifested with Apache 2.0.40 and PHP 4.23 (and 4.22 and 4.12) running as a CGI module on Windows 2000 (Pro for development, Server for testing - never got to production).
... executable was loaded (and memory space assigned), script was read, and somewhere along the line something bad happened.
:(
If it had been loaded as a long-running process (Apache module or IIS ISAPI module), I doubt I would have seen the consistent error - instead I would have seen much more random errors as different things would happen in different ways. By running as a CGI module, I was ensuring that the exact same sequence of events was occurring each time
What you are doing sounds exactly as I described - you are doing the *normal* things with PHP - primarily serving pages generated using data from a database.
I *expect* that my case is unusual - otherwise all these PHP sites would be failing left, right and centre.
However, the fact that I did indeed encounter these problems, plus the general immaturity of much of PHP (for example, the session-handling) means that I cannot recommend the technology.
Not to mention that it was almost as much of a horror to program in as VBScript
My immediate thought upon reading the "crashing computers" comment was, naturally enough ...
These guns are unlikely to be controlled by a full-blown operating system. Embedded systems anyone? The test cycle for such systems tend to be much more stringent.
Of course, whilst I applaud this move (it's something I've talked about to friends many times, esp. concerning cases of kids "somehow" getting hold of Daddy's "unloaded" gun), it still doesn't deal with the root problem of too many people both owning and using guns. Reduce the number of gun owners, reduce the potential for accidental gun deaths and the *ease* of killing in "crimes of passion" and suchlike. Deaths will still occur, but it's a lot harder to kill or seriously maim someone with a knife than a gun.
Not in the slightest. Please stop trying to suggest that I'm a moron. Chances are I know more about such things than you, but I'm not going to get into a pissing contest with an anonymous coward (or anyone for that matter).
;) have been noted with any of those machines since the changeover. One is the machine I've been using every workday for the past two years.
... display pages with data extracted from a database. Since these are the most common things to do, bugs in those code paths have already been found and fixed.
5 machines - 3 development machines, 2 servers (rack mounts, very high quality control). All exhibited the problem in different ways, but the problem was consistent when it happened.
If it had been a hardware problem, the results would have been inconsistent (happening not just in PHP, and not in exactly the same way each time on the same machine, across reboots). Whilst I would normally expect more inconsistency with a memory problem, due to differences in the order of things happening, it is actually not surprising that this is consistent. PHP performs exactly the same steps each time it loads up and runs the offending page. As CGI, it has its own memory space, so it *should* hit the problem in the same way each time.
No problems (other than general windows and specific application ones
The most likely explanation is a bug in the PHP 4.x codebase, which has been exposed because I'm doing something unusual. Most people simply do the usual things with PHP
No, and if I were not agnostic I'd thank God that we don't.
All a codification does is make it easy for some people to argue that anything not explicitly covered in the "Bill of Rights" is not a right at all.
It's not something I can prove (since I couldn't get any of the 4.x versions to build ... bits appeared to be missing from the MSVC projects, and I've never used MSVC).
... in particular that a single space or newline (which should be insignificant) could either show or hide the problem. It was most likely a buffer overrun ... but not for sure, since I could provoke it on very short files (buffer overruns tend to be on larger chunks of data), and *adding* stuff to files could hide the problem. Plus it was consistent across reboots (which implies it was in the PHP memory space).
However, the symptoms I was getting were extremely indicative
As I said, not mature enough for use to rely on. We might have had it work on all our dev and test machines, but then fail on the production machine. We couldn't know.
Whilst we have the same problems with IIS (can't know for sure that it works) we at least haven't had it *fail* anywhere. Cracked yes (Nimda) but not a basic technology failure.
Hmm ... strange that I said I was running PHP under *Apache* ... and using CGI no less (in another post).
So where did you get the impression that I was running PHP under IIS?
Ignoring the "millions of people" bit, don't you consider 5% (a figure that is probably way higher than reality) having issues that pop up out of nowhere being way too high?
The simple fact is, the site was developed in PHP over the course of about 2 months, during which time a number of issues came up, but nothing that couldn't be worked around.
Until finally a major failure in PHP occurred, at a time when we could not dedicate the time to hunting down and fixing it.
The rewrite in ASP took 5 days. It would have taken considerably longer if it was being done from scratch, but of course we had worked out the problems with the other technologies involved whilst working with PHP - similarly all the design and structural work was done. The rewrite was essentially a translation (taking into account VBScript's flaws).
I'm sure PHP is fine for many things - but it proved to be unsuitable for what we were doing, and I am unable to recommend it for another project when there are so many better things out there (and no, I don't in general consider IIS and ASP better).
The site was originally specced to use Zope (which I would have been very happy to use ... been wanting to have a look at the ZPT for some time).
... the approaches to web development are just so different between the technologies.
However, the decision was made by someone (I'm not sure who - it was before I came onto the project) that Zope was too heavy-weight for what we wanted.
By the time PHP failed, it was too late to go to Zope
Basically, ASP was the one technology where I could (almost) guarantee having the site in an equivalent state to the PHP version in the time frame. A purely risk-management decision (including the risk of bugs in IIS, etc).
Unfortunately not. Going back to a completely clean install of 4.2.2 and 4.1.2 for example failed to fix the problem.
It appears to be a long-standing bug.
Whilst you *can* use JScript, it really isn't as well supported as VBScript. VBScript is the "native" ASP language, and everything else is a second-class citizen.
:(
... for a single project. I gave up on Perl once I started looking at the so-called "object-oriented" aspects. Python is so much nicer.
One of the reasons for moving to ASP/VBScript was familiarity - much to my dismay, I have written extensive amounts of it
I've also used PerlScript before
I was indeed using the CGI module (the ISAPI module looked *way* too flakey for me to consider).
The COM stuff isn't surprising, as we're doing fairly unusual stuff with something that wasn't really designed for it.
... and why I won't go back.
... and sometimes expose it on another machine. I'm talking about adding a blank line to a script. It seemed likely that there was a memory error of some kind in PHP.
... transferring to a 3rd-party session system that was incompatible with the 4.x sessions and completely untested by us was not possible by that time.
... I dumped PHP. I was in a situation where I could not trust the underlying technology.
... IIS 5.0 and Active Server Pages. Believe me ... if there had been any other viable option, I would have taken it. mod_python looked viable at first, but I didn't have time to go through the cycle of building a single-threaded python, and verifying the underlying technology. With ASP there was a fairly direct translation from PHP.
... which was acceptable since the users are trusted. Under IIS I eventually needed to create an administrator user which a single page uses - all other pages use a Guest user.
PHP 4.2.3. Windows 2000.
90% of the way into a decent-sized project, I started experiencing somewhat random crashes. Somewhat random in that there seemed to be no consistent way to provoke them, but once they started happening they happened in precisely the same way, consistently.
Simple changes, such as adding a single character to a script, would "fix" it on a particular machine
Downgrading to earlier versions of PHP 4.x didn't fix the problem. Downgrading to 3.x was not feasible
Of course, I attempted getting the source code and finding the problem myself. Unfortunately, none of the 4.x versions would compile. The 3.x versions would - but 4.x wouldn't. Obviously, some black magic was required. Sacrifices failed.
Time was running short. Faced with a very short deadline, I made the only decision I could
As an indication of what dire straits I was in, the technology I eventually recommended to replace PHP and Apache was
I hate that this application has been written in VBScript. The shenanigans I had to go through to get a particular COM control to load and be controlled by IIS - it's system of impersonation doesn't work very well if the COM object isn't specifically designed to be used with it. Under Apache it was able to run as LocalSystem
Obviously I was doing something outside the norm, since there are thousands of web sites which use PHP as the underlying technology. I suspect most of them are running 3.x. But the sheer number of issues that I found with PHP during the relatively short development cycle convinced me that it was in no way mature enough for us to trust our work to it.
And most importantly, historically most anime is *not* pornographic.
A large amount of what was originally imported to the US was pornographic (e.g. Urotsukidoji/Legend of the Overfiend and sequels).
However, the vast majority of anime is not pornographic, and never has been. There may be scenes of nudity at times (very often comedic), and they often deal with adult situations (not necessarily sex).
Many animated Japanese shows are mature. There are also many that are aimed at children. And many aimed at teenagers.
Anime covers the entire spectrum. Anime is a style, not a genre.
This is what a good *system engineer* is for.
The system engineer's job is primarily to translate between techies and customers. Note: this is a properly-trained person, with experience working both with customers and developers. I've seen good system engineers come from both sides - primarily developer, or primarily working with customers.
So, it is the system engineer who produces the requirements for the product, based on talking to the customer. The development team talks to the system engineer, and develops the requirements analysis together.
There are times that the development team should talk to the customer (it's incredibly valuable), but there should always be someone there who understands both groups.