Re:Kids and Real Science don't mix
on
The Geek Atlas
·
· Score: 3, Interesting
Wow, what a sad post.
There are hundreds of thousands of applied science jobs that do allow you to get out of a cube and get your hands dirty. Two personal examples:
My father just retired after being a chemical engineer for 15 years (his second career). During this he spent most of his time in a laboratory or in the field working with manufacturers of physical goods to design processes that would yield good results with the chemicals they were using, or suggesting better alternatives. This often involved mixing up small batches of sealants, adhesives, etc. applying them to materials with different methods (brushing, spraying, etc.), and seeing how they held up. Not everyone's cup of tea, but certainly not spending a lot of time in a cube.
My hands-on experience is with an airplane manufacturer (Boeing), where I worked for 4 years in a lab that produces simulations for all of their commercial airplanes. Actual test data for physical systems like engines and control surfaces was combined with modules like autopilots and flight management into a 7 million line-of-code simulation that could be used to drive the complete flight deck.
True much of my week was in the cube, but very often, sometimes for days on end, we would be in flight deck replicas of the commercial airplanes (complete with hardware, hydraulic controls, etc. and simulated out-of-the-window view). We used the simulator to test behavior of new equipment in simulation, prototyping new displays for pilots, etc. Engineers in our sister group, Flight Test, actually got to test the equipment in flight.
In both examples above there were dozens of engineers at the same companies doing largely the same things we were, with different programs or areas of emphasis. In other words, there were many such opportunities, but everyone was "the expert" on some particular niche.
There is always an adjustment from academia to industry, and some disillusionment (I've found it happens with new engineers around the 1 year period once the novelty of joining the work force has worn off). As a hiring manager, I look for new engineers that can do the grunt-work but are still inspired to try new things and I've found that "new blood" can actually energize the entire team. I would say a goal for academia is to inspire students with a passion for science and discovery while preparing them for the discipline and sustained hard work required to succeed in industry.
I think it is actually destructive to suggest that creativity and inspiration are not important in science jobs, because the types of jobs that do not require these (in other words, that require a certain level of knowledge but are describable and repetitive), tend to be outsourced to contractors.
The screen showed a central nucleus, with spinning electron holes. Your job was to capture free electrons with your little ship and shoot them into the holes. You started with the first shell with 2 holes, one for H and one for He, and then the next shell of 8 appeared for you to fill, etc. etc. Eventually the screen got very cramped, which must be why they stopped at 54.
If you fired the electron and missed the hole, you'd hit the nucleus, and the whole thing would explode. Very frustrating once you had made it all the way to Germainium (I remember playing this game about the same time as the Jackson's Victory Tour, and being tickled that there was an element named Germainium, but I digress).
Re:5 years in the business...
on
Effective XML
·
· Score: 1
3) SOAP Okay, initially this actually seemed like a good idea to me, but having thought about it, I really think it sucks. Okay, so it is easier to implement SOAP for a particular platform or programming language, but a wire protocol is like a compiler or an OS kernel in a certain sense - it is okay that it is very hard to write, as long as it is stable and high performance, because it is such a central component.
Without regard to particular Web Services implementations (the ones I've tried have been difficult to use), the idea of an application communication protocol that is readily decipherable by tools and humans is pretty powerful. I think SOAP complements (not replaces) binary protocols like RMI, DCOM, or CORBA by providing for a looser coupling. For example, if the semantics of two particular services are the same or similar, it should be possible for a client to switch from one provider to another (or choose from multiple providers without modifying the application objects). The modification could instead be done in the binding between XML and application objects, or perhaps even by performing transformations on the XML going in and out over-the-wire. Loose coupling between systems is not impossible with RMI or CORBA, but is easier with SOAP in situations where the parties are independent and there is no possibility for everyone to conform to a standard language and interface.
Re:XML Limited in at least one regard.
on
Effective XML
·
· Score: 1
Sure, XML as a format is hierarchical, but various mechanisms can be used to represent arbitrary, non-tree structures in XML, and to categories a single entity in numerous ways. A simple example is defining an "id" attribute for a node and then using "ref-id" attributes elsewhere in the document as shorthand for repeating the original XML subtree.
More complex relationships can be expressed with more sophisticated mapping approaches: XTM is a good example of an XML dialect that can represent a semantic web of ideas and relationships between them.
A "Must Have"
on
Effective Java
·
· Score: 3, Informative
In my opinion, this book is a "must have" for anyone that wants to develop Java code at anything more than a casual level.
Many important Java techniques and idioms are described so well in this book that I have been known to insert comments to the effect of:
// Hash code implementation per "Effective Java" Item 9
(or some such) into my code. Most of the author's items should be as engrained in the mind of a Java developer as terms like 'singleton' and 'event listener'.
Obviously you didn't spend as much time with this wonderful game as shyster and I here. The command was "attack [hand]", as in "attack right" or "attack left", and if you actually typed it all out, you would get your ass handed to you even by a snake. Per the manual, you could use one-key abbreviations instead. The correct sequence is: "a r" "a r" "a r" *crack* ("r" key pops off from too much repeated abuse, and stone troll whacks you while you're trying to put it back on)
Oh, when its quiet and dark and there's no one around, I can still here the sound of that wizard in the distance, coming closer...and CLOSER...
I have an undergrad in Aerospace Engineering, and a Master's in Computer Science, and have worked for both an airplane manufacturer and a software company, so I like to think I know a little about both engineering and software. There are a million definitions of engineering out there. One of my favorites is this one (not sure if it's attributed correctly; it exists in many forms):
"An engineer is someone who can build for a dollar what a fool can build for twenty" - Robert A. Hienlein
I think that's a great results-oriented definition of an engineer, but doesn't say much about the practice itself. My own take is that engineers perform practical application of mathematic and scientific principles to produce artifacts that are useful in the real world. The analogies to bridge building always fall down at some point, but in many ways it holds: a structural engineer specifies a steel beam of a certain size and shape because of the loads it will bear. Many times, the parts choses are "don't care" or "cheapest available" because their function is not critical. Software engineering is a lot like that. As a software engineer, you choose a hashtable when fast, random lookup is important. Otherwise, you choose a list or array to iterate through. Software construction is thousands of decisions like that, both big and small. In the end, a good software engineer understands the fundamental principals (logic, math, algorithms, architecture) and how they relate to the building blocks of programming (loops, functions, sorts, searches, hashes), and so can produce programs that meet requirements with minimal cost along one or more axes (price, time to market, efficiency, etc.)
First of all, glad to see a lot of positive posts on this topic...I frequently see on this very same site laments about the dismal state of software. I am in agreement with the viewpoint that software developers continue to be more and more productive (through frameworks, code reuse, improved languages and tools, etc.), however the productivity hasn't resulted in improved software quality because we are simply being asked to do more complex tasks with the same schedule and resources.
One thing that has drastically improved my productivity is the Web itself (time on Slashdot notwithstanding), as a way to locate resources for programming. Almost any algorithm, component, or subsystem that is not specific to the problem domain can probably be found on the web, whether as a library, a set of source code, or simply a precise definition of an algorithm. I agree with one post that a lot of young developers would have difficulty writing a correct bubble sort, but anyone that attempts to design and implement a bubble sort on the job is wasting resources, since there is an implementation somewhere on the Web in any language you would want. In addition to software projects, informative articles and API documentation, newsgroup discussions are invaluable as well for pinpointing problems. So the Web is really my most important programming tool.
In conjunction with the Web, the vast supply of open source and free software out there that has drastically improved my productivity. The Apache Jakarta project and CPAN are my favorites, but there are many interesting projects on SourceForge and FreshMeat as well. Often, even if you are determined (or required by corporate standards) to roll your own, free software can give you a good idea about how others have approached the problem and the abstractions and metaphors they've used. In my experience, design reuse is often far more helpful and practical than actual reuse of code.
Perhaps it's just a sign of our times, that an active imagination is now considered to be a Bad Thing.
Ummm...films based on books (fantasy and otherwise) are not a new phenomenon. This site lists 165 in the fantasy genre alone, many produced pre-WWII. In fact, unless you're middle-aged, animated films for both The Lion, the Witch, and the Wardrobe(1979) and The Lord of the Rings (1978) existed before you read them.
The US government is not supposed to be in the business of "labeling" or "dealing with" cults; or small, emerging religions, to use an unbiased term. I like to think that the government shouldn't be "labeling" or "dealing with" anybody.
In fact, the government does have to make a distinction between religious and non-religious organizations for tax purposes. If I recall correctly, the federal government does classify Scientology a religion, thereby exempting at least some of its activities from taxation. Other governments (for example, some in Europe) will not recognize Scientology as a religion. The point is that even if a government has a tradition of non-interference in religion, it still will likely make distinctions between religions and non-religious organizations.
Re:But what can mortals achive?
on
Biking @ 80 MPH
·
· Score: 2, Informative
In the warm months, I bike to work 3 days a week (9 miles each way, suburban/urban, moderately hilly), and average about 18 mph. The difference in commute time (total time is under 30 minutes either way) between driving is very small, and faster in a bike when traffic is heavy. I am 27 and in average shape. It simply a matter of having a reasonably light road bike (a mid-level Trek, Cannondale, or Fuji -- weight about 20 lbs.) and letting your body condition itself for the ride.
I could ride on the same moderate terrain all day averaging about 16 mph, or on a long, flat highway at about 20 mph.
Re:Mercury (Perl has first-class functions)
on
ICFP 2001 Task
·
· Score: 1
No, because Perl isn't a functional language. *sigh*.
No, Perl has too many capabilities to be considered a purely functional language, however it does have first-class functions, so any program that can be created in more than one functional language (say Lisp and ML) can also be created in Perl:
Obviously, 10 years as a blanket maturation time for all software is over-the-top. But Spolsky does make some good points about software development.
His main points can be summarized in the statement that creation of new, non-trivial software is a "wicked problem"--it requires constructing an incomplete or unsatisfactory solution to fully characterize the problem in the first place.
A deep understanding of software design as a wicked problem will make you a better (and less frustrated) developer. For example:
Requirements will always fluctuate throughout the development cycle, because users cannot entirely formulate what they want until they have seen something close. For the same reason, requirements can never be fully formalized--the more explicitly complex behavior is described, the more likely it is not exactly what the user wants.
It is nearly impossible to get a complex design right the first time, even if you are among the very best. Design and build functionality slowly and incrementally, and expect to revise aspects of the design and code you didn't anticipate revisiting.
All non-trivial software has defects--you should accept this and spend time and effort developing an effective QA process, rather than treating QA as an afterthought or feeling guilty that your software has bugs. The development process lasts months, but the QA process lasts for the lifetime of the software. Concentrate on making the software better, not just fixing the bug at hand.
These are just a few points, acceptance of which will lead to more effective development. A big barrier to acceptance of the real difficulty of software is that we spent our formative years developing trivial, batch-oriented programs that our professors could run easily and grade objectively. With these programs, the requirements were known upfront (any ambiguities having been flushed out by repetition of the assignment), the program was known to be doable by most developers in the alloted time, and it could be completed bug-free. None of those things is certain in the real world. Yet we treat complex software as if it can be done this way. It doesn't work--"Zaro Boogs", anyone?
My experience with Tomcat is that it still has a lot of bugs/features under construction and is certainly not optimized for performance in the way that commercial servlet containers are. A more stable and robust servlet container (Allaire's JRun comes to mind) would have provided much more realistic numbers on JSP performance.
'hubie' is probably thinking of commercial jetliners (for example, 737s), which tend to cruise between 25,000 and 30,000 feet. Commuter aircraft, on the other hand, are generally turboprops with much lower service ceilings.
While it's appealing to suggest that Linux developers should implement all important (a.k.a. strongly hyped) standards and let the marketplace sort things out, I don't think its always in the best interest of the Linux community to do so. As mentioned, the forces behind WAP represent things repugnant to many open source developers--a standard developed in closed quarters by a group of corporate interests, a standard which (poorly) reinvents and fails to interoperate with existing Internet protocols, a standard rife with patents, and a standard which promotes a very restrictive Internet access model.
Why should developers and vendors spend their effort implementing and supporting a protocol stack which was developed primarily to serve a few select corporate interests? By implementing WAP, they would only be reinforcing it (support for a technology encourages use of that technology). People who use and work on Linux because it is free would be taking a step in the wrong direction to support WAP.
Of course, we are tempted to post the language we learned with (I learned basic on a TRS-80), but I think HTML is a really valuable 'programming' language for beginners to start with. No, it's not Turing complete, but it does get you used to the most basic and fundamental aspects of computer programming as well as a general purpose programming language does.
There are also some nice aspects of HTML which might appeal to newcomers, and especially kids. First of all, HTML is very forgiving, which is nice for a youngster ("Daddy, what's a GPF?"). Another is that they can post their work on the Internet instantly and show it off to their friends. A subtle (but important) lesson of HTML is that it's possible to obtain immense enjoyment out of something which is both free and relatively simple. Finally, HTML certainly has more practical value than a typical beginner language like BASIC or FORTRAN.
HTML also serves as a good launching point to learn a more complete language like BASIC or C: you understand that with more power also comes more complexity, and a greater potential for harm. Furthermore, the learner will already have multi-language experience and understand that different technologies are best suited to different tasks.
I was curious about Katz' new book Geeks, but don't feel like shelling out $16 for it. Now that I know he approves, could someone (perhaps Jon himself) direct me to an online copy, so that I can read it for free?
Alternatively, if anyone feels the same as I do, I would be happy to buy Jon's book, scan/OCR it, and post it on Slashdot. After all, I have Jon's permission now.
Who says you can't get a hug on the Web?
on
LonelyNet
·
· Score: 1
"E-mail is a way to stay in touch, but you can't share a coffee or a beer with somebody on e-mail or give them a hug,"
Slashdot Mirror
Wow, what a sad post.
There are hundreds of thousands of applied science jobs that do allow you to get out of a cube and get your hands dirty. Two personal examples:
My father just retired after being a chemical engineer for 15 years (his second career). During this he spent most of his time in a laboratory or in the field working with manufacturers of physical goods to design processes that would yield good results with the chemicals they were using, or suggesting better alternatives. This often involved mixing up small batches of sealants, adhesives, etc. applying them to materials with different methods (brushing, spraying, etc.), and seeing how they held up. Not everyone's cup of tea, but certainly not spending a lot of time in a cube.
My hands-on experience is with an airplane manufacturer (Boeing), where I worked for 4 years in a lab that produces simulations for all of their commercial airplanes. Actual test data for physical systems like engines and control surfaces was combined with modules like autopilots and flight management into a 7 million line-of-code simulation that could be used to drive the complete flight deck.
True much of my week was in the cube, but very often, sometimes for days on end, we would be in flight deck replicas of the commercial airplanes (complete with hardware, hydraulic controls, etc. and simulated out-of-the-window view). We used the simulator to test behavior of new equipment in simulation, prototyping new displays for pilots, etc. Engineers in our sister group, Flight Test, actually got to test the equipment in flight.
In both examples above there were dozens of engineers at the same companies doing largely the same things we were, with different programs or areas of emphasis. In other words, there were many such opportunities, but everyone was "the expert" on some particular niche.
There is always an adjustment from academia to industry, and some disillusionment (I've found it happens with new engineers around the 1 year period once the novelty of joining the work force has worn off). As a hiring manager, I look for new engineers that can do the grunt-work but are still inspired to try new things and I've found that "new blood" can actually energize the entire team. I would say a goal for academia is to inspire students with a passion for science and discovery while preparing them for the discipline and sustained hard work required to succeed in industry.
I think it is actually destructive to suggest that creativity and inspiration are not important in science jobs, because the types of jobs that do not require these (in other words, that require a certain level of knowledge but are describable and repetitive), tend to be outsourced to contractors.
I used to play this educational game for the TRS-80 called "Atom" http://nitros9.stg.net/atom.html.
The screen showed a central nucleus, with spinning electron holes. Your job was to capture free electrons with your little ship and shoot them into the holes. You started with the first shell with 2 holes, one for H and one for He, and then the next shell of 8 appeared for you to fill, etc. etc. Eventually the screen got very cramped, which must be why they stopped at 54.
If you fired the electron and missed the hole, you'd hit the nucleus, and the whole thing would explode. Very frustrating once you had made it all the way to Germainium (I remember playing this game about the same time as the Jackson's Victory Tour, and being tickled that there was an element named Germainium, but I digress).
Without regard to particular Web Services implementations (the ones I've tried have been difficult to use), the idea of an application communication protocol that is readily decipherable by tools and humans is pretty powerful. I think SOAP complements (not replaces) binary protocols like RMI, DCOM, or CORBA by providing for a looser coupling. For example, if the semantics of two particular services are the same or similar, it should be possible for a client to switch from one provider to another (or choose from multiple providers without modifying the application objects). The modification could instead be done in the binding between XML and application objects, or perhaps even by performing transformations on the XML going in and out over-the-wire. Loose coupling between systems is not impossible with RMI or CORBA, but is easier with SOAP in situations where the parties are independent and there is no possibility for everyone to conform to a standard language and interface.
Sure, XML as a format is hierarchical, but various mechanisms can be used to represent arbitrary, non-tree structures in XML, and to categories a single entity in numerous ways. A simple example is defining an "id" attribute for a node and then using "ref-id" attributes elsewhere in the document as shorthand for repeating the original XML subtree.
More complex relationships can be expressed with more sophisticated mapping approaches: XTM is a good example of an XML dialect that can represent a semantic web of ideas and relationships between them.
Many important Java techniques and idioms are described so well in this book that I have been known to insert comments to the effect of:
(or some such) into my code. Most of the author's items should be as engrained in the mind of a Java developer as terms like 'singleton' and 'event listener'.
"kill"?!?!
Obviously you didn't spend as much time with this wonderful game as shyster and I here. The command was "attack [hand]", as in "attack right" or "attack left", and if you actually typed it all out, you would get your ass handed to you even by a snake. Per the manual, you could use one-key abbreviations instead. The correct sequence is:
"a r"
"a r"
"a r" *crack*
("r" key pops off from too much repeated abuse, and stone troll whacks you while you're trying to put it back on)
Oh, when its quiet and dark and there's no one around, I can still here the sound of that wizard in the distance, coming closer...and CLOSER...
I'm going to hide under my desk now.
I have an undergrad in Aerospace Engineering, and a Master's in Computer Science, and have worked for both an airplane manufacturer and a software company, so I like to think I know a little about both engineering and software. There are a million definitions of engineering out there. One of my favorites is this one (not sure if it's attributed correctly; it exists in many forms):
"An engineer is someone who can build for a dollar what a fool can build for twenty" - Robert A. Hienlein
I think that's a great results-oriented definition of an engineer, but doesn't say much about the practice itself. My own take is that engineers perform practical application of mathematic and scientific principles to produce artifacts that are useful in the real world. The analogies to bridge building always fall down at some point, but in many ways it holds: a structural engineer specifies a steel beam of a certain size and shape because of the loads it will bear. Many times, the parts choses are "don't care" or "cheapest available" because their function is not critical. Software engineering is a lot like that. As a software engineer, you choose a hashtable when fast, random lookup is important. Otherwise, you choose a list or array to iterate through. Software construction is thousands of decisions like that, both big and small. In the end, a good software engineer understands the fundamental principals (logic, math, algorithms, architecture) and how they relate to the building blocks of programming (loops, functions, sorts, searches, hashes), and so can produce programs that meet requirements with minimal cost along one or more axes (price, time to market, efficiency, etc.)
First of all, glad to see a lot of positive posts on this topic...I frequently see on this very same site laments about the dismal state of software. I am in agreement with the viewpoint that software developers continue to be more and more productive (through frameworks, code reuse, improved languages and tools, etc.), however the productivity hasn't resulted in improved software quality because we are simply being asked to do more complex tasks with the same schedule and resources.
One thing that has drastically improved my productivity is the Web itself (time on Slashdot notwithstanding), as a way to locate resources for programming. Almost any algorithm, component, or subsystem that is not specific to the problem domain can probably be found on the web, whether as a library, a set of source code, or simply a precise definition of an algorithm. I agree with one post that a lot of young developers would have difficulty writing a correct bubble sort, but anyone that attempts to design and implement a bubble sort on the job is wasting resources, since there is an implementation somewhere on the Web in any language you would want. In addition to software projects, informative articles and API documentation, newsgroup discussions are invaluable as well for pinpointing problems. So the Web is really my most important programming tool.
In conjunction with the Web, the vast supply of open source and free software out there that has drastically improved my productivity. The Apache Jakarta project and CPAN are my favorites, but there are many interesting projects on SourceForge and FreshMeat as well. Often, even if you are determined (or required by corporate standards) to roll your own, free software can give you a good idea about how others have approached the problem and the abstractions and metaphors they've used. In my experience, design reuse is often far more helpful and practical than actual reuse of code.
Although for some reason this article forgot to mention the
drilling through glass part.
This site lists 165 in the fantasy genre alone, many produced pre-WWII. In fact, unless you're middle-aged, animated films for both The Lion, the Witch, and the Wardrobe (1979) and The Lord of the Rings (1978) existed before you read them.
The US government is not supposed to be in the business of "labeling" or "dealing with" cults; or small, emerging religions, to use an unbiased term. I like to think that the government shouldn't be "labeling" or "dealing with" anybody.
In fact, the government does have to make a distinction between religious and non-religious organizations for tax purposes. If I recall correctly, the federal government does classify Scientology a religion, thereby exempting at least some of its activities from taxation. Other governments (for example, some in Europe) will not recognize Scientology as a religion. The point is that even if a government has a tradition of non-interference in religion, it still will likely make distinctions between religions and non-religious organizations.
In the warm months, I bike to work 3 days a week (9 miles each way, suburban/urban, moderately hilly), and average about 18 mph. The difference in commute time (total time is under 30 minutes either way) between driving is very small, and faster in a bike when traffic is heavy. I am 27 and in average shape. It simply a matter of having a reasonably light road bike (a mid-level Trek, Cannondale, or Fuji -- weight about 20 lbs.) and letting your body condition itself for the ride.
I could ride on the same moderate terrain all day averaging about 16 mph, or on a long, flat highway at about 20 mph.
No, Perl has too many capabilities to be considered a purely functional language, however it does have first-class functions, so any program that can be created in more than one functional language (say Lisp and ML) can also be created in Perl:
http://perl.plover.com/lambda/
- Requirements will always fluctuate throughout the development cycle, because users cannot entirely formulate what they want until they have seen something close. For the same reason, requirements can never be fully formalized--the more explicitly complex behavior is described, the more likely it is not exactly what the user wants.
- It is nearly impossible to get a complex design right the first time, even if you are among the very best. Design and build functionality slowly and incrementally, and expect to revise aspects of the design and code you didn't anticipate revisiting.
- All non-trivial software has defects--you should accept this and spend time and effort developing an effective QA process, rather than treating QA as an afterthought or feeling guilty that your software has bugs. The development process lasts months, but the QA process lasts for the lifetime of the software. Concentrate on making the software better, not just fixing the bug at hand.
These are just a few points, acceptance of which will lead to more effective development. A big barrier to acceptance of the real difficulty of software is that we spent our formative years developing trivial, batch-oriented programs that our professors could run easily and grade objectively. With these programs, the requirements were known upfront (any ambiguities having been flushed out by repetition of the assignment), the program was known to be doable by most developers in the alloted time, and it could be completed bug-free. None of those things is certain in the real world. Yet we treat complex software as if it can be done this way. It doesn't work--"Zaro Boogs", anyone?Where's the "Filter Non-Adult Content" option?
My experience with Tomcat is that it still has a lot of bugs/features under construction and is certainly not optimized for performance in the way that commercial servlet containers are. A more stable and robust servlet container (Allaire's JRun comes to mind) would have provided much more realistic numbers on JSP performance.
'hubie' is probably thinking of commercial jetliners (for example, 737s), which tend to cruise between 25,000 and 30,000 feet. Commuter aircraft, on the other hand, are generally turboprops with much lower service ceilings.
Why should developers and vendors spend their effort implementing and supporting a protocol stack which was developed primarily to serve a few select corporate interests? By implementing WAP, they would only be reinforcing it (support for a technology encourages use of that technology). People who use and work on Linux because it is free would be taking a step in the wrong direction to support WAP.
There are also some nice aspects of HTML which might appeal to newcomers, and especially kids. First of all, HTML is very forgiving, which is nice for a youngster ("Daddy, what's a GPF?"). Another is that they can post their work on the Internet instantly and show it off to their friends. A subtle (but important) lesson of HTML is that it's possible to obtain immense enjoyment out of something which is both free and relatively simple. Finally, HTML certainly has more practical value than a typical beginner language like BASIC or FORTRAN.
HTML also serves as a good launching point to learn a more complete language like BASIC or C: you understand that with more power also comes more complexity, and a greater potential for harm. Furthermore, the learner will already have multi-language experience and understand that different technologies are best suited to different tasks.
Alternatively, if anyone feels the same as I do, I would be happy to buy Jon's book, scan/OCR it, and post it on Slashdot. After all, I have Jon's permission now.
Nonsense....
I KISS YOU!