皆さんはEmacs大好きですか？ 私は嫌いです。*1
ですが、Emacsを超えるエディタがないので仕方ありません。
今回は開発の流れの中で、Emacsに関連する部分を抜き出して説明してみたいと思います。

最初に断っておきますが、この記事はEmacsを使っている人向けです。
C-fやC-bを見て「？？？」となる人は、以降を読んでも最後まで「？？？」だと思われます。

私の設定ファイル(.emacs.el)を公開します

折角なので、私の.emacs.elを公開します。https://gist.github.com/2637273
ほぼどこかのコピペですが、ほぼどこからコピペしたのか分かりません。ごめんなさい。
この後の説明では、拡張の設定方法や、具体的にどのキーにどの拡張を割り当てて云々みたいな話は省かれることが多いので、不明点は直接.emacs.elを見て下さい。
ちょっと変えている部分や消している部分もありますが、ほとんど生の設定ファイルです。何か参考になれば。

まずanything-for-files

Emacsを立ち上げると、まずはC-x bを打ち込みます。
この割り当てですが、私はanything-for-filesに割り当てています。
まさか素のままバッファの切り替えを使っている人がいるとは思えないので、C-x bにはiswitchbの割り当てをしている人が多いのでは、と思います。
ですが、Recentf（ファイルの使用履歴）があるanything-for-filesが便利すぎるので思い切って割り当ててます。Anything超絶便利。

Trampで開発

開発のやり方としては、Trampで開発サーバーに入って、その中身をゴリゴリ書き換えていきます。
…なのですが、実はC-x bした時点で（今の私の場合は）勝手にTrampが走ります。
これはanything-for-filesを開いた時に、前回まで開発サーバーで作業していた履歴が残っているからです（たぶん）。
コマンド入力せずにTrampがいきなり使えて、前回の途中からすんなり開発に入れるのは嬉しいです。

ところで、sshの多段の設定やkeyの設定は、私は.ssh/configに書く派です。
Trampの設定は率直に言って意味不明ですし、普通にsshで入りたい時にも使えるので便利です。

バックアップ系ファイルの作成はOFFにする

お目当てのファイルを開いたら、ゴリゴリ編集します。
この時、バックアップやオートセーブのファイルの生成はOFFにしてます。gitのstatusで見た時に鬱陶しかったからです。*2
基本的に、開発サーバーのものを直に変えて、すぐ結果を見ているので、気をつけてなくても小まめにセーブしてます。
最初は不安でしたが、今まで困ったことはありませんでした。こんなの使うくらいならセーブしろという感じです。

Auto Complete Mode

ソースの編集中はAuto Completeで補完無双してます。Auto Completeは補完機能です。メソッド名とか補完するアレです。
昔はこんなの軟弱者が使う機能だと思っていましたが、今やこれないと生きていけないです。*3
結構変な補完もされますが、それはそれです。真面目に調整すれば良い結果になるかもしれませんが、それはそれです。

素のターミナル

ひととおり出来たら、rails consoleが使いたくなったりするでしょう。
ここまでEmacs推しておいてアレですが、私はEmacs内でshellは使いません。
デフォルトのshellを使ったらディレクトリ名のTab補完が効かないという事件が以前あり、そこから色々と試したんですが、Emacsのshellはどれも…こう…微妙というか…はい。
あと重いファイル開いたり、tailでログを延々と流しっぱなしにする時にEmacsだと怖いってのもあります。*4
なので、私はMac OS Xに標準でついているターミナルを使ってます。タブの切り替えとか出来て、必要十分です。軽いし。

Anything

ひと仕事終えたら、gitのbranchを切り替えてfeatureブランチ（機能開発ブランチ）に切り替えて頑張りたくなるかもしれません。
branchを切り替えた場合、同じファイルでも読み込み直す必要があるケースもありますよね。
そこでrevert-buffer、なんですが、ここでもAnythingの出番です。というかここが主な出番です。

