Yes, being in the same process is very helpful! That is, until you have to scale your website. Uh oh, you have maxed out your server. Okay, you buy a bigger server. Time passes. Congratulations, your site is very successful and you max it out! Too bad your now-popular app is riddled with assumptions that come from all requests being inside the same process.
Learn from the big guns of websites -- scale horizontally. Frontend proxies load balancing across multiple backend servers. Redundancy and scalability. Definitely don't assume all of a user's requests will come to the same server. For goodness sake, though, don't start out fundamentally limited in your potential scale.
I agree with everything you're saying -- my post was aimed at naive serialization as a file saving format, not at more complex forms of serialization.
Most languages, though, that have serialization routines don't give you the flexibility inherently you're mentioning here; they don't version objects or data and they just plop them in data structures (or, maybe, noticing they aren't format matches and exploding, but definitely not offering much in the way of recoverability).
The "serialization pattern" isn't much of a pattern really; I mean, it comes down to 'object knows how to save and restore itself' -- whether or not you use operator overloading or subclass Serializable, it's the same basic idea. My point was against implementing the pattern poorly, not the pattern being bad itself; I certainly agree the object should be responsible for persisting and restoring its state (well, in most cases). It's all in the details. Sadly, serialization (esp naive serialization) as quick and easy ways to persist data without really addressing the real-world concerns that tend to pop up.
The core of my point was: don't rely on other people to solve your complex problems for you, which I think you would agree with:)
Don't rely on naive serialization. Don't rely on some magical infrastructure doing all the hard work for you. Why? Because there are subtleties involved.
Ever play a game that had bugs, and they made a patch to fix it but the patch made your old savegames not work anymore? Serialization at work, in one form or another.
Objects change over time. Don't back yourself into a wall by requiring nonchanging datastructures in order to read old saved files. Then you get to a point where you have to destroy saved files or not add a feature/bug fix.
Serialization is cute and sometimes works, but you should know its limitations.
True, but id3cp works fine with copying the tags to those files. The reference implementations of flac properly skip them, but it isn't guaranteed to have that behavior. I've not actually tested ogg's but I would bet it behaves fine there as well; definitely could use improvement in the script, though... patches welcome!
This is the script I use. Wrote it a while back for basically the same reasons -- record everything in FLAC, convert to lossy format of the week. I originally used a bash script but found it to be a bit less than robust and somewhat more difficult to extend.
This script either takes command line args, or, if none present, reads filenames one at a time from the command line. Generally I run it via 'find -name "*.flac" | transcode' and let it DTRT. As an added bonus, it copies the id3 tags from src to dest (assuming id3cp is installed)
Though it really depends on what kind of system you're trying to make, generally speaking, embedding any serious amount of code into code in a different language often becomes very difficult to maintain. For quick things, it's usually the easiest. For moderately complex things, it's usually a push either way. But for any sizeable website, especially one that is going to be maintained over an extended period of time by multiple people, keeping as much -separate- as possible is a better approach.
Whether you use ASP, JSP, TT, Mason,.NET, or anything else, you likely will have a lot more going on than simply displaying some simple words, maybe wrapped in some kind of if statement or while loop. You'll need to do some kind of data lookup, perform some kind of transformation of that data, apply a few business rules, then, finally, spit it out in HTML. By far, it is easier to maintain code that isn't mixed with html; like wise, it's easier to maintain html that isn't mixed with code. Plus you then have the option of using that same code to manipulate the data differently, perhaps a GUI application, set of command line utilities, or under a different embedding technology. Decoupling presentation from logic is always a win as complexity increases.
Mason is terrific technology, though, and I'm very glad to see a book dedicated to it finally on the market. It is especially good to finally see some quality documentation on application frameworks that run under mod_perl; before now, there wasn't much besides the excellent wrapmod book and the equally excellent mod_perl cookbook.
Due to popular demand, Skipjack ISOs are also available on Red Hat Network, just as other ISOs are (ie, subject to the same restrictions, meaning Paid Basic service or higher).
Use RPMs. Store your doctree in CVS and have a script/makefile that will do exports and create a CVS image from it. Do the same with code so that static and dynamic code both get proper, versioned treatment. This makes it very easy to revert to known good configurations, etc. The downside is you have to have root access on the web server. I can speak from practice in saying this works quite well, especially if you have staging/QA environments to test on. Simply roll the RPM, test it, and if it passes, push the same RPM live.
I wonder how the major labels will divvy it up among all of their artists.
Oh wait, they practically don't do that as it is when it comes to actual CD sales.
It would be nice if Napster came up with some kind of plan for independant artists and smaller labels. Something based on volume, maybe. And perhaps some kind of micropayment system, who knows.
I'm one of those people who buys more CDs because of Napster. I don't mind paying for music. I just wish more of it made it to the artists and not to the corporations.
sprintf(buf, "...%80s...", badstr) will happily pull more than 80 characters from badstr. You really want to use snprintf, though it isn't supported identically on various platforms -- check the manpage.
Read this if you want to learn considerably more about safe usage of strncpy/cat/etc:
Given that a G400MAX is the fastest 3D card under Linux at the moment (going by GLX performance), this is great news. Even NVidia's latest GeForce GLX drivers don't compare on a GeForce SDR to the G400. I expected to see the GeForce dominate once the NVidia drivers were out, but on a P3 500 the G400MAX was over twice as fast[1] as a GeForce SDR on an Athlon 600 at quake3 (something like 55 fps for the G400, 25 for the Geforce).
Matrox is further increasing their lead in linux with moves like this. Once DualHead is in place and XFree86 4.0 with DRI support is out, I can't see any other company providing drivers as reliable or as fast for a long time. It takes time to ramp up expertise on a new platform, and by using Open Source/GLX drivers, Matrox will almost certainly be a step ahead for a long time to come.
[1] - Now in Windows the G400MAX doesn't beat the GeForce, which shows the GeForce Linux drivers are severely limited. With time this will improve, assuming NVidia keeps up with their pledge to support XFree86 and Linux and releases specs so that other developers can contribute in meaningful ways.
Online relationships can work. Some people find a lot of happiness through them.
BUT THAT DOESN'T GIVE EVERY LONELY GEEK ON THE NET FREEDOM TO GO HARASS EVERYONE HE THINKS IS FEMALE IN AN ATTEMPT TO GET WHAT HE WANTS!
Having a lot of mud experience, I can say with certainty that there are a LOT of idiotic children out there who treat members of the opposite sex with incredible rudeness. How many women out there use male names in public forums to avoid unwanted attention?
Don't go sending obscene messages, ICQs, mudtells, or whatever to ANYONE. If you're interested in someone, propositioning them for cybersex just isn't going to get you anywhere except a long term relationship with spanky and his five friends.
Treat ladies with respect. Don't say or do anything you wouldn't do in real life in person in front of them. Behave. Treat them with respect, kindness, and understanding. Most of all, just be yourself. No one ever had a succesful longterm relationship pretending to be someone they're not.
The server went down with a power outage. It's a linux box (for those who are curious) with enough memory and CPU time to burn. If anything gets slashdot'd, it would be the pipe...
Slashdot Mirror
Yes, being in the same process is very helpful! That is, until you have to scale your website. Uh oh, you have maxed out your server. Okay, you buy a bigger server. Time passes. Congratulations, your site is very successful and you max it out! Too bad your now-popular app is riddled with assumptions that come from all requests being inside the same process.
Learn from the big guns of websites -- scale horizontally. Frontend proxies load balancing across multiple backend servers. Redundancy and scalability. Definitely don't assume all of a user's requests will come to the same server. For goodness sake, though, don't start out fundamentally limited in your potential scale.
I agree with everything you're saying -- my post was aimed at naive serialization as a file saving format, not at more complex forms of serialization.
:)
Most languages, though, that have serialization routines don't give you the flexibility inherently you're mentioning here; they don't version objects or data and they just plop them in data structures (or, maybe, noticing they aren't format matches and exploding, but definitely not offering much in the way of recoverability).
The "serialization pattern" isn't much of a pattern really; I mean, it comes down to 'object knows how to save and restore itself' -- whether or not you use operator overloading or subclass Serializable, it's the same basic idea. My point was against implementing the pattern poorly, not the pattern being bad itself; I certainly agree the object should be responsible for persisting and restoring its state (well, in most cases). It's all in the details. Sadly, serialization (esp naive serialization) as quick and easy ways to persist data without really addressing the real-world concerns that tend to pop up.
The core of my point was: don't rely on other people to solve your complex problems for you, which I think you would agree with
Don't rely on naive serialization. Don't rely on some magical infrastructure doing all the hard work for you. Why? Because there are subtleties involved.
Ever play a game that had bugs, and they made a patch to fix it but the patch made your old savegames not work anymore? Serialization at work, in one form or another.
Objects change over time. Don't back yourself into a wall by requiring nonchanging datastructures in order to read old saved files. Then you get to a point where you have to destroy saved files or not add a feature/bug fix.
Serialization is cute and sometimes works, but you should know its limitations.
True, but id3cp works fine with copying the tags to those files. The reference implementations of flac properly skip them, but it isn't guaranteed to have that behavior. I've not actually tested ogg's but I would bet it behaves fine there as well; definitely could use improvement in the script, though... patches welcome!
This is the script I use. Wrote it a while back for basically the same reasons -- record everything in FLAC, convert to lossy format of the week. I originally used a bash script but found it to be a bit less than robust and somewhat more difficult to extend.
This script either takes command line args, or, if none present, reads filenames one at a time from the command line. Generally I run it via 'find -name "*.flac" | transcode' and let it DTRT. As an added bonus, it copies the id3 tags from src to dest (assuming id3cp is installed)
http://perl.pattern.net/transcode
Though it really depends on what kind of system you're trying to make, generally speaking, embedding any serious amount of code into code in a different language often becomes very difficult to maintain. For quick things, it's usually the easiest. For moderately complex things, it's usually a push either way. But for any sizeable website, especially one that is going to be maintained over an extended period of time by multiple people, keeping as much -separate- as possible is a better approach.
.NET, or anything else, you likely will have a lot more going on than simply displaying some simple words, maybe wrapped in some kind of if statement or while loop. You'll need to do some kind of data lookup, perform some kind of transformation of that data, apply a few business rules, then, finally, spit it out in HTML. By far, it is easier to maintain code that isn't mixed with html; like wise, it's easier to maintain html that isn't mixed with code. Plus you then have the option of using that same code to manipulate the data differently, perhaps a GUI application, set of command line utilities, or under a different embedding technology. Decoupling presentation from logic is always a win as complexity increases.
Whether you use ASP, JSP, TT, Mason,
Mason is terrific technology, though, and I'm very glad to see a book dedicated to it finally on the market. It is especially good to finally see some quality documentation on application frameworks that run under mod_perl; before now, there wasn't much besides the excellent wrapmod book and the equally excellent mod_perl cookbook.
Due to popular demand, Skipjack ISOs are also available on Red Hat Network, just as other ISOs are (ie, subject to the same restrictions, meaning Paid Basic service or higher).
s os.pxt
The URL is:
https://rhn.redhat.com/network/channel/download_i
Sorry for the delay, folks. Enjoy the beta!
The next official release of Red Hat Linux will also be made available vial the above page on the day of release, under the same terms.
Use RPMs. Store your doctree in CVS and have a script/makefile that will do exports and create a CVS image from it. Do the same with code so that static and dynamic code both get proper, versioned treatment. This makes it very easy to revert to known good configurations, etc. The downside is you have to have root access on the web server. I can speak from practice in saying this works quite well, especially if you have staging/QA environments to test on. Simply roll the RPM, test it, and if it passes, push the same RPM live.
Wrong.
1 .. .
0.101001000100001000001000000100000001000000000
That isn't rational, but it doesn't contain the number 2 in it anywhere.
Not all irrational numbers contain every arbitrary sequence of digits.
--
I wonder how the major labels will divvy it up among all of their artists.
;)
Oh wait, they practically don't do that as it is when it comes to actual CD sales.
It would be nice if Napster came up with some kind of plan for independant artists and smaller labels. Something based on volume, maybe. And perhaps some kind of micropayment system, who knows.
I'm one of those people who buys more CDs because of Napster. I don't mind paying for music. I just wish more of it made it to the artists and not to the corporations.
Heh, maybe that's blasphemy around here
--
sprintf(buf, "...%80s...", badstr)
will happily pull more than 80 characters from badstr. You really want to use snprintf, though it isn't supported identically on various platforms -- check the manpage.
Read this if you want to learn considerably more about safe usage of strncpy/cat/etc:
http://www.usenix.org/events/usenix99/full_papers/ millert/millert_html/
Ayup, most likely.
Given that a G400MAX is the fastest 3D card under Linux at the moment (going by GLX performance), this is great news. Even NVidia's latest GeForce GLX drivers don't compare on a GeForce SDR to the G400. I expected to see the GeForce dominate once the NVidia drivers were out, but on a P3 500 the G400MAX was over twice as fast[1] as a GeForce SDR on an Athlon 600 at quake3 (something like 55 fps for the G400, 25 for the Geforce).
Matrox is further increasing their lead in linux with moves like this. Once DualHead is in place and XFree86 4.0 with DRI support is out, I can't see any other company providing drivers as reliable or as fast for a long time. It takes time to ramp up expertise on a new platform, and by using Open Source/GLX drivers, Matrox will almost certainly be a step ahead for a long time to come.
[1] - Now in Windows the G400MAX doesn't beat the GeForce, which shows the GeForce Linux drivers are severely limited. With time this will improve, assuming NVidia keeps up with their pledge to support XFree86 and Linux and releases specs so that other developers can contribute in meaningful ways.
Online relationships can work. Some people find a lot of happiness through them.
BUT THAT DOESN'T GIVE EVERY LONELY GEEK ON THE NET FREEDOM TO GO HARASS EVERYONE HE THINKS IS FEMALE IN AN ATTEMPT TO GET WHAT HE WANTS!
Having a lot of mud experience, I can say with certainty that there are a LOT of idiotic children out there who treat members of the opposite sex with incredible rudeness. How many women out there use male names in public forums to avoid unwanted attention?
Don't go sending obscene messages, ICQs, mudtells, or whatever to ANYONE. If you're interested in someone, propositioning them for cybersex just isn't going to get you anywhere except a long term relationship with spanky and his five friends.
Treat ladies with respect. Don't say or do anything you wouldn't do in real life in person in front of them. Behave. Treat them with respect, kindness, and understanding. Most of all, just be yourself. No one ever had a succesful longterm relationship pretending to be someone they're not.
Chip
The server went down with a power outage. It's a linux box (for those who are curious) with enough memory and CPU time to burn. If anything gets slashdot'd, it would be the pipe...
It's up now.
Chip