A couple months ago I made a new addition to my home entertainment setup: a little wireless keyboard named “Rii”:

It’s a lot more practical to use than my previous Logitech wireless full size mouse and keyboard combo because it’s so easy to grab, do something quick, and toss away (e.g. restart a program, copy or move a few files, type a search query, etc…). Obviously it’s not as good if you want to do anything that takes more than a minute, so in that case what I do is use my living room laptop (a Macbook Pro that’s always sitting on the coffee table) to either remote desktop into the HTPC or control it with Synergy.

Thanks to Eddie for showing me this little gem!

This is the second post of a series of things I learned while using PieCrust.

From the Disqus documentation:

[You can tell] the Disqus service that you are testing the system on an inaccessible website, e.g. secured staging server or a local environment. If disqus_developer is off or undefined, Disqus’ default behavior will be to attempt to read the location of your page and validate the URL. If unsuccessful, Disqus will not load. Use this variable to get around this restriction while you are testing on an inaccessible website.

Assuming you will be baking your final website, you basically want this disqus_developer variable to be enabled if you’re not baking (i.e. you let PieCrust server each page dynamically), or if you’re baking from the chef server. And because both the baker and the server define variables you can access from your templates and pages, you can write this:

{% if not baker.is_baking or server.is_hosting %}{{ disqus.dev() }}{% endif %}

That’s assuming you’re using the default template engine (Twig), and that you have a disqus.dev macro defined somewhere in your template paths with the following code:

{% macro dev() %}
<script type="text/javascript">
    var disqus_developer = 1;
</script>
{% endmacro %}

This is the first post of a series of things I learned while using PieCrust.

If you’re using PieCrust as a static website generator, you know you can use the built-in development server to preview your site as you’re modifying it. This is all pretty nice but there are plenty of good reasons to not go that way, the top ones being:

1. The development server doesn’t run any custom scripts you may have.
2. IIS, Apache and all the other well-known web-servers are faster and more robust.
3. You can’t use special features like .htaccess or web.config settings.

If you went with the recommended directory structure for your site, you will have all your content in a _kitchen directory ready to be baked into your final website. But this _kitchen directory really looks a lot like a regular PieCrust website when PieCrust is used as a lightweight CMS. The only difference is that there’s no main index.php file, and that you may be using some file processors.

If you create an index.php file to bootstrap the _kitchen website, it would get deployed to your export directory when you bake your site, so you need to do one of the following:

• Write some PHP wrapper to the chef baking utility to exclude that file from baking (you can pass a “skip_pattern” parameter to the baker class). I’ll try to make it easier to add exclude rules to chef in the near future, but at the moment you would need to write some code. Not ideal.
• Rename the bootstrap file _index.php, since all files or directories with a leading underscore in their names are excluded. Now, however, you will need to edit your .htaccess or web.config to add _index.php as a default document, but that’s really just one line of text or a couple clicks. That’s the solution I use.

If you use file processors, you may have to work around them, which may not be possible. I myself only use the LESS CSS processor, and it’s easy to avoid it because LESS comes with a client-side Javascript processor. The trick is now to switch between the client and server side processors, which can be done with a few Twig macros:

{% macro stylesheet(baker, path, media) %}
{% if baker.is_baking %}
<link rel="stylesheet" href="{{ path }}.css" type="text/css" media="{{ media|default('all') }}" />
{% else %}
<link rel="stylesheet/less" href="{{ path }}.less" type="text/css" media="{{ media|default('all') }}" />
{% endif %}
{% endmacro %}

This macro emits a reference to a stylesheet that points to the standard CSS file if the website is currently being baked (which means the server-side processor will run to generate that CSS file), or points to the LESS file itself otherwise (which means the processor will run on the client).

{% macro less_js(baker, site_root) %}
{% if not baker.is_baking %}
<script src="{{ site_root }}js/less-1.0.41.min.js" type="text/javascript"></script>
{% endif %}
{% endmacro %}

This second macro adds the client-side processor to your page if the baker is not running.

Now you just need to call those macros from your template file(s):

{{ less.stylesheet(baker, site.root ~ 'styles/my-awesome-stylesheet', 'screen, projection') }}
{{ less.less_js(baker, site.root) }}

Update (PieCrust >= 0.0.3)

Recent versions of PieCrust have, at last, the ability to define which files should be excluded from baking. This means you can rename the bootstrap file back to index.php if you wish, and exclude it from the bake along with any .htaccess or web.config:

baker:
    skip_patterns:
        - /^_/
        - index.php
        - .htaccess
        - web.config

