2016年8月11日木曜日

Linux に慣れてきたと感じる方たちに贈りたい心構え

さて、夏ですね。

春にはブログ界隈も「新入社員に伝えたい〜」とかそんなタイトルでたくさんのエントリが書かれていたものです。
しかしながら、現実的なことを考えてみますと、人間というのは馬鹿なんです。春にそんなこと言われても、実際に新入社員が春にやることと言えば、分厚い仕様書をドンと渡されて「把握しておいて」くらいのものです。
実務的にオペレーションをしたりするのはこの時期くらいからなんではないか、と思うわけです。何でああいう記事を春に書くんですかね。まあ、それはいいや。

タイトルの通りなんですが、そろそろ UNIX や Linux を使いはじめたぞ、という方たちが心がけるとよいのではないかと思うポイントについて、自分の考えをまとめてみました。

「なぜ?」なのかを考える

SI-er とかになって、オレってば RedHat Enterprise Linux に Oracle の環境を作成して、それを使いこなしてどんどん成長してるぜぇ。って感じのお年頃の方もこの季節多いのではないかと思います。

だがしかしですね。きちんと本質を捉えて今後も同じ業界でやっていくためには「なぜ?」をきちんと考えましょう。たとえばですが、上述みたいな作業をした方は、たいていの場合は手順書に従ったりするわけです。その手順書というのが先人たちの知恵でもあり、自身の成長を遮る壁なのです。

ついうっかり何も考えずに SELinux を disable にしたりしてませんか?たぶん、そんな経験あるでしょう。周囲に聞いても「SELinux はトラブルの元だから」とか言われた、とか並の職場ではそんな感じなんじゃないですかね。
では、なぜトラブルの元が規定の設定になっており、有効化されているのでしょう。そういったところからきちんと「分からない」「なぜ?」を調べていくことが、いつも利用している道具の仕組みを知るチャンスになります。

