Category Archives: general

kindle in freezer bag

Amazon Kindle: how I read in the bath

12 Replies

I love my Amazon Kindle. It cost £109 and for that has changed the way I read. It’s lightweight, slim, and tactile. The battery life is amazing, mainly because the Kindle doesn’t need much power. Its display is not backlit, making it appear far more like paper, and therefore easier on the eye.

It has one main use: for reading books. To my mind it does that one thing brilliantly.

An advantage of the Kindle over real books is that you can carry hundreds of books with you more or less wherever you go. Notice I said ‘more or less’. Let’s face it, for those of us who enjoy a good soak in a lovely hot, deep bath, reading in the bath is part of the ritual. Books don’t mind if they get a bit soggy. Even if you drop the whole book in the bath (as I’ve done a few times) they still seem to dry out. And if they really are ruined, well it’s only a few quid lost.

Sadly water and electrical things don’t mix so well. But to me the Kindle seemed somehow robust enough that it didn’t seem implausible to be able to read it in the bath if it were protected in some way. I’d never, never even consider allowing an iPad anywhere near water. There are in fact waterproof cases and bags available commercially for Kindles, but when you think about it these are little more than (semi)waterproof bags. They don’t need to be completely waterproof, just splashproof.

So that’s when I thought about using a standard zip-lock freezer bag. Ok I wouldn’t want to read my Kindle underwater with one, but it’d at least be splashproof. Below is a photo of my Kindle, with a freezer bag I’ve used a few times for reading in the bath.

kindle in freezer bagNothing special, just a zip-lock freezer bag. Oh, and I made sure it had at least one side completely see-through: freezer bag manufacturers have a habit of printing logos etc on their bags. Fine for freezing food, not fine for reading through.

One of my concerns was actually condensation on the inside, not water on the outside. However this didn’t seem to be a problem at all. I just tried to get most of the air out of the bag before I sealed it. I also put a small wad of paper tissue in the bag with the Kindle to help absorb any condensed water that might collect. However I’ve never noticed any dampness at all inside, so the paper is just a precaution.

So there you go. That’s how I got to reading my Kindle in the bath.

Of course, normal disclaimers apply. I’ve outlined how I read my Kindle in my bath with my freezer bags. If you want to try it with your own Kindle and freezer bags (and in your own bath!), well it’s a free world… But you do so completely at your own risk in the knowledge that if it all goes horribly wrong you’ll have to fork out £109/£149 for a new Kindle. And much wailing and gnashing of teeth.

It was a risk I thought worth taking. I found that by exercising some caution and trying to keep the Kindle+freezer bag as dry as was reasonable, I was finally able to read my Kindle in the bath.

Hoorah!

Review of Panic’s Coda – One-Window Web Development for Mac OS X

12 Replies

I’ve recently been trialling Coda, Panic’s web development environment for Mac OSX. It currently costs $99 (about £65 at current rates) per licence, and offers a fully-featured 15-day trial before you burn your money. The version I’m looking at here is 1.6.2.

Coda sells itself as offering a complete environment for all-round web developers: somewhere to do your coding, a css tool for the design-oriented, and built-in subversion, FTP and SSH tools to transfer your masterpieces from your localhost to your live environment. In other words… an IDE (although it’s perhaps telling that it never uses that acronym in its sales pitch).

Coding
Coda offers a passable pure coding environment. It has all the basic text editing things: fancy colours, a certain amount of text completion and insertion (e.g. comment blocks). I don’t want to bore you with a list all the small details I found wanting in its text editor. Some of the bigger issues I had were lack of diff tool, and the inability to search across an entire project (or ‘site’ in Coda-speak). On the plus-side the editor did have a nice visual list of functions in your code. Macromate’s TextMate is often compared to Coda (a not entirely fair comparison, but anyway…), and to be honest in terms of code editing offers lots of things Coda doesn’t, and all the things Coda does. So, take your pick…

Styling
The css editor is pretty much what you get from tools like MacRabbit’s CSSEdit. You get to edit your css with a user-interface rather than hand-coding the stuff. That’s pretty much it. I’m left wondering just how useful Coda’s CSS tool is. If you’re proficient in CSS then do you really need a GUI to help you? If you’re not proficient in CSS then you’ll still be confused because Coda assumes you have some knowledge of how HTML and CSS work together. It’s a kind of irritating half-way house which I suppose might make life easier for half-way-house developers. I’m not sure.

