rubyで言うところの

File.dirname(File.expand_path(__FILE__))

を、bashでやりたかったのですが、今まで適当に誤摩化してました。こたえはこちらにありました。

Bashシェルスクリプトで自分の絶対パスを取得

echo $(cd $(dirname $0);pwd)

shの理屈はよくわかってないのですが、どうやらこういうことのようです。

1. かっこ()内はサブシェルになるらしく、cdしても外側には影響がない
2. $は括弧内の出力を文字列として展開する

なるほどなるほど。

追記：

と、思ったんですが、$()が単にバッククオートと同じ動作をするということっぽいです。単純に左右の対応がとれるので、バッククオートを入れ子にするようなややこしい事をするよりは簡単みたい？

で、なんとなくメモリを見てみたら、相当X関係がメモリの無駄遣いをしている（様に見える

実際はcacheなので気にすることもないかなぁと思ったのですが、いらないので終了させてみました。

sudo /etc/init.d/gdm stop

これでOK。

ちなみに、モノは試しでcacheをクリアするには。

echo 3 > /proc/sys/vm/drop_caches

でいけるらしい。

ext/readline % ruby extconf.rb

checking for tgetnum() in -lncurses… yes

checking for readline/readline.h… no

checking for editline/readline.h… no

checking for tgetnum() in -lncurses… yes

checking for readline/readline.h… no

checking for editline/readline.h… no

extconf.rbを開いてみたらオプションを発見したので試してみたらこれでいけた。

ext/readline % ruby extconf.rb –enable-readline-v6

これで解決。

ので、簡単なパッチを書きました。

もし困ってる人がいたらご利用ください

# よくよく使ってみたらSEGVしまくるので、あまりオススメできないかもしれないです

実はtwitterは2回、mixiも2回ほどすでにやめたことあるんですが、その度になんとなく復活してました。
やっぱり友達に連絡するには便利ですよねアレ。

twitterとかは割りと積極的に発言したりしていて760くらいフォロワーがいたりもしたんですが、自分があまり気のきいたこと言ってないのもあるかもですが、おもしろい発言とかからみが帰ってくるわけでもなかったです。

あんまり面白く無いしtogetterやまとめページを見る方が早いし有益だなぁと思いました。

自分が書くにしても、twitterとかで適当な釣り発言しているよりは、blogとかできちんとまとめて書く方がきっと有益だろうなという気もしました。

ご連絡の際は、facebookかskype, メッセンジャーでどうぞ。

gyazoって知ってますか？masuiさんが開発された驚異的な便利ツールです。
実はこれGPLでオープンソースになっています。

自宅サーバでgyazoを運用するためのtipsです。
当方macなので、クライアントがmacでserver側はrack(rubyのアプリケーションコンテナ)を使うようにしています。

さて、自宅サーバでgyazoをするメリットとは。

• 情報漏洩リスクが低い
• basic認証かけたりできる
• 社内の情報共有ツールとして使う
• ログがとれる

などなどでしょうか。

情報漏洩リスクは、低いと言えば低いんですがgyazo.comは本質的には情報漏洩リスクがあります。
どっかの会社ではあまり気にしないで使われてるんですが、twitterがコンプライアンス違反ならこっちの方が余程リスクが高い気もします・・・・（細かい話はまた別で

だから、自分で運用するgyazoをたてましょうということです。

ちょっと運用上の問題からオリジナルのgyazoから多少の変更をしています。

手順は

1. 私のgithubからチェックアウト
2. クライアント側のパスワードとサーバのアドレス設定
3. サーバ側にrackをデプロイ

こんな感じです。

githubからチェックアウト

私のgithubからチェックアウトするかフォークするかしてください。

git clone git://github.com/harajune/Gyazo.git

するとソースが落ちてきます。

クライアント側の設定

ほとんどの人はwindowsなんでしょうけど、自分はmacなのでmacの説明。
一応windowsもソースみたんですが多分簡単に出来そうな気がします。

以下の要領でクライアントの設定をしてください。

cd Gyazo.app/Contents/Resources
cp config.sample.rb config.rb
vi config.rb

viじゃなくてもいいですが。config.rbを以下のように編集します。

HOST=”your.domain.com”
CGI=”/upload”

CGIの方はアップロードの時に使うパスです。一応デフォルトがこれです。

これでクライアントの設定は終了。

サーバにrackを設置

