Do you need to keep the existing functionality of Exchange (ie: calendaring)?
The latter will limit your choices more than the former.
Funny, the first answer that came to mind was "Solaris." Sun gets a bad rap here, but really, their hardware is pretty good.
Is your organization decentralized? Be sure to think about administration and infrastructure issues associated with your particular topography. Ideally you'd want to keep your current processes, and slide another product underneath it.
Anyhow, be sure to phase it in. Run a pilot in one section. Better yet, run multiple pilots with multiple vendors if you can mange it.
Insist that the vendors do the pilot for free. If possible try and run within your existing infrastructure somehow, with live users. Find a department or two that's willing to volunteer, and use them as part of the test.
Vendors won't lie to you, but their data is obviously biased. Be sure to understand exactly what you're trying to figure out from each vendor. Keep metrics now, and while you're doing the pilot, so you have hard data as part of the pilot.
If you have requirements, be sure to share them with the vendors when they design their pilot. List -everything-, including every feature in webmail, every administrative capability that you'd like, etc. Be specific. "Supports IMAP" isn't good enough. "Supports the entire IMAP feature suite" is better. Listing every IMAP feature that you want is the best. It's not overkill, because inevitably the feature you need will be implemented in a later release and you'll be screwed.
The idea isn't to beat one vendor with the requirements. Nobody will be able to do everything. The idea is that at least you know what each product/suite can do and what it can't, so you can adjust the expectations.
Be sure that the people in the food chain forwards all external entities inquiring about the project back down to you. Vendors will attempt to affect the requirements by talking to your boss, your boss' boss, etc. Make sure that everyone knows that you are in charge, and that you are the point of contact.
Hmmm. Understand what your infrastructure is now. You can't replace it if you don't know what it is. Understand as much as you can about it, so you can spew statistics out the wazoo at meetings. If you know, for example, that 8% of everyone checks their email after business hours, you'll overpower everyone else in the meeting with your obvious technical Mojo.
Be nice, but firm. Save being a dick for vendors. Your job is to keep your internal customers happy. The Sales Engineers are not your friends, they're there to make sure you buy their product.
You can yell at sales people. It is a negotiating tactic, and can be very effective. Don't yell at the SEs, because they don't have any real authority.
And whatever you do, don't change everything at once!
Lastly, keep your boss (and your boss' boss) in the loop as to your progress. When the s**t hits the fan, they have to back you up. They can't do that if they have no idea what's happening.
You know, it's funny, but in some ways the patent office has gotten better over the years.
I heard that Smucker's tried to patent Uncrustables a while back (process patent?). For those of you who don't know, Uncrustables are fillings (PB & J, Cheese) that are wrapped in a neat doughy pod thing.
Anyway, the patent office refused to grant the patent, because they said that Uncrustables were basically big ravioli.
That's about what the PO should have done here. The Creative interface is basically a Smalltalk object browser. I suppose that's obscure enough that an examiner wouldn't know what it was, though - there's a big difference between ravioli and music players.
Another option might be that Neanderthals were enslaved by humans, and they slowly died out due to abuse and the poor living conditions afforded them. Not a great story either.
Interedis is better beause, to be brually honest, most programmers will be working on business applications. With business apps, domain knowledge is more important than technical skill.
Why?
Because you can always learn technical skills. Pick up a book and read. Anyone who is any good should be able to pick up a new language in a few weeks.
Domain knowledge, though, takes a ridiculous amount of work to gain. And once you have it, you can apply those programming skills to problems inside your domain and make money (or at least useful tools). It's difficult for someone without domain knowledge to make tools that solve problems for people inside a domain, because the problems are arcane and non-obvious.
In short, by going into a field instead of CS, you gain a niche inside that field. CS is basically tool-building, which while useful, isn't as useful as knowing which tool to build and why.
Old formats don't die, they just go into maintenance mode.
Saying one format or another has won is always premature. The only time it's safe to say that a format is dead is when they have to build new equipment to read it because the hardware is missing. And even then you never know.
This article is obviously biased. It's like when Netscape said "the desktop is dead" when the Java plugin was first released.
And when you think about it, $50 for a 15-year old machine shows how well Macs hold their value.
Shit, you can't give away a P2 system these days. And an SE/30 is equivalent to about a 386.
Great machines, those SE/30s. I tricked mine out with an extra video card (rops 264) and thinnet card. Ah, the good old days. Dual head goodness - in 1990!
I've found over the years that CS grads tend to make things much too complicated.
Generalization is great, but it always seems that CS-degreed programmers always want to over-generalize and over-engineer their stuff.
What does this mean?
Let's say I need a function that adds two numbers. Pretty simple. Instead of just writing a function, CS grads tend to write a big function, body of functions, or a library that does addition, subtraction, multiplication, division, etc.
Then they'll forget to check the arguments, and it'll barf.
As an aside, I don't think I've ever on a project that didn't need to refactor code, even if that code was written with the intent that it didn't need refactoring. So why bother writing generalized, reusable functions that do more than you want when you have to rewrite them anyway next time they're used?
You know, one of the dumbest things about an article like this is the attempt at being definitive.
It's like writing an article that states "We asked the CIA about assassination, and the CIA said it never killed anyone. When we interviewed various ex-CIA employees, they agreed."
Does this guy really believe that he'd find someone who would say "oh yeah, we used to f*ck up competitor's stuff all the time."
I'd say "look at the trail of broken applications behind the various DOS revisions, not the mea culpas of the people today."
Unfortunately, it sounds like you're one of the developers. You still don't get it. Maybe you should listen to people who have actually used tools like yours for the last 10 years? Maybe your ideas really are better, and have sprung from your genius much the way athena sprung from Zeus' forehead.
However, that's really unlikely. Nobody working on inkscape is Kai Krause.
By lumping all comments like mine into the "oh, they want our app to be like their favorite app" you're ignoring real complaints and issues.
Blah blah blah. Go ahead, do your own thing, and ignore years of domain-specific experience.
Sticking your head in the ground and ignoring the de-facto standard is just irritating. I use Photoshop and Freehand, and have been since version 1.0 of both products. Ignoring their key combos means not taking advantage of a huge body of learned behaviors.
While it's nice to be all macho and shit, realistically speaking those key combos are like that for the simple reason that they've stood the test of time. Some of those key combos have a lifespan longer than linux. They've tried other key combos, and those haven't worked.
By ignoring that, the developers show that they're either (1) so young that they don't understand and take advantage of the past, (2) they've got NIH syndrome, or (3) they're so full of their own cleverness that they've gone pinhead.
In any case, that's really Bad News for the future of the app.
The gist of the article was that you should be afraid (from a corporate point of view) if your competitors are looking at leading/bleeding edge things like python or ruby, because that means they're way out ahead of you, technologically speaking.
People who look at python and ruby are doing so because they're curious, and it might make their jobs easier and their apps better. Their job doesn't stop when they leave the building. If they're looking for python programmers, that means the core people are like that.
This should be Bad News for Microsoft, because in the end, any software product is first and foremost a reflection of what's in the mind of the developer. If you're hiring 2nd tier minds, you get 2nd tier software.
Even if a product is so big that one person can't understand it, you can still understand what you're working on.
This remind me of the "Joel on Software" article about python. Better software developers stay up-to-date because they want to. Lesser software develoeprs stay up-to-date because they have to.
Why would working at Microsoft be interesting, unless you're political?
Re:Yeah, there's a bunch of this stuff around
on
Examining ICMP Flaws
·
· Score: 1
The problem with that is simple: what if your DHCP server fails and you have to install another one?
Suddenly, you have to reconfigure everything while users sit there complaining that the IntarWeb is down.
It also implies end-to-end configuration, which with more than about 5 machines becomes a real PITA.
Yeah, there's a bunch of this stuff around
on
Examining ICMP Flaws
·
· Score: 2, Insightful
I think you could send a redirect via ICMP too, to generate your own man-in-the-middle attack. It's been too long since I've read the RFC.
DHCP has a whole bunch of issues too. For example, what if a DHCP client gets a DHCPACK from some machine? I'll bet that it would just reconfigure itself using the information in the packet. Bam, you've got a man-in-the-middle attack.
In general, Homo Sapiens pretty much will wipe out anything that looks like a competitor/threat, including other Homo Sapiens.
This has extended itself to the modern times, though it's been toned down somewhat by the various mores and moralities.
Things wouldn't be any different for our ancestor Homo Sapiens. I'd guess that they'd be even more aggressive towards Neanderthals, due to the larger size and bigger heads (and brains) of the Neanderthals.
If they weren't so big, they probably would've been domesticated or enslaved.
Realistically speaking, how much is it worth to you to secure your company's assets? At retail locations, conventional wisdom says "give the dude the money, because it's not worth it."
Would you lose a body part?
I think the answer would be "Heck No!"
What would the court say? Isn't using biometric security putting life and limb of the employees in jeopardy?
That would be an interesting case for a judge and jury.
Microsoft has in every area in which it isn't a monopoly.
What does that mean?
That means that every product line except Windows and Office has problems - because of how the MS entries match up to the competition. Problems meaning business problems, not technical problems. They have those too, but the business problems are the ones that long-term will affect the company.
Even Windows will start to have problems, when mactel starts shipping. Once IBM moves to mactel internally, everyone and their brother will move to mactel internally. It may take 10 years, but in that 10 years there will be competition in the desktop arena.
Of course, that assumes Apple adjusts to the needs of corporate computing. That's a big assumption.
Slashdot Mirror
How much money are you willing to spend?
Do you need to keep the existing functionality of Exchange (ie: calendaring)?
The latter will limit your choices more than the former.
Funny, the first answer that came to mind was "Solaris." Sun gets a bad rap here, but really, their hardware is pretty good.
Is your organization decentralized? Be sure to think about administration and infrastructure issues associated with your particular topography. Ideally you'd want to keep your current processes, and slide another product underneath it.
Anyhow, be sure to phase it in. Run a pilot in one section. Better yet, run multiple pilots with multiple vendors if you can mange it.
Insist that the vendors do the pilot for free. If possible try and run within your existing infrastructure somehow, with live users. Find a department or two that's willing to volunteer, and use them as part of the test.
Vendors won't lie to you, but their data is obviously biased. Be sure to understand exactly what you're trying to figure out from each vendor. Keep metrics now, and while you're doing the pilot, so you have hard data as part of the pilot.
If you have requirements, be sure to share them with the vendors when they design their pilot. List -everything-, including every feature in webmail, every administrative capability that you'd like, etc. Be specific. "Supports IMAP" isn't good enough. "Supports the entire IMAP feature suite" is better. Listing every IMAP feature that you want is the best. It's not overkill, because inevitably the feature you need will be implemented in a later release and you'll be screwed.
The idea isn't to beat one vendor with the requirements. Nobody will be able to do everything. The idea is that at least you know what each product/suite can do and what it can't, so you can adjust the expectations.
Be sure that the people in the food chain forwards all external entities inquiring about the project back down to you. Vendors will attempt to affect the requirements by talking to your boss, your boss' boss, etc. Make sure that everyone knows that you are in charge, and that you are the point of contact.
Hmmm. Understand what your infrastructure is now. You can't replace it if you don't know what it is. Understand as much as you can about it, so you can spew statistics out the wazoo at meetings. If you know, for example, that 8% of everyone checks their email after business hours, you'll overpower everyone else in the meeting with your obvious technical Mojo.
Be nice, but firm. Save being a dick for vendors. Your job is to keep your internal customers happy. The Sales Engineers are not your friends, they're there to make sure you buy their product.
You can yell at sales people. It is a negotiating tactic, and can be very effective. Don't yell at the SEs, because they don't have any real authority.
And whatever you do, don't change everything at once!
Lastly, keep your boss (and your boss' boss) in the loop as to your progress. When the s**t hits the fan, they have to back you up. They can't do that if they have no idea what's happening.
Good luck!
You know, it's funny, but in some ways the patent office has gotten better over the years.
I heard that Smucker's tried to patent Uncrustables a while back (process patent?). For those of you who don't know, Uncrustables are fillings (PB & J, Cheese) that are wrapped in a neat doughy pod thing.
Anyway, the patent office refused to grant the patent, because they said that Uncrustables were basically big ravioli.
That's about what the PO should have done here. The Creative interface is basically a Smalltalk object browser. I suppose that's obscure enough that an examiner wouldn't know what it was, though - there's a big difference between ravioli and music players.
Yes, it pretty much always is violence.
Another option might be that Neanderthals were enslaved by humans, and they slowly died out due to abuse and the poor living conditions afforded them. Not a great story either.
However, have you read the paper? Looked at the data? It seems a bit early for you to dismiss their conclusions based on a blog entry.
Interedis is better beause, to be brually honest, most programmers will be working on business applications. With business apps, domain knowledge is more important than technical skill.
Why?
Because you can always learn technical skills. Pick up a book and read. Anyone who is any good should be able to pick up a new language in a few weeks.
Domain knowledge, though, takes a ridiculous amount of work to gain. And once you have it, you can apply those programming skills to problems inside your domain and make money (or at least useful tools). It's difficult for someone without domain knowledge to make tools that solve problems for people inside a domain, because the problems are arcane and non-obvious.
In short, by going into a field instead of CS, you gain a niche inside that field. CS is basically tool-building, which while useful, isn't as useful as knowing which tool to build and why.
After some thought, I'd probably agree that step 4 is valid for the vast majority of web users.
The only way this might break is if a large number of people are sitting behind a proxy/cache. But if it is the case they have fallbacks.
Old formats don't die, they just go into maintenance mode.
Saying one format or another has won is always premature. The only time it's safe to say that a format is dead is when they have to build new equipment to read it because the hardware is missing. And even then you never know.
This article is obviously biased. It's like when Netscape said "the desktop is dead" when the Java plugin was first released.
And when you think about it, $50 for a 15-year old machine shows how well Macs hold their value.
Shit, you can't give away a P2 system these days. And an SE/30 is equivalent to about a 386.
Great machines, those SE/30s. I tricked mine out with an extra video card (rops 264) and thinnet card. Ah, the good old days. Dual head goodness - in 1990!
http://www.publicvpn.com/
Sniff this!
All scientists do all day is think. How boring is that?
I've found over the years that CS grads tend to make things much too complicated.
Generalization is great, but it always seems that CS-degreed programmers always want to over-generalize and over-engineer their stuff.
What does this mean?
Let's say I need a function that adds two numbers. Pretty simple. Instead of just writing a function, CS grads tend to write a big function, body of functions, or a library that does addition, subtraction, multiplication, division, etc.
Then they'll forget to check the arguments, and it'll barf.
As an aside, I don't think I've ever on a project that didn't need to refactor code, even if that code was written with the intent that it didn't need refactoring. So why bother writing generalized, reusable functions that do more than you want when you have to rewrite them anyway next time they're used?
You know, one of the dumbest things about an article like this is the attempt at being definitive.
It's like writing an article that states "We asked the CIA about assassination, and the CIA said it never killed anyone. When we interviewed various ex-CIA employees, they agreed."
Does this guy really believe that he'd find someone who would say "oh yeah, we used to f*ck up competitor's stuff all the time."
I'd say "look at the trail of broken applications behind the various DOS revisions, not the mea culpas of the people today."
Just wondering. He bought the computer and its contents from the government, so does he have rights to the source on the box?
If you do offer WiFi, are you going to offer a VPN so they don't broadcast their stuff everywhere?
www.hotspotvpn.com
www.publicvpn.com
www.witopia.net
No, -you- simply don't get it.
Unfortunately, it sounds like you're one of the developers. You still don't get it. Maybe you should listen to people who have actually used tools like yours for the last 10 years? Maybe your ideas really are better, and have sprung from your genius much the way athena sprung from Zeus' forehead.
However, that's really unlikely. Nobody working on inkscape is Kai Krause.
By lumping all comments like mine into the "oh, they want our app to be like their favorite app" you're ignoring real complaints and issues.
Blah blah blah. Go ahead, do your own thing, and ignore years of domain-specific experience.
Peh.
Sticking your head in the ground and ignoring the de-facto standard is just irritating. I use Photoshop and Freehand, and have been since version 1.0 of both products. Ignoring their key combos means not taking advantage of a huge body of learned behaviors.
While it's nice to be all macho and shit, realistically speaking those key combos are like that for the simple reason that they've stood the test of time. Some of those key combos have a lifespan longer than linux. They've tried other key combos, and those haven't worked.
By ignoring that, the developers show that they're either (1) so young that they don't understand and take advantage of the past, (2) they've got NIH syndrome, or (3) they're so full of their own cleverness that they've gone pinhead.
In any case, that's really Bad News for the future of the app.
I remember a while back getting a PC that had no discs - it was all on the local drive.
If you got something like that, you'd be screwed.
That may be it; it sounds familiar.
All the advice stuff sort of blends into one big stew after a while.
Huh. I can't find it anymore.
The gist of the article was that you should be afraid (from a corporate point of view) if your competitors are looking at leading/bleeding edge things like python or ruby, because that means they're way out ahead of you, technologically speaking.
People who look at python and ruby are doing so because they're curious, and it might make their jobs easier and their apps better. Their job doesn't stop when they leave the building. If they're looking for python programmers, that means the core people are like that.
This should be Bad News for Microsoft, because in the end, any software product is first and foremost a reflection of what's in the mind of the developer. If you're hiring 2nd tier minds, you get 2nd tier software.
Even if a product is so big that one person can't understand it, you can still understand what you're working on.
This remind me of the "Joel on Software" article about python. Better software developers stay up-to-date because they want to. Lesser software develoeprs stay up-to-date because they have to.
Why would working at Microsoft be interesting, unless you're political?
The problem with that is simple: what if your DHCP server fails and you have to install another one?
Suddenly, you have to reconfigure everything while users sit there complaining that the IntarWeb is down.
It also implies end-to-end configuration, which with more than about 5 machines becomes a real PITA.
I think you could send a redirect via ICMP too, to generate your own man-in-the-middle attack. It's been too long since I've read the RFC.
DHCP has a whole bunch of issues too. For example, what if a DHCP client gets a DHCPACK from some machine? I'll bet that it would just reconfigure itself using the information in the packet. Bam, you've got a man-in-the-middle attack.
In general, Homo Sapiens pretty much will wipe out anything that looks like a competitor/threat, including other Homo Sapiens.
This has extended itself to the modern times, though it's been toned down somewhat by the various mores and moralities.
Things wouldn't be any different for our ancestor Homo Sapiens. I'd guess that they'd be even more aggressive towards Neanderthals, due to the larger size and bigger heads (and brains) of the Neanderthals.
If they weren't so big, they probably would've been domesticated or enslaved.
Realistically speaking, how much is it worth to you to secure your company's assets? At retail locations, conventional wisdom says "give the dude the money, because it's not worth it."
Would you lose a body part?
I think the answer would be "Heck No!"
What would the court say? Isn't using biometric security putting life and limb of the employees in jeopardy?
That would be an interesting case for a judge and jury.
Microsoft has in every area in which it isn't a monopoly.
What does that mean?
That means that every product line except Windows and Office has problems - because of how the MS entries match up to the competition. Problems meaning business problems, not technical problems. They have those too, but the business problems are the ones that long-term will affect the company.
Even Windows will start to have problems, when mactel starts shipping. Once IBM moves to mactel internally, everyone and their brother will move to mactel internally. It may take 10 years, but in that 10 years there will be competition in the desktop arena.
Of course, that assumes Apple adjusts to the needs of corporate computing. That's a big assumption.