This is much better!

Since I’ve migrated this blog to PieCrust and all its comments to Disqus I’ve run into a few problems that took me some time to figure out (although I got help from the nice Disqus guys). Those problems come down to the following information which was not quite clear to me even after reading their documentation several times:

• The disqus_identifier value gives a unique name to a thread.
• The disqus_location value indicates the URL(s) at which a given thread can be found.
• A thread can be used by several URLs, but no URL can be used by more than one thread.

The first 2 points are pretty straightforward, but that last one was the tricky one. Basically (at the time of this writing, obviously) if you have 2 threads with 2 correctly unique identifiers that were created both with the same URL, your page at that URL will show all kinds of weird behaviours, from never loading any comments (you get the “Disqus loading” icon animation) to loading one of the thread regardless of what disqus_identifier you specified on that page. You would think that identifier would, well, identify exactly what thread you wanted to display, but no, the URL from which it is loaded apparently also plays an important role.

This means, for example, that you can’t display more than one thread on a single page, although the Disqus guys told me this limitation will be removed in a few months.

Another little thing to look for is the subtle distinction between http://example.com/some/url and http://example.com/some/url/ (note the trailing slash character at the end of the second URL). Those URLs are effectively different, as far as Disqus is concerned. This is especially important for statically generated websites since the actual URL of a page or post is http://example.com/some/url/index.html, so there could be at least 3 correct ways to access the same page. Hopefully, as long as you don’t have some weird address collision, you won’t run into the problem mentioned above (which I ran into because I was messing around with the very handy Disqus Python bindings to batch rename and re-identify my threads).

Hopefully this will save somebody some head-scratching.

You may have noticed that this blog has changed its look, and has migrated its comments to Disqus. You may also see at the bottom of the page something about some pie crust baking… here’s what’s happening.

I have a few websites around and most of them don’t have much in them (e.g. I use the domain name for other things). There’s clearly not enough content to use a proper CMS, but there’s a bit too much repetition for my tastes if I write HTML files by hand. Also, I wanted to take advantage of libraries like Markdown or SmartyPants to make my text look nice with no effort. Basically, I needed some micro-CMS that would handle some basic layout and formatting.

Then there was the issue of this blog. It was running with WordPress, which I’m very happy with usually, but it wasn’t geeky enough. Also, syntax highlighting for code snippets felt dirty and over-complicated. I stumbled upon the whole “static site generation” underground scene and figured I could find something in between: a micro-CMS (for my small sites) that could also bake its own contents into static HTML files (for this blog).

Enter PieCrust.

There was already a shitload of static website generators, but none that could also work as a “dynamic” micro-CMS. Also, I’m a programmer geek, so it’s kind of my duty to not be happy with existing solutions and write one myself (“this one uses curly braces, but I want to use brackets instead! Surely now I have to write my own!). Anyway, isn’t the whole point of home projects to write stuff for yourself, to learn something new or just have fun with a new subject, regardless of whether it’s productive? I was bored, too.

I ended up writing PieCrust in PHP not because I like PHP (it mostly sucks), but because it’s still the most widely used web application language out there. And also because I’ve already got other home projects aimed at having fun with Python and Ruby.

So there you have it, go check out PieCrust. The code is on BitBucket, and mirrored on GitHub.

So the cat’s out of the bag, now. I needed an excuse to learn some more Javascript, along with looking at
how Google Chrome extensions look like, so I decided to add a sync feature to the excellent Minimalist for Gmail
extension. It’s all in my own GitHub fork of Ansel’s repository. It will be integrated into the shipping
branch soon, but I’ll probably keep experimenting for a while.

My little scripts for syncing Google Chrome search engines preferences are now available on GitHub, where it’s simpler for anyone to grab them and modify them.

That’s all!

After receiving some feedback, I’ve updated my scripts for syncing the search engine settings in Google Chrome. You can grab the new ZIP file here.

Here are the changes:

• I’ve written some native CMD.EXE scripts for Windows, which are easier to run than the Powershell ones for non dev people (or devs that never used Powershell).
• The scripts have been renamed to “export” and “import” since most people don’t get the “push” and “pull”.
• The “import” script creates a backup of the settings files (a file called “Web Data.backup” in the same directory) so you can revert to the previous version if something goes wrong.

Enjoy!

Tablets, and especially Android tablets, are going to be all the rage this year, with more new tablets announced every week than Lindsay Lohan had rehabs. Because I’m a geek with money to waste on unneeded electronics, I’ve decided to be part of the early adopters with my new shiny toy, the Archos 70.