アプリケーションコンテナは好きなのを使ってください。私はpassengerを好んで使っています。

Serverディレクトリ以下を適当なrackコンテナの場所に設置してください。basic認証とかしたく無ければこれで終了。

終わり

以上です。open Gyazo.app とかしてgyazoってみてください。
たぶんちゃんと動くはずです。

実はちょっとだけ改造してあります

本家gyazoはCGIでの運用が前提になっているので個人的には扱いにくいです・・・・
ので、harajuneバージョンではrackに対応させてあります。

まぁ大した差はないんですが、ほとんどのrubyアプリケーションコンテナがrackに対応していますし、cgiって個人的には運用が面倒なのでこちらの方がいい気がしています。

というわけで、楽しいgyazoライフを！

使ってる環境がruby1.9.2trunkとrails3.0betaなんですが、残念ながらredmineはrails2.3.5とruby1.8.xでしか動かない。

とりあえず動かしてみたところ、基本的にひっかかるのは文字コード周りであることがわかったためちょっと修正してみたらだいたい動く感じになりました。

ポイントは

• gitを使う
• rails2.3.5をvendor/railsに入れる
• Stringを拡張する
• Encoding.external_encodingをUTF-8にする
• postやgetの値paramsを全部force_encoding("UTF-8")する

です。

gitを使う

redmineを直接いじるのでバージョン管理する方がおすすめです。

git clone http://github.com/edavis10/redmine.git

このgitリポジトリはofficialミラーだそうです。

rails2.3.5をvendor/railsに入れる

git submoduleが便利です。

git submodule add http://github.com/rails/rails.git ./vendor/rails

そして、railsの中身をv2.3.5にします。

cd vendor/rails/
git checkout -b v235 v2.3.5

これでok。

Stringを拡張する

String.eachが1.9では無くなっています。代わりにeach_lineを使えばいいんですが、全部書き換えるのが面倒なので、config/environment.rbに書いちゃいます。

config/environment.rb

PLAIN TEXT

CODE:

1. class String
2. def each(*args)
3. self.each_line(*args)
4. end
5. end

class String

def each(*args)

self.each_line(*args)

end

end

Encoding.external_encodingをUTF-8にする

いらないかもしれない。config/environment.rbに書き込みます。

config/environment.rb

Encoding.default_external = "UTF-8"

app/controllers/application_controller.rb

PLAIN TEXT

CODE:

1. before_filter :params_filter
2.  
3. def params_filter
4. self.utf8nize(params)
5.  
6. end
7.  
8. def utf8nize(obj)
9. if obj.is_a? String
10. obj.force_encoding("UTF-8")
11. elsif obj.is_a? Hash
12. obj.each {|key, val|
13. obj[key] = self.utf8nize(val)
14. }
15. elsif obj.is_a? Array
16. obj.map {|val| self.utf8nize(val)}
17. else
18. obj
19. end
20. end

だいたいこんな感じでruby1.9でもredmineが動くようになりました。

とりあえず動かないところ見つける度に直してるのであまり網羅的ではないかも。

一応githubでコードは晒してあります。

あまり具体的な企業名とか自分のスペックについて書かないのであまり面白くは無いかもですが、誰かの役に立つかもしれないと思い書いておこうと思います。

1, 就職活動は戦略が大事

思いつきでうけると間違いなく泥沼化します。
思ったよりもガンガンお祈りメールが来るものなので、わかってても結構落ち込みますし周りが内定で始めると焦ります。
そうした時に慌てて適当にES書いて出したりすると、時間も取られるはお祈りメールは増えるはでいいこと皆無です。

企業によっては（公的には言わないものの）OB訪問が事実上必須になっているところもあります。知ってる範囲でも生保は新入社員が事実上のリクルータになっているところがありますし、どこぞやの有名企業はOB訪問の結果を人事に提出させられるところもあるそうです。
OB訪問に参加しないと出れないイベントがあったり、イベントに出ないとうけられない選考があったり・・・・どんだけ隠れルートがあるのか想像もつきません・・・・・
だからこそ、思いつきでうけることはできるだけ避け、行きたい会社の情報をいかに集めるかが重要になっていきます。
ある程度就職活動が始まる前に、どういう企業をうけるか程度は考えておきましょう。

2, 友達は大変重要

