I admit it. I'm an iPod fan-boy. And as such I've been in the Apple store shortly after releases of iPods quite a few times and the demand for the newly released iPods are just insane. If they can speed up that process then that's good for both the customer and the store.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
A single CPU machine without hyperthreading would be an example.
I'm wondering if you actually are talking about software in your question. And while the application server most certainly will be multithreaded your web request will most likely execute in one thread from the time the request is made until you send the response. Unless you create a second thread yourself.
But I shouldn't have said: "This is a benefit for single threaded hardware". I should have said: This is a benefit you get _even_ on single threaded hardware.
And the benefit I'm talking about is that the cleanup can take place after the response has been sent.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
off topic, but do you know that gruntled actually isn't the opposite of disgruntled? The dis is part of the word and not a prefix. I still appreciate your sig, I just thought that you might be interested to know.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
For a single threaded piece of work on a computer with SMP, hyperthreading or dual core... Umm, yes, it does.
Also, consider a call to a web servie. With C++ the destructors for any objects you allocate has to be executed before the webservice can return. For Java the webservice can return before the objects are destroyed. So they will be able to do some of the work after the web service has responded to the client. This is a benefit for single threaded hardware.
I love the requirements they list (especially note the last one):
* Windows XP with Service Pack 1 installed or Windows 2000 with Service Pack 3 installed, or newer, or Mac OS X 10.3 or newer.
* A connection to the Internet.
* 512 megabytes of RAM is recommended.
* Lots of spare time.
While Pricerite seems to be grade A jerks it is immature to try to DOS their website.
Complaints should go through normal channels. A few comments up there was a guy with the opposite perspective. He had an online store and was blown out of the water by a "conspiracy" that likely was due to the competition not liking him. He seemed like a nice guy.
So, what guarantee do you have that Pricerite aren't good guys and all the testimonials you have read are fictious? You would only need maybe 10 fictitious online identities to achieve this.
I think Pricerite probably deserve getting shafted. But not this way!
I'm so tired of people who say to _never_ use gotos. I understand why professors are saying this. The average computer science student often will use it in the wrong way. On average a class of computer science students will produce better code if they are told to never use gotos. But that doesn't mean that it never is good, only that the average programmer is a moron.
Not using goto's are one of those mantras that was coined by someone who hadn't thought things through, that got popular and were taught to students without critical thinking by professors with no real life experience.
I rarely use gotos (unless I'm coding in a language that doesn't support exceptions in which case it is a central part to how I centralize the cleaning up my stuff before returning an error code from my function) but I would be really pissed if it wasn't available when I really need it.
I don't know if I'm misreading your post and maybe I'd read something different into it if I was working at your company. But I react to two things:
1) I followed the link to your companies web site and you speak of your amazing support team, yet, in your/. post you say that you pay low salaries and you don't expect gurus. So the "amazing" support team is a marketing term. This is fine. Except, don't write about it in a public forum.
2) With the reasoning in item 1) it seems as if you are stabbing your existing employees in the back. You are saying that they aren't very good.
Now, I realise that I might have misunderstood your post and if that is the case then please set me straight. But even if I did, I'm thinking others might also have misunderstood.
I don't disagree with using stored procedures. Or even putting business logic in them if it either makes something a whole lot simpler, or if it is more efficient (and the optimization is needed).
I'm an OO guy. I am also a database guy. But I'm a zealot of neither. I worship correctness, robustness, simplicity and 'fast enough'.
Zealots of either side tend to come up with rules that categorically puts some type of code inside or outside the database. Their rules are right most of the time, but there are often exceptions.
The pragmatic programmer is always right though (conceptually speaking).
I love it when someone comes up to me and says that gotos shouldn't be allowed. These are typically spoon fed students who forgot to think on their own. Because I can show them that there are cases where gotos makes things simpler or faster. Gotos are often bad, but not always. To paraphrase the NRA wackos, gotos don't write bad code, people do.
I believe this is true for any SQL statement in.net. Not just stored procedures. ODBC supports arrays as input parameters, so the problem isn't in SQL Server. I think the problem is that ADO.net doesn't support it. One would presume that they will sooner or later. Who know's they might even support it with the version that was released today? I don't really know.
It is pretty easy to scale most things in a big n-tier system. Just buy more servers. The database however is really hard to scale. You quickly get to a point where twice the money will buy you only very little extra performance.
Therefore I treat the database as the "sacred resource". This almost always means that business logic is kept outside the database.
Your approach was right in the 80's when client/server was the norm. Today you should have an n-tier system and have the business logic in an application server.
You can still have lots of different applications while using centralized code. Only, now you call the application server instead of the database.
However, I've met a few people who have bought Macs just because they look cool, fit in with their Ikea furniture, and are trendy.
Part of that coolness and trendyness, I think, isn't just the look of the machines. It is because "coolness" is spilling over from the iPod to the entire Apple brand. It has also helped tremendeously with the brand awareness.
A bad manager, using either your system or mine, would still be a bad manager. And a good manager, using either your system or my system would likely still be a good manager.
Assuming that both you and I are good managers we would likely be good managers with either method, but probably a bit better with our "own" method. It also depends on the type of work the team is doing and the personalities in the team.
Putting it shortly, the manager and his/her basic properties are more important than the method.
Downloading from one dedicated single source, like it is now, is _less_ reliable than a swarm with one dedicated seed that takes the place of the current dedicated single source.
The swarm can deal with every single seed going off line, as long as the dedicated seed stays up. This is equivalent to the current single point download.
But in addition to this, if at least one person has downloaded the entire file, then the system can handle the loss of the dedicated seed as well. This goes above the reliability of the single point download.
As for speed, the dedicated seed could have the same capacity as todays single point download source. It would help seed others really fast. After that it would be even faster than today. So you get greater speed with this solution than with the current solution.
So, why would people want to share?
First of all, if Apple builds it so that it doesn't interfere with the users normal activities then users might not object much to have it running in the background.
In addition, the application can keep track of your share ratio and allow you a faster download if you have a good share ratio. This will encourage a user to keep sharing all night in anticipation of being able to download the latest "word nerds" or systm podcast at maximum speed the next day.
I'm thinking about this in terms of podcasts. And the podcasts that you are finding on iTunes aren't actually on the iTunes server. The only thing on the iTunes server is the small XML feed description file. When you click to download a podcast you are downloading it from the podcast publishers web server. And those are the people that this system would help the most.
Slashdot Mirror
I admit it. I'm an iPod fan-boy. And as such I've been in the Apple store shortly after releases of iPods quite a few times and the demand for the newly released iPods are just insane. If they can speed up that process then that's good for both the customer and the store.
If I had written this software I would just determine if the subject was male or female from the user name.
Then, if the user is female I'd hard code the mood to "mood for shopping" and if male I'd hard code it to "mood for porn".
There, five minutes of coding and the result is spookily accurate.
Why not?
A single CPU machine without hyperthreading would be an example.
I'm wondering if you actually are talking about software in your question. And while the application server most certainly will be multithreaded your web request will most likely execute in one thread from the time the request is made until you send the response. Unless you create a second thread yourself.
But I shouldn't have said: "This is a benefit for single threaded hardware". I should have said: This is a benefit you get _even_ on single threaded hardware.
And the benefit I'm talking about is that the cleanup can take place after the response has been sent.
off topic, but do you know that gruntled actually isn't the opposite of disgruntled? The dis is part of the word and not a prefix. I still appreciate your sig, I just thought that you might be interested to know.
For a single threaded piece of work on a computer with SMP, hyperthreading or dual core... Umm, yes, it does.
Also, consider a call to a web servie. With C++ the destructors for any objects you allocate has to be executed before the webservice can return. For Java the webservice can return before the objects are destroyed. So they will be able to do some of the work after the web service has responded to the client. This is a benefit for single threaded hardware.
I love the requirements they list (especially note the last one):
* Windows XP with Service Pack 1 installed or Windows 2000 with Service Pack 3 installed, or newer, or Mac OS X 10.3 or newer.
* A connection to the Internet.
* 512 megabytes of RAM is recommended.
* Lots of spare time.
That was harder than I thought:
perpetuum fellatio, 922 hits
perpetuum chives, 84 hits
perpetuum snail, 190
922 people were able to fit perpeetum and fellatio on the same page. 84 people wrote about perpetuum and chives and 190 about perpetuum and snail.
perpetuum napalm, 2190
perpetuum booger, 487
perpetuum spleen, 518
perpetuum ninja, 931
Man...
While Pricerite seems to be grade A jerks it is immature to try to DOS their website.
Complaints should go through normal channels. A few comments up there was a guy with the opposite perspective. He had an online store and was blown out of the water by a "conspiracy" that likely was due to the competition not liking him. He seemed like a nice guy.
So, what guarantee do you have that Pricerite aren't good guys and all the testimonials you have read are fictious? You would only need maybe 10 fictitious online identities to achieve this.
I think Pricerite probably deserve getting shafted. But not this way!
Sheesh...
Been there done that
Amen!
I'm so tired of people who say to _never_ use gotos. I understand why professors are saying this. The average computer science student often will use it in the wrong way. On average a class of computer science students will produce better code if they are told to never use gotos. But that doesn't mean that it never is good, only that the average programmer is a moron.
Not using goto's are one of those mantras that was coined by someone who hadn't thought things through, that got popular and were taught to students without critical thinking by professors with no real life experience.
I rarely use gotos (unless I'm coding in a language that doesn't support exceptions in which case it is a central part to how I centralize the cleaning up my stuff before returning an error code from my function) but I would be really pissed if it wasn't available when I really need it.
I think it would be a great idea if you could re-download your songs and I would pay for it.
1 cent is a good deal for me, and 1 cent will cover the network cost for iTunes.
I think the problems aren't of a technical nature. I rather think that the RIAA has objections and concerns of abuse.
I don't know if I'm misreading your post and maybe I'd read something different into it if I was working at your company. But I react to two things:
/. post you say that you pay low salaries and you don't expect gurus. So the "amazing" support team is a marketing term. This is fine. Except, don't write about it in a public forum.
1) I followed the link to your companies web site and you speak of your amazing support team, yet, in your
2) With the reasoning in item 1) it seems as if you are stabbing your existing employees in the back. You are saying that they aren't very good.
Now, I realise that I might have misunderstood your post and if that is the case then please set me straight. But even if I did, I'm thinking others might also have misunderstood.
Suggesting that SCO has visited another dimension is ridicilous when it is clear that they just have traveled in time.
I don't disagree with using stored procedures. Or even putting business logic in them if it either makes something a whole lot simpler, or if it is more efficient (and the optimization is needed).
I'm an OO guy. I am also a database guy. But I'm a zealot of neither. I worship correctness, robustness, simplicity and 'fast enough'.
Zealots of either side tend to come up with rules that categorically puts some type of code inside or outside the database. Their rules are right most of the time, but there are often exceptions.
The pragmatic programmer is always right though (conceptually speaking).
I love it when someone comes up to me and says that gotos shouldn't be allowed. These are typically spoon fed students who forgot to think on their own. Because I can show them that there are cases where gotos makes things simpler or faster. Gotos are often bad, but not always. To paraphrase the NRA wackos, gotos don't write bad code, people do.
Amen brother!
.net. Not just stored procedures. ODBC supports arrays as input parameters, so the problem isn't in SQL Server. I think the problem is that ADO.net doesn't support it. One would presume that they will sooner or later. Who know's they might even support it with the version that was released today? I don't really know.
I believe this is true for any SQL statement in
It is pretty easy to scale most things in a big n-tier system. Just buy more servers. The database however is really hard to scale. You quickly get to a point where twice the money will buy you only very little extra performance.
Therefore I treat the database as the "sacred resource". This almost always means that business logic is kept outside the database.
Your approach was right in the 80's when client/server was the norm. Today you should have an n-tier system and have the business logic in an application server.
You can still have lots of different applications while using centralized code. Only, now you call the application server instead of the database.
Part of that coolness and trendyness, I think, isn't just the look of the machines. It is because "coolness" is spilling over from the iPod to the entire Apple brand. It has also helped tremendeously with the brand awareness.
I'm the grand parent AC.
A bad manager, using either your system or mine, would still be a bad manager. And a good manager, using either your system or my system would likely still be a good manager.
Assuming that both you and I are good managers we would likely be good managers with either method, but probably a bit better with our "own" method. It also depends on the type of work the team is doing and the personalities in the team.
Putting it shortly, the manager and his/her basic properties are more important than the method.
My guess is "double plus good"!
Hahaha...
Great comment. It took me a while to figure it out though.
So, to those that don't get it. That's clippy from the office suite.
I'm afraid that you have created a monster though. This will be the new beowulf, natalie portman, hot grits, soviet russia plague.
Again, on Dilberts advice... You should probably hum west side story and have a dance fight.
So, since this is free it should be possible to add this as a listing to iTunes, right?
Industry support.
Downloading from one dedicated single source, like it is now, is _less_ reliable than a swarm with one dedicated seed that takes the place of the current dedicated single source.
The swarm can deal with every single seed going off line, as long as the dedicated seed stays up. This is equivalent to the current single point download.
But in addition to this, if at least one person has downloaded the entire file, then the system can handle the loss of the dedicated seed as well. This goes above the reliability of the single point download.
As for speed, the dedicated seed could have the same capacity as todays single point download source. It would help seed others really fast. After that it would be even faster than today. So you get greater speed with this solution than with the current solution.
So, why would people want to share?
First of all, if Apple builds it so that it doesn't interfere with the users normal activities then users might not object much to have it running in the background.
In addition, the application can keep track of your share ratio and allow you a faster download if you have a good share ratio. This will encourage a user to keep sharing all night in anticipation of being able to download the latest "word nerds" or systm podcast at maximum speed the next day.
I'm thinking about this in terms of podcasts. And the podcasts that you are finding on iTunes aren't actually on the iTunes server. The only thing on the iTunes server is the small XML feed description file. When you click to download a podcast you are downloading it from the podcast publishers web server. And those are the people that this system would help the most.