Jurassic Park computer system in the browser
jurassicsystems.com
jurassicsystems.com
The computers in Jurassic Park is what got me into programming when I was young. I saw their 3D weather overlay when the storm was approaching and thought "THAT IS IT!". I was 8 years old at the time.
I was determined to learn and create that system - I started learning C, so that I could open and close files. I learnt OpenGL so that I could create the 3D scene. I learnt socket programming so that I could download weather images from the NOAA.
It took me until I was 15 (I was totally self taught and it took me a while before I could learn all of the vector / matrix math myself) but I ended up building it! I made a program in C that downloaded the weather jpg, cleaned it up (removed noise, removed the NOAA logo, smoothed out the clouds) then generated a heightmap in OpenGL, and made a fly-over.
I wish I still had the code, it's sitting on my old computer at the Farm in New Zealand :<
Every day I'd come home with a box of floppy disks full of open source programs to read, and satellite jpgs downloaded from the noaa website.
later on I got internet access and that's when I hooked it up live ... good old NZ Farm internet : 0.5kb/s because our electric fences caused so much electrical interference with the phone lines ....
I'm guessing you would be around 28-30 years old, so I'm a couple of years or more older ... but I started learning C when I was 31, currently I'm interested in stuff like parsers and data structures (I really should look at sockets soon). Perhaps I'm just too old to hack.
> I wish I still had the code, it's sitting on my old computer at the Farm in New Zealand :<
I bet a fair few people on HN would be interested in it as well, it sounds quite hardcore.
Did you do any programming at all before 31?
I don't think you're ever too old to do anything, personally. I was 26 (which isn't terribly old, admittedly, but definitely past the little kid age) when I talked to a friend who was a professional programmer and decided "huh, I like computers and solving problems. I'm going to do that." I hadn't programmed before then, though I was computer savvy, I guess. I also have a degree in sociology, heh.
Took me about four years, but now I have a corporate job doing full stack .net work in C#/MVC, I've done side projects in ruby, and I do some C, Haskell, and python on the side. I'm also working my way through The Algorithm Design manual and have Concrete Mathematics to work through later on.
I always got really discouraged because I constantly see and hear about people who started programming when they were five, or eight, or something like that, and I'd think "no way could I get into it that deeply, starting so late" but that's just totally untrue. I'm finally at a point where I think "given the desire and time, I can learn whatever comp sci topic I want," so I get discouraged less.
I think part of it has to do with notions of talent, and natural abilities. When I was a kid, I took for granted that something would be hard until I learned it. I don't remember learning most of the basic skills I have, so I forget that things can be difficult starting out. Every topic I've started learning and stuck with in programming has pretty fully integrated itself into the core of how I think about the topic. One for-example would be immutable data structures as they're implemented in Clojure, or functional programming in general.
Anyway, that's a rambling tl:dr for: stick with it. You're never too old. You just have to try that much harder to catch up initially, but if you can teach yourself to keep learning now, you've got an extra skill a lot of people don't have, which is learning how to learn as an adult. I think it's the most valuable skill I have right now.
(ps I'm making a lot of assumptions in this post; sorry if any of them are way off base)
A couple years ago I figured I would try anyways, so I started looking up good books to read through and do the exercises. Started with Python and I've read books on and written assembly and C. Now I'm an independent contractor doing webmaster/web developer.
Any books you'd recommend other than The Algorithm Design/Concrete Mathematics? Those look interesting and I'll probably go through them.
I think I've listened to every podcast on software engineering radio a few times [2]. The older ones are especially nice because they usually pick a specific topic and cover the high points. I liked that I could listen to it while I was driving, or otherwise not in front of a computer.
It's specific, but Javascript: The Good Parts is probably the most used book I have on my shelf. It has such a perfect amount of usable information in it. It's pretty great. Again, it's definitely worth looking up critiques and counterpoints.
I've also got Introduction to Algorithms, which I use as a reference, sometimes. I switched over to The Algorithm Design Manual [5] after I saw it referenced in an older Steve Yegge post [6]. I read through the intro and it seemed like a book that would be more appropriate from an autodidactic standpoint. I really have no idea if that's going to pan out, since I'm not that far into it, but we'll see, for sure. Doesn't kill me to have an extra algorithms book laying about, though, and I've always got intro to algorithms for cross reference. I've found that I really need to have as many sources available as possible when I'm learning alone. Usually I don't get something until the fifth person describes it from the tenth different angle.
That's most of what I can think of off hand. I really enjoyed The Joy of Clojure [7], though haven't checked out the newer version. Programming Collective Intelligence [8] is a fun book, and is what made me want to go back down the maths route to get more into machine learning.
And of course habitually reading hacker news for an hour or three every night :)
So that's my totally inexpert list of random stuff that I enjoy
[1] http://www.amazon.com/Code-Complete-Practical-Handbook-Const... [2] http://www.se-radio.net/ [3] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... [4] http://www.amazon.com/Introduction-Algorithms-Thomas-H-Corme... [5] http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/... [6] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... [7] http://www.amazon.com/Joy-Clojure-Michael-Fogus/dp/161729141... [8] http://www.amazon.com/Programming-Collective-Intelligence-Bu...
No, I didn't. Sorry, I only just noticed my comment had been replied to.
I just wanted to say, get in there and start doing it. I honestly think that, to a point, I'm at an advantage. I've had so much work experience outside of coding, that my context for interacting with people seems to work in my favor. I'm also just super glad to have a programming job. Mix a (hopefully) more level head, with an exuberance for the job, and I think I put across a pretty good image.
If I can throw some suggestions out there, listen to every episode of software engineering radio. The other books I mentioned are great, but SE radio is nice in that you can just casually listen to it while you're commuting or whatever else. I listened to it when I had barely done any coding and I think it lent a lot of perspective to what I was doing. I still run into random situations where someone says something like "do you know anything about AS400?" and I'll say, "well, not really, but I have a general context as far as the ibm i series os goes, and some of the general ideas behind it. I could probably pick up material and get going." It's not much, but being familiar enough with a ton of random stuff has given me credibility in a lot of situations I wouldn't have had before.
I also relisten to them a lot, and get new tidbits because I didn't understand bits and pieces before.
I hope this doesn't sound preachy. I think our culture pushes this idea of the talented hacker, or the person that started x or y when they were five. That's great, but man, screw that. I don't plan on stopping learning until my brain doesn't work, and I'm going to use that to my advantage.
Good luck!
No such thing.
My point to all of that is that, in the end, those experiences meant very little to me now. They were indicative of the kind of person I am, and they are pretty cool to look back on and brag about, but in the end, they don't really make me better at any specific programming task. If I were to have not had the same resources to try to do those things, I would probably not be significantly better or worse. I would have spent my time trying to take apart electronics or learning a language or something instead, developed my problem solving skills and semantic skills in other areas. Maybe a little bit less experience, but in the end I think I would not be significantly impacted.
The reason that people might fear that starting late holds them back is because they might not be the kind of person who, even with access to the tools and resources, would be interested in taking things apart and finding out how they worked to start with.
If you can say at this point that you're interested in stuff like parsers and data structures, then that's awesome. If you're interested in it and you want to learn more, you will learn more, and you will succeed. If on the other hand you are uninterested but think that programming is a smart career path, you'll probably do poorly.
I was lucky enough to have the pleasure of working with a few of the smart folks who were responsible for those weather visualizations.
They were created by a little known startup in Minneapolis, Minnesota called EarthWatch Communications. At the time they were creating 3D displays of weather data long before such visualizations were commonplace on every TV weather forecast.
In the computer room scene you can see a CM-5 [1] from Thinking Machines in the background (or at least, only the front panels with the futuristic blinking red leds). Those were very interesting computers when launched, with a fundamentally different architecture for parallel computing.
Also, fun story: the company hired Richard Feynman [2].
[1] http://www.sgistuff.net/funstuff/hollywood/images/hwd_jpark9...
[2] http://longnow.org/essays/richard-feynman-connection-machine...
I used that at my first programming internship at university. Even then (1999) it was a dated OS, but it was still fun it.
I wonder if they used IRIX in the movie because the VFX guys making the movie, ILM, were doing all the VFX work using Softimage on SGI machines running IRIX at the time.
SGI machines were beautiful, full stop.
The Indigos were another story entirely: They couldn't touch the raw graphics performance of an Iris, since the rendering was all in software, but you could actually stuff one of them in the overhead compartment on an airplane!
And then there was the SGI Indy... They made up for being small on the outside, by being HUGE and BLOATED in the inside:
"Indy: an Indigo without the 'go'". -- Mark Hughes (?)
This legendary leaked memo has become required reading for operating system design courses:
http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassi...
Software Usability II October 5, 1993 Tom Davis
Last May, I published my first report on software usability, which Rocky Rhodes and I presented to at Tom Jermoluk's staff meeting (with Ed, but without Tom). Subsequently, I made it available to quite a few other people. This sequel is to satisfy all those people who have urged me to bring it up to date. I begin with a summary; details follow.
Please read at least the summary.
SUMMARY
Release 5.1 is a disappointment. Performance for common operations has dropped 40% from 4.0.5, we shipped with 500 priority 1 and 2 bugs, and a base Indy is much more sluggish than a Macintosh. Disk space requirements have increased dramatically.
The primary cause is that we attempted far too much in too little time. Management would not cut features early, so we were forced to make massive cuts in the final weeks of the release.
What shall we do now? Let's not look for scapegoats, but learn from our mistakes and do better next time.
A December release of 5.1.2 is too early to fix much -- we'll spend much more time on the release process than fixing things. Allow enough time for a solid release so we don't get: 5.1.2.1, 5.1.2.2, 5.1.2.3, ...
Let's decide ahead of time exactly what features are in 5.1.2. If we pick a reasonable set we'll avoid emergency feature cuts at the end.
Nobody knows what's wrong -- opinions are as common as senior engineers. The software environment is so convoluted that at times it seems to rival the US economy for complexity and unpredictability. I propose massive code walk-throughs and design reviews to analyze the software. We'll be forced to look closely at the code, and fresh reviewers can provide fresh insights.
For the long term, let's change the way we do things so that the contents and scheduling of releases are better planned and executed. Make sure marketing and engineering expectations are in agreement.
INTRODUCTION
We've addressed some of the problems presented in the original May report, but not enough. Most of the report's warnings and predictions have come true in 5.1. If we keep doing the exact same thing, we'll keep getting the exact same results. I'm preparing this report in ASCII to make it widely available. It's easy to distribute via news and mail, and everyone can read it.
An ASCII version of the May 12 report can be found in:
bedlam.asd:/usr/tmp/report.text
The included quotations are not verbatim. Although the wordings are inexact, I believe they capture the spirit of the originals.
BLOAT UPDATE
"Do you want to be a bloat detective? It's easy; just pick any executable. There! You found some!" -- Rolf van Widenfelt
[...] Read the rest at: http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassi...
What always amused me is that in order to trigger the locks, the "computer whiz" girl had to navigate some sort of 3d control environment, probably the most ineffective way possible to control something that should be random access.
It's admirable that SGI was experimenting with interfaces. However in this situation having to navigate such an interface created a very real safety hazard. I suppose she could have used the regular file browser instead - or perhaps the substantially less exciting XTerm.
Things like that and running xearth as the background when logging in on the Indy's made them stand out massively next to the Sun boxes with monochrome terminals in our computer labs, which seemed ancient and outdated.
Heck, even booting them, with their nice blue gradient background and metallic frame around the window where the boot messages scrolled by set them apart from the boring Sun boxes. SGI early on had a lot of the design sense and flair that Apple has today.
http://www.youtube.com/watch?v=826qq6pslJk
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=...
With modern GPUs and processing power these could be made silky smooth. Still mostly pointless, which is a shame.
It's actually a Quadra 700. Business class all the way at Jurassic Park.
I bought an SGI Indy and spent a lot of time in the shell just so it would look and feel like the scene from this movie. I don't know why it affected me so much but it did.
So much love for the author who create this simulator.
a comparison of the two from 1993.
http://www.opus1.com/www/jms/machten.html
FWIW BeOS made me feel as excited to use a system as IRIX did back when i first used it.
On the "low end", besides Apple's A/UX, Microsoft had Xenix and Commodore had Amiga Unix.
There's a subreddit for everything.
edit: Here's the GitHub issue for it https://github.com/tojrobinson/jurassicsystems.com/issues/1
> access main security system please
> display zebraGirl.jpg
<script src="/js/lib/modernizr-2.6.2.min.js"></script>
When I see "Don't use Safari", I interpret that as "I'm too lazy to make this work in Safari", rather than "this doesn't work in Safari".
The funny part is I probably still have a working copy of it on the SGI Onyx in my garage.
access main computer system please
access local security grid please
access yer mom please
That said, it's more fun to get it wrong...