What I wish for is a tool that constantly downloads changes from all of the other developers' trees and highlights the lines that have changed in whatever file you're working on (but does not merge them), and optionally lets you view the changes. So you can immediately see if someone else has modified code that you want to mess with, and you can call up that person and negotiate a compromise or proper fix. Network bandwidth would be a total hog, but the time saved when you don't have to suddenly discover that someone else broke all of your changes.
You know, 12 UI changes to be made divided by 6 developers = 2 UI changes per developer. Nice "perfect" load balancing. Never mind that 5 of those 6 now have to learn the structure of the UI system developed by the 6th and not yet documented for public consumption and that the 6th could have implemented all 12 changes himself in the same time as the entire team.
Rock on, dude! Prima donnas (sp?) may suck, but no matter what, 90% of the real coding is done by 10% of the coders. If I were a manager, I would rather "balance" the load by assigning each one or two developers to a specific piece of the system, and have them become experts at it. Then, I'd give all 12 fixes to the UI expert(s), and if he couldn't handle it, let him ask one of the less-busy experts in another area to help out on the changes for which the learning curve isn't too high.
Almost all software projects or mostly-self-contained components start out with one or maybe two people doing all of the initial coding. It takes a lot of work to get it to a point where more people can even start to work on it concurrently.
So if you are starting a project, plan modularly so there are not conflicts between the different "experts". Separate concerns. Also, lessons learned here will help when your project becomes so large or old that no single person knows the entire system.
That's not a problem with designing the code modularly, that's a problem (and a major one) with the company. Besides, with CVS and other similar systems, it isn't even really possible to take out a lock on a file. If your company was too stupid or too lazy to make branches and tags of the code and to learn how to do merges, then any other problems are completely secondary. You will find they all but go away when you learn how to manage the code properly and communicate between departments.
As early as possible in the development stage, we try to identify what will be finished when, and assign a one-up sequence number to each patch. Developers then know that they will be patching against the baseline that was patched by the patch with the previous sequence number. It is hoped that this prevents a lot of rework of patches. A potential problem with this approach is the need for a responsive central authority to assign sequence numbers. Also, such sequence numbers may have to be rearranged in the face of last minute advances and setbacks in developer progress. Despite careful scheduling and detailed design, it may be impossible to know the exact check-in sequence of patches more than a week or two in advance.
When Subversion is ready, you might check it out. It keeps track of not specific versions for files, but revisions/patches for the entire tree. This way you can tell exactly the state of all the code at, say, revision 2735. No manual tagging needed. This would take up a lot of the work of your sequence numbers, without the severe administrative overhead. You could even try to assign a range of actual revisions for which a specific feature is targetted.
I'm already using Subversion for the early stages of one of my projects. It seems to be very stable currently, and of course I still make backups of the DB in case there still remain bugs that would corrupt it. I figure, I won't need to make any branches or merges in this project until well after the time that subversion can support it (due in April).
Are you kidding? If I spin the wheel for a while in IE on Windows (or hold down the down-arrow for that matter), it will take several seconds for the damn screen to catch up, during which time it is completely unresponsive. Personally, I appreciate the fact that Mozilla doesn't try and do "smooth scrolling", because apparantly IE will never get it right.
But in something like AOL, if the engineers have started integrating it, then imagine the cost to restart all of the re-testing, re-integration, and wasted time if they were to back down.
Of course I won't believe it until I see it either...
Not trying to be pedantic, but XML does not allow binary sections. You cannot say "�", for example. The best you can do is encode the data in Base64 or something.
It's funny, I went skiing this weekend with some friends who are very beginner, and they were talking about trying it out and taking lessons this summer on that conveyer belt. Fortunately, according to Yahoo Yellow Pages at least, it still exists.
I'm pretty sure anyone who is capable of carving (ie., has at least a couple years experience) wouldn't waste their time on this. It sounds like a tool that would be more successful at teaching beginners who are too afraid to actually start moving on real snow, since this thing could be stopped whenever they want.
That brings up an interesting point though: how are you supposed to learn to turn properly if you move at different speeds when you turn left or right? One of the biggest problems I had when learning was that I was better at turning left than right for a long time, and it really hurt me when skiing tougher terrain like moguls and deep snow. Eventually I figured it out, but that's a problem that will have to be resolved before I would send my kids to learn on this.
Heh, I was about to post how the Olympic Sports in Seattle (Northgate) had one of those, but you got it first. I don't know if it's still there, but it was last time I was in that store (probably two years ago). My mom and my sister learned to ski on that conveyer belt before taking to the real slopes.
Have you ever been skiing? If you have, you know that at 100kph, the wind resistance against your upright body can almost knock you flat on your ass. The lower center of gravity does help in turns, I suppose, but the goal is not to spin faster (like a figure skater). In fact, racers often extend their arms while turning to help with balance (while still in a tuck).
If this is the case then the copyrights would revert back to the artists.
But what happens when the industry loses the copyrights? Unfortunately, and I hope this is not the case, artists could lose their corporate backing. All of a sudden, there is nobody around to pay for album production, tours, and promotion. Only the big-time artists could survive in the light of the general public, and we'd still be stuck with two choices: N'Sync and Brittany Spears. It's an interesting situation, and like I said, I *really* hope that doesn't happen:)
Seems to me like everyone posts these because they know they can get the karma boost, not because they really care about it. They know the editors are bound to use it.
It's a vicious cycle; people post to get the karma, the editors use it because they think lots of people are interested, and then more people post because they know the editors will use it.
At least when I go to bugzilla.mozilla.org and I can actually see the discussions the developers are having on the bug that I want fixed, I feel like something will get done. Even though I know that their resources are limited, so their response time might be a few months for non-critical bugs, at least they know about it.
When I have a bug and call some 3rd-party tech support, and they tell me to reboot my computer and then give up, I don't have those assurances. For all we know, and for all we bitch and moan, Microsoft probably doesn't even *want* to fix many of the bugs in IE, such as those related to standards compliance. I *know* that the Mozilla people care, even if they can't fix everything immediately.
As great as that would be, the first person to write a regular expression engine that can process a petabyte of indexed web-pages in 0.25 seconds should get more than $10,000!
The problem is that search engines use pre-indexed tables of words, probably one table for every word used by any page anywhere. Regular Expressions have to process the raw data, which wouldn't scale worth a dime.
Um... okay... People might be a little scared, but only the stupid ones. I don't know anyone here in the US that is seriously panicking 24/7 because of the 1/1m chance they will be killed by a terrorist. Other countries (Isreal, Palistine) put up with far worse. The only people considering revolution are the Texas gun-totin' militia hate groups.
Have you seen the m505 or IIIc handhelds? Palm has had color for a while. Also, PalmOS still runs the vast majority of handhelds. The reason Palm has lost market share is because, in addition to saturation (which doesn't account for 44% but is definitely real), other PalmOS handhelds like Handspring, Sony, and Handera are kicking ass by supporting higher resolution screens and MP3 players. Palm's hardware sales might be down, which is why they recently split off the PalmOS group as a separate company. PalmOS isn't going anywhere.
Personally I tend to believe that it's the tech support that's stupid, and they don't even know enough to tell whether it's the stupid customer or themselves. During the recent Excite -> AT&T fiasco, my connection was a week slower to come back up than the rest of my city, and you should have heard the bullshit that came out of their mouths.
Let's put it this way: I will never ever waste my time with AT&T's "live Internet chat" customer support again. It may be "live", but only so much as you can call somebody hitting C-x, C-v over and over again "live":)
At least I got double credits for my downtime, so I guess they learned their lesson in that respect. That was half a month free for me!
I Am Not A Carbon Nanotube Scientist, but I think that the tubes strength comes when they are streched (tension), but not necessarily when there are other forces. So it might be pretty easy to snip the tubes when cut from the side.
Exactly... you can engineer a distributed system that is more reliable than even the best single-unit system (in the low-to-mid-range market, at least). The price is far cheaper to start with, and you have to go through several replacements before your hardware costs approach the cost of the single system (by which time you would have had to do replacements in the single system as well, increasing its cost... and so on).
If your company wants a mainframe that costs $1m or more, then there isn't really any commodity alternative. But for low-to-mid-range solutions, so long as you have an in-house tech team capable of living without paying for Sun's support, it's a tough call.
This has to be a troll or flaimbait, because that is just plain not true. The only problems Java has running cross-platform are certainly not related to binary or bytecode, they are if you use native libraries or don't do your file-system access correctly.
Just use GCC (PRC-tools, with Pilrc), Emacs, and the SDK which you can download in 4 clicks (see comment above). POSE is also awesome; the only thing you might have trouble with is getting Debug ROMs (but if you are in the USA, you can register and get them within 36 hours like I did a few weeks ago). And the SDK documentation is among the best available of any platform.
Part of the reason why this doesn't happen, unfortunately, is that the software developers and programmers continue to 1) push existing processing performance capabilities, and/or 2) write ineficient code. In my experience, it's been a combination of those two, with the stress on 2).
One of the great things about Palm (and one of the things that might indeed make hardware saturation a reality) is that all of the software for it is extremely efficient. Palm is doing everything in their power to make sure that your #2 doesn't happen. The UI is minimalistic (but very functional), the API is 100% designed for low-memory footprint,
and most importantly, you can still run nearly every useful palm application on your Palm III (which is 4+ years old), and most of them on your Palm Pilot Pro (released in '97, not counting upgrades).
As long as you don't drop your PDA on the cement and crack the screen (like I did, which is why I just bought a new m505), there is almost zero incentive to buy a new one, unless you want to go for color. Color, and possibly higher resolution like on the Sony Clie's, is the only upgrade right now that is actually worth it (and that's debatable, because you will always be able to organize your datebook in black and white). MP3 players, like those touted on most PocketPC devices, are just fluff, and so is the ability to write full Word documents (really, who wants to type for 3 hours on that little keyboard).
So for the non-gadget freaks, a $100 m100 will do just fine until probably 5 years from now, and you can get an old Palm III for untold numbers of pennies on Ebay. Hardware saturation may be a reality soon.
Speaking of math jokes, is there a reason why that is question number "3.1.4"? It's a conspiracy...
What I wish for is a tool that constantly downloads changes from all of the other developers' trees and highlights the lines that have changed in whatever file you're working on (but does not merge them), and optionally lets you view the changes. So you can immediately see if someone else has modified code that you want to mess with, and you can call up that person and negotiate a compromise or proper fix. Network bandwidth would be a total hog, but the time saved when you don't have to suddenly discover that someone else broke all of your changes.
Anyone up for the task?
You know, 12 UI changes to be made divided by 6 developers = 2 UI changes per developer. Nice "perfect" load balancing. Never mind that 5 of those 6 now have to learn the structure of the UI system developed by the 6th and not yet documented for public consumption and that the 6th could have implemented all 12 changes himself in the same time as the entire team.
Rock on, dude! Prima donnas (sp?) may suck, but no matter what, 90% of the real coding is done by 10% of the coders. If I were a manager, I would rather "balance" the load by assigning each one or two developers to a specific piece of the system, and have them become experts at it. Then, I'd give all 12 fixes to the UI expert(s), and if he couldn't handle it, let him ask one of the less-busy experts in another area to help out on the changes for which the learning curve isn't too high.
Almost all software projects or mostly-self-contained components start out with one or maybe two people doing all of the initial coding. It takes a lot of work to get it to a point where more people can even start to work on it concurrently.
So if you are starting a project, plan modularly so there are not conflicts between the different "experts". Separate concerns. Also, lessons learned here will help when your project becomes so large or old that no single person knows the entire system.
That's not a problem with designing the code modularly, that's a problem (and a major one) with the company. Besides, with CVS and other similar systems, it isn't even really possible to take out a lock on a file. If your company was too stupid or too lazy to make branches and tags of the code and to learn how to do merges, then any other problems are completely secondary. You will find they all but go away when you learn how to manage the code properly and communicate between departments.
As early as possible in the development stage, we try to identify what will be finished when, and assign a one-up sequence number to each patch. Developers then know that they will be patching against the baseline that was patched by the patch with the previous sequence number. It is hoped that this prevents a lot of rework of patches. A potential problem with this approach is the need for a responsive central authority to assign sequence numbers. Also, such sequence numbers may have to be rearranged in the face of last minute advances and setbacks in developer progress. Despite careful scheduling and detailed design, it may be impossible to know the exact check-in sequence of patches more than a week or two in advance.
When Subversion is ready, you might check it out. It keeps track of not specific versions for files, but revisions/patches for the entire tree. This way you can tell exactly the state of all the code at, say, revision 2735. No manual tagging needed. This would take up a lot of the work of your sequence numbers, without the severe administrative overhead. You could even try to assign a range of actual revisions for which a specific feature is targetted.
I'm already using Subversion for the early stages of one of my projects. It seems to be very stable currently, and of course I still make backups of the DB in case there still remain bugs that would corrupt it. I figure, I won't need to make any branches or merges in this project until well after the time that subversion can support it (due in April).
Are you kidding? If I spin the wheel for a while in IE on Windows (or hold down the down-arrow for that matter), it will take several seconds for the damn screen to catch up, during which time it is completely unresponsive. Personally, I appreciate the fact that Mozilla doesn't try and do "smooth scrolling", because apparantly IE will never get it right.
But in something like AOL, if the engineers have started integrating it, then imagine the cost to restart all of the re-testing, re-integration, and wasted time if they were to back down.
Of course I won't believe it until I see it either...
Not trying to be pedantic, but XML does not allow binary sections. You cannot say "�", for example. The best you can do is encode the data in Base64 or something.
Either way, it can't beat the real thing (always wanted to try one of those).
It's funny, I went skiing this weekend with some friends who are very beginner, and they were talking about trying it out and taking lessons this summer on that conveyer belt. Fortunately, according to Yahoo Yellow Pages at least, it still exists.
I'm pretty sure anyone who is capable of carving (ie., has at least a couple years experience) wouldn't waste their time on this. It sounds like a tool that would be more successful at teaching beginners who are too afraid to actually start moving on real snow, since this thing could be stopped whenever they want.
That brings up an interesting point though: how are you supposed to learn to turn properly if you move at different speeds when you turn left or right? One of the biggest problems I had when learning was that I was better at turning left than right for a long time, and it really hurt me when skiing tougher terrain like moguls and deep snow. Eventually I figured it out, but that's a problem that will have to be resolved before I would send my kids to learn on this.
Heh, I was about to post how the Olympic Sports in Seattle (Northgate) had one of those, but you got it first. I don't know if it's still there, but it was last time I was in that store (probably two years ago). My mom and my sister learned to ski on that conveyer belt before taking to the real slopes.
Have you ever been skiing? If you have, you know that at 100kph, the wind resistance against your upright body can almost knock you flat on your ass. The lower center of gravity does help in turns, I suppose, but the goal is not to spin faster (like a figure skater). In fact, racers often extend their arms while turning to help with balance (while still in a tuck).
If this is the case then the copyrights would revert back to the artists.
:)
But what happens when the industry loses the copyrights? Unfortunately, and I hope this is not the case, artists could lose their corporate backing. All of a sudden, there is nobody around to pay for album production, tours, and promotion. Only the big-time artists could survive in the light of the general public, and we'd still be stuck with two choices: N'Sync and Brittany Spears. It's an interesting situation, and like I said, I *really* hope that doesn't happen
Seems to me like everyone posts these because they know they can get the karma boost, not because they really care about it. They know the editors are bound to use it.
It's a vicious cycle; people post to get the karma, the editors use it because they think lots of people are interested, and then more people post because they know the editors will use it.
At least when I go to bugzilla.mozilla.org and I can actually see the discussions the developers are having on the bug that I want fixed, I feel like something will get done. Even though I know that their resources are limited, so their response time might be a few months for non-critical bugs, at least they know about it.
When I have a bug and call some 3rd-party tech support, and they tell me to reboot my computer and then give up, I don't have those assurances. For all we know, and for all we bitch and moan, Microsoft probably doesn't even *want* to fix many of the bugs in IE, such as those related to standards compliance. I *know* that the Mozilla people care, even if they can't fix everything immediately.
As great as that would be, the first person to write a regular expression engine that can process a petabyte of indexed web-pages in 0.25 seconds should get more than $10,000!
The problem is that search engines use pre-indexed tables of words, probably one table for every word used by any page anywhere. Regular Expressions have to process the raw data, which wouldn't scale worth a dime.
We're only three meals away from revolution
Um... okay... People might be a little scared, but only the stupid ones. I don't know anyone here in the US that is seriously panicking 24/7 because of the 1/1m chance they will be killed by a terrorist. Other countries (Isreal, Palistine) put up with far worse. The only people considering revolution are the Texas gun-totin' militia hate groups.
Have you seen the m505 or IIIc handhelds? Palm has had color for a while. Also, PalmOS still runs the vast majority of handhelds. The reason Palm has lost market share is because, in addition to saturation (which doesn't account for 44% but is definitely real), other PalmOS handhelds like Handspring, Sony, and Handera are kicking ass by supporting higher resolution screens and MP3 players. Palm's hardware sales might be down, which is why they recently split off the PalmOS group as a separate company. PalmOS isn't going anywhere.
Personally I tend to believe that it's the tech support that's stupid, and they don't even know enough to tell whether it's the stupid customer or themselves. During the recent Excite -> AT&T fiasco, my connection was a week slower to come back up than the rest of my city, and you should have heard the bullshit that came out of their mouths.
:)
Let's put it this way: I will never ever waste my time with AT&T's "live Internet chat" customer support again. It may be "live", but only so much as you can call somebody hitting C-x, C-v over and over again "live"
At least I got double credits for my downtime, so I guess they learned their lesson in that respect. That was half a month free for me!
I Am Not A Carbon Nanotube Scientist, but I think that the tubes strength comes when they are streched (tension), but not necessarily when there are other forces. So it might be pretty easy to snip the tubes when cut from the side.
Exactly... you can engineer a distributed system that is more reliable than even the best single-unit system (in the low-to-mid-range market, at least). The price is far cheaper to start with, and you have to go through several replacements before your hardware costs approach the cost of the single system (by which time you would have had to do replacements in the single system as well, increasing its cost... and so on).
If your company wants a mainframe that costs $1m or more, then there isn't really any commodity alternative. But for low-to-mid-range solutions, so long as you have an in-house tech team capable of living without paying for Sun's support, it's a tough call.
This has to be a troll or flaimbait, because that is just plain not true. The only problems Java has running cross-platform are certainly not related to binary or bytecode, they are if you use native libraries or don't do your file-system access correctly.
Just use GCC (PRC-tools, with Pilrc), Emacs, and the SDK which you can download in 4 clicks (see comment above). POSE is also awesome; the only thing you might have trouble with is getting Debug ROMs (but if you are in the USA, you can register and get them within 36 hours like I did a few weeks ago). And the SDK documentation is among the best available of any platform.
Part of the reason why this doesn't happen, unfortunately, is that the software developers and programmers continue to 1) push existing processing performance capabilities, and/or 2) write ineficient code. In my experience, it's been a combination of those two, with the stress on 2).
One of the great things about Palm (and one of the things that might indeed make hardware saturation a reality) is that all of the software for it is extremely efficient. Palm is doing everything in their power to make sure that your #2 doesn't happen. The UI is minimalistic (but very functional), the API is 100% designed for low-memory footprint,
and most importantly, you can still run nearly every useful palm application on your Palm III (which is 4+ years old), and most of them on your Palm Pilot Pro (released in '97, not counting upgrades).
As long as you don't drop your PDA on the cement and crack the screen (like I did, which is why I just bought a new m505), there is almost zero incentive to buy a new one, unless you want to go for color. Color, and possibly higher resolution like on the Sony Clie's, is the only upgrade right now that is actually worth it (and that's debatable, because you will always be able to organize your datebook in black and white). MP3 players, like those touted on most PocketPC devices, are just fluff, and so is the ability to write full Word documents (really, who wants to type for 3 hours on that little keyboard).
So for the non-gadget freaks, a $100 m100 will do just fine until probably 5 years from now, and you can get an old Palm III for untold numbers of pennies on Ebay. Hardware saturation may be a reality soon.