I bought this last weekend, and it looks good. I'm seeing a lot of patterns I'd noticed, and he's brought up some that I can look back and say "Yeah, we did that - badly...."
He does a good job talking about the pragmatic decisions that real architects and senior developers make, as opposed to the idealists and purists. The OO purists may want each attribute's "get" to be a separate call (and maybe cause that call to traverse the network), but the Remote Facade builds much more efficient interfaces. I've been building Domain Models and Foreign Key Mappings for years, and calling them by terms close to those.
One of the things all these Patterns books have done is define a common terminology for concepts we've all known about. For that, if nothing else, we owe Fowler our thanks.
Duh! You obviously haven't read the entire RFC - there's a 128-bit field in there to denote whether the packet is evil for each segment of the network (like DDoS) or evil end-to-end, and to indicate relative strength.
Ahh, April 1 - the day Slashdot drags unsuspecting servers out into the sunlight, points thousands of browsers at them, and watches as they get hammered like baby seals....
That story took what, 30 seconds to crash 2 of those servers? You'd hope these guys could come up with something more original than PHP/mySQL error strings when their page generators choke and die... kudos to those whose servers managed to survive, even if they didn't bring up the right story.
IP over Avian Carriers with Quality of Service? Do I feed the pigeons spoiled grain, and let the receiver analyze the poop? Do I spraypaint them black? What if they're black already - do I spraypaint them white?
Clearly, this RFC needs a lot of work to integrate it into the Internet we've come to know and love.
Yippee! Yahoo! He picked my question and answered it! (does happy joy dance)
Now that that's over with... I think his answer makes projects like OpenSSL more important. We can all look over the implementations, they're thrashed by the community at large, and they've proven to be quite responsive when someone does find a vulnerability.
Now, off to my next assignment - writing an access rights repository using the M$ Foundation Classes Crypto API. *sigh*
I played a round of it last Christmas - my old C128 with the C64's floppy drive (the 128's died), and my old game disks. M.U.L.E. was good, although I eventually had to play single-player - noone wanted to play me anymore. Archon was good too - strategy of chess, action of an arcade game.
I remember thinking how cool it was that there were folks in Arkansas (where I grew up) that could write those things... I wanted to do that.
Years later, a friend and I wrote a game. It was fun, but the bad part of writing a game for your friends is that they tend to complain a lot if things aren't "perfect" - and few agreed on perfection.
Over the last couple of decades, cryptography has gone from being the domain of major governments, big business, and the odd hobbyist and researcher to being a massive public industry that anyone can (and does) participate in, with new algorithms published and new applications announced almost every week. Meanwhile, we learn of vulnerabilities in various implementations of cryptosystems much more frequently than we hear of people discovering fundamental flaws in the cryptosystems themselves.
Given these facts, do you think we need to change focus, turning to validating and "approving" implementations of cryptosystems (such as your own SSL 3.0) or should the emphasis of the "crypto community" continue to be innovation in fundamentals of cryptographic systems and new applications for them? How important is it to have someone verify that a cryptosystem is implemented well?
The effects are easy, nowadays... it still depends on the ability of the screenwriters, actors, and director to tell the story. Speaker and Nessus could be done, IMHO - they would probably be CGI, and it would be on a scale similar to Gollum in LOTR.
All that said, I still foamed at the mouth when I found out Verhoven had dropped the powered armor from Starship Troopers. He pretty much proved he couldn't direct, or select good actors, too.
I hope the Heinlein estate made good money off that monstrosity.
Hmmm... didn't see that in the article - if Apple's system actually tracked the songs you'd bought, then we get into a situation where people start sharing accounts to maximize the amount of music they can access while minimizing their contribution... if you can re-download a song you already "own", then a savvy group of college-student sorts could each put up, say, $100, and get 100n songs out of the deal, where n was the number of members...
Then the licensing terms would get tighter, and Apple would start to do IP-monitoring, and only allow users in a certain number of hours a day, and we'd have another flame war here on/. about all the evil corporations after they broke how we'd rigged the system.
when CDs can often be found for $10-12 or even less
Not sure where you're shopping, but popular CDs are running $14.99 around here (DC area) - you have to go to the used CD stores or the bargain bins to get down into the $10 range - and the used stores are only $2 or so cheaper than the new ones around here.
Besides, when was the last time you bought an album for the album and not just a couple of songs? Meatloaf? Pink Floyd? There aren't that manny artists producing thematic albums, instead of "compilations of 3-5 minute songs we just wrote."
I'd pay $0.99 a track to create my own version of someone's Greatest Hits.
Which would imply that if your patent gets tossed later for having screaming hordes of techno-geeks pointing out commercial and free prior art (Clearcase, CVS, even Oracle SCM) - the government should have to give you your money back.
Maybe even pay the legal fees of the folks who sued and presented trivially-findable prior art...?
And another all-new area will open up for the serious hackers - how to spoof a ticket authority.
Ever since the "loss" of a couple of M$ certificates, I've been cynical about the ability of organizations to keep these "services" going. In order for it to work, there has to be reciprocity - if Verisign recognizes Thawt certificates, Thawt had better recognize Verisign's - so what happens when someone spoofs Thawt to Verisign? The same things can happen here... with Real Money involved...
Why can't the person organizing and running the conference be allowed to decide who gets invited to speak and present?
If you want to have a "Paunchy Pale Perl Preacher's Pow-Wow", and happen to invite a deeply-tanned agnostic who programs in Python to speak - that's your right. Why are we second-guessing someone who's putting on a conference for government customers to meet Open Source Software up close and personal? If Tony thinks inviting M$ to speak is valid, maybe he has a point. After all, he's smart enough to get a gig at a place called the Cyberspace Policy Institute - he's probably also smart enough to realize the value of putting M$ and OSS up against one another in a public forum. It's NOT just a conference on Open Source - it's Open Source Software in Government. Speaking as a contracting creature, it's tough to sell - easier today than ten years ago, but non-trivial, whereas if you say you're buying Oracle, IBM, or M$, they just complain about the price - you won't get strange looks and questions about whether that will still be there in four years, and (valid) questions about lifecycle support.
Read his commentary and ponder - do you want to be a member of a group that won't even consider listening to members of opposing groups? That way lies extinction....
A little Googling, (the buddy and his dad weren't quickly available yesterday) and I found that the plant is question is owned by... FMC! So the bad news is, the company that's messing with Carmack is the one that shut down the plant... the good news is, the Bayport, TX plant (down JC's way) is the one that's supposed to make up for the reduction in capacity.
Not my dad - and no, not necessarily. It's industrial-strength stuff - I understand they can crank it out anywhere from 90% to 35% strength, depending on the customer. They're a bit ticked off - in the retiring guy's opinion, they're one of the few plants that can change the concentration of the stuff they make without major retooling (of course, I could have heard that wrong).
While I can't testify to your time-stuckedness (please repost if you run into Montana Wildhack), I can testify to Slashdot being verra, verra strange on the filtering tonight. This topic keeps going from 3 entries to over a hundred, and I'm not messing with my filters.
I'm sure it'll all be over soon. Move right along, nothing to see here....
Funny - my buddy's dad is being forced to retire from a 30-year career because the peroxide plant he works for in West Virginia is closing. They claimed "oversupply", obsolete equipment and processes, and bad market conditions.
I came to it from software, just finished a engineering Master's (although the CS degree was from the engineering school, back in Mississippi). Hardware folk still tend to think "We can solve that in software" and software people tend to have NO idea what's required to modify custom hardware. Still, I'd like every "system engineer" who wants someday to work with software people to be forced to work on a program where they have to the project's programming language(s), produce code (and have it reviewed by the team), test the code, document it the way the System Engineers want it - and spend a few nights in the lab debugging during integration, when the "software fixes" hit the hardware "oop"es.
Sounds like you have a nicely structured team. Keeping that kind of balance as a project scales up - that's the challenge of those management types that I'm afraid I'm growing up to be. Pray for me:-/
Hey, the author replies in the thread! Kudos to you, man...
Now, to reply - deployment is really neglected. It's not a thing the programming team often thinks of - they're busy implementing the class/module/function point they've been assigned, and they'll test it (hopefully in an environment close to the target), but there are so many ways software gets used these days, deployment changes quickly. Full-screen C++ apps using file-based storage became Java applets in a 3-tier system talking client/server to a database, then evolved into JSP pages using JBoss and mySQL.
My point is, deployment is a skill related closely to an ability to learn, and the patience to try things until they work, while documenting your every move so it can be recreated later. I'm only so-so at it, and have high regard for those who are good - but I'm not sure it's a skill every programmer needs.
Since I'm doing that "system architect" job at the moment, I feel like I can reply to this:->
If I didn't have years of prior experience hammering systems together, debugging custom code and off-the-shelf things made to play together in new and unforseen circumstances, and a few tens of thousands of lines of multiple languages of coding, I wouldn't be able to avoid the land mines that the folks who designed THOSE systems subjected me and my "tribe" to.
One of the glaring gaps in the last 15 years or so has been the one between the classic "system engineers" and "software engineers". The "System Engineers" have usually been hardware types, and have no problem saying "it's a software problem - deal with it" and making the poor code monkeys cope with their bad decisions. It's taken me years to get the credibility among those folks to make them listen to my opinions and actually change their minds; I was just a software guy, not a Systems Engineer. Now, I have a program manager who's former software, and a software manager who's former software, and I'm senior to our chief system engineer:-D. I can't dictate, but if it doesn't fit in with my architecture, I have a veto - and I'm consulted on every technical decision that's not already delegated to someone for implementation (I review those).
This may actually be my dream job - fortunately, we're doing well on it, so we're thought of well inside the company; unfortunately, we're meeting our schedules, so it'll end within the year *sniffle*. Then, I'll just have to find a way to keep myself out of management....
Like I said - Unobtainium. We're missing about a dozen technologies before we can even try something like this with carbon nanotubes - like ways to mass-produce enough of them to create a 100m wide, 36,000+km long structure (nano meaning "really tiny" to those who don't know - and that's referring to their length); then there's how we bond 'em together, attach things (like said elevator) to 'em, repair them - and, as you mentioned, get it up there in the first place.
The theorists have an answer for the conservation of momentum thing - we anchor it to a sizable asteroid at geosync, and stretch the tether outward to slingshot loads into space. Plus, whenever one "elevator car" starts up, another starts down.
Wonder what a nice thunderstorm would do to something like this? Noone's experimented with conductors that go out past the inner Van Allen belts before....
Only problem is, we need to find new supplies of Unobtanium to be able to build it. Oh, and the "force of the earth spinning around" part is wrong, too... read Niven and Barnes' "Dream Park" series, or Kim Stanley Robinson's Mars series, which has a pretty accurate model of what happens when there's an "oops" somewhere along your 36,000+ km cable and it decides to wrap itself around your planet a few times.
Incredible stuff, few engineers, short amount of time - and absolutely no control over their budgets. Read Ben Rich's biography - the Skunk Works has historically been a money pit. They'd figure out how to do a job, quickly and well, and then turn it over for production, but their price tag was enourmous.
The current Everquest UI also uses XML for customizing the user interface - there are megs of documentation and several nice-looking ones available for download at the various EQ fan sites.
Slashdot Mirror
I bought this last weekend, and it looks good. I'm seeing a lot of patterns I'd noticed, and he's brought up some that I can look back and say "Yeah, we did that - badly...."
He does a good job talking about the pragmatic decisions that real architects and senior developers make, as opposed to the idealists and purists. The OO purists may want each attribute's "get" to be a separate call (and maybe cause that call to traverse the network), but the Remote Facade builds much more efficient interfaces. I've been building Domain Models and Foreign Key Mappings for years, and calling them by terms close to those.
One of the things all these Patterns books have done is define a common terminology for concepts we've all known about. For that, if nothing else, we owe Fowler our thanks.
Duh! You obviously haven't read the entire RFC - there's a 128-bit field in there to denote whether the packet is evil for each segment of the network (like DDoS) or evil end-to-end, and to indicate relative strength.
-1, Offtopic.
Ahh, April 1 - the day Slashdot drags unsuspecting servers out into the sunlight, points thousands of browsers at them, and watches as they get hammered like baby seals....
That story took what, 30 seconds to crash 2 of those servers? You'd hope these guys could come up with something more original than PHP/mySQL error strings when their page generators choke and die... kudos to those whose servers managed to survive, even if they didn't bring up the right story.
IP over Avian Carriers with Quality of Service? Do I feed the pigeons spoiled grain, and let the receiver analyze the poop? Do I spraypaint them black? What if they're black already - do I spraypaint them white?
Clearly, this RFC needs a lot of work to integrate it into the Internet we've come to know and love.
Yippee! Yahoo! He picked my question and answered it! (does happy joy dance)
Now that that's over with... I think his answer makes projects like OpenSSL more important. We can all look over the implementations, they're thrashed by the community at large, and they've proven to be quite responsive when someone does find a vulnerability.
Now, off to my next assignment - writing an access rights repository using the M$ Foundation Classes Crypto API. *sigh*
I played a round of it last Christmas - my old C128 with the C64's floppy drive (the 128's died), and my old game disks. M.U.L.E. was good, although I eventually had to play single-player - noone wanted to play me anymore. Archon was good too - strategy of chess, action of an arcade game.
I remember thinking how cool it was that there were folks in Arkansas (where I grew up) that could write those things... I wanted to do that.
Years later, a friend and I wrote a game. It was fun, but the bad part of writing a game for your friends is that they tend to complain a lot if things aren't "perfect" - and few agreed on perfection.
Thanks for letting us ask you these questions.
:)
Over the last couple of decades, cryptography has gone from being the domain of major governments, big business, and the odd hobbyist and researcher to being a massive public industry that anyone can (and does) participate in, with new algorithms published and new applications announced almost every week. Meanwhile, we learn of vulnerabilities in various implementations of cryptosystems much more frequently than we hear of people discovering fundamental flaws in the cryptosystems themselves.
Given these facts, do you think we need to change focus, turning to validating and "approving" implementations of cryptosystems (such as your own SSL 3.0) or should the emphasis of the "crypto community" continue to be innovation in fundamentals of cryptographic systems and new applications for them? How important is it to have someone verify that a cryptosystem is implemented well?
Thanks, and I'll take my answer off the air
The effects are easy, nowadays... it still depends on the ability of the screenwriters, actors, and director to tell the story. Speaker and Nessus could be done, IMHO - they would probably be CGI, and it would be on a scale similar to Gollum in LOTR.
All that said, I still foamed at the mouth when I found out Verhoven had dropped the powered armor from Starship Troopers. He pretty much proved he couldn't direct, or select good actors, too.
I hope the Heinlein estate made good money off that monstrosity.
Hmmm... didn't see that in the article - if Apple's system actually tracked the songs you'd bought, then we get into a situation where people start sharing accounts to maximize the amount of music they can access while minimizing their contribution... if you can re-download a song you already "own", then a savvy group of college-student sorts could each put up, say, $100, and get 100n songs out of the deal, where n was the number of members...
/. about all the evil corporations after they broke how we'd rigged the system.
Then the licensing terms would get tighter, and Apple would start to do IP-monitoring, and only allow users in a certain number of hours a day, and we'd have another flame war here on
Or is that too cynical?
when CDs can often be found for $10-12 or even less
Not sure where you're shopping, but popular CDs are running $14.99 around here (DC area) - you have to go to the used CD stores or the bargain bins to get down into the $10 range - and the used stores are only $2 or so cheaper than the new ones around here.
Besides, when was the last time you bought an album for the album and not just a couple of songs? Meatloaf? Pink Floyd? There aren't that manny artists producing thematic albums, instead of "compilations of 3-5 minute songs we just wrote."
I'd pay $0.99 a track to create my own version of someone's Greatest Hits.
Which would imply that if your patent gets tossed later for having screaming hordes of techno-geeks pointing out commercial and free prior art (Clearcase, CVS, even Oracle SCM) - the government should have to give you your money back.
Maybe even pay the legal fees of the folks who sued and presented trivially-findable prior art...?
And another all-new area will open up for the serious hackers - how to spoof a ticket authority.
Ever since the "loss" of a couple of M$ certificates, I've been cynical about the ability of organizations to keep these "services" going. In order for it to work, there has to be reciprocity - if Verisign recognizes Thawt certificates, Thawt had better recognize Verisign's - so what happens when someone spoofs Thawt to Verisign? The same things can happen here... with Real Money involved...
Why can't the person organizing and running the conference be allowed to decide who gets invited to speak and present?
If you want to have a "Paunchy Pale Perl Preacher's Pow-Wow", and happen to invite a deeply-tanned agnostic who programs in Python to speak - that's your right. Why are we second-guessing someone who's putting on a conference for government customers to meet Open Source Software up close and personal? If Tony thinks inviting M$ to speak is valid, maybe he has a point. After all, he's smart enough to get a gig at a place called the Cyberspace Policy Institute - he's probably also smart enough to realize the value of putting M$ and OSS up against one another in a public forum. It's NOT just a conference on Open Source - it's Open Source Software in Government. Speaking as a contracting creature, it's tough to sell - easier today than ten years ago, but non-trivial, whereas if you say you're buying Oracle, IBM, or M$, they just complain about the price - you won't get strange looks and questions about whether that will still be there in four years, and (valid) questions about lifecycle support.
Read his commentary and ponder - do you want to be a member of a group that won't even consider listening to members of opposing groups? That way lies extinction....
A little Googling, (the buddy and his dad weren't quickly available yesterday) and I found that the plant is question is owned by... FMC! So the bad news is, the company that's messing with Carmack is the one that shut down the plant... the good news is, the Bayport, TX plant (down JC's way) is the one that's supposed to make up for the reduction in capacity.
Strange but true....
Not my dad - and no, not necessarily. It's industrial-strength stuff - I understand they can crank it out anywhere from 90% to 35% strength, depending on the customer. They're a bit ticked off - in the retiring guy's opinion, they're one of the few plants that can change the concentration of the stuff they make without major retooling (of course, I could have heard that wrong).
While I can't testify to your time-stuckedness (please repost if you run into Montana Wildhack), I can testify to Slashdot being verra, verra strange on the filtering tonight. This topic keeps going from 3 entries to over a hundred, and I'm not messing with my filters.
I'm sure it'll all be over soon. Move right along, nothing to see here....
Funny - my buddy's dad is being forced to retire from a 30-year career because the peroxide plant he works for in West Virginia is closing. They claimed "oversupply", obsolete equipment and processes, and bad market conditions.
Hunh.
I came to it from software, just finished a engineering Master's (although the CS degree was from the engineering school, back in Mississippi). Hardware folk still tend to think "We can solve that in software" and software people tend to have NO idea what's required to modify custom hardware. Still, I'd like every "system engineer" who wants someday to work with software people to be forced to work on a program where they have to the project's programming language(s), produce code (and have it reviewed by the team), test the code, document it the way the System Engineers want it - and spend a few nights in the lab debugging during integration, when the "software fixes" hit the hardware "oop"es.
:-/
Sounds like you have a nicely structured team. Keeping that kind of balance as a project scales up - that's the challenge of those management types that I'm afraid I'm growing up to be. Pray for me
Hey, the author replies in the thread! Kudos to you, man...
Now, to reply - deployment is really neglected. It's not a thing the programming team often thinks of - they're busy implementing the class/module/function point they've been assigned, and they'll test it (hopefully in an environment close to the target), but there are so many ways software gets used these days, deployment changes quickly. Full-screen C++ apps using file-based storage became Java applets in a 3-tier system talking client/server to a database, then evolved into JSP pages using JBoss and mySQL.
My point is, deployment is a skill related closely to an ability to learn, and the patience to try things until they work, while documenting your every move so it can be recreated later. I'm only so-so at it, and have high regard for those who are good - but I'm not sure it's a skill every programmer needs.
All IMHO, of course....
Since I'm doing that "system architect" job at the moment, I feel like I can reply to this :->
:-D. I can't dictate, but if it doesn't fit in with my architecture, I have a veto - and I'm consulted on every technical decision that's not already delegated to someone for implementation (I review those).
If I didn't have years of prior experience hammering systems together, debugging custom code and off-the-shelf things made to play together in new and unforseen circumstances, and a few tens of thousands of lines of multiple languages of coding, I wouldn't be able to avoid the land mines that the folks who designed THOSE systems subjected me and my "tribe" to.
One of the glaring gaps in the last 15 years or so has been the one between the classic "system engineers" and "software engineers". The "System Engineers" have usually been hardware types, and have no problem saying "it's a software problem - deal with it" and making the poor code monkeys cope with their bad decisions. It's taken me years to get the credibility among those folks to make them listen to my opinions and actually change their minds; I was just a software guy, not a Systems Engineer. Now, I have a program manager who's former software, and a software manager who's former software, and I'm senior to our chief system engineer
This may actually be my dream job - fortunately, we're doing well on it, so we're thought of well inside the company; unfortunately, we're meeting our schedules, so it'll end within the year *sniffle*. Then, I'll just have to find a way to keep myself out of management....
Like I said - Unobtainium. We're missing about a dozen technologies before we can even try something like this with carbon nanotubes - like ways to mass-produce enough of them to create a 100m wide, 36,000+km long structure (nano meaning "really tiny" to those who don't know - and that's referring to their length); then there's how we bond 'em together, attach things (like said elevator) to 'em, repair them - and, as you mentioned, get it up there in the first place.
The theorists have an answer for the conservation of momentum thing - we anchor it to a sizable asteroid at geosync, and stretch the tether outward to slingshot loads into space. Plus, whenever one "elevator car" starts up, another starts down.
Wonder what a nice thunderstorm would do to something like this? Noone's experimented with conductors that go out past the inner Van Allen belts before....
Only problem is, we need to find new supplies of Unobtanium to be able to build it. Oh, and the "force of the earth spinning around" part is wrong, too... read Niven and Barnes' "Dream Park" series, or Kim Stanley Robinson's Mars series, which has a pretty accurate model of what happens when there's an "oops" somewhere along your 36,000+ km cable and it decides to wrap itself around your planet a few times.
Incredible stuff, few engineers, short amount of time - and absolutely no control over their budgets. Read Ben Rich's biography - the Skunk Works has historically been a money pit. They'd figure out how to do a job, quickly and well, and then turn it over for production, but their price tag was enourmous.
The current Everquest UI also uses XML for customizing the user interface - there are megs of documentation and several nice-looking ones available for download at the various EQ fan sites.
Not only that, it'll have its own TCP/IP stack! You'll be able to dial-up to a phone line and connect to the Information Superhighway!