FTP/SSH
One of the really nice things about Coda is that you can fiddle around with a local copy of your website and FTP it up to your live hosting account, all in a simple, integrated way. When you alter a file a little icon appears next to it in Coda’s file browser. Just click it, and off it goes. It really is very simple and easy to understand. So it has the same feature if you’re working in a more serious environment, where SSH is the only way to transfer? Erm… nope.

No quick-and-easy scp-equivalent? Let’s just stop here and digest what Coda’s all about. Those of you wondering what scp is will probably be ok with Coda. Those of you who know will probably realize that Coda’s aimed primarily at semi-pro developers who need to access hosting accounts with FTP. If you work in a professional environment where servers are locked down to such an extent that SSH is probably your only means of access, well one of Coda’s main selling points is lost.

To be fair there is an SSH terminal. My feelings are that this has been bundled to make Coda look more professional and justify a higher price-tag. Why is it any easier to click a button in Coda taking you to the terminal, than it is to switch to a terminal in a different window? Cmd-Tab? At best you might consider it a very, very minor advantage. At worst it confuses Coda and makes you wonder whether it’s trying to pitch itself at semi-pro or at professional developers. Is it for the Rails and Symfony developers out there? Who knows.

Preview window
Coda’s preview window lets you see your webpage as it would appear in a browser. Well, actually it shows you how you web page does appear in a browser, because the preview window is basically just a browser window. Again, I’m left asking the question: Cmd-Tab? Personally I found it more useful to analyze my CSS changes in Firefox + Firebug. Note too that the idea that you can review a single page of your website as a complete entity is a very out-dated and curiously amateurish one. The idea that ‘blah.php’ as a file actually renders a page of HTML is verging on the laughable: there will typically be dozens of files involved in rendering a single web page. Any serious (PHP) web developer would surely be using either home-grown code developed in a framework such as Symfony, or would be modifying available web apps such as Drupal or WordPress. The only way to view a ‘page’ in any vaguely sophisticated web app is to view it in a browser with a web server running. All this makes Coda’s preview window largely defunct. Once again, just Cmd-Tab to Firefox or something. Is it really that hard to do?

Subversion
A big selling point of Coda has been its inclusion of some kind of version control mechanism for your code. In this case subversion. The user interface is nice, although a little basic. Any checked-out code will display little icons next to the file name in the file browser. If you’ve made a change, you’ll see a little ‘M’ icon appear next to the file, which you can click to commit to the repository. It’s all very neat and rather lovely.
This does seem to be one area of Coda that works well. You will have to rely on terminal svn commands for some things, but most day-to-day stuff can be done very neatly and easily. Incidentally, TextMate includes very similar functionality. It doesn’t have the useful icons to let you know when something is out of sync with the repository, so for me Coda’s svn scores a point over TextMate here.

Conclusion
Coda looks lovely, and feels like something designed for semi-pro web developers. I can’t imagine hard-core designers and CSSers finding it particuarly useful, and hard-code programmers and coders won’t find its text-editing functionality up to scratch compared to much cheaper/free tools like TextMate, JEdit, or Eclipse. The preview window and SSH terminal features feel like a bolt-on, and honestly you’d have to be pretty lazy to find Cmd-Tabbing to another application much harder than pressing a button on Coda’s UI. The lack of integrated scp functionality will be annoying for many developers.

Coda costs $99, and could be a really useful value-for-money tool for semi-professional web developers who appreciate the convenience of having almost-TextMate, almost-CSSEdit, almost-web-browser, and SSH terminal thrown into one eye-candy package. Dreamweaver it ain’t. For starters Coda it has none of the HTML-building capability of Dreamweaver.

For about half the cost of Coda you can buy TextMate, CSSEdit, and use Firefox and an SSH terminal. Ok, you have to switch between them which is a slight inconvenience. But you do get more functionality for less cost. At the end of the day it’s all about what you’re comfortable with as a developer.

iPhone 2.2 and how not to build a user-interface

Leave a reply

Am I totally brain-dead? Or am I just getting old and no longer able to cope with technology?

Probably both. Whatever the answers, these questions popped into my addled mind this morning after I’d excitedly updated my iPhone’s software from 2.1 to 2.2. “Excited” is perhaps too strong a word, but I was hoping for some new iPhone features to play with for 10 mins or so.