Anythingは、様々な操作の統一的なインターフェースとなるものです。説明し辛いので使ってみて下さい。
M-xでAnythingを起動したら、その時点でコマンドの履歴も見れますし、全てのコマンドからpatternで絞っていってお目当てのものを掘り出すことができます。
なので、revert-bufferの場合は、reve…とかまで入力すれば十分絞り込まれた結果になります。
Emacsはコマンド多すぎでなんとなく覚えているコマンドばかりなので、適当に入力して検索できるAnythingは超便利です。

ちなみに、Anythingに頼らず手癖で割り当てたキーを使うのは、

• ソースコードのコメントアウト
• ソースコードの段落揃え
• undoとredo

くらいのものです。
これらは手癖すぎて、逆にコマンド名も知りませんし、どういう操作か（どうキーを打ってるか）も実は書けないです。
知りたい人はググって下さい。

その他

細かい事を言い出すとキリがありませんが、他で大事な設定は

• C-h でのbackspace
• 行数表示（Rubyのエラーから場所を推測できなくなる）

くらいのもんですね。
speedbarとかGTAGSとかは必要であれば使う感じですが、使用頻度は落ちます。
そして使って馴染まずに、.emacsから排除された拡張は膨大にあります…。

まとめ

• 悟りでも開かないと、Anythingを使わないノーマルのEmacsを使う時代には戻れない
• Trampが生まれなかった平行世界で、開発サーバーのEmacsを直に使う世界があるかもと考えるだけでも苦痛
• Xcodeで飼いなさられた我々はAuto Completeが手放せない
• Emacsのshellはビミョー

Enjoy!

最近暖かいです。

ごきげんよう皆様。
2年目に突入しました、新人（から能力的に脱出できない）プログラマーの中森です。

最近ブログ書いていなかった気がしますが、なんだかここ数ヶ月の記憶がない*1気がするので、しょうがないですね。
なので、何故更新されなかったのか私にも分かりません。やー、ハハハ、記憶ないのでね。

2月とか3月とかは特に、採用とか、そういう面でブログを書く必要性が、おそらく、あったような、なかったような…。
ネタも新サービスの事とか、あったような、なかったような…。
いやー、でも、ハハハ、でも記憶が無いですからね！ 記憶ないですから。ハハハ。

1月

記憶がないのですが、プログラムを書いていました。
ひたすらプログラム書いていました。記憶ないですが、ただただプログラムを書いていました。
記憶がないですが（ry

2月

いやー、記憶がないのでー、…ってそろそろこのネタいいですかね。
2月末に新サービスをリリースするという話は決まっていたので、それに向けて、最終準備していました。

特に思い出深いのは…そうですね、あるスクリプトを作っていて、移行期間の間に流す予定だったんです。
移行のためにサービスを停止できる時間は限られていて、さらに言えばそのスクリプトの持ち時間は半日ってところだったのですが、試算すると数日必要とか出てきて笑いました。正確に言えば涙しました。
もちろんそのままで良いわけがないので、ひたすら速度改善しました。膨大なタスクに埋もれながら速度改善。泣きそうになりながら、ただただ速度改善。
結果は、確か4時間とかに収まったのですが、できればもうあの移行期間は味わいたくないですね…。
当日スクリプト群を流した時は、他のスクリプトも合わせて全部終わるまで結構緊張しました。*2

3月

リリースしたぜ、やったー！ 遊べる！
…となるはずもなく、タスクが出てくるわ、出てくるわ。
なので、この時期はちぎっては投げ、ちぎっては投げ、……していたわけではなく、主に私は自分の失態と戦い続けていました。

「プログラム修正！ 君に決めた！ commit!」
↓
「reject」
↓
「あっ…。確かにこれダメじゃん。でも負けずに俺はこのカードを切る！commit! push!」
↓
「reject」
↓
「あっ…」

みたいな。はい。ごめんなさい。足引っ張りました。すみませんでした。

4月

4月になったぜ、やったー！ 落ち着いた！ 遊べる！
とはなりませんでした。いっぱいやることあるよぅ。アワワワ。

ということで

訪れない平和。開発パレードは今日も続く！
どうなるEight、どうなる開発チーム、乞うご期待！*3

