funny, I got sick of the slow ass rendering and opened up firebug. I took all the stuff that took the longest to load and blocked it in squid. (the JS stuff seems to be the worst) and it loads really quick now.
It's sort of funny to see 'Mainframes are teh expensive' argument. I miss the old days of slashdot when more then 20% of folks knew there was more to computers then 'hello world' and javascript.
You can run all kinds of modern software on a mainframe. You get anything linux can run, but outside of linux you can use java, websphere, DB/2, IMS, messaging (MQ on a mainframe is amazing).
Yeah, you can use RPG, COBOL, PL/1 and that other crap. but why would you =-)
iSeries aren't as good for a reason. If you can buy a mini instead of a Mainframe then you won't buy the mainframe. VM on a real mainframe has been doing what these folks have come up with forever. with sysplex you get multiple machines, kick ass uptime, and multiple OSes like VM, Zos, linux, shit, you can run your OS from the 70s on it if you want.
yeah, it costs an craptastic amount of money, but if you have the cash and need the uptime....
Just a couple of things dude, - JFS was in AIX way before it was in OS/2. - The NUMA stuff from sequent never had anything to do with OS/2, they ran their own unix OS.
I liked OS/2 back in the day. However you must realize that there are NO 'large parts' of OS/2 that have been open sourced.
You know, I used to work on an application that had > 200 stored procedures and it was a pain in the ass. SQL is a crappy procedural language. SPs work really good for a set of problems, but using them for more then the simplest of business logic gets you a horrid pile of crud.
No offense to you, but that is wrong. If you have a good client library prepared statements are faster and safer. A good client library will know how to escape things correctly for a the database it speaks to. It's not always as simple as adding \ to ' and ". If your client library sucks, well then your DB probably isn't that great either.
Most mature coders realize that there are times when it's just better to use proven code, and this is one of them.
On a related note, java makes using prepared statements easy (even easier when you use JDBCTempate in spring). You configure your datasource to cache the prepared statements and you pay the compile price once.
JDBCTemplate in spring is just
template.query("select count(*) from foo where user = ?",new Object[]{'bob'});
When you structure your code correctly and use transactions, you won't get the crap strewn all over.
De-normalization can really give you a speed boost when your doing 10's of millions of inserts a day with tables > 80 - 100 million rows in them, that need millisecond response time for updates and queries. Joins are a killer once your DB gets huge, even if the data is partitioned.
why don't connection pools get more love around here? If you have any high volume site, you save quite a bit of CPU overhead by re-using the connection. Plus, your database doesn't take a dump when your site gets slammed.
I realize shitty j2ee apps may have something to do with the bad rep, but a well managed connection pool saves you so much trouble when your application is complex.
I work in a large bank. believe me, things are controlled more then you can know.
There's so much red tape and CYA crap it takes forever to get changes in. Maybe some stupid little web application that has the rent a coder type working on it is lax, I assure you the real systems at my employer that handle the money are tightly controlled.
I just to make sure everybody realizes this about JMS/MQ: the DB is for storage not for routing. The message brokers like DBs because ones with proper transaction support makes it easier on them. It's easy to determine the message got stored in the queue if the database insert succeeded. After the insert, send the ack to the sender. Otherwise, they'd have to save the message, take some checksum, and make sure it got written ok before sending the ack.
Getting back to his blog entry, yes, it's lame. I can draw from my experience on why it's a bad idea. I used to work on an application where the manager didn't trust messaging at all. we had a bunch of daemons polling a database, we used it as a router! We had several parts of our system that depended on events and to know if those events happen, we had to poll the database. This works ok for low load, but once the load went up, it killed us. We had lots of processes constantly bugging the DB for work, which generated locks, which blocked other stuff, etc... I re-wrote some of the stuff form C to java and changed some of the notification to use sockets instead of table notification. That one part scaled much better.
This was a situation where messaging (JMS/MQ/whatever you like) shines, because your processes just sit in a sleep state until something they care about happens.
exactly. I've written some very complicated threaded programs in java. The java.util.concurrent package has some really nice abstractions that make it much easier.
I don't get all the dissing of threads around here (my 5 or so years of experience with threads are in the java world). with a little planning, they are not that hard to program. It almost sounds like the folks that couldn't understand pointers now matter how many different ways you explained them.
Yeah, i'm an old mofo. I've worked professionally for a while. You refute what I said with I don't "get it". You really didn't refute my claim that a full ajax web client is dumb.
I've used ajax type techniques in many projects. I know what it does well, and what it doesn't.
I'm assuming that your talking about sites where the user never submits data. Using no serverside validation on user input is completely retarded, just ask slashdot what happened when they didn't scrub the input from their users for javascript.
GWT and other frameworks can only take you so far, it still has to get rendered by the client, which once again, most have crappy slow dom and javascript implementations. GWT doesn't do shit for a user once it's reached the browser. Once there, it's a bunch of javascript and HTML.
Not using browser cache is retarded. If you are writing your ajax sites in a way that doesn't use the no-cache headers for all the requests, your more clueful then most. Most full ajax sites don't, and it's really lame.
Finally, you admitted you didn't have the ability to make a simple, dynamic PHP site fast. that's where my comment about learning came in. As much as I hate PHP, even the most crappy PHP code I've seen is somewhat fast.
Seriously, server side web apps are where you write serious apps that actually do more then display a couple of photos of your dog.
sounds good, except you may or may not know that a lot of javascript implementations are sloooow. not to mention you usually have to set the no cache headers for everything in the page so your javascript works right.
I find that sites built with the method you describe are the asshole sites that fuck with browser history, disable the back button, try to disable the context menu, and those dumb ass tricks to get around the fact they don't know how to write proper server side code.
There's no reason you can't make a fast serverside site (with ajax too, that works without the stupid tricks I described above), if you can't I suggest you educate yourself, or don't use a wallmart PC for production use.
I've personally written many J2EE webapps (no EJB BS, spring & struts & jsp/velocity) that where very fast, with proper coding you can let the browser cache stuff so it constantly doesn't have to refetch crap. when you do this, all you push down to the client is the HTML to render, which browsers are really good at doing quickly.
the cost of your network getting broken into and having customer credit card numbers leaked is much larger then hiring some intern to move your software to a secure environment.
We had some guy from a local college in my last job do that. he'd come in and maintain the braindead cold fusion apps every other quarter.
dude, just drop the dumbasses that insist on old versions of PHP. Offer to help them move, but if the clowns won't move, your going to pissing money away when your server gets pwned by some stupdid script kiddy.
do what most businesses do, drop the customers that you lose money on.
Slashdot Mirror
funny, I got sick of the slow ass rendering and opened up firebug. I took all the stuff that took the longest to load and blocked it in squid. (the JS stuff seems to be the worst) and it loads really quick now.
The big deal with static typing is it is easier on others when you leave for your next programming adventure. Maintainability by others is a big deal.
Python is nice, by the way. I'm sort of trying to learn it in my spare time, enough to start using jython at work.
ascii porn isn't the best idea for an easter egg
not to nickpick, but hey it's slashdot =-)
>>Crap hardware support? Who cares - you're running numerical calculations, not a bloody game on some tossy video card.
He's talking about interconnect.
>>Crap vendor support? This vendor will have been given full support by Microsoft, and will be equally supportive of their users.
Think about expertise. 5 out of 500 compared with > 400 in the same area. where do you think most of the vendor experience will be in HPC?
>>Stability? If you're not dealing with odd hardware / crappy drivers, Windows Server versions are actually fairly stable.
I'll give you that. windows on a server has gotten a lot better.
It's sort of funny to see 'Mainframes are teh expensive' argument. I miss the old days of slashdot when more then 20% of folks knew there was more to computers then 'hello world' and javascript.
You can run all kinds of modern software on a mainframe. You get anything linux can run, but outside of linux you can use java, websphere, DB/2, IMS, messaging (MQ on a mainframe is amazing).
Yeah, you can use RPG, COBOL, PL/1 and that other crap. but why would you =-)
iSeries aren't as good for a reason. If you can buy a mini instead of a Mainframe then you won't buy the mainframe. VM on a real mainframe has been doing what these folks have come up with forever. with sysplex you get multiple machines, kick ass uptime, and multiple OSes like VM, Zos, linux, shit, you can run your OS from the 70s on it if you want.
yeah, it costs an craptastic amount of money, but if you have the cash and need the uptime....
Fair enough. however the parent claimed that JFS started on OS/2 which is false. The original JFS was AIX specific.
Just a couple of things dude,
- JFS was in AIX way before it was in OS/2.
- The NUMA stuff from sequent never had anything to do with OS/2, they ran their own unix OS.
I liked OS/2 back in the day. However you must realize that there are NO 'large parts' of OS/2 that have been open sourced.
You know, I used to work on an application that had > 200 stored procedures and it was a pain in the ass. SQL is a crappy procedural language. SPs work really good for a set of problems, but using them for more then the simplest of business logic gets you a horrid pile of crud.
So, it's better to have a stored procedure for every select you do?
No offense to you, but that is wrong. If you have a good client library prepared statements are faster and safer. A good client library will know how to escape things correctly for a the database it speaks to. It's not always as simple as adding \ to ' and ". If your client library sucks, well then your DB probably isn't that great either.
Most mature coders realize that there are times when it's just better to use proven code, and this is one of them.
On a related note, java makes using prepared statements easy (even easier when you use JDBCTempate in spring). You configure your datasource to cache the prepared statements and you pay the compile price once.
JDBCTemplate in spring is just
template.query("select count(*) from foo where user = ?",new Object[]{'bob'});
When you structure your code correctly and use transactions, you won't get the crap strewn all over.
De-normalization can really give you a speed boost when your doing 10's of millions of inserts a day with tables > 80 - 100 million rows in them, that need millisecond response time for updates and queries. Joins are a killer once your DB gets huge, even if the data is partitioned.
why don't connection pools get more love around here? If you have any high volume site, you save quite a bit of CPU overhead by re-using the connection. Plus, your database doesn't take a dump when your site gets slammed.
I realize shitty j2ee apps may have something to do with the bad rep, but a well managed connection pool saves you so much trouble when your application is complex.
it's a mega corp that has both.
the red tape here could of choked andre the giant.
I work in a large bank. believe me, things are controlled more then you can know.
There's so much red tape and CYA crap it takes forever to get changes in. Maybe some stupid little web application that has the rent a coder type working on it is lax, I assure you the real systems at my employer that handle the money are tightly controlled.
I just to make sure everybody realizes this about JMS/MQ: the DB is for storage not for routing. The message brokers like DBs because ones with proper transaction support makes it easier on them. It's easy to determine the message got stored in the queue if the database insert succeeded. After the insert, send the ack to the sender. Otherwise, they'd have to save the message, take some checksum, and make sure it got written ok before sending the ack.
Getting back to his blog entry, yes, it's lame. I can draw from my experience on why it's a bad idea. I used to work on an application where the manager didn't trust messaging at all. we had a bunch of daemons polling a database, we used it as a router! We had several parts of our system that depended on events and to know if those events happen, we had to poll the database. This works ok for low load, but once the load went up, it killed us. We had lots of processes constantly bugging the DB for work, which generated locks, which blocked other stuff, etc... I re-wrote some of the stuff form C to java and changed some of the notification to use sockets instead of table notification. That one part scaled much better.
This was a situation where messaging (JMS/MQ/whatever you like) shines, because your processes just sit in a sleep state until something they care about happens.
exactly. I've written some very complicated threaded programs in java. The java.util.concurrent package has some really nice abstractions that make it much easier.
I don't get all the dissing of threads around here (my 5 or so years of experience with threads are in the java world). with a little planning, they are not that hard to program. It almost sounds like the folks that couldn't understand pointers now matter how many different ways you explained them.
BI, business intelligence? ha ha ha
that's like slashdot editor
nuke power has the problem of having to store dangerous waste products long term.
that's a crappy problem too.
Yeah, i'm an old mofo. I've worked professionally for a while. You refute what I said with I don't "get it". You really didn't refute my claim that a full ajax web client is dumb.
I've used ajax type techniques in many projects. I know what it does well, and what it doesn't.
I'm assuming that your talking about sites where the user never submits data. Using no serverside validation on user input is completely retarded, just ask slashdot what happened when they didn't scrub the input from their users for javascript.
GWT and other frameworks can only take you so far, it still has to get rendered by the client, which once again, most have crappy slow dom and javascript implementations. GWT doesn't do shit for a user once it's reached the browser. Once there, it's a bunch of javascript and HTML.
Not using browser cache is retarded. If you are writing your ajax sites in a way that doesn't use the no-cache headers for all the requests, your more clueful then most. Most full ajax sites don't, and it's really lame.
Finally, you admitted you didn't have the ability to make a simple, dynamic PHP site fast. that's where my comment about learning came in. As much as I hate PHP, even the most crappy PHP code I've seen is somewhat fast.
Seriously, server side web apps are where you write serious apps that actually do more then display a couple of photos of your dog.
sounds good, except you may or may not know that a lot of javascript implementations are sloooow. not to mention you usually have to set the no cache headers for everything in the page so your javascript works right.
I find that sites built with the method you describe are the asshole sites that fuck with browser history, disable the back button, try to disable the context menu, and those dumb ass tricks to get around the fact they don't know how to write proper server side code.
There's no reason you can't make a fast serverside site (with ajax too, that works without the stupid tricks I described above), if you can't I suggest you educate yourself, or don't use a wallmart PC for production use.
I've personally written many J2EE webapps (no EJB BS, spring & struts & jsp/velocity) that where very fast, with proper coding you can let the browser cache stuff so it constantly doesn't have to refetch crap. when you do this, all you push down to the client is the HTML to render, which browsers are really good at doing quickly.
DNS cache is your friend.
also, just point to a faster DNS servers. it's not hard at all to configure.
the cost of your network getting broken into and having customer credit card numbers leaked is much larger then hiring some intern to move your software to a secure environment.
We had some guy from a local college in my last job do that. he'd come in and maintain the braindead cold fusion apps every other quarter.
dude, just drop the dumbasses that insist on old versions of PHP. Offer to help them move, but if the clowns won't move, your going to pissing money away when your server gets pwned by some stupdid script kiddy.
do what most businesses do, drop the customers that you lose money on.