OBの共有したり、隠れイベントの情報を共有したり・・・・・本当にこれ重要です。
ネットに書いてあることは情報が遅かったり、そもそも公開できる情報しかなかったりしますし、そもそもググる時間がかかって面倒です。
自分たちは友達同士でグループチャットを作り、「あそこの選考どうだった？」とか「ESこういうのは通ったけどアレはダメだった」といったことを即時共有していました。
こういう情報は、ネットで調べるよりも100倍信用できますし情報も早くていいです。

3, webテストは必ず対策しよう

あんまり具体的には書きませんが、どこの会社がなんのwebテストを利用しているかというのは市販の書籍にまとめられていたりします。びっくり。

しかも、そのwebテストもひどいもので、問題の数があまりにも少なく3,4回うけると問題が重複しはじめて問題文読まなくても解けたりします・・・・・・
webテスト対策本は過去の問題を再構成していたりするので、ぜひともやっておくことをお勧めします。
また、webテストの練習のためだけに何社かうけておくのもいいかもしれません。本命をうける頃には知ってる問題だらけに・・・・とかいうこともあり得ます・・・・・

テストによっては、紙でうけてもwebでうけても問題が一緒だったりすることもあり、webテストはやればやるほどお得になります。

4, コネ重要

例えば、入りたい会社でアルバイトとかしてると筆記免除になったりします。
会社によってはそのままいつのまにか採用で終わります。友達でも何人かはこのパターンがいます。
自分も、就職人気ランキングに入るような商社で「もしうちにきたいなら人事部長紹介するよ」と言われたことがあります（結局お願いはしませんでしたが）
そういう感じで、一番理想的なのは興味のある業界や会社でアルバイトしたりインターンしておくのが一番いいと思います。
一応念のために言っておきますが、そういうコネで何かお願いして内定取ったらちゃんとその会社入りましょう。その後の人間関係に響きます・・・・・
断るかもしれないなら最初からお願いするのはやめておくのが人の道という気がします（※個人の感想です）

とは言っても就職活動なので、向こうも「そういうものだ」という心づもりでOB訪問受け入れてるところもあるので、そういう常識的な判断が出来ないならお願いしておいた方が日本企業全体としては正解な気がします。

5, 学生時代は「仕事しながら遊ぶ」のが一番いい

周り見てると、自分も含めベンチャーでお仕事したり会社作ってつぶしたりとかしてる人の方が就職活動うまくいっているように思います。
結局は相手の言ってることがわかったりとか話が通じることが重要なんだなと。
自分もなんか結局IT関連企業以外もいくつかうけてみましたがサッパリでしたし・・・・・逆にITの企業だと談笑して特になにか面接するわけでもなく通るんですよね。
グループディスカッションとかしても、結局打ち合わせとかに慣れているかどうかで出来が全く違うように思います。

なにか、課題が出された時もその業界で何かしてれば過去に使った資料とかを使ってそのままやれば大概通ります。

プログラマがプログラム書いたら負けですよね（キリッ

とか言っても通ります・・・・・こういうネタが通るくらいまでよく事情知ってれば通るんじゃないでしょうか。

6, グループディスカッションのコツ

グループディスカッション3回しかしてないですが、全勝してます。自分の何が良かったのかはよくわからないですが、自分がグループディスカッション中に指摘したり気になったりしたことをいくつか。

• 大抵の場合、まとめ役がいない
• 大抵の場合、目的が達成されていない
• 大抵の場合、みんな意見を曲げない

大抵の場合、まとめ役がいない

まとめようとする人はいるんですけどね。ファシリテーションの本とかを読むと大抵書いてあると思いますが、まとめ役に重要なことはとにかく「受け入れる」ことです。
ホワイトボードでも紙でもいいので、誰かが言ったことは必ずどこかに書き留めましょう。不思議とこれだけで発言者に納得感があるようです。

次に、意見を戦わせては行けません。やってみればわかりますが情報少ないので「どちらが正しいかを論理的に説明する」とか不可能です。
まず考えるべきは、単純に2つの意見をくっつけます。日本語はだいたい文が長くなっても読めます。違和感がないレベルではどんどんくっつけましょう。
その次は、場合分けをしましょう。「これこれこうだったらAが正しいね」「これこれこうだったらBが正しいね」という感じにします。
私はこの発想の元に、結論をでっかいワークフローにまとめて発表したことがあります。誰も文章にしろとはいってないわけでセーフです（もちろん通りました）
こういう思考フレーム（笑）は、最近勝間和代という人が色んな本でまとめてるそうですが、普通にファシリテーションとしてはよくある話で、学生団体とかで不毛な議論に辟易してる人は読んでみるといい気がします。（実際自分はそういう理由でちょっと勉強したりして、地味に色々やってました）

