Mr Kirkland 2.0

Archives

« Older

Loading Newer »

Less

Excerpts Headlines Full Length

CodeIgniter Language File Translator

Published by Mr Kirkland April 26th, 2008 in webmastering. Closed

My good friend Owen Christian and myself have cooked up a nice little code igniter language file translator. This is a controller and series of views that you can drop in on your CI install and then use a nice front end to manage administration of the language files for your application.

This is meant for people to be able to edit the standard application language files in your CI install, which work with the CI Language Class. The basic idea is that you have a master language, and then this allows translators to translate into other languages.

Features

UTF8 support
Handles php in language strings
Synchronises language keys with ‘master’ language
Checks php for syntax errors

Download

Download version 0.5.1 here

Installation

Unpack archive
tar -zxvf translator-0.5.tgz
Copy files into appropriate location in your CI install (or just unpack archive over your install)
If your language files are in an exotic location, edit config/translator.php
set language files to be writable by your webserver
that’s it!

Usage

(If you haven’t already) Create your master language files and keys e.g.:
language/english/file1_lang.php
$lang['file1_some_key'] = 'some key'; $lang['file2_another_key'] = 'another key';
etc.
Create corresponding ’slave’ language files e.g.:
language/japanese/file1_lang.php

NB You don’t have to create the keys, just the empty writable files
Make sure language files are webserver writable
Fire up your new controller i.e. index.php/translator and go!

Code Igniter Japanese Localisation

Published by Mr Kirkland January 23rd, 2008 in webmastering. Closed

Following on from a previous note about Japanese and code igniter, I just found a Japanese language pack for code igniter on http://www.cilab.info/. There’s a Japanese turorial and user guide aswell if that takes your fancy.

Domain names in Japan

Published by Mr Kirkland January 19th, 2008 in webmastering and search. 0 Comments

Not long after the first time I arrived in Tokyo I noticed (amongst a vast array of other wierd and wonderful things) a common trend among the advertisements on the metro, TV and just about anywhere, and that was the ’search term’ call to action. Although most of the paper adverts will at least list a URL the real call to action is search box with the keywords inside and a mouse pointer hovering over the search button.

This struck me as a dangerous strategy - intstantly you’re telling your competition which terms to bid on and in many cases these terms are quite esoteric and not particularly hard to get natural rankings for. In fact I actually did a little experiment, and for the keyword of one particular advert I put up an almost empty page with the japanese keyword as the title and within a few weeks start receiving search traffic, I think the page still ranks about 6th (look for anglojapanese.net): search for てんるす.

However I have since come to the realisation that this search call to action is much easier for the Japanese customers to remember than a URL using the (less familiar) Roman alphabet, therefore it’s a risk advertisers have to take. So why not use japanese words in the domain? Anyone West of Turkey will be familiar with the heavy use of keyword domains - www.cheapfilghts.co.uk etc. Can’t the japanese do this aswell?

Well they can, as any ‘domainer’ out there will tell you, one has been able to register “International Domain Names” (i.e. domains with non-roman alphabets - chinese, cyrillic etc.) for a number of years now. But (a big but) good old microsoft have only started to support use of IDNs with IE7, so this is probably a key factor.

Anyway I would expect this trend to change in the near future as IE6 usuage shrinks while more modern browsers with IDN support, such as firefox and IE7 take hold. So I’d hazzard a guess Japanese Language urls start cropping up on the metro ads. In fact I’ve taken a punt myself: インテリアアート.jp
オフショア.jp
モダンアート.jp
アート販売.com
オフィスレンタル.jp
水彩.jp
現代作家.com
ネットギャラリー.jp

Wikia Search Reviewers Missing the point

Published by Mr Kirkland January 8th, 2008 in search. 2 Comments

Wikia Search having launched into Alpha today has received a number of negative reivews, but I these reviewers are clearly missing the point. I would forgive them for not understanding what an “alpha relase” is, but the apparent tech centricity of their publishing sites does not allow such concession.

