I just booked a hotel, which is something I don't do terribly often.
And while researching hotels on the wonderfully informative, horrendously designed TripAdvisor I found someone mentioning easytobook.com.
Off I went, and I was very pleasantly surprised. I ended up booking through them. It was easy.
And I got a very good deal. I recommend it.
I still haven't quite talked myself into using Twitter but I suppose I'm inching towards it.
Today I ran across a really cool use of the service, but one that also shows the flaw in its enforced brevity: Swiss rail delays are posted at http://twitter.com/oev.
This is a great idea, and apparently the PR folks at Burson-Marsteller had something to do with it. The only problem is that the cornerstone of Twitter is a 140-character limit on posts ("tweets" to the kids).
So you get things like this:
Zwischen Ramsei und Langnau auf der Linie Burgdorf - Langnau ist die Strecke für den Bahnverkehr un... #sbb #cff #ffs...which translates loosely as "Between Ramsei and Langnau on the Burgdorf-Langnau line, train traffic is un..."
Of course you could always hire a programmer to condense all that into txt-ese bt nobdy likes u thn. Or you could break it into multiple "tweets," but that breaks the paradigm.
Instead, I think Twitter should allow longer "tweets" in cases where all of the following conditions are met:
Traffic reports of all kinds would qualify. Updates from your political party, television show, or church would not.
WordPress is nice, but setting up a local instance in a nonstandard environment is more trouble than it's worth. WordPress was designed for shared-hosting environments that have a classic "LAMP" application stack preconfigured (Linux+Apache+MySQL+PHP). It was specifically not designed to run on a wide variety of server environments.
Fortunately, for the kind of work I want to do (blog template design) there are acceptable workarounds. But this latest encounter with the MySQL and PHP ecosystems has left me, once again, sorely tempted to just build my own blogging system.
Read on if you want to geek out on some of the details. If you just want the conclusion, it is: use a standard virtual machine (VM) or set up a sandbox blog in a shared environment. Either one of those will work well enough, and the VM approach is probably the closest you'll get to a "safe" install. Unless you're being paid for the setup time, I strongly advise against trying to make it work locally in anything but a stock configuration.
A while ago I set up a blog with a friend of mine: Migratorium. It's an outlet for our travel writing, or at least it will be.
It runs on WordPress in a shared-hosting environment over at Dreamhost: bang, meet buck, at least for small projects. I really like the WordPress user interface, but even with great templates like veryplaintxt I quickly became frustrated with the design possibilities.
In short, you have to learn some PHP (painful but not so hard) and the arcane, under-documented WordPress templating system (ditto) in order to do any meaningful design. Since I already know HTML, CSS, Perl, and Template Toolkit, I thought I'd be much happier building my own sites using those technologies. And it would keep me away from PHP, which I dislike, and MySQL, which I abhor.
Then I thought about setting up an RSS feed. No biggie, just another afternoon. Then I thought about setting up a decent editing UI. No biggie, just another weekend. Then I thought about making it easy for my non-computer-geek friends to use. Uh-oh... that started to sound like real work.
So I decided to make at least one serious effort to teach myself enough WordPress Templatese to either do serious design in that ecosystem or give it up from an informed position. And for that I need a local copy of WordPress in which to hack the templates.
I'm doing this on an Intel Mac running the latest version of Leopard (OS X 10.5.5 as of this writing). I use lighttpd as my local web server and would prefer to use that, but I will use the built-in Apache if I must. I have MacPorts installed, but I would prefer to run this under the system default PHP. I also want this to run on SQLite if at all possible, since I want to hack templates, not databases.
Oh-oh. The first thing I found is that only MySQL is supported, as WordPress doesn't have a database abstraction layer. That's a shame, but it seems like an absolute.
There is one plug-in that gets you close: PDO, but its limitations make it sound just about as onerous for my purposes as MySQL itself.
OK, let's see if this can be done with minimal exposure to MySQL. 2 tablespoons has some instructions for getting MySQL running under MacPorts. That almost worked, but not quite. Following more info under the comments I found I had to set the socket file in /opt/local/etc/mysql5/my.cnf:
[mysqld_safe]
socket = /tmp/mysql.sock
[mysqld]
socket = /tmp/mysql.sock
I also had to create the run directory:
sudo mkdir -p /opt/local/var/run/mysql5
Now I was able to start the system, but everything complained
about the socket file location. I fixed that in my aliases in
.bash_profile:
# evil mysql is required for local wordpress
alias mysql5='mysql5 --socket=/tmp/mysql.sock'
alias mysqladmin5='mysqladmin5 --socket=/tmp/mysql.sock'
alias mysqlstart='sudo /opt/local/bin/mysqld_safe5 &'
alias mysqlstop='/opt/local/bin/mysqladmin5 -u root -p shutdown \
--socket=/tmp/mysql.sock'
Backgrounding your startup command with & is
a Very Bad Practice but it seems like that's what mysqld
wants; I may be using the wrong command altogether.
Also note that you will almost certainly have to set
that socket location explicitly in other commands/configs as
well. Once you have the above aliases in effect don't forget to
set your MySQL "root" password (not to be confused with the system
root password). Press RETURN at the Password prompt, or enter
whatever the previous password was.
mysqladmin5 -u root -p password MYSECRETPW
At this point I'm able to connect to the database server with mysql5 and issue some simple commands, so I consider it done-ish after about two hours of work. Further tweaks will be listed below.
This little exercise is already confirming my various prejudices against MySQL and PHP and all sloppy engineering everywhere in the universe. But man, I do love that editing UI. Must... persist! Thank you Xarmant Txakolina!
I'd actually gotten far enough to have the PHP running, more or less, though without valid HTTP headers and without a successful database connection. And then I hit the php-cgi wall. Turns out you have to install from source, the standard install doesn't work properly with lighttpd.
Fortunately Simplistic Complexity had a helpful blog post.
Unfortunately that doesn't work with MySQL installed via MacPorts.
I tried a few of the obvious tweaks to the make process and realized I would have to reinstall MySQL. And that's where I hit the wall.
Having spent most of the day on this and gotten very close, I had to ask myself: Is it worth it to push on through?
Since I make software for a living I'm always tempted to put on my Big Fat Engineer's Hat and complain about the quality gaps in whatever piece of software I'm pounding my head against at the moment. But that wouldn't be even close to fair in the WordPress case: here is a product I really like as long as I don't have to look under the hood; and its content-management UI is frankly more usable than any equivalent thing I've ever built, and even if it is finicky on the server side I think the proof of its value is in the client experience.
I love WordPress for its content-management UI, and there's no special reason why its installation prerequisites or developer documentation should be tailored to my needs. If I cared that much I could contribute to the project, or fork it, or write my own.
So in the interest of fairness to a justly popular blogging system, and also in the interest of my own sanity, I gave up on my little snowflake of a local WordPress installation.
Instead, I'll try it their way and see if I can make some headway with the templates. A lot of generous people have given a lot of their time to this open-source product, and I still hold onto the hope that I can more easily beef up my WordPress templates than use (or write) a different blogging system.
I think the most sensible thing to do now is install a VMWare image with a recent version of WordPress. It looks like rPath has one.
That has the advantage of still being more or less "local" even if a bit resource-intensive; and if it doesn't work, it's always possible to just set up a sandbox WordPress account with an obfuscated URL.
I'll be sure to update the blog with the results of that operation when I have time for it.
One of the blogs I read all the time is TechCrunch: it covers the high-tech startup scene.
You could argue that it's more than a blog since it's a full-fledged business with multiple partner sites and paid writers, but I still think of it as a blog because if its focus on immediacy. Everything is reported fast and off-the-cuff, with even the more ponderous, essay-like posts obviously written in haste.
As I was looking at it today I started wondering how big, in terms of data size and bandwidth, a site like that is. The answer: almost two megabytes for the home page.
Folks, that is a lot. Yahoo's front page, which also takes a long time to load and is also full of Flash adverts, clocks in at 445K today. The chart view on Google Finance, which has light ads but very heavy (and feature-rich) Flash, is 680K.
I'm not trying to pick on TechCrunch here: the fact is that the acceptable size of any web page has grown phenomenally in the last year or so. As an iPhone user and a Web developer I find the trend worrisome.
Of course you want to make the page as rich as possible for the user, and of course you want to maximize your ad revenue. But you have to balance that against a fundamental aspect of usability: if the page takes too long to load, or puts too great a burden on low-power devices, you are leaving a lot of potential users out in the cold.
For my part, I plan to take page size and load time very seriously in my next Web project. I doubt I'll be able to hit my Web 1.0 gold standard of 15K per page, since a decent JavaScript toolkit and a bit of Google Analytics already breaks the 100K barrier, but it's still an important consideration.
(As for TechCrunch specifically, they're very good about publishing a full RSS feed. I read that on my phone most of the time, and read the site a bit during the day since there are often embedded videos and links to other heavyweight sites that aren't as usable on a mobile device.)
It seems the iPhone is finally available in Hungary.
The bad news is that the local T-Mobile goonery thinks it's a good idea to bleed the heavy users for data charges.
This is so short-sighted it's comical: you have the one and only revolutionary convergence device in your stores, and you're trying to make an extra buck (Forint) on any unsuspecting schmuck who uses it as intended.
Being more than fair, let's look at the option with the most data, which will cost you about $90 plus tax, more or less what you would pay in America.
That gives you 4GB "data traffic" included in the price -- so we should probably assume that includes all data, Web and Mail and app and SMS and GPS and whatever else might touch the network, in both directions. Go over that and it's 0.1 HUF per 10 kilobytes.
Honestly, I think I wouldn't hit the 4GB border in a month, and I probably use my iPhone on the 3G or Edge network a bit more than average for a late-30s professional but probably a lot less than a teenager would (WiFi doesn't count towards the limit).
So how much money is that really? Let's assume you use 6GB per month, which would seem to be 50% more than T-Mobile thinks the average user would (giving them the benefit of the doubt here on ethics, even at the risk of credulity).
Let's assume they think a GB is 1000 x 1000 KB, which is incorrect but almost certainly the calculation they'd use. That means your extra 2GB are an extra 4,000MB or an extra 4,000,000 kilobytes which is 400000 10KB chunks at 0.1 HUF per.
OK, now you owe the Germans 40,000 HUF. That's about $200.00 US, a bit more than tripling your bill. For exceeding the limit by half in one month at today's (favorable) dollar rate.
This is exactly what smells bad about the arrangement. T-Mobile says 4GB is fine -- but that burns fast if you're much into YouTube, and if their prices were honest they'd be spotting you the equivalent of $400.
We know that's not the case. We know, in fact, that this is a regressive price structure directly aimed at teenagers whose parents will bail them out the first time, much to T-Mobile's benefit.
Make no mistake: business users like me won't get caught by this ruse. We're unlikely to get close to the limit, we're likely to pay attention to the contract, and we can write it off and correct the course if we go a little bit over. But the kids are not going to be so attentive, and they're also vastly more likely to spend a lot of time on YouTube and other data-intensive applications; and further, they're most likely to opt for the $50/mo plan which only gives them 2GB before the evil kicks in. That means a user in the above scenario could see a $500 monthly bill when they expected to pay $50.
This cost structure is a direct and aggressive attempt to exploit the naive and young among T-Mobile's new customer base. To take advantage of those who want to bring the future into their pockets, and who want to pay T-Mobile a hundred bucks a month for the privelege.
Shame on you, Hamid Akhavan. You had a chance to take the moral high ground, and you're fucking your customers instead. Specifically, you're fucking your customers with families..