« 2007年12月 | メイン | 2008年2月 »

2008年1月 アーカイブ

2008年1月31日

jQueryの$(function)がwindow.onload後に効かない問題

病み上がり職場復帰のリハビリ代わりに、下記jQueryの$(function)の挙動をソースから追っかけてみました。

で、amachangの

jQuery.event.special.ready.setup()
/* または */
$.event.special.ready.setup()

は、たしかjQuery1.2.2から実装されたイベントAPIの一種なので、それ以前のバージョンのjQueryでは使えないので使うときはバージョンを要チェックです(ちがってたらゴメンナサイ)。

川崎さんが困っている、

具体的には、DOM 構築完了後に、script 要素を DOM ツリーに追加して、
そのソース中で $(function) した場合とかに、C の状態が発生する。

という現象は、そもそも普通に実行しちゃだめなのかなぁと思うのですが、どうなんだろう。

hoge()を$(hoge)と書かなければいけない理由が作られているアプリにあるのかな。

 

ソースを見ていて、

(C) DOM 構築完了前に実行される JavaScript 中で $(function) を呼び出さないまま
  DOM 構築後に初めて $(function) を呼び出す
    →スルーされる

こうなっちゃうのは、jQuery.ready()が実行されていないからで、強引に、

$.ready()

とかやっちゃえば使えるようになるんだけど、これもいまいちかな。

$(function)をDOM構築前に実行すると、以下のbindReady()が実行されて、最後にwindowがloadするタイミングでjQuery.ready()が実行されるようになっているから間違っちゃいないとは思うんだけども。うーむ。

function bindReady(){
 if ( readyBound ) return;
 readyBound = true;
 // If Mozilla is used
 if ( jQuery.browser.mozilla || jQuery.browser.opera )
  // Use the handy event callback
  document.addEventListener( "DOMContentLoaded", jQuery.ready, false ); 
 // If Safari or IE is used
 // Continually check to see if the document is ready
 else (function(){
  try {
   // If IE is used, use the trick by Diego Perini
   // http://javascript.nwbox.com/IEContentLoaded/
   if ( jQuery.browser.msie || document.readyState != "loaded" && document.readyState != "complete" )
    document.documentElement.doScroll("left");
  } catch( error ) {
   return setTimeout( arguments.callee, 0 );
  }
  // and execute any waiting functions
  jQuery.ready();
 })();
 // A fallback to window.onload, that will always work
 jQuery.event.add( window, "load", jQuery.ready );
}

 

2008年1月30日

DisられやすいPHP

Rubyの作者Matzことまつもとゆきひろさんのブログで、PHPについて書かれたエントリが盛り上がっています。

PHPは、確かに簡単お手軽な言語である分、上記リンク先で指摘されているような問題点も確かにありますよね。

エンジニア的な立場からすると、各言語のメリット・デメリットをしっかり把握しておくのは重要なので、こういう指摘は勉強になります。

この件に関連しているエントリをメモメモ。

2008年1月29日

JavaScript Pretty Date

John Resigさんのブログで、pretty.jsなるものが紹介されていました。

prettyDate("2008-01-28T20:24:17Z") // => "2 hours ago"
prettyDate("2008-01-27T22:24:17Z") // => "Yesterday"
prettyDate("2008-01-26T22:24:17Z") // => "2 days ago"
prettyDate("2008-01-14T22:24:17Z") // => "2 weeks ago"
prettyDate("2007-12-15T22:24:17Z") // => undefined

こんな感じで、セットした日時に応じて、現在の時間との差分を文字で表現してくれるライブラリです。

サーバサイドで重宝しそうです。

2008年1月28日

IEのメモリリーク検出

IEでのJavaScriptメモリリークを発見するツールが発表されたようです。

IEのJavaScriptメモリリークを検出:JavaScript Memory Leak Detector - builder by ZDNet Japan

FireFoxにはこの手のツールがいくつかありましたが、IEには決め手になるようなものがなかったので、嬉しいニュースですね。

後で試してみよ。

2008年1月27日

JAXERでサーバサイドjQueryが超便利

 一昨日に引き続きJaxerの話。

今回は、jQueryをサーバサイドでも使えるよという内容です。

jQueryを一度でも使ったことのある方は、その便利さに、もうjQueryなしには生きられない感じになってしまってるのではないでしょうか(僕だけか?)。

John Resigのサンプルコード

jQueryを作ったJohn Resigさんのブログで、jQueryをサーバサイドでも使うというサンプルコードが公開されています

<html>
<head>
  <script src="http://code.jquery.com/jquery.js" runat="both"></script>
  <script>
    jQuery(function($){
      $("form").submit(function(){
        save( $("textarea").val() );
        return false;
      });
    });
  </script>
  <script runat="server">
    function save( text ){
      Jaxer.File.write("tmp.txt", text);
    }
    save.proxy = true;
   
    function load(){
      $("textarea").val(
        Jaxer.File.exists("tmp.txt") ? Jaxer.File.read("tmp.txt") : "");
    }
  </script>
