このブログでホッテントリ入りしている数少ないエントリの中に「手軽で使い勝手の良いCompact Calendar 2008 (でぃべろっぱーず・さいど)」というのがあります。
毎年DAVID SEAHさんによって公開され、各国で翻訳版（祝日を各国に合わせた版）が作られ公開されています。
で、このCompact Calendarを自由に作れないかと思って作ったのが↓こちら。
使い方は簡単で、カレンダーの開始日と終了日を指定して、「作成」ボタンをクリックするだけ。
祝日を反映したい場合は、「祝日を取得」ボタンをクリックすると、Google Calendarの日本の祝日カレンダーから情報を取得してきます。
表示したカレンダーは、そのまま印刷しても良し、「PDF」ボタンを押してPDFにするも良し。
PDF化には、アシアルのHTML2PDFというサービスを利用しています。
鳴り物入りで公開された検索エンジンの「Cuil」が手厳しい批判を受けてますね。
TechCrunch Japanese アーカイブ » Cuil―発射後20秒で爆死
白と黒と青のデザインとか、結構好きなんだけどなぁ。
作っている人たちはその分野のエリートの方々のようで、そういう人たちでも新しいサービスのリリースではこんな結果になっちゃうんですね。
これから信頼を回復していくことができるのか、ちょっと注目です。
『YouTube』を持つGoogleは、『Google Video』をなぜ閉鎖しないのか | WIRED VISION
GoogleがYouTubeを買収して以来、Google Videoはすっかり影の存在になってしまいました。
それでも、Google Videoには良いところがいくつかあったんですよ。
例えば、10分を超える動画でもアップロードできるとか、画質がYouTubeより良いとか、iPodやPSP用の動画ファイルがダウンロードできるとか。
でも、それらの利点は徐々にYouTubeの方へ吸収されていきつつあって、なかなか修正されない既存バグのせいで数少ないユーザも徐々に他のサービスに流れて行っているんですよね。困ったもんだ。
例えばUstream.tvのようなサービスを、Google Videoが実装すれば良かったんじゃないかな。
そうすれば、Google Developer Dayのようなイベントも、Google Video上で生中継できたりして、もっと注目されたんじゃなかろうか。
勉強会や講演会の長時間動画も、生中継してそのまま動画としてアーカイブできるわけだし。
なんにせよ、このまま静かにフェードアウトってのはちょっと寂しすぎるなぁ。
Google App Engineにアップデートがあり、1ユーザが登録できるアプリの数が3から10に大幅増量されました！
Google App Engine Blog: Some small updates!
- More apps: Want to create more than 3 applications with your App Engine account? Now you can now create up to 10!
- Time windows for Dashboard graphs: Zoom in on the data in your dashboard to get a more accurate picture of whats going on. You can zoom in to see graphs for the last 24, 12, and 6 hour periods.
- Logs export: You can now use appcfg.py to download your application's logs in plaintext format. Use appcfg.py --help for more information on how to download your logs.
- Send email as logged in user: If you're using the users API, you can now send email from the email address of the currently-logged-in user.
これは良いアップデートですねー。登録できるアプリが3つということで、登録を躊躇していたものもあるのですが、これで思う存分利用することができそうです。
MashupAwards4は、これを使ったものを出そうかな。
最近5人チームのチームリーダをしてます。
メンバが全体的に経験が浅く、お互いのこと（得手不得手）を知っているわけではないので、チームとしてのシナジー効果が出せていない感じ。まあ、そこを戦えるチームの形にしていくのがチームリーダの仕事なので、あの手この手を尽くしているところです。
そんな中、最近やり始めたのが、タスクの進捗状況を確認する毎日の夕会の中で、「アジャイル・プラクティス」から1つプラクティスを決めて、みんなで共有するということ。
まだ仕事がそれほど大変な局面になっていないからできることかもしれないけれど、大変な局面になったとき、チームとして乗り切ることができる力を今のうちにつけておかないと、と思ってます。
面白かったのは「コードレビューのパターン」。コード見直し模様。
「アジャイル」と構えなくても、実践できるプラクティスも多いです
悪魔のささやきを天使が打ち破り、バランスまで教えてくれる 基本的プラクティスの網羅 読んでいてワクワクするマイクロソフトがカタカナ語の長音表記を見直すそうです。
で、各ニュースサイトでこのことが取り上げられているのですが、例として挙げてある言葉がそれぞれ違っていておもしろいです。
これまで「ー」がない表記に慣れていたので、「ー」がある表記に違和感があります。
label要素とその挙動 | Web標準Blog | ミツエーリンクス
しかし、ユーザビリティの向上を見込めるにも関わらず、label要素を利用していないフォームは数多くのWebサイトに存在しています。
あるある。というか、僕自身このlabel要素のこと、半年くらい前まで知りませんでした。
まあ、label要素が指定してあっても、そこをクリックするとラジオボタンやチェックボックスにチェックが入るってことを知らなかったら意味ないわけで。
いっそ、label要素に↓こんなスタイルを適用したら良いんじゃないかなと。
label{
cursor:pointer;
}
すると↓こんな感じになります。
かえってややこしいかな・・・。
会社で、オフィスに図書館を作ろうという企画が盛り上がっています（一部でですが）。
有志から本を集めて、システムで管理して、ちゃんと図書館っぽいことをしてみようと。
で、その管理システムをWebベースで作ってみようと言うことになっていて、なんとなく僕が作るんじゃないかという雰囲気になっています。
で、技術要素は、というか言語を何にしようかという話になり。
お手軽さっさに作るのならPHPでも良いのかなと思いましたが、のちのち色んな人がメンテしていくとか、若い人がおもしろがってソースを触って欲しいとかいうことでRuby on Railsで作ることになりそうな予感。
うーん、個人的にはJaxer使ってJavaScriptで作ってみたいんだけどなぁ。
というか、スロウライダーのWebサイトに、MashupAwardに、これにと、プライベートで作るものが多すぎだな。
夏は忙しくなりそう。
なにげにPSP Storeを覗いてみたら、PS時代の名作がPSPで遊べるようになってるじゃないですか！
個人的にぐっときたのは、スクエニ最盛期の名作「武蔵伝」「アインハンダー」「ゼノギアス」「エアガイツ」（クソゲー含む）ですね。
シューティングの「アインハンダー」とかPSPでやりこむのにかなり適してるんじゃなかろうか。
ということで、さっそく購入してみました。
他にも過去の名作が遊べそうなので、色々発掘してみようかと思ってます。
プログラミングファースト開発の必要性 - ひがやすを blog
システムエンジニア不要説 - masayangの日記（ピスト通勤他
↑この辺のエントリを読んで思ったこと。
ちょっと前に、会社の中で議論したのが「設計書と仕様書は違うんじゃね？」という話。呼び名が違うから、そりゃ内容も違うんですけどね。
仕様書は、アプリケーションの仕様を定義するもの。アプリケーションの処理方式とか、コード値とか、或いはデータ取得の条件とか。のちのちメンテナンスフェーズで確実に必要になり、かつドキュメントとして残してあった方が良いもの（SIer的には顧客と合意しておくべきもの）は、仕様書というくくり。
設計書は、アプリケーションの製造段階でプログラマが主に参照するドキュメントという位置づけ。要件定義から参加していて、かつ少数精鋭で開発する場合は設計書なんて指針だけ書いてあれば、詳細なものは必要ないんじゃないかと思います。或いは、ホワイトボードのコピーとか、紙に書いたメモ書きとか、そんなのでもプログラマ間の意思疎通が図れれば、全部設計書と呼んで良いんじゃないかな。
ドキュメント作るときに、「仕様書」なのか「設計書」なのかを意識しないで作っていくと、のちのちメンテナンスしにくい、かつ読みにくい奇怪なものが出来上がることがあるので、注意が必要かな。
映画「ホリデイ」を観ました。
この手の感想は日記的なブログの方に書いてるんだけど、ちょっとIT系の切り口で書いてみたくなったのでこっちにも書きます。
話のあらすじは、同じタイミングで失恋したLAとイギリスの2人の女性が、インターネットのサイトを通じて家を交換することを約束し、2週間の期間限定で、まったく見知らぬ環境で生活をするというもの。
この「インターネットのサイトを通じて」というところがミソで。
LAとイギリスの2人が休暇の間だけ家を交換する、なんてプロットは、インターネットが普及してなかったらまず生まれなかっただろうアイデアだなぁというところに、IT化が進む生活にちゃんとハリウッドの脚本家が追いついて、それなりに新しいアイデアを生み出そうと努力している姿が垣間見え、好感が持てました。
また、恋愛ものなんだけど、「直接会う」「電話する」「メールする」というコンタクトの手段が、ちゃんと使い分けられていて、多様になった現代社会のコミュニケーションの姿もちゃんと押さえられているなぁと思いましたよ。
そんなことを考えながらサザエさんを観ていたら、あれってちゃんと昭和的な要素のまま話が止まってるんですね。
携帯電話とかパソコンとか全然出てこないし。
「磯野～、マスオさんのパソコンでエロサイト見ようぜ～」
「なかじまぁ～」
なんて会話はおよそ登場することはないのですよ。
まあそれはないにしても、携帯電話を使って、雨が降る駅から
「サザエ～、迎えに来てくれよ～」
とマスオさんがラブコールをする姿も登場しないんですよね。視聴者に「なんで携帯使わないんだろ」「なんでメールしないんだろ」って突っ込みを入れられない世界観を維持するのは大変そうですね。
ほとんどが歩いている。
インテリアと会話を楽しんだ映画 ダブルハッピーエンドでめでたしめでたし 生活空間が変わるというワクワク感が漂っています。 酔ってしまえば面白いかと思いますjQueryのJohn Resigさんが、MozillaのFirebug開発チームに加わったそうです。
これは楽しみですね。
Firebug 1.2正式版のリリースが待ち遠しいなぁ。
以前このエントリでちらっと書いたTransferJetがいよいよ実用化されました。
これはおもしろいよなぁ。
ちょっと考えただけで、色んなアイデアが浮かんでくるし。
ゲームとかにも応用できそうですよね。携帯ゲーム機。ソニーなんで次世代PSPでサポートされたら楽しげだねぇ。
大学名の略し方っておもしろい！ - これでも大学職員のブログ -情報センター勤務中-
略し方って意外と方言があっておもしろいですよね。
会社に入ったばかりの頃、行き先掲示板に、
「○○（顧客名）→NR」
と書いてあって、「NRってどこの会社名の略称だろうか」と真剣に考えていました（正解は"No Return"、つまり直帰のこと）。
あと、MTG（ミーティング）も、分からない人は分からないですね。
メールアドレスを、「メアド」と略すか「メーアド」と略すかって、結構ばらつきあります。僕は「メアド」派なので、「メーアド」って表記を見かけると、なんか小骨が喉に引っかかったような違和感をおぼえちゃいます。
後輩が、メーリングリストを「メーリス」って略していたのも、ちょっと気になったなぁ。
あるグループ内で共通の略語を作っていくのは、約束事を共有していく楽しさがあって、その言葉を使って会話をするのは楽しいのですが、度が過ぎると新しい人が入って来にくい閉鎖的な環境になってしまうので注意が必要です。
今のプロジェクトでSeleniumによるテスト自動化を図りたいと思ってます。
ただ、今までExcelでテストケースを書いていた文化のところに、HTMLでテストを記述するというのをいきなり持ち込むのは、抵抗がありそうな予感。
（文書の変更管理も、Subversionのコミットログで良いじゃんと思ったのですが、結局Excelでも管理することになったし・・・）
そこで、↓こんな手法が気になるところ。
マクロを使ってテストケースを作成する、と。これなら、まだ説得しやすそうかなぁ。
あとは、テストの結果が常に保証されるように、テスト用のデータの自動ロードを検討したいところです。
これはちょっと嬉しい機能。
Gmailに「リモートからログアウト」機能 - ITmedia Biz.ID
友人のコンピュータなど、ほかのマシンからGmailを利用した場合、ログインしたままにしておくと、メッセージを他人に読まれる恐れがある。新機能は、ほかのコンピュータからのログイン状態をリモートで確認し、ログアウトできるというもの。
出先でGmailにログインして、後から「あ、ログアウトしたっけ？」と不安になることって結構ありそう。
そんなこと考えもしなかったって人は、この機能をつかってちゃんとログアウトすることをオススメします。
こんな簡単な書き方で文字列から数値だけを抜き出してる。
この処理が秀逸だよなぁ。必ず偶数番目に数値がくるっていうのが目からウロコ
DIGITS = re.compile(r'(¥d+)')
>>> print DIGITS.split('abc123a4bcd56')
['abc', '123', 'a', '4', 'bcd', '56', '']
>>> print DIGITS.split('123a4bcd56e')
['', '123', 'a', '4', 'bcd', '56', 'e']
なるほどねー。
個人的にはPythonの以下の記法がおもしろいなーと思いました。
pieces[1::2]
これで、piecesという配列のインデックス1から最後まで2ステップ（1つ飛ばし）でスライスしちゃうと。
JavaScriptにも似たような書き方ないか探してみたけど、見あたらず。
配列のsplitは同じように書けるのになぁ。
var hoge ='a123bc4d567ef89'; hoge.split(/(\d+)/);
ところで上記pythonのコードはTracのどういう機能で使われてるんだろ。
仕事でSeasar2使うので、なんとなくじゃなくちゃんと理解しておこうと思い、購入。
S2Daoのところをメインに読もうと思ったんですが、Teedaのところが結構おもしろいですね。
これまでStrutsでいくつかアプリを作ってきたので、Viewをhtmlで記述できることのメリットは良く分かります。
これ使ったらほんとにさくさく作れそうだなぁと思いました。
ただ、気になったのが、id属性を使うというところ。
バックエンドのアプリや趣味で作るときは、画面デザインも自分でできるから良いのですが、フロントエンドになるとHTMLはまずデザイナさんが作る、なんてことが良くあります。
で、idでスタイルを設定されちゃうと、めんどくさい感じになるんじゃないかなぁ。
さらに、僕なんかはjQuery使ってJavaScriptのコードを組んじゃうので、同じくidを使って色々とやりたいわけで。
まあ、デザインも全部自分でやったら良いだけなんですけどね。
今度仕事でTeeda使うことがあったら、デザイン入る前にこの辺のことをちゃんとルール決めして、デザイナ・プログラマ間でちゃんと認識合わせるようにしよ。
説明は丁寧だが… Seasar初心者に超オススメの一冊以前、JUIに参加したときに、「jQuery pluginとしてリリースします」と言ってほったらかしになっていたcolor-utils.jsをリリースしました。
jquery-color-utils - Google Code
使い方等のドキュメントは↓こちら。
Document - jquery-color-utils - Google Code
RGB(rbb(n,n.n))表記を、16進表記（#nnnnnn）に変換したり、rgbの値を与えて色を変更したり、色の平均値を出したり、背景色でHTML Elementをソートしたりできます。
まあ、普通のアプリでは、あまり使われることはなさそうですかね。
テストを先日紹介したQUnitで書いているので、興味がある方はテストのページもご覧ください。
ダウンロードは↓コチラのページから。
Google Chart API がQRコードをサポートしたようです。
Developer's Guide - Google Chart API - Google Code
http://chart.apis.google.com/chart?chs=150x150&cht=qr&chl=Hello%20world&choe=UTF-8
imgタグのsrc属性に、上記のように指定すると、↓こんな感じでQRコードになります。
これは良いですね。
ドキュメントを見ると誤り検出レベルの指定もちゃんとできるようです。
Mashup Award 4thはこれを使ってみようかな。携帯と連携させたいときに便利そう。