When I heard Mr Wales speak at the FCCJ in Tokyo last April, I was inspired by his plans for an open search engine. Clearly the key point behind Wikia Search is to built a platform based on openess and to share the technology with the world. To compare an alpha release of this bold project with Google is like comparing a spritely toddler with a top olympic athlete as though they were both adults.

Anyway Jimmy posted a response on the tech crunch article which eloqently makes this point:

Release early, release often.

It’s a project to *build* a search engine, not a search engine. We’ve been telling everyone that constantly. I’m sorry Michael’s disappointed, but having said that, we didn’t build it for him, but for people who think that openness, transparency, and participation are more important than slick releases.

When I launched Wikipedia, I wrote at the top of the first page “Wikipedia, the free encyclopedia”. On that day, anyone reviewing it would have laughed. What’s this? There’s nothing here! This is not an encyclopedia, it is an empty website with some funny editing syntax!

So the comparison to Google on day one is just mistaken. Google didn’t launch a project to build a human-powered search engine, they launched an algorithmic search engine with a clever new idea. So they didn’t have to wait for the humans to come in and start building it.

We aren’t even running with a real index yet, just a placeholder index. Yeah, the search sucks today. But that’s not the point. The point is that we are building something different.

Adding a user to phpbb3 from an external script

Published by Mr Kirkland January 5th, 2008 in webmastering. 8 Comments

So working on a phpbb2 -> phpbb3 upgrade this weekend and the final part was updating the script to sync my applications user table with phpbb3, so users of my application automatically have an account on the forum with the same credentials.

phpbb3 has a new password handling system so it’s not so simple to write raw queries to insert/update the phpbb database. Instead, after a little research I opted to use phpbb’s own functions to add a new user. As noted here and here you can call the user_add function from includes/functions_user.php. This works fine until you want to call the function from inside another function as noted on the above links, it’s a little tricky getting it to work.

I managed to come up with a fairly simple solution - you need to declare a number of key variables as global at the top of your function so they are in scope when you include the phpbb files.

define(’IN_PHPBB’, true);
/* set scope for variables required later */
global $phpbb_root_path;
global $phpEx;
global $db;
global $config;
global $user;
global $auth;
global $cache;
global $template;

# your php extension
$phpEx = substr(strrchr(__FILE__, ‘.’), 1);
$phpbb_root_path = ;

/* includes all the libraries etc. required */
require($phpbb_root_path .”common.php”);
$user->session_begin();
$auth->acl($user->data);

/* the file with the actual goodies */
require($phpbb_root_path .”includes/functions_user.php”);

/* All the user data (I think you can set other database fields aswell, these seem to be required )*/
$user_row = array(
‘username’ => “Username”,
‘user_password’ => md5(”Password”), ‘user_email’ => “Email”,
‘group_id’ => $default_group_id,
‘user_timezone’ => ‘1.00′,
‘user_dst’ => 0,
‘user_lang’ => ‘en’,
‘user_type’ => ‘0′,
‘user_actkey’ => ”,
‘user_dateformat’ => ‘d M Y H:i’,
‘user_style’ => $not_sure_what_this_is,
‘user_regdate’ => time(),
);

/* Now Register user */
$phpbb_user_id = user_add($user_row);

Facebook Presentation at Tokyo 2.0

Published by Mr Kirkland December 12th, 2007 in facebook. 1 Comment

Last night I presented my Facebook development experiences to the crowd at Tokyo 2.0. I’m not going to repeat myself as most of the information I presented I’ve already written about in the facebook section, but I’d like to share the presentation data: odp or pdf and mention my references:

Japanese charaters in code igniter urls

Published by Mr Kirkland December 6th, 2007 in webmastering. 3 Comments

Code igniter is restrictive over permitted url characters (a good thing!), and it’s simple enough to edit the permitted_uri_config option to add more charaters. However, what if you’re dealing with Japanese charaters in the url?

