In theory I suppose even if it didn't ban that, it would allow an order to harvest a password at login time and provide it to the government. Or maybe they already think that's OK. The level of retard going on here is so high that I'm having trouble understanding what view of the world these people have.
I use the paid version of perforce at work. I would rather use _any_ other system I've had experience with. That includes cvs and svn, as well as, believe it or not, SourceSafe.
Perforce is decent for merging. However, the model is incomprehensible; the terminology seemingly chosen by randomly selecting words from a dictionary. Perforce is designed for SCM and build gurus; not for the developers who actually have to use it. (For example; have I forgotten to 'p4 add' a file? Tough luck; no way to find out. 'svn stat' tells me just what I want to know.)
Ditto this. Used it on ~850,000 lines of code. Takes some doing to get it configured to flag what you want, and not what you want to ignore. But a great tool. Customer support was fantastic. Reported a bug on ATL template analysis and it was fixed within 2 weeks.
I'm a pretty senior architect, so to some degree I get to play at what you want to do. Here's are some things that I think would be useful to get familiar with.
1) Whatever you do, do some TDD. Test Driven Development is more of a mind-shift than any particular technolgy you're likely to be exposed to. Make sure you have a unit-test (class level) test framework going for whatever you do.
Issue: How much more qualtiy, at what cost, are your developers likely to get practicing TDD? (My answer? Lots, but see what you think.)
2) Pick something Eclipse-based. vi? emacs? Gimme a break. Whether it's Java or C++ (CDT plug-in) or Ruby or Python, use Eclipse. It's the emacs for the new era.
Issue: How much do state of the art tools affect developer productivity? (My answer? It's huge.)
3) Do something web-based that requires running in an app-server. Tomcat / MS$ / J2EE / Rails (sort of).
Issue: Abstracting object lifetime / persistence / what have you buys you what? (My answer? Way less than you might think.)
You likely won't be able to get a feel for all three issues unless you do Ruby on Rails under Eclipse, which I haven't done - and so hesitate to recommend. But it might make sense. But if you pick something close to the three things raised above you're going to be exposed to things that will cause you to think about what drives developer productivity, which is what I take it you're interested in.
OK. So now people are going to write bots that will flag other people's stuff as objectionable. Or, in order to flag something as objectionable, you're going to have to type some distorted letters into the form.
The 'cost of spam' is not the cost of spam filters, extra storage, etc. The cost of spam is the cost to the end user of having to figure out which mail is real and which is spam.
Let's assume it takes a user only 1 second to determine if a piece of mail is spam, and deal with it, and let's assume the average user's time is worth $20 per hour. A million spams then cost the users:
$5555 = 1 second * 1 million / 3600 seconds in an hour * $20
You're right, the ISPs scared of being blacklisted. But they also view (correctly) keeping spam volume down as part of the service they sell. I know I have given up on some ISPs because of spam volume.
This is a very interesting project. As I understand the article, the point - long term - of the development effort is to try to get Linux (RedHat) adopted on the desktop by appealing to the TCO mentality of the IT department rather than by appealing to the desire of the end user to actually get stuff done. In other words, if the savings to IT of administering your machine centrally outweighs the benefits of you (corporate cube dweller) being able to configure your machine to your liking and use it as you see fit, then IT wins, and Linux makes an appearance on the Fortune 2000 desktop.
'Thin client' was the first attempt to dethrone MS in this way, but this approach appears much more sophisticated, and consequently much more likely to succeed. Without seeing how the whole thing plays out I really have no idea whether the approach is successful or not. But it's a really nifty shot across the MS bows.
Whether this goes anywhere or not ends up being decided by (as with most IT projects) whether the services provided by IT to the end users are adequate (in which case IT gets their way) or so obnoxiously limited that the end user cabal ends up storming the IT department with burning torches.
It all depends on how you want to view your database. Fundamentally, you can look at it in two ways:
a) It's a persistence mechanism. At root, this is fundamentally what databases arose from. It's a fine way to look at the issue, and one that personally appeals to me. In that case, don't use stored procedures, but use triggers and constraints to ensure database integrity. Your access to the database should be through class loaders (in your language of choice). Don't try to get tricky with the database. Its job is to persist object instances and load them. Essentially what you are running is an OO database that actually works, since relational databases are - in practice - stunningly robust.
This the the normal 'application' use case.
b) The database is the company store of information. The understanding is that many applications will be written by disparate groups to access the data, and those groups will certainly not be willing to communicate and may not even know the other groups exist. In that case, for God's sake, make plenty of use of stored procedures and encourage their use. Stored procedures are the API to the company jewels, and are the only thing that allows changes to be made to the data structures.
This is the normal 'IT / internal business' use case.
Decide which category you are in follow that model.
(There is also the use case of the application with performance requirements that require the use of stored procedures. If you are in that situation you already know who you are.)
Even though the press has been getting a lot of flack in recent times, I think think they still get way too much credit for their opinions. If the story had been 'This article analyzes Linux blah blah blah and finds it somewhat lacking.' the/. community would have been pissing on the author's grave.
However, since the enforcability of the sig is basically a legal issue, everyone gives the (journalist) author of the article a bunch of slack. Now, I (yes, former lawyer) happen to agree that the sig is just so much BS. But that's just the problem. The opinion expressed really - to be accurate - relies on a whole lot of technical legal analysis that the writer clearly does not have. Why does anyone give a rat's ass what this guy says?
'Employment insurance'. Right. Because I need insurance in case I get employed. It used to be called - before the lunatics took over the asylum - 'unemployment insurance'.
Just so you know what your money is going toward. Maybe you agree; maybe you don't. But 'employment insurance'!! Give me an effing break.
I mean, how on earth could you miss the opportunity to take advantage of a proprietry, non-portable, technology that hasn't officially been released yet and probably won't be for another 2 years
IIRC, the Gartner group has said that Loghorm will not be released until 2007. So I think it's closer to 3 years out than 2, fwiw.
porsche has a tiny market share - but nobody suggests they should make a k-car version to get a bigger slice of the pie!
Well... basically that's what the Porche Cayenne is. Porche whored themselves and left their traditional sport car market for a larger user base (profit!).
I don't object (even though I think the Cayenne is an abomination), don't get me wrong. It's just that the Porche analogy is off base.
The thing I like about epicurious is that you can search by ingredient. So if you happen to have squid and tomatoes, you can search for all the recipes that require both. Sometimes you find something worth making that saves you a trip to the store.
Might or might not be true, but don't do the following. This - more or less - is a true conversation.
Boss: I see you posted your resume on Monster on Friday. Empoloyee: I was just trying to see what was out there. You never know, you know... Boss: Good move. Because of course, you've got no choice as of now.
As a gimic a software company did this with soda. They 'open sourced' the instructions to make the stuff. I think the company blew up in the dot com bust, but it was a cute idea.
Years ago, I had - pretty much - the following conversation with my then boss:
Me: I cannot sign this.
Him: Then you are fired.
Me: Then I guess I am fired, since I cannot sign this.
Him: Oh. I'm sure we can work something out.
Me: That's up to you, since I cannot sign this.
Him: Don't worry about it. You do not have to sign this.
That was basically the conversation. It took less than 5 minutes. It was a fairly small company, and it might work much less well in a larger one. But if you've got real skills, don't let the bastards grind you down.
"Can architect masterful C++ for $4.50 per hour?" I do not mean to denigrate your skills, but I think not. And, with all due respect, I do not care what the local market is like. "Masterful?" Give me a break.
I bought an Apex, had it fail within a week, and got a replacement. (The store did _not_ seem surprised to see me.) The replacement did not work from the beginning.
I returned that one, and got an 'Oritron' branded one for about the same price. Its been working fine for about a year.
I'm sure the technical idiots don't help, but the main problem seems to be the Apex players are crap. I was not surprised by the %80 return estimate from the guy who sells them.
There is however one thing I don't understand. I am assuming that the distinction you draw between object-oriented and class-oriented designs / languages is the one about the desirability of run-time binding a la Smalltalk, Python etc. versus compile time al la C++. However, you then say 'if you write Java in a true OO manner' you don't get those types of problems. But Java hasn't got run-time binding, so what am I missing?
I work for a company that creates shrink-wrap software, insofar as that description means anything anymore. It's not cheap.
At least once a quarter, a largish potential customer is persuaded by internal IT that they can write the application more cheaply than buying it from us. The IT department is always wrong. I don't mean mostly wrong. I mean wrong 100% of the time. In the vast majority of cases the company ends up coming back to buy a solution and dumps the in house solution. In some cases the company makes do with something they hate.
Think about it. If there is a company out there that provides something close to what you want, and it has more than a few developers / real tech support / real QA etc., how possibly could an in house solution work better?
1) The company could be charging a completely outrageous amount for the software. Good idea, but that simply doesn't happen. That company is out of business immediately, especially in this economy.
2) The company is selling a product that doesn't exist. Vaporware is a real possibility, but if you can actually pilot the stuff, and it's close to what you want, buy it.
3) The software actually doesn't do what you want. You have unique requirements. This is the only actual legitimate reason to build.
If the software addresses a requirement of your company, and no other, the build it. But if the problem is one faced by some reasonable number of similarly situated companies, then just buy something. Robustness, maintenance, updates, new features, support etc. will be way better. It's the advantage of specialization.
Slashdot Mirror
I'm sure the government is somehow contriving to pay more for an S4 than I would pay for an S7.
In theory I suppose even if it didn't ban that, it would allow an order to harvest a password at login time and provide it to the government. Or maybe they already think that's OK. The level of retard going on here is so high that I'm having trouble understanding what view of the world these people have.
I look forward to dickbutt on the search page.
I use the paid version of perforce at work. I would rather use _any_ other system I've had experience with. That includes cvs and svn, as well as, believe it or not, SourceSafe.
Perforce is decent for merging. However, the model is incomprehensible; the terminology seemingly chosen by randomly selecting words from a dictionary. Perforce is designed for SCM and build gurus; not for the developers who actually have to use it. (For example; have I forgotten to 'p4 add' a file? Tough luck; no way to find out. 'svn stat' tells me just what I want to know.)
Ditto this. Used it on ~850,000 lines of code. Takes some doing to get it configured to flag what you want, and not what you want to ignore. But a great tool. Customer support was fantastic. Reported a bug on ATL template analysis and it was fixed within 2 weeks.
If you've got mod points, mod this guy up.
This isn't a tech question. This isn't a pay question. This is a life question.
Decide what you want to do. Do that.
I'm a pretty senior architect, so to some degree I get to play at what you want to do. Here's are some things that I think would be useful to get familiar with.
1) Whatever you do, do some TDD. Test Driven Development is more of a mind-shift than any particular technolgy you're likely to be exposed to. Make sure you have a unit-test (class level) test framework going for whatever you do.
Issue: How much more qualtiy, at what cost, are your developers likely to get practicing TDD? (My answer? Lots, but see what you think.)
2) Pick something Eclipse-based. vi? emacs? Gimme a break. Whether it's Java or C++ (CDT plug-in) or Ruby or Python, use Eclipse. It's the emacs for the new era.
Issue: How much do state of the art tools affect developer productivity? (My answer? It's huge.)
3) Do something web-based that requires running in an app-server. Tomcat / MS$ / J2EE / Rails (sort of).
Issue: Abstracting object lifetime / persistence / what have you buys you what? (My answer? Way less than you might think.)
You likely won't be able to get a feel for all three issues unless you do Ruby on Rails under Eclipse, which I haven't done - and so hesitate to recommend. But it might make sense. But if you pick something close to the three things raised above you're going to be exposed to things that will cause you to think about what drives developer productivity, which is what I take it you're interested in.
OK. So now people are going to write bots that will flag other people's stuff as objectionable. Or, in order to flag something as objectionable, you're going to have to type some distorted letters into the form.
And of course, we're missing the essential perfume dispenser.
4 /0411_citroen_c4/
http://www.automobilemag.com/auto_shows/paris_200
The 'cost of spam' is not the cost of spam filters, extra storage, etc. The cost of spam is the cost to the end user of having to figure out which mail is real and which is spam.
Let's assume it takes a user only 1 second to determine if a piece of mail is spam, and deal with it, and let's assume the average user's time is worth $20 per hour. A million spams then cost the users:
$5555 = 1 second * 1 million / 3600 seconds in an hour * $20
You're right, the ISPs scared of being blacklisted. But they also view (correctly) keeping spam volume down as part of the service they sell. I know I have given up on some ISPs because of spam volume.
This is a very interesting project. As I understand the article, the point - long term - of the development effort is to try to get Linux (RedHat) adopted on the desktop by appealing to the TCO mentality of the IT department rather than by appealing to the desire of the end user to actually get stuff done. In other words, if the savings to IT of administering your machine centrally outweighs the benefits of you (corporate cube dweller) being able to configure your machine to your liking and use it as you see fit, then IT wins, and Linux makes an appearance on the Fortune 2000 desktop.
'Thin client' was the first attempt to dethrone MS in this way, but this approach appears much more sophisticated, and consequently much more likely to succeed. Without seeing how the whole thing plays out I really have no idea whether the approach is successful or not. But it's a really nifty shot across the MS bows.
Whether this goes anywhere or not ends up being decided by (as with most IT projects) whether the services provided by IT to the end users are adequate (in which case IT gets their way) or so obnoxiously limited that the end user cabal ends up storming the IT department with burning torches.
It all depends on how you want to view your database. Fundamentally, you can look at it in two ways:
a) It's a persistence mechanism. At root, this is fundamentally what databases arose from. It's a fine way to look at the issue, and one that personally appeals to me. In that case, don't use stored procedures, but use triggers and constraints to ensure database integrity. Your access to the database should be through class loaders (in your language of choice). Don't try to get tricky with the database. Its job is to persist object instances and load them. Essentially what you are running is an OO database that actually works, since relational databases are - in practice - stunningly robust.
This the the normal 'application' use case.
b) The database is the company store of information. The understanding is that many applications will be written by disparate groups to access the data, and those groups will certainly not be willing to communicate and may not even know the other groups exist. In that case, for God's sake, make plenty of use of stored procedures and encourage their use. Stored procedures are the API to the company jewels, and are the only thing that allows changes to be made to the data structures.
This is the normal 'IT / internal business' use case.
Decide which category you are in follow that model.
(There is also the use case of the application with performance requirements that require the use of stored procedures. If you are in that situation you already know who you are.)
Even though the press has been getting a lot of flack in recent times, I think think they still get way too much credit for their opinions. If the story had been 'This article analyzes Linux blah blah blah and finds it somewhat lacking.' the /. community would have been pissing on the author's grave.
However, since the enforcability of the sig is basically a legal issue, everyone gives the (journalist) author of the article a bunch of slack. Now, I (yes, former lawyer) happen to agree that the sig is just so much BS. But that's just the problem. The opinion expressed really - to be accurate - relies on a whole lot of technical legal analysis that the writer clearly does not have. Why does anyone give a rat's ass what this guy says?
'Employment insurance'. Right. Because I need insurance in case I get employed. It used to be called - before the lunatics took over the asylum - 'unemployment insurance'.
Just so you know what your money is going toward. Maybe you agree; maybe you don't. But 'employment insurance'!! Give me an effing break.
IIRC, the Gartner group has said that Loghorm will not be released until 2007. So I think it's closer to 3 years out than 2, fwiw.
porsche has a tiny market share - but nobody suggests they should make a k-car version to get a bigger slice of the pie!
Well... basically that's what the Porche Cayenne is. Porche whored themselves and left their traditional sport car market for a larger user base (profit!).
I don't object (even though I think the Cayenne is an abomination), don't get me wrong. It's just that the Porche analogy is off base.
The thing I like about epicurious is that you can search by ingredient. So if you happen to have squid and tomatoes, you can search for all the recipes that require both. Sometimes you find something worth making that saves you a trip to the store.
Might or might not be true, but don't do the following. This - more or less - is a true conversation.
Boss: I see you posted your resume on Monster on Friday.
Empoloyee: I was just trying to see what was out there. You never know, you know...
Boss: Good move. Because of course, you've got no choice as of now.
Be careful out there.
As a gimic a software company did this with soda. They 'open sourced' the instructions to make the stuff. I think the company blew up in the dot com bust, but it was a cute idea.
Years ago, I had - pretty much - the following conversation with my then boss:
Me: I cannot sign this.
Him: Then you are fired.
Me: Then I guess I am fired, since I cannot sign this.
Him: Oh. I'm sure we can work something out.
Me: That's up to you, since I cannot sign this.
Him: Don't worry about it. You do not have to sign this.
That was basically the conversation. It took less than 5 minutes. It was a fairly small company, and it might work much less well in a larger one. But if you've got real skills, don't let the bastards grind you down.
"Can architect masterful C++ for $4.50 per hour?" I do not mean to denigrate your skills, but I think not. And, with all due respect, I do not care what the local market is like. "Masterful?" Give me a break.
I bought an Apex, had it fail within a week, and got a replacement. (The store did _not_ seem surprised to see me.) The replacement did not work from the beginning.
I returned that one, and got an 'Oritron' branded one for about the same price. Its been working fine for about a year.
I'm sure the technical idiots don't help, but the main problem seems to be the Apex players are crap. I was not surprised by the %80 return estimate from the guy who sells them.
Buy your own 48 person submarine on eBay!
? Vi ewItem&item=2438017155&category=26434
http://cgi.ebay.com/ebaymotors/ws/eBayISAPI.dll
It's important not to shop for submarines impulsively. Shop around, and be sure to get the features you need.
Interesting post, a lot of which I agree with.
There is however one thing I don't understand. I am assuming that the distinction you draw between object-oriented and class-oriented designs / languages is the one about the desirability of run-time binding a la Smalltalk, Python etc. versus compile time al la C++. However, you then say 'if you write Java in a true OO manner' you don't get those types of problems. But Java hasn't got run-time binding, so what am I missing?
I work for a company that creates shrink-wrap software, insofar as that description means anything anymore. It's not cheap.
At least once a quarter, a largish potential customer is persuaded by internal IT that they can write the application more cheaply than buying it from us. The IT department is always wrong. I don't mean mostly wrong. I mean wrong 100% of the time. In the vast majority of cases the company ends up coming back to buy a solution and dumps the in house solution. In some cases the company makes do with something they hate.
Think about it. If there is a company out there that provides something close to what you want, and it has more than a few developers / real tech support / real QA etc., how possibly could an in house solution work better?
1) The company could be charging a completely outrageous amount for the software. Good idea, but that simply doesn't happen. That company is out of business immediately, especially in this economy.
2) The company is selling a product that doesn't exist. Vaporware is a real possibility, but if you can actually pilot the stuff, and it's close to what you want, buy it.
3) The software actually doesn't do what you want. You have unique requirements. This is the only actual legitimate reason to build.
If the software addresses a requirement of your company, and no other, the build it. But if the problem is one faced by some reasonable number of similarly situated companies, then just buy something. Robustness, maintenance, updates, new features, support etc. will be way better. It's the advantage of specialization.