In most of Europe laws are very similar to canadian law in that sense - which is why EULAs are not worth the paper they're written on around here.
From many stories in Slashdot i get the impression that laws in the US are a lot less consumer friendly than in most other western countries - add to that the disparity in resources between consumers and companies (as pointed already by another poster) and an expensive legal system where the party with the less resources has to pay full costs even when they win and the end-result is the unpunished widespread use of deceitful and bulish practices by companies towards individual consumers.
I can understand the fixation of many americans on small government as an ideal - one of the few acceptable purposes of democratic governments beyond enforcing the law is to keep the ballance between the individual and the corporations. In the US it seems that the main purpose of government is to further empower corporations...
I've played EVE for a year - so i was hardly a new player.
When you're travelling 20+ systems in a trade run it can easilly take hours to get from one place to the other. Even with instas (and i did had quite a big network of instas), a 10 system trip stil takes 15-30 minutes.
Very often you have to trade speed for firepower or hauling tonnage and fast frigates not an option when you're doing things like hauling ore, flying trading runs or moving your BS to 0.0.
BTW: For fast AFK travelling shuttles are the best option.
If you really want to have some fun i recommend you train for elite frigates and join a 0.0 corp.
I reckon this is just yet another lame PR tactic - trying to give the impression that the console is going to be so successful that they have to have a really high reserve price.
Next up will be some article about Sony having to turn away game development companies that want to develope games for the PS3 so as to avoid having too many titles when the PS3 comes out...
I guess it can be seen as subtle criticism to the excess of Sony-PS3 articles and all the attention which is being given around here at the moment to all PS3ish things.
Some of us are kind of fed up with all the viral marketing type of articles about the PS3 around here when we have already decided that the PS3 is most likelly a dead fish anyways and even if it isn't we've already made our minds to get something else for our gaming needs so we don't really care that much.
EVE requires constant massive time injections - basically travelling takes a lot of time and making money to aquire a half-decent ship requires lots of time doing repetitive taks (mining, trading, missions).
From the several MMORPGs i've played (WoW included), the only one that doesn't push you by design into one or more "time-sinks" is Guild Wars - which is also the only one where you don't pay a monthly fee.
---- Back to the overall theme of the thread ----
The threat posed by WoW to games such as Titan Quest is much more basic than it being a time-sink for hardcore gamers: - It simply is one of the best RPGs out there.
If you concentrate on the basic RPG aspects of WoW and forget about the whole end-level content stuff (which indeed are just time sinks for hardcore gamers) and PvP aspects (some of the major problems with the game have to do with griefing by high-level players), it turns out that WoW is very much a voyage of wonder and discovery, way up there amongst the best such as Neverwinter Nights (beter than Oblivion IMHO).
At the same time, Titan Quest sucks (starting with the view point never going high enough to allow you to see enough around you no nor low enough to allow you to play in 1st person view and feel like you're the hero).
The time sink problem is only an issue for game publishers targetting the hardcore gamer market segment - as yesterday's teenage (hardcore) gamers age and turn into today's adult (casual) gamers, more and more of the gamer population consists of gamers which don't have the time to seriously go into online RPGs and would rather just have games which you can just pick up and have fun for half-an-hour.
Maybe the industry should start targetting the part of the gaming market that's actually growing???
Really, now... is this the fault of the iPod and not the punk-ass thugs doing this crap?
Of course not.
They're just poor desinfranchised youths which are led astray by the perverse influence of the corporated controlled media and the consumeristic society they live in.
If it wasn't for iPod and other such pseudo-status symbols of our out of control society they wouldn't be pressured into a life of crime.
Deep down they're really all pure hearthed little angels.
Scenario: You move from SQL Server to Oracle. You use sprocs, so the only communication you do with the database is to pass parameters too/from said sprocs.
Now, if you'd been using SQL from your object layer, you'd have had to re-write all the SQL code in the application. If, however, you used sprocs, you simply re-write them all, then change your data access layer's setting to use Oracle. Your application is now completely unaware of the change and requires minimal re-writing.
If you used SQL92 (as in, standard SQL) and were not relying on vendor specific database access libraries you won't have to change a single piece of database access code in your app when changing databases. This is of course dependent on the language you're using for the core application and the database libraries available in that language. For example, in Java, using the standard libraries all you would have to do is load a different driver class and use a different connection URL.
Even if some queries are database specific, only those queries have to be changed when changing databases, while with stored procs it is 100% guaranteed that the whole database-bound data access layer would need to be redone from scratch.
You're also ignoring what happens when a business object (say, a customer order) is split over 3 or 4 tables in the database: using a sproc can give you a nice, simple interface to those tables so your developers don't have to worry about the underlying database structure.
You can just as easilly create said simple interface in the application side - it's called a method.
Also, SECURITY. If you use SQL, then you give your application blanket rights to execute arbitrary code. Assuming it's compromised, an attacker could run any code they wanted on your database. Using sprocs, they can only run those procedures which the application is allowed to run.
It depends: - If your stored procedures are low level enough so that that don't contain much business logic, then they will likelly be very close to basic operations and cover a great deal of the universe of all such operations. In that case they're just a non-standard interface for doing most of what could otherwise be done via the standard interface and can be combined to do the vast majority of the possible operations on data. - If on the other hand they are functions of a high enough level of complexity that combining then still results in pretty much only being able to do changes to the data as the application would (eg, a transfer_money method which "checks the debitors balance, takes money from the debitor's account and places it on the creditors account"), then you've just moved you business logic to the database thus openning a whole new Pandora's box.
Security: You can grant privs on the sproc and not on the underlying table.
And yet anything the application can do, anybody with the application's password on the database can do too. Unless your application can't write to the database (in which case making the tables read-only would be easier), the procedures will still provide a gateway to the database - in which case you didn't really added any security, at most you've made sure that security breaches will keep data consistency (assuming the stored procs are designed in such a way as to guarantee that - although if they are, they likelly encode business logic).
Testability: You can test your sproc separate from your application logic.
Testing of application components separated from the rest of the application logic (aka unit testing) is already common without the need of spreading the application accross 2 different platforms and 2 different languages. If people design an application with separate Data Access Component (be they objects, components or methods) they can already test them separately from the rest - no need to move that code to the database.
DB roundtrips: Need to update ten tables? Do it in a sproc and call it in 1 step as opposed to 10 steps.
That's what i meant with "solve high-impact IO bottlenecks between the application and the database". My point being you do this as an exception, not as a rule. When choosing the path of also coding in the database, you should keep in mind the side-effects of it. I've personally more than once refrained from doing this because i was aware that nobody else in the company would've been able to maintain the database code when i left (i'm a freelancer), though on other occasions i've used this because other members of the team could maintain that code too.
Splitting the code into multiple tiers - specifically in this case, by putting part of it in the database - is not a decision to take lightly. There is a number of side-effects that might negate any expected beneficts from such a move, for example: - Two languages, meaning people with expertise in both are needed - Application upgrades will much more often include database updates. This means your upgrade scripts will have to do both most of the time and that you have twice as much chance that the upgrade will fail. Rolling back failed upgrades accross two different platforms is much more complex that for only one platform. - Version control on both the database and the application itself is much more important. If you don't control the production environment (for example it's hosted by a customer) both the application and the database should have some sort of version number, with the application checking the one in the database and only running if it matches the expected one. You can get away with not doing it when all that's on the database is a data model, since it rarelly changes (in mature applications, it hardly ever changes). - All sorts of border problems (in the core application - database border) in developing the application, such as for example not being able to properly take advantage of certain core application side frameworks/libraries for persistant datastore access (since they're not optimized to calling procedures on the database), silent databased side updating of data contained in the core application side caches, meta-definition issues ("what happens if i pass a negative number in this parameter of this stored procedure") when there are two devs one on each side and much more.
If the upsides don't outweight the donwsides and the extra risks of doing it in some other way, then it's beter not to do it this way.
Certainly it's not worth using stored procedures if the only upside is not having to escape SQL input strings.
My very recent experience working for a company that makes web sites (i'm a freelance software designer/developer) is that most developers working there have almost no notion of data integrity (transactions, what's that?).
Interestingly enough the place suffered from most of the illnesses of our industry: - Clueless managers - Disorganised development process (if we can call THAT a process) - Ad-hoc tracking of requirements - Undocumented requirements, no design, undocumented code - Feature creep - Overworking - Lack of professionalism in the contacts with the customer, including on delivery - Arbitrary choice of frameworks, libraries and even languages to implement new applications, the choice being mostly made on the basis of the "how much fun it would be to use this", "this is new and sounds cool" and "how good it will look on my CV" criteria.
From what i've read here on Slashdot i'm starting to get a feeling that this a wider problem with this part of the industry (ie web development) rather than just a problem with a specific company.
If that is so, it's hardly surprising to find widespread input checking related security problems with web sites...
Or you could just use stored procedures. I've been doing that for years without any problems. I've also never had any issue with "business logic". I can keep my business logic seperate with stored procs. (I never understood that argument against them.)
If your stored procedures are only very thin layers encapsulating low level database access operations (thus not much more than pre-packaged selects, updates, inserts and deletes) you should have no business logic in the database problems.
On the other hand there's a couple of downsides to such a design: - It requires developers with a good level of expertise in both the language used to develop the core of the application and the one used for the stored procedures. This is true both for initial development and for maintenance. - It makes an application tightly couple to the database. If you want to port to another database, at the very least you will have to redo all the stored procedures. - It increases the likellyhood of having version conflict problems between the core application and the database application components. More specifically, the data-model is usually more stable across versions of the application than the actions executed on data in that model (eg "find all employees in more than Y departments and whose manager is level X"), and thus if you store in the database code which is tightly couple to the actions that the application executes on the data then previous versions of the database (for example, those restored from a backup) are not likelly to work with the lastest version of the application (nor are they likelly to be easilly "fixed" by a DBA). - It's harder to debug code that crosses platforms and languages
More in general, the problem of SQL injection can be avoided simply by using prepared statements or any other type of SQL query that takes input parameters instead of using string concatenation to make SQL queries that include the input values.
Using stored procedures to solve this specific problem is very much overkill.
Beyond this, the only good reason i can see for using stored procedures like this is for performance reasons if you do some level of post-processing on the results or some sort of "smart" block updating of data. In this case, stored procedures should only be used in a very small number places (to solve high-impact IO bottlenecks between the application and the database) and not in a generic way.
The last couple of reasons i see for such a design are: - A "job protection" measure by locking the application to the specific skillset combination of a specific developer - Because the developer prefers-to/is-more-confortable-with developing code in the database that in the core application Hardly good reasons IMHO
Feel free to share with us how to do in HQL: - an hierarchical query (Oracle style) - a bulk update having a sub-select in the SET clausule
So yeah, HQL can't do everything for you, and when you have to go beyond what HQL can do, you end up hand coding SQL. At this point there are two types of programmers: - Those that escape single quotes - Those that don't
And no, prepared statements aren't always the right option.
"More dangerous than those which are totally ignorant are those which do not yet know enough to be aware of how much they do not know"
And that's what is wrong with todays sets. No room to grow with them. Of course they get boring quick - that's part of the revenue model. They're designed not to hold your interest very long - you can only do one thing per set. Don't confuse poor toy design with ADHD or video game addiction. You are making a more boring product these days. Your revenue-maximizing model you've fallen in love with is the broken part. Go back to making general sets as well as your special kits and you'll see interest in Hot Wheels perk back up I'll bet.
Same problem with Legos.
I stopped giving Legos to my friends' kids because of that:(
It's quite likelly that stem cell research will help discover a way to regenerate organs.
In a scenario where one's organs can be regenerated, suspended animation could be used, if needed, to maintain the sick person alive until the process of generating the organ(s) - quite likelly outside the body - was completed.
Still, if a certain moralistic government of a certain big country gets their way the world described by Larry Niven is more likelly to be what we get.
Perfectionism can be a problem in IT (and most other creative fields) because: a) Perfection is by definition an unachievable ideal. b) Customers are not willing to do a tradoff where the perfect system will be delivered to them after and infinite amount of time.
If you have a problem with perfectionism (like i did when i started), i sugest you aim for "maximum efficiency" instead of "perfect implementation". The intersting part of this approach is that you'll not only learn your job, but also a bit of all the non-technical jobs that feed into the software development process (business analysis, management) since they have a (really) big impact in the efficiency of the software development process.
The idea of playing Quake online with a 345600000 ms ping time is... interesting.
"When i was a kid we didn't have any online FPS... we would just go out the street, point a fingers to some other kid and say 'Pam' - and then we had to convinced him to play dead".
If you feel like your project needs some sort of methodologies in place, but "you don't have the time", the answer is simple, it's not that you don't have the time, you don't have the right personnel. It's true if you have no one with the experience of delivering the architecture required in a professional and timely manner then taking on methodologies new to everyone on the team is going to take time and lots of it. A good manager however will make sure that the project is correctly resourced.
Unfortunately, from my experience, there seems to be both a lack of business analysts with the experience and ability to create a well-documented, internally consistent set of requirements and of senior designers/developers that actually figured out that the secret of speed in software design/development is to take some time of in the beginning for preparation.
And please, don't get me started on clueless managers...
From a cursory look at the article i got the impression that the "tricks" listed boil down to "doing what should've been done in the beginning during analysis".
Starting a project without gathering requirements, scoping the project, hammering the list of business rules and doing a high-level design is a great way set the project up for getting out of control after a couple of months, even without the extra pressure.
Just make your developers pick up the slack by working lots of overtime.
A couple of points: - If you don't have a clear vision of what the software is suposed to do and how to get there, having people work 10h/week or 80h/week produces exactly the same result - you get nowhere - either the project is late and gets canned or what you deliver is not accepted because it doesn't match the expectations of the customer. - Long hours => tired developers => a lot more bugs => much more time is needed to implement the same features => long hours. Unless long hours are restricted to a couple of days, the end result is a vicious circle where removing the extra bugs introduced by tired designers/developers ends up consuming more time than whatever extra time you got from those extra work work hours.
Making people work extra hours gives the appearence of getting more work done while reducing the actually amount of work that does get done. This is one of those management techniques that sites high up in the list of "Things that managers that have no sense of strategy do", right above measuring productivity by "lines of code written" instead of by "requirements features implemented".
this is just a sign that the web has got dumb enough for dumb people to use it
People have been complaining about dumb people using the internet ever since AOL started giving their users access to it.
(i would hardly be surprised if the guys that created Darpanet were the first to get concerned about dumb people accessing the would be Internet when universities started giving students access to it)
My favorite model is what i call try-and-buy (just made the name up, feel free to find a beter one). It works like this: - Download the music, movies, games from the Internet - If you like them, buy them - If you don't like them, stop using them
For someone like me (and hopefully many others here in/.), the problem is not one of lack of money to pay for content, it's one of being decieved once too many by sleazy industry tricks such as: - Music CDs whic have only 1 good track (which has been hyped-up by radio) but cost full price. - Music CDs that won't play in some CD Players and which are hard to rip to MP3s so that i can listen them in my MP3 player. - Games which have been hyped up by the media but turn out to be: not-really-that-fun / short / buggy / hindered-by-needless-copy-protection or in general not worth the money. - Movies released at different times in different regions. - Technology to artificially regionally segment markets so as to inflated prices in some markets (ie, Region Code in DVDs).
The method i described combines some level of consumer protection (since both the content producing industry and the media industry - which promotes the content - have shown themselfs not to be in any way trustworthy) with paying content producers for the content one does use and enjoy, NOT for content one neither uses nor enjoys.
In other words - reward those who make products that do satisfy their customers and NOT those that try to scam their customers.
- The FIA is a private company which has the full rights to F1. Although the FIA is part owned by the racing teams, in practice (and with the help of a really complicated corporate structure and some borderline-legal tricks with assigning members to the board of one of the parent companies) it's controlled by Bernie and Max.
There's been quite a number of problems with it latelly (i.e. the borderline-legal tricks) and last i heard the racing teams wanted to create a separate league controller by the racing teams themselfs.
So: - It's hardly surprising that FIA (a private company not controlled by the racing teams) would do an exclusivity contract with MS - F1 might have it's days counted anyway.
Slashdot Mirror
In most of Europe laws are very similar to canadian law in that sense - which is why EULAs are not worth the paper they're written on around here.
...
From many stories in Slashdot i get the impression that laws in the US are a lot less consumer friendly than in most other western countries - add to that the disparity in resources between consumers and companies (as pointed already by another poster) and an expensive legal system where the party with the less resources has to pay full costs even when they win and the end-result is the unpunished widespread use of deceitful and bulish practices by companies towards individual consumers.
I can understand the fixation of many americans on small government as an ideal - one of the few acceptable purposes of democratic governments beyond enforcing the law is to keep the ballance between the individual and the corporations. In the US it seems that the main purpose of government is to further empower corporations
I've played EVE for a year - so i was hardly a new player.
When you're travelling 20+ systems in a trade run it can easilly take hours to get from one place to the other. Even with instas (and i did had quite a big network of instas), a 10 system trip stil takes 15-30 minutes.
Very often you have to trade speed for firepower or hauling tonnage and fast frigates not an option when you're doing things like hauling ore, flying trading runs or moving your BS to 0.0.
BTW: For fast AFK travelling shuttles are the best option.
If you really want to have some fun i recommend you train for elite frigates and join a 0.0 corp.
Actually if 1 person eats a whole chicken and 3 other persons eat no chicken at all then in average they each eat 1/4 of a chicken.
Not that it really maters for the chicken in question though.
I reckon this is just yet another lame PR tactic - trying to give the impression that the console is going to be so successful that they have to have a really high reserve price.
...
Next up will be some article about Sony having to turn away game development companies that want to develope games for the PS3 so as to avoid having too many titles when the PS3 comes out
I guess it can be seen as subtle criticism to the excess of Sony-PS3 articles and all the attention which is being given around here at the moment to all PS3ish things.
Some of us are kind of fed up with all the viral marketing type of articles about the PS3 around here when we have already decided that the PS3 is most likelly a dead fish anyways and even if it isn't we've already made our minds to get something else for our gaming needs so we don't really care that much.
Then again, maybe it's just me.
EVE requires constant massive time injections - basically travelling takes a lot of time and making money to aquire a half-decent ship requires lots of time doing repetitive taks (mining, trading, missions).
From the several MMORPGs i've played (WoW included), the only one that doesn't push you by design into one or more "time-sinks" is Guild Wars - which is also the only one where you don't pay a monthly fee.
----
Back to the overall theme of the thread
----
The threat posed by WoW to games such as Titan Quest is much more basic than it being a time-sink for hardcore gamers:
- It simply is one of the best RPGs out there.
If you concentrate on the basic RPG aspects of WoW and forget about the whole end-level content stuff (which indeed are just time sinks for hardcore gamers) and PvP aspects (some of the major problems with the game have to do with griefing by high-level players), it turns out that WoW is very much a voyage of wonder and discovery, way up there amongst the best such as Neverwinter Nights (beter than Oblivion IMHO).
At the same time, Titan Quest sucks (starting with the view point never going high enough to allow you to see enough around you no nor low enough to allow you to play in 1st person view and feel like you're the hero).
The time sink problem is only an issue for game publishers targetting the hardcore gamer market segment - as yesterday's teenage (hardcore) gamers age and turn into today's adult (casual) gamers, more and more of the gamer population consists of gamers which don't have the time to seriously go into online RPGs and would rather just have games which you can just pick up and have fun for half-an-hour.
Maybe the industry should start targetting the part of the gaming market that's actually growing???
Nobody gets irony these days ....
Of course not.
They're just poor desinfranchised youths which are led astray by the perverse influence of the corporated controlled media and the consumeristic society they live in.
If it wasn't for iPod and other such pseudo-status symbols of our out of control society they wouldn't be pressured into a life of crime.
Deep down they're really all pure hearthed little angels.
PS: Do i hear a whooshh?
If you used SQL92 (as in, standard SQL) and were not relying on vendor specific database access libraries you won't have to change a single piece of database access code in your app when changing databases. This is of course dependent on the language you're using for the core application and the database libraries available in that language.
For example, in Java, using the standard libraries all you would have to do is load a different driver class and use a different connection URL.
Even if some queries are database specific, only those queries have to be changed when changing databases, while with stored procs it is 100% guaranteed that the whole database-bound data access layer would need to be redone from scratch.
You can just as easilly create said simple interface in the application side - it's called a method.
It depends:
- If your stored procedures are low level enough so that that don't contain much business logic, then they will likelly be very close to basic operations and cover a great deal of the universe of all such operations. In that case they're just a non-standard interface for doing most of what could otherwise be done via the standard interface and can be combined to do the vast majority of the possible operations on data.
- If on the other hand they are functions of a high enough level of complexity that combining then still results in pretty much only being able to do changes to the data as the application would (eg, a transfer_money method which "checks the debitors balance, takes money from the debitor's account and places it on the creditors account"), then you've just moved you business logic to the database thus openning a whole new Pandora's box.
And yet anything the application can do, anybody with the application's password on the database can do too. Unless your application can't write to the database (in which case making the tables read-only would be easier), the procedures will still provide a gateway to the database - in which case you didn't really added any security, at most you've made sure that security breaches will keep data consistency (assuming the stored procs are designed in such a way as to guarantee that - although if they are, they likelly encode business logic).
Testing of application components separated from the rest of the application logic (aka unit testing) is already common without the need of spreading the application accross 2 different platforms and 2 different languages. If people design an application with separate Data Access Component (be they objects, components or methods) they can already test them separately from the rest - no need to move that code to the database.
That's what i meant with "solve high-impact IO bottlenecks between the application and the database". My point being you do this as an exception, not as a rule. When choosing the path of also coding in the database, you should keep in mind the side-effects of it. I've personally more than once refrained from doing this because i was aware that nobody else in the company would've been able to maintain the database code when i left (i'm a freelancer), though on other occasions i've used this because other members of the team could maintain that code too.
Splitting the code into multiple tiers - specifically in this case, by putting part of it in the database - is not a decision to take lightly. There is a number of side-effects that might negate any expected beneficts from such a move, for example:
- Two languages, meaning people with expertise in both are needed
- Application upgrades will much more often include database updates. This means your upgrade scripts will have to do both most of the time and that you have twice as much chance that the upgrade will fail. Rolling back failed upgrades accross two different platforms is much more complex that for only one platform.
- Version control on both the database and the application itself is much more important. If you don't control the production environment (for example it's hosted by a customer) both the application and the database should have some sort of version number, with the application checking the one in the database and only running if it matches the expected one. You can get away with not doing it when all that's on the database is a data model, since it rarelly changes (in mature applications, it hardly ever changes).
- All sorts of border problems (in the core application - database border) in developing the application, such as for example not being able to properly take advantage of certain core application side frameworks/libraries for persistant datastore access (since they're not optimized to calling procedures on the database), silent databased side updating of data contained in the core application side caches, meta-definition issues ("what happens if i pass a negative number in this parameter of this stored procedure") when there are two devs one on each side and much more.
If the upsides don't outweight the donwsides and the extra risks of doing it in some other way, then it's beter not to do it this way.
Certainly it's not worth using stored procedures if the only upside is not having to escape SQL input strings.
My very recent experience working for a company that makes web sites (i'm a freelance software designer/developer) is that most developers working there have almost no notion of data integrity (transactions, what's that?).
Interestingly enough the place suffered from most of the illnesses of our industry:
- Clueless managers
- Disorganised development process (if we can call THAT a process)
- Ad-hoc tracking of requirements
- Undocumented requirements, no design, undocumented code
- Feature creep
- Overworking
- Lack of professionalism in the contacts with the customer, including on delivery
- Arbitrary choice of frameworks, libraries and even languages to implement new applications, the choice being mostly made on the basis of the "how much fun it would be to use this", "this is new and sounds cool" and "how good it will look on my CV" criteria.
From what i've read here on Slashdot i'm starting to get a feeling that this a wider problem with this part of the industry (ie web development) rather than just a problem with a specific company.
If that is so, it's hardly surprising to find widespread input checking related security problems with web sites...
If your stored procedures are only very thin layers encapsulating low level database access operations (thus not much more than pre-packaged selects, updates, inserts and deletes) you should have no business logic in the database problems.
On the other hand there's a couple of downsides to such a design:
- It requires developers with a good level of expertise in both the language used to develop the core of the application and the one used for the stored procedures. This is true both for initial development and for maintenance.
- It makes an application tightly couple to the database. If you want to port to another database, at the very least you will have to redo all the stored procedures.
- It increases the likellyhood of having version conflict problems between the core application and the database application components. More specifically, the data-model is usually more stable across versions of the application than the actions executed on data in that model (eg "find all employees in more than Y departments and whose manager is level X"), and thus if you store in the database code which is tightly couple to the actions that the application executes on the data then previous versions of the database (for example, those restored from a backup) are not likelly to work with the lastest version of the application (nor are they likelly to be easilly "fixed" by a DBA).
- It's harder to debug code that crosses platforms and languages
More in general, the problem of SQL injection can be avoided simply by using prepared statements or any other type of SQL query that takes input parameters instead of using string concatenation to make SQL queries that include the input values.
Using stored procedures to solve this specific problem is very much overkill.
Beyond this, the only good reason i can see for using stored procedures like this is for performance reasons if you do some level of post-processing on the results or some sort of "smart" block updating of data. In this case, stored procedures should only be used in a very small number places (to solve high-impact IO bottlenecks between the application and the database) and not in a generic way.
The last couple of reasons i see for such a design are:
- A "job protection" measure by locking the application to the specific skillset combination of a specific developer
- Because the developer prefers-to/is-more-confortable-with developing code in the database that in the core application
Hardly good reasons IMHO
So you live in one of the poles?
Feel free to share with us how to do in HQL:
- an hierarchical query (Oracle style)
- a bulk update having a sub-select in the SET clausule
So yeah, HQL can't do everything for you, and when you have to go beyond what HQL can do, you end up hand coding SQL. At this point there are two types of programmers:
- Those that escape single quotes
- Those that don't
And no, prepared statements aren't always the right option.
"More dangerous than those which are totally ignorant are those which do not yet know enough to be aware of how much they do not know"
Same problem with Legos.
I stopped giving Legos to my friends' kids because of that
It's quite likelly that stem cell research will help discover a way to regenerate organs.
In a scenario where one's organs can be regenerated, suspended animation could be used, if needed, to maintain the sick person alive until the process of generating the organ(s) - quite likelly outside the body - was completed.
Still, if a certain moralistic government of a certain big country gets their way the world described by Larry Niven is more likelly to be what we get.
Perfectionism can be a problem in IT (and most other creative fields) because:
a) Perfection is by definition an unachievable ideal.
b) Customers are not willing to do a tradoff where the perfect system will be delivered to them after and infinite amount of time.
If you have a problem with perfectionism (like i did when i started), i sugest you aim for "maximum efficiency" instead of "perfect implementation". The intersting part of this approach is that you'll not only learn your job, but also a bit of all the non-technical jobs that feed into the software development process (business analysis, management) since they have a (really) big impact in the efficiency of the software development process.
The idea of playing Quake online with a 345600000 ms ping time is ... interesting.
... we would just go out the street, point a fingers to some other kid and say 'Pam' - and then we had to convinced him to play dead".
"When i was a kid we didn't have any online FPS
... does a coder with multiple personality disorder really need a collegue for pair programming?
Unfortunately, from my experience, there seems to be both a lack of business analysts with the experience and ability to create a well-documented, internally consistent set of requirements and of senior designers/developers that actually figured out that the secret of speed in software design/development is to take some time of in the beginning for preparation.
And please, don't get me started on clueless managers
From a cursory look at the article i got the impression that the "tricks" listed boil down to "doing what should've been done in the beginning during analysis".
Starting a project without gathering requirements, scoping the project, hammering the list of business rules and doing a high-level design is a great way set the project up for getting out of control after a couple of months, even without the extra pressure.
A couple of points:
- If you don't have a clear vision of what the software is suposed to do and how to get there, having people work 10h/week or 80h/week produces exactly the same result - you get nowhere - either the project is late and gets canned or what you deliver is not accepted because it doesn't match the expectations of the customer.
- Long hours => tired developers => a lot more bugs => much more time is needed to implement the same features => long hours. Unless long hours are restricted to a couple of days, the end result is a vicious circle where removing the extra bugs introduced by tired designers/developers ends up consuming more time than whatever extra time you got from those extra work work hours.
Making people work extra hours gives the appearence of getting more work done while reducing the actually amount of work that does get done. This is one of those management techniques that sites high up in the list of "Things that managers that have no sense of strategy do", right above measuring productivity by "lines of code written" instead of by "requirements features implemented".
People have been complaining about dumb people using the internet ever since AOL started giving their users access to it.
(i would hardly be surprised if the guys that created Darpanet were the first to get concerned about dumb people accessing the would be Internet when universities started giving students access to it)
My favorite model is what i call try-and-buy (just made the name up, feel free to find a beter one). It works like this:
/.), the problem is not one of lack of money to pay for content, it's one of being decieved once too many by sleazy industry tricks such as:
- Download the music, movies, games from the Internet
- If you like them, buy them
- If you don't like them, stop using them
For someone like me (and hopefully many others here in
- Music CDs whic have only 1 good track (which has been hyped-up by radio) but cost full price.
- Music CDs that won't play in some CD Players and which are hard to rip to MP3s so that i can listen them in my MP3 player.
- Games which have been hyped up by the media but turn out to be: not-really-that-fun / short / buggy / hindered-by-needless-copy-protection or in general not worth the money.
- Movies released at different times in different regions.
- Technology to artificially regionally segment markets so as to inflated prices in some markets (ie, Region Code in DVDs).
The method i described combines some level of consumer protection (since both the content producing industry and the media industry - which promotes the content - have shown themselfs not to be in any way trustworthy) with paying content producers for the content one does use and enjoy, NOT for content one neither uses nor enjoys.
In other words - reward those who make products that do satisfy their customers and NOT those that try to scam their customers.
By the way, FYI for everybody:
- The FIA is a private company which has the full rights to F1. Although the FIA is part owned by the racing teams, in practice (and with the help of a really complicated corporate structure and some borderline-legal tricks with assigning members to the board of one of the parent companies) it's controlled by Bernie and Max.
There's been quite a number of problems with it latelly (i.e. the borderline-legal tricks) and last i heard the racing teams wanted to create a separate league controller by the racing teams themselfs.
So:
- It's hardly surprising that FIA (a private company not controlled by the racing teams) would do an exclusivity contract with MS
- F1 might have it's days counted anyway.