Well (after a little searching) it turns out that this isn’t too difficult to fix as the config value is a regex and one can add the kanji charater ranges in a similar fashion to the standard ascii ‘a-z’ syntax:

$config['permitted_uri_chars'] = 'a-z 0-9~%.:_-'; 　　　　　　　　↓ $config['permitted_uri_chars'] = '一-龠ぁ-んァ-ヴーａ-ｚＡ-Ｚ０-９a-z 0-9~%.:_-';

courtesy of: http://pricewave.blog110.fc2.com/blog-category-4.html

setting up terminal and vim for japanese on osx

Published by Mr Kirkland December 6th, 2007 in Uncategorized and webmastering. 0 Comments

I’d hazzard a guess that there aren’t a great deal of non-japanese vi users on osx who need to work in japanese, but at the very least this will serve as a reminder for myself later on!

First up, the most useful resource I found was the following page http://osksn2.hep.sci.osaka-u.ac.jp/~taku/osx/vimjp.html (thanks to Taku Yamanaka!)

If you can read Japanese, then follow his instructions otherwise, the key steps are:

Setting up VIM

edit. you ~/.vimrc file and add:
:set enc=utf-8 :set fenc=utf-8 :set fencs=iso-2022-jp,euc-jp,cp932

Edit your terminal settings

File -> Show Info (ファイル>情報を見る)
Go to Emulation (エミュレーション)
uncheck Escape non-Ascii characters (非Ascii文字をエスケープする)
Go To Display (ディスプレイ)
Check Wide glyphs count as 2 columns (ワイドグリフは２桁とカウントする) and Wide glyphs for Japanes/Chinese/etc.(日本語や中国語などにワイドグリフを使用する)
You’ll probably want to make the settings default (設定をデフォルトとして使用)

Bash

For good measure you might want to tweak bash. Edit ~/.profile and add:
export LC_CTYPE=en_US.UTF-8
Edit ~/.inputrc and add:
set input-meta on set output-meta on set convert-meta off set meta-flag on set output-meta on
You’ll need to reload bash for these changes to take affect - close and reopen terminal.

Facebook Apps on EC2 update

Published by Mr Kirkland October 31st, 2007 in webmastering and facebook. 1 Comment

I wrote an overview on using ec2 for hosting facebook apps a few months back. I’ve been poking around a little more with EC2 lately and have a couple of items to report back.

Facebook ‘hello world’ Public EC2 image

I spotted this public ami for getting started with facebook, shipping with:

1. Facebook Client Libraries
2. HelloWorld Facebook Application that lists the objects in your Amazon S3 bucket
3. Footprints Facebook Application that is shipped with Facebook Client Libraries

New Large and Extra Large Instance Types

I mentioned previously about setting up a cluster of servers to deal with the potential high traffic for facebook apps, however amazon have released some more beefy images that could absorb a lot more traffic before showing the strain.
They now have 3 types of instance small, large, extra large:

Small Instance (default) (1)

1.7 GB memory, 32-bit platform
1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)
160 GB instance storage (150 GB plus 10 GB root partition)
Instance Type name: m1.small (used in EC2 APIs)
Price: $0.10 per instance hour

Large Instance

7.5 GB memory, 64-bit platform
4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each)
850 GB instance storage (2 x 420 GB plus 10 GB root partition)
Instance Type name: m1.large (used in EC2 APIs)
Price: $0.40 per instance hour

Extra Large Instance

15 GB memory, 64-bit platform
8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each)
1,690 GB instance storage (4 x 420 GB plus 10 GB root partition)
Instance Type name: m1.xlarge (used in EC2 APIs)
Price: $0.80 per instance hour

So potentially you could quickly shift from a small instance to large, then to extra large as required.
NB There are still great benefits to going down the cluster route rather than single server though, particular if you’re doing anything with a database (of course you are!) then you’ll really want to have replication onto a separate machine to ensure minimum data loss in the event of failure.