</head>
<body onserverload="load()">
  <form action="" method="post">
    <textarea></textarea>
    <input type="submit"/>
  </form>
</body>
</html>

とりあえず、上記コードをテキストにコピペして、index.htmlと名前をつけ、jaxerのpublicフォルダの下に配置しましょう。

サーバが起動している状態であれば、http://localhost:8081/ でアクセスすることができます。

すると↓こんな画面が表示されます。

jaxer_003.png

この画面で、テキストエリアに文字を入力し、「クエリ送信」をクリックすると、index.htmlを配置しているディレクトリに、テキストエリアの内容が書かれたtmp.txtが出力されます。

一度画面を閉じ、再度ページを表示すると、先ほど入力した値が、デフォルト値としてテキストエリア内に表示されます。

というわけで、サンプルコードのコード解説です。

1~3行目

<html>
<head>
  <script src="http://code.jquery.com/jquery.js" runat="both"></script>

jQueryを読み込み、runat="both"で、このコードをサーバとクライアントの両方で利用することを宣言しています。

4~11行目 

 <script>
    jQuery(function($){
      $("form").submit(function(){
        save( $("textarea").val() );
        return false;
      });
    });
  </script>

ドキュメント中のformエレメントのsubmitイベントに、テキストエリア内の値を引数としてsave関数を実行するようにバインドしています。このscriptタグにrunat属性はないので、必然的にクライアント側でのコードとなります。

12~22行目

  <script runat="server">
    function save( text ){
      Jaxer.File.write("tmp.txt", text);
    }
    save.proxy = true;
   
    function load(){
      $("textarea").val(
        Jaxer.File.exists("tmp.txt") ? Jaxer.File.read("tmp.txt") : "");
    }
  </script>

runat="server"なので、サーバ側での関数定義です。

saveは、引数で渡された値を、tmp.txtとしてファイルに書き出します。

loadは、tmp.txtが存在すれば、その内容をページ中のテキストエリアの値としてセットします。

save関数は、proxy=trueとされており、これでクライアント側のJavaScriptからsave関数をコールすることができます。逆に、load関数は指定がないので、クライアント側から呼び出すことはできません。

また、サーバ側で動作するこのコードで、$("textarea").val()と、jQueryのコードが書けているのも注目です。

23~30行目

</head>
<body onserverload="load()">
  <form action="" method="post">
    <textarea></textarea>
    <input type="submit"/>
  </form>
</body>
</html>

bodyタグのonserverloadという指定で、ページ表示時にload関数が実行されるようになっています。

サーバ側でjQueryを使うことで何が便利になるのか?

基本的にjQueryはDOMを簡単に直感的に利用できるライブラリになっており、サーバサイドでの出番はあまりないようにも思えます。

では、サーバサイドでjQueryを使うメリットはどんな点なのか。

1つは、「入力フォームの値をset / get しやすい」という点です。

これは今回のサンプルでも明らかだと思います。

もしjQueryを利用していなければ、値のset / get は以下のようになって、コードも長くなり少々面倒です。

document.getElementById('hoge').value = 'moge';

document.forms[0].hoge.value = 'moge';

もう1つは、「スクレイピングしやすい」という点です。

Jaxerでは、以下のコードで任意のページのHTMLを取得できます。

Jaxer.Web.get(url);

これを利用すると、以下のようにjQueryのselectorを用いて取得したHTMLを操作することができます。

$('selector',Jaxer.Web.get(url))

例えば、ページ中のaタグのhref要素を全部取得する場合は、

     var txt = '';
     $('a',Jaxer.Web.get(url)).each(function(){
       txt += $(this).attr('href') + '\n';
     });

こんな感じで。

このままだと正規表現の方が簡単じゃんってことかもしれませんが、ページ中の特定の部分の中身からurlを抜き出したりとかできて、個人的には正規表現でゴリゴリ書くよりやりやすいです(まあ僕が正規表現苦手なだけですが)。

ただ、jQueryのメソッドすべてがサポートされているわけではないので、注意が必要。

Jaxer付属のサンプルページで、jQueryのユニットテストの動作結果が確認できます。

<関連エントリ>

2008年1月26日

BPMオフ会に参加してきた(飲み会だけ)

BPMのオフ会に参加してきました。

勉強会の方には参加せず、飲み会だけ行ってみるメソッド発動。

Twitterで、「飲み会だけ参加するのありかしら」とつぶやいたら、幹事のid:gothedistanceさんが「OKOK」と返してくれたので決心した次第です。なんかTwitterっておもしろ、と思った瞬間でした。

