プログラミング言語の仕様・振る舞いを確認するために小さいプログラムを書く。 「この式を評価すると値は何になるの?」とか「この2つの書き方どっちが速いの?」とか「この正規表現にどうパターンマッチングするの?」とかを確認したい時。
当たり前の進め方だと思っていたんだけれど、そうすることを勧めたらスルー気味だったので。
特にスクリプト言語なら 「a.ほげほげ 」(Perl なら a.pl)なファイル作って実行してみればいいじゃんと思うのだけれど手間に感じるのかな。本丸のプログラムのソースコードを書き換えて試す(Apache 再起動して Web ブラウザでアクセスしてデバッグプリント読むとか)よりよっぽどはやいよ。あと、単体テストファイルでやっちゃうのもアリ。
それに適当に記事としてまとめておけば、今度は自分が他人に説明する時にそれを示せば済むようになるしね。
「Vim で Perl ソースコード上でパッケージ名の上にカーソルがあるときに gf するとそのファイルを開くんだけど、……」という話が出て、あ、それ Emacs でもやりたいと思って調べて設定した。
最初は FFAP の設定。実は今まで知らなかったのだけれど ファイル名などをポイントしている時に Cx C-f するとそのファイル名を guess してくれるl FFAP というのが標準で入ってた。
(ffap-bindings)
で有効になる。
これでファイル名は OK。Perl のパッケージ名からファイル名を guess してもらうには ffap-perl-module.el を使う。
上記から ffap-perl-module.el を取ってきて load-path の通っているところに置く。で以下を設定に追加。
(eval-after-load "ffap" '(require 'ffap-perl-module))
これで Perl ソースコード中のパッケージ名が書かれているところにカーソルがある時に C-x C-f するとそのモジュールファイル名を minibuffer にデフォルトで出してくれるようになる。捗る。
なおデフォルトだと system Perl の @INC にあるものを探しにいくようになっているので、perlbrew 下だったり Carton で入れた local/ 下だったり開発中のモジュールだったりを見つけられるようにするには ffap-perl-module-path を設定しておく必要がある。
(setq ffap-perl-module-path '("/path1/to/lib" "/path2/to/lib"))
両国の KFC Hall で開催された、株式会社ジースタイラス運営の2015年卒対象「ITエンジニア逆求人フェスティバル」という企業・学生交流イベントに参加してきた。この手のは5月のサポーターズ主催イベント以来。
5月の時はまだ夏前でインターンシップが目下の感心事といった感じだけれど、今の時期になると就職活動という意味合いが強い感じ。
「ITエンジニア」というくくりなので必ずしも Web 系志望じゃない方がいるのはあるとして、それ以前にエンジニア志望じゃない人も参加されていたのは運営に課題があるんじゃないかな。あと経験されている技術要素して Unity・OpenCV・Kinect などを上げている方が多かったかな。なにか恣意的な参加者人選なのだろうか。
特に Web 系は独学である程度やってみる・作ってみるという事ができる高速道路が敷かれている世界なので、学生時代からいろいろされている人も多い。やっている、やっていないで結構差が出るので、Web 系を目指しているけれども何もやっていないという方はすぐにでも何か始めると良いと思う。
もちろん選ばれる立場として、優秀な方々にそこで活躍したいと思われる企業にならなければと身を引き締めなおした1日でもあった。
以下所属組織とは関係ない個人的見解:
でも自分が学生の頃そんなの全然出来てなかった……。
GitHub 主催の「GitHub トレーニングチームから学ぶ Git の内部構造」に行ってきた。会場は Yahoo! JAPAN のある東京ミッドタウン。
内容的には「入門Git」の始めの方で説明されている Git のデータ構造(もはやファイルシステム)について。「Git の内部: グラフ、ハッシュ、圧縮」というのがトピックとのことだったので、漠然と Git のソースコードレベルでの話題になるのかなと思っていたのだけれど、そうでなかった。
新しく知った事:
オブジェクトが不変でかつ同じ内容ならオブジェクト ID が必ず同一になることを利用して、オブジェクトファイルを共用していることを発表中「ハードリンク」と言ってしまったけれど、多くの人がファイルシステムのハードリンクで実現されていることと勘違いしていた模様。質問を受けて説明しなおしていたけど。
ちなみに実際にファイルシステム上でハードリンクになるのは、ローカルリポジトリを指定して clone した時。大きなリポジトリでもローカル内で clone する分にはストレージ容量的にはあまり気にしなくて大丈夫。
Git の contrib/diff-highlight を使って行単位ではなく文字列単位で異なる部分をハイライトしてくれるという記事を教えてもらった。
自分の設定では .gitconfig の color のところは
[color] branch = auto diff = auto grep = auto interactive = auto showbranch = auto status = auto
となっていて pager 指定は .bashrc で
if command -v lv > /dev/null; then export GIT_PAGER='lv -Ou8 -c' fi
と今している。diff-highlight*1 を PATH の通っているところにおいて、
GIT_PAGER='diff-highlight | less -R' git diff HEAD~..HEAD
とかすると文字列単位で差分が反転色で表示される。
lv だと \x1b[7m で反転させるとそれまでの色属性が落とされてしまうのか、行のそれ以降が黒白/白黒になってしまう。 lv v.4.21*2 のソースコードを軽くみたけどちょっとしっかり読まないと対応できなさそうなので、今日は諦め。
diff-highlight は Perl スクリプトなので、こちらでハイライト開始とハイライト終了時のエスケープシーケンスをいじって lv で見栄え良くなるようにするのが簡単でいいかもなあ。
*1Debian GNU/Linux だと /usr/share/doc/git/contrib/diff-highlight/diff-highlight にある
*2(Debian GNU/Linux だと v.4.51.a が入っているので、見たのはちょっと古いバージョンだった模様)
Vim の jellybeans カラースキームにインスパイアされて作られたという Emacs 24 のカスタムテーマ Ujelly を入れてみた。
custom-theme-directory を設定するほどでもないので、require できるところに ujelly-theme.pl を配置しておいて、
(if window-system (when (>= emacs-major-version 24) (when (require 'ujelly-theme) (load-theme 'ujelly t))))
としてロードするようにした(ujelly-theme.el を読むとその中で自身のあるディレクトリを custom-theme-load-path に追加してくれる)。
今までは Solarized の dark を使っていたんだけれど、ディスプレイが暗い時(省電力のためノート PC の液晶モニタを暗くしている時)に見づらいなと思っていたのでもうちょっとハッキリした感じのにしようかなと。
Ujelly テーマでソースコードを開いてみたら、くっきりメリハリがあって見やすくテンションが上がった。いい感じ! (スクリーンキャプチャは Perl 5.18.1 の Data::Dumper のソースコードの一部)。
ただ実際に入れてみると Solarized は目に優しいなとあらためて実感して良さを再認識することにもなった。Solarized も捨て難いね。
夏に竜宮城スパホテル三日月で2泊ぐらいどうかなーという話があったのでちょっと調べたのですが、7月下旬とかだと1泊2万円超なんですね。結構しますな。
それから、アプリ開発のチームにも入ることになったので iOS アプリの開発環境を用意した方が良いかなと思ったのですが「コードは書く予定ないですよね? であれば Xcode でソースコードが見られるぐらいでどうですか」となりました。確かに書く余裕は無いですね。
仕事で使っている15インチ MacBook Pro はまだ OS X El Capitan のままなので Xcode を入れるにはまずはそこのアップデートが必要。そこからか。
保守が難しくなってきたライブラリを使うのをやめ、まだ導入していない新しいライブラリを使う実験的取り組みをしている担当者に「ドキュメントにまとめておいてほしい」とリクエストしたら「誰が何のために読む想定で書けばよいか」という良い質問をもらった。ドキュメント化で期待する価値について伝えられるよう整理しなおした。
今回のトライアル実装のドキュメント化で期待する価値は以下と考えている。
ということで「今のチームメンバ」「将来のメンテナ」「将来の組織の他のメンバ」が読者の想定だ。
「詳細設計書」をまとめるより「今回やったこと」と「分かったこと」「考えたこと」「気付いたこと」(わかき)を整理して書き出すことが、形式知化とナレッジ共有に役立つと考えている。
「ドキュメントにまとめておいてほしい」には「成果物としてドキュメントを残してほしい」だけでなく「情報発信をするメリットを知ってほしい」という思いも含んでいたりする。
[ opinion ]
髪伸びてきたので来週で床屋の予約をした。
MkDocs + Roamlinks Plugin で静的サイト生成している組織内公開ワーキングノートサイトでやっぱりバックリンクが欲しいなと思って mkdocs-backlinks v0.9.1 試してみた。
がバックリンクを出力させられず。ソースコードを読んでみたがうまく動かない理由は分からずじまい。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。