This is astonishing to me. I check back to see if this site is still up once every year or two just to have a smile. If you were sitting across from me in an interview I am quite sure I'd lose all pretense of professionalism and ask you about nothing else for the hour.
The only reason I am sad about the death of flash is that it has all but killed my version of this: zombo.com.
Seems like management believes it is better to wait for real bad actor to purposefully destroy your site than have it done by your honest employees by accident.
I know security in 2001 was much more lax (I started in 2000) but this still shows ignorance of management.
The right way to handle this would be to ask your staff to ensure it is possible to restore services and to ensure you know what the tests are doing before you run them.
From a politics standpoint that is completely true. Which would you rather tell your boss:
Q: Why is the website offline?
A: One of our sys admins accidentally deleted it.
OR
Q: Why is the website offline?
A: Some nation-state/teenager launched a sophisticated cyber attack, we need to increase the cybersecurity budget. It's the wildwest out there!
Mistakes are normal course of action at a corporation. Sane managers will understand that is not possible to not have people make any mistakes. Mistakes are part of the learning process.
Now, when somebody makes a mistake what I am looking for are:
Does this person show good judgment? Were precautions taken by the person reasonable?
Does the mistake show pattern of abnormality? Some people seem to attract failure, maybe there is some underlying cause?
Is the person learning from mistakes? Learning is expensive, if somebody made an expensive mistake I want as much learning as possible for the expense.
Is there some kind of external factor that made the mistake possible or more likely? Usually it is possible to improve the environment to reduce the number of mistakes.
As to preventing these guys from scanning ever again, that is bad decision because it is likely they would never make the same mistake again. What's done is done. The scan showed there are problems with the app, now we should want to know if there are more problems but without risking the application stability (too much).
---
-- Do you know what the Big Co. pays when they pay high salary for an experienced engineer?
-- They pay for all the mistakes he/she made at her previous place.
Usually, HTTP servers would be huge bloats of configuration running on huge machines. As a sysadmin, it was not typically feasible to replicate the configuration on the local machine.
With a static website nobody would figure you can accidentally actually do something harmful to the website. The worst thing that could happen was that you made a configuration error in which case you just rolled back the config.
Of course we were supposed to have backups in case the server failed. While the servers would typically use RAID arrays we knew it would not save against rm -fr so there was a backup but backups rarely could be restored instantly.
I love these examples of historical calls made too early...
The usual example I trot out is when I was writing a client-side pivot table creator in the mid-2000s, as far as I can remember, with just 100 items the js version took 20-30 seconds. I then tried it using XML/XSLT instead[1] and it was instant.
I haven't checked recently, but even a few years ago javascript is extremely slow with large datasets, I was mucking around with Mandelbrot generators and js compared to C# was like a bicycle vs a jet engine, they weren't even vaguely in the same league performance-wise. Just had a quick look at some js based versions looks like it's got a bit faster, but still slow.
[1] Awesome performance, super hard for others to understand the code. XSLT was great in some ways, but the learning curve was high.
https://blogs.unity3d.com/2014/10/07/benchmarking-unity-perf...
Granted, this benchmark is for generated Javascript, not "idiomatic Javascript" (if there is such a thing). Of course you can write arbitrarily slow Javascript as well. There's a lot of stuff that can throw a wrench into the JIT.
That said, there's a lot going on there. Javascript can not use SIMD or multiple threads. Some tests are heavier on C#, which is converted to C++ in the Javascript version and thus becomes "faster than native C#".
The point is not give an exact number on how fast Javascript is compared to any other language, there's wide variance across usage and implementations. The point is to show that Javascript to rival C# performance is feasible.
Node is an unlikely event. It hit the sweet spot precisely when async started being needed, there was a runtime environment that made it viable (v8, thanks to massive investment by Google on Chrome), and a language that made it kind of natural.
Node as a server/backend language: I would say the say the ecosystem and usage are at least as large as Go/Ruby. This is hard to gauge. But I assume/expect a factor of 2 or more. If you look for web specific libraries it is unlikely you'd find something for either Go/Ruby but not for Node. Python is harder to compare because it is used much more broadly.
For me the biggest use-cases for Node are: server-side/static rendering (get all the power/expression of frontend libraries on your http/build server), web-socket ease of use and the fact that there are tons of programmers who are at least familiar with the language.
And even though it is steadily declining, the most popular web-backend language is still PHP by a long shot. And this won't change until the other languages get managed hosting that is as cheap and simple and similarly ubiquitous.
Server side javascript didn't catch on the first time around because you couldn't create threads. Because in the early 2000's, all technical interviews asked about Java style multi-threading. At some companies, the first round of technical interviews was a very, very detailed discussion about the Java threading model. If you didn't pass, you didn't get to round two. So everybody wanted to use threads.
But I used a few servers that allowed for JS scripting way before Node.
I guess, most of them were proprietary, so it never caught on until Node.
Just an example of (sort of) non-proprietary, non-browser JS.
I like how it loads instanly! :-) I remember staring at this thing for about 2 mins watching it load over dial up in a third world country on an laptop dad somehow smuggled into the country from dubai without paying import duties. Yeah.
For a site that never had pagespeed as a tool, that is super impressive and just goes to show how bloated today's websites really are.
[0] https://developers.google.com/speed/pagespeed/insights/?url=...
Actually matrix.com now appears to be a site relating to hairstyling and haircare products.
Here's another one - Solaris had a 2GB file size limit (this was before ZFS). Which isn't as crazy as it sounds now - hard drives were 9GB at the time. So ordinarily this wasn't a problem, but when the first Harry Potter movie came out, harrypotter.com (which was being served off the same server as spacejam.com) was the most popular website on the internet and the web server log would hit the 2GB limit every couple hours and we would have to frantically move it somewhere and restart the process.
I started “web stuff” with Apache and Perl CGI, and I knew NES existed but never used or saw it myself. I had no idea “server side JavaScript” was a thing back then. That’s hilarious.
Plus ça change, plus c'est la même chose.
That background story is fascinating. I wonder how many full-circles server side JavaScript has made up until now.
I'd love to see this unpublished book, if possible!
Plus a few more from 2001:
https://www.amazon.com/Server-Side-JavaScript-Developing-Int...
https://www.amazon.com/Server-Side-Javascript-Developing-Int...
Netscape's 1998 Server Side Javascript guide: https://docs.oracle.com/cd/E19957-01/816-6411-10/816-6411-10...
Oh man, the early days were so exciting. Like that time I told my boss not to use Alexa on our admin page out of general paranoia... and a few days later a bunch of content got deleted from our mainpage because they spidered a bunch of [delete] links. I learned my lesson; secured the admin site a lil better and upgraded to delete buttons. Boss kept on using Alexa on the admin page tho.
Enterprise server-side JavaScript was the first stage of dynamic web servers that connected to relational databases. Netscape LiveWire, Sybase PowerDynamo, and Microsoft Active Server Pages (with interpreted LiveScript or VBScript) were early. The enterprise software industry switched to three tiered app server architectures with JVM/.net bytecode runtimes. Single-process, multi-threaded app/web servers were a novelty and none of the client drivers for the popular relational databases were thread safe initially.
It took some time for RESTful architectures to shake-out.
Everyone has mostly forgotten AOLserver (and TCL!). Almost everyone of that generation was influenced to use a RDBMS as a backend by Philip and Alex's Guide to Web Publishing which came out in 1998.[0] Although I never actually met anyone who used AOLserver itself! Everyone took the idea and implemented it in ASP or perl, until the world succumbed to EJBs.
So many websites I remember came back up with "the last two weeks of posts are gone, sorry" or just shut down for good because it was all too corrupted to fix, and so were the backups, if they had any.
My manager even had us (early 2000s) take a one-week(?) bootcamp at Ars Digita HQ in Boston. Though about the only thing I remember from it was the fancy aeron chairs.
A scan detects a severe vulnerability and their reaction is to never run scans again...
I don't think anyone (at least no one I worked for at the time) ran staging or dev servers.
It was always stupid, yes. But back then we didn't have the tools and testing suites that we have today. CI/CD setups didn't exist. Git wasn't even built until 2005. The only version control solution was SVN at the time, which was released in 2001. But it was clunky and immature.
Back in 2000, launching a site update meant someone would log into the server via FTP, drag the files over, and try to "be careful" while they did it. Using passwords that were written on a sticky note, stuck to the CRT monitor's screen (password managers weren't a thing).
It is easy to forget how immature and primitive the world of web development was at this time.
Also, the internet was still so new, that every C-level executive had built their careers by running businesses in the 70s, 80s, and 90s. Back before you built websites or relied on them for any significant impact on your bottom line. So to tell an executive from that era that your website broke when you poked at it, their solution would be to stop poking at it. Security wasn't really a major concern like today, and having a website was still mostly a novelty in the eyes of most executives.
Heck, I remember just compiling Java classes on the server machine itself, copying them to a production directory, and restarting the app server (tomcat IIRC). Source control was the sysadmin running a nightly backup of source directories
Pre SVN there was CVS, and before that was RCS. Now these didn't work the way we think about git today, but they did allow you to roll back to a known good state with some futzing about.
Plus the web wasn't as important business stratergy back then as it obviously is now. I doubt Warner Brothers would have been willing to invest in replica dev infrastructure when "developers can write code on their desktops". I know dev infrastructure is for more than just developing code, but common concepts we take for granted like IaC, CI/CD, config management etc wasn't formalised or widely used back then and servers were pets that were held together with duct tape and sacred rituals.
In many ways, that's what made being a sysadmin in that era fun. There wasn't any shame in hacking together a solution.
hah true, and management was absolutely amazed! In the late 90s/early 2000s i worked for an independent pharmacy chain. I wrote what was basically just a proxy sitting between our dispensing systems and the central clearing networks for rx drug pricing. All it did was double check the price on the prescription (our stores weren't applying price updates which was a manual process at the time) and reject prescriptions that were priced wrong with a message telling the pharmacist to apply their price update. The CEO invented an annual award to give to me for the "work" hah
Real software engineers ssh directly into PROD to write code.
/s
Makes sense. This server-side Javascript thing will never take off. The Internet in general is really just a passing fad!
Their site report used to show an entire history so you could see every time they changed servers but it doesn't look like it does anymore. Now it's running in AWS so certainly not the same Solaris server. Although those E4500s were built like tanks so it could be plugged in somewhere...
https://sitereport.netcraft.com/?url=https://www.spacejam.co...
Lol. I used to read Slashdot when I was in college and that time the running joke was "Had Netcraft confirmed it?", right?
> Now it's running in AWS so certainly not the same Solaris server.
Hmm. Would they have maintained the site to run on modern software stack or would they have just used legacy emulator like this: https://aws.amazon.com/blogs/apn/re-hosting-sparc-alpha-or-o...
Also Space jam has « style » to be compared to « wikipedia » that is « pure html text »
<!-- Badda Bing, Badda Boom -->
Back then it was served from a Sun E4500 running Solaris (7?) and Netscape Enterprise Server. Netscape had been acquired by AOL which had also just bought Time Warner (that's why we moved to their datacentre) but somehow we couldn't make the internal accounting work and still had to buy server licenses.
Fun fact, unlike Apache, NES enabled the HTTP DELETE method out of the box and it had to be disabled in your config. We found that out the hard way when one of the sysadmins ran a vulnerability scanner which deleted all the websites. We were forbidden from running scans again by management.
Another fun fact about NES - they were really pushing server side Javascript as the development language for the web (and mostly losing to mod_perl). Also back in 2001 but at a different place I worked with the person who had just written a book on server side js for O'Reilly - he got his advance but they didn't publish it because by the time he had finished it they considered it a "dead technology".
Our job was basically to maintain an enormous config file for the webserver which was 99% redirects because they would buy every conceivable domain name for a movie which would all redirect to the canonical one. Famously they couldn't get a hold of matrix.com and had to use whatisthematrix.com. Us sysadmins ran our own IRC server and "302" was shorthand for "let's go" - "302 to a meeting". "302" on its own was "lunchtime".
I still mention maintaining this site on my CV and LinkedIn - disappointingly I've never been asked about it in an interview. I suspect most of the people doing the interviewing these days are too young to remember it.