と言いつつ、私はひとりお休みを取って実家に帰り、これを書いています。
皆が必死になってあれやこれやを進めているうち、進捗が良くない私が一週間ぶち抜いて休んでます。
だって先月は今頃暇になる予定だったもん………てへぺろ(・ω<)
頑張ります。

次は何か技術系更新したいですね。そちらの方面に興味ある方は次回も是非よろしくお願いします。

最近寒いです。
まぁ、寒さを感じるのは駅と自宅との間の、たった5分程度ですけどね。
真冬に30分かけて学校へ歩いていたあの頃に比べれば楽なもんですが、最近は5分でも辛いと感じます。
慣れというか、文明の発展のおかげではありますが、ちょっと脆弱な生き物になってしまったのかもしれません。

これが文明の進化の先にあるもの…これが…欲にまみれた人間という生きの物…末路…！
逃れられぬ宿命というもの…！！！


とか外に出ないのを文明のせいにせず、運動不足の身体を外で動かすべきなのは分かってます。何も言わないで下さい。

今回は、予定していたネタが用意できなかったので私の1日を振り返り、こんな日常ですよーと軽く紹介したいと思います。
学生の方などは、何かの参考にして頂ければ。

私の1日

09:15〜 出社

だいたい9時15分から強マッチ（後述）が始まるので、その時間までに来ます。
私の場合、前日の仕事の終わり方によって出社時間が違っていて、仕事が「アワワワワ」ってなっている時は2時間早く来たりもします。朝は集中できますからね。
余裕があって寝たい時は本当にギリギリに出社します。
普段何も無いときは、だいたい10分程度前に来て、帰った後にバグ報告等がきていないか見たり、1日の予定をおおまかに決めたりします。

09:15 強マッチ

三三では、社員がお互いの強みを活かし合うために、朝に軽いディスカッションを行います。
細かくはその時々でやっている事が違っていて、ストレングスファインダーをやったりエニアグラムをやったり、その他のテーマでやったり色々です。
強マッチは簡単に言えば、自分がこういう人間ですよ、という事を喋る場なので、相手を知る機会であるとともに、自己を見つめ直す機会でもあります。
自分はどういう人間なのか？ といった事を深く掘り下げていくのは、なかなか難しいですね。未だに自分の発表前は悩みます。*1
ちなみに、正直私は、エニアグラムはあまり好きではないです。
なので、そういう人のために断っておきますが、この会におけるエニアグラム等のフレームワークは、お互いを考える切っ掛けとするものであり、覚えるためのものではありません。何かの考えを押し付ける会ではないのでご安心を。
まぁ、個人の強みをチームの力へ繋げたい！ 皆を良く知りたい！ といった考えが既にカルトだと言われると、もはやどうしようもありませんが…。

09:30〜 朝会

昨日やったこと、今日やることをチーム内で報告します。
チームの1日の動向を知る大切な会です。お腹が痛くて電車を途中下車し、朝会に間に合わなかったときの気まずさといったら。

10:00〜 開発

朝会が終わり、タスクを整理したら、開発に取りかかります。
私の場合、テンションに反比例して、この時間が最も頭が冴えているので、難しい課題は朝やります。
手を付け始めるまでは朝なのでかなりテンションが低いのですが、作業を始めるとそんな事は忘れて没頭していきます。
とにかく、朝は集中して仕事します。

12:00〜 お昼

お腹が減ったらお昼！
朝食を抜くことが多い私は、もはや我慢できません。
だいたい12時頃になると、他部署の方含め、席が近い人達から外食する人を募って行きます。
市ヶ谷の昼飯は、結構美味いです。私は本当に腹が減っているので、ご飯大盛り/おかわりが無料のお店に好んで行きます。
お昼終わったら、外食チームと別れて、お散歩したり、少しだけぶらぶらして会社へ。

13:00〜 開発再開

ご飯直後は、正直やる気ないです。
午前中に集中してやったものの事後処理的なものをやります。それが片付いたら、細かいタスクをやります。
2時間ぐらいそうこうして、15時あたりになったら、今度は大きい課題に取りかかります。
大きい課題は、難しい課題とは別で、時間がかかりそうな修正等です。中くらいのモチベーションで、中くらいの難しさの課題を、じっくり腰を据えてやるようなイメージですね。