というのもですね。
いまどき Linux のカーネル(譲歩して Lion's 本で PDP-11 のカーネルとかでもよい)を読破してから、システムを俯瞰的に見れる状態で実務に投入されている人材なんていないし、そんなこと社会人になってからではできないんですよ。
ならば、システムを俯瞰的に見れるようになるにはどうするか、というと、ユーザの視点から「先人たちが作った仕組みであるはずなのに、なぜこのようなことになっているのだろう?」という視点をもつことが大切になってくると思います。上から部分的に謎を解いていき、どんどん謎を埋めていく、という作戦です。

SQL などでも JOIN とか VIEW を使うときも「こうするとできるから使う」ではなくて、 JOIN や VIEW を使うべき理由を考えることが大切です。考えた結果、割とそういったものは必要なかったりしたりして、他のクエリーで代替えすることで無駄な複雑性がなくなり、 KISS な状態でシステムを維持できるようになります。

「なぜ?」を繰り返していればそのうち 0x7C00 までたどり着くのではないでしょうかね。

師が何をしているか理解する

たいていの場合は上司というのは自分よりもよりスキルセットが高いものです。
それを利用しない手はありません。

ターミナルの操作からプログラムの書き方まで、身近な先人が身につけたのもを盗む、というわけです。このとき重要なのは一挙手一投足について「何をしているのか」を理解して師と同期することです。ターミナルでよく分からないカーソルの飛び方や補完が発生したら何をしたのか聞きましょう。聞かなければ自分はいつまでも非効率なままですが、一時の恥を忍べば、これからは思考のバリエーションが増えます。

与力のある場合は「いまこういう操作をしたけど、自分だったらこうするな」みたいなことを考えてみたり、師と仲がよければ提案してみましょう。いつも質問して盗んでいるばかりではなく、恩はきちんと返していくべきです。

人が造りしものを恐れない


近頃はオープンソースのライブラリを使ったシステムなどを構築していたりすることも多いのではないかと思います。そのときによくありがちなのが、エラーメッセージをきちんとみる、というのは実践しているが、そのさきの深みについては避けるといった行動があります。

どんなシステムも人が造ったものです。たいていのシステムはごく一部の「頭の中が理解できねぇな」って人が造ったもので理解できなかったりしますが、たいていのシステムは読み解くことで理解ができます。「これはオレの仕事じゃないから」はやめましょう。積もり積もった後回しで技術や知識がない自分を形成していくというプロセスに陥ります。

もちろん、時と場合を選ばなければなりませんが、大いに深みにハマり、大いに先人たちが作った仕組みに憤りを感じましょう。そして、願わくば先人たちよりもよいものをフィードバックしてオープンなシステムに反映していくのがみなの幸せにつながるのです。

所感

ですます調で書いたらえらく仰々しい文章になった。
しかし、成長したい、という人にはこれくらいしてもらいたいと感じる昨今です。

さて、手元の FreeBSD も 10.2-RELEASE から 10.3-RELEASE に上がったことだし、そろそろ外出するかな。

2016年7月20日水曜日

英字配列を好んで使う指向があまり自分には理解できない件

キーボードの話題です。
表題の通りなんですが、英字配列が「カッコいい」という意識高い感じのプログラマが理解できない。

理由はいくつかあるんですよね。まず、自分がかな打ちで日本語入力しているというのが理由のひとつではあるんですが、これは決定的な理由ではない感じですな。英字配列でもだいたいどこに仮名の文字がマッピングされるか頭に入ってるので、モバイルデバイスとかで英字配列のキーボードしか使えない、というときでもかな打ちで日本語入力しています。

じゃあ、なんで英字配列を愛用している人が理解できないかっていうと、なんか使っている人たちの意識を見ていると気持ち悪いことが多いんですよ。「デザインがいいので英字配列使ってる俺カッコいい」みたいなワナビー系の感じとか「プログラマならやっぱり英語でしょ」というようなよく理解できない主張がとても気持ち悪い。

だって、普通に不便じゃないですか。英字配列。キーの数が少ないんですよ。
それに、いくつかのプログラミングでよく使う英字について入力しやすいという主張も見かけるんですが、だとしたらなんで日本語の文章を書くときによく使う日本語入力について効率がよいかな打ちをしないんですかね。よく分かりません。

あと、文字コード的に英字配列気持ち悪いじゃないですか。man できる端末があったらたいていのマシンに ascii(7) あると思うので、 man ascii なり man 7 ascii で文字コードを見てみてくださいよ。0x2a が * で 0x2b が + てですよね。日本語配列だときれいに並んでますよ。
「いくつかのプログラミングでよく使う英字について入力しやすい」英字の代表として挙げられることがあるダブルクォートなんかも 0x22 に位置していて、隣の 0x23 が # なんですよ。日本語配列のマッピングと一致していてとても気持ちいいんですよ。なんでダブルクォートごときで英字配列を選択しているのかよく理解できない。だいたいにおいておまえらはあまりC言語とか書かないだろうから、リテラル文字列に使うのはシングルクォートでいいじゃねぇか、という気もします。そんなシングルクォートは 0x27 なわけですが、これまた隣の 0x26 が & で日本語配列だと隣です。なんという整合性のとれた配列なんでしょう。

日本語配列は JIS 配列なんて呼ばれたりもしますが、最近は同様の記号の配列で他国のキーボードも作られていたりするわけで、ようするに英語圏で英字配列を使い続けているのは MKS単位系が国際標準の世の中で、やれフィートだポンドだ、ガロンだみたいな気持ち悪い単位系を使ってるのと同じようなもんなんですよ。
なんで日本人であるところの君らがわざわざ標準から外れていくの?という感じでこれもまた意味が分かりません。

他にも MacBook などの日本語配列だと A の横に Ctrl がきていて規定の設定でも UNIX らしさがマシマシになってよりハッカーにとって優れていると思うんですがね。なんでわざわざ英字配列を選択しちゃうの…もったいない…

最後になんですが、わたくしはそこまで何かに偏るってことはないので、基本的には英字配列も使えますよ。使うときもありますさ。しかし、あえて英字配列を選択しなければ英字配列のものが手に入らないという状況で、ここまで気持ち悪くてよく分からない理由で英字配列を選択する意味ってそんなにあるんですかね?という感じです。

みんながもっと日本語配列のキーボードを使ってくれると、しいてはかな打ちとかしてくれれば、日本語配列のキーボードから仮名刻印を削ってオサレ!みたいな狂った製品が出回ることもなく平和なんですけど、あれはどうにかなりませんかね。

あー、なんか書き殴ってたら収集がつかなくなったんですけど、ふと思ったので書いておきました。なんかこれくらいのノリのほうがブログっぽいでしょ。たまにはいいんじゃないかな、と。

じゃあの。

2016年7月1日金曜日

kcm89 をコンパイルできなかった記録

結論。挫折した。

ドキュメント少ないし、 autotools ないな。
暗黙的なルールあるんだろうな。
が第一印象。

トップでバーンと make

% make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src build
cc -Wall -Wextra -O2 -DDEBUG -ansi -pedantic -MMD -MP -I. `llvm-config --cflags | sed 's/ -DNDEBUG / /g'` -Wno-long-long -c main.c -o main.o
/bin/sh: llvm-config: command not found
main.c:2:10: fatal error: 'llvm-c/Analysis.h' file not found
#include
         ^
1 error generated.
make[1]: *** [main.o] Error 1
make: *** [build] Error 2

はい、聞いてないヘッダでてきたぁ。
とりあえず、 brew で探して info してみる。

% brew info llvm
llvm: stable 3.6.2 (bottled), HEAD [keg-only]
Next-gen compiler infrastructure
http://llvm.org/
Not installed
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/llvm.rb
==> Dependencies
Build: xz ✔, cmake ✘
==> Options
--universal
Build a universal binary
--with-clang
Build the Clang compiler and support libraries
--with-clang-extra-tools
Build extra tools for Clang
--with-compiler-rt
Build Clang runtime support libraries for code sanitizers, builtins, and profiling
--with-libcxx
Build the libc++ standard library
--with-lld
Build LLD linker
--with-lldb
Build LLDB debugger
--with-python
Build Python bindings against Homebrew Python
--with-rtti
Build with C++ RTTI
--without-assertions
Speeds up LLVM, but provides less debug information
--HEAD
Install HEAD version
==> Caveats
LLVM executables are installed in /usr/local/opt/llvm/bin.
Extra tools are installed in /usr/local/opt/llvm/share/llvm.
This formula is keg-only, which means it was not symlinked into /usr/local.
OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.
無難どころと思われるオプションで install しますかね。

% brew install llvm --with-clang --with-clang-extra-tools --with-compiler-rt --with-libcxx --with-lld --with-python --with-rtti

がんばれー

これた。ちょっとこれ以上はいま時間取れそうになくて頓挫。


コンシューマの FPS ゲームに手を出したら痛い目にあっている

いやぁ、PS4 - PlayStation 4 をついに購入してしまいましたね。5月。
理由としては

  • 日本の動画配信サービスなどと相性がいい
    • システムに手を入れず、PS4が単体でゲーム実況などができる機能を持っている
  • ビッグタイトルがそれなりにある
    • スクエニとか頑張ってますし、Steamで配信されているようなインディーズゲームもいくつか配信されています
    • たとえば、スマートフォンでプレイして「操作感がゴミだなぁ」と感じてしまった Minecraft や Downwell が人類の叡智である十字キーで遊べます
  • 後輩の誕生日プレゼントに PS Vita クロスバイの製品がふくまれた
    • ウィッシュリストに入れていなくても砂が 2t とか送れるテクニックを使って送りつけてきたやつがいます
    • 先輩としては沽券にかかわるので PS4 くらい一発でポチるぜといきました
買ったモノなんですが、初音ミクマニアの私としては初音ミクモデルいったと思うでしょ?でもタイミングが悪かった。それはまだ発表されてない時期にポチった。

かといって普通のモデル買ってもつまんないでしょ、というわけで Call of Duty : Black Ops III モデルを購入して「Ubuntuカラーだ!」と気分をよくしたわけです。その後、初音ミクモデルが発表されて、ぐぬぬったわけですが、まあどうせ Play Station 4 は E3 の前後で 4K モデルが次期に発売されることがちらつかされたので、現在のやつで Play Station 4 に慣れたら、艦これモデルだかかすみちゃんブルーがきたときに書い直すかもしれないですね。

閑話休題。
PS4 の購入とともに魔の契約と思っていた Play Station Plus についに今月から加入しました。ということで、 FPS ゲームのオンライン対戦や格闘ゲームのランクマッチをガンガンしていかないと使わないだけ損という貧乏根性がでてきております。
契約はガッツリ12ヶ月契約ですね。後ろは振り返らない。ところが、Call of Duty : Black Ops 3 のオンラインプレイしてみたら、ぜんぜん相手を倒せない!!!
驚くほど倒せないんですよ。

自信はあったんですよ。それなりに。PC の FPS で動きには慣れているので、基本的な「死んで覚えろ」系のことはできるんですよ。丁寧にクリアリング、パイカッテッイングしながら周囲の安全を確認してエンカウントポイントでの警戒、足音で敵の位置を探るなどなど。
しっかし、圧倒的にAIMが定まらない、つまり狙いがガバガバ。
マウスなら一発で敵の頭らへん、武器によっては「こっから腰撃ちで勝てるはず」というところに入るんだけど、アナログパッドきつすぎ。

何が言いたいかというと、基本的な立ち回りができていて、慣れているような動きをするんだけど、妙にトロい動きをしているヤツがいたら、それは私なんで接待してください。
嘘です。温かい目で見てください。

くっそぉ、武器のカスタマイズとかしたいけど、勝てないとぜんぜんポイントが入らなくてスコープとかも気にいるような性能のものが手に入らない…
11月には Call of Duty の次回作出ちゃうんで、それまでにはなんとかアナログパッドの右で AIM ができるようになっておきたい、欲を言うならスナイパーライフルでクイックショットしたり、壁抜きで相手を抜くようにはなっておきたいんだよなぁ。

ん?オーバーウォッチ?知らない子ですね。

PCのグラボ?ぶっ壊れると面倒なので自作には関わりたくないですね?

そんなこの頃です。よろしくお願いします。

2015年12月17日木曜日

Smalltalk ではどれくらいまで長いクラス名が標準で使われているものなのか

Smalltalk Advent Calendar 2015 #Qiita の 12月16日の記事になります。

仕事で結構長いクラス名ついてるなー、っていう感じのヤツが Seaside にふくまれてい
て、コードを書くなどしていました。まあ、それはそれとして「標準で配布されているイメージで定義されているクラスの名前のうち、いちばん長いものってどれくらいの長さなの?」って気になっちゃったんですよ。

気になったら調べてみよう。ということで、やってみました。
環境は Smalltalk Pharo 5 です。



コードとしてはこんな感じ。
| allClasses |
allClasses := Smalltalk allClasses collect:  [ :each |  each name ].
allClasses sort: [ :a :b | a size < b size ].
allClasses inspect.
はい。他の処理系で試してみると違う結果が出るかもしれませんね。

Pharo 5 での結果は以下のようになりました。

どうやら
RBLiteralArrayContainsSuspiciousTrueFalseOrNilRule
というクラスがいちばん長いクラス名のようです。50文字です。2位は48文字で2文字差でのトップとなりました。

上の方だけみていると、フォントがプロポーショナルなためか、これより横幅が長く表示されているものがあって、ほんとうにこの結果あってるの?と思いましたが、下位の方をみてみると確かにきちんとソートできている模様ですね。



こういったシステム全体を俯瞰してすべてに対しての見通しがよいというのも Smalltalk のよさですね。

みなさんも「どんなメソッド名がいちばんよく使われているか」など気になったら調べてみると面白いかもしれません。

2015年12月15日火曜日

Smalltalk でシステムの基幹部を作っている会社に転職した話

pyspa Advent Calendar 2015 の 12月14日のエントリでありつつ、Smalltalk Advent Calendar 2015 の12月22日のエントリです。

「pyspa のこと、ナニ書こうかな?」って思ってたんたけど、よく見たら自分の好きなことでよかった。

こんなワタクシは数学における四択問題の解答欄に数式を細かく書いて不正解となるようなバカでした。人の話はちゃんと聞く、見る。大切ですね。はい。

そして、記事を書き終え、クリスマスを迎えた本日12月25日に Smalltalk の話でもあったな、ということで Smalltalk Advent Calendar 2015 12月22日のエントリとしました。

転職

わたくしの今年のトピックはなんといっても転職ですね。
今年の8月まで水色の六角形の会社で働いておりましたが、実際のところ、一昨年の夏くらいから、紫色の楕円をみると痙攣しそうになる病気になってましたね。いま思うと。

しかし、全部丸投げしてもらったものは赤い宝石で大勝利できたり、今年の頭くらいからちょくちょく赤いコードのレビューもしていたんですよね。さすがに紫の楕円だけではみな痙攣するようになってきたか、と思ったんですがレビューすると赤い世界では `SomeObject#true_or_false?` 的なものが `SomeObject#isTrueOrFalse` とか書いてありまして、クソ真面目にレビューで「これはなんか赤くないので治せってば」ってマサカリ投げてみたりすると「移植性を優先します」みたいなコメントが返信されてきちゃったりなんかして、クソワロスでした。

はー、もう。人海戦術の世界では何かがおかしくても、みなおかしいと分かりつつ、自分の船だけ前に進めようとして、全体として前に進んでいなくてもいいっていう雰囲気になるんだなぁって思ったんですよね。意思統一が計られていて、きちんと郷に入れば郷に従えを守るメリットを知ったるステージで仕事したいなぁと思うようになったんですよ。

そんなときに、 Smalltalk 界隈の重鎮から Smalltalk-er が不足していて困っている、という連絡をいただくことができまして、そのまま Smalltalk で仕事している会社に転職してしまいました。
ちなみに、誘っていただいた方とは15年くらい前にはじめて知りあった感じです。大学生時代にアルバイトしていたソフトウェアハウスが自社製の Smalltalk の処理系を作成し、それを用いて Linux 向けや Windows 向けのアプリケーションを動作させ、高速化させる必要のあるリリース版の作成には各プラットフォーム向けに C言語 のコードを生成するっていうヤツ作っていたんです。そんなもんで、たぶん自分がプログラミングしてはじめて給金してもらった仕事は「独自 Smalltalk 処理系向けに GTK のバインディングと Win32 API のバインディングを書きながら、 Smalltalk VM の修正した」というヤツになりますね。我ながらクレイジーですね。これは。

そうそう、15年前ほどの付き合いという話でしたね。まあ、そのクレイジーな大学時代に、独自 Smaltalk 処理系によるプロジェクトについてのコンサルというような感じでわたしがアルバイトしていたソフトウェアハウスにきてくれていたのが尊敬する師、というわけでした。その師に誘われて断る理由もなく引きこまれていったという感じてす。
しかも、ちょうど自分が悩んでいた「郷に入れば郷に従えを守るメリットを知ったるステージ」がほとんど Smalltalk という処理系が保証していますよ。だって、 Smalltalk って鎖国してガラパゴス化してるもん。

いま、うちの会社はまだ開発環境とかも「これでなんとかなるのでやってきた」という状態なので、ガンガンと「ごくある普通の近代的な開発」になるようにバシバシやってます。上にあまり人がいないし、自分がいちばんインフラとか暗黒UNIXテクノロジーに詳しいようなので、すんなり意見が通るのがラクですね。マルバツ表みたいなの書かなくても仕事できる!!!
ちなみに、エンジニアも採用しているので興味のあるヤツらはなんか連絡するといい。

来年

よくわかんないけど、年末だし最後に来年についてとか書くといいのかなってふと思ったので「来年」って書いてみたんだけど、とりあえずいまの仕事について期待されているくらい、あるいはそれ以上の成果を求めて仕事していくっていうのと、落ち着いたらコミュニティ活動とかも積極的に顔出せるようになるかなって思います。

あれ?

主にみどり色のトグロについてのアドベントカレンダーだった気がするのだが、でできたのが紫色の楕円と赤い宝石と気球ですね。
気球といえば、わたしは中田さんとかアラン・ケイとか梅澤さんを勝手に自分の師として尊敬しているんですが、うまい具合に気球つながりで弟子入りできた気がします。いや、まだ公式に弟子にしてもらってないし、リアル気球しないと中田さんの弟子にはなれない!まだまだやることはたくさんあるな!!!

ということで、これからもヨロスク!

2015年12月6日日曜日

BlockClosure の引数の数に対してことなる引数の数を与えてよしなに呼び出す

Smalltalk Advent Calendar 2015 - Qiita の 12月5日の内容です。
Smalltalk のブロッククロージャについて書きます。
このエントリで使用している Smalltalk は Pharo Smalltalk ですが、他の処理系でもだいたい同じのはずです。

BlockClosure をみてみる

Smalltalk では [ と ] で囲まれている部分がブロッククロージャとなります。



[ ] を inspect it してみました。
BlockClosure の詳細をみたい場合はどうすればいいんでしょう。っていうときに、 Smalltalk が他の言語と大きく異なる動的な評価という特徴を生かすことができます。

BlockClosure のインスタンスに対して browse というメッセージを送ってみましょう。


BlockClosure のインスタンスを inspect している下のペインで self browse と打ち込んで do it します。

システムブラウザに BlockClosure を表示することができました。ラクチン。

BlockClosure に引数を与えてみる

Ruby のブロックのように BlockClosure も引数を受け取ることができます。
たとえば、ふたつの引数を受け取って、ふたつの引数を Transcript に出力してみましょう。

BlockClosure にふたつの引数を設けて、ふたつの引数を与えるには BlockClosure でふたつの引数を受け取ることを明示的に記述して、BlockClosure>>#value:value: を使います。

出力できました。

BlockClosure が受け取る引数の数とはことなる数の引数を与えてみる

ちょっと意地悪をしてみましょう。
ふたつの引数を受け取る BlockClosure に BlockClosure>>#value: でひとつの引数を与えるとどうなるんでしょうか?
ありゃりゃ、 Error が発生してしまいました。
Ruby ではこういった意地悪をするとふたつめの引数には nil が入って例外が起こらないという挙動をするので、わりと適当に書きたいときは便利な挙動だったりします。
% ruby -e '[1,2,3].each{|i,j| p i; p j}'
1
nil
2
nil
3
nil
うーん、厳密なのもよいけれど、柔軟に受け取る引数の数より少ない引数を与えて呼び出したときにエラーが出ないのも魅力的ですね。
BlockClosure で受け取る引数とはことなる数の引数を与えてもエラーが発生しないようにできないものでしょうか。

BlockClosure の受け取り引数をよしなに処理するためのメッセージ

cull: というメッセージを使うと BlockClosure が受け取る引数の数よりも多い引数を与えても平気な挙動になります。

cull も万能ではないです

この cull: を使えばブロックの引数の数と不一致な数の引数を与えて呼び出すことができるわけですが、欠点もあります。
それは何かというと、組み込みの状態からいじっていない BlockClosure では、よっつの引数までしか扱えないのです。
原因は単純によっつまでしかメソッド定義がないからです。まあ、よっつ以上の引数なら別の方法を使った方がよくないか?という気もしますので、自然な気がします。

多くの引数をブロックで受け取りたい場合はどうすればいいのか

value: メッセージを送信して、引数に OrderedCollection とかを与えればいいんじゃないですかね。

おわりに

今回の話のネタ、ほとんど梅澤さんにアドバイスしてもらったことをまとめただけだったりします。
すみません。すみません。すみません。