This was a TECHNICAL conference, not a typical marketing dog and pony show. We were there to listen to what the speakers had to say (and a damned fine job they did too) not to look pretty or try and impress, but to learn.
Fair enough, dress however the hell you like, but the original poster does have a point. A sad fact of life is that the rest of the world relies on your external appearance to make a quick, initial (and probably wrong) judgement about you.
Of course its your right to dress not to impress, but if you want to promote your company, get a job, network (i.e. with people - not in the geek sense) or whatever, then why not give yourself every possible advantage, even if it means running an iron over your shirt before you head down.
I have over 200 cds worth of legally purchaced music ripped onto my jukebox. I have nightmares about the day i hook it up and whatever latent thing on my box destroys my whole collection. Just because i have copyrighted files on my computer doesn't mean i stole them.
Just two words for you:
back ups
Or should that be one word ?? Anyway, you have a good life is this is the stuff of your nightmares !!
Re:All this hype about XML
on
DTD vs. XML Schema
·
· Score: 4, Insightful
I discovered that XML was just a lot of hype about nothing.
Amen to that. Sad to say, but certain parts of the IT industry (and in particular, anything to with one computer (or piece of code) magically talking to another one owned by a different organization) are constantly buying into the bogus claims of snakeoil salesman with silver bullet technologies. XML is merely the latest in a long line.
The only new things about XML, IMHO, are that is has spawned more sub-specifications than any previous pretender to the crown.
Anyone remember CORBA ? Or any of the other zillions of RPC-type mechanisms that people have jumped on the bandwagon of ?
I'm not blaiming the people who push these agendas. I too would love to spend my weekends sunning on the beaches of exotic European tourist destinations and chugging beers on my expense account. The price of sitting through a ferw stiflingly boring and pointless standards meetings seems a small price to pay. All large IT companies employ 2 or 3 people whose job it is to front up to these meetings. Typically these people are articulate and highly versed ex-programmers but architecurally challenged and with little understanding of the real nature of building complex IT systems.
Ultimately, these RPC mechanisms all end up as nothing - or rather, as only perhaps 1% of the eventual solution.
All that XML is, is an easy-to-parse, text based data transfer mechanism. And as the parent posting says, there are some nice tools around for it. Big deal. Probably you'd be silly to use anything else if designing a data transfer. But is it ever going to change the world ? Or even rock it a little ? No.
The question is, at best, a little too simplistic: Which is the best cross-platform GUI toolkit that provides native look and feel? Which is the best overall?
I myself would favour Swing over others, though I'm really only fully conversant with MFC. But I fully realise that it depends what you're doing.
If you're building a mass-market app you plan to sell you all of the great unwashed out there, then you probably need to make it look very Windows-centric. Practically speaking, something like a turbo tax is probably going to get 99% of its revenue from Windows users. Its crazy to use anything - like Swing - that doesn't give you the best, most up-to-date look on Windows (though Sun would claim it is native look and feel). Use MFC or something like that.
If on the other hand you're building something like an IDE, other factors come into play. The fact that your app runs on linux as well as Windows will probably be a key sales point to your target audience. And your app is probably far more complex than a mass market app - meaning you need good productivity and a strong underlying architecture(which, IMHO, Swing gives you). Your users are likely to care less about the memory requirements of a technology like Swing.
Or as a final example, if you're writing a game, then screw their sheety GUI ! Code everything yourself from lines, dots, and mouse events. Make your list boxes scrollable using human skulls as thumbtabs, have rats running up and down inside your text fields to show focus. (personally I would also use Swing for this but realise that may be straying into personal predjudice).
In summary, its no good saying "whats best". It depends on what you're coding.
1. Require username/password - unless these are paid for, it's hard to stop people from registering
Kind of obvious but slashdot itself shows another alternative, which is to leave accounts free but allow them to build up value over time in the form of a pseudo-curency (karma). This works well to the extent that people, once they've acquired their hard-earned karma, are less likely to act in a troll-like way.
Of course you still get the puerile pests who start their troll-like uterances with something like "You might think I'm trolling but I've reached my karma cap so f*** you, I'll say what I want".
Personally though I find the stuff at less controlled places like fucked company's message boards pretty funny though, just because they are populated by nothing but trolls.
This is a testament to the power of free software: this sort of innovation could never happen if it weren't for the free software nature of the underlying systems.
At the risk of being bitchslapped into troll-land, I'd go further and say that probably a company like MS is the only one thats going to pull this off.
I'll be honest and admit I haven't thoroughly reviewed this approach for newness - and anyway I'm no expert. But, as many other posters have pointed out, this sort of thing is not new and the problem (and many so-called "solutions" for it) has been around for a very long time indeed.
This is one of those problems that is very difficult to solve because it goes to the heart of user behavior, and users are, well, awkward.
Anyway can support metadata descriptions in n forms, relationships between documents, etc., etc. The problem is in developing a solution that users actually use. Not one that demos well, one that is so natural that when I'm looking for something that Jane in Acounts put there, I can assume she used it when she created the doc.
That involves a lot of very un-open source like work. Interviewing thousands of Janes. Spying on them in usability labs. Building endless iterations and prototypes and measuring the success of each one. Making sure the approach translates well into otehr languages and cultures. Thats the sort of thing that takes real big-company resources.
If this problem was as simple as having an "Ah Hah !" moment, it would have been solved twenty or more years ago.
I don't think that Laos needs free Internet connections. I think what they need is houses, and a literacy rate above 60%. How do expect a small village, only 60% literate, to know how to use the Internet?
I agree theres a whole lot of other stuff they need more than internet access. But, if thats whats on offer, I wouldn't say it is useless because of high illiteracy rates. It might only take one semi-literate person in a small village, AND some compelling content, to plant the seeds for others to teach themselves to read. It might be surprising just what people can teach themselves, and perhaps the internet could be the key to reducing illiteracy.
When I was studying we used an old (very old) Burroughs mainframe. It had a loudspeaker hooked up to one of the bits of the program counter (a register that equates to what piece of code is currently being executed). To give an idea how slow this machine was, a typical program produced a crazy bunch of tones somewhat like a dial-up modem synching itself up.
But if your program entered a loop, the loudspeaker started emitting a very high pitched and steady tone. You could tell other things by listening too - depending on whether the whole "kernel" was looping or not, you might hear individual interrupt handlers breaking in. It was actually a pretty cool tool and I have often considered how difficult it would be to build a UI (not that there was any such thing as a UI in those days) that gave the equivalent information.
CPUs are now way too fast of course and do too many things at once to make this approach any use. But I think it could be a very useful way to very quickly get a good estimation of the quality of a network connection.
Whether you'd want to start open heart surgery based on that estimate is another matter of course.
I won't invest in a company who has at it's head a man who spends to excess. *Cough*Oracle*ahem*. If Priest is spending money like water, then the money isn't going towards the product, real or not, it's going towards his personal taste, and that nets the investor nothing
I think you've confused the company's money and the employee's money. You probably wouldn't care if employee #2708 spent all his money on cladding his house in the burbs with faux bricks, so why should you care if employee #1 wastes his on fast cars and the like ?
In this guys's case, you might have a point, since he's probably the only employee and he really IS the company, but why begrudge Larry or Paul Allen or any other successful business the fruits of their labour/ingenuity/luck or whatever ? Presumably you would only invest in companies where the boss lives in a trailer parked out back of the office ?
One of the biggest issues we have is trying to placate potential customers that are worried about us going out of business and leaving them with un-supported code.
To get around this, we've put copies of source code, with docs, build environments/scripts, etc., in escrow. This way, if we DO go down in flames, all registered license holders of our software are entitled to complete access to EVERYTHING required to support the software themselves.
We went through a similar discussion at my company with a very very large software company (OK, the largest) that licenses our Java technology. Their view was that escrow was no good for several reasons. One was that there was no guarantee that the escrow actually contained "everything". A true escrow service that guarantees this would have to do a complete build, and then release the result to the customer for them to check it is complete. Further, some skilled and independent authority would need to verify that the build was truly done from source and there were no binaries in it.
After considering these and other objections for a while, they did seem reasonable and escrow is not as simple as it looks to be.
Is it possible to have good products without "good code?" Depending on the product, I think yes
I agree with this. It is possible to write good software that has somewhat lousy code inside it. For exampe, an inefficient sort algorithm that is only used when a rarely-accessed administration screen is displayed. The code may be inelegant but practically speaking it does not matter and there is no reason for the vendor to be called up on it (which some smart-arse certainly would "ha ha Microsoft used the Breighton-Whirst Bubble sort when the Langer-Turston would have been 100 times faster ! What dipsticks !").
Much more important to quality of apps are "bigger picture" items such as schema designs for any RDBMS-based product (readily available now without the source code) or external interfaces (which, to use MS Word as the extreme example, it is made clear by the vendor that they do not intend to adopt any industry format nor to even be bound even by their own published formats).
Yeah but I can't help feeling that old cars, boats and aeroplanes are very very sexy and likely of interest to most of the inhabitants of the planet, and, yeah, to be honest might well help get you laid...whereas consider whether you could muster quite the same charisma offering to show someone over your collection of rebuilt dental hygiene equipment (for example)...
If the window is loaded, but not shown, then everyone wins except the advertiser.
Actually, only in the very short term is the advertiser the loser. Its better than that in the medium term, because the advertisers will become aware that there is stealth technology out there that is ripping them off. They'll say to the double-click or whoever "how bad is this problem ? can you guarantee that ANYONE is actually seeing the ads I pay for ?".
Then doubleclick become the loser - and its a bad place for them to be because its hard for them to reassure the advertiser since they have very little idea how bad the problem is. Their service will become valueless, their stock will fall (further) and their houses and boats will be repossessed.
Look out for MS's righteous rage when the forged MAC addresses start colliding with existing, non-hacker users and it disrupts the Live service they've paid for! Can anyone say "bolt the door, the wolf's outside" ?
It takes for-profit companies, with a lot of money to throw at the problem, to design original and effective UI's.
This is utterly true, and it is refreshing to see someone highlighting it. To go even further, designing an effective UI is something you simply can't get right in one go, no matter how much money and experts you throw at it. Most products only develop a good UI after several versions, based on a *lot* of user feedback.
So Microsoft has to fork out on developing this great UI, and anyone who cares to can come along and pick it up for free and leverage it. Thats a great thing. And ironically its how Microsoft got where they were in the first place - not by being great innovators but by being "fast followers".
There might be a lot more OSS successes if more people swallowed their pride, decided they didn't have to reinvent the wheel, and became fast followers themselves.
There is one thing that has puzzled me about slashdot. That is that very seldom (perhaps never, at least I've never seen them) are any meta-topics posted like "why does the karma system work the way it does". Furthermore anyone who does raise such issues seems to (according to their moaning sigs and bitter journals anyway) be ruthlessly modded down as offtopic, perhaps even causing them to go all feral and troll-like.
What about some discussion that would release these pent up forces and dispel the illusion of "Gulag Taco".
Rant is right. The issue of seawalls is a little more complex than you make out.
You say never build that close to a beach. The thing is, cliffs and foreshores move over time. It may happen gradually, or there may be a huge slip that moves the coast inwards by many yards overnight. So when you say "don't build that close to a beach", how not close is not close enough ? Where I live the same discussion is going on. The council discourages building seawalls. Trouble is, theres only one line of houses, then the public road. What happens when the houses are gone and the road comes under threat ? In some parts of the UK the land is disappearing at the rate of up to 5 metres per year.
Sure, developers who want to create huge unnatural structures that play havoc with the natural wave and current patterns should get a hard time. But its a bit too simplistic to just say "never build near the sea".
Offtopic perhaps but what a delight to see a cheap and cheerful web page that looks like it will survive a slashdotting storm, nothing but good old text and links on it, loads up like lightning...
We salute you "www.pacific-cable.org" - and not least for saving us from a bushel of lame jokes about the/. effect...
The article seems utterly light on some key information (about which file formats etc), but simple information theory suggests that this will only work on less-than-optimal image formats.
Any optimal image format will result in a file only just big enough to store the image and no bigger - and therefore it will not be able to store any additional data without reducing the image quality in some way.
Without any further information available, could it be they are just talking about taking advantage of flaws in some given format such as jpeg ?
Pull your head in paperclip man. I am in total agreement with your analysis of the paper from the little I read of it, and from my own strongly held but flawless prejudices against computer science BS by people who've never built a real system in their lives. And I did not in fact call you snotty or pertentious (sic) (though now I believe I justifiably could).
I didn't read the paper either, but you, my friend, are 100% right. It IS a lot of pretentious academic twaddle. I know this, because by spending 60 seconds or so reading the snippets plucked from the paper by the erudite slashdot readership, like golden berries plucked from the tree of knowledge, I have a composite knowledge of the paper that is far greater even than the authors themselves possess.
...and of course I have some primo skank here that has tken me even beyond the bounds of understanding possible to mere earth-bound mortals...
Though your polysyllabic observation does indeed lead to the inference that you know what you're talking about, I have always heard (and read) the opposite so could you point us to a definitive source that backs up your statement ?
despite the fact that nine out of ten slashdotters constantly complain about abuse of the patent system, almost every top-rated comment in this thread recommends that the submitter patent first and decide whether or not to extort later.
Reminds me of the psychology experiment conducted at an army barracks which had ten washbasins shared by all the soldiers for their morning ablutions.
The experimenters removed the plug from one of the basins overnight. By the next day, all the other plugs had been stolen by soldiers who may not have agreed with plug stealing but sure as hell weren't going to be the ones who had to go without.
Slashdot Mirror
Fair enough, dress however the hell you like, but the original poster does have a point. A sad fact of life is that the rest of the world relies on your external appearance to make a quick, initial (and probably wrong) judgement about you.
Of course its your right to dress not to impress, but if you want to promote your company, get a job, network (i.e. with people - not in the geek sense) or whatever, then why not give yourself every possible advantage, even if it means running an iron over your shirt before you head down.
Just two words for you:
back ups
Or should that be one word ?? Anyway, you have a good life is this is the stuff of your nightmares !!
Amen to that. Sad to say, but certain parts of the IT industry (and in particular, anything to with one computer (or piece of code) magically talking to another one owned by a different organization) are constantly buying into the bogus claims of snakeoil salesman with silver bullet technologies. XML is merely the latest in a long line.
The only new things about XML, IMHO, are that is has spawned more sub-specifications than any previous pretender to the crown.
Anyone remember CORBA ? Or any of the other zillions of RPC-type mechanisms that people have jumped on the bandwagon of ?
I'm not blaiming the people who push these agendas. I too would love to spend my weekends sunning on the beaches of exotic European tourist destinations and chugging beers on my expense account. The price of sitting through a ferw stiflingly boring and pointless standards meetings seems a small price to pay. All large IT companies employ 2 or 3 people whose job it is to front up to these meetings. Typically these people are articulate and highly versed ex-programmers but architecurally challenged and with little understanding of the real nature of building complex IT systems.
Ultimately, these RPC mechanisms all end up as nothing - or rather, as only perhaps 1% of the eventual solution.
All that XML is, is an easy-to-parse, text based data transfer mechanism. And as the parent posting says, there are some nice tools around for it. Big deal. Probably you'd be silly to use anything else if designing a data transfer. But is it ever going to change the world ? Or even rock it a little ? No.
I myself would favour Swing over others, though I'm really only fully conversant with MFC. But I fully realise that it depends what you're doing.
If you're building a mass-market app you plan to sell you all of the great unwashed out there, then you probably need to make it look very Windows-centric. Practically speaking, something like a turbo tax is probably going to get 99% of its revenue from Windows users. Its crazy to use anything - like Swing - that doesn't give you the best, most up-to-date look on Windows (though Sun would claim it is native look and feel). Use MFC or something like that.
If on the other hand you're building something like an IDE, other factors come into play. The fact that your app runs on linux as well as Windows will probably be a key sales point to your target audience. And your app is probably far more complex than a mass market app - meaning you need good productivity and a strong underlying architecture(which, IMHO, Swing gives you). Your users are likely to care less about the memory requirements of a technology like Swing.
Or as a final example, if you're writing a game, then screw their sheety GUI ! Code everything yourself from lines, dots, and mouse events. Make your list boxes scrollable using human skulls as thumbtabs, have rats running up and down inside your text fields to show focus. (personally I would also use Swing for this but realise that may be straying into personal predjudice).
In summary, its no good saying "whats best". It depends on what you're coding.
What can you do?
1. Require username/password - unless these are paid for, it's hard to stop people from registering
Kind of obvious but slashdot itself shows another alternative, which is to leave accounts free but allow them to build up value over time in the form of a pseudo-curency (karma). This works well to the extent that people, once they've acquired their hard-earned karma, are less likely to act in a troll-like way.
Of course you still get the puerile pests who start their troll-like uterances with something like "You might think I'm trolling but I've reached my karma cap so f*** you, I'll say what I want".
Personally though I find the stuff at less controlled places like fucked company's message boards pretty funny though, just because they are populated by nothing but trolls.
At the risk of being bitchslapped into troll-land, I'd go further and say that probably a company like MS is the only one thats going to pull this off.
I'll be honest and admit I haven't thoroughly reviewed this approach for newness - and anyway I'm no expert. But, as many other posters have pointed out, this sort of thing is not new and the problem (and many so-called "solutions" for it) has been around for a very long time indeed.
This is one of those problems that is very difficult to solve because it goes to the heart of user behavior, and users are, well, awkward.
Anyway can support metadata descriptions in n forms, relationships between documents, etc., etc. The problem is in developing a solution that users actually use. Not one that demos well, one that is so natural that when I'm looking for something that Jane in Acounts put there, I can assume she used it when she created the doc.
That involves a lot of very un-open source like work. Interviewing thousands of Janes. Spying on them in usability labs. Building endless iterations and prototypes and measuring the success of each one. Making sure the approach translates well into otehr languages and cultures. Thats the sort of thing that takes real big-company resources.
If this problem was as simple as having an "Ah Hah !" moment, it would have been solved twenty or more years ago.
I agree theres a whole lot of other stuff they need more than internet access. But, if thats whats on offer, I wouldn't say it is useless because of high illiteracy rates. It might only take one semi-literate person in a small village, AND some compelling content, to plant the seeds for others to teach themselves to read. It might be surprising just what people can teach themselves, and perhaps the internet could be the key to reducing illiteracy.
But if your program entered a loop, the loudspeaker started emitting a very high pitched and steady tone. You could tell other things by listening too - depending on whether the whole "kernel" was looping or not, you might hear individual interrupt handlers breaking in. It was actually a pretty cool tool and I have often considered how difficult it would be to build a UI (not that there was any such thing as a UI in those days) that gave the equivalent information.
CPUs are now way too fast of course and do too many things at once to make this approach any use. But I think it could be a very useful way to very quickly get a good estimation of the quality of a network connection.
Whether you'd want to start open heart surgery based on that estimate is another matter of course.
I think you've confused the company's money and the employee's money. You probably wouldn't care if employee #2708 spent all his money on cladding his house in the burbs with faux bricks, so why should you care if employee #1 wastes his on fast cars and the like ?
In this guys's case, you might have a point, since he's probably the only employee and he really IS the company, but why begrudge Larry or Paul Allen or any other successful business the fruits of their labour/ingenuity/luck or whatever ? Presumably you would only invest in companies where the boss lives in a trailer parked out back of the office ?
One of the biggest issues we have is trying to placate potential customers that are worried about us going out of business and leaving them with un-supported code.
To get around this, we've put copies of source code, with docs, build environments/scripts, etc., in escrow. This way, if we DO go down in flames, all registered license holders of our software are entitled to complete access to EVERYTHING required to support the software themselves.
We went through a similar discussion at my company with a very very large software company (OK, the largest) that licenses our Java technology. Their view was that escrow was no good for several reasons. One was that there was no guarantee that the escrow actually contained "everything". A true escrow service that guarantees this would have to do a complete build, and then release the result to the customer for them to check it is complete. Further, some skilled and independent authority would need to verify that the build was truly done from source and there were no binaries in it.
After considering these and other objections for a while, they did seem reasonable and escrow is not as simple as it looks to be.
For some reason I'm left with the strong impression you're sitting at a wooden desk driking a glass of wine, with LOTR on your desk or bookshelf ??
I agree with this. It is possible to write good software that has somewhat lousy code inside it. For exampe, an inefficient sort algorithm that is only used when a rarely-accessed administration screen is displayed. The code may be inelegant but practically speaking it does not matter and there is no reason for the vendor to be called up on it (which some smart-arse certainly would "ha ha Microsoft used the Breighton-Whirst Bubble sort when the Langer-Turston would have been 100 times faster ! What dipsticks !").
Much more important to quality of apps are "bigger picture" items such as schema designs for any RDBMS-based product (readily available now without the source code) or external interfaces (which, to use MS Word as the extreme example, it is made clear by the vendor that they do not intend to adopt any industry format nor to even be bound even by their own published formats).
Yeah but I can't help feeling that old cars, boats and aeroplanes are very very sexy and likely of interest to most of the inhabitants of the planet, and, yeah, to be honest might well help get you laid...whereas consider whether you could muster quite the same charisma offering to show someone over your collection of rebuilt dental hygiene equipment (for example)...
Actually, only in the very short term is the advertiser the loser. Its better than that in the medium term, because the advertisers will become aware that there is stealth technology out there that is ripping them off. They'll say to the double-click or whoever "how bad is this problem ? can you guarantee that ANYONE is actually seeing the ads I pay for ?".
Then doubleclick become the loser - and its a bad place for them to be because its hard for them to reassure the advertiser since they have very little idea how bad the problem is. Their service will become valueless, their stock will fall (further) and their houses and boats will be repossessed.
heh heh
Look out for MS's righteous rage when the forged MAC addresses start colliding with existing, non-hacker users and it disrupts the Live service they've paid for! Can anyone say "bolt the door, the wolf's outside" ?
A. You can negotiate with a terrorist.
This is utterly true, and it is refreshing to see someone highlighting it. To go even further, designing an effective UI is something you simply can't get right in one go, no matter how much money and experts you throw at it. Most products only develop a good UI after several versions, based on a *lot* of user feedback.
So Microsoft has to fork out on developing this great UI, and anyone who cares to can come along and pick it up for free and leverage it. Thats a great thing. And ironically its how Microsoft got where they were in the first place - not by being great innovators but by being "fast followers".
There might be a lot more OSS successes if more people swallowed their pride, decided they didn't have to reinvent the wheel, and became fast followers themselves.
There is one thing that has puzzled me about slashdot. That is that very seldom (perhaps never, at least I've never seen them) are any meta-topics posted like "why does the karma system work the way it does". Furthermore anyone who does raise such issues seems to (according to their moaning sigs and bitter journals anyway) be ruthlessly modded down as offtopic, perhaps even causing them to go all feral and troll-like.
What about some discussion that would release these pent up forces and dispel the illusion of "Gulag Taco".
You say never build that close to a beach. The thing is, cliffs and foreshores move over time. It may happen gradually, or there may be a huge slip that moves the coast inwards by many yards overnight. So when you say "don't build that close to a beach", how not close is not close enough ? Where I live the same discussion is going on. The council discourages building seawalls. Trouble is, theres only one line of houses, then the public road. What happens when the houses are gone and the road comes under threat ? In some parts of the UK the land is disappearing at the rate of up to 5 metres per year.
Sure, developers who want to create huge unnatural structures that play havoc with the natural wave and current patterns should get a hard time. But its a bit too simplistic to just say "never build near the sea".
We salute you "www.pacific-cable.org" - and not least for saving us from a bushel of lame jokes about the /. effect...
Any optimal image format will result in a file only just big enough to store the image and no bigger - and therefore it will not be able to store any additional data without reducing the image quality in some way.
Without any further information available, could it be they are just talking about taking advantage of flaws in some given format such as jpeg ?
Pull your head in paperclip man. I am in total agreement with your analysis of the paper from the little I read of it, and from my own strongly held but flawless prejudices against computer science BS by people who've never built a real system in their lives. And I did not in fact call you snotty or pertentious (sic) (though now I believe I justifiably could).
...and of course I have some primo skank here that has tken me even beyond the bounds of understanding possible to mere earth-bound mortals...
Though your polysyllabic observation does indeed lead to the inference that you know what you're talking about, I have always heard (and read) the opposite so could you point us to a definitive source that backs up your statement ?
Reminds me of the psychology experiment conducted at an army barracks which had ten washbasins shared by all the soldiers for their morning ablutions.
The experimenters removed the plug from one of the basins overnight. By the next day, all the other plugs had been stolen by soldiers who may not have agreed with plug stealing but sure as hell weren't going to be the ones who had to go without.