I would have usually waited on more mature tablets, along with a more mature version of Android (hopefully Honeycomb), but there are a few reasons I jumped on this one:

• I’ve been a relatively faithful user of Archos’ previous portable media players (I’ve owned 2 other devices of theirs in the past, the AV500 and the 1st gen Archos 5).
• The Futureshop warranty on my Archos 5 was about to expire, so I returned it and cashed in its retail value as a gift card in order to upgrade to the latest model “for free”.
• I need a portable video player first, and a tablet second, so I don’t care much if the tablet experience is not so good.
• I’m not playing games on my phone, and I don’t intend to play games on my tablet either.

Reading through Engadget’s review of the Archos 70 and his big brother the Archos 101, all I can say is that it’s a pretty fair review. If you don’t want to read the whole thing, the conclusion is that although those devices are clearly not as good as the Galaxy Tab or the iPad, for less than half the price there’s really nothing you can complain about. I’d go as far as saying that the price/quality ratio is actually higher on the Archos 70. This is especially true when compared to the Galaxy Tab, because this one is bound to be obsolete very soon (if it’s not already by the time I finish writing this) – at least the iPad features an OS and apps that are very well designed for the tablet format and are already quite mature.

Now there’s a few things I’d like to add to Engadget’s review, because I think they didn’t highlight some of the things the Archos 70/101 are doing better than the competition.

Body Design

Archos has been until now mostly a portable media player manufacturer, and it shows in the Archos 70. First, the device has a widescreen aspect ratio, unlike the big shots out there. This means that when watching movies and recent TV series, you will have smaller black bars around the screen, if any at all. For example, this is it playing Dirty Harry… See? No bars, no cropping. Just full-screen bad-assery.

Speaking of the screen, it’s bright enough that you can watch videos outside to some degree, but it’s not as good as the iPad or Galaxy Tab screens, obviously. The view angles are particularly pretty horrible, but I don’t think it’s a big deal because it’s not like you can cram several people in front of a 7 inches screen anyway. For personal use, it’s “good enough”.

Second, the device has a built in stand you can unfold in the back. It’s very useful if you’re watching something while doing something else, like eating or cleaning your camera lenses or whatever. Way better porn watching experience, too 🙂

The stand itself is cheap plastic and feels a bit fragile, so I wouldn’t be surprised if some people broke it at some point (which would suck).

By the way, I was expecting something bad in terms of device body after reading Engadget’s review, but it turned out okay in my opinion. It sure doesn’t feel as nice and solid as an iPad, but it doesn’t feel like a Playskool toy either. And I dropped it a couple times already and it’s completely fine (unlike an iPhone 4…). True to Archos’ tradition, however, the power and volume buttons on the side are a bit wobbly, and I expect them to be the first thing that breaks down. I wish they would learn to make sturdier buttons…

Another thing Engadget mentioned already, but it’s good to mention it again, is how thin that tablet is. It’s almost 50% thinner than the iPad. See how it’s even thinner than my iPhone 3G:

It’s also super light. Archos says it’s 300 grams, which is less than half the iPad’s weight (although that’s not fair since the iPad is way bigger, with a 10 inches screen). My point is that it’s just a bit heavier than a Kindle 3 (at 250 grams), so it feels pretty natural to hold the Archos 70 in one hand while riding the bus or the subway. This is perfect for me since that’s where I watch most of my videos with it.

Media Playback

Another thing Archos is famous for is releasing devices that can read all the major (and even some minor) audio and video codecs. These tablets are no different, and so far anything I’ve thrown at it has been playing fine without the need for transcoding. Also, and that’s a big feature for me, the device appears as an external USB drive when you connect it to your computer – no need to go through some painful piece of software like iTunes. And you don’t even have to connect it at all since you can put stuff on an external mini-SD card (not included). Like any other Android device, it will scan the SD card when you mount it back and all the media that’s on it will be available. Hell, you can even just push stuff on it wirelessly with FTP or any other Wi-Fi syncing app. You’re free! Yay!

Speaking of Wi-Fi, the Archos 70 does a good job of integrating with your home network. The custom Video Player app can not only read local media, but also media from your SMB shares or your UPnP servers.

If I want to finish watching some TV series episode in bed before going to sleep, I can stream it from my NAS or my XBMC box downstairs. The only thing that wouldn’t play was uncompressed rips of Blu-Ray movies (we’re talking 25 to 30 Gb HD video files, here!). I would get this error message:

