KohanaフレームワークでPHPTALを利用してみた2

前回の記事ではとりあえずKohanaフレームワークからPHPTALを呼び出すところまで試してみた。
なんとなく繋がったので今度はより実践向きに共通ヘッダーやフッターを利用できるバージョンにしてみる。
共通のヘッダーやフッターを表示させるには主に2パターン
・コンテンツのテンプレートを書いてそこからヘッダーとフッターを呼ぶ
・共通のレイアウトから内部だけくり抜いてコンテンツを当て込む
なんとなくCakePHP使ったときにやりやすかった共通のレイアウトの中身くり抜いて内部のコンテンツを当て込む方法を採用。
PHPTALを調べていたらちょうど良さそうなのを発見!
METAL(Macro Extension for TAL)、コンテンツの中身を書き換えてくれるらしいのでこれを使って作ってみる。
悩ましいのが2パターンどちらの方法を使ってもhtmlソースがちぎられた状態で存在してしまうこと。
テンプレートファイルがいきなりdivから始まってたりするとデザーナーさんでも読みやすいPHPTALのテンプレート特性を生かせない。
とりあえずはコンテンツ用のテンプレートにはダミーのヘッダー、フッターを書いてもらうことにする。
これで極端なテンプレートにはならないと思うけど、いまいちかな?
■設定ファイルとライブラリ
/system/application/config/ptal.php

<?php defined(’SYSPATH’) or die(’No direct access allowed.’);
/*
* File: Ptal
*
* Options:
* dir -
* suffix -
* layout -
* title-default -
* title-format -
*/
$config = array
(
‘dir’ => APPPATH.’views/’,
[…]

翻訳が簡単にできるGreasemonkeyのスクリプト

同一ページでさくっと単語や文章を翻訳したいと要望があったのでいろいろ探したらだいたい2タイプに分かれてアドオンやグリモンのスクリプトが存在した。
(1)alcサイトや他の翻訳サイトをスクレイピングしてるっぽいやつ
(2)ローカルの辞書を使って翻訳するタイプ
1の場合だと、利用しているサイトのレイアウトやURL変更が発生するとすぐ動かなくなる。
昨年URLの変更があったalcを利用しているアドオンなどは動かなくなっている模様。
各自でソース内部のURL変更して対応しているみたいです。
2の場合はローカル辞書が必要でほとんどの辞書が有料。フリーの辞書は試していないので実力は不明。
大体こんな感じ。
結構よさげな奴もあるのですがもうちょっとさくっと引けたらな~と思い作ってみました。
作るにあたって一番の問題はデータの取得元。
翻訳サイトをスクレイピングするとちょっと問題ありそう。問題なくてもメンドクサイ。
でも今は便利な世の中で翻訳用のAPIを提供しているところがありました。
英語←→日本語の翻訳APIとして使えるYahoo Pipesを作った
http://muumoo.jp/news/2007/05/09/0translationapi.html
タイトル通りYahoo! Pipesで提供されています。
管理人ぷーるさんとYahoo! Pipesに感謝!
これがあれば後はUIだけ考えて2時間くらいで実装終了。
できあがったのがこれ
■機能
・日本語→英語に翻訳できる
・英語→日本語に翻訳できる
■スクリーンショット

■インストール
通常のユーザスクリプト(Greasemonkey)と同じ。
簡単に説明すると
FirefoxのアドオンGreasemonkeyをインストール
https://addons.mozilla.org/ja/firefox/addon/748
下記のリンクをクリックするとユーザースクリプトがインストールされます。
poolmmjp_translation.user.js
■使い方
翻訳には2つの方法があります。
(1)Ctrlキーを押しながら翻訳したい文字列をマウスで選択して反転させます。
画面上部に訳が表示されます。
(2)Ctrlキー+F1キーを押すと入力ボックスが表示されます。
入力ボックスに単語や文章をいれて「OK」ボタンをクリックすると画面上部に訳が表示されます。
画面上部に表示された訳はダブルクリック若しくはCtrlキー+F1で消すことが可能です。
リクエストで作ったユーザースクリプトですが予想外に使い勝手がいい。やっぱり画面遷移やスクレイピングよりは速いからかな。
いままでランチャーにコマンド入れて翻訳サイトに画面遷移させていたんですけどこれに切り替えます。
興味がある方はお試し下さい。
※不具合を見つけた方はコメントでお願いします。
■変更
※2008/01/29 ver0.81 ソースの見直し

SEとプログラマが利益を得る方法

組織に所属している以上、組織の利益を求めるのはあたりまえだけど
SEやPGの立場で仕事をしているとちょっと悩む。いや、だいぶ悩む。
これは中小企業のソフトハウスが前提なのだけれどソフト会社といっても実態はほぼ人材派遣である。
私が勤めている会社もほとんど派遣で一部社内で一括請負をしている。
そんな中で派遣されている社員が組織の為に利益を求めるのはとんでもなくしんどい。
まず派遣で行く場合、1ヶ月いくらの世界でありその時の交渉で金額が決まる。
派遣先でスキルを見せても単価が上がることはあまりない。
上がったとしてもわずか1人月の10%程度の話でありそれは組織全体から見てもほんのわずかである。
結局は人月単価で作業している限りSEやPGの利益は一人分に毛が生えた程度である。
一括請負の場合でもソフトハウスで請負える範囲であればそれほど差が無い。
例えば30人月の仕事を5人で6ヶ月行えば派遣と差はない。
これを4人で6ヶ月行ったと想定する。
1人月、70万と仮に設定すると顧客から支払われる金額は30人月×70万=2100万
1人あたりのコストを60万で計算すると4人×6ヶ月×60万=1440万。
利益は2100万-1440万=660万である。
これを一人当たりの利益にすると660万÷(4人×6ヶ月)=27.5万である。
1人月の費用が60万かどうかは考えるところであるがこの金額は少なすぎる。
更に一括請負はリスクが高くこの利益では受ける事はできないだろう。
これを考えるとソフトハウスが30代以上にマネージメントを勧める理由が分かる。
マネージメントであれば自社の人間ではない費用が安い人員を使う事ができる。
一人当たりの費用が下がれば当然利益は上がる。
なのでソフトハウスの経営陣はマネージメントできる人材を求めるのであろう。
また別に利益を求める方法として、SEやPGをプロジェクトに入れ次のシステム開発にお呼びがかかる事を期待する方法もある。
今まで勤めてきたソフトハウスは大体こんな感じだ。
マネージメントで差額から利益を求めたり、次の発注を見込んでプロジェクトに参画するなどして利益を得る(若しくは見込む)のは分かるのだけれど
それってソフトウェアを作るって部分には関係が無い。
そこで問題なのだけれど顧客の問題を解決したり素晴らしいプログラムを作ってもソフトハウスの利益には直結しない。
利益がでる仕組みはそれとは無縁の部分なのだ。
悲観的な部分や数値に根拠が無い部分もあるけれど、SEやPGが利益を求めるのが難しいと考えさせられる。
タイトルには方法と書いているが全くその方法は分からない。
「ソフトハウスがソフトを作って利益を得る」って当たり前に聞こえるがどれだけの会社が実践できているのだろうか?
SEやPGがソフトを作ることで利益を得る方法を知っている方は教えて下さい。