Doesn't it?
The "ignorant majority", as you call them, simply do not give a flying flip if 13 people are still playing Halo 2. They don't care that you can't play Halo 2 on XBL. Frankly, I don't care either.
Eventually every game you buy and love multiplayer will have no one left to play with. It sucks a little bit that Microsoft has the power to move that date up, but it doesn't suck enough for me to not buy XBL games.
Don't expect the "ignorant majority" to fight a battle for you when they simply do not care.
Well that explains everything.
The < operator, when typed straight from the keyboard, gets filtered out. The parent post, like me, didn't properly check his "preview".
Try "i <= 10" ftw.
Oh btw, Anonymous Coward = me, forgot to log in.
The problem, I think, runs a little deeper than all that though.
SQL is unfortunately tied fairly tightly to an RDBMS implementation. All those "join" statements, various ways of expressing "constraints" such as "foreign keys" - all are considered "integral" parts of SQL.
No, you don't have to provide them. A Post-Relational like Amazon SimpleDB could, theoretically, use SQL for querying and just trim back the feature-set.
But perhaps it'd be wiser to look at a query language more specific to the Post-Relational model?
Perhaps SQL stopped being "SQL" and started being "Structured Relational Query Language". *shrugs*
Is it spending 3 weeks drawing diagrams that, in 3 more weeks, won't represent the true state of the system at all?
You draw your diagram. I'll spend 1 night doing a rough-shot prototype. I'll "hack" it.
Then I'll use that prototype when I create a well-architected system. Then, since I share my stuff lots, other "hackers" will help improve that design.
Be careful when you discard one set of "propaganda", and listen blindly to another. Maybe "hackers" aren't so "evil" after all. After all, I don't remember signing up for any cult.
Oh really?
http://en.wikipedia.org/wiki/Hacker_ethic
Hacker Ethic is knowledge sharing, decentralization, respect based on merit.
Compare that to the "professional" environment where certain races or genders can't advance past the "glass ceiling".
Yup, those hackers sure suck. Generalizing is fun.
If that headache plaguing you this morning led you first to a Web search and then to the conclusion that you must have a brain tumor, you may instead be suffering from cyberchondria.
Cyberchondria is when you search the net for your symptoms and suddenly start panicking because you think you might have something bad.
This suggests the opposite of your post - you should consult medical professionals.
Dermatology is a completely different beast, because many skin conditions have no real tests. The creed of dermatology is "if the area is moist, make it dry, and if it's dry, make it moist". I've had a problem for 2 years now undiagnosed. *shrugs*
This offer is far from comprehensive, though, as it excludes case cracks, small numbers of dead pixels, broken keys, smashed screens, software issues, virus infections or failed batteries that are older than one year.
Basically, the normal wear and tear of a laptop is excluded. This seems particularly negligent regarding failed batteries, as I've noticed that most laptops become almost unusable after a few years. Even with a RAM upgrade after 3 years, it is unlikely to last much longer than that, especially if broken keys and worn out batteries aren't included. (Are batteries even designed to last that long?
Man, you've taken the article out of context. You're implying that what you're describing relates to the Lifebook4Life program - it does not.
For anyone too lazy to read, here's what they -actually- said.
From TFA:
The company is also launching another interesting scheme with its Esprimo range, offering a complete refund of the original sales price if the customer needs to send the notebook back to Fujitsu Siemens for any repairs.
This offer is far from comprehensive, though, as it excludes case cracks, small numbers of dead pixels, broken keys, smashed screens, software issues, virus infections or failed batteries that are older than one year.
They're offering full refund on the -first- sign of trouble. It's only fair that they exclude normal wear and tear. No company can make money by giving you back all your money every 3 years because you cracked the case, come on!
I'm working on a project that's been going probably 10+ years. No, I wasn't one of the originals - none of them are even around. So just pretend for a moment that all the technology we have today was available 10 years ago. You're pretty pro, think you can get _all_ of the requirements for the next 10 years and beyond out of your client on the first try before you write a single line of code? Good luck.
Customers don't know what they want. Period. You can ask them, interview them, and you'll get a lot of very telling answers. You'll build what they said they wanted... and it's not what they wanted! Why not? Because it was what they wanted 6 months ago when you started.
Worse than that, customers have a nasty habit of not knowing what they want until its delivered. We did a photoshop mockup of a UI for a feature we were adding, and got it approved by our customer, before proceeding on a recent feature-addition. He still liked it the day we tried to deliver... until he used it. Then we spent another two weeks changing the UI and some of the underlying functionality linked to it.
The fact of the matter is that the requirements and scope change. You can't prevent it. Yes, you should spend some time determining requirements, try to minimize the harmful effects of change, but you cannot _cannot_ prevent it.
Perhaps he might even hire a troll. Who knows.
Perhaps he might even hire an Agile programmer instead of a Waterfall one. Who knows.
You're not mistaken, Chrome in fact does use WebKit as its rendering engine. And it is the same rendering engine Safari uses.
I'm not 100% on what components come from where, but I'm not convinced WebKit is to blame for the Javascript quirks. (DOM may be another matter.)
After all, Chrome actually has its own brand new Javascript engine based on a JSVM called V8. The thing is lightning fast, not going to lie, but I'm thinking they still have a few quirks.
Exactly. Anyone arguing against branching either a) has never worked on a large scale production or b) isn't able to wrap their mind around keeping track of various branches. The system suggested by the grandparent would be a disaster at any of the places I've worked. It just doesn't allow any flexibility in responding to the needs of the customer. Most software teams now are moving towards the 'agile' model, or some variation, and the tools that they use should reflect their principles. So branching is a given, the question is, which system does it best?
Everyone is living in a personal delusion, just some are more delusional than others.
I think it's more that some people agree to have the same delusions.:-)
Dude... how is branching a given? If you're running Test Driven Development + Agile things should always be stable and transparent.
Changing to TDD+Agile from Waterfall-ish styles overnight? Heck yes that would be a disaster. Period. You have to make a more gradual step-by-step change.
Right now our team is doing exactly that. The company hired someone, and we're learning how to do it right.
Here's the TDD+Agile cycle, as he explained to us yesterday:
Write tests (only a few)
Write as little code as possible to make them pass
Refactor the existing architecture, if needed, to adapt (timebox this)
Commit
And this should happen, as he said, on order of 20 times a day. Just today I've committed 5 times and I'm just learning
Ok, I think I get what dubl-u is getting at. And I agree. I'll admit before I start, though, that I'm spoiled. Our project lead acts as the proxy to the customer, and understands the processes involved very very well, so he's very sympathetic to our needs as developers and communicates them effectively to our client.
"Tagging" and "Branching" in SVN are handled the same way - they're identical, but have different names. They really are conceptually different - two different tools that are implemented the same way. It really is important to remember the difference between them, because most of your post can be handled.
"Tagging" is a point-in-time snapshot of the code. It stays where it is, you don't develop on it, it just sits there. It's good practice, for example, to tag releases of your software. When you release Version 1.2.3 you make sure to create a tag for V1.2.3. You really shouldn't be updating this code at all.
There are situations where you want to edit the code in a tag. High-priority production issues, for example, sometimes require a re-release. In these instances, you should be checking out the tag and making your changes there. Then you commit there, and you patch the changes to your current trunk. Re-release as necessary, of course.
"Branching" is for when you want two concurrent versions of your software to be developed. In my experience, this is most commonly used for two incompatible versions of the code, such as "Windows" version and "Linux" version, or "Implemented using Java Servlet" vs "Implemented using PHP". Occasionally you actually branch in order to develop a long-term change in parallel with the main software, then merge it in. I recommend, if you're doing this, that you actually patch the changes accross from the trunk to the experimental branch as often as possible - this reduces complexity of merging.
One last thing to note: I recommend using 2 repositories if you want to expose the SVN to your customer (as we do). One is your Release Repo and this is where you commit releases to allow your customer access after they've been cleared, and the other is a development repo that you use in-house.
Since many of my answers here are going to be the same, I'm going to shorten my post - whenever I say "Tag, Update, Patch" I am referring to the practice of tagging your releases, making high-priority updates there, and then quickly patching your trunk. You always want to edit the tag, because it's easier to patch the changes to the head. Also, with short cycles, it should never be more than a few weeks between releases, so the code differences between a tag and a head should be minimal.
So I guess you've never worked in the real world, where corporate mandates a change that has to go out before EOB same day, or where you are half way through a feature set impl, and management changes the priorities. What do you do with that code then? Or when the CTO ups and quits, and his info has to be yanked from the website in 30 minutes or less.
High-priority changes requiring a re-release.
Tag, Update, Patch
Often you need three branches at least, one for dev, one for staging, and one for production. And that's not counting the system rewrite branch that might be bumbling along in the background perpetuated by another developer whose been assigned to fixing all the wrongs in the current system.
Branches, or tags? Prod and staging should be copies of your latest Release Repo head, or your latest tag.
Tag, Update, Patch.
System Rewrite? Are you _rewriting_ or just doing maintenance? Rewriting is probably not something you want to merge your old faulty code with, and maintenance should be done on the head revision.As for your system rewrite - if the system is being _rewritten_, do you really want to merge parts of the old system back into it? Really? I'm not sure what you're getting at here. If you're talking standard maintenance though, I say he should be working in the trunk ju
Slashdot Mirror
Doesn't it? The "ignorant majority", as you call them, simply do not give a flying flip if 13 people are still playing Halo 2. They don't care that you can't play Halo 2 on XBL. Frankly, I don't care either. Eventually every game you buy and love multiplayer will have no one left to play with. It sucks a little bit that Microsoft has the power to move that date up, but it doesn't suck enough for me to not buy XBL games. Don't expect the "ignorant majority" to fight a battle for you when they simply do not care.
Well that explains everything. The < operator, when typed straight from the keyboard, gets filtered out. The parent post, like me, didn't properly check his "preview". Try "i <= 10" ftw. Oh btw, Anonymous Coward = me, forgot to log in.
The problem, I think, runs a little deeper than all that though.
SQL is unfortunately tied fairly tightly to an RDBMS implementation. All those "join" statements, various ways of expressing "constraints" such as "foreign keys" - all are considered "integral" parts of SQL.
No, you don't have to provide them. A Post-Relational like Amazon SimpleDB could, theoretically, use SQL for querying and just trim back the feature-set.
But perhaps it'd be wiser to look at a query language more specific to the Post-Relational model?
Perhaps SQL stopped being "SQL" and started being "Structured Relational Query Language". *shrugs*
What is proper design?
Is it spending 3 weeks drawing diagrams that, in 3 more weeks, won't represent the true state of the system at all?
You draw your diagram. I'll spend 1 night doing a rough-shot prototype. I'll "hack" it.
Then I'll use that prototype when I create a well-architected system. Then, since I share my stuff lots, other "hackers" will help improve that design.
Be careful when you discard one set of "propaganda", and listen blindly to another. Maybe "hackers" aren't so "evil" after all. After all, I don't remember signing up for any cult.
Oh really? http://en.wikipedia.org/wiki/Hacker_ethic Hacker Ethic is knowledge sharing, decentralization, respect based on merit. Compare that to the "professional" environment where certain races or genders can't advance past the "glass ceiling". Yup, those hackers sure suck. Generalizing is fun.
Paragraph 1:
If that headache plaguing you this morning led you first to a Web search and then to the conclusion that you must have a brain tumor, you may instead be suffering from cyberchondria.
Cyberchondria is when you search the net for your symptoms and suddenly start panicking because you think you might have something bad.
This suggests the opposite of your post - you should consult medical professionals.
Dermatology is a completely different beast, because many skin conditions have no real tests. The creed of dermatology is "if the area is moist, make it dry, and if it's dry, make it moist". I've had a problem for 2 years now undiagnosed. *shrugs*
From TFA:
This offer is far from comprehensive, though, as it excludes case cracks, small numbers of dead pixels, broken keys, smashed screens, software issues, virus infections or failed batteries that are older than one year.
Basically, the normal wear and tear of a laptop is excluded. This seems particularly negligent regarding failed batteries, as I've noticed that most laptops become almost unusable after a few years. Even with a RAM upgrade after 3 years, it is unlikely to last much longer than that, especially if broken keys and worn out batteries aren't included. (Are batteries even designed to last that long?
Man, you've taken the article out of context. You're implying that what you're describing relates to the Lifebook4Life program - it does not.
For anyone too lazy to read, here's what they -actually- said.
From TFA:
The company is also launching another interesting scheme with its Esprimo range, offering a complete refund of the original sales price if the customer needs to send the notebook back to Fujitsu Siemens for any repairs.
This offer is far from comprehensive, though, as it excludes case cracks, small numbers of dead pixels, broken keys, smashed screens, software issues, virus infections or failed batteries that are older than one year.
They're offering full refund on the -first- sign of trouble. It's only fair that they exclude normal wear and tear. No company can make money by giving you back all your money every 3 years because you cracked the case, come on!
Sorry Duckie, but you're still missing the point.
I'm working on a project that's been going probably 10+ years. No, I wasn't one of the originals - none of them are even around. So just pretend for a moment that all the technology we have today was available 10 years ago. You're pretty pro, think you can get _all_ of the requirements for the next 10 years and beyond out of your client on the first try before you write a single line of code? Good luck.
Customers don't know what they want. Period. You can ask them, interview them, and you'll get a lot of very telling answers. You'll build what they said they wanted... and it's not what they wanted! Why not? Because it was what they wanted 6 months ago when you started.
Worse than that, customers have a nasty habit of not knowing what they want until its delivered. We did a photoshop mockup of a UI for a feature we were adding, and got it approved by our customer, before proceeding on a recent feature-addition. He still liked it the day we tried to deliver... until he used it. Then we spent another two weeks changing the UI and some of the underlying functionality linked to it.
The fact of the matter is that the requirements and scope change. You can't prevent it. Yes, you should spend some time determining requirements, try to minimize the harmful effects of change, but you cannot _cannot_ prevent it.
Perhaps he might even hire a troll. Who knows.
Perhaps he might even hire an Agile programmer instead of a Waterfall one. Who knows.
You're not mistaken, Chrome in fact does use WebKit as its rendering engine. And it is the same rendering engine Safari uses.
I'm not 100% on what components come from where, but I'm not convinced WebKit is to blame for the Javascript quirks. (DOM may be another matter.)
After all, Chrome actually has its own brand new Javascript engine based on a JSVM called V8. The thing is lightning fast, not going to lie, but I'm thinking they still have a few quirks.
So I guess you've never worked in the real world
Exactly. Anyone arguing against branching either a) has never worked on a large scale production or b) isn't able to wrap their mind around keeping track of various branches. The system suggested by the grandparent would be a disaster at any of the places I've worked. It just doesn't allow any flexibility in responding to the needs of the customer. Most software teams now are moving towards the 'agile' model, or some variation, and the tools that they use should reflect their principles. So branching is a given, the question is, which system does it best?
Everyone is living in a personal delusion, just some are more delusional than others.
I think it's more that some people agree to have the same delusions. :-)
Dude... how is branching a given? If you're running Test Driven Development + Agile things should always be stable and transparent.
Changing to TDD+Agile from Waterfall-ish styles overnight? Heck yes that would be a disaster. Period. You have to make a more gradual step-by-step change.
Right now our team is doing exactly that. The company hired someone, and we're learning how to do it right.
Here's the TDD+Agile cycle, as he explained to us yesterday:
And this should happen, as he said, on order of 20 times a day. Just today I've committed 5 times and I'm just learning
Ok, I think I get what dubl-u is getting at. And I agree. I'll admit before I start, though, that I'm spoiled. Our project lead acts as the proxy to the customer, and understands the processes involved very very well, so he's very sympathetic to our needs as developers and communicates them effectively to our client.
"Tagging" and "Branching" in SVN are handled the same way - they're identical, but have different names. They really are conceptually different - two different tools that are implemented the same way. It really is important to remember the difference between them, because most of your post can be handled.
"Tagging" is a point-in-time snapshot of the code. It stays where it is, you don't develop on it, it just sits there. It's good practice, for example, to tag releases of your software. When you release Version 1.2.3 you make sure to create a tag for V1.2.3. You really shouldn't be updating this code at all.
There are situations where you want to edit the code in a tag. High-priority production issues, for example, sometimes require a re-release. In these instances, you should be checking out the tag and making your changes there. Then you commit there, and you patch the changes to your current trunk. Re-release as necessary, of course.
"Branching" is for when you want two concurrent versions of your software to be developed. In my experience, this is most commonly used for two incompatible versions of the code, such as "Windows" version and "Linux" version, or "Implemented using Java Servlet" vs "Implemented using PHP". Occasionally you actually branch in order to develop a long-term change in parallel with the main software, then merge it in. I recommend, if you're doing this, that you actually patch the changes accross from the trunk to the experimental branch as often as possible - this reduces complexity of merging.
One last thing to note: I recommend using 2 repositories if you want to expose the SVN to your customer (as we do). One is your Release Repo and this is where you commit releases to allow your customer access after they've been cleared, and the other is a development repo that you use in-house.
Since many of my answers here are going to be the same, I'm going to shorten my post - whenever I say "Tag, Update, Patch" I am referring to the practice of tagging your releases, making high-priority updates there, and then quickly patching your trunk. You always want to edit the tag, because it's easier to patch the changes to the head. Also, with short cycles, it should never be more than a few weeks between releases, so the code differences between a tag and a head should be minimal.
So I guess you've never worked in the real world, where corporate mandates a change that has to go out before EOB same day, or where you are half way through a feature set impl, and management changes the priorities. What do you do with that code then? Or when the CTO ups and quits, and his info has to be yanked from the website in 30 minutes or less.
High-priority changes requiring a re-release.
Tag, Update, Patch
Often you need three branches at least, one for dev, one for staging, and one for production. And that's not counting the system rewrite branch that might be bumbling along in the background perpetuated by another developer whose been assigned to fixing all the wrongs in the current system.
Branches, or tags? Prod and staging should be copies of your latest Release Repo head, or your latest tag.
Tag, Update, Patch.
System Rewrite? Are you _rewriting_ or just doing maintenance? Rewriting is probably not something you want to merge your old faulty code with, and maintenance should be done on the head revision.As for your system rewrite - if the system is being _rewritten_, do you really want to merge parts of the old system back into it? Really? I'm not sure what you're getting at here. If you're talking standard maintenance though, I say he should be working in the trunk ju