It's funny how CD/DVD burning software is the one that doesn't work Actually, what's funny is that CD/DVD burning software is the first thing I thought of when GP mentioned things that didn't work. I would't be surprised if high-end video cards that support HD video had issues, too.
It's all about the DRM, you see. MS has to be seen to control the entire transport path, to reassure its media partners that they can safely release their wares for Vista. I think I even read a story here recently that a VAR wound up replacing the disc burning software they normally bundled with the default Vista program, because their regular software had such serious issues. What do you want to be MS made them a pretty good offer to stick with the MS solution?
Sun (just like Mac [sic]) is not big enough to keep up with AMD and Intel on chip performance I dunno, I haven't seen either AMD or Intel shipping 8-core chips yet. Sun is. And I'll bet that 8 1.8GHz cores will beat 2 @ 3.4GHz...
So we're back to the original question, in a fashion: how to find a job where the path to advancement is not exclusively through management? I think the answer here is to make sure you're in a company that has a technical career track. IBM was famous for introducing this, and I think it exists in many large technical companies. The problem is, if your company doesn't have computer software as one of its primary products, then chances are slim they offer this kind of career path. If you want to stay technical, best bet is to work for a technical company. I know lots of guys in the insurance/banking field, and it's definitely expected that after you lead a successful project, you get promoted to management. The ones I know who didn't want to move to management left to join one of the many "development partners" (ISVs and consulting shops) that the banks and insurance companies use. That doesn't always end well, though, as some of them wound up becoming de facto project managers. All the hassle of tracking schedules, managing requirements and reviewing test results, without the title or the money (or the opportunity to design or code).
Actually, things weren't better before. The same technology that makes it possible for an assistant manager to take a receipe filing program and mung it into a contact management system has made it possible for developers to do in a couple of weeks what it would have taken a small team six months to do. We all benefit. But to say that experience gained before 1994 doesn't count because things are easier *now* disrespects the fact that it was because of the work programmers did twenty years ago that made things so easy to do today.
Seriously, when was object-oriented progarmming invented? Distributed systems? Multi-processor programming? The Internet? Scripting languages? All this stuff was invented decades ago, it just took Moore's Law this long to make most of it practical. If we'd all had bit-mapped windowing environments back then (instead of just those folks over at Bell Labs), we'd have been spared the horrors of Hungarian notation — if you don't remember a variable's type, just hover your mouse over it and the editor will tell you! Hell, CSS just celebrated its tenth birthday, the web itself is even older (not twenty-five years, probably closer to fifteen). Ruby's been around longer than that...
Hell, in my case, things are better now than they were just a couple of years ago. I remember spending days writing Perl scripts because the only thing worse than writing EJB deployment descriptors was getting XDocletto do it. Now, I just annotate my class with "@WebService", and it's all taken care of behind the scenes (as it should be).
Of course, some things are becoming too easy — it bothers me how many developers are writing code that automatically generates database tables. The problem is, they generally don't specify foreign keys, or constraints, or a lot of the other features that a good data model brings to the table...
I sure hope I get to be as cranky as you when I get older. Don't make me call your mother!
Programming was alot more of a magical/black-box back then Yeah, as opposed to the magical rainbow-colored box it is now...
People believe that they can outsource cheaply programming now. Well, that's good for you -- your boss probably doesn't notice that you can't write English any better than some offshoring consultant.
People can get a secretary to use Microsoft Office to do what you were programming in 1982, with the help of an animated paper-clip. Yep, and they'll fsck it up in ways that weren't even possible Back In The Day. Ever had to work with an Access database created by some guy in Marketing? Or try to debug an application written in Excel by an administrative assistant? Sure, they do the same things the apps I used to write did, they just take 300 lines of macro language running on an 800K-line interpreter/execution environment in 400M of memory to do what I did in 200 lines of C that ran in about 80K. And yet, the biggest difference in the end result is that my reports were in text format, instead of PDF.
But, at least people were able to write these new apps while they were seriously hung over (from the looks of their code...)
(call yourself a DBA and six figures isn't impossible to reach, but I'd stick to Database Developer if you don't want to carry a pager) Call yourself a DBA if you're a database developer and expect to get fired the first time the database spends more than a half-hour off-line. There's a big difference between writing some PL/SQL procedures and knowing how to call them from an app, and the nitty-gritty of DBA work. Development is more about following the rules (e.g., how to get to 3NF), DBA work is more about how to properly break the rules (e.g., partitioning, denormalizing).
Developers might have been able to hire themselves out as system operators back in the day, but a developer trying to hire themselves out as a DBA is just setting themselves up for a smackdown. That said, I've certainly known some developers who went on to become DBAs. I think every one of them wound up going to some form of DBA training, though.
FWIW, I've been a de-facto DBA for both Oracle and SQL Server. I can do some of the simple stuff (create a database, add more space, figure out why a table is locked and unlock it, gather statictics for the optimizer), but there's still a lot of voodoo I can't do.
Like, oh, say ClF5 (chlorine pentafluoride). It's a nice oxidizer: dense, liquid at room temperature (given a bit of pressure), and highly energetic. Of course, there's the issue of it being hypergolic with human flesh (and nearly everything else -- asbestos burns in ClF5), but really, it's got a lot of things going for it. Use it with a little hydrazine (N2H4) for full effect. Of course, hydrazine has its own problems (it becomes explosive under pressure, and is carcinogenic if you live through handling it;), but that doesn't seem to affect its popularity.
Sun seems to think that these boxes are hot stuff. They're gateway machines (as opposed to Gateway). Once you've got stuff running on Solaris on an 8-way Opteron box, and you find out you need more power, well, Sun will be happy to explain all about their new Niagra machines...
You dont see IBM giving away their AIX operating system for free, do you? Doesn't matter, nobody'd take it anyway... Seriously, AIX feels like System V was translated to Japanese, went through a generation or two of development, then was translated into English again. It's got some nice features (the first Unix I used with an LVM, lo these many years ago), but it's...I dunno, got an accent or something. It's just not right...
Nah, you could just have a timestamp register in the machine that contains its creation date. It validates the DRM against that date. Manufacturers would have to offer a timestamp update program for all machines over N years old. And the DRM code would have to be preserved, even after it expired, so in case someone came up with a way to defeat the timestamp in one machine (so they could copy some media), they'd have to defeat the timestamp in every "unauthorized" machine they wanted to use.
after spending much of a day visiting the company and talking to their staff, I was not sent so much as a courtesy "Thanks but no thanks" letter Was this out Portland way, by chance? I was unemployed for half of the two years I lived out there (2002-3), *lots* of competition for the rare development positions that turned up. With one company, I went through a phone interview, an on-site interview with the project leader, then another on-site, half day "tag-team" interview with management. After that, not only did they not send me a flush letter, but when I called after a couple of weeks just to verify that they weren't interested, the head of HR told me "Gee, I'm not sure what their decision was. Let me run down the hall and check." Then she puts me on hold, and ten minutes later hangs up without a word.
That was really the only bad one, though. Most places, if I got a phone interview, I got the job (short-term consulting gigs). The vast majority of places I applied to, though, just never responded. Which I understood, once I spoke with a recruiter who told me she had received over 300 applications for a position she had advertised, and they were still coming in over a week later.
Good for B2B web sites. But in the case of B2C web sites, will users in internet cafes, work break rooms, and public libraries have this option? What we've found is that school and public libraries are generally not "early adopters", so they mostly have older browsers anyway (hence our support for NS6 & 7). Not sure about internet cafes, but most work break rooms I've seen are in a similar situation. The real problem places, it seems, are actual offices, where the IE7 update was pushed out by the IT staff in order to stay current with Windows patches. Some of these places have the PCs so locked down that users can't install their own software. I did hear from one place, though, that actually rolled out FF alongside of IE7 because some of their internal apps weren't compatible...
I know IE5 and Safari can, because that's what was on one of the machines I tested my last project with — a Mac with an old release of OS X (.2, I think). Which turned out to be good, because the site worked all right with Safari 1.3, but not 1.0, which is what I had on the test box. So I got to add pre-1.3 Safari compatability (w00t...). FWIW, I also had NS6, 7.1, and 8.0 installed on my machine, along with FF1.5 and IE6. IE7 came out just a couple of weeks before we released, and when we found out that it wasn't compatible with our stuff, our solution was "recommend that users either find another computer to use to sign up, or have them install FireFox". From what I've heard, over 80% of the users elect to install FF (after they find out it's free);).
And while we're on the subject, mad props to the FireBug team. Not nearly as klunky as Venkman, and unlike IE's script debugger, it actually gives informative error messages (not "unable to perform operation on line 211")!
Let's face it, there are companies that make it on their technical excellence, and there are those that make it on their marketing. The sad thing is, it takes a fair amount of money to get by on just your marketing, so most companies that do were initially those that had some technical excellence. I think that's why geeks hate companies like Sony and Bose so much: it's like they sold out, milking their formerly-deserved reputation while cranking out products that are markedly inferior to their competition (except from the "ooh, shiny!" and thumping bass standpoints). Especially when they start protecting their reputation with heavy-handed legal maneuverings.
it was an OLD mainframe versus a PRESENT-DAY Linux grid The 2066-002 was released in 2002, it's hardly an "old" mainframe. I think their biggest advantage was in getting rid of everything they had, and starting from scratch. They could have done this on the mainframe too, and probably would have seen similar gains. From the description of their job load, it sounds like a typical data-processing environment (take huge amounts of raw data, sort/filter/categorize and store it), which is what mainframes were designed for. I'll bet they could have just written a new mainframe app to partition the data and then fire it off to an appropriate processing step. Run the processing steps in parallel and you've got the same basic idea as the grid. It sounds like their mainframe wasn't big enough, though — only two processors and 16G of memory. I'm sure they'd get better throughput with a 4-way box and the same amount of memory.
I'd be interested in knowing some more technical details of both set-ups, though: were they all using fibre-channel drives? A SAN? RAID? The backbone of these big DP shops is the storage bandwidth (which is where mainframes shine), could a lot of the increases in speed be accounted for by the increase in aggregate disk bandwidth? The Dell servers can host HBAs for FC SANs, but RH pushes their GFS/GNBD solution (storage servers w/ multiple Gb Ethernet ifcs), what really got used?
Um, you do know that there's a difference between audio CDs and CD-ROMs, right? I think I went through a couple of CD players before I first got a CD-ROM drive for my computer. I remember I had to get a SCSI expansion cab for it, since my computer (Apple Quadra 700) had NO HDD bays...
ISTR that BG & Co declared 1985 "the year of the CD-ROM". CD-ROMs didn't become generally available to home users for almost ten years. So, I guess that maybe in ten years we might see some significant robot usage (other than Roombas, which are still pretty cool).
Server functions will migrate to your desktop. Yep, and I've migrated them back off again. Nothing like trying to run make on a good-sized project when somebody suddenly decides to load 300+ snapshots into Postgres (even running Solaris). Now a database/file/print server sits on a milk crate next to the dehumidifier in the basement, and my desktop is no longer subject to the desires of others.
If you've got server functions running on your desktop, you don't have either a desktop or a server...
The PC revolution moved us away from a mainframe/terminal environment. Why would we want to move back to a similiar model? Well, what do you think the web is? You request a page from a server, it sends one back, your browser renders it. You change some data on it, hit "Submit", it sends the changes back to the server for processing, the server responds with another page. Lather, rinse, repeat...
Now go look up the detail of the 3270 display terminal protocol. Control characters define regions of the screen and assign attributes to those regions — sounds a lot like "<div style='background-color:black;foreground-color:gre en'>" to me. Those regions could be independently addressed — gee, just like named input fields! And the "read modified" command could read all the regions that had been modified with a single transfer. That's even better than HTTP, since a POST will send all the data in all form fields, whether they've been modified or not.
Too bad if you don't want to go back to a mainframe/terminal environment — we're already gone!
Plan on updating your QA and development data once a week. It's better if you simply give your developers the ability to update their development databases at will (perhaps by restoring from a weekly snapshot). I know several times I've set up some complex (and sometimes 'illegal', constraint-wise) data relationships to ferret out a particularly evil bug, and it can take time to recreate those. Plus, in a dynamic development environment, updating the database can require updating your code base as well (tables get added/merged/split/converted to views), which can be a non-trivial task. It can be frustrating to put your work on hold for half a day while you go chasing dependencies and merging your code with the head, only to have to turn around and do it all again a couple of hours later when you get your code working and want to merge it back.
For the record just a dev and prod environment isn't enough Actually, it could be. It sounds like this is a pretty small shop, so it's not unreasonable that developers develop something in dev, then have their account managers (or other responsible-as-in-accountable persons) review the changes, then roll them into production. Lots of web projects are easily broken down into discrete non-interdependent pieces that can be developed and rolled out separately. This is certainly true for the Perl and PHP shops I've worked in, much less so for Java (since you often have to deploy an entire war file to roll out new features).
ideally you would have multiple dev environments (individual playgrounds plus common test areas, two QA environments (New releases and current release for bugfix testing), and possibly even a User Acceptance Testing area. If you're running a large web site or creating a significant web-based application, this would be appropriate. The progression I usually see in "mature" shops is: development -> integration -> UAT -> QA -> production. Lots of places place UAT after QA, but if you're doing proper regression testing, then you waste a lot of time testing in QA every time the users decide they want the layout changed, or certain fields moved to another form.
In response to the original question, I'd suggest that each developer have a copy of the production system on their machine (which should be running Solaris using the same versions of Perl and Apache and whatever else you use), and there should be a separate test/QA environment (could probably be set up under its own zone on the production box). You'll also need to define processes for common tasks (release a new module, release a new version of an existing module, retire a module, roll back a module to a previous version, release a new version of the whole system, etc.) and document them. Then develop a process for keeping the documentation up to date. Wikis are good for this.
ISTR that Windows has actually supported foreign file systems since around Win98. At least, there's supposed to be an external file system layer, and some skeleton code in MSDN. However, the fact that nobody's written an extfs driver suggests to me that either it's too Windows-oriented, or the support is incomplete.
You don't have to be a pro driver to get the most out of a Ferrari on a race track. I've taken my Porsche on several tracks, as part of the PCA Driver Education program (basically a racing school without the high cost). I'd further argue that anybody who drives a Ferrari and slams on the brakes to avoid an accident is using it to the fullest, but I doubt that limiting "performance" to braking performance would sway much opinion...
Slashdot Mirror
It's all about the DRM, you see. MS has to be seen to control the entire transport path, to reassure its media partners that they can safely release their wares for Vista. I think I even read a story here recently that a VAR wound up replacing the disc burning software they normally bundled with the default Vista program, because their regular software had such serious issues. What do you want to be MS made them a pretty good offer to stick with the MS solution?
Seriously, when was object-oriented progarmming invented? Distributed systems? Multi-processor programming? The Internet? Scripting languages? All this stuff was invented decades ago, it just took Moore's Law this long to make most of it practical. If we'd all had bit-mapped windowing environments back then (instead of just those folks over at Bell Labs), we'd have been spared the horrors of Hungarian notation — if you don't remember a variable's type, just hover your mouse over it and the editor will tell you! Hell, CSS just celebrated its tenth birthday, the web itself is even older (not twenty-five years, probably closer to fifteen). Ruby's been around longer than that...
Hell, in my case, things are better now than they were just a couple of years ago. I remember spending days writing Perl scripts because the only thing worse than writing EJB deployment descriptors was getting XDocletto do it. Now, I just annotate my class with "@WebService", and it's all taken care of behind the scenes (as it should be).
Of course, some things are becoming too easy — it bothers me how many developers are writing code that automatically generates database tables. The problem is, they generally don't specify foreign keys, or constraints, or a lot of the other features that a good data model brings to the table... I sure hope I get to be as cranky as you when I get older. Don't make me call your mother!
But, at least people were able to write these new apps while they were seriously hung over (from the looks of their code...)
Developers might have been able to hire themselves out as system operators back in the day, but a developer trying to hire themselves out as a DBA is just setting themselves up for a smackdown. That said, I've certainly known some developers who went on to become DBAs. I think every one of them wound up going to some form of DBA training, though.
FWIW, I've been a de-facto DBA for both Oracle and SQL Server. I can do some of the simple stuff (create a database, add more space, figure out why a table is locked and unlock it, gather statictics for the optimizer), but there's still a lot of voodoo I can't do.
Like, oh, say ClF5 (chlorine pentafluoride). It's a nice oxidizer: dense, liquid at room temperature (given a bit of pressure), and highly energetic. Of course, there's the issue of it being hypergolic with human flesh (and nearly everything else -- asbestos burns in ClF5), but really, it's got a lot of things going for it. Use it with a little hydrazine (N2H4) for full effect. Of course, hydrazine has its own problems (it becomes explosive under pressure, and is carcinogenic if you live through handling it ;), but that doesn't seem to affect its popularity.
Fun facts to know and tell here.
Nah, you could just have a timestamp register in the machine that contains its creation date. It validates the DRM against that date. Manufacturers would have to offer a timestamp update program for all machines over N years old. And the DRM code would have to be preserved, even after it expired, so in case someone came up with a way to defeat the timestamp in one machine (so they could copy some media), they'd have to defeat the timestamp in every "unauthorized" machine they wanted to use.
That was really the only bad one, though. Most places, if I got a phone interview, I got the job (short-term consulting gigs). The vast majority of places I applied to, though, just never responded. Which I understood, once I spoke with a recruiter who told me she had received over 300 applications for a position she had advertised, and they were still coming in over a week later.
I know IE5 and Safari can, because that's what was on one of the machines I tested my last project with — a Mac with an old release of OS X (.2, I think). Which turned out to be good, because the site worked all right with Safari 1.3, but not 1.0, which is what I had on the test box. So I got to add pre-1.3 Safari compatability (w00t...). FWIW, I also had NS6, 7.1, and 8.0 installed on my machine, along with FF1.5 and IE6. IE7 came out just a couple of weeks before we released, and when we found out that it wasn't compatible with our stuff, our solution was "recommend that users either find another computer to use to sign up, or have them install FireFox". From what I've heard, over 80% of the users elect to install FF (after they find out it's free) ;).
And while we're on the subject, mad props to the FireBug team. Not nearly as klunky as Venkman, and unlike IE's script debugger, it actually gives informative error messages (not "unable to perform operation on line 211")!
Let's face it, there are companies that make it on their technical excellence, and there are those that make it on their marketing. The sad thing is, it takes a fair amount of money to get by on just your marketing, so most companies that do were initially those that had some technical excellence. I think that's why geeks hate companies like Sony and Bose so much: it's like they sold out, milking their formerly-deserved reputation while cranking out products that are markedly inferior to their competition (except from the "ooh, shiny!" and thumping bass standpoints). Especially when they start protecting their reputation with heavy-handed legal maneuverings.
I'd be interested in knowing some more technical details of both set-ups, though: were they all using fibre-channel drives? A SAN? RAID? The backbone of these big DP shops is the storage bandwidth (which is where mainframes shine), could a lot of the increases in speed be accounted for by the increase in aggregate disk bandwidth? The Dell servers can host HBAs for FC SANs, but RH pushes their GFS/GNBD solution (storage servers w/ multiple Gb Ethernet ifcs), what really got used?
Um, you do know that there's a difference between audio CDs and CD-ROMs, right? I think I went through a couple of CD players before I first got a CD-ROM drive for my computer. I remember I had to get a SCSI expansion cab for it, since my computer (Apple Quadra 700) had NO HDD bays...
ISTR that BG & Co declared 1985 "the year of the CD-ROM". CD-ROMs didn't become generally available to home users for almost ten years. So, I guess that maybe in ten years we might see some significant robot usage (other than Roombas, which are still pretty cool).
If you've got server functions running on your desktop, you don't have either a desktop or a server...
Now go look up the detail of the 3270 display terminal protocol. Control characters define regions of the screen and assign attributes to those regions — sounds a lot like "<div style='background-color:black;foreground-color:gr
Too bad if you don't want to go back to a mainframe/terminal environment — we're already gone!
In response to the original question, I'd suggest that each developer have a copy of the production system on their machine (which should be running Solaris using the same versions of Perl and Apache and whatever else you use), and there should be a separate test/QA environment (could probably be set up under its own zone on the production box). You'll also need to define processes for common tasks (release a new module, release a new version of an existing module, retire a module, roll back a module to a previous version, release a new version of the whole system, etc.) and document them. Then develop a process for keeping the documentation up to date. Wikis are good for this.
ISTR that Windows has actually supported foreign file systems since around Win98. At least, there's supposed to be an external file system layer, and some skeleton code in MSDN. However, the fact that nobody's written an extfs driver suggests to me that either it's too Windows-oriented, or the support is incomplete.
"Pizza, bah!"
"Your pizza is insignificant compared to the power of the Force!"
"Dude, pizza is, like, so last week, dude..."
ITYM scarfing pizza...
You don't have to be a pro driver to get the most out of a Ferrari on a race track. I've taken my Porsche on several tracks, as part of the PCA Driver Education program (basically a racing school without the high cost). I'd further argue that anybody who drives a Ferrari and slams on the brakes to avoid an accident is using it to the fullest, but I doubt that limiting "performance" to braking performance would sway much opinion...