大抵の場合、目的が達成されていない

大抵の場合、お題に対する結論が出たところで満足して終了することが多いようです。
けど、ほとんどの場合与えられた課題は「発表しなさい」ですよね。
だから常識的に考えるとプレゼンテーション作るところまでがお仕事です。

全員がそこまでの全体感をもってGDできないと時間が無くなってしまうので、ほとんどの場合は無理なんですが、1回だけ時間が余ることがあったのでプレゼンテーションの内容検討まで全部やってみました。
そしたら社員の人に「突っ込むところがない・・・・・」と言わしめるクオリティにまではなりました。余裕があったらここまでやってみたらいい気がします。

時間が余ったからプレゼン内容について検討しようよ（キリッ

実は言ってみたかっただけです（ぉ

大抵の場合、みんな意見を曲げない

これは最初のと一緒ですが。
とにかく他人の意見を受け入れることを最優先しましょう。とにかくどっかに書くだけでも納得してくれます。どっかに書いておけばその人は同じことを二回も三回も言いません。
その人の思考を1ステップすすめてあげることが重要です。

脳はそんなにたくさんのことが考えられないため、とりあえずその人の考えを脳の外に出してあげるとその人の考えが前に進みます。
「なんだこいつしつこいな」と思ったら、意見を否定するのではなく、その人の考えを脳から出して思考を前に進めてあげることを考えましょう。

7, 就活だけでなく学生生活全般について。就社ではなく就職。

実はこれが一番難しいんだと結果的に思うのですが、要は自分のやってみたいことをやってみるということです。
留学行きたい人はさっさといってくればいいし、ゲーム作りたい人はゲーム作れば言い訳です。

自分は最初IT関係でプログラミングしてみたいと思って、大学一年の頃にプログラミングのバイトを探してプログラミングを覚え、起業とか面白いかなと思って学生ベンチャーに入って、これだったら俺でも出来るだろうjkとか思ってさっさと独立してやってみたけどなんか違うかなぁと思って今に至っています。
結果的にIT好きでプログラムも組めるんですが、プログラマとか開発者ってなんか違うなぁと思い、最近はプログラミングをする傍らひとつメタレベルでの活動をしています。フレームワーク導入したりデプロイ方法を工夫したりチケット管理をやってみたりetc,etc。

結局そういう感じで色々やってくうちに就活の時期にやってくると、それなりにやってることにあった会社に入れるんではないかなという気がします。

結局いつかは働かないと行けないわけですから、研究者になるにしても営業になるにしても自分の興味のあることをさっさとやってみるのがいいのかと思います。

学生団体なんかやってると「就活に有利になるから」とかで入ってくる人もいるんですが、結果を見ると確かに有利になってるのかなという気もします。
けど、学生団体やってない人も結局似たような結果になっている気がするので、あまり関係ないのかなトイウ気もします。
正直わかりません（ぉ
それよりは、環境に興味があるとか国際関係に興味があるとか、ちゃんとそういう理由があってそういうところに参加する方が結果的にうまくいくように思います。

それに、いずれにしても社会の歯車として働くことになるわけです。で、あれば、自分で歯車を回す原動機付き歯車として職業に就く方が会社の歯車として回されるよりもきっと楽しいんじゃないかなという気がします。

Css Spriteという手法をご存知ですか？
画像の部品をひとつの画像にすることで、セッション数を節約したり圧縮効率を上げたりする手法です。
こうすることによりwebページがより素早く表示されるようになり、ユーザはハッピー！ということらしいです。
ものすごい負荷がかかるほどの大規模サイトじゃない限り、大抵の人には関係ない代物ではあります。

この画像を作るために通常はデザイナが苦労して画像を合成するらしいです・・・・お疲れさまです・・・
何が大変かというと、デザインが変更になる度に画像を合成しCSSを書き換え・・・・死にたくなりますね。

そこで例えばこんなツールがあります。CSS Sprite Generatorは、画像一式をzipで圧縮して投稿すると冒頭の画像のように合成してくれその上CSSまで作ってくれるという優れものです。
けど、結局デザインって画像とか文字色とかを微調整することがなんどもあり、その度にここにアップロードしてチェックしてとか大変ですね。