Amazon EC2 as webhosting replacement

Published by Mr Kirkland October 24th, 2007 in webmastering. 1 Comment

So I’m currently researching hosting options for our infrustructure expansion on www.theartistsweb.co.uk, we already make heavy use of S3 and so I wanted to look into taking advantage of EC2 aswell. I’m not a complete newbie to EC2 and used it to scale a popular facebook application, which worked well.

However more traditional website hosting has a few specific needs that aren’t standard to EC2, anyway read on to see the results of my research so far

Disadvantages

Start with the bad news:)

No Persistant Storage

Simply If you shut down an EC2 instance all the data is lost, reboots are okay but it is still possible that an instance can fail (the program is still BETA btw) and you’ll loose your data. I actually consider this an advantage as it forces you to plan for failure and so create a more robust set up and ideally you’d use S3 to provide your persistant storage whilst using EC2 for quickly replacable nodes to serve the data/application.

And in reality cheapo dedicated servers have hardware failures, in my own personal experience with uk2.net I went through 4 dedicated servers in a month as each had faulty ram - I couldn’t believe it was a hard fault in all machines until the 4th one just worked.

No Static IP Address (yet)

This is potentially a big disadvantage in my opinion. At the moment you can’t reserve an IP address, so each time you create a new instance you get a new IP, and as you should generally expect failure at some point this means you have to assume (at least occassional) IP address change. Whilst you could get by with changing IP address by using low TTL and/or a third party dynamic dns service/api the following cases could be show stoppers if not handled properly:

DNS caching, theoretically DNS caches should obey your TTL, but there may be some links in the chain to your website that don’t (proxies, client applications etc.)
Reverse IP, PTR (Mail reverse IP lookups) - now this is a big deal for any mailhost in my opinion. Sending mail involves jumping through tighter and tigher hoops now-a-days and reverse dns records and PTR for your mail server are a must.On top of this many large ISP’s (yahoo etc.) associate reputation information with IP addresses so a change in IP address can directly affect your mail deliverability. I’m sure this can largely be dealt with configuration and careful planning, but it’s a non standard setup with potential for problems - poor mail deliverability is poor/lost business. See the aws ec2 forum, plenty of discussion on this problem
General pain in the arse - static IP address are probably what you (and your customers) have been used to for the last x years, so apart from the 2 key points above there’s bound to be some fixed IP skeletons in the closet that will come out if you are migrating an existing infrastructure.

You can see on the EC2 forum that quite a few people want optional static IP’s and this is apparently going to be a new feature ’soon’

Some other forum posts.

Lack of Support

You’re really on your own here, Amazon is providing a platform rather than controlled environment dedicated servers, so you can hardly expect Amazon tech support to hold your hand then through your software issues. If you need built in software support stick with a standard supported plan on a regular ISP.

Cost

The bandwith prices can rack up see the cost calculator and compare with some other offers

Advantages

Cost!

The cost of running an instance is comparable to regular dedicated servers and increases linearly with the number of instances you deploy, so no nasty surprises as your needs grow - see the cost calculator. You could also be using an AMI instance periodically for testing, compute tasks etc., you are billed by the hour not the month. However compared with other offerings, the bandwith is where the expense lies so it really depends on your needs/usage.

Quick Set Up

You can fire up an instance in a few minutes and choose from a wide variety of public images to get started. Once you’ve fully tweaked and set up your instance, you can then make your own AMI to launch more instances from. This is a big time saver over the traditional set up and tuning of a dedicated server, how long would it take you to drop in another server in your pool?

Scale

The real beauty is the on demand aspect, with proper planning you can quickly fire up a few extra instances and absorb huge spikes. If your infrastructure is one or 2 servers (and will be for the foreseable future) then there’s no appeal here. However if you need to plan a path for growth then EC2 might still be worth considering (as I still am!).