勉強会の最後にみなさん自己紹介をしていたらしく、そんなのに顔を出していないおいらはひとりぼっち。やはり飲み会からの参加は無謀かと思ったんですが、会社の同僚のpapandaを見つけて一安心。彼の知っている人を何人か紹介してもらいました。

で、この飲み会で分かったことを箇条書いてみると、

  • gothedistanceさんは男前。
  • Yoshioriさんはもてる。
  • java-jaは仲がよい。そして濃い。
  • はぶさんはパワフルである。
  • wicket は面白そうだ。
  • twitterで変なことを発言するとふぁぼられるらしい。
  • そしてふぁぼられると嬉しいらしい。

こんな感じ。

ネット上でブログ読んだり、プレゼン動画見ている人と生で合う感じは、なんか不思議な感じですね。

さて、来週は197Xsのオフ会だ。

java-jaの人たちから「197Xsはおとなしい!もっとエロいことを発言しても良いでしょ!」みたいな突っ込みがあった。まあ1981sの人にないたいわけじゃないから別にいいんじゃね?と思ったけど、エロい話をするのには賛成。

さてどんな集まりになるのか。楽しみ楽しみ。

<追記>

せっかくなのでBPMオフで知り合った人のエントリをメモ(顔とかちゃんと覚えてるかな・・・)

2008年1月25日

Ajax server Aptana JAXERを触ってみた

 最近JavaScriptづいていて、サーバサイドもJavaScriptで書きたいなぁと思っていたところに、AptanaからJAXERなるAjax Serverがリリースされたとのニュースがあったので、渡りに船とばかりに触ってみました。

とりあえず動かしてサンプルを見るまでは超簡単。興味がある人は試してみると良いよ。

ということで遊んでみた内容のメモ。

環境構築

JaxerのホームページのDownloadをクリックして、"Download Jaxer for Windows (.zip)"をダウンロード。

ダウンロード後、解凍して、必要なら任意のディレクトリに移動。

解凍後のルートディレクトリにある"StartServer.bat"を実行すると、http://localhost:8081/aptana/ にアクセスすることができます。※環境によってはセキュリティソフトから、Jaxer やApache がネットワークに接続することを許可しろとか言われます。

これだけでOK。もはや環境構築と呼ぶまでもない簡単さです。

サンプルで遊ぶ

上記URLのページを表示して、左側のSample And Tools をクリックすると、サンプルの一覧が表示されます。

 

jaxer_001.png

サンプルの内容は見たまんま、メール送信やRSS取得、タスク管理、チャットなんかが扱えます。個人的にはタスク管理やチャットが普通にまんま使えそうかなと思ったり。

各サンプルは、画面の右上に「HTML」マークがあって、そこからソースを見ることができます。

 

jaxer_002.png

タスク管理やチャット、wikiにユーザ情報等は、付属のSQLiteに保存されます。つまり、サーバ側で、JavaScriptからDBを操作するAPIが提供されています。

一番下のjQuery Compatibilityは、サーバサイドでjQueryのtest suitsを実行した結果が見られます。そこそこ動くようですが、100%ではないようです。↓こんなメッセージが表示されてます。

PLEASE NOTE: The current jQuery test Suite has a number of tests which currently fail. We are working to extend the test coverage to be as complete as possible.

サンプルをちょっと改良して見たいなと思った場合、サンプルの実ファイルは、<Root directory>/jaxer/aptana/samples にあります。

例えばRSS Sample のRSSの取得先を自分のブログにしてみます。

<Root directory>/jaxer/aptana/samples/rss-sample/index.html の

var feed = Jaxer.Web.get("http://www.news.com/2547-1_3-0-20.xml?tag=pre_ft");

のURLを好きなRSSのURLに書き換えて、アクセスすればOKです。※サンプルページに文字コードの指定がないので、文字化けしてしまうこともあります。

自分でアプリを作ってみる

自分でアプリを作る場合は、<Root directory>/public の下にファイルを配置します。

ページ中にJaxerの読み込みがうまくいくと、