16:00〜 会議とか

一応会議の時間を入れてみましたが、普段は会議はほとんどないです。私の場合、週2〜3個程度です。
チーム間の決定は、じっくり話すべき事以外はその場で決めてしまうことが多いです。
必要無さそうな人まで呼びまくったりする人もおらず、また必要の無い補佐役として呼ばれることもないので、エンジニアとしては集中出来る環境です。

18:00 卓球を始める

会社にある卓球台で卓球をします。それだけです。卓球をするだけ。

18:30 帰る or 仕事続行

18時以降は各自の判断で帰ったり仕事したりしています。
毎日早く帰る家庭思いの方もいれば、締め切り日が近いと言って遅くまでやっている人もいます。
多種多様です。古参新参関係無く、各自で判断します。
三三ではガツガツ仕事したいという人が多いというのはそうなのですが、早く帰る人はきっちり仕事やって帰っているので、早く帰る人は尊敬される事はあっても文句を言われることはありえません。正直、早く帰ってスケージュールの通りに進めている人は、すごいです。
私はと言うと、帰りたい日（テンション的な意味で）は定時に帰ります。頑張れる時（というより頑張らないとヤバイ時）は夜までいます。だいたい水曜は早く帰ってますね。
カッコ良く「仕事が終わったら帰ってるぜ」と言いたいところなのですが、仕事が終わらなくても気分が乗らない場合は投げ出して帰ったりもしてます…すみません…。

という感じで

三三に入ろうと思っている人に、何か参考になれば！ と思って書き始めたものの、全く参考になりませんね。
普通過ぎでごめんなさい。

次回は何か技術的なネタを出したいなぁ…と思ってます。ネタが用意できれば！

皆さん、良いgitライフ送っていますかー？

私は、業務の性質上、1日に数回ブランチを切り替えることがあります。
が、どこでもキリの良いところで切り替えられるわけでもなく、作業途中に「急いで対応して！」と切り替えを迫られることもあります。
commitするのはアレですし、そんな時こそstashですね！
今日は自分のメモ代わりに、git stashについてまとめたいと思います。

git stash

現在のワークツリーの状態を一時的に保存しておくのがstashです。

$ git stash save
Saved working directory and index state WIP on develop: 07b8dda hogehoge

stash saveすれば、すぐ別のブランチに切り替えることができます。
そして、別のブランチでの作業から戻ってきたら、

$ git stash pop

とすれば、元の状態に戻せます。

stash saveすると、一旦クリーンな環境に戻ることができるので、ブランチ切り替え以外にも、ブランチ切るほどじゃないけどちょっと時間のかかる修正をしたい、でもその間別の作業もしなければならない、という時に便利です。stashを使えば、修正中でも一瞬で元の動く状態に戻すことができます。素晴らしい。

嬉しいことに、saveは何度でも行えます。

$ git stash save
（ごにょごにょ別の何かを変更する）
$ git stash save

とすると、stashが2つある状態を作れます。

いくつsaveしたものがあるかは、stash listで見ることができます。

$ git stash list
stash@{0}: WIP on develop: 07b8dda hogehoge
stash@{1}: WIP on develop: 5d515b0 Merge branch 'develop' of https://git.hogehoge.net/www into develop

複数ある中から特定のstashを展開する場合は

$ git stash pop stash@{0}

のようにして展開します。
ちなみに、popするとリストから削除されるので、削除はせずに展開だけしたい、という場合は

$ git stash apply

を使います。applyした後に、「これじゃなかった！」と思って焦ってsaveとかしちゃった場合は

$ git stash list #確認する
$ git stash drop #削除

で消しましょう。全てのstashしているものを消したい場合は

$ git stash clear

です。私は以前誤って、必要な修正まで消してしまったこともあったので、皆さんご注意を…。

また、stashにはコメントをつけることができ、

$ git stash save 改修A
$ git stash save 改修B

とやっておくと、listで見た時に

$ git stash list
stash@{0}: On develop: 改修A
stash@{1}: On develop: 改修B

