Ubuntu 13.10 で fcitx-mozc を使う
Ubuntu13.10のiBusでは、今まで出来ていた次の2つの使い方が難しそうだったので、Fcitxをインストールして使えるようにしました。
- 変換キーでIMオン / 無変換キーでIMオフ
- IMのオン/オフがインジケータ・アプレット上に表示される
とりあえずは満足に動かせるように設定できたので、まとめておきます。
インストール
japanese-testersのリポジトリを追加。
デフォルトのリポジトリのFicitxだと、IMオンのホットキーがIMのトグルとして動き、IMオフのホットキーが何も動作しないバグ？が起こりました。
$ sudo add-apt-repository ppa:japanese-testers/ppa $ sudo apt-get update
fcitxとfcitx-mozcをインストール。
$ sudo apt-get install fcitx fcitx-mozc
設定
System Settings の Language Support を開き、Keyboard input mehtod systemにfcitxを選択する。
ログインし直すとFcitxのインジケータ・アプレットが現れるので、アプレットをクリックしてメニューからComfigure Current Imput Methodを開く。
Imput Methodのタブで、左下のプラスアイコンからMozcを追加し、Mozcが上から2番目になるように並べ替える。
Global Configのタブで、Show Advance Optionにチェックを入れ、
Trigger Imput Methodに全角半角キー
Activate Input Methodに変換キー
Inactivate Input Methodに無変換キーを設定する。
extra trigger keyはデフォルトの左SHiftだけでIMの状態が変わるのが嫌だったので、無効にしました。
Nested Virtualization を使って仮想マシン上で Vagrant する
普段開発するときは、Windows 上に仮想マシンの Ubuntu を起動して、その仮想マシンで開発することがほとんどなのですが、仮想マシン上で Vagrant を使いたいと思って色々調べて設定していたら、結構時間がかかってしまいました。 結論から言うと、ゲストOSの Windows で仮想化ソフトとして VMware Player を使うと、仮想マシン上でも仮想マシンを起動することができます。
仮想マシン上で仮想マシンを動かすことを、Nested Virtualization といい、それが可能どうかはゲストOSで使う仮想化ソフトに依存します。 ゲストOS上の仮想化ソフトが、ハードウェア仮想化支援機能（Intel VT や AMD-V）を仮想化してホストOS上でも有効にできるのであれば、Nested Virtualization が可能になります。
調べた範囲だと、VMware Player では Nested Virtualization が可能でしたが、VirtualBox では不可能でした。 なので、ホストOS（Windows）上で VMware、ゲストOS（Ubuntu）上で VirtualBox を起動するようにすると、仮想マシン上で Vagrant を使えました。
設定
ゲストOS上の VirtualBox はインストールするだけでいいですが、ホストOS上の VMware Playerでは、ゲストOS上でもハードウェア仮想化支援機能を有効にするための設定が必要です。
仮想マシン設定の編集からプロセッサを選択し、仮想化エンジンのオプション設定で、Intel VT-x/EPT または AMD-V/RVI を仮想化にチェックを入れるだけです。
参考
大江戸ハッカソンで入賞できませんでした
このたびスローガン株式会社主催の大江戸ハッカソンに参加して、ものの見事に入賞できませんでした。
振り返って反省点などを書いておこうと思います。
大江戸ハッカソンとは
大江戸Hackathon ～仲間たちと完成させる「粋」なアプリケーション
8/30から9/1の3日間+最終審査までの1週間という期間で行われたハッカソンです。
「和」というテーマで粋なwebサービスを作れ、みたいな課題でした。
参加者は学生限定で、高校生（高専生）もいましたが、僕の知る限りでは学部4年や修士など年齢層が高めな人が多い印象でした。
参加まで
お前誰よ？
工学部電子情報専攻の学部4年。
プログラミング歴は大学入ってからの3年半。
1年半くらいweb系企業でプログラマとしてアルバイトやってました。
なぜ参加したか
- 制作物の実績作り
プログラミングをやってて、これを作ったと堂々と言えるものを何も作れていないことに焦りを持ってました。具体的には、「プログラミングやってます」→「作ったの見せて」→「あれ、大したもの作ってない」っていう流れを変えたかったです。
僕が趣味のプログラミングで主に何をしているのかというと、公開するほどではない細々としたツールみたいな何かを作って遊んでたりすることが多いです。
時には何か不満があって、こういうサービスがあったらいいなと思うことがありますが、ググると既にそれっぽいサービスが存在して、それを使えばいいやと思ってしまい、結局大したものは何も作れていません。
なんとしてでも作って公開してやるみたいな意識が低いのかなと思っていたので、意識の高いことに挑戦しようと思いました。
- チーム開発の経験
プログラマとしてアルバイトしていたことはありますが、チーム開発の経験はあまりありません。
大学の課題で2人チームで開発を行ったこともありますが、そのときは自分主導でエイヤッと無理やりやって終わらせた感があって、チーム開発とは言えないと自分では思っています。
意識高い？系の学生団体で活動していたという、今となっては少し恥ずかしい僕の少ない経験からいうと、僕が仕事選びの際に何を一番重視するのかというと、誰と一緒に仕事をするかだと思うのです。
なので将来的には、こいつと一緒に仕事したいと他人から思われるようなエンジニアになりたいと思っています。
ということで、チーム開発の経験を積んでおくのは悪くないと思いました。
実際に参加して
チームについて
申込時からチームを組んでいたところもありましたが、多くは初対面で3～5人1組のチームを組みました。 僕のチームも初対面同士の3人でチームを組むことになりました。初対面で3人というのは僕のチームだけでした。
申し込みの時にプログラミング経験を言語とその年数で聞かれたのですが、割りと正直に書いたらできるやつ扱いされたっぽく、3人でもなんとかなるかと思われたのかなと思ったり。
実際のところ、経験期間に対して誇れるものはあまりないです。プログラミング経験は期間ではなく中身だと思います。
作業分担としてはメンバーの技術面の差を考慮し、サービス発案者と僕の2人が主に開発して、残り1人が主にマネジメントをするという形で進めていきました。 なんか開発に集中しちゃって、マネージャーを手持ち無沙汰にさせてしまった感は否めないです。
作ろうと思ったサービス
コンセプトとして次の2つを満たすようなサービスを作ろうと当初は考えました。
- 漫画のコマのセリフ改変をweb上だけで簡単にできる
- 他人の作った4コマ漫画をより面白く改変できる
1つ目は、発案者がよくtwitterでレス画像を使ったリプライのやりとりをしていて、それを画像編集ソフトを使わずにもっと簡単に作れないかところから考えました。
2つ目は、GitHubのfork機能から発想していて、誰かの作った4コマ漫画をforkしてより面白く改変するみたいなことができたら面白いのでは？という思いがありました。サービス名もここから名づけました。
実際に作ったサービス
サービス名: 「MangaHub」
- 漫画のコマのセリフ改変をweb上だけで一応はできる
- 誰かが作ったコマを組み合わせて、4コマ漫画を編集できる
結局リリースもできていませんし、fork機能も途中で頓挫し、誰かが作ってアップロードしたコマを組み合わせて4コマ漫画を編集できるという、中途半端なものとなってしまいました。
結果
7チーム中4チームに何らかの賞が与えられましたが、僕のチームは入賞すらできませんでした。
このコンセプトはぶっちゃけ入賞できるポテンシャルがあると思っていただけに、とても悔しいです。
反省点
チームとして
- ハッカソンに意識を集中できなかった
なまじ中間審査での評判が良かったために、これから先このサービスをリリースしていくことに注意が向いてしまって、最終審査に意識を集中できていなかった。
そのため、期限を意識して機能を絞って作りこんでいくということをあまりせずに、ただただ機能追加にばかり取り組み、しかもその完成度が高くない状態で最終審査を迎えるという愚行を犯してしまった。
またプレゼンテーションの準備もおろそかになってしまった。
- どう見られるかを考えるのが甘かった
ユーザーからサービスがどう見られるかや、プレゼンテーションで審査員からどう見られるかをあまり意識せず、自分たちが作りたいものを一人よがりに作ってしまったのではないかと思う。
個人として
- 自分の意見を強く言えなかった
僕は普段から自分の意見を押し通すタイプではなく、今回のハッカソンでも、論拠があって80%以上は確信を持っているくらいの意見じゃないと言えていなかった。
「こう疑問に思うんだけどどう？」みたいな形で話を切り出せるようになるのがいいのかなと思う。
また、1回言えば意見が伝わっているだろうと勝手に思い込んで、何回も言わなかったために、意思疎通ができていないことがあった。 くどくど言うくらいのほうがいいのか。
- 自分がこれ作りたいと思う当事者意識が欠けていた
発案者が、よくセリフ改変を画像編集ソフトで行ってtweetしてたりする、いわばこのサービスのコアユーザーに当たる人だったので、コアユーザーがここにいるんだから、この人が作りたいものを作っていこうと甘く考えてしまっていた。
そのため、既存の画像編集ソフトを使うときにはどこに不満があるのかとか、どういうシチュエーションでセリフ改変を行ってどうtweetしているのか、など発案者に詳しく突っ込まなかったため、コアユーザーがどういうものを望んでいるのかを深堀りできなかった。
fork機能が頓挫したのは、なんとなく面白いかもと勝手に思っているだけで、実際はその面白さがどこにあるかを突き詰められていなかったから。でも、いざ切り捨てるという決断もできず、ずるずる中途半端なものを作ってしまった。
サービスをどうするか
当初の目的として実績作りを掲げているので、何かリリースはしたいと考えています。
僕としては、機能を縮小し、セリフ改変をより簡単にできることに特化して、ユーザーの利用シーンにマッチしたサービスにするのがいいのではないかと思います。そこはチームメンバーと要相談ですが。
終わりに
自分の反省点が見えてきたり、また他の参加者のすごさを見たりして、何だか意識が高まってきました。参加してよかったです。
これからはプログラミングだけでなくいろいろ精進していきたいです。
まずは卒論がんばるところからかな。
Ruby歴半年もないけどRuby技術者認定試験Silverに合格しました
タイトル通りなんですが、Ruby技術者認定試験Silverを受験して、94点で合格しました。
どうして受験したか
今年の4月頃にChefやVagrantなどのRuby製のツールを触ることがあり、それで少しRubyについて知り、なんだか良さげな言語なのかなーと思うようになりました。
Rubyを勉強しようかなと思ったけど、その頃はまだRuby 2.0対応の書籍が出版されてなかったので、とりあえず必要な部分な調べるという遅延評価勉強をやっていました。
6月に『たのしいRuby 第4版』が発売されて、Ruby 2.0に対応しているということだったので、そこからRubyを体系立てて入門し始めました。
でも、買ったはいいものの1ヶ月たっても半分も読めていなくて、このままじゃアカンなと思い、無理やり読むために1週間後の試験に申し込んで、試験までの1週間で読みきりました。
勉強法
上にも書いたとおり『たのしいRuby 第4版』と、あと『Ruby技術者認定試験 公式ガイド』を使いました。
公式ガイドは前半の説明を一通り読んだ後、後半の模擬問題を解いて、間違えたりわからなかったりした部分について、説明を見返したり、るりまで確認して覚えるようにしていました。
試験本番の実行環境は、すでにサポートが終了しているRuby 1.8.7が想定されていたので、バージョン間の差についても少しググって調べました。
- 作者: 高橋征義,後藤裕蔵,まつもとゆきひろ
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2013/06/04
- メディア: 単行本
- この商品を含むブログ (9件) を見る
Ruby技術者認定試験 公式ガイド (ITpro BOOKs)
- 作者: 伊藤忠テクノソリューションズ,Rubyアソシエーション,ITpro
- 出版社/メーカー: 日経BP社
- 発売日: 2009/03/25
- メディア: 単行本（ソフトカバー）
- 購入: 49人 クリック: 595回
- この商品を含むブログ (42件) を見る
UbuntuデスクトップでPATHの設定は、~/.bashrc か ~/.bash_profile か ~/.profile のどれに書けばよいのか？
結論
結論から言うと、.bashrc に書くのがいいと思います！
以下解説です。
ログインシェル、対話的シェル、対話的ログインシェル
まずシェルの種類についての説明が必要です。
シェルは大雑把に言うと、ログインシェル、対話的シェル、対話的ログインシェルに分けられます。
下のベン図のような関係です。
ログインシェルとは
ログインしたときに起動するシェルです。
GUIでログインした場合は、表示はされませんが内部的にログインシェルが起動しているんだと思います。
対話的シェルとは
manページによると標準入力と標準エラーがターミナルに接続されているようなシェルです。要は対話的にコマンドを実行するシェルですね。
GUIログイン後に、ターミナルを開いたときに起動するのが、対話的シェルです。
対話的ログインシェルとは
ログインシェルかつ対話的なシェルです。
たぶん、CUIでログインしたときに起動するシェルのことを言っているのだと思います。
まとめると、起動するシェルの種類は次のようになります。
.bashrc などの設定ファイルの読み込み順
ログインシェルの場合
manページによると、~/.bash_profile、~/.bash_login、~/.profile の順に探して、最初に発見したファイルだけを読み込みます。
ただしここで注意すべきことは、UbuntuデスクトップでGUIでログインした場合は、~/.bash_profile, ~/.bash_loginを読み込みません。なので、~/.profile だけを読み込もうとします。
対話的シェルの場合
~/.bashrc を読み込みます。
対話的なログインシェルの場合
上記の両方の動作をしますが、その順番については調べてません。
どのファイルにPATHの設定を書くべきか
Ubuntuデスクトップの場合を考えると、ログインしたときに、1度だけ ~/.profile が読み込まれ、ターミナルを開いたときに、毎回 ~/.bashrc が読み込まれることになります。
PATHの設定を動的に変えたいなんてことは多分珍しいことなので、実行のコストを考えると、ログイン時に設定を済ませればいいかもしれません。
しかしUbuntuのドキュメントによると、ターミナルの起動時にはBashをforkして実行するオーバーヘッドが支配的なので、~/.bashrc で毎回PATHを設定するコストは無視できるとあります。
実行コストの面ではどちらでもよいと考えれられるので、他の視点から考えます。
僕に限らず、設定ファイルをGitで管理して、複数の環境で共有している人は少なくないと思います。
この場合、Ubuntuデスクトップ以外の環境でも設定を共有しようと思ったときに、できるだけ環境に依存しない設定の仕方をしたいです。
例えば、WindowsでGit Bashを使おうと思ったときに、~/.profileは読み込まれません。
WindowsでGit Bashを起動したときは、~/.bash_profile も ~/.profile も読み込まれました。しかも、~/.bash_profileが優先されていました。
しかし、~/.bashrc がなく、~/.bash_profile だけある場合に、~/.bash_profile が2回読み込まれる原因不明の動作が起きました。
以上より、結論としては、一番環境に依存せず、Bashの起動時に毎回読み込まれる ~/.bashrc に設定を書いておくのがいいと思いました。
補足など
~/.bashenv もしくは ~/.zshenv
~/.bashenv も ~/.bashrc 同様、Bashの起動時に毎回読み込まれるみたいなことをネットで見かけたのですが、manページにもUbuntuのドキュメントにもなかったので、あまり調べてません。
~/.bashenv ではなく、~/.zshenv だとどうなるか試したのですが、僕の Zsh + byobu-tmux の環境では、Byobu Terminalの起動時に ~/.zshenv が2回読み込まれてしまったため、~/.zshenv を使うのはやめました。
~/.pam_environment について
Ubuntuのドキュメントによると、~/.bashrc や ~/.profile に環境変数の設定を書くよりも、~/.pam_environment に書くことが推奨されています。
このファイルは ~/.bashrc などと違い、source コマンドによって読み込めないので、変更を適用するのに再度ログインし直す必要があります。
一度試してみたのですが、PATHの記述を間違えてしまい、ログイン画面でユーザー名とパスワードを入れてもログインできずに、同じ画面にまた戻るという現象が起きてしまいました。
リカバリモードでログインして、~/.pam_environment を削除することで事なきを得ましたが、ログインし直さなければ記述の間違いを発見できないというのは、間違ったときに致命的です。
また、Linux環境に特有の設定ファイルなので、やはり前述の理由から、~/.pam_environment を使うのはやめました。
