Aug 31: Database Swtich (the extended version)
Due to the uproar my previous post caused (one comment on this blog qualifies), here's a quick note on the database switch and the reasons for it.
A while ago, I started renting a dedicated server with the intention of starting a small web hosting company. The cost was $118/month for a pretty beefy server that could handle everything I was planning to throw at it. At the time, I set it up with the intention of having many users. This colored the configuration significantly, since I had to secure it such that any of those users couldn't do any damage. This made the configuration a lot more complex. One way I decided to minimize complexity and potential for harm was to use sqlite as the database for anything it could. Sqlite is a pretty cool little database system that resides all in one file. It's somewhat similar to an access database without being crappy and having a big, heavy, buggy graphical interfact slapped on top of it. Also, it's simple to setup and wicked fast. By using sqlite, each site's database would just be a file that resided in their directory, as opposed to accessing traditional database server system like Postgresql, MySql, MS SQL server (yuck), or Oracle (also yuck). So, all the blogs that I setup (this one, Cyndi's, and a couple for some friends that have been abandoned) were setup to use sqlite. But, I still had a Postgresql database for the couple sites that didn't support sqlite and the email system. But now, I've decided not to do the web hosting company and am in the process of switching to a virtual private server. This basically is identical to a dedicated server, except that instead of having a box all to myself, my virtual server is housed on a server with other virtual servers. I still have full root access and so can do whatever I want with it, but the specs are a lot closer to what I'll actually need. There are also a bunch of benefits to a virtual server--stuff like the hosting company can do a full system backup by backing up the one file that is my server. But, the main benefit is that instead of $118/month, the cost is $15/month. So, I'm saving $103 a month and don't have to compromise on functionality. Anyway, while getting ready for this switch, and since I don't need to complex setup and super-secure site separation, I decided to consolidate everything onto one database system. I'm going with Postgresql since it's super powerful, all my sites, etc. will work with it, and it's centrally admined as opposed to the sqlite which is a bunch of separate files. Oh yeah, one other thing is that the upgrade process for Serendipity (the blog software I use) can't update sqlite databases with new database schema due to a less-than-full implentation of the sql standards. Over the past couple days, I've migrated all of the blogs from sqlite to postgresql. It was a relatively easy process. You can dump a sqlite database to a file like this: $> echo '.dump' | sqlite DATABASE.db > DUMPFILE The resulting file is basically ready for importing into postgres. There were just a couple gotchas that I had to overcome. The first was that sqlite defines the length of fields with type 'int' while postgresql doesn't. So, I had to do a search for int(##) and replace it with just int. Another thing was that the dump made every percent sign (%) show up as %25. That caused a ton of problems and took me a while to realize what was causing it. So, I had to do a search and replace for that, too. The last thing was that it didn't set the sequences that controlled the auto-incrementing id fields for the various tables to the right value. This caused failures when trying to insert anything into the database (entries, comments, etc.). So, for each table, I pulled the highest id using this query (in postgres): SELECT max(id) from TABLE; Then, I updated the sequence to have that as the current value, so the next time it was called, it would give the next value: SELECT setval('SEQUENCENAME', MAXID-FROM-LAST-QUERY); Once I got it all figured out, it took about 5 minutes per blog to do the whole switch. While I was at it, I went ahead and upgraded all the blogs from Serendipity version 0.9 to 1.0.1. Now that everything's on postgres, the migration to the new virtual server will be pretty easy. It would've been pretty easy beforehand, too, but now it's consistent throughout all of the sites. I guess that wasn't the 'quick note' that I thought it'd be... Aug 29: Database conversion
I've switched the database backend for furiousBlog. So, if you notice any weirdness, please let me know.
Jul 21: More blog changes
I've always wanted to put a list of the blogs and photoblogs I frequent on the sidebar, but I didn't like the various options provided by Serendipity (my blog software). Yesterday, it occured to me that I could use the del.icio.us plugin to only show a particular tag, and that I could use that for blogs and photoblogs. One benefit to that is that I only have to post the link to my del.icio.us bookmarks page (which I would've done already) and it's automatically added to furiousBlog.
So, I did that. Jul 20: New Blog Design
As you can see (unless you're reading this via RSS), I've redesigned furiousBlog. Please post a comment (include what browser you're using) if you notice any weirdness.
Update 2006-07-21: I found some weirdness when viewing the site with the oh-so-crappy Internet Explorer (shocking!). So, I had to make some changes to how the columns were positioned. I wanted the left column to extend down the entire page no matter how long it was, but that caused IE to render the right column too wide for the screen. So, I went back to my original code that made the left column stop after its contents' end. I've also done a couple other little tweaks, so if you notice anything wonky, please comment. Thanks.
« previous page
(Page 3 of 9, totaling 44 entries)
» next page
|
What I'm Doing (twitter)CategoriesSyndicate This BlogQuicksearch |