The rest would play smoothly across Wi-Fi. Here’s Serenity streaming from my NAS. I can even switch/toggle the audio or subtitle tracks and all that jazz.

Applications

The main thing that kinda sucks about applications on the Archos 70 is how Archos decided to not install the Google Market, or any of the Google applications. That was probably to avoid having to get the device certified by Google or something, but still, it’s pretty lame. Instead, they want the user to go through some other market, AppsLib, which is decent (it has quite a lot of applications) but, well, is only a subset of the main Google Market.

Thankfully, and because we’re talking about Android here, people hacked the device pretty quickly. Archosfans was, I think, the first to offer an APK of the official market app, and that’s what the Engadget guys point you to, but now I recommend using the one from XDA. In both cases, it’s super simple: you just download a file and launch it with the built-in file browser. Once that’s done, you can get GMail and Google Reader and whatever you feel like downloading. You can even run AppBrain and copy all the apps you already have on your phone, if you have an Android phone. You’re free! Yay!

Performance

I don’t care much about performance, since I’m not using the tablet for anything heavy like gaming or whatever, but in case you’re curious, here it is. I ran the Quadrant Benchmark on it and got a score of 1271 without tweaking anything on the device (e.g. it still had applications running in the background and all that).

People around the web can get scores around 1500 and more (above the Nexus One running 2.2) by killing all running apps and setting the “Power Management” to “Overdrive” in the system settings. Now, benchmarks like these don’t mean much, I know. For example the OS version alone seems to play a big part in it (see the difference between the Nexus One running 2.1 and 2.2 on the previous screenshot?). But at least it gives a rough idea of where the Archos 70 falls in terms of performance.

Just for laughs I installed a few well known games like Angry Birds or X Construction Lite and they ran very smoothly. Some people reported, at first, that a few games were unplayable, but it looks like it got fixed when Archos released the 2.0.71 firmware. And if you’re looking for serious speed and power, the XDA guys have already released a few custom kernels for the Archos tablets, some of which feature CPU overclocking.

Conclusion

So far I’m quite happy with my new toy, and the only thing I’m worried about at this point is how long it’s going to last – Archos usually cuts costs with cheap builds that tends to break or malfunction after a couple years (but then again, my Apple devices haven’t lasted much longer in my experience, although it’s usually for different reasons). I originally expected to only use it as a portable video player, ignoring most of the other features like I did with the Archos 5 (it had a web browser and all that, but the horrible resistive touch screen and crappy performance made it unusable for anything else than media playback). But it turns out the Archos 70 is a very nice tablet, and I find myself browsing the web, checking my email and social networks, and all that stuff more and more. For example it’s a pretty nice way to catch up on saved Google Reader or Instapaper articles before going to sleep. It’s also a very decent eBook reader.

It’s the best gadget I’ve bought since my first iPhone, although it’s mostly awesome because it’s so cheap. But still, it’s awesome.

Update: since Lifehacker featured this post on their home page, I released some simpler updated version of the scripts here.

The wonderful thing about open-source software is that whenever something’s missing, anybody can go ahead and fix it… that is, unless nobody cares enough about it. And that’s precisely what’s happening with the “search engines sync” feature in Google Chrome, which has been in Chromium’s bug database for more than a year and a half. Looks like Google is not so much in a hurry to let you use other search engines as soon as you install a fresh copy of their browser.

Oh, don’t look at me. I seriously don’t have the time to dive into such a big codebase to add the feature myself… but what I do have the time for is a little scripted hack to get around the problem quickly!

Google Chrome, like a lot of programs these days, is using SQLite to store its data. Your search engines are stored in a database called “Web Data”, in a table called “keywords”. It’s quite easy to use the SQLite command line shell to export and import that table across your computers… so that’s what I did. There are 2 scripts: one to export, and one to import, although I called them “push” and “pull” to sound cool like the Git/Mercurial guys.

Windows

On Windows, my scripts are written in Powershell, which ships by default with Windows 7. On previous versions of Windows, Powershell ships with some service packs, so if you’re up to date you should have it. Otherwise, go get it from Microsoft’s website.

Update: if you’ve never run any Powershell script before, you’ll have to change the security settings because I didn’t sign my scripts. Run Powershell as an administrator and type “Set-ExecutionPolicy RemoteSigned”.

You’ll need to also download the SQLite command line shell (no install required, it’s just one .exe file in a zip). Just keep it next to the script files.

Here’s the export script:

param (
    [String] $Destination = "keywords.sql"
)