はい。そこで作っちゃいました。普通に作ったwebページを放り込めば勝手にCSS Spriteをしてくれるスクリプト。
まだベータで凄く単純にケースにしか対応していませんが、作り込めば大抵のサイトで使えるようにできる見込みがあります。
またとりあえずの実験ということで画像の配置に関しては最適化をしていません。（余談ですがこれは長方形詰め込み問題として知られており、いわゆるNP困難な問題です。しかし結構歴史ある問題でさまざまな解放があります。）
作り込むかどうかは様々な要因（就職活動とかバイト先との兼ね合いとか）と気分で変わります。

今回は、mixiさんの会社概要ページで実験させてもらいました。
まず、wgetでソースを丸っととってきます。

wget -k -p http://mixi.co.jp/

すると、index.htmlと関連する画像やCSSが取得できます。
つぎにこれを作成したスクリプトに突っ込みます。

ruby css_spriter.rb src/mixi.co.jp/index.html dest

すると、スクリプトが自動的にHTMLを解析し、imgタグをdivに置き換えるとともに画像合成まで行い、CSSを作成しそれを読み込んだHTMLを作成してくれます！
before/afterのソースコードとか晒せたらよかったんですが、一応他人様のサイトなので自重して結果と部分的なコードだけ示します。

まず、これがビフォア。

で、こちらがアフター。

えぇっと違いわかりませんね(^^;;;;  ほぼ完璧な置換が出来ています。

詳細を見てみましょう。結合した画像はこんな感じ。とりあえず今回は最適化を行わず並べるだけにしてあります。これは長方形詰め込み問題を解くことで効率よく並べられることがわかっています。

次に自動的に作成されたCSSを部分的に。

#globalnavi_company001_off_gif{
display: block;
width: 178px;
height: 36px;
background-image: url(../images/sprites.png);
background-repeat: no-repeat;
background-position: -0px -107px;
}

これはちょうど「会社情報」と書いてある画像の部分になります。

具体的にどういう風に置換されるかというと、

<img height="36" width="178" alt="会社情報" src="http://mixi.co.jp/wp-content/themes/mixicojp2009/img/globalnavi_company001_off.gif">

という部分が、

<div id="globalnavi_company001_off_gif">&nbsp;</div>

こんな感じに置き換わります。
つまり、画像ファイル名をもとにidを生成して、それに対してcssを設定しdivに置き換えてるわけですね。
大変便利です。

これを使うことによって、デザイナーさんはがんばって画像を合成する手間を省くことができ、従来のツールで従来と同じようにウェブ製作を行うことができます。
しかも、最近流行のアジャイル開発とかで頻繁にデザインが変わったとしても、このスクリプトさえあれば簡単にストレス無くデザイン変更が行えます。

大変素晴らしいですね！

機械が出来ることは機械で！人間がやるべきことを人間で！

ついかっとなって2時間くらいで作った割には有益なものが出来たな。

最近、自分ががしがしコミットしていたソースツリーを他人と共有する必要があり、人がどういう変更をしていたのかを確認する必要が出てきました。
コンフリクトを避けるのはもちろんですが、互いの空気をソースから読み取るというのは重要です。

要は git diff を見ればいいんですが、git diff はぱっとみよくわかりませんね・・・・

世の中にはスーパーハカーがいたりするのでこれでいいのかもしれませんが、超一般ピープルである私にはちょっときついです。そこでGitVimDiffです。

motemen さんの git.vim をベースにさせていただきました。これはmoteます・・・・！

スクリプトを.vim/pluginsにコピーしてvimを起動します。
そこでいきなり:GitVimDiffと入れてみます。するとHEADからの差分が表示されます。

さて、今回の目的は他人のコミットとの差分を表示することです。git logでハッシュ値を確認してそれとworking ソースの差分を表示してみましょう。
例えば、 :GitVimDiff cb110a2a9c1532b8737ed37953aeaaa48436351c とか入れてみます。すると、このコミットの時のソースコードとの差分が出ます。これが冒頭のスクリーンショットです。

git diffよりも大分見やすくなりましたね！すばらしい。

vimscript歴2時間で作成したコードなのでまだまだ改善の余地はあるのではないかと思いますが、突っ込み改善歓迎です。