> it's like apple have hired *all* the good
> minimalist product designers in the world and
> every other product has to be designed with
> virtually no sense of style
OK, so the ID might not be much on the Riot,
but did you check out the interface demo?
It may not be minimalist, but with just a few
extra items (play new, play things i haven't
listened to for a while, etc) they've captured
several listening patterns that are very common
and VERY difficult to compose from simpler
interface operations.
I was pretty impressed -- I think they've struck
a far better features / simplicity balance
than apple managed with the iPod
(although the riot's equalizer is pretty lame).
Re-reading my post, I guess it came across that I think XP, per se, is bad.
On the contrary, I feel that many of the assertions XP makes are quite good software engineering practices. However, I also feel that many professed adherents of XP become fascinated with the methodology and forget that, in the end, software engineering is about building a product that makes the customer (not the fake customer on your XP team, the real customer holding the checkbook) happy. This means that XP methodologies must be applied with careful judgement and an eye towards flexibility -- the most elegantly organized project in the world will still net you zero income if it doesn't get out the door on time with all of the required features.
That said . . .
> I've found that it makes a lot more sense to
> focus on testing the hard stuff, like this,
> than simple things like the ones you mentioned.
Exactly my point.
However, I think very few proponents of XP actually understand the principle outlined in this article, namely that XP is a set of best practices and NOT a color-by-numbers guide to successful software engineering. There's a great deal of XP fundamentalism out there, mostly on the part of development managers who are excited to the point of bursting by the childishly simple ABCs of XP according to [insert snide columnist here].
> By the way, it's also quite useful (totally
> apart from XP) to decompose such a beast into
> pieces you can test effectively.
Unfortunately, the actual code that inspired my description is about as atomic as you can get in an asynchronous system. A few inputs, a few outputs, and a very well-defined domain of functionality. However, both internal state and external state, as well as the timing of incoming messages, are quite complex, and non-trivial to simulate as part of a unit test.
My point being: unit testing is Hard in many situations, and most XP literature I've read glosses over that fact and downplays the necessity of picking the right things to unit test.
> Can you point to any project which did XP (most
> or all of it, not just talked about it) and
> resulted in an unhappy customer for that reason?
Well, I can't point to any project that managed to successfully implement "pure" XP, the kind that I've only seen in a training center. Most of the ones I know of that tried it gave up on it pretty quickly, usually because either:
1) They didn't have enough staffing to constantly pair program AND get all the necessary features completed
2) Their time frame wasn't sufficiently flexible to allow for the additional time incurred by XP-style unit testing (as opposed to a more traditional test suite).
3) Their Real Customer (not the XP customer) was not a nice and reasonable person with an understanding of how software development ought to work. He kept demanding additional features, some of which were negotiated away; the remainder necessitated that process be streamlined in order to deliver them on time.
While only a couple of these projects failed, they all wasted effort and money on implementing a methodology of which they had little understanding, but were led to believe was Just That Simple.
Nobody can sensibly argue that the generalities espoused by XP are bad. Testing is good. Iterative development is good. Refactoring is good. Pair programming *can* be good, in the right situations. However, the manner in which XP's principles are presented and disseminated (i.e. "the cult of XP") is, for the most part, misleading. Like most cults, The Cult of XP claims to have the one right and true solution to every problem in existence, which can be yours if you just do A, B, and C. Like many cults, The Cult of XP has some good things to say; in fact, it DOES benefit you to join up if your problem fits certain constraints. Also, unfortunately, like many cults, the Cult of XP is more interested in casting aspersions on its detractors (who are "afraid of change" or "unenlightened") than it is in engaging in serious examination of situations in which its dogma doesn't exactly hold true.
> In some situations you can avoid Unit Testing,
> some here are going to call me crazy for saying
> this but it is true. In a lot of high level
> applications, which are NOT used as libraries
> by other applications, you can bypass Unit
> Testing in order to increase development time.
> This is a dangerous practice but it is often
> outweighed by the extra functionality you will
> end up with in your product.
Amen.
While unit testing is important for key libraries, it's not a panacea. Inexperienced programmers can parrot the maxims of XP all they like, however the fact is a unit testing policy can create a terrible drag on application development if poorly implemented.
A sensible, real-world policy DOES NOT operate on the scale that %90 of the XP acolytes out there recommend. I'm sick to death of smug self-styled gurus (who, mysteriously, don't seem to do much programming since they started writing articles for Javaworld) that admonish us sloppy developers for our unwillingness to sacrifice key features in order to make time to build unit tests for every radio button. One of the most important components of unit testing is understanding the difference between a unit test and a waste of time.
Oh, and don't bother with articles or books that discuss unit testing, unless you interpret them in the most general terms. I've never seen an example of a unit test that wasn't unbelievably trite. Unit tests for an imaginary number storage class? Please. What about when the code unit you need to test manages asynchronous input from five different sources, where that input consists of five different complex packages of information that must be unraveled, interpreted, and transduced based on the code unit's multi-tiered internal state?
Unit testing is an art, not a science -- so don't sacrifice your project and your customer on the altar of XP. Explore unit testing, but don't embark on a comprehensive policy until you understand what you're getting into. A half-assed unit-testing policy is much worse than none at all.
. . . when distributing IP for the personal use of the consumer. I'm thinking specifically of cable TV and video rentals.
The advantage of cable TV is the subscription model. It's better for the consumer, because their cost-per-use tends to be lower. And it's better for the content producer, because their revenue is steady, reasonably predictable, and not subject to spikes and canyons in usage. Lesson learned: consumers vastly prefer to pay a subscription fee for a huge library of content from which they can pick and choose. Compare this to pay TV or video-on-demand, the revenues for which lag pathetically behind a the regular cable TV subscription base.
The advantage of video rental is, well, obvious. People who are not willing to pay $20 to own a copy of a movie may be perfectly willing to pay $3 to rent it for a few days. Lesson learned: cost-per-unit for "ownership" of content is too high for most people, if they're unfamiliar with the content in question.
Both modes of commerce are subject to piracy. However, the effect of piracy is mitigated by the fact that the copies which are made tend to be of lower quality compared to the original. Case in point: I'll tape every single episode of the Sopranos, but I'm still willing to shell out cash to own the Special Edition DVDs so that I can watch them in widescreen. Lesson learned: people like the freedom of making copies, but they're still willing to pay for a higher fidelity / more contentful version.
I think the real solution to DRM can be found in a subscription-based broadcast-on-demand model, which allows people to easily create (analog quality) copies to store locally on their machine or carry with them in their personal music player. People who want digital quality simply need to either a) buy the CD, or b) be connected to the network.
Now, this might not be very satisfactory in the short term -- your Rio-like device would be restricted to tape-quality music. But there's a great deal of push already to expand the country's broadband and wireless infrastructure -- in another 20 years it would probably be perfectly feasible for your personal digital music player to store nothing more than a playlist, wirelessly streaming the music as you go.
I think everyone wins under this model -- what little revenue companies lose from file trading would be more than compensated for by the subscription base, and consumers would have the choice and flexibility that they crave.
The Java platform was meant to serve as a networked computing platform, so it's got quite a few things built in that one would have to write as part of a plugin for another language:
flexible security model
Permissions are split into several categories, and a user can grant or deny permissions for each category instead of a blanket grant-permission for everything an applet might want to do to your machine.
platform independence
the Java standard library's API is written to abstract away a lot of platform-specific foo that you find in the standard library of other languages.
performance
yeah, Java takes a lot of crap for its performance problems. But Sun has spent almost a decade optimizing their VM to make it as fast as possible. An applet language MUST run inside VM or interpreter (for security and platform independence reasons) and writing one that provides even marginal performance for computationally intensive stuff is no easy task.
I suppose my company counts as a "fun" company. We have nerf toys. We have a beer fridge. We have a funky office in a refurbished warehouse. We have a 12-foot-high pile of hop-balls in an unused office. We have a monthly toy budget of $400. I work with a wide variety of interesting and creative people. However, I think that companies like this have existed since the beginning of the technology industry. Here's what makes them different:
1) Focus
We're a technology design company, with heavy emphasis on human factors. Part of our core competency is creativity. That's what clients pay for. Having a "fun" work environment impresses our clients (because they come to us looking for creativity) and improves our product (because it stimulates our employees). If we were, say, a web applications consulting shop, having a fun work environment would be more of a luxury and less of a necessity.
2) Values
My company is very fiscally conservative. In three years, we've grown from three people to twenty-seven. That's a snail's pace by dot-com standards. However, from day one, we valued having a fun, interesting work environment over aggressive growth. We carefully selected our clients and projects based on our capabilities and the scope of the project. We refused VC, instead funding our internal development via government contracts (which let you retain the rights to stuff you make). You simply can't have your cake and eat it too; a company has to decide early on whether they want to make jillions of dollars (and have a stressful, boring work environment) or enjoy themselves and do cool stuff (but make less money doing it).
3) People
A lot of the people at the crazy, funky dot-coms had no skills whatsoever. They were fresh out of college, and it was their youth alone that made them a hot commodity. A fun technology company CAN exist; however, like any company, if it's to survive it has to hire people based on their skills and experience rather than the number of their piercings. A successful fun technology company is very choosy about hiring people; it needs people who have both the necessary skills and the creative, funky, or bizzaro flair that fits with the company's culture. People like this are hard to come by, so naturally these companies tend to grow slowly. Even during the height of the dot-com fury, when kids fresh out of liberal arts college were getting $80K to write HTML, we were very selective about who we hired. If anything, our rate of rejection was higher than it is now. We moderated the growth of our business to match the growth of our employee base, because we wanted to hire only top-quality people.
For a little while, it was possible to have the best of both worlds: a company with a loose, wild culture that grew explosively and made its founders rich. However, now that the VC purses have snapped shut once more, we're back to reality: for a company to be "fun", its managers need to value the quality of life of their employees and the nature of the work that they do over pure profit. And, sadly, such executives are few and far between.
My Verizon DSL in Pittsburgh has been blocking incoming port 80 for about a week now. I haven't heard back yet from tech support. I haven't heard anything via email.
> 2) Verizon is not blocking smtp servers
Verizon here in Pittsburgh was blocking incoming 25 as of last summer.
> 3) Verizon isn't blocking any ports as far as I can tell
What city are you in?
> 4) Verizon IS preventing spam from being generated from their mail servers by requiring every piece of mail sent from their smtp servers to have a valid userid@verizon.net.
And, conveniently, railroading their users into either paying more for an outside smtp server or paying more for verizon's expensive vhosting.
There are other, less intrusive ways to prevent spam.
>5) Verizon will shutdown DSL accounts on a case by case basis if you computer account is being used to degrade overall network service (ie you are a spam or virus factory, and Verizon can trace the network congestion back to you)
One thing I will say for Verizon / Bell Atlantic DSL -- they have had fairly reliable service since I started with them (about a year ago).
However, this has proved to be the breaking point. I have no wish to deal with them any longer. I'm switching to a local DSL provider (telerama, for you yinzers in the audience).
When corporations start fucking you and complaining that you're ungrateful for it, it's time to vote with your wallet.
When I first saw this piece of news, I was very happy.
The reasons for this are obvious. Rambus' patents are bogus, were obtained fraudelently, and are being used as a tool to tax and stifle innovation, not contribute to it. This ongoing saga embodies the corruption and hypocrisy that permeates the current US patent system as it pertains to technology. So it's good to see a judge acknowledge an instance of abuse.
However, in hindsight, I begin to wonder: Did Rambus ever REALLY have a chance? Here's a single upstart company, with a few million in market cap (at first), trying to take on some of the biggest multinational technology companies in the world. Did they really think they would be able to win, armed with something as inconsequential as THE LAW? What if Rambus' patents were legitimate? Do you really think the outcome would be any different?
Why should we cheer on Micron, Infineon, and all the other corporations that have become targets of Rambus' litigious business model? Do we really think that, if they felt that they had a realistic chance of success, they wouldn't do the EXACT same thing that Rambus is doing now? Like any other corporation, none of the players in this game have any ethic higher than that of profit.
By all means, celebrate Rambus' defeat. For their unethical business practices, they deserve to burn. However, I view this case as nothing more than dueling firehoses of money. Rambus' firehose has less pressure to it, so they'll probably lose. Remember that Law is FOR SALE. If you can throw enough money at a good lawyer, a judge will overturn anything for you. Neat how that works.
When I see a legal victory in which principle and ethics triumph over money, when I see one of the many DeCSS defendents win their case, THEN I'll celebrate.
It's mainly for the folks who need a 2D, Java-based solution. It's pretty darn useful; lots of great projection math utilities, a nicely structured architecture, support for a wide variety of GIS products out there, and has transparent support for delivering imagery over a network.
Plus the platform of choice for primary developers (BBN) is Linux.:)
http://openmap.bbn.com
I strenuously object to the use of the term "entrepreneur" to refer to domain name brokers.
Entrepreneurs work for their success. They organize, they manage, and they assume the risk of building a profitable business. They rely on intelligence and a solid work ethic to be successful.
They do not exploit the rules of a flawed system to make a quick buck. Those who do are more properly referred to as hucksters, shysters, or carpetbaggers.
> My understanding was that the main reason for this was due to the Hardware Abstraction Layer, or HAL, in Windows NT.
Ah, OK. I suppose I'm not precisely aware of the underlying issues, however I understand the basic principles behind HALs and am slightly confused.
One of the reasons Be has so much trouble supporting a broad range of hardware is the utter coolness of their HAL. WinNT has / had only two core architectures to support (Intel and Alpha) while BeOS is targeted at several more. Given the resources Microsoft has at their disposal, they must have screwed up in a big way (either on the design of the WinNT HAL or the management of their programmers) to deliver such poor hardware support under NT.
*sigh* This is what happens when innovations are kept proprietary. Organizations come up with (potentially) clever and elegant architectures that they don't have the resources or the skill to implement and support, and the whole thing languishes in mediocrity.
> The game industry seems uninterested in supporting Windows NT 4. ^^^^^^^^^^^^^^^^^ You misspelled "Microsoft".
Microsoft wants to make sure that nobody can purchase just one version of Windows that meets all of their needs. Therefore, they have crippled NT as a gaming platform. DirectX on NT is only available in version 3.0, when it was pretty much unusable for anything except the most primitive operations. Human Interface Device support is absent. DirectSound support is absent. etc. etc.
Only companies like id, who have the financial and technical resources to make games with a minimal reliance on supporting technologies and APIs, can afford to deploy on Windows NT.
> Of course, the AWT package (for graphics) is not > particularly impressive, either in speed or in > basic window management such as redrawing.
The AWT may be slow, but it's a beautifully designed API. Our company does a lot of UI prototyping (UIs that need to be driven by massive amounts of actual data); each of our UI toolkits is built for rapid development, flexibility, and visual snazziness. These toolkits go through several iterations every year as they are tuned and refined -- without the simplicity and elegance of the AWT's rendering model, we'd be pretty screwed.
Granted, none of this stuff is intended for massive deployment on anything other than an intranet that's within the tight grip of a professional IT manager. The clumsy manner in which the JVM must be invoked under most OS's (mucking about with classpaths, command line invocation, the crappiness of netscrape- and ie's JVM) and, yes, the abysmal speed of more complex Java UIs severely hampers the wide distribution of Java user interface applications to Joe User. Just YAAWSHSTP (Yet Another Area Where Sun Has Screwed The Pooch).
The thing about XWindows being extremely high bandwidth, etc. over a network environment - this is surely true of ANY program that tries to control windows. If not - then this means that an extension to XWindows would be possible that DID cut down on the bandwidth.
mmm-hmmm. Here is one solution our company is hoping to use: Jazz. Jazz is a 2D scenegraph rendering API in java. If you've ever done any 3d work, you'll know that a scenegraph is basically a bunch of primitives (polygons, text, curves) organized in a tree structure with linear matrix transforms between nodes. This lets you scale, flip, stretch, etc. any portion of your scene simply by tweaking the values in a single transform node. More importantly, this lets you ship an arbitrarily complex user interface over the netwerk merely through specifying your initial scenegraph (with the addition of some serialized callback objects + wiring) followed by commands that mutate various nodes on the scenegraph.
But - it is fast. Very fast. And a lot of Java is based on C (syntax, etc) - a cut-down, partially redisgned version of C++ could look very similar to Java and be one heck_of_a_lot faster - even a Java-To-C++ translator that gave you C++ code to compile would probably end up faster than the native Java!
Well, the language design by itself isn't necessarily slow (although all the reflection APIs would definitely drag down any implementation). It really is the VM that makes Java annoyingly sludgy. There are a few competing efforts for a native Java compiler, the most prominent being GCJ.
In NEITHER area am I ANYTHING close to expert - so please feel free to correct me about any of the details that follow.
Not a prob.:)
[kersnip] On the other hand - any AWT stuff that I've tried to do is almost pathetically slow, especially compared to the X-Windows stuff that I've tried to do. I also suspect (but aren't sure) that the Swing components are add-ons to the whole AWT idea, and not a fundamental re-organisation of the AWT event model (am I right???).
Essentially, yes. The main difference between Swing and AWT is that every AWT widget has a native peer -- basically a hook into the windowing toolkit of the console's graphic environment. In Swing, every widget is "lightweight" -- it's drawn entirely through Java's neato rendering context APIs. This gives you a lot of flexibility and lets you do cool things like insta-double-buffering and translucent UI components with a minimum of effort. However, it is definitely slower.
The event model is the same for both Swing and AWT.
The reason that I say this is because there's lots of things about the AWT event model that suck - for instance, only one thread for the entire AWT system (how do you implement sprites easily? You can't - you have to manually write code that updates each one in turn. With new AWT threads being spawned at will, you could just "spawn" a new sprite with internal timing signals, and everything would be fine and dandy).
Ummm... there's only one *event* thread in AWT. You can have as many threads as you like merrily drawing away to the Graphics object of your choice. The single-event-thread system only screws you if you're doing something like multi-modal input (which I am:().
Look - XWindows was ALREADY a platform-independant and fast windowing toolkit (with networking capabilities too:-). Why didn't the Java guys just provide a set of wrappers for that???
Ever use X over a modem? Or any connection that wasn't a LAN? It is VERY high bandwidth, and therefore not a good thing to tie your windowing toolkit into when you are a networking-oriented language. And if you can't use X in that manner, why use X at all?
Wrapping X in a properly object-oriented fashion was probably more work than JS was willing to commit to.
Or at least provide a set of methods to interface with it?
We're using just such a toolkit in our next project to drive a wall-size display. No URL off the top of my head, unfortunately, but such things are out there.
Also - C++ (ANSI) is extremely fast and fairly standard. Java is basically a subset of the C++ methods, along with a whole bunch of new code ("libraries") and some kewl new ideas about method/class organisation, all organised in such a fashion as to make it platform independant.
OK, here's where I get pissed.:) C++ is a bastard hack. It is a crufty, inelegant glomming of some OOPy-sounding keywords onto a language that was NEVER designed to be used in an object-oriented fashion. The concept of OOP was around for a looong time before C++; Java is the first mainstream P/L to be architected from the ground-up with OOP in mind. THAT is why it has greatest programming language design in the history of computing (note my omission of the word "implementation";). The fact that Sun is harping this silly cross-platform angle is incidental.
[kersnip] So my opinion is that Java is an extremely good idea that was moderately badly implemented.
I think every real java programmer in the world would agree with you on that one. The fact that the Creator permits a virtual-platform networking-centric elegantly OOP language to be wholly owned by a traditional "big iron" computer corporation has contributed greatly to my cynicism and festering sense of misanthropy.
I think you've got it spot-on, although I would state #2 more generally as "an algorithm". This would actually be a neat way to patent algorithms (such as an audio codec) yet let them remain in the public domain: A claim on the actual _algorithm_ would be rejected (since it might be a no-brainer derivation of current techniques, e.g. 3dfx and single-pass multitexturing), but a claim on a method of business that DEPENDS on the algorithm would be accepted.
The really key insight in that article was a depressingly simple filter that the USPTO could be using RIGHT NOW: if a claim is merely the application of an established method-of-business in a networked environment, it should be thrown out. Of course, the model you've offered is much more useful, but it may be a little too complex for the poor mouth-breathers at the USPTO.
Slashdot Mirror
> That's what they're doing. The news article doesn't give an accurate impression of what's happening.
:)
Notice that the news article is hosted on excite.com, one of Google's competitors.
(OK, OK, it's an AP story, but I still think that's a little suspicious)
> it's like apple have hired *all* the good
> minimalist product designers in the world and
> every other product has to be designed with
> virtually no sense of style
OK, so the ID might not be much on the Riot,
but did you check out the interface demo?
It may not be minimalist, but with just a few
extra items (play new, play things i haven't
listened to for a while, etc) they've captured
several listening patterns that are very common
and VERY difficult to compose from simpler
interface operations.
I was pretty impressed -- I think they've struck
a far better features / simplicity balance
than apple managed with the iPod
(although the riot's equalizer is pretty lame).
Re-reading my post, I guess it came across that I think XP, per se, is bad.
On the contrary, I feel that many of the assertions XP makes are quite good software engineering practices. However, I also feel that many professed adherents of XP become fascinated with the methodology and forget that, in the end, software engineering is about building a product that makes the customer (not the fake customer on your XP team, the real customer holding the checkbook) happy. This means that XP methodologies must be applied with careful judgement and an eye towards flexibility -- the most elegantly organized project in the world will still net you zero income if it doesn't get out the door on time with all of the required features.
That said . . .
> I've found that it makes a lot more sense to
> focus on testing the hard stuff, like this,
> than simple things like the ones you mentioned.
Exactly my point.
However, I think very few proponents of XP actually understand the principle outlined in this article, namely that XP is a set of best practices and NOT a color-by-numbers guide to successful software engineering. There's a great deal of XP fundamentalism out there, mostly on the part of development managers who are excited to the point of bursting by the childishly simple ABCs of XP according to [insert snide columnist here].
> By the way, it's also quite useful (totally
> apart from XP) to decompose such a beast into
> pieces you can test effectively.
Unfortunately, the actual code that inspired my description is about as atomic as you can get in an asynchronous system. A few inputs, a few outputs, and a very well-defined domain of functionality. However, both internal state and external state, as well as the timing of incoming messages, are quite complex, and non-trivial to simulate as part of a unit test.
My point being: unit testing is Hard in many situations, and most XP literature I've read glosses over that fact and downplays the necessity of picking the right things to unit test.
> Can you point to any project which did XP (most
> or all of it, not just talked about it) and
> resulted in an unhappy customer for that reason?
Well, I can't point to any project that managed to successfully implement "pure" XP, the kind that I've only seen in a training center. Most of the ones I know of that tried it gave up on it pretty quickly, usually because either:
1) They didn't have enough staffing to constantly pair program AND get all the necessary features completed
2) Their time frame wasn't sufficiently flexible to allow for the additional time incurred by XP-style unit testing (as opposed to a more traditional test suite).
3) Their Real Customer (not the XP customer) was not a nice and reasonable person with an understanding of how software development ought to work. He kept demanding additional features, some of which were negotiated away; the remainder necessitated that process be streamlined in order to deliver them on time.
While only a couple of these projects failed, they all wasted effort and money on implementing a methodology of which they had little understanding, but were led to believe was Just That Simple.
Nobody can sensibly argue that the generalities espoused by XP are bad. Testing is good. Iterative development is good. Refactoring is good. Pair programming *can* be good, in the right situations. However, the manner in which XP's principles are presented and disseminated (i.e. "the cult of XP") is, for the most part, misleading. Like most cults, The Cult of XP claims to have the one right and true solution to every problem in existence, which can be yours if you just do A, B, and C. Like many cults, The Cult of XP has some good things to say; in fact, it DOES benefit you to join up if your problem fits certain constraints. Also, unfortunately, like many cults, the Cult of XP is more interested in casting aspersions on its detractors (who are "afraid of change" or "unenlightened") than it is in engaging in serious examination of situations in which its dogma doesn't exactly hold true.
> In some situations you can avoid Unit Testing,
> some here are going to call me crazy for saying
> this but it is true. In a lot of high level
> applications, which are NOT used as libraries
> by other applications, you can bypass Unit
> Testing in order to increase development time.
> This is a dangerous practice but it is often
> outweighed by the extra functionality you will
> end up with in your product.
Amen.
While unit testing is important for key libraries, it's not a panacea. Inexperienced programmers can parrot the maxims of XP all they like, however the fact is a unit testing policy can create a terrible drag on application development if poorly implemented.
A sensible, real-world policy DOES NOT operate on the scale that %90 of the XP acolytes out there recommend. I'm sick to death of smug self-styled gurus (who, mysteriously, don't seem to do much programming since they started writing articles for Javaworld) that admonish us sloppy developers for our unwillingness to sacrifice key features in order to make time to build unit tests for every radio button. One of the most important components of unit testing is understanding the difference between a unit test and a waste of time.
Oh, and don't bother with articles or books that discuss unit testing, unless you interpret them in the most general terms. I've never seen an example of a unit test that wasn't unbelievably trite. Unit tests for an imaginary number storage class? Please. What about when the code unit you need to test manages asynchronous input from five different sources, where that input consists of five different complex packages of information that must be unraveled, interpreted, and transduced based on the code unit's multi-tiered internal state?
Unit testing is an art, not a science -- so don't sacrifice your project and your customer on the altar of XP. Explore unit testing, but don't embark on a comprehensive policy until you understand what you're getting into. A half-assed unit-testing policy is much worse than none at all.
. . . when distributing IP for the personal use of the consumer. I'm thinking specifically of cable TV and video rentals.
The advantage of cable TV is the subscription model. It's better for the consumer, because their cost-per-use tends to be lower. And it's better for the content producer, because their revenue is steady, reasonably predictable, and not subject to spikes and canyons in usage. Lesson learned: consumers vastly prefer to pay a subscription fee for a huge library of content from which they can pick and choose. Compare this to pay TV or video-on-demand, the revenues for which lag pathetically behind a the regular cable TV subscription base.
The advantage of video rental is, well, obvious. People who are not willing to pay $20 to own a copy of a movie may be perfectly willing to pay $3 to rent it for a few days. Lesson learned: cost-per-unit for "ownership" of content is too high for most people, if they're unfamiliar with the content in question.
Both modes of commerce are subject to piracy. However, the effect of piracy is mitigated by the fact that the copies which are made tend to be of lower quality compared to the original. Case in point: I'll tape every single episode of the Sopranos, but I'm still willing to shell out cash to own the Special Edition DVDs so that I can watch them in widescreen. Lesson learned: people like the freedom of making copies, but they're still willing to pay for a higher fidelity / more contentful version.
I think the real solution to DRM can be found in a subscription-based broadcast-on-demand model, which allows people to easily create (analog quality) copies to store locally on their machine or carry with them in their personal music player. People who want digital quality simply need to either a) buy the CD, or b) be connected to the network.
Now, this might not be very satisfactory in the short term -- your Rio-like device would be restricted to tape-quality music. But there's a great deal of push already to expand the country's broadband and wireless infrastructure -- in another 20 years it would probably be perfectly feasible for your personal digital music player to store nothing more than a playlist, wirelessly streaming the music as you go.
I think everyone wins under this model -- what little revenue companies lose from file trading would be more than compensated for by the subscription base, and consumers would have the choice and flexibility that they crave.
flexible security model
Permissions are split into several categories, and a user can grant or deny permissions for each category instead of a blanket grant-permission for everything an applet might want to do to your machine.
platform independence
the Java standard library's API is written to abstract away a lot of platform-specific foo that you find in the standard library of other languages.
performance
yeah, Java takes a lot of crap for its performance problems. But Sun has spent almost a decade optimizing their VM to make it as fast as possible. An applet language MUST run inside VM or interpreter (for security and platform independence reasons) and writing one that provides even marginal performance for computationally intensive stuff is no easy task.
I suppose my company counts as a "fun" company. We have nerf toys. We have a beer fridge. We have a funky office in a refurbished warehouse. We have a 12-foot-high pile of hop-balls in an unused office. We have a monthly toy budget of $400. I work with a wide variety of interesting and creative people. However, I think that companies like this have existed since the beginning of the technology industry. Here's what makes them different:
1) Focus
We're a technology design company, with heavy emphasis on human factors. Part of our core competency is creativity. That's what clients pay for. Having a "fun" work environment impresses our clients (because they come to us looking for creativity) and improves our product (because it stimulates our employees). If we were, say, a web applications consulting shop, having a fun work environment would be more of a luxury and less of a necessity.
2) Values
My company is very fiscally conservative. In three years, we've grown from three people to twenty-seven. That's a snail's pace by dot-com standards. However, from day one, we valued having a fun, interesting work environment over aggressive growth. We carefully selected our clients and projects based on our capabilities and the scope of the project. We refused VC, instead funding our internal development via government contracts (which let you retain the rights to stuff you make). You simply can't have your cake and eat it too; a company has to decide early on whether they want to make jillions of dollars (and have a stressful, boring work environment) or enjoy themselves and do cool stuff (but make less money doing it).
3) People
A lot of the people at the crazy, funky dot-coms had no skills whatsoever. They were fresh out of college, and it was their youth alone that made them a hot commodity. A fun technology company CAN exist; however, like any company, if it's to survive it has to hire people based on their skills and experience rather than the number of their piercings. A successful fun technology company is very choosy about hiring people; it needs people who have both the necessary skills and the creative, funky, or bizzaro flair that fits with the company's culture. People like this are hard to come by, so naturally these companies tend to grow slowly. Even during the height of the dot-com fury, when kids fresh out of liberal arts college were getting $80K to write HTML, we were very selective about who we hired. If anything, our rate of rejection was higher than it is now. We moderated the growth of our business to match the growth of our employee base, because we wanted to hire only top-quality people.
For a little while, it was possible to have the best of both worlds: a company with a loose, wild culture that grew explosively and made its founders rich. However, now that the VC purses have snapped shut once more, we're back to reality: for a company to be "fun", its managers need to value the quality of life of their employees and the nature of the work that they do over pure profit. And, sadly, such executives are few and far between.
> 1) Verizon is not blocking web servers
My Verizon DSL in Pittsburgh has been blocking incoming port 80 for about a week now. I haven't heard back yet from tech support. I haven't heard anything via email.
> 2) Verizon is not blocking smtp servers
Verizon here in Pittsburgh was blocking incoming 25 as of last summer.
> 3) Verizon isn't blocking any ports as far as I can tell
What city are you in?
> 4) Verizon IS preventing spam from being generated from their mail servers by requiring every piece of mail sent from their smtp servers to have a valid userid@verizon.net.
And, conveniently, railroading their users into either paying more for an outside smtp server or paying more for verizon's expensive vhosting.
There are other, less intrusive ways to prevent spam.
>5) Verizon will shutdown DSL accounts on a case by case basis if you computer account is being used to degrade overall network service (ie you are a spam or virus factory, and Verizon can trace the network congestion back to you)
One thing I will say for Verizon / Bell Atlantic DSL -- they have had fairly reliable service since I started with them (about a year ago).
However, this has proved to be the breaking point. I have no wish to deal with them any longer. I'm switching to a local DSL provider (telerama, for you yinzers in the audience).
When corporations start fucking you and complaining that you're ungrateful for it, it's time to vote with your wallet.
When I first saw this piece of news, I was very happy.
The reasons for this are obvious. Rambus' patents are bogus, were obtained fraudelently, and are being used as a tool to tax and stifle innovation, not contribute to it. This ongoing saga embodies the corruption and hypocrisy that permeates the current US patent system as it pertains to technology. So it's good to see a judge acknowledge an instance of abuse.
However, in hindsight, I begin to wonder: Did Rambus ever REALLY have a chance? Here's a single upstart company, with a few million in market cap (at first), trying to take on some of the biggest multinational technology companies in the world. Did they really think they would be able to win, armed with something as inconsequential as THE LAW? What if Rambus' patents were legitimate? Do you really think the outcome would be any different?
Why should we cheer on Micron, Infineon, and all the other corporations that have become targets of Rambus' litigious business model? Do we really think that, if they felt that they had a realistic chance of success, they wouldn't do the EXACT same thing that Rambus is doing now? Like any other corporation, none of the players in this game have any ethic higher than that of profit.
By all means, celebrate Rambus' defeat. For their unethical business practices, they deserve to burn. However, I view this case as nothing more than dueling firehoses of money. Rambus' firehose has less pressure to it, so they'll probably lose. Remember that Law is FOR SALE. If you can throw enough money at a good lawyer, a judge will overturn anything for you. Neat how that works.
When I see a legal victory in which principle and ethics triumph over money, when I see one of the many DeCSS defendents win their case, THEN I'll celebrate.
It's mainly for the folks who need a 2D, Java-based solution. It's pretty darn useful; lots of great projection math utilities, a nicely structured architecture, support for a wide variety of GIS products out there, and has transparent support for delivering imagery over a network. Plus the platform of choice for primary developers (BBN) is Linux. :)
http://openmap.bbn.com
I strenuously object to the use of the term "entrepreneur" to refer to domain name brokers.
Entrepreneurs work for their success. They organize, they manage, and they assume the risk of building a profitable business. They rely on intelligence and a solid work ethic to be successful.
They do not exploit the rules of a flawed system to make a quick buck.
Those who do are more properly referred to as hucksters, shysters, or carpetbaggers.
> My understanding was that the main reason for this was due to the Hardware Abstraction Layer, or HAL, in Windows NT.
Ah, OK. I suppose I'm not precisely aware of the underlying issues, however I understand the basic principles behind HALs and am slightly confused.
One of the reasons Be has so much trouble supporting a broad range of hardware is the utter coolness of their HAL. WinNT has / had only two core architectures to support (Intel and Alpha) while BeOS is targeted at several more. Given the resources Microsoft has at their disposal, they must have screwed up in a big way (either on the design of the WinNT HAL or the management of their programmers) to deliver such poor hardware support under NT.
*sigh* This is what happens when innovations are kept proprietary. Organizations come up with (potentially) clever and elegant architectures that they don't have the resources or the skill to implement and support, and the whole thing languishes in mediocrity.
> The game industry seems uninterested in supporting Windows NT 4.
^^^^^^^^^^^^^^^^^
You misspelled "Microsoft".
Microsoft wants to make sure that nobody can purchase just one version of Windows that meets all of their needs. Therefore, they have crippled NT as a gaming platform. DirectX on NT is only available in version 3.0, when it was pretty much unusable for anything except the most primitive operations. Human Interface Device support is absent. DirectSound support is absent. etc. etc.
Only companies like id, who have the financial and technical resources to make games with a minimal reliance on supporting technologies and APIs, can afford to deploy on Windows NT.
> Of course, the AWT package (for graphics) is not
> particularly impressive, either in speed or in
> basic window management such as redrawing.
The AWT may be slow, but it's a beautifully designed API. Our company does a lot of UI prototyping (UIs that need to be driven by massive amounts of actual data); each of our UI toolkits is built for rapid development, flexibility, and visual snazziness. These toolkits go through several iterations every year as they are tuned and refined -- without the simplicity and elegance of the AWT's rendering model, we'd be pretty screwed.
Granted, none of this stuff is intended for massive deployment on anything other than an intranet that's within the tight grip of a professional IT manager. The clumsy manner in which the JVM must be invoked under most OS's (mucking about with classpaths, command line invocation, the crappiness of netscrape- and ie's JVM) and, yes, the abysmal speed of more complex Java UIs severely hampers the wide distribution of Java user interface applications to Joe User.
Just YAAWSHSTP (Yet Another Area Where Sun Has Screwed The Pooch).
mmm-hmmm. Here is one solution our company is hoping to use: Jazz.
Jazz is a 2D scenegraph rendering API in java. If you've ever done any 3d work, you'll know that a scenegraph is basically a bunch of primitives (polygons, text, curves) organized in a tree structure with linear matrix transforms between nodes. This lets you scale, flip, stretch, etc. any portion of your scene simply by tweaking the values in a single transform node. More importantly, this lets you ship an arbitrarily complex user interface over the netwerk merely through specifying your initial scenegraph (with the addition of some serialized callback objects + wiring) followed by commands that mutate various nodes on the scenegraph.
But - it is fast. Very fast. And a lot of Java is based on C (syntax, etc) - a cut-down, partially redisgned version of C++ could look very similar to Java and be one heck_of_a_lot faster - even a Java-To-C++ translator that gave you C++ code to compile would probably end up faster than the native Java!
Well, the language design by itself isn't necessarily slow (although all the reflection APIs would definitely drag down any implementation). It really is the VM that makes Java annoyingly sludgy. There are a few competing efforts for a native Java compiler, the most prominent being GCJ.
Oh well. Will nothing ever be done Right??? :-(
nope.
Not a prob. :)
[kersnip]
On the other hand - any AWT stuff that I've tried to do is almost pathetically slow, especially compared to the X-Windows stuff that I've tried to do. I also suspect (but aren't sure) that the Swing components are add-ons to the whole AWT idea, and not a fundamental re-organisation of the AWT event model (am I right???).
Essentially, yes.
The main difference between Swing and AWT is that every AWT widget has a native peer -- basically a hook into the windowing toolkit of the console's graphic environment. In Swing, every widget is "lightweight" -- it's drawn entirely through Java's neato rendering context APIs. This gives you a lot of flexibility and lets you do cool things like insta-double-buffering and translucent UI components with a minimum of effort. However, it is definitely slower.
The event model is the same for both Swing and AWT.
The reason that I say this is because there's lots of things about the AWT event model that suck - for instance, only one thread for the entire AWT system (how do you implement sprites easily? You can't - you have to manually write code that updates each one in turn. With new AWT threads being spawned at will, you could just "spawn" a new sprite with internal timing signals, and everything would be fine and dandy).
Ummm... there's only one *event* thread in AWT. You can have as many threads as you like merrily drawing away to the Graphics object of your choice. The single-event-thread system only screws you if you're doing something like multi-modal input (which I am :().
Look - XWindows was ALREADY a platform-independant and fast windowing toolkit (with networking capabilities too :-). Why didn't the Java guys just provide a set of wrappers for that???
Ever use X over a modem? Or any connection that wasn't a LAN? It is VERY high bandwidth, and therefore not a good thing to tie your windowing toolkit into when you are a networking-oriented language. And if you can't use X in that manner, why use X at all?
Wrapping X in a properly object-oriented fashion was probably more work than JS was willing to commit to.
Or at least provide a set of methods to interface with it?
We're using just such a toolkit in our next project to drive a wall-size display. No URL off the top of my head, unfortunately, but such things are out there.
Also - C++ (ANSI) is extremely fast and fairly standard. Java is basically a subset of the C++ methods, along with a whole bunch of new code ("libraries") and some kewl new ideas about method/class organisation, all organised in such a fashion as to make it platform independant.
OK, here's where I get pissed. :) ;). The fact that Sun is harping this silly cross-platform angle is incidental.
C++ is a bastard hack. It is a crufty, inelegant glomming of some OOPy-sounding keywords onto a language that was NEVER designed to be used in an object-oriented fashion. The concept of OOP was around for a looong time before C++; Java is the first mainstream P/L to be architected from the ground-up with OOP in mind. THAT is why it has greatest programming language design in the history of computing (note my omission of the word "implementation"
[kersnip] So my opinion is that Java is an extremely good idea that was moderately badly implemented.
I think every real java programmer in the world would agree with you on that one. The fact that the Creator permits a virtual-platform networking-centric elegantly OOP language to be wholly owned by a traditional "big iron" computer corporation has contributed greatly to my cynicism and festering sense of misanthropy.
I think you've got it spot-on, although I would state #2 more generally as "an algorithm".
This would actually be a neat way to patent algorithms (such as an audio codec) yet let them remain in the public domain: A claim on the actual _algorithm_ would be rejected (since it might be a no-brainer derivation of current techniques, e.g. 3dfx and single-pass multitexturing), but a claim on a method of business that DEPENDS on the algorithm would be accepted.
The really key insight in that article was a depressingly simple filter that the USPTO could be using RIGHT NOW: if a claim is merely the application of an established method-of-business in a networked environment, it should be thrown out. Of course, the model you've offered is much more useful, but it may be a little too complex for the poor mouth-breathers at the USPTO.