Why not try beating the sh** outta it? I'm sure that'd make it cough out enough blood for you to reconnect its vitals long enough to access "My Documents":-)
I have been a proponent of unit testing, facing a lot of flak from the team members, project managers, etc for the added time in the development cycle. Over time, following are the observations that I've made about unit testing:
#1. Don't test the obvious - enthusiastic new developers (or naive old developers) tend to write miniscule tests (like testing the accessor methods of a class), which are equivalent to testing the compiler. Avoid them at all costs!
#2. Test for the obvious - if you wrote a method that expects a number and uses it to divide something else, don't write tests to catch divide by zero, not a number exception, etc. Test the boundary conditions of your unit and what it is expected to do!
#3. Remember you are testing the program unit - dont let loose your imagination and spend time thinking of new ways to break your code. Leave that for the testing stage.
#4. And finally update the tests along with the code - its tedious, we all hate it, but someone else wouldnt have to dig through your code to find out what was the change you did that broke the framework!
Having been on both sides of outsourcing (working in India on jobs that were outsourced and then having worked "onshore" on "onsite" as a permanent employee with software organizations), AND being a one-time failed business owner who tried to work his way around outsourcing, here are few things I would like to mention:
Outsourcing revolves solely around money. Any organization in the west, relies on outsourcing only as a means of reducing cost. This viewpoint may attract a lot of flak, but thats the bottomline.
Having outsourced, or wooing the employeers/stakeholders about outsourcing, the management then espouses other "benefits" - the large english speaking skill pool, low cost, high degree of enthusiasm, deep processes, etc.
Once outsourced, the problems begin to crop up:
They don't understand the overall picture. Most times they are not even bothered about the overall picture.
"Isolated" skills - Once you find the programmers/team members of your choice (and I must say, its a tedious process getting your choice from the "large pool"), you realize they don't know anything beyond their programming language/platform
Non-existent design skills - as pointed by someone else, either the design skills don't exist or they try to get around by re-using/adapting stuff available by few searches on google.
Unrealistic estimates - I have yet to come across a single venture where outsourced business units managed to meet the committed deadlines. Sure things go wrong, but hey, whatever did happen to keeping adequate buffers and/or checks and balances to inform what's going wrong or went wrong?
Tedious process - I love the detailed documents they keep and maintain regularly. I love the weekly reports I got. But the entire process is so blooming disjointed, one has to trudge through a heap of documents before tracing anything.
Last minute reporting - Heaven forbid if you have your timelines dependent on release (say, a roadshow/conference). Everything will be "on schedule" till last week, when suddenly you'll find 40% of stuff is buggy, another 15% incomplete!
Now from their perspective:
Hungry for projects - No matter what anyone says, getting a project is not easy. There's fierce competition driving down prices and they go to any extent to get the project. Which is good in a sense, but this also leads to classical overcommitting.
Customer apathy - most times, the customers simply want a piece of work done. Attempts to become a part of the process, or relate to the process/project are usually ignored, or declined politely.This apathy finally results in being concerned with just delivering.
Cultural and other differences: The client being the prime stakeholder, knows exactly what he/she wants. However, no matter how deep and detailed the requirements documents are, it is very difficult to convey the need. A true match is reached only by following an iterative process, which, funnily, most customers are averse to doing in an outsourcing model (no matter if they used to follow that in house)!
Customers concerned with just delivery - I've been witness to several customers who, after outsourcing, believe the unwanted baby is no longer their problem. Let the outsourced company handle it - we just want the end result. Hordes of emails asking more information, help, advice, comment are ignored, or delayed. While the outsourced team is waiting for a response, the clock keeps ticking and the deadlines keep looming. Caught between a rock and a hard place, they implement whatever they know, however they know.
IT skills and courses may teach you a certain skill, but they don't imbibe in you the principles that make a good design. Its something to learn yourself, or pick up from analyzing, evaluating other designs. Which takes time. But sadly, the best pool of p
Having been on both sides of outsourcing (working in India on jobs that were outsourced and then having worked "onshore" on "onsite" as a permanent employee with software organizations), AND being a one-time failed business owner who tried to work his way around outsourcing, here are few things I would like to mention:
1. Outsourcing revolves solely around money. Any organization in the west, relies on outsourcing only as a means of reducing cost. This viewpoint may attract a lot of flak, but thats the bottomline.
2. Having outsourced, or wooing the employeers/stakeholders about outsourcing, the management then espouses other "benefits" - the large english speaking skill pool, low cost, high degree of enthusiasm, deep processes, etc.
3. Once outsourced, the problems begin to crop up:
+ They don't understand the overall picture. Most times they are not even bothered about the overall picture.
+ "Isolated" skills - Once you find the programmers/team members of your choice (and I must say, its a tedious process getting your choice from the "large pool"), you realize they don't know anything beyond their programming language/platform
+ Non-existent design skills - as pointed by someone else, either the design skills don't exist or they try to get around by re-using/adapting stuff available by few searches on google.
+ Unrealistic estimates - I have yet to come across a single venture where outsourced business units managed to meet the committed deadlines. Sure things go wrong, but hey, whatever did happen to keeping adequate buffers and/or checks and balances to inform what's going wrong or went wrong?
+ Tedious process - I love the detailed documents they keep and maintain regularly. I love the weekly reports I got. But the entire process is so blooming disjointed, one has to trudge through a heap of documents before tracing anything.
+ Last minute reporting - Heaven forbid if you have your timelines dependent on release (say, a roadshow/conference). Everything will be "on schedule" till last week, when suddenly you'll find 40% of stuff is buggy, another 15% incomplete
Now from their perspective:
+ Hungry for projects - No matter what anyone says, getting a project is not easy. There's fierce competition driving down prices and they go to any extent to get the project. Which is good in a sense, but this also leads to classical overcommitting.
+ Customer apathy - most times, the customers simply want a piece of work done. Attempts to become a part of the process, or relate to the process/project are usually ignored, or declined politely.This apathy finally results in being concerned with just delivering.
+ Cultural and other differences: The client being the prime stakeholder, knows exactly what he/she wants. However, no matter how deep and detailed the requirements documents are, it is very difficult to convey the need. A true match is reached only by following an iterative process, which, funnily, most customers are averse to doing in an outsourcing model (no matter if they used to follow that in house)!
+ Customers concerned with just delivery - I've been witness to several customers who, after outsourcing, believe the unwanted baby is no longer their problem. Let the outsourced company handle it - we just want the end result. Hordes of emails asking more information, help, advice, comment are ignored, or delayed. While the outsourced team is waiting for a response, the clock keeps ticking and the deadlines keep looming. Caught between a rock and a hard place, they implement whatever they know, however they know.
+ IT skills and courses may teach you a certain skill, but they don't imbibe in you the principles that make a good design. Its something to learn yourself, or pick up from analyzing, evaluating other designs. Which takes time. But sadly, the best pool of programmers with such skills chooses to migrate to greener pasters (read USA). Besides, most customers in outsourcing, still have the labour market perspective - define the job yourself, let the outsourced chaps complete it.
While the economics will kee
Here's the bit I loved about the new page:)
Google giveth
and Google taketh away
Blessed is Google?
hahaha! that question mark at the end just cracked me up:)
First it was Robert Kilroy for his ill-informed remarks about the Arab nations, then the head honcho Dyke himself.. wonder if this will lead to another string of resignations beginning from this Evans chap himself?..
Why blame outsourcing for losing jobs, when you simply be an ill-informed moron and dig your own grave?
I read the news item (and some of the comments here), but am still trying to figure out what the news item was trying to convey.
Not a single figure or fact had been established (quote "No one knows how much misspelling is out there in eBay land..", "unofficial survey turned up dozens of items). It further trolls on completely unresearched bits like "Some experts say there is no evidence that people are spelling worse than they ever did".
I think the news item is another shining example of eager "news" reporting, or meeting a deadline (gee whiz! I have to submit 1000 words today again!).
Wans't tehere an emial diong ruonds soemtmie ago, taht metnoined taht huamns colud undrestand a mis-spleled wrod so lnog as the frist and lsat letetrs reamined the smae?
yes, definitely outsourcing is the solution. there are several large corporations that have outsourced their business processes (claims, medical transcription, etc) to india, where they have trained professionals who do it for you.
these professionals are equipped with all the equipment aka the foot pedal, etc, and have been "trained" to understand the accent, etc. they further have references and journals to look up a term if they are not familiar with it. on top of it all, there are several quality checks they go through before sending you the transcript.
and the cost? these ppl are paid about $2/hour (maybe even less)..some of them charge per line, though i can't recall the cost..
Makes sense.. unfortunatly i'm stuck in the office doing overtime (crappy release dates as usual). Will dig this when I go home.. but all I need right now is beer ummmmm!!!
I wonder why the rippers that I use have a problem in track separation then. I will implement something of my own this weekend and post an update later
Its interesting that you mention that track separation is also assisted by the media player requesting the metadata for a new track. I did notice winamp changing the track title a few seconds before the actual track started. May this happens because of cross-fading?
Well, the radio stations that I listen to, apparently the meta-data comes BEFORE the song actually starts, even though they have a fairly large number of listeners...
Still, thanks anyway. I need to examine the protocol more closely this weekend
Yes I did think of doing that - but dont you think that makes the whole process more tedious - not only would I have to keep track of the sequence in which the tracks are downloaded (and to the best of my knowledge none of the rippers keep a sequence).
I dont mind paying for tracks, but as I have had this discussion in the past with several othere ppl (especially related to those RIAA lawsuits), but dont you think the recording industry makes you pay for the whole album when only a single track is what you want to listen to? Anyway, I think this line of discussion would open a whole new can of worms.
I definitely agree there has to be SOMETHING that identifies track separation.
As you said, you look for an inconsistency in the flow of sound, and given that these rippers do detect some inconsistency based upon which they determine track separation, which means this inconsistency is either not good enough, or there is no inconsistency at all, since they terminate the track at the wrong place.
I wish I had the knowledge of how to identify this track separation, but I don't - which is why I posted this here:)
Slashdot Mirror
Why not try beating the sh** outta it? I'm sure that'd make it cough out enough blood for you to reconnect its vitals long enough to access "My Documents" :-)
I have been a proponent of unit testing, facing a lot of flak from the team members, project managers, etc for the added time in the development cycle. Over time, following are the observations that I've made about unit testing:
#1. Don't test the obvious - enthusiastic new developers (or naive old developers) tend to write miniscule tests (like testing the accessor methods of a class), which are equivalent to testing the compiler. Avoid them at all costs!
#2. Test for the obvious - if you wrote a method that expects a number and uses it to divide something else, don't write tests to catch divide by zero, not a number exception, etc. Test the boundary conditions of your unit and what it is expected to do!
#3. Remember you are testing the program unit - dont let loose your imagination and spend time thinking of new ways to break your code. Leave that for the testing stage.
#4. And finally update the tests along with the code - its tedious, we all hate it, but someone else wouldnt have to dig through your code to find out what was the change you did that broke the framework!
Having been on both sides of outsourcing (working in India on jobs that were outsourced and then having worked "onshore" on "onsite" as a permanent employee with software organizations), AND being a one-time failed business owner who tried to work his way around outsourcing, here are few things I would like to mention:
Now from their perspective:
Having been on both sides of outsourcing (working in India on jobs that were outsourced and then having worked "onshore" on "onsite" as a permanent employee with software organizations), AND being a one-time failed business owner who tried to work his way around outsourcing, here are few things I would like to mention: 1. Outsourcing revolves solely around money. Any organization in the west, relies on outsourcing only as a means of reducing cost. This viewpoint may attract a lot of flak, but thats the bottomline. 2. Having outsourced, or wooing the employeers/stakeholders about outsourcing, the management then espouses other "benefits" - the large english speaking skill pool, low cost, high degree of enthusiasm, deep processes, etc. 3. Once outsourced, the problems begin to crop up: + They don't understand the overall picture. Most times they are not even bothered about the overall picture. + "Isolated" skills - Once you find the programmers/team members of your choice (and I must say, its a tedious process getting your choice from the "large pool"), you realize they don't know anything beyond their programming language/platform + Non-existent design skills - as pointed by someone else, either the design skills don't exist or they try to get around by re-using/adapting stuff available by few searches on google. + Unrealistic estimates - I have yet to come across a single venture where outsourced business units managed to meet the committed deadlines. Sure things go wrong, but hey, whatever did happen to keeping adequate buffers and/or checks and balances to inform what's going wrong or went wrong? + Tedious process - I love the detailed documents they keep and maintain regularly. I love the weekly reports I got. But the entire process is so blooming disjointed, one has to trudge through a heap of documents before tracing anything. + Last minute reporting - Heaven forbid if you have your timelines dependent on release (say, a roadshow/conference). Everything will be "on schedule" till last week, when suddenly you'll find 40% of stuff is buggy, another 15% incomplete Now from their perspective: + Hungry for projects - No matter what anyone says, getting a project is not easy. There's fierce competition driving down prices and they go to any extent to get the project. Which is good in a sense, but this also leads to classical overcommitting. + Customer apathy - most times, the customers simply want a piece of work done. Attempts to become a part of the process, or relate to the process/project are usually ignored, or declined politely.This apathy finally results in being concerned with just delivering. + Cultural and other differences: The client being the prime stakeholder, knows exactly what he/she wants. However, no matter how deep and detailed the requirements documents are, it is very difficult to convey the need. A true match is reached only by following an iterative process, which, funnily, most customers are averse to doing in an outsourcing model (no matter if they used to follow that in house)! + Customers concerned with just delivery - I've been witness to several customers who, after outsourcing, believe the unwanted baby is no longer their problem. Let the outsourced company handle it - we just want the end result. Hordes of emails asking more information, help, advice, comment are ignored, or delayed. While the outsourced team is waiting for a response, the clock keeps ticking and the deadlines keep looming. Caught between a rock and a hard place, they implement whatever they know, however they know. + IT skills and courses may teach you a certain skill, but they don't imbibe in you the principles that make a good design. Its something to learn yourself, or pick up from analyzing, evaluating other designs. Which takes time. But sadly, the best pool of programmers with such skills chooses to migrate to greener pasters (read USA). Besides, most customers in outsourcing, still have the labour market perspective - define the job yourself, let the outsourced chaps complete it. While the economics will kee
Here's the bit I loved about the new page :)
Google giveth
and Google taketh away
Blessed is Google?
hahaha! that question mark at the end just cracked me up :)
First it was Robert Kilroy for his ill-informed remarks about the Arab nations, then the head honcho Dyke himself.. wonder if this will lead to another string of resignations beginning from this Evans chap himself?.. Why blame outsourcing for losing jobs, when you simply be an ill-informed moron and dig your own grave?
damn, i shouldn't even dare participating then... guess the yet-to-be-born further /. 'ers would scowl at me :-s
I read the news item (and some of the comments here), but am still trying to figure out what the news item was trying to convey.
Not a single figure or fact had been established (quote "No one knows how much misspelling is out there in eBay land..", "unofficial survey turned up dozens of items). It further trolls on completely unresearched bits like "Some experts say there is no evidence that people are spelling worse than they ever did".
I think the news item is another shining example of eager "news" reporting, or meeting a deadline (gee whiz! I have to submit 1000 words today again!).
Wans't tehere an emial diong ruonds soemtmie ago, taht metnoined taht huamns colud undrestand a mis-spleled wrod so lnog as the frist and lsat letetrs reamined the smae?
yes, definitely outsourcing is the solution. there are several large corporations that have outsourced their business processes (claims, medical transcription, etc) to india, where they have trained professionals who do it for you.
these professionals are equipped with all the equipment aka the foot pedal, etc, and have been "trained" to understand the accent, etc. they further have references and journals to look up a term if they are not familiar with it. on top of it all, there are several quality checks they go through before sending you the transcript.
and the cost? these ppl are paid about $2/hour (maybe even less)..some of them charge per line, though i can't recall the cost..
Makes sense.. unfortunatly i'm stuck in the office doing overtime (crappy release dates as usual). Will dig this when I go home.. but all I need right now is beer ummmmm!!!
Thanks for the info
I wonder why the rippers that I use have a problem in track separation then. I will implement something of my own this weekend and post an update later
Cheers
Thanks for your reply
Its interesting that you mention that track separation is also assisted by the media player requesting the metadata for a new track. I did notice winamp changing the track title a few seconds before the actual track started. May this happens because of cross-fading?
Well, the radio stations that I listen to, apparently the meta-data comes BEFORE the song actually starts, even though they have a fairly large number of listeners...
Still, thanks anyway. I need to examine the protocol more closely this weekend
Yes I did think of doing that - but dont you think that makes the whole process more tedious - not only would I have to keep track of the sequence in which the tracks are downloaded (and to the best of my knowledge none of the rippers keep a sequence).
I dont mind paying for tracks, but as I have had this discussion in the past with several othere ppl (especially related to those RIAA lawsuits), but dont you think the recording industry makes you pay for the whole album when only a single track is what you want to listen to? Anyway, I think this line of discussion would open a whole new can of worms.
I definitely agree there has to be SOMETHING that identifies track separation. As you said, you look for an inconsistency in the flow of sound, and given that these rippers do detect some inconsistency based upon which they determine track separation, which means this inconsistency is either not good enough, or there is no inconsistency at all, since they terminate the track at the wrong place. I wish I had the knowledge of how to identify this track separation, but I don't - which is why I posted this here :)