$CurrentDir = Split-Path -Parent $MyInvocation.MyCommand.Path
if (![IO.Path]::IsPathRooted($Destination)) { $Destination = [IO.Path]::Combine($CurrentDir, $Destination) }
$Destination = $Destination.Replace('', '/')
$TempSqlScript = "$env:TEMPsync_chrome_sql_script"

Push-Location
Write-Output "Exporting Chrome keywords to $Destination..."
cd "$HOMEAppDataLocalGoogleChromeUser DataDefault"
Write-Output ".output `"$Destination`"" | Out-File $TempSqlScript -Encoding ASCII
Write-Output ".dump keywords" | Out-File $TempSqlScript -Encoding ASCII -Append
& "$CurrentDirsqlite3.exe" -init $TempSqlScript "Web Data" .exit
Remove-Item $TempSqlScript
Pop-Location

And here’s the import script:

param (
    [String] $Source = "keywords.sql"
)

if ((Get-Process -Name chrome -ErrorAction SilentlyContinue | Measure-Object).Count -gt 0)
{
    throw "Close Chrome and try again..."
}

$Reply = Read-Host -Prompt "This will overwrite your Google Chrome search engines! Are you sure?  "
if (!($Reply -match "^(Y|y|YES|Yes|yes)$"))
{
    Write-Output "Cancelling operation."
    exit
}

$CurrentDir = Split-Path -Parent $MyInvocation.MyCommand.Path
if (![IO.Path]::IsPathRooted($Source)) { $Source = [IO.Path]::Combine($CurrentDir, $Source) }
$Source = $Source.Replace('', '/')
$TempSqlScript = "$env:TEMPsync_chrome_sql_script"

Push-Location
Write-Output "Importing Chrome keywords from $Source..."
cd "$HOMEAppDataLocalGoogleChromeUser DataDefault"
Write-Output "DROP TABLE IF EXISTS keywords;" | Out-File $TempSqlScript -Encoding ASCII
Write-Output ".read `"$Source`"" | Out-File $TempSqlScript -Encoding ASCII -Append
& "$CurrentDirsqlite3.exe" -init $TempSqlScript "Web Data" .exit
Remove-Item $TempSqlScript
Pop-Location

MacOS X

On MacOS X I’m using bash so all you need is to make sure you’ve got the SQLite command line shell. You can either download it directly, or use one of the package managers like MacPorts or Homebrew (I’m using the latter myself).

Here’s the export script:

#!/bin/sh

DESTINATION=${1:-./keywords.sql}
TEMP_SQL_SCRIPT=/tmp/sync_chrome_sql_script
echo "Exporting Chrome keywords to $DESTINATION..."
cd ~/Library/Application Support/Google/Chrome/Default
echo .output $DESTINATION > $TEMP_SQL_SCRIPT
echo .dump keywords >> $TEMP_SQL_SCRIPT
sqlite3 -init $TEMP_SQL_SCRIPT Web Data .exit
rm $TEMP_SQL_SCRIPT

And here’s the import script:

#!/bin/sh
if ps -x | grep -v grep | grep Google Chrome > /dev/null; then
    echo "Close Chrome and try again..."
    exit 1
fi

read -p "This will overwrite your Google Chrome search engines! Are you sure?  " -n 1
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    echo "Cancelling operation."
    exit 1
fi

SOURCE=${1:-./keywords.sql}
TEMP_SQL_SCRIPT=/tmp/sync_chrome_sql_script
echo
echo "Importing Chrome keywords from $SOURCE..."
cd ~/Library/Application Support/Google/Chrome/Default
echo DROP TABLE IF EXISTS keywords; > $TEMP_SQL_SCRIPT
echo .read $SOURCE >> $TEMP_SQL_SCRIPT
sqlite3 -init $TEMP_SQL_SCRIPT Web Data .exit
rm $TEMP_SQL_SCRIPT

Bringing it all together with Dropbox

Those scripts handle importing and exporting our search engines, but we’re missing the “sync” part so far. That’s where popular syncing service Dropbox comes into play (but you can do this with any other syncing service). Just put all this stuff (the SQLite command line shell, the scripts, and the database dump) in a Dropbox folder. All you have to do is run the “export/push” script after you’ve changed your search engines, and run the “import/pull” script next time you get on another computer. Dropbox will have synced the dumped database file (“keywords.sql” by default) in the meantime (unless you’re moving really super fast, in which case you’ll have to wait a second or two).

I’ve made a handy ZIP file with those scripts, a couple of bootstrap (double-clickeable) files for Windows, and the SQLite win32 command line shell. So download it and start syncing in a very hacky and lame way!