I really don't see what I'm advocating as anything groundbreaking at all. It sounds like cabbage's company is trying to shoehorn a consulting business into a traditional product-based business without breaking either business. I just don't see that happening without a lot of pain.
I'm sure they've already got a few developers who trek out to customer sites to implement their current product. Why don't they simply build a team around these engineers and label them the "Product Integration" team. It would free them up from having to develop the product and let them focus on customer issues. Not only would this allow for quite a bit of specialization within the company, it would allow both divisions to grow independently of each other making it possible for the company to branch out into other profitable markets.
The benefits of having the separate teams is pretty clear. Better customer service, more forward-looking ideas, and more expertise among the engineers of each division are only a few of the ones that pop into my head straight away.
I'm sure there are a few engineers who are already interested in doing something besides crunching code all day long. Grab 10 or so of them and make them the Integration team. As these guys get better, the quality of their work and their implementation schedules will improve immensely.
If, as it sounds to me, they've already got a solution developed and are merely updating and bug-fixing it as their main development effort, wouldn't it be saner to keep those existing developers at home and simply create the dreaded "new department"?
It sounds as if they are thinking of moving into the area of on-site support and integration while keeping the development effort going. It makes sense (to me) to have specialists in the code, and specialists in integration. Both departments can play off one another and improve the quality of the software as a byproduct of their interaction.
Also, having people in the field who are solely focused on solving immediate customer problems will gain quite a bit of insight into future products that might be profitable for the company to develop.
As I said, I think your memory's fuzzy. But then, I've never been that big a fan of fantasy. But even disregarding that, where was the fun? The whole thing was too dark, too long, and the only interesting things were the audience members who were freezing their collective asses off waiting for the doors to open because they thought dressing up as hobbits and elves would be a good idea. Harumph.
Save your money. The acting was mediocre and the sound was shitty. The effects were about the only saving grace for this flick, but it wasn't anywhere near the quality of Monsters Inc. or even Shrek. The story was pretty lame, as well. I guess everyone's memory has been fuzzied enough that this kind of non-story has become a classic.
Bottom line: If you liked Final Fantasy, you'll like this dreck. All flash, no substance. Wait for Blackhawk Down.
Dancin Santa
Re:Don't judge Perl based on the article
on
Happy Birthday Perl!
·
· Score: 2, Informative
I think you're looking for the Inline module for Perl.
Perl is really the reason I stay with programming. Trained in Cobol, Pascal, C, and C++, I thought that coding was an adventure like delving into the depths of Mayan pyramids - difficult and yet rewarding. There's only so much grinding one can take, though, and I was at the point of giving it all up to focus all my time on engineering new toys for all the boys and girls.
Then I found Perl. Built-in data structures, a text-parsing mechanism that's second to none, and a community that's more interesting than a barrel of camels. Programming in Perl is like painting, it's fun, engaging, and every bit of creativity that rolls from the tips of your fingers is reflected in the code.
Besides, I've had the opportunity to have lunch with Randal, and he was much more interesting than Bjarne (who couldn't be bothered, but I'm sure is a nice guy).
I'm not sure solution A would work out. MS claims it already documents all Win32 APIs on MSDN and even under such a remedy any APIs that they kept secret could simply be explained away as internal OS functions that are not meant to be used by developers.
Solution B is a good step, but it doesn't do anything to remedy or prevent Microsoft's abuse of monopoly power. Their monopoly doesn't come from their (ab)use of copyright, but from their ability to restrict OEMs from installing non-MS operating systems and software on their hardware.
I'm not usually one who sides against Microsoft or roots for the government in this case, but the solution was completely useless and didn't do anything to remedy the actual problem that exists in the Windows space.
A good solution would be to restrict Microsoft in those actions that they were using to crush competitors: exclusive and restrictive contracts with hardware manufacturers. Restricting MS from entering into these contracts would be a simple and effective method of freeing up the market place for other operating systems and bundled software. It would effectively eliminate their monopoly leverage point without taking away their de facto monopoly.
Microsoft wouldn't need to release their business plans 5 years into the future, and they would be encouraged to keep their software current in order to remain competitive with other products that could possibly be bundled by OEMs.
Though your arguments are clear and correct, there still remain islands (pun intended) of 'bad' sweatshop labor.
Take the case of the clothing factories in the CNMI (makers of fine Polo, Liz Claiborne, J. Crew, and Banana Republic clothes, among others). Chinese laborers are lured into the labor by the promise of American dollars and a better life, but their 'saviors' charge them usuriously high rates to transport them from their home country. They then get to work off their debt by working in the factories. However, they likely have no place to stay so they live in the company barracks which also charges rent, leaving the workers penniless and unable to improve their lot.
This is not a bash of those clothiers named above, most have actually pulled their manufacturing out of Saipan. However, when discussing sweatshops, it must be made clear to the companies taking advantage of cheap overseas labor that it is unacceptable to allow such abuses of the system to occur.
The licensee shall notify the Creator of this program with any changes and shall make available to the Creator such changes at the licensee's expense in the event the licensee releases this product in a modified form.
Ah, but the Registry only keeps a one to one mapping of file types to applications. A good system would be to have an API called AppSupportsFileType(const TCHAR* szFileExt) which would then add the file extension to the Registry if it didn't already exist and add the application information to a "Supported by" list.
Then you'd only have to check the registry for the specific filetype you're looking for to get a list of apps that at least admit to supporting a certain filetype.
Elements of Programming with Perl was a big hit over at CLPM when it came out. It doesn't assume the programmer has any programming experience coming in. It is clear, concise, and aimed directly at the market you're interested in.
Slashdot Mirror
I really don't see what I'm advocating as anything groundbreaking at all. It sounds like cabbage's company is trying to shoehorn a consulting business into a traditional product-based business without breaking either business. I just don't see that happening without a lot of pain.
I'm sure they've already got a few developers who trek out to customer sites to implement their current product. Why don't they simply build a team around these engineers and label them the "Product Integration" team. It would free them up from having to develop the product and let them focus on customer issues. Not only would this allow for quite a bit of specialization within the company, it would allow both divisions to grow independently of each other making it possible for the company to branch out into other profitable markets.
The benefits of having the separate teams is pretty clear. Better customer service, more forward-looking ideas, and more expertise among the engineers of each division are only a few of the ones that pop into my head straight away.
I'm sure there are a few engineers who are already interested in doing something besides crunching code all day long. Grab 10 or so of them and make them the Integration team. As these guys get better, the quality of their work and their implementation schedules will improve immensely.
IMHO, of course.
Dancin Santa
If this pans out, you won't have to worry about the price. You can simply grow arms and legs as necessary. :-)
Dancin Santa
If, as it sounds to me, they've already got a solution developed and are merely updating and bug-fixing it as their main development effort, wouldn't it be saner to keep those existing developers at home and simply create the dreaded "new department"?
It sounds as if they are thinking of moving into the area of on-site support and integration while keeping the development effort going. It makes sense (to me) to have specialists in the code, and specialists in integration. Both departments can play off one another and improve the quality of the software as a byproduct of their interaction.
Also, having people in the field who are solely focused on solving immediate customer problems will gain quite a bit of insight into future products that might be profitable for the company to develop.
JMHO,
Dancin Santa
You didn't believe in me?
Dancin Santa
More Chicken Run!
Maybe some claymation Dancing Santas in a cameo?
Dancin Santa
And if you don't know what to do with the hardware after you've bought it, please send it to me.
Thank you,
Dancin Santa
Harry Potter is known around the world and has even had a movie done about the characters.
Martin and Sawyer's fans are few and far between. (Though no less avid and quite a bit more thoughtful.)
Dancin Santa
Actually, it really helps me when people put these things up. I use them as navpoints.
Dancin Santa
What's also sad is that the other three posts are mine. One modded up, one modded down, and this one modded just right.
Dancin Santa
No, I'm pretty sure it's the trademark issue.
Dancin Santa
As I said, I think your memory's fuzzy. But then, I've never been that big a fan of fantasy. But even disregarding that, where was the fun? The whole thing was too dark, too long, and the only interesting things were the audience members who were freezing their collective asses off waiting for the doors to open because they thought dressing up as hobbits and elves would be a good idea. Harumph.
Personally, I'm waiting to see Ali.
Dancin Santa
Save your money. The acting was mediocre and the sound was shitty. The effects were about the only saving grace for this flick, but it wasn't anywhere near the quality of Monsters Inc. or even Shrek. The story was pretty lame, as well. I guess everyone's memory has been fuzzied enough that this kind of non-story has become a classic.
Bottom line: If you liked Final Fantasy, you'll like this dreck. All flash, no substance. Wait for Blackhawk Down.
Dancin Santa
I think you're looking for the Inline module for Perl.
Dancin Santa
Perl is really the reason I stay with programming. Trained in Cobol, Pascal, C, and C++, I thought that coding was an adventure like delving into the depths of Mayan pyramids - difficult and yet rewarding. There's only so much grinding one can take, though, and I was at the point of giving it all up to focus all my time on engineering new toys for all the boys and girls.
Then I found Perl. Built-in data structures, a text-parsing mechanism that's second to none, and a community that's more interesting than a barrel of camels. Programming in Perl is like painting, it's fun, engaging, and every bit of creativity that rolls from the tips of your fingers is reflected in the code.
Besides, I've had the opportunity to have lunch with Randal, and he was much more interesting than Bjarne (who couldn't be bothered, but I'm sure is a nice guy).
No coal for you this year, Larry.
Dancin Santa
I could have been the next Damian or Dan had I just stuck with Perl for a couple more years.
Lost opportunities... *sigh*
Dancin Santa
You haven't been nice, according to my list.
Coal for you this year.
Dancin Santa
I'm not sure solution A would work out. MS claims it already documents all Win32 APIs on MSDN and even under such a remedy any APIs that they kept secret could simply be explained away as internal OS functions that are not meant to be used by developers.
Solution B is a good step, but it doesn't do anything to remedy or prevent Microsoft's abuse of monopoly power. Their monopoly doesn't come from their (ab)use of copyright, but from their ability to restrict OEMs from installing non-MS operating systems and software on their hardware.
Dancin Santa
I'm not usually one who sides against Microsoft or roots for the government in this case, but the solution was completely useless and didn't do anything to remedy the actual problem that exists in the Windows space.
A good solution would be to restrict Microsoft in those actions that they were using to crush competitors: exclusive and restrictive contracts with hardware manufacturers. Restricting MS from entering into these contracts would be a simple and effective method of freeing up the market place for other operating systems and bundled software. It would effectively eliminate their monopoly leverage point without taking away their de facto monopoly.
Microsoft wouldn't need to release their business plans 5 years into the future, and they would be encouraged to keep their software current in order to remain competitive with other products that could possibly be bundled by OEMs.
Dancin Santa
We've got 'em. They're called "hands".
Dancin Santa
Though your arguments are clear and correct, there still remain islands (pun intended) of 'bad' sweatshop labor.
Take the case of the clothing factories in the CNMI (makers of fine Polo, Liz Claiborne, J. Crew, and Banana Republic clothes, among others). Chinese laborers are lured into the labor by the promise of American dollars and a better life, but their 'saviors' charge them usuriously high rates to transport them from their home country. They then get to work off their debt by working in the factories. However, they likely have no place to stay so they live in the company barracks which also charges rent, leaving the workers penniless and unable to improve their lot.
This is not a bash of those clothiers named above, most have actually pulled their manufacturing out of Saipan. However, when discussing sweatshops, it must be made clear to the companies taking advantage of cheap overseas labor that it is unacceptable to allow such abuses of the system to occur.
The licensee shall notify the Creator of this program with any changes and shall make available to the Creator such changes at the licensee's expense in the event the licensee releases this product in a modified form.
But isn't that just more handcuffs?
Dancin Santa
Heh. How about that!
A cursory glance at the Registry doesn't reveal anything besides the Default registered app. I wonder how it's done.
Dancin Santa
Ah, but the Registry only keeps a one to one mapping of file types to applications. A good system would be to have an API called AppSupportsFileType(const TCHAR* szFileExt) which would then add the file extension to the Registry if it didn't already exist and add the application information to a "Supported by" list.
Then you'd only have to check the registry for the specific filetype you're looking for to get a list of apps that at least admit to supporting a certain filetype.
Dancin Santa
Elements of Programming with Perl was a big hit over at CLPM when it came out. It doesn't assume the programmer has any programming experience coming in. It is clear, concise, and aimed directly at the market you're interested in.
Dancin Santa
The first physical test of whether or not Hawking radiation really takes place would be observing mini black holes made in an accelerator...
What would be unfortunate would be that being the last test.
It would be nice if Nature came equipped with signs like: Proceed with caution!
Dancin Santa