とっても分かりやすい！
実際に使っている感想としては、メッセージがないと、溜まってるリストを見ても全然分からない時があるので、メッセージをつけることをオススメします。*1
メッセージを付け忘れて何をstashしているか分からない、または詳細にdiffレベルで見たい、という場合には

$git show stash@{0} # この場合、0番目を見る

で内容を確認を見ることも可能です。*2
が、面倒なので単なる確認用途ではメッセージつけた方が楽ですね。

ということで

今回はgit stashを見てきました。
stashは簡単便利なので、なんでもかんでもstashするという悪癖がつきかねません。ブランチ切る時はブランチ切る、コミットするべきときはコミットする、という基本原則を忘れない範囲内で、幸せになりたいものです。

Hey、みんな！ 元気にしてたかい？
ナイスガイのオレは、独りで（いつものように）引きこもって連休を過ごしてたよ！ HAHAHA！


…大丈夫、寂しくないです。


などと涙を誘う連休はどうでも良く、皆様、あけましておめでとうございます。
今年も三三、主に私をよろしくお願いします。ブログの更新頻度がめっきり下がっている私を今年もよろしくお願いします。

さて、三三のLKチーム開発メンバーが中心になり、ブログを持ったそうです（ブログ何個目なの…）。
そこで我らが藤倉先生が今年の目標について触れていたので、私も便乗しようと思います。

今年の目標のきっかけ

昨年の後半に、大きく仕事内容が変わったことが、そもそものきっかけでした。
以前と違い、何も分からない分野での仕事だったため、とにかく投げられたボールをひたすら打ち返すような仕事の進め方をしていました。
それはそれで効果はあったと思いますし、その中で学んだこと、出来るようになったことは沢山あります。

ただ、最近はそのフェーズも終わりに近く、そろそろ時間の使い方を考えるべきタイミングだな、とも思い始めました。

時間の使い方

何に時間が足りていないか？
または
意識して作るべき時間は何か？
と考えると諸々あるのですが、特に改善すべきだと思ったのは、メインの仕事というよりも、「やらなくても仕事が回る」部分だと思いました。

最近、ちょっと痒いところに手が届いていないような、そんな感じがしています。
インデントを自力で直したり、Emacsを使いながらも内部でshellを呼べなかったり*1、意味が分からん！と思っていたら基礎中の基礎で特定のワードで検索したら一瞬で解決したり。

これらは、自動化とか、開発環境の整備とか、Webの体系的な勉強とか、そういうメインでない、でもちょっと時間を使うことで解決できます。
ちょっと基礎を勉強したり、ちょっと改善することです。「ちょっと」なんです。

でも、そのちょっとをやる前に、メインの仕事で「あの実装よく考えると大丈夫か？」「これチェックしたい」「あの機能作らなきゃ」云々…とか考え出すので、一向に改善されないんですね。
それはそれで大切なんですが、意識がメインの仕事に行き過ぎた感は否めません。
自分の成長としても、仕事の効率としても、このままだと頭打ちになる可能性があると思いました。

これではいかん

ここまで言えばもはや明白なのですが、今年は、意識して少しずつ時間を作る事にしました。
お昼後の30分でEmacsを改造して1日試してみるとか、朝ちょっと早く出てスクリプト書くとか、今年は地味な小さな時間を意識的に作って、「ちょっとしたこと」に割り当てます。

ということで、前振り長くなりましたが、これが今年の目標の「攻めるための（ちょっとした）時間を作る」です。
今年は追われるのはやめて、攻めたい！ と思ってます。頑張ります。

おまけ

えー…、時間を作ります、ということで、今年はブログを書く時間も作ります。
上司と相談した結果、2週に一回「スケジュールに明確に入れて」やります。今の頻度はあんまりですね。すみませんでした。

まだ厳密にいつスケジューリングするか決めていませんが、だいたい月曜〜火曜朝が最も忙しくなるので、水曜の朝にでも書こうと思います。
技術的な内容も、開発メンバーのブログに負けずに増やしていきたいところです。

ひとまず今回で今までサボっていた期間を水に流して頂けると期待して（お願いします…）、来週の水曜からご期待下さい。

それではまた来週！