Wow, looks like you had a bad week. You've taken this far too seriously. Honestly, man, this is a discussion of one paradigm vs. another.
Why let it go to your head?
Life is short. You should really take the time to enjoy it more.
I'm sorry I called your view of application development "myopic." You seem to be very sensitive to polite but unequivocal criticism. Had I realized you'd be so offended, I'd have left it out.
In my opinion it really WAS a nice conversation. Maybe we can pick it up again when you're less stressed-out.
"In my experience, 99 out of 100 web apps I've seen don't qualify, especially the inhouse frameworks. It's usually simple stuff like you mentioned, which is never reused outside the company, or even within, within its lifetime cycle. So if someone new comes in, he's awed by this huge, complex, slow system, which could have been done simpler and cheaper."
I really don't mean to be pedantic.. but I'm going to be
If code is never reused, never shared between different applications, how would it even meet the definition of a framework?
Wouldn't it just be part of the application?
I work for a web retailer and we produce a large number of product-centric websites (Amazon is the web version of a "big box" store that carries everything. We're the web version of, say, Limited Brands: Separate boutique stores for each product line)
Anyway, my point is that you seem to have an awfully myopic view of things.
I mean, you assume the application/framework is "simple stuff" because the only thing I mentioned was simple.
You assume an OOD application is "huge, complex, slow" perhaps because you've seen systems that are.
You assume that writing it in procedural code would be "simpler and cheaper" without taking the long view.
And it seems to me that you're really over-estimating he overhead that object construction brings.
If an object hierarchy is properly designed, using lazy-loading, object caching, etc, you're not going to see dramatic differences. It's going to be minor. Perhaps 10%. I'd even give you 15%. Which means that the 1 second execution time of a procedural system might increase to 1.1 seconds.
Again, that 1/10 second is not ever going to matter in the vast majority of applications that aren't run on an Slashdot-like scale.
And I really believe that OOD systems are far easier (thus cheaper) to maintain and modify.
Imagine you have a Widgets table and PHB wants a new column. In a proper OO system, you add the column to the database, you find the widgets class, you add a property of the same name, you use whatever system is in place in your app to define it as loaded-lazy or loaded-default.
Then you update the unit test.
And, that's it.
The reports and forms that bind to the data model will display the new field.
The sql that populates the objects will automatically reflect the new field.
And, for example, in our framework, its even easier. You just add it to the data model and load the class using a bootstrap script from the command line and it will automatically update the DB and the unit test.
Compare that to a procedural model. Data from that modified table might exist on any number of separate pages, in any number of methods. You will have to edit numerous SQL statements, reports, forms, etc. And it's very hard to be CERTAIN that you updated it everywhere that table is called.
Anyway, it's been a nice conversation. I've enjoyed it. I've made my point clear and there's no use in repeating myself.
"The decoupling of presentation from logic is one of the best paradigms you can use for any application."
Agreed. 100%.
And I like your take -- I suppose the web is innately MVC. But not in the sense that Rails is, and not in the sense that he meant.
We're talking more like requests come in and a simple procedural front-controller instantiates a Controller based on whatever routing rules you've defined. It creates the data models (Usually some ORM system, be it ActiveRecord or a TableGateway) and the View is going to be a templating engine of some sort.
"So for the web, it degenerates both object oriented programming and MVC into mere ways to organize your code"
That's nonsense.
If for no other reason than the fact that displaying a page often involves some real work. Some real heavy-lifting. Often far more than just a couple database queries being fed into a grid or report.
OOP brings order, structure, reuse and quality control to large, complex systems (and website/webapps can certainly be very large and very complex) That's true no matter what context it's being used in, web, rich client, whatever.
Yes, there is overhead involved in creating objects. But even in your worst-case scenario where there is no shared state, the overhead is hardly a deal breaker: It's far better to optimize for the developer than it is to optimize for the machine. Unless you're working on a website in the 99th percentile of traffic, you probably don't have a lot to worry about.
Further, your scenario IS worst-case.
For example, we have an in-house framework. It's not all that different than the ones you've seen. Take, for example, a simple web form:
You instantiate the data model (need to pre-populate the form), you instantiate a webform object, which is view-tier and is just a widget that binds to a data model and presents an HTML form.
When that form is rendered in HTML, the webform object and the data model it binds to are serialized and stored in the session.
When the user submits the form the front-controller will look at the formkey submitted with the form and unserialize the form and model objects. It pulls the values from the HTTP Post into the data model and they're validated and saved.
This is nothing revolutionary. It's not even complicated. And it's just one of a dozen ways to overcome the no-shared-state problem.
The idea that OOD is "degenerated" in a web environment is ludicrous. Procedural development is a thing of the past. The idea of 1 page : 1 script that runs from line 1 to line n is just not adequate for MOST modern web apps.
Todays systems are not your mothers web applications. We're doing far too much on the web. Applications the size of the web applications that are written today would collapse under their own weight if done procedurally.
Ok, I'll bite. What makes MVC a "piss poor model" for web applications?
The only thing you mentioned was scalability.
Personally, I find the MVC pattern applies to web apps wonderfully. Being able to "plug and play" views is far more helpful in the web universe than it is in rich client programming.
I can create a default view, lately that's been a standard XHTML interface with Ajax, usually leveraging the ext.js library.
And I also create a simplified HTML-only view for graceful degredation on clients that are not using JavaScript.
And a view for mobile interfaces.
On "data grid pages" I can plug-in a view that outputs the data in XML or Excel format.
For reporting I can create a view for an on-screen HTML based report, or I can plug in a view that displays it as a PDF or, again, XML or Excel.
Meanwhile, I only create the data models and controllers once.
This is FAR easier and faster to create and maintain.
And in todays world, unless you're a top-1% web destination it's a FAR wiser move to optimize for development time and cost than it is to optimize for the machine.
Adding a server is much cheaper than adding a developer.
Believe it or not, I'm not a fan of Rails. I'm especially not a fan of ActiveRecord. In ruby, DataMapper is a much better Db layer than is ActiveRecord.
But to denounce Rails because it's MVC? I'd love to hear why you feel that way.
FWIW, Inno (and other storage engines) do offer row-level locking. Only MyISAM tables are limited to table-level locking.
I'm curious.. if you're seeing 1000 t/s from a single user, what were the reasons you chose MySQL/MyISAM to begin with? (I'm genuinely interested. I'm a developer not an admin, but I do have a large set of experience with databases and datasets. My experience lies more on the capacity side than throughput. I've built systems on top of databases with billions of rows (the DNC voter history database, among others) but these systems were invariably fed millions of rows at a time by replication/dts and had very few cases of sustained transaction activity. Any given day would see millions of reads but just thousands of writes.
Very easy in nearly any modern DBMS to optimize such a system for reads. Biggest downside is the minutes needed to rebuild indices after batch-imports.
1. Inno provides row-level locking which is what the GP mentioned when he suggested Inno. The presumption being that any table with that many rows is going to have a lot of transactional activity.
That's not always the case. In just my small slice of the world I've been involved in 2 projects that fit that bill:
One was robotic cells in a manufacturing plant where each cell was attached to a PC that, among other things, ran a MySQL/ISAM DB that recorded a near-continuous stream of data from the robot. Anywhere between 500,000 and 1,000,000 writes per day that got uploaded to an Oracle db every night along with every other robots data stream. In this case locking was not an issue because every insert came from a single client. But speed was. Because we were writing between 5 and 10 rows per second.
The second example was a read-only reporting database.
2. There is no fine line between "large" and "small." 4bn rows is unquestionably large. Likewise, anything below, say, 500k rows is unquestionably small. But that leaves an awfully large gray area.
I dunno... If i'm that coworker, even if I like you, why would I go to mgmt and argue on your behalf?
If anything I would see it as an opportunity to demonstrate that I CAN handle things without you.
If I'm the manager and you come to me and say "You have to restore his privileges! I can't get my job done without him!"...well... I'd probably think that the guy is leaving in a couple weeks so maybe I should hire somebody who CAN.
OK... perfectly valid and all, but joining on the WHERE clause?
Yuck.
(I'm just being a little snarky. Any DBMS worth it's salt will execute the same query plan as it would if you did explicit INNER JOIN in the FROM clause, but if this was a code review and you were on my team, I'd be stressing the fact that join criteria is separate from product criteria and, as such, it should be kept separate)
You can also delete it and then create a text file and name it qttray.exe.
It will pass the generic:
if(!exists(qttray.exe)) {// recreate }
check but when it tries to execute it it just fails silently.
More on point, though: By deleting the file (or doing this little hack I proposed) you're still "changing your usage." It would be easier to just disable it in msconfig.
Of course, even that is fallible: Next time the app updates itself it'll be re-enabled.
I had written a long reply. But you'll just wave your arms and yell "propaganda" because, well, it's easier to label it all "propaganda" than it is to actually discuss something reasonably.
I think a cultural barrier is going to prevent us from ever really seeing eye-to-eye.
But here's my issue with you:
You fault the American people for the mistakes our Government has made. Most notably, in your last post, about Iraq.
But, when it comes to extending the "nuclear umbrella" over NATO states, when it comes to intervening in and winning "The Great Patriotic War," for these things, it's "high politics" and a selfish act.
Well, you can't have it both ways. If our country, if our people, deserve your scorn for Iraq then that means that you believe that the American people are responsible due to who we chose to elect into power.
Well, the American People could've elected in isolationist in 1940, 44, 48, 52, etc.
We could've sat idly by while Nazi's consume the people and resources of Europe for their own gain.
No matter what you want to believe Hitler, even if he'd been successful in Europe, posed no direct threat to our homeland. We weren't required to fight him to defend ourselves.
The American People chose to.
Regualar folks, middle class, middle age, middle income voters, in the voting booth, pulling the lever for a man who would continue to send our young boys to Europe to fight YOUR menace.
Regular men and women, who knew what that vote meant. Who remembered WWI, where we also fought on your behalf, who knew the sacrifice of another European war.
You say there is no act of altruism.
Well, you're wrong about that.
The only other option is that the power the American people hold is fictitious, that they were manipulated by our gov't.
Well, like I said: you can't have it both ways. If you do feel that way, then how could you hold it against us for invading Iraq?
1. You can think what you want, but can you really argue that the US Army is a quality force? "Best trained" as the OP said is a little presumptuous. Israel does a damn fine job, for example.
A well-trained force? Sure.
Best in the world? I wouldn't really know, and I don't really care.
2. It should be noted that you most likely live in an allied state (either a NATO country or one in the western hemisphere) OR an enemy/former-enemy state like the old soviet bloc.
If you live under the latter, well, I understand why you'd say such a thing.
However, if you live in the former, please consider this: The US has, for 50 years, guaranteed your safety. It may not seem like much to you. But please, consider it: We've made a treaty that says that if you're attacked by nuclear weapons that we would consider that an attack upon our own soil and retaliate as necessary.
Since the USA is not the only country in the NATO with nuclear weaponry, do keep in mind that each of the other countries in the NATO has said absoutely the same thing.
Frankly, if my country is attacked with nuclear weaponry, I don't give jack shit how you will retaliate; I'll have been incinerated and/or irradiated to the degree of absolute apathy by that point.
Furthermore, during the Cold War, it seems to me that you benefited way more from that treaty; the USSR was more likely to nuke you than us. With several European nations armed with nuclear weaponry, they were much less likely to try anything.
I don't believe in altruism in high politics; if it hadn't benefitted you and you primarily, you wouldn't have signed the treaty. Case in point: Tokyo Treaty.
BTW, your either-or logic is severely flawed: I was born in Yugoslavia, which has since fallen apart in a nasty little bunch of nasty little wars. We were neither in the Allied nor in the Soviet block, and Croatia is only now about to enter NATO. Probably.
Yugoslavia was Non-Aligned, which I still consider the best position in the dick-measuring contest you had with the Russians.
In other words, we, the American People, would deliberately involve ourselves in full nuclear exchange just to protect you and your countrymen.
Oh, puh-lease.
It's so sad to encounter people who so fervently believe their own propaganda.
What part isn't true?
Of COURSE we benefited from the treaty. We wouldn't have passed it otherwise.
But I disagree about "who would be nuked" should it have come to that.
Most likely, nobody would just, on a whim, fire off some ICBMs.
Most likely, it would be an escalation. Like: Soviet crosses the border into West Berlin, or greater West Germany, and we respond, and they respond, etc.
My point is simple: we stood beside you. You can throw stones at the people of this country. But we stood beside you. You can deride our military. But we pledged our military to protect YOU if you needed it.
We're a flawed people. But you show me one that isn't.
You can "LOL" all you'd like but it doesn't change the facts.
If you think that the Soviet Union wouldn't have kept expanding if they felt it was in their best interest then you're just fooling yourself.
If they could expand the iron curtain without fear of significant reprisal, they would have.
But the people of this country stood beside you. We stood beside you against a common foe and said "our fate is tied to yours."
This kind of long-standing alliance is rare in all of human history.
Say what you want, without the US most of Europe would be speaking either German or Russian right now.
We didn't 'save' you from either threat -- you did much of the heavy lifting yourselves -- but you weren't capable of doing it without our help.
No reason to be smug on either side. But as you cast aspersions towards the US, as you deride our idiot President and his moronic foreign and economic policies (and rightly so), remember that American dominance on its worst days is far better than Germanic or Soviet dominance on their best.
So you're implying, then, that you ARE testing each "module" in a staging environment as its developed?
And, then, I assume that if/when that module is modified, it's retested, perhaps automatically, in a staging environment for "each of the platforms it's ever going to run on."
In other words, the code that's doing all the work actually is being tested in a staging environment.
And, as it sounds, you're doing more high-level work that uses these libraries and you're committing right from dev to production.
Even that would never fly if you worked for me -- nor just about anywhere else -- but you're representing yourself as "what? testing on a stage? No reason for THAT?" even though that's precisely what the developers of the modules have done for you.
"Analogy, meet encoderer. encoderer, Analogy."
Actually, you made a metaphor. Not an analogy. And it was a bad metaphor, because HTML is not code.
For the most part I agree with you, and I think the pro-army guys upthread got their panties in a bunch for no reason whatsoever.
Even if you WERE insulting the military: Who cares? They do a great job for this country, but that's what they're paid to do. We're an all volunteer force.
Anyhoo, I will take you to task on the "rest of the world" comment.
Two things:
1. You can think what you want, but can you really argue that the US Army is a quality force? "Best trained" as the OP said is a little presumptuous. Israel does a damn fine job, for example.
2. It should be noted that you most likely live in an allied state (either a NATO country or one in the western hemisphere) OR an enemy/former-enemy state like the old soviet bloc.
If you live under the latter, well, I understand why you'd say such a thing.
However, if you live in the former, please consider this: The US has, for 50 years, guaranteed your safety. It may not seem like much to you. But please, consider it: We've made a treaty that says that if you're attacked by nuclear weapons that we would consider that an attack upon our own soil and retaliate as necessary.
In other words, we, the American People, would deliberately involve ourselves in full nuclear exchange just to protect you and your countrymen.
True enough. In fact, I had a helluva time trying to come up with a good example.
I couldn't think of one, which I suppose is a good thing.
When a bug like this does occur, tho, it can be a bitch. When it happened to me I think I ran that code under the debugger a dozen times before I found the error. It's hard to notice small changes in a complex, nested data structure.
So you're developing on, say, XP, and deploying directly to the production server without ANY staging environment?
Seriously?
You just cross your fingers and hope everything works right?
If that's the case, you really must not be working on any high-availability systems.
Furthermore, your HTML comment was a little inane. HTML is not a programming language. It's not even, generally, procedural markup. It's descriptive markup. In other words: HTML has far more in common with a data format than a programming language.
Do you not have a staging environment? Are you seriously taking code from your local box and deploying it to production machines without a staging environment?
Of course you don't need to be literally typing the code into a PC running the same OS/Stack as the production server. My production servers are mostly all Linux and I develop on an XP machine or my macbook.
But I'm not trying to RUN the code locally. I build the project to my staging sever to test....And as far as I'm concerned, this is a non-negotiable step and there's NO excuse to skip it. You don't need "new hardware." A VM Instance would work perfectly.
I worked for companies of all sizes, start-ups in 99/2000/2001, couple fourtune 500's, etc, and in 2003 I bootstrapped my own software company with a couple good friends. I've been a professional software developer for half my life.
Testing your software on its target platform before being deployed isn't an academic exercise as you eluded to w/ the "still in school." comment. There's a lot of academic theory that does not translate well to real world constraints. Methods with no more than 25 lines, single return points in functions, nearly everything involving UML, complete normalization, etc. But this isn't one of them.
First, the PHP code doesn't really make sense. Why are you passing in the $args parameter?
All this code is doing is accepting a method name, validating it as valid (yes, an Enum dt would help here), and returning it if it is.
In which case, this is much better:
if (is_callable($method)) {
return method; }
Or, more on point, you'd never even call the __call() method, you'd just call is_callable().
I think the point is to show a plausible example of PHP being "hard work like C."
I'm not a PHP apologist. It's got a lot of problems. Chief among them a glaring inconsistency that just makes an elegence-loving guy like myself cry my eyes out. But to say that it's "hard work like C" just because it retained a syntax and offers up some thin wrappers around C functions is, I believe, disingenuous.
Honestly, any IDE worth it's salt has by now solved the auto-formatter problem.
It's a by-demand feature so it's not like Word AutoCorrect. And you should be able to use a nice WYSIWYG editor to build the rules.
This is what you get, for example, in Eclipse and Visual Studio.
Personally, I like things like integrated FTP, integrated subversion, integrated unit testing, and, most of all, an integrated server-side debugger w/ all expected function: breakpoint/play/step control, stack and heap manipulation, etc.
All of these are possible using a text editor, but you need 5 different applications and none of it works together.
Not to mention: INTELLISENSE and DATA TYPE DISCOVERY! (on a loosely typed language that's a big help).
Instead of having to basically memorize or manually lookup class names, method names, and method arguments, I just begin typing the class name, use some arrow keys, and be done w/ it.
Anybody using an IDE w/out these features is fine by me, but for good measure they really should bill a customer less than those of us do that are using these tools.
You're deliberately handicapping your productivity. The customer shouldn't pay for that.
Slashdot Mirror
Wow, looks like you had a bad week. You've taken this far too seriously. Honestly, man, this is a discussion of one paradigm vs. another.
Why let it go to your head?
Life is short. You should really take the time to enjoy it more.
I'm sorry I called your view of application development "myopic." You seem to be very sensitive to polite but unequivocal criticism. Had I realized you'd be so offended, I'd have left it out.
In my opinion it really WAS a nice conversation. Maybe we can pick it up again when you're less stressed-out.
"In my experience, 99 out of 100 web apps I've seen don't qualify, especially the inhouse frameworks. It's usually simple stuff like you mentioned, which is never reused outside the company, or even within, within its lifetime cycle. So if someone new comes in, he's awed by this huge, complex, slow system, which could have been done simpler and cheaper."
I really don't mean to be pedantic.. but I'm going to be
If code is never reused, never shared between different applications, how would it even meet the definition of a framework?
Wouldn't it just be part of the application?
I work for a web retailer and we produce a large number of product-centric websites (Amazon is the web version of a "big box" store that carries everything. We're the web version of, say, Limited Brands: Separate boutique stores for each product line)
Anyway, my point is that you seem to have an awfully myopic view of things.
I mean, you assume the application/framework is "simple stuff" because the only thing I mentioned was simple.
You assume an OOD application is "huge, complex, slow" perhaps because you've seen systems that are.
You assume that writing it in procedural code would be "simpler and cheaper" without taking the long view.
And it seems to me that you're really over-estimating he overhead that object construction brings.
If an object hierarchy is properly designed, using lazy-loading, object caching, etc, you're not going to see dramatic differences. It's going to be minor. Perhaps 10%. I'd even give you 15%. Which means that the 1 second execution time of a procedural system might increase to 1.1 seconds.
Again, that 1/10 second is not ever going to matter in the vast majority of applications that aren't run on an Slashdot-like scale.
And I really believe that OOD systems are far easier (thus cheaper) to maintain and modify.
Imagine you have a Widgets table and PHB wants a new column. In a proper OO system, you add the column to the database, you find the widgets class, you add a property of the same name, you use whatever system is in place in your app to define it as loaded-lazy or loaded-default.
Then you update the unit test.
And, that's it.
The reports and forms that bind to the data model will display the new field.
The sql that populates the objects will automatically reflect the new field.
And, for example, in our framework, its even easier. You just add it to the data model and load the class using a bootstrap script from the command line and it will automatically update the DB and the unit test.
Compare that to a procedural model. Data from that modified table might exist on any number of separate pages, in any number of methods. You will have to edit numerous SQL statements, reports, forms, etc. And it's very hard to be CERTAIN that you updated it everywhere that table is called.
Anyway, it's been a nice conversation. I've enjoyed it. I've made my point clear and there's no use in repeating myself.
Have a good weekend!
"The decoupling of presentation from logic is one of the best paradigms you can use for any application."
Agreed. 100%.
And I like your take -- I suppose the web is innately MVC. But not in the sense that Rails is, and not in the sense that he meant.
We're talking more like requests come in and a simple procedural front-controller instantiates a Controller based on whatever routing rules you've defined. It creates the data models (Usually some ORM system, be it ActiveRecord or a TableGateway) and the View is going to be a templating engine of some sort.
"So for the web, it degenerates both object oriented programming and MVC into mere ways to organize your code"
That's nonsense.
If for no other reason than the fact that displaying a page often involves some real work. Some real heavy-lifting. Often far more than just a couple database queries being fed into a grid or report.
OOP brings order, structure, reuse and quality control to large, complex systems (and website/webapps can certainly be very large and very complex) That's true no matter what context it's being used in, web, rich client, whatever.
Yes, there is overhead involved in creating objects. But even in your worst-case scenario where there is no shared state, the overhead is hardly a deal breaker: It's far better to optimize for the developer than it is to optimize for the machine. Unless you're working on a website in the 99th percentile of traffic, you probably don't have a lot to worry about.
Further, your scenario IS worst-case.
For example, we have an in-house framework. It's not all that different than the ones you've seen. Take, for example, a simple web form:
You instantiate the data model (need to pre-populate the form), you instantiate a webform object, which is view-tier and is just a widget that binds to a data model and presents an HTML form.
When that form is rendered in HTML, the webform object and the data model it binds to are serialized and stored in the session.
When the user submits the form the front-controller will look at the formkey submitted with the form and unserialize the form and model objects. It pulls the values from the HTTP Post into the data model and they're validated and saved.
This is nothing revolutionary. It's not even complicated. And it's just one of a dozen ways to overcome the no-shared-state problem.
The idea that OOD is "degenerated" in a web environment is ludicrous. Procedural development is a thing of the past. The idea of 1 page : 1 script that runs from line 1 to line n is just not adequate for MOST modern web apps.
Todays systems are not your mothers web applications. We're doing far too much on the web. Applications the size of the web applications that are written today would collapse under their own weight if done procedurally.
Ok, I'll bite. What makes MVC a "piss poor model" for web applications?
The only thing you mentioned was scalability.
Personally, I find the MVC pattern applies to web apps wonderfully. Being able to "plug and play" views is far more helpful in the web universe than it is in rich client programming.
I can create a default view, lately that's been a standard XHTML interface with Ajax, usually leveraging the ext.js library.
And I also create a simplified HTML-only view for graceful degredation on clients that are not using JavaScript.
And a view for mobile interfaces.
On "data grid pages" I can plug-in a view that outputs the data in XML or Excel format.
For reporting I can create a view for an on-screen HTML based report, or I can plug in a view that displays it as a PDF or, again, XML or Excel.
Meanwhile, I only create the data models and controllers once.
This is FAR easier and faster to create and maintain.
And in todays world, unless you're a top-1% web destination it's a FAR wiser move to optimize for development time and cost than it is to optimize for the machine.
Adding a server is much cheaper than adding a developer.
Believe it or not, I'm not a fan of Rails. I'm especially not a fan of ActiveRecord. In ruby, DataMapper is a much better Db layer than is ActiveRecord.
But to denounce Rails because it's MVC? I'd love to hear why you feel that way.
Sure, but if you're using Citrix nFuse, you're already accessing any (published) app via the browser.
+1 Funny
FWIW, Inno (and other storage engines) do offer row-level locking. Only MyISAM tables are limited to table-level locking.
I'm curious.. if you're seeing 1000 t/s from a single user, what were the reasons you chose MySQL/MyISAM to begin with? (I'm genuinely interested. I'm a developer not an admin, but I do have a large set of experience with databases and datasets. My experience lies more on the capacity side than throughput. I've built systems on top of databases with billions of rows (the DNC voter history database, among others) but these systems were invariably fed millions of rows at a time by replication/dts and had very few cases of sustained transaction activity. Any given day would see millions of reads but just thousands of writes.
Very easy in nearly any modern DBMS to optimize such a system for reads. Biggest downside is the minutes needed to rebuild indices after batch-imports.
There's a few reasons:
1. Inno provides row-level locking which is what the GP mentioned when he suggested Inno. The presumption being that any table with that many rows is going to have a lot of transactional activity.
That's not always the case. In just my small slice of the world I've been involved in 2 projects that fit that bill:
One was robotic cells in a manufacturing plant where each cell was attached to a PC that, among other things, ran a MySQL/ISAM DB that recorded a near-continuous stream of data from the robot. Anywhere between 500,000 and 1,000,000 writes per day that got uploaded to an Oracle db every night along with every other robots data stream. In this case locking was not an issue because every insert came from a single client. But speed was. Because we were writing between 5 and 10 rows per second.
The second example was a read-only reporting database.
2. There is no fine line between "large" and "small." 4bn rows is unquestionably large. Likewise, anything below, say, 500k rows is unquestionably small. But that leaves an awfully large gray area.
I dunno... If i'm that coworker, even if I like you, why would I go to mgmt and argue on your behalf?
...well... I'd probably think that the guy is leaving in a couple weeks so maybe I should hire somebody who CAN.
If anything I would see it as an opportunity to demonstrate that I CAN handle things without you.
If I'm the manager and you come to me and say "You have to restore his privileges! I can't get my job done without him!"
In all seriousness, this is one of the reasons I now prefer MSSQL to Oracle: Managed Code in the DB.
Not just that it's easier: it's only easier because I know C# better than I've ever known TSQL.
But it's just a more powerful language. And it's more intuitive -- I find it easier to make self-documenting code in C# than I ever could in TSQL.
OK... perfectly valid and all, but joining on the WHERE clause?
Yuck.
(I'm just being a little snarky. Any DBMS worth it's salt will execute the same query plan as it would if you did explicit INNER JOIN in the FROM clause, but if this was a code review and you were on my team, I'd be stressing the fact that join criteria is separate from product criteria and, as such, it should be kept separate)
BUT... i did like the query.
You joke, but self joins are very powerful and useful in relational modeling.
You can start reading here: http://www.google.com/search?q=self+join&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a
You can also delete it and then create a text file and name it qttray.exe.
// recreate
It will pass the generic:
if(!exists(qttray.exe))
{
}
check but when it tries to execute it it just fails silently.
More on point, though: By deleting the file (or doing this little hack I proposed) you're still "changing your usage." It would be easier to just disable it in msconfig.
Of course, even that is fallible: Next time the app updates itself it'll be re-enabled.
That's not what the PHP code does, though... so he's not comparing apples == apples.
Perhaps he's a better Ruby developer than PHP developer.
That's understandable, but it means that maybe he isn't qualified to issue judgment on PHP.
I had written a long reply. But you'll just wave your arms and yell "propaganda" because, well, it's easier to label it all "propaganda" than it is to actually discuss something reasonably.
I think a cultural barrier is going to prevent us from ever really seeing eye-to-eye.
But here's my issue with you:
You fault the American people for the mistakes our Government has made. Most notably, in your last post, about Iraq.
But, when it comes to extending the "nuclear umbrella" over NATO states, when it comes to intervening in and winning "The Great Patriotic War," for these things, it's "high politics" and a selfish act.
Well, you can't have it both ways. If our country, if our people, deserve your scorn for Iraq then that means that you believe that the American people are responsible due to who we chose to elect into power.
Well, the American People could've elected in isolationist in 1940, 44, 48, 52, etc.
We could've sat idly by while Nazi's consume the people and resources of Europe for their own gain.
No matter what you want to believe Hitler, even if he'd been successful in Europe, posed no direct threat to our homeland. We weren't required to fight him to defend ourselves.
The American People chose to.
Regualar folks, middle class, middle age, middle income voters, in the voting booth, pulling the lever for a man who would continue to send our young boys to Europe to fight YOUR menace.
Regular men and women, who knew what that vote meant. Who remembered WWI, where we also fought on your behalf, who knew the sacrifice of another European war.
You say there is no act of altruism.
Well, you're wrong about that.
The only other option is that the power the American people hold is fictitious, that they were manipulated by our gov't.
Well, like I said: you can't have it both ways. If you do feel that way, then how could you hold it against us for invading Iraq?
A well-trained force? Sure.
2. It should be noted that you most likely live in an allied state (either a NATO country or one in the western hemisphere) OR an enemy/former-enemy state like the old soviet bloc.Best in the world? I wouldn't really know, and I don't really care.
If you live under the latter, well, I understand why you'd say such a thing.
However, if you live in the former, please consider this: The US has, for 50 years, guaranteed your safety. It may not seem like much to you. But please, consider it: We've made a treaty that says that if you're attacked by nuclear weapons that we would consider that an attack upon our own soil and retaliate as necessary.
Since the USA is not the only country in the NATO with nuclear weaponry, do keep in mind that each of the other countries in the NATO has said absoutely the same thing.
Frankly, if my country is attacked with nuclear weaponry, I don't give jack shit how you will retaliate; I'll have been incinerated and/or irradiated to the degree of absolute apathy by that point.
Furthermore, during the Cold War, it seems to me that you benefited way more from that treaty; the USSR was more likely to nuke you than us. With several European nations armed with nuclear weaponry, they were much less likely to try anything.
I don't believe in altruism in high politics; if it hadn't benefitted you and you primarily, you wouldn't have signed the treaty. Case in point: Tokyo Treaty.
BTW, your either-or logic is severely flawed: I was born in Yugoslavia, which has since fallen apart in a nasty little bunch of nasty little wars. We were neither in the Allied nor in the Soviet block, and Croatia is only now about to enter NATO. Probably.
In other words, we, the American People, would deliberately involve ourselves in full nuclear exchange just to protect you and your countrymen.Yugoslavia was Non-Aligned, which I still consider the best position in the dick-measuring contest you had with the Russians.
Oh, puh-lease.
It's so sad to encounter people who so fervently believe their own propaganda.
What part isn't true?Of COURSE we benefited from the treaty. We wouldn't have passed it otherwise.
But I disagree about "who would be nuked" should it have come to that.
Most likely, nobody would just, on a whim, fire off some ICBMs.
Most likely, it would be an escalation. Like: Soviet crosses the border into West Berlin, or greater West Germany, and we respond, and they respond, etc.
My point is simple: we stood beside you. You can throw stones at the people of this country. But we stood beside you. You can deride our military. But we pledged our military to protect YOU if you needed it.
We're a flawed people. But you show me one that isn't.
You can "LOL" all you'd like but it doesn't change the facts.
If you think that the Soviet Union wouldn't have kept expanding if they felt it was in their best interest then you're just fooling yourself.
If they could expand the iron curtain without fear of significant reprisal, they would have.
But the people of this country stood beside you. We stood beside you against a common foe and said "our fate is tied to yours."
This kind of long-standing alliance is rare in all of human history.
Say what you want, without the US most of Europe would be speaking either German or Russian right now.
We didn't 'save' you from either threat -- you did much of the heavy lifting yourselves -- but you weren't capable of doing it without our help.
No reason to be smug on either side. But as you cast aspersions towards the US, as you deride our idiot President and his moronic foreign and economic policies (and rightly so), remember that American dominance on its worst days is far better than Germanic or Soviet dominance on their best.
"Once a new module is vetted"
So you're implying, then, that you ARE testing each "module" in a staging environment as its developed?
And, then, I assume that if/when that module is modified, it's retested, perhaps automatically, in a staging environment for "each of the platforms it's ever going to run on."
In other words, the code that's doing all the work actually is being tested in a staging environment.
And, as it sounds, you're doing more high-level work that uses these libraries and you're committing right from dev to production.
Even that would never fly if you worked for me -- nor just about anywhere else -- but you're representing yourself as "what? testing on a stage? No reason for THAT?" even though that's precisely what the developers of the modules have done for you.
"Analogy, meet encoderer. encoderer, Analogy."
Actually, you made a metaphor. Not an analogy. And it was a bad metaphor, because HTML is not code.
For the most part I agree with you, and I think the pro-army guys upthread got their panties in a bunch for no reason whatsoever.
Even if you WERE insulting the military: Who cares? They do a great job for this country, but that's what they're paid to do. We're an all volunteer force.
Anyhoo, I will take you to task on the "rest of the world" comment.
Two things:
1. You can think what you want, but can you really argue that the US Army is a quality force? "Best trained" as the OP said is a little presumptuous. Israel does a damn fine job, for example.
2. It should be noted that you most likely live in an allied state (either a NATO country or one in the western hemisphere) OR an enemy/former-enemy state like the old soviet bloc.
If you live under the latter, well, I understand why you'd say such a thing.
However, if you live in the former, please consider this: The US has, for 50 years, guaranteed your safety. It may not seem like much to you. But please, consider it: We've made a treaty that says that if you're attacked by nuclear weapons that we would consider that an attack upon our own soil and retaliate as necessary.
In other words, we, the American People, would deliberately involve ourselves in full nuclear exchange just to protect you and your countrymen.
True enough. In fact, I had a helluva time trying to come up with a good example.
I couldn't think of one, which I suppose is a good thing.
When a bug like this does occur, tho, it can be a bitch. When it happened to me I think I ran that code under the debugger a dozen times before I found the error. It's hard to notice small changes in a complex, nested data structure.
So you're developing on, say, XP, and deploying directly to the production server without ANY staging environment?
Seriously?
You just cross your fingers and hope everything works right?
If that's the case, you really must not be working on any high-availability systems.
Furthermore, your HTML comment was a little inane. HTML is not a programming language. It's not even, generally, procedural markup. It's descriptive markup. In other words: HTML has far more in common with a data format than a programming language.
I ask you the same I asked downthread:
...And as far as I'm concerned, this is a non-negotiable step and there's NO excuse to skip it. You don't need "new hardware." A VM Instance would work perfectly.
Do you not have a staging environment? Are you seriously taking code from your local box and deploying it to production machines without a staging environment?
Of course you don't need to be literally typing the code into a PC running the same OS/Stack as the production server. My production servers are mostly all Linux and I develop on an XP machine or my macbook.
But I'm not trying to RUN the code locally. I build the project to my staging sever to test.
I worked for companies of all sizes, start-ups in 99/2000/2001, couple fourtune 500's, etc, and in 2003 I bootstrapped my own software company with a couple good friends. I've been a professional software developer for half my life.
Testing your software on its target platform before being deployed isn't an academic exercise as you eluded to w/ the "still in school." comment. There's a lot of academic theory that does not translate well to real world constraints. Methods with no more than 25 lines, single return points in functions, nearly everything involving UML, complete normalization, etc. But this isn't one of them.
First, the PHP code doesn't really make sense. Why are you passing in the $args parameter?
All this code is doing is accepting a method name, validating it as valid (yes, an Enum dt would help here), and returning it if it is.
In which case, this is much better:
if (is_callable($method)) {
return method;
}
Or, more on point, you'd never even call the __call() method, you'd just call is_callable().
I think the point is to show a plausible example of PHP being "hard work like C."
I'm not a PHP apologist. It's got a lot of problems. Chief among them a glaring inconsistency that just makes an elegence-loving guy like myself cry my eyes out. But to say that it's "hard work like C" just because it retained a syntax and offers up some thin wrappers around C functions is, I believe, disingenuous.
Honestly, any IDE worth it's salt has by now solved the auto-formatter problem.
It's a by-demand feature so it's not like Word AutoCorrect. And you should be able to use a nice WYSIWYG editor to build the rules.
This is what you get, for example, in Eclipse and Visual Studio.
Personally, I like things like integrated FTP, integrated subversion, integrated unit testing, and, most of all, an integrated server-side debugger w/ all expected function: breakpoint/play/step control, stack and heap manipulation, etc.
All of these are possible using a text editor, but you need 5 different applications and none of it works together.
Not to mention: INTELLISENSE and DATA TYPE DISCOVERY! (on a loosely typed language that's a big help).
Instead of having to basically memorize or manually lookup class names, method names, and method arguments, I just begin typing the class name, use some arrow keys, and be done w/ it.
Anybody using an IDE w/out these features is fine by me, but for good measure they really should bill a customer less than those of us do that are using these tools.
You're deliberately handicapping your productivity. The customer shouldn't pay for that.