Anyone ever looked at the headers slashdot sends back on its pages?
X-Bender: Care to contribute to the Anti-Mugging-You Fund? X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. X-Bender: Oh no! Not the magnet! X-Fry: I'm never gonna get used to the thirty-first century. Caffeinated bacon? X-Fry: To Captain Bender! He's the best!...at being a big jerk who's stupid and
his big ugly face is as dumb as a butt! X-Fry: He's an animal. He belongs in the wild. Or in the circus on one of those tiny tricycles. Now that's entertainment. X-Fry: But this is HDTV. It's got better resolution than the real world.
Fun easter egg? Or a waste of 100MB in bandwidth a day?
I've used a system where the database has a version number (in a table).
We then have a script with a list of 'update commands' to run (usually SQL). Each update command has a database version attribute. It runs itself if it's version is newer than the databases. Then it updates the database version.
You could have various permutations on the implementation of this idea (we do!).
The upshot is that you'd have a script that developers could run that would perform whatever SQL DDL or DML changes are needed to get their databases into the right order.
Visit 220giftcenter for code-free dvd players.
Grab a transformer and you can even bring over your old player.
You'd be mad to bring a TV to the states, they're huge!
Get a TV that supports PAL (so you can play it with your old DVDs/Player) as well as NTSC (for your new DVDs/Player). Try here
I have a similar dilemma. But mine is what to do with my NTSC/US region DVDs when I go back to New Zealand!
Managing terabytes of data in Oracle is not such easy task. You're talking signigicant backup issues (e.g. each backup is going to be huge).
Consider putting the meta data (name, categorisation, ACL, etc) in the database and keep your files on your NetApps. The database would contain a lookup to the NetApp file.
You would gain better management, searching, integration of your data.
You would still be at risk if key NetApps filers went down. (But perhaps some kind of replication based on the database metadata could sort that out...?)
How much will a rewrite of the spec gain you? The protocol would have to be backwards compatible with all the existing clients? How would users on old clients feel about all their online buddies being reduced to numbers?
The IRC protocol has done its dash. Its time for something completely different. Something extensible, something that better reports online presense. Check out IMUnified or Jabber.org. Jabber even provides an IRC gateway (converting its native XML based protocol to the IRC protocol).
The following are some lessons I've learned the painful way. They may be of some use.
0) Do you really want to do this? Hire an expert, consult with your vendor.
1) Get the latest version of Linux. We ran into such horrible problems with Red Hat 6.0 and Oracle I still have nightmares. 6.2 works a lot better. Redhat are now selling an 'oracle8i' tuned Linux version for $2100.
2) Increase your file limits.
echo "16384" >/proc/sys/fs/file-max
echo "49152" >/proc/sys/fs/inode-max
ulimit -Hn 16384 (as root)
ulimit -n 16384 (as your db user)
From here, its standard db tuning:
3) Memory is a biggie. Make sure you have a ton. With Oracle I use the following rule of thumb: count the number of DIMM slots in your machine, multiply that by the largest DIMM size available e.g. 512Mb. You should be able to scrape by on this.
4) Disks: the more the better. Use straight disks (no raid), Raid 0, raid 1, or raid 0+1 (depending on the level of safety you need), we use 0+1. Raid 5 has a write performance impact. The Oracle redo logs are a bottleneck. We write out two copies of our log to 2 different straight disks for max performance.
5) More CPU won't hurt.
COPPA is huge. It affects nearly everyone. What web site doesn't cater to under 13 year olds? Even if you don't actively target them as your audience, are you discouraging them?
I've really been blown away by how COPPA seems to have slipped under the radar of most web sites. This is probably the first piece I've seen in the 'media' about it.
My company, Infopop, makes community software including a popular discussion forum. We made some changes to this software to make it easier for sites to comply with the COPPA regulations. And you know what? COPPA has such a low profile that a lot of customers got upset with us. They thought COPPA was something we'd made up. They had no idea that legally their sites had to be COPPA compliant come April 21st.
I have doubts about the level of COPPA compliance we'll see among web sites. Look out for some high profile 'lets make an example of them' cases in the comming months.
It uses XSL and XML to render each page. Users are able to upload their own XSL with different languages if they wish. This is the 'template' approach mentioned by many other posters. Contrary to what has been said about XSL performance however, I've found it works well.
Also, we use a database to store keyed messages in different languages. Each message is requested by key and looked up by the language of the site its being used on.
The only problem? Getting Oracle to swallow UTF-8 characters. We're having a daemon of a time. If anyone has worked with Oracle, Java and Unicode I'd love to hear from you! peter @ infopop . com
The company I work for is going a step further than skins.
We write web applications and let our users customize the HTML using XSL stylesheets. We license the XSL stylesheets we create under GPL to help encourage people to change them and swap their improvements with other users of our software. Users can upload their own XSL or select from a drop down list of currently available stylesheets.
We call this technology X-Face. X for XML, XSL, eXtensible. Face since a face is more expressive than skin. A face makes someone recognisable. And a face has character.
I've just finished adding scripting to my IRC app, Objirc Chat from Objexcel.com.
It supports the Python and Java languages, so you should be able to do some REAL coding with it - e.g. hook up to a database of info or past conversations you'd recorded, open sockets to other Internet servers, heck even use RMI for distributed programming with other Objirc client - kind of a JIT distributed.net.
I just bought 2 IBM netfinities. They're 1U, dual PIII 500, 512Mb ram, dual NIC, 2x*Gb disk. Still for $6K I was a bit surprised they came sans OS. They run Linux and NT. Great application server engines!
I am writing a servlet application to replace a large Perl app. The Perl app has performance problems and scalability issues. It is also proving difficult to maintain and enhance.
Some of these problems could have been fixed with a redesign of the perl code (such as using a database to manage all the data we have).
The replacement app uses database access, XML, XSL, business rules, etc. It also has to support thousands of sites.
I've chosen to implement the replacement with Java servlets. Specifically I'm using Apache JServ, with MySQL as the database (soon to be Oracle). JServ11b3 performance is now on a par with the other servlet engines (they did some work with thread re-use). But more critically it is hardware scalable (i.e. you can cluster a bunch of machines together to increase your throughput). The Tomcat project (www.jakarta.apache.org) will also be an implementation to look out for.
I've posted some material on servlet and Perl performance on my web site at Working Java. This includes a comparison of Perl to Servlet performance in a real life application.
There are also a set of 'pure' helloworld benchmarks for Perl, Servlets, PHP, etc on lots of different hardware at..... (the URL escapes me, anyone?)
As the other posters have pointed out, your choice will depend on your requirements.
For a simpler problem I may have gone with a simpler solution: Perl or PHP. (Actually I probably wouldn't becuase I'm comfortable/productive in the Java environment, but someone who was into Perl may do).
I can vouch for a trouble-free time developing with servlets, lots of reference material, good implemetations of the spec to choose from, acceptable performance (and scalable across hardware), a productive environment, decent maintenance prospects (how does the joke go? Java is WORA - write once run anywhere. Perl is WO - write once and never understand again.
If you are interested in taking a first hand look at python - maybe even using it for a real application - check out http://objexcel.com
It features Objirc Chat a Java IRC client with Python (and Java) scripting built in.
I've had several queries from students whose assignment was to 'write a chat client in Java'. It seems to be CS101's most common project. Instead, I'd argue they should be using an existing framework and add something new.
I'm replacing some perl code with Java servlets using mySQL, Apache JServ, XML and XSL.
Apache JServ allows load balancing (basically doing a round robin over each of your servlet engines). I've found performance goes up about 30% for each PC you throw into the mix (I've only been able to test this up to 3 PCs).
FYI: I've found I needed servlet engines running on 2 PC's connected to 1 mySQL database to reach the performance of the perl app which stores its data as | delimited files.
While this may seem pretty poor, using a database means that the scalability (for size of data) is going to be a lot better than the file solution and the servlet solution used XSL which gives us a lot more flexibility over the HTML that we generate (basically each one of our users can have a completely different looking site while running the same app as all the others).
I'll be posting some benchmarks at http://objexcel.com in a few days if anyone is interested.
Slashdot Mirror
Anyone ever looked at the headers slashdot sends back on its pages?
...at being a big jerk who's stupid and
X-Bender: Care to contribute to the Anti-Mugging-You Fund?
X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank.
X-Bender: Oh no! Not the magnet!
X-Fry: I'm never gonna get used to the thirty-first century. Caffeinated bacon?
X-Fry: To Captain Bender! He's the best!
his big ugly face is as dumb as a butt!
X-Fry: He's an animal. He belongs in the wild. Or in the circus on one of those tiny tricycles. Now that's entertainment.
X-Fry: But this is HDTV. It's got better resolution than the real world.
Fun easter egg? Or a waste of 100MB in bandwidth a day?
I've used a system where the database has a version number (in a table).
We then have a script with a list of 'update commands' to run (usually SQL). Each update command has a database version attribute. It runs itself if it's version is newer than the databases. Then it updates the database version.
You could have various permutations on the implementation of this idea (we do!).
The upshot is that you'd have a script that developers could run that would perform whatever SQL DDL or DML changes are needed to get their databases into the right order.
Visit 220giftcenter for code-free dvd players. Grab a transformer and you can even bring over your old player. You'd be mad to bring a TV to the states, they're huge! Get a TV that supports PAL (so you can play it with your old DVDs/Player) as well as NTSC (for your new DVDs/Player). Try here I have a similar dilemma. But mine is what to do with my NTSC/US region DVDs when I go back to New Zealand!
Managing terabytes of data in Oracle is not such easy task. You're talking signigicant backup issues (e.g. each backup is going to be huge).
Consider putting the meta data (name, categorisation, ACL, etc) in the database and keep your files on your NetApps. The database would contain a lookup to the NetApp file.
You would gain better management, searching, integration of your data.
You would still be at risk if key NetApps filers went down. (But perhaps some kind of replication based on the database metadata could sort that out...?)
I'll second SlickEdit. You get to configure the JDK it uses for things like building and javadocing your project.
Code formatting is great.
It supports method completion, though not perfectly for me if inner classes are involved.
It supports (color coding, some completion stuff) non-java file types like C#, HTML, xsl.
It supports macros (which I don't use)
It supports various "views" of your project: file based, class based, etc.
It does _not_ have a debugger. For that I use the excellent bugseeker from www.karmira.com
How much will a rewrite of the spec gain you? The protocol would have to be backwards compatible with all the existing clients? How would users on old clients feel about all their online buddies being reduced to numbers?
The IRC protocol has done its dash. Its time for something completely different. Something extensible, something that better reports online presense. Check out IMUnified or Jabber.org. Jabber even provides an IRC gateway (converting its native XML based protocol to the IRC protocol).
The following are some lessons I've learned the painful way. They may be of some use. 0) Do you really want to do this? Hire an expert, consult with your vendor. 1) Get the latest version of Linux. We ran into such horrible problems with Red Hat 6.0 and Oracle I still have nightmares. 6.2 works a lot better. Redhat are now selling an 'oracle8i' tuned Linux version for $2100. 2) Increase your file limits. echo "16384" >/proc/sys/fs/file-max echo "49152" >/proc/sys/fs/inode-max ulimit -Hn 16384 (as root) ulimit -n 16384 (as your db user) From here, its standard db tuning: 3) Memory is a biggie. Make sure you have a ton. With Oracle I use the following rule of thumb: count the number of DIMM slots in your machine, multiply that by the largest DIMM size available e.g. 512Mb. You should be able to scrape by on this. 4) Disks: the more the better. Use straight disks (no raid), Raid 0, raid 1, or raid 0+1 (depending on the level of safety you need), we use 0+1. Raid 5 has a write performance impact. The Oracle redo logs are a bottleneck. We write out two copies of our log to 2 different straight disks for max performance. 5) More CPU won't hurt.
Yawn
COPPA is huge. It affects nearly everyone. What web site doesn't cater to under 13 year olds? Even if you don't actively target them as your audience, are you discouraging them?
I've really been blown away by how COPPA seems to have slipped under the radar of most web sites. This is probably the first piece I've seen in the 'media' about it.
My company, Infopop, makes community software including a popular discussion forum. We made some changes to this software to make it easier for sites to comply with the COPPA regulations. And you know what? COPPA has such a low profile that a lot of customers got upset with us. They thought COPPA was something we'd made up. They had no idea that legally their sites had to be COPPA compliant come April 21st.
I have doubts about the level of COPPA compliance we'll see among web sites. Look out for some high profile 'lets make an example of them' cases in the comming months.
I've developed software that is to be used with multiple languages.
You can see the software running at http://beta.infopop.net.
It uses XSL and XML to render each page. Users are able to upload their own XSL with different languages if they wish. This is the 'template' approach mentioned by many other posters. Contrary to what has been said about XSL performance however, I've found it works well.
Also, we use a database to store keyed messages in different languages. Each message is requested by key and looked up by the language of the site its being used on.
The only problem? Getting Oracle to swallow UTF-8 characters. We're having a daemon of a time. If anyone has worked with Oracle, Java and Unicode I'd love to hear from you! peter @ infopop . com
The company I work for is going a step further than skins.
We write web applications and let our users customize the HTML using XSL stylesheets. We license the XSL stylesheets we create under GPL to help encourage people to change them and swap their improvements with other users of our software. Users can upload their own XSL or select from a drop down list of currently available stylesheets.
We call this technology X-Face. X for XML, XSL, eXtensible. Face since a face is more expressive than skin. A face makes someone recognisable. And a face has character.
I'm employing people to work with (amongst other) Linux systems. Check our jobs page for positions managing a Linux NOC, Java/XML/XSL/Oracle developers.
It supports the Python and Java languages, so you should be able to do some REAL coding with it - e.g. hook up to a database of info or past conversations you'd recorded, open sockets to other Internet servers, heck even use RMI for distributed programming with other Objirc client - kind of a JIT distributed.net.
Any interested developers, please check it out.
I just bought 2 IBM netfinities. They're 1U, dual PIII 500, 512Mb ram, dual NIC, 2x*Gb disk. Still for $6K I was a bit surprised they came sans OS. They run Linux and NT. Great application server engines!
Which is the better tool for server side web development?
Maybe there is more to choosing a web development environment than mod_perl vs perl?
(Expecting to get at least the 2 points for this post that the above flame got)
Some of these problems could have been fixed with a redesign of the perl code (such as using a database to manage all the data we have).
The replacement app uses database access, XML, XSL, business rules, etc. It also has to support thousands of sites.
I've chosen to implement the replacement with Java servlets. Specifically I'm using Apache JServ, with MySQL as the database (soon to be Oracle). JServ11b3 performance is now on a par with the other servlet engines (they did some work with thread re-use). But more critically it is hardware scalable (i.e. you can cluster a bunch of machines together to increase your throughput). The Tomcat project (www.jakarta.apache.org) will also be an implementation to look out for.
I've posted some material on servlet and Perl performance on my web site at Working Java. This includes a comparison of Perl to Servlet performance in a real life application.
There are also a set of 'pure' helloworld benchmarks for Perl, Servlets, PHP, etc on lots of different hardware at ..... (the URL escapes me, anyone?)
As the other posters have pointed out, your choice will depend on your requirements.
For a simpler problem I may have gone with a simpler solution: Perl or PHP. (Actually I probably wouldn't becuase I'm comfortable/productive in the Java environment, but someone who was into Perl may do).
I can vouch for a trouble-free time developing with servlets, lots of reference material, good implemetations of the spec to choose from, acceptable performance (and scalable across hardware), a productive environment, decent maintenance prospects (how does the joke go? Java is WORA - write once run anywhere. Perl is WO - write once and never understand again.
If you are interested in taking a first hand look at python - maybe even using it for a real application - check out http://objexcel.com
It features Objirc Chat a Java IRC client with Python (and Java) scripting built in.
I've had several queries from students whose assignment was to 'write a chat client in Java'. It seems to be CS101's most common project. Instead, I'd argue they should be using an existing framework and add something new.
I'm replacing some perl code with Java servlets using mySQL, Apache JServ, XML and XSL.
Apache JServ allows load balancing (basically doing a round robin over each of your servlet engines). I've found performance goes up about 30% for each PC you throw into the mix (I've only been able to test this up to 3 PCs).
FYI: I've found I needed servlet engines running on 2 PC's connected to 1 mySQL database to reach the performance of the perl app which stores its data as | delimited files.
While this may seem pretty poor, using a database means that the scalability (for size of data) is going to be a lot better than the file solution and the servlet solution used XSL which gives us a lot more flexibility over the HTML that we generate (basically each one of our users can have a completely different looking site while running the same app as all the others).
I'll be posting some benchmarks at http://objexcel.com in a few days if anyone is interested.
Peter