How do you think you're going to get talented people to become teachers, if the pay is so much worse than their other options? All of the smartest teachers I know have either left or are thinking about leaving because the pay is so bad.
The MySQL scaling problems you're describing are due to using MyISAM tables for an OLTP application. Don't do that. They're fine for read-mostly applications, but the locking is not efficient enough for more. Use InnoDB tables for OLTP apps. The InnoDB tables use an multi-version concurrency control approach just like Postgres does.
If you ask them to submit code samples, you'll get people who are either incredibly anal or look for shortcuts.
Where are you getting this from? I always ask for code samples because then I have something technical to discuss with the person. It works very well. If they send in lousy code, that tells me they don't understand what good coding style is. I don't care much what the code does, and it doesn't need to be more than a couple pages out of a larger project. I just want to get them to talk about the decisions they made when writing this code. It's not even a problem when people bring in code that they just worked on after it was originally written by someone else, as long as they can talk intelligently about why the code is done the way it is and demonstrate some depth of knowledge about the language.
I've often seen people try to split it up this way: dev creates the software, sysadmins (or IT or operations or whatever your company calls it) owns it after deployment. It seems logical to have people who are responsible for overseeing the network and machines, and having them install and run all the software on those machines sounds reasonable too.
In practice though, this has always led to a very adversarial relationship. The sysadmins probably don't know much about how the software works, so they end up having trouble with it and cursing the developers for making such impossible software. Very few dev shops have the resources to make software so polished that a person can run it without bothering to learn how it works. It costs tons of money to make software that easy to run.
And maybe that's the crux of the problem: handing off a technology to a different group is hard. It's easier for a group to own a piece of software through its whole lifecycle than to try to throw it over a wall at some point.
Lately, all of the interviews I read that talk about how things are run at the big Internet companies -- Google, Yahoo, Amazon -- talk about how they make the developers responsible for maintaining their software in production. The developers have a lot of personal investment in seeing their software work, so having them maintain it makes sense. The sysadmins take care of the network, the OS-level maintenance, and the hardware.
The only company where I saw this tried was also the most successful at keeping a solid and well-maintained production setup. It still had some friction between groups (DBAs vs. programmers, etc.) but a lot less than in other places.
If anyone has pointers to more reading about the production/maintenance practices of successful software companies, I'd certainly like to see them.
The Java CMSes you named are fine. The problem is that you aren't looking for a CMS. A CMS is just a platform for publishing static articles. What you want is an interactive community site. Things like Roller are more along the lines of what you're asking for.
Sorry to break it to that PostgreSQL fan, but MySQL has had ACID transactions for years now, and it's still faster than PostgreSQL for average web app queries. Time to stop making excuses based on half-truths about ancient versions of MySQL and just acknowledge that MySQL is fast.
I remember times when Amazon.com and Google.com were not fully available. And I certainly remember times when they weren't fully available *to me*, like last night when my terrible ISP had problems. Access to these services is not reliable.
I can't imagine why you would change the type of a table in a running application.
There are some uses for multiple table types. One convenient use is for data warehousing. You can make the read-only data warehouse use MyISAM tables, which have low overhead, and keep your main database in ACID-compliant InnoDB tables.
So your complaint is that MySQL is too configurable? And you don't like the default configuration? Most Slashdot readers could name a few dozen pieces of software they feel that way about. The fact remains, MySQL can be very similar to PostgreSQL for those who want it to be.
The older table type in MySQL, MyISAM, doesn't handle concurrency well. The InnoDB table type uses the same locking approach as PostgreSQL and Oracle, and should stand up to multiple users much better.
Since MySQL has a very complete set of features at this point, it almost certainly DOES do everything they need. If they aren't using advanced SQL features, you can't blame it on MySQL anymore.
Java compiles to bytecode, but people still call it a compiled language. The only difference is that Perl doesn't keep the intermediary format around on disk afterward. I would agree though that the distinction between compiled and interpreted is less clear and less important than it was in the past. The main point is that these other languages compile to an intermediary format and Ruby doesn't, which contributes to it being slower than the rest.
Sure, I realize that it gets compiled to an intermediary format, not to machine code, but it still makes a huge difference. The way Ruby lags behind the others in performance is frequently discussed on blogs and mailing lists. Ruby does not currently compile to bytecode, although according to Wikipedia this is planned for an upcoming release. Wikipedia also says that Python is compiled to bytecode.
Re:Rails rocks (but isn't a silver bullet)
on
Exploring Active Record
·
· Score: 3, Informative
I don't know about Python, but Perl and more recent versions of PHP are not interpreted. They are compiled to opcodes and then the opcodes are executed. With a persistent environment like mod_perl, you are always running the compiled code after the inital load. Both of them have much better base language performance than Ruby does at this point. I expect that Ruby will eventually work this way too.
Slashdot Mirror
How do you think you're going to get talented people to become teachers, if the pay is so much worse than their other options? All of the smartest teachers I know have either left or are thinking about leaving because the pay is so bad.
Only 8% comes from government funding.
The MySQL scaling problems you're describing are due to using MyISAM tables for an OLTP application. Don't do that. They're fine for read-mostly applications, but the locking is not efficient enough for more. Use InnoDB tables for OLTP apps. The InnoDB tables use an multi-version concurrency control approach just like Postgres does.
If you ask them to submit code samples, you'll get people who are either incredibly anal or look for shortcuts.
Where are you getting this from? I always ask for code samples because then I have something technical to discuss with the person. It works very well. If they send in lousy code, that tells me they don't understand what good coding style is. I don't care much what the code does, and it doesn't need to be more than a couple pages out of a larger project. I just want to get them to talk about the decisions they made when writing this code. It's not even a problem when people bring in code that they just worked on after it was originally written by someone else, as long as they can talk intelligently about why the code is done the way it is and demonstrate some depth of knowledge about the language.
I've often seen people try to split it up this way: dev creates the software, sysadmins (or IT or operations or whatever your company calls it) owns it after deployment. It seems logical to have people who are responsible for overseeing the network and machines, and having them install and run all the software on those machines sounds reasonable too.
In practice though, this has always led to a very adversarial relationship. The sysadmins probably don't know much about how the software works, so they end up having trouble with it and cursing the developers for making such impossible software. Very few dev shops have the resources to make software so polished that a person can run it without bothering to learn how it works. It costs tons of money to make software that easy to run.
And maybe that's the crux of the problem: handing off a technology to a different group is hard. It's easier for a group to own a piece of software through its whole lifecycle than to try to throw it over a wall at some point.
Lately, all of the interviews I read that talk about how things are run at the big Internet companies -- Google, Yahoo, Amazon -- talk about how they make the developers responsible for maintaining their software in production. The developers have a lot of personal investment in seeing their software work, so having them maintain it makes sense. The sysadmins take care of the network, the OS-level maintenance, and the hardware.
The only company where I saw this tried was also the most successful at keeping a solid and well-maintained production setup. It still had some friction between groups (DBAs vs. programmers, etc.) but a lot less than in other places.
If anyone has pointers to more reading about the production/maintenance practices of successful software companies, I'd certainly like to see them.
The Java CMSes you named are fine. The problem is that you aren't looking for a CMS. A CMS is just a platform for publishing static articles. What you want is an interactive community site. Things like Roller are more along the lines of what you're asking for.
Nope. InnoDB tables are faster than PostgreSQL for simple queries.
Sorry to break it to that PostgreSQL fan, but MySQL has had ACID transactions for years now, and it's still faster than PostgreSQL for average web app queries. Time to stop making excuses based on half-truths about ancient versions of MySQL and just acknowledge that MySQL is fast.
I remember times when Amazon.com and Google.com were not fully available. And I certainly remember times when they weren't fully available *to me*, like last night when my terrible ISP had problems. Access to these services is not reliable.
"Are self-describing XML documents flowing around inside your service-oriented architecture?"
With MySQL 5 you don't have to worry about that either.
InnoDB tables are very fast. It is accurate to describe MySQL as fast and ACID-compliant.
I can't imagine why you would change the type of a table in a running application.
There are some uses for multiple table types. One convenient use is for data warehousing. You can make the read-only data warehouse use MyISAM tables, which have low overhead, and keep your main database in ACID-compliant InnoDB tables.
So your complaint is that MySQL is too configurable? And you don't like the default configuration? Most Slashdot readers could name a few dozen pieces of software they feel that way about. The fact remains, MySQL can be very similar to PostgreSQL for those who want it to be.
It's not "musch slower." Try it.
The older table type in MySQL, MyISAM, doesn't handle concurrency well. The InnoDB table type uses the same locking approach as PostgreSQL and Oracle, and should stand up to multiple users much better.
Strict type checking and triggers are both in MySQL 5, which has been out for a while now. You need to update your complaints.
And this is somehow Perl's fault? You could call it bash-syndrome or Ruby-syndrome just as easily.
In addition, MySQL has just about everything that a normal user could ask for from a database. The feature disparity is just not very large anymore.
Since MySQL has a very complete set of features at this point, it almost certainly DOES do everything they need. If they aren't using advanced SQL features, you can't blame it on MySQL anymore.
Since I switched to Ruby on Rails, I can develop fusion powered spacecraft in half the time! With no code at all! And it all tests itself!
Java compiles to bytecode, but people still call it a compiled language. The only difference is that Perl doesn't keep the intermediary format around on disk afterward. I would agree though that the distinction between compiled and interpreted is less clear and less important than it was in the past. The main point is that these other languages compile to an intermediary format and Ruby doesn't, which contributes to it being slower than the rest.
Sure, I realize that it gets compiled to an intermediary format, not to machine code, but it still makes a huge difference. The way Ruby lags behind the others in performance is frequently discussed on blogs and mailing lists. Ruby does not currently compile to bytecode, although according to Wikipedia this is planned for an upcoming release. Wikipedia also says that Python is compiled to bytecode.
I don't know about Python, but Perl and more recent versions of PHP are not interpreted. They are compiled to opcodes and then the opcodes are executed. With a persistent environment like mod_perl, you are always running the compiled code after the inital load. Both of them have much better base language performance than Ruby does at this point. I expect that Ruby will eventually work this way too.
Verizon DOES charge for incoming text messages unless you pay the monthly fee for unlimited messages.