<script type="text/javascript">/** Jaxer clientFramework_compressed.js - 

こんな行が、ページのソース中(上部)に書き出されます。

動的な部分はJavaScriptで定義していきます。

<script runat="server">と書かれたタグはサーバ側で動作するJavaScript、<script runat="client">と書かれたタグはクライアント側で動作するJavaScript、<script runat="both">と書かれたタグは両方側で動作するJavaScriptとなります。

DBに接続してSQLを発行したりするJavaScriptはサーバ側にしか書けません。そこで定義された関数をクライアント側から呼び出すことができます。

例えば、サーバ側の関数hoge()をクライアント側から呼び出したいときは、

<script type="text/javascript" runat="server">
function hoge(){
}
hoge.proxy = true;
</script>

としておきます。最後のhoge.proxy = ture;がポイントです。これにより、ページが生成されるとき、

<script type="text/javascript">
function hoge() {return Jaxer.remote("hoge", arguments);}
function hogeAsync(callback) {return Jaxer.remote("hoge", arguments, callback);}
 </script>

というコードがクライアント側に生成され、クライアント側からサーバ側にアクセスし、結果を受け取るということができます。

注意点としては、クライアント側から呼び出したい(つまりhoge.proxy = trueとしたい)関数は、外部.jsファイルではなく、ページ中に書いてある必要があるようです。(これでちょっとはまりました)

Jaxerのウリ

Jaxerの公式サイトトップページに書いてあることですが、以下の点がポイントになります。

  • アプリケーションを.html と.jsファイルで構築できる。
  • サーバ側で、htmlのDOMにアクセスするような記述ができる。
  • ブラウザとサーバがシームレスにコミュニケーションできる。
  • 既存の他の言語で書かれたページにアクセスできる(既存資源を活かせる)。
  • Validationコードをブラウザとサーバで共有できる。
  • データベースやファイル、ソケット通信がJavaScriptから可能になる。
  • 最新のJavaScript標準に則ってる。

個人的にはValidationコードをサーバとクライアントでシェアできるというのが嬉しいですね。Javaでアプリを作っていて、ブラウザ側のチェックとサーバ側のチェックの仕方が微妙に異なり、それがバグにつながるなんてことが結構起こりやすいので。

ただ、サーバ側のJavaScriptファイルがエンドユーザに見えてしまう可能性があるという点がちょっとだけ気になります。SQLとか丸見えだしね。僕が触ったバージョンだと、サーバのJaxerでエラーが発生したとき、クライアント側にサーバ側のJavaScriptソースがまるっと見えちゃって、これはちょっとと思いました。この辺は今後改善されていくのだろうと思います。

というわけで、これを使ってちょっとしたアプリを作ってみようかなと。サンプルを改造するだけでもそこそこのものができそうですし。

興味が沸いた方は、この土日に是非遊んでみてください。

<参考リンク>

2008年1月24日

英語ブログのススメ

英語ブログのことを書こうと思っていたら、てっく煮のにとよんさんが英語ブログについて書かれていました。

ちょうど良いから便乗します。

Ajaxian で紹介してもらったよ - てっく煮ブログ

実は僕も昨年末から英語ブログをちょろっと書いていて、先日公開したiGoogleテーマエディタが、海外のGoogle情報ブログに取り上げられました。

Editors for Creating iGoogle Themes

Ajaxianほどではありませんが、このサイトもGoogle情報にかけてはそこそこ影響力があるサイトで、Google-maniaさんがこの記事を元に紹介記事を書いていました。

たった2分でオリジナルiGoogleテーマを作れるサイトを2つ紹介 | Google Mania - グーグルの便利な使い方

ってことで、日本のブログで自分が書いた英語のブログが紹介されるという逆輸入的な展開でした。

 

やったこと

まずは紹介するアプリ作り。最初はオール英語だったんですが、以前に多言語対応についてエントリを書いたことがあったので、せっかくなので日本語と英語の2言語でリリースすることにしました。

で、英語の記事の作成にとりかかったのですが、にとよんさんほどまじめに書かず。なんとなく雰囲気で書いてしまいましたよ。なので、正直うんこになってます英語です。うんこクラスの英語です。はい。

しょぼい記事を書き終えたところで、digg.comに投稿しました。

日曜の夜に投稿して、月曜の夜までなんの反響もありませんでしたが、その後上記サイトに取り上げられ、そこそこアクセスしていただいた次第になります。

なんか自分の書いたエントリが、英語ブログに取り上げられていたときはちょっと小躍りしましたよ。An even cooler solutionとか書かれてるし。

 

思ったこと

にとよんさんも書かれていますが、日本のレベルの高い技術が、言語のせいで国内だけにしか知られないのは、やはりもったいないです(レベルが高いってんは、もちろん僕のコトじゃないです)。

ブログの更新が滞る原因として、コメントやトラックバックが少なく、書いてもあまり楽しくなくなってしまうということが挙げられます。その点、海外の人は気楽にコメントを残してくれるので、反応がある感があって、きっと楽しいと思いますよ(僕のブログはこれからですが;)。

あと、以前作ったtimer ガジェットも英語対応させていて、アクセス解析を見ると、ヨーロッパの人や北米の人が使った形跡が分かります。iGoogleユーザもまた、英語圏の人が結構多いので、日本特有のガジェットではない限り、英語対応のことも考えておくと良さそうです。

2008年1月23日

iGoogleテーマエディタのコード解説 --- その2

今日は「Gmailの使い方」メールマガジンでもiGoogle Theme Editor を紹介していただきました。ありがとうございます。

というわけで昨日のコード解説の続きです。

 

150~202行目:エディタ自身のHTMLです。

多言語対応させるメッセージ部分はmessage(key,lang)で返ってきたメッセージを結合させています。なんか眺めれば眺めるほどリファクタリングできそうだなぁと思ってきましたよ。

 

203~245行目:スタイルオブジェクトの定義とスタイル指定。

エディタのCSSをJSONで定義しています。jQueryは、$.css(key,value)や$.css(styleObj)で簡単にスタイルを指定できるので、外部にCSSファイルを持たないようにしています。

また、226~230行目では、各ブロックの開け閉めを$.toggle(fn,fn)で設定しています。これまた簡単ですわ。

var deco = {"cursor":"pointer","text-decoration":"underline"};
$('#str_1').css(deco).toggle(function(){$(this).text('[-]'+message('m1',lang));$('#tbl_1').show();},function(){$(this).text('[+]'+message('m1',lang));$('#tbl_1').hide();});

 

246~284行目:テキストエリアやセレクトボックスで値を入力/選択したときに、即座にiGoogleの画面に繁栄させるようにしているところです。

Class名とかはFireFoxのfirebugでちまちま調べながら作りました。

$('#header_bgcolor').keyup(function(){try{$('#nhdrwrap').css('backgroundColor',$('#header_bgcolor').val())}catch(e){}}).val('#FFFFFF').keyup();

あと、上記のように、テキストエリアにkeyupイベントで実行される関数を割り当て、それをkeyup()で実行できることを知りました。超便利。上記部分は、jQueryオブジェクト取得→keyupイベントに関数割り当て→初期値設定→keyupイベントに割り当てた関数を実行という流れになっています。これがつらつらとメソッドチェーンで書けちゃうのが気持ちよいです。さすがjQuery。

 

こうやって解説を書きながら、かなり無駄に書いている部分が多いなぁと思ったので、リファクタリングしていこうと思います。

なんか2日に分けて書くと言いつつさらっと終わっちゃいました。

2008年1月22日

iGoogleテーマエディタのコード解説 --- その1

先日公開した「iGoogleテーマエディタbookmarklet」をWebOS Goodiesさんで取り上げていただきました。ありがとうございます。

で、今日はbookmarkletのコード解説をしたいと思います。といっても、たいしたソースじゃないですが。

(※行数はversion 0.1.0 でカウントしているので、後から見るとずれるかもしれませんが雰囲気で追ってください)

1~11行目:コメントです。

12~18行目:

var jq=document.createElement('script');
jq.id="jqery";
jq.type="text/javascript";
jq.src="http://igoogle-theme-editor.googlecode.com/svn/trunk/iGoogleThemeEditor/dist/jquery-1.2.2.min.js?"+new Date().getTime();
document.getElementsByTagName('head')[0].appendChild(jq);

いきなりjQueryのjsファイルをheadにappendしています。今回はデザインを色々といじるってことで、ライブラリを読み込んだ方が都合が良かったのでそうしました。jQueryを選んだ理由は、ファイルサイズが小さく、グローバルなオブジェクトを汚染せず、かつスタイルの操作がやりやすいからです。

19~22行目:

var jqueryStartTimer;
if(!jqueryStartTimer) jqueryStartTimer = setInterval(themeEditorload,500);

続いて、iGoogleテーマエディタを表示するために、setIntervalで定期的にthemeEditorload()を実行します。即実行できないのは、scriptタグで後からappendしたjsファイルが、ロードが終了し、ページ上でコンパイルされるまでタイムラグがあるからです。

23~31行目:

function themeEditorload(){
try{
if($){
 clearInterval(jqueryStartTimer);
}else{
 throw new Exception();
}

メインメソッドです。$をチェックし、定義されていれば(if($)でtrueが返れば)、setIntervalで定義したタイマーをclearIntervalでクリアしています。もしこの関数が実行されたとき、まだjQueryがロードされていなければ、Exceptionをthrowしてスルーします。

32~46行目:URLを操作する現在開発中のjQueryプラグインです。まだアルファ版にもならない完成度ですが、試しに使ってみることにしました。

47~61行目:iGoogle Theme 用のXMLの元データです。文字列の最後に\を付ければ改行できることを知ったので、そういう風に書いています。

62~65行目:

function createAttr(id,attr){
 if($('#'+id).val()) return '<Attribute name="'+attr+'">'+$('#'+id).val()+'</Attribute>\r\n';
 return '';
}

この後のcreateXML()の中で使っている関数です。iGoogle Theme 用のXMLを作る際、ユーザが値をテキストフィールドに入力していれば、引数のデータを利用してXMLデータの一部を返します。

66~102行目:XMLを生成している部分です。思いっきりベタ書きです。

103~104行目:

var lang = $.urlParams('lang',$('#igteid')[0]);

ここで、先ほど紹介したURLを操作するプラグインを利用しています。このブックマークレットをappendしているscriptタグのsrc属性のURLから、GETパラメータに指定されているlang属性を取得しています。

105~141行目:ここで多言語のメッセージオブジェクトを保持しています。そう、このbookmarkletは無駄に多言語対応させているのです。

142~149行目:

function message(key,lang){
 try{
  var t = words[key];
  return (t[lang])?t[lang]:t['en'];
 }catch(e){
  return '';
 }
}

メッセージオブジェクトから、言語名とキー値を元に、メッセージを取得します。デフォルトは"en"の値です。

 

長くなったので、今日はここまで。続きはまた明日。

2008年1月21日

就職活動は「縁」です

なんか就職活動のことについて盛り上がっているので、僕も少し絡んでみます。

こういうとき、会社ばれしていると書きづらいね。まあ、あくまでここに書くことは、僕個人の考えであって、会社は関係ないということで。

就職活動を終えた先輩の皆さん。あなたは後輩に「こうすれば絶対内定取れるぞ!」と、どのようにアドバイスしますか?

そんなアドバイスしません。求められても断ります。

ものごとに「絶対」なんてことはないしね。そもそも会社によって採用担当者が違うんだから、こうすれば絶対、なんてことは言えないでしょ。

そんな優しさのない社会人の先輩である僕が、これから会社を受けるという学生さんにお話しできることは、就職に関する自分の経験しかないです。僕の話からどんな教訓や法則を感じ取るかは、学生さんにおまかせします。僕が話す内容は、相談してきた学生さんに合わせるので、「これを話す!」みたいなことは書けないかな(ずるいね)。

学生のみなさんは、なるべくたくさんの社会人の先輩に、就職活動の話じゃなくて会社生活のことを聞いて回ると良いと思うよ。日中どんなことしているのかとか、就職活動のときの社会人生活のイメージとどう違うかとか。

テクニックを駆使して、良い会社と思っていたところに入ったは良いけど、思い描いていた仕事じゃなくて、なんか話ちがくね?みたいになっている人、世の中には多いと思うよ。新卒3年以内に辞めていく人の中には、そう言う人も大勢いるんじゃないでしょうか。

 

ここで、昨年、一昨年と、グループ面接/ディスカッション(以下、グループ面接)の面接官として、新卒採用のお手伝いをさせてもらったときのことをちょっと書きます。

うちの会社では、現場の人間から活きの良いのがピックアップされて、グループ面接の面接官を担当するのが恒例になっています。

オリエンテーションがあって、グループ面接の方法とか、学生さんの評価の仕方とかを一通りレクチャーされます。

で、月に何回か会場に呼ばれて、面接官をするわけです。 

面接官を経験して、色々とおもしろいことに気づきました。

1つは、評価の仕方は人それぞれであるということ。

よく、「短所は長所の裏返し」みたいなことを、自己PRを作るときにアドバイスされますけど、まさしくあれ。

とある学生さんがやってきて、僕の目から見ると、ものすごく傍若無人だったわけです。言葉遣いも横柄だし、発言の端々になんか亀田家のビッグマウス的雰囲気を醸し出している。で、面接が終わった後、ペアを組んでいた面接官と学生さんの評価をすり合わせるんですが、そこでペアを組んだ彼は、僕が「こいつはちょっと」と思ったその学生さんを「大物感が漂っていて良いね」と評するわけですわ。評価が180度逆なの。へー、そういう風に見る人もいるんだなぁと思ったものです。

もう1つ、採用活動の中で分かったのは、「一緒に働きたいかどうか」が基準になるということ。

学生さんの評価が割れたり、グループの中で順位を付けるのに迷った場合は、「その学生さんが自分の後輩として職場に入ってきてやっていけそうかどうか」ってことで判断していきました。ものすごくファジーな基準だけど、意外と重要なことで。

Googleも、中途採用で面接に来た人は、職場のメンバーに顔通しして、一緒に働け想かどうかを判断するという話がどこかに書いてあったし。この辺は新卒だろうが中途だろうが関係ないところだと思う。

自分と合った採用担当者に出会えればラッキーだし、まったく合わない採用担当者であればその会社には縁がなかったと思うしかないんじゃないかな。

なかなか内定がもらえない人は、それで落ち込むんじゃなくて、まだこれから良い出会いがあると思って活動しましょう。就職活動で落ちまくると、自分の人格が否定されたみたいに感じて落ち込んじゃう人がいるらしいけど(僕もそうでしたわ)、それはまったくナンセンスですよ。縁です、縁。だから胸はって自信を持って活動に挑んでください。

 

採用担当者のファジーな感じで決まってしまうことに納得できない人は、経験したことのある何かの(例えばサークルとか)勧誘活動を思い出してください。

そのとき、あなたはどんなことを基準にして、その子を勧誘していましたか?

どんな子に「うちのグループに入って欲しいなぁ」と魅力を感じ、どんな子を「この子はちょっと・・・」と敬遠していましたか?

まったく同じではないにせよ、採用担当者も似たようなことをきっと感じるのだと思います。

 

他にも色々と気づいたことはあるのだけれど、長くなるので今日はここまで。

 

とまあ、これってやっぱりそこそこの大きな企業の採用だね。採用人数が少ないITベンチャーとかは、もっと違う採用基準が明確にあるのだと思うよ。

#読み返してみると超gdgdですな。

2008年1月20日

iGoogleのテーマXMLを作成するbookmarklet

先日公開されたiGoogle Theme API を便利に使うためのbookmarkletを作ってみました。

iGoogle のページで実行すると、テーマ変更用のエディタが表示されます。

iGoogle Theme Editor (←右クリックからお気に入りに追加できます)

javascript:var s = document.createElement('script');s.id="igteid";s.type="text/javascript";s.src="http://igoogle-theme-editor.googlecode.com/svn/trunk/iGoogleThemeEditor/dist/ige.js?lang=ja&"+new Date().getTime();document.body.appendChild(s);void(0);

例えば、↓こういうデザインにしているiGoogleの画面でbookmarkletを実行します。

igte_0001.png

すると、適用されているデザインがクリアされて(そう言う風に見せかけているだけですが)、↓こんな画面になります。

 

igte_0002.pngガジェットのエリアの左側に、iGoogleのテーマを編集するエリアが表示されます。それぞれのリンクをクリックすると、編集エリアが表示されます。

 

igte_0003.png
「ヘッダ部分」をクリックすると、ヘッダエリアのデザインを変更することができます。画像のURLを指定するところには、サーバにアップロード済みの画像のアドレスを入力してください。画像を使用しない場合は空欄でかまいません。

 

igte_0004.png

以下、同様に「タブ部分」「ガジェット部分」「フッタ部分」を変更できます。

 

igte_0005.png

 

igte_0006.png

 

igte_0007.png
入力した後、「XML生成 >>」をクリックすると、テキストエリアに現在適用されているテーマのためのXMLが表示されます。

 

igte_0008.pngこの内容を、テキストファイルにコピペして、適当な名前を付けてxmlとして保存してください。

保存したxmlをサーバにUP(サーバを持っていない人は、Google Codeにホスティングすることができます)して、↓以下のようにURLを指定すると、xmlのデザインを確認することができます。

ちなみに、超簡単ですが、↓僕が試しに作った白黒のデザインのxmlです。

http://www.google.com/ig?skin=http://www.chrisryu.com/data/igoogle_theme/blackandwhite.xml

作ったXMLを公開したり、コンテンツディレクトリに登録する際は、XMLの以下の部分を編集してください。

<ConfigMap type="Skin">
<Meta name="title">theme title</Meta>
<Meta name="description">theme description</Meta>
<Meta name="author">author</Meta>
<Meta name="author_email">email</Meta>
<Meta name="thumbnail">thumbnail url</Meta>
<Meta name="screenshot">screenshot url+</Meta>
</ConfigMap>

こんなツールは、もっと使い勝手が良くて便利なものをGoogleが提供してくれそうですが、jQueryの練習のために(jQuery読み込んでます)作ってみました。

内容の解説は、また別のエントリで。

2008.1.21 12:15追記 動作確認しているブラウザは、IE7 & FF2です。IE6だとデザイン崩れちゃいます。ごめんなさい。

2008年1月19日

2007年に人気伸びたのはPython、Ruby/Perlは微減

Pythonキター!(ってほど日本での人気は伸びてないけれど・・・)

2007年に人気伸びたのはPython、Ruby/Perlは微減 - builder by ZDNet Japan

この1年でPythonは2.04%の伸びを見せ、もっとも人気が伸びたプログラミング言語となった。ほかにはVBが1.84%、Javaが1.69%、C#が1.34%、PHPが1.25%、Delphiが1.00%、JavaScriptが0.36%人気を伸ばしている。

VB、C#とかも伸びてるんですね。そっち方面の言語には全くうといので・・・。

JavaScriptが以外と伸びていないのでちょっと驚き。jQueryの人も、海外ではJavaScriptの人気は今ひとつみたいなことを、WEB+DB PRESS のアルファギークに逢いたいで言ってたし、そうなのかな。

人気言語Pythonの技を身につけよう - builder by ZDNet Japan

上記リンク先は、builder 中のPythonに関する情報のリンク集になっているので、Pythonやるときに参考にしてみます。 

2008年1月18日

Google Maps の航空写真刷新

Google Maps とGoogle Earthで、都市部のマップタイルが刷新されました。

Google Japan Blog: Google Earth と Google マップの航空写真がさらに新しく、鮮明になりました

東京 23 区、名古屋市、大阪市の 3 地域の画像がこれまでよりも新しい画像に更新されています。さらに!今回の更新では画像の解像度をこれまでよりぐっと高め、かなり詳細なものにしました。 一段と綺麗になった画像で街の詳細をぜひ確認してみてください。初めての場所を訪れる際も、これで細かく周辺などもチェックできますね。

ってことで、マップを見てみると、確かに綺麗になってました。ビル群とかズームしてみると気持ち悪いくらいに綺麗ですね。

 

うちの近所(JR田端駅前)には、桜並木があって、春になるとそれはもう綺麗なんですが、その周辺の写真がちょうど桜が咲いているときに撮影されていました。

JR田端駅前の桜

なんか、上から見るともさもさして変な感じですね。

 

神宮球場では何かの試合をしているっぽいです。 

 

高解像度になっているので、こういう球場の写真を使ってゲームとか作れそうな気がします。

 

もっとあちこち見て遊んでみよ。

2008年1月17日

iGoogle Theme API

iGoogleのテーマをカスタマイズできるiGoogle Theme APIが公開されました。

iGoogle Theme API

使い方は簡単で、xml に色や画像のURLを指定して、コンテンツディレクトリに登録の申請をすれば良いだけです。

作成したxmlは↓以下のようなURLで確認することができます。(下のサンプルはGoogleが提供しているサンプル)

http://www.google.com/ig?skin=http://gadget-doc-examples.googlecode.com/svn/trunk/themes/theme_simple.xml

リファレンスは↓こちら。

http://code.google.com/apis/themes/docs/reference.html

ガジェットが開発者向けのカスタマイズ機能だとしたら、Theme APIはデザイナー向けのAPIと言えるのではないでしょうか。

xml の中で、TraitというタグにTimeOfDayとして、時間を指定することができます。なので、朝は明るいデザインで、夜は暗いデザインにする、といった切り分けが可能です。

このTraitに指定できるのは、今のところTimeOfDayだけですが、既存のテーマを見ていると、曜日に応じてデザインを分けたり、天気に応じてデザインを分けることが、近いうちに可能になるのではないでしょうか。

 

iGoogle のデザインで検索してみたら、↓こんなガジェットを見つけました。

Custom iGoogle Skins

このガジェットを登録すると、Theme APIよりもっと自由にデザインをカスタマイズできるみたいです。

iGoogle Version2.0用のSkinと書かれていますが、普通に使えるみたいですね。

(iGoogle Version 2.0 になると、各ウィンドウの「開く」「閉じる」等のメニューが「Menu」という文字リンクにまとめられるみたいです)この辺よく分かってないからとりあえず削除

コンテンツディレクトリに登録されているより多くのデザインが公開されていて、↓マリオとか、

20080118_02.png

↓FireFoxとかあります。(ロゴもFireFoxが入っているのが良い感じ)

20080118_01.png

おもしろいテーマがたくさん登場すると良いですね。

2008年1月16日

Apache Wicket

↓このエントリ読んでWicket 使いたくなっちゃいましたよ。

ウェブ・アプリケーションの革命がここにある - Apache Wicketユーザーグループを始めます - 矢野勉のはてな日記

そういやJavaのフレームワークって、がっつり使ったことあるのstrutsくらいだもんなぁ。

Tapestryは、2年くらい前にSNS作って(友達登録くらいまでしかできなかったけど)それっきりだし、Seaser2 もやりたいやりたいと思ってちゃんと触ってないし。

その発想の根底にあるのは、デザインとプログラムのほぼ完全な分離と、「JavaプログラマはJavaで書くのが一番楽なんだ」という考え方です。WicketはHTMLはHTMLのまま、HTMLエディタで編集できる形式のままテンプレートとして使用します。Wicketは各種設定をすべてJavaソース内で行います。Wicketはウェブ・ページをステートフルにし、デスクトップアプリケーションを作るときのように、普通にインスタンス変数を使えるようにします*1。Ajaxによる画面のコンポーネント更新を、JavaScriptではなくJavaソースから行うことが出来ます。

そうだよねー。やっぱ言語は1つの方が作りやすいよねー。

そういう意味では、サーバサイドJavaScriptにも興味があります。

Wicketおもしろそうなんだけど、Javaアプリは、作ったアプリを簡単に公開できない(スクリプト言語に比べて)という点でちょっと二の足を踏んじゃうんだよなぁ。

安くでJavaのアプリをホスティングしてくれるサーバはないものか。

自前サーバ立てちゃうか? それはそれで結構な決心が必要なんだよね。