No it isn't too bulky. It is actually smaller than you might think. It fits nicely in my pocket, and is much lighter than you might think. The keyboard is also much better than you might think. Very good feedback from the small buttons. Excellent hardware!
> First off all, it was largely PR and lobbying
> from Netscape, who had gained their market
> position by giving away their browser for free,
> so it's pretty hypocritical of them to complain
> that MS is doing the same.
MS didn't just give it away; they even paid to push it out. I worked at the Swedish Post at the time, and I remember that MS offered us money for putting Explorer on our CDs.
Re:Object Oriented programming is overrated
on
Why not Ruby?
·
· Score: 1
> So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping.
No, that is not the most important aspects of OOP. My choice is Data Abstraction and Encapsulation. I think you're looking at the wrong parts of OOP.
No, it does not make sense, but
on
Eco-Terrorism
·
· Score: 1
Of course, burning up a bunch of cars is environmentally crazy, but the sad thing is that most americans label people doing it as crazy, and then just goes on with their lives.
Americans are absolute bastards when it comes to the environment. We (I'm swedish but live in the US) are the richest country in the world, and have a president that claims that "High energy consumption is the american way". America has such a responsibility, but we're totally blowing it because of ignorance. Sad, very sad.
A common trait of many of the companies that
failed is that they gave away for free or at
a loss the very thing they produced that was
of greatest value - in the hope that somehow
they'd make money selling something else.
Gee, that sounds a lot like this story about a big company spending half a billion dollars creating a web browser and then paying people for using it.
I don't know that much about freenet, so I wonder if it would be possible for RIAA or any other organization that wants it to fail to just insert so much junk that it gets to be useless? If they insert an Elvis song and labels it as something I like, then I will be deeply disappointed when I play it. Or if they just "spam" it will millions and millions of MP3's that are just empty files or something similar.
It is pretty clear that he should step out of the OSS world for a few minutes and see that Java is a huge language, particularly on the server side. The mere fact that he mostly talks about Java applets makes it very clear that he doesn't have a clue. The sad thing is that he can't see where his limits are, since that would refrain him from making a fool of himself.
"Make sure you buy or use open source" applies to in-house projects only, of course.
And "make clean;make" was a recommendation, not a rule, just because of the reason you mention, since it can take too much time. We use make + Java, and it I'm not sure it works that well. Is Ant the solution?
Rule 0: Don't break a rule unless you have a very good reason for doing so.
Rec: Make sure a project manager is dedicated to your project.
Rec: Have regular project meetings, typically once a week, with all participants, where all kinds of project issues are discussed.
Rec: Manage risks (by using the likelyhood * severity formula)
Rule: Involve the user in the process. (This is the single most important reason why projects are successful).
Rec: Select a set of tools that works well, document its use, and make it the default tools for the project.
Rule: Use a version management tool, such as CVS, to handle your code and documentation.
Rec: When checking in code, write meaningful descriptions for the changes.
Rule: Before developing a completely new product, make sure you can't buy a similar product, or use an open source product.
Rule: Use short release cycles.
Rec: Create Use Cases (or stories) for how features are used by the customer.
Rec: Let developers estimate their own tasks so that they are realistic.
Rec: Use the Stories as the basis for writing test cases.
Rec: Write test cases for new features before you implement the feature itself.
Rec: Make sure test cases are easy to configure, run and automate.
Rec: Automatically run the test suite after each build.
Rec: Update the list of desired features after each release cycle.
Rec: Write a Release Note after each release, where all known issues are listed.
Rec: Use a programming standard.
Rec: Use a code style standard.
Rec: Review eachothers code.
Rule: Don't leave commented out code in the files, unless you explain why it is there.
Rule: Check in files in the correct order, so that the risk of corrupt intermediate checkouts by your coworkers are minimized.
Rule: Make a diff on your changes before you check them in.
Rec: A function should do one thing and one thing only.
Rec: You should never make. You should always "make clean;make".
Rec: If you've changed a file, don't ever close it until you've checked it in, since open files are a good way to remember which files you've edited and needs to be checked in.
> Chernobyl... incident really just goes to show you the drawbacks of communism, not nuclear power
So, is Three Mile Island in a Communist country?
> Another thing worth noting is that electric cars are a stupid idea if the electricity is generated by burning fossil fuels.
Nonono, you're missing the point; if the electricity is produced at a huge power plant, then you can spend tens of millions of $$ on filters and stuff to get the bad stuff out, while cars absolutely sucks in this respect, since you can't afford it for each individual car.
> wouldn't it be fun to ultimately travel from
> Tierra del Fuego to Johannesburg by train?"
There are more issues that needs to be addressed:
1. The only way from Asia to Africa is across the
Sinai desert, where there are no rails.
2. If you manage to get into Africa, how are you
going to cross the Sahara desert? There is no
rail from Sudan to Uganda, so you're toast.
The real reason why Microsoft invented this new language is that writing COM components in C++ sucks really bad, and VB isn't really powerful enough for writing COM. Java would have been perfect, but it turned out to be a too good language, so they did this instead.
> However, considering the amount of mail delivered and the regular level of service this organization > maintains, they actually do a pretty good job. Far better than their counterparts in other countries.
Ahem, what makes you believe it does a better job than, say, the Swedish Postal Service?
> There are so many problems with it [Linux] right now..installing programs, removing them...
Linux may have a long way to go, but installation problems certainly isn't any of the major problems. apt-get on Debian is insanely great. Try it out!
Re:Here is the secret for staying in demand
on
Too Old To Code?
·
· Score: 1
"CVS, patches, peer reviews, no managers" may be cool, but knowledge in those areas aren't going to boost your salary by much, which was what the question was all about. And noone can call CVS cool by itself. Plus it is a dead end as a source base. Noone is going to bring it up to date with what is state of the art today.
Smalltalk-80 versus Java... well, Java has a much more familiar syntax, and industry momentum. ST was after all not that big as a language.
No it isn't too bulky. It is actually smaller than you might think. It fits nicely in my pocket, and is much lighter than you might think. The keyboard is also much better than you might think. Very good feedback from the small buttons. Excellent hardware!
> I have yet to see anything that resembles MS Project on Linux
Try Enact:
http://www.enact.cc/
Maybe one out of 10 does it well.
> First off all, it was largely PR and lobbying
> from Netscape, who had gained their market
> position by giving away their browser for free,
> so it's pretty hypocritical of them to complain
> that MS is doing the same.
MS didn't just give it away; they even paid to push it out. I worked at the Swedish Post at the time, and I remember that MS offered us money for putting Explorer on our CDs.
> So what really separates Objects from regular old modern programming? I say two things: inheritance and subtyping.
No, that is not the most important aspects of OOP. My choice is Data Abstraction and Encapsulation. I think you're looking at the wrong parts of OOP.
Of course, burning up a bunch of cars is environmentally crazy, but the sad thing is that most americans label people doing it as crazy, and then just goes on with their lives.
Americans are absolute bastards when it comes to the environment. We (I'm swedish but live in the US) are the richest country in the world, and have a president that claims that "High energy consumption is the american way". America has such a responsibility, but we're totally blowing it because of ignorance. Sad, very sad.
We delivered this baby in 1996:
http://www.ccc.lu/3c/prod01.htm
> Will this further solidify Qt's position as the de facto way to develop cross-platform applications?
Get real!! The de facto standard for cross-platform development is Java, and will remain so.
> chips in our asses
No way! It will be satellite dishes!!!
Quote from the interview:
A common trait of many of the companies that
failed is that they gave away for free or at
a loss the very thing they produced that was
of greatest value - in the hope that somehow
they'd make money selling something else.
Gee, that sounds a lot like this story about a big company spending half a billion dollars creating a web browser and then paying people for using it.
www.anoto.com
Hi!
I don't know that much about freenet, so I wonder if it would be possible for RIAA or any other organization that wants it to fail to just insert so much junk that it gets to be useless? If they insert an Elvis song and labels it as something I like, then I will be deeply disappointed when I play it. Or if they just "spam" it will millions and millions of MP3's that are just empty files or something similar.
Just curious...
It is pretty clear that he should step out of the OSS world for a few minutes and see that Java is a huge language, particularly on the server side. The mere fact that he mostly talks about Java applets makes it very clear that he doesn't have a clue. The sad thing is that he can't see where his limits are, since that would refrain him from making a fool of himself.
"Make sure you buy or use open source" applies to in-house projects only, of course.
And "make clean;make" was a recommendation, not a rule, just because of the reason you mention, since it can take too much time. We use make + Java, and it I'm not sure it works that well. Is Ant the solution?
http://jakarta.apache.org/ant/index.html
No-nonsense SW Development Process, version 0.01
By Mats Henricson
Rule 0: Don't break a rule unless you have a very good reason for doing so.
Rec: Make sure a project manager is dedicated to your project.
Rec: Have regular project meetings, typically once a week, with all participants, where all kinds of project issues are discussed.
Rec: Manage risks (by using the likelyhood * severity formula)
Rule: Involve the user in the process. (This is the single most important reason why projects are successful).
Rec: Select a set of tools that works well, document its use, and make it the default tools for the project.
Rule: Use a version management tool, such as CVS, to handle your code and documentation.
Rec: When checking in code, write meaningful descriptions for the changes.
Rule: Before developing a completely new product, make sure you can't buy a similar product, or use an open source product.
Rule: Use short release cycles.
Rec: Create Use Cases (or stories) for how features are used by the customer.
Rec: Let developers estimate their own tasks so that they are realistic.
Rec: Use the Stories as the basis for writing test cases.
Rec: Write test cases for new features before you implement the feature itself.
Rec: Make sure test cases are easy to configure, run and automate.
Rec: Automatically run the test suite after each build.
Rec: Update the list of desired features after each release cycle.
Rec: Write a Release Note after each release, where all known issues are listed.
Rec: Use a programming standard.
Rec: Use a code style standard.
Rec: Review eachothers code.
Rule: Don't leave commented out code in the files, unless you explain why it is there.
Rule: Check in files in the correct order, so that the risk of corrupt intermediate checkouts by your coworkers are minimized.
Rule: Make a diff on your changes before you check them in.
Rec: A function should do one thing and one thing only.
Rec: You should never make. You should always "make clean;make".
Rec: If you've changed a file, don't ever close it until you've checked it in, since open files are a good way to remember which files you've edited and needs to be checked in.
I wish all press releases were like that. Funny, informative and short. I bet the author has read "The Cluetrain Manifesto":
http://www.cluetrain.com/
> scientists don't agree on global warming.
Wrong, very wrong. The only scientist that don't agree are the ones bought by the industry. This is a pretty well known fact.
But I guess you need to see your skin fry to coal before you're convinced?
> Chernobyl ... incident really just goes to show you the drawbacks of communism, not nuclear power
So, is Three Mile Island in a Communist country?
> Another thing worth noting is that electric cars are a stupid idea if the electricity is generated by burning fossil fuels.
Nonono, you're missing the point; if the electricity is produced at a huge power plant, then you can spend tens of millions of $$ on filters and stuff to get the bad stuff out, while cars absolutely sucks in this respect, since you can't afford it for each individual car.
> wouldn't it be fun to ultimately travel from
> Tierra del Fuego to Johannesburg by train?"
There are more issues that needs to be addressed:
1. The only way from Asia to Africa is across the
Sinai desert, where there are no rails.
2. If you manage to get into Africa, how are you
going to cross the Sahara desert? There is no
rail from Sudan to Uganda, so you're toast.
The real reason why Microsoft invented this new language is that writing COM components in C++ sucks really bad, and VB isn't really powerful enough for writing COM. Java would have been perfect, but it turned out to be a too good language, so they did this instead.
> However, considering the amount of mail delivered and the regular level of service this organization
> maintains, they actually do a pretty good job. Far better than their counterparts in other countries.
Ahem, what makes you believe it does a better job than, say, the Swedish Postal Service?
http://www.posten.se
> I'd pay a micro-payment to yank banner ads from websites I frequent.
Why, when you can do it for free with Junkbuster?
http://www.junkbusters.com
Anyone knows?
> There are so many problems with it [Linux] right now..installing programs, removing them...
Linux may have a long way to go, but installation problems certainly isn't any of the major problems. apt-get on Debian is insanely great. Try it out!
"CVS, patches, peer reviews, no managers" may be cool, but knowledge in those areas aren't going to boost your salary by much, which was what the question was all about. And noone can call CVS cool by itself. Plus it is a dead end as a source base. Noone is going to bring it up to date with what is state of the art today.
Smalltalk-80 versus Java... well, Java has a much more familiar syntax, and industry momentum. ST was after all not that big as a language.