I’d heard about street view coming to the iPhone. Although we don’t yet have this for UK cities, it’s still fun to play around with. So where was this bright new iPhone future? I mean, you go into maps… and… no new buttons. Nothing saying ‘press for street view’, no options saying ‘turn on street view’.

Apple’s site in fact proudly announces the arrival of street view to the iPhone. There are photos of it there, and it’s working on their demo phone. What about on my phone?! I was clearly missing something obvious and had just become an Old Man overnight.

So after half an hour of searching on google I find some blog somewhere mentioning something about dropping a pin and pressing a tiny red man somewhere. Huh? The plot thickens.

Surely this can’t be true? Have Apple gone mad?

“Oh yes it is”. And “oh yes they have”.

Really, it’s true. To use a lovely new built in feature like Google Street View on your iPhone you actually have to arse around with a pin thing and a tiny icon of a red man that only appears when you drop the pin. Even worse, you have to press a button to get to the page which lets you drop a pin. And then press another button to drop the pin.

One… two… three… 

So that’s three button presses to get to street view? None of the steps are at all obvious. And pressing that little red man icon thingy? Yes, that’s really obvious…

Apple have clearly ditched any attempt to make interfaces intuitive in favour of making it a requirement to read an explanation first. This is the kind of thing some crazed nerd might do. Not Apple. Not the company that Jef Raskin once worked for. Not the makers of OSX and the iMac and the original iPod.

Phew… rant over. Sorry.

Well, not quite. That other new feature: podcast live downloads. In principle it’s simple: you search for a podcast on the go, download it, then listen to it. Nice idea. Trouble is – again – that the user interface is just bizarre.

You enter podcast mode in the iPod app. Press a “get more episodes…” button which takes you to a different app, where you download the podcast or search for something different.

There are some nagging questions though:

  • How do I get out of podcast app and back to iPod? Hmmm, press the Home button and press on iPod. Not brilliant design really.
  • And how do you delete old unwanted podcasts that you just downloaded? Well, you don’t. Unless of course there’s some other hidden icon of a red man or you have to guess some combination of button presses.

All in all, Apple’s tried to add in a few new features with the 2.2 update. They’re nice features, but just a bit weird and poorly thought out.

Expect 2.2.1 fairly soon because unless my brain really has died, surely others will be asking the same questions and wanting answers.

Drupal Enterprise how-to

2 Replies

In a couple of earlier posts I mentioned how I thought Drupal could be used as an enterprise-level CMS, at least if you were willing to change modify your definition of ‘enterprise-level’ slightly.

When thinking about deploying any CMS across a large organisation or large company, one of the things you’re going to find is that you need two key things:

  1. separate departments will want separate sites that they can control the content of, and maybe even the look-and-feel of
  2. content from all those departments will need to be aggregated in some way, and reused by other departments

It’s these requirements that enterprise-level CMS cater for really well. It’s these that Drupal can only partially answer. This is why Drupal isn’t really completely enterprise ready, yet.

However it can go a long way towards that using its little-known but powerful multi-site capability. There are plenty of blogs detailing how you can do this in any number of ways, so I won’t go into details here.

Take a look at some of my delicious bookmarks for things I found really helpful in setting up a multi-site system.

Basically, the idea is that each site in your multi-site setup has its own folder in Drupal’s sites/ folder. Something like www.mydomain.com.site1 would do. Now you have one Drupal installation, but the potential for lots of separate drupal sites.

While that does cater for a really simple single codebase setup, it doesn’t let you share things like users and logins. That’s going to be crucial for any true multisite setup, because you’ll want the same user to be able to go to different parts of your overall website without having to log in to each separately.

Luckily, Drupal has a really elegant solution to this. You can easily share tables across sites using Drupal’s database prefix system. So for example you could say that site1 will have its own tables prefixed with site1_ except it will use the user table of site2 (identified by site2_) for its user data.

This is all set in each site’s settings.php file, and requires just a few lines of code to do. Simple.

And with that, you open up a whole new world of multiple sites with single signons: the first step to an enterprise-level solution.

OK, so you don’t have truly shared content across sites yet. You may never have that, but then you may never need that. RSS feeds, simple RESTful APIs… there are all sorts of other ways of sharing content. You could even get adventurous and write your own module that treats some kinds of content types differently, putting them in shared tables rather than a site’s own set of tables.