2021年12月12日日曜日

とある Rubyist の「次の20年」

Rubyist近況[1] Advent Calendar 2021 の12日目です。前日とか次の日は適当にリンク先からたどってください。

 12月12日を今年のアドベントカレンダーの担当日に選んだのは、先月の同日、11月12日で40歳となったので、そのあたりについて書こうかと思いました。

11月12日は40歳に東京から千葉に引っ越しました。生まれ育った街に引っ越しています。

いまはリモートワークで仕事できますし、生まれ育った街も交通はそこそこよくなっており大手町まで40分くらいで出られるようになっているみたいです。いざという時は出勤もできますが、これからはなるべくなら人がたくさんいるところに行かないようにしたいですね。

このエントリでは11月12日からの人生を「第三の人生」としたときに、いままでどんな人生を過ごしたのか、これからの人生をどうしたいのか、自分が感じている人生の転換を区切りに、簡単に「第一の人生」「第二の人生」「第三の人生」と分けて所感を記録しておこうと思います。

おそらく、これは間違った見解であったり、微妙なところもあるのですが所詮は40歳ほどではこれくらいの感覚だった、ということを残しておこうと思いました。限られた時間で適当に考えて、適当に書いていますしね。

すみませんが、この文章はまとまりがないですし、他人に理解されることを目的としてないです。

自分用の記録ですが、読みたい方がいたらどうぞ。


第一の人生

生まれてから、会社員になるまでの人生。

育った家庭は裕福ではありませんでしたし、家庭環境にも多少の問題はありましたが、特別に劣悪さが飛び抜けているということもありませんでした。総合的には平均より「少し悪い」か「悪い」くらいの環境だったのではないかと思います。

「いや、あなたの家庭はよい環境だったでしょう」と私の家庭を周囲から観測している方に言われるかもしれませんが、そもそも見栄っ張りで世間体を異常に気にするという「悪い」環境でしたので、それが作り出している情報に騙されているだけです。そこまでよい環境ではありません。

裕福ではありませんでしたが、この時期は自分が好きなことに挑戦して、無理なことは無理だと体験したり、自分が将来どんなことをしたいかの選択と集中などをしました。

さいわい、いまはそれほどエンジニアとして大失敗した結果になったわけではない(気がする)ので、苦労が表に出にくいですが、いろいろと挑戦や失敗はあります。

野球に挑戦してプロ野球選手になりたいと思ったことはありましたが体が大器晩成な育ちだったので少年野球ではそれほど活躍できなくて挫折しました。

高校生のときは勉強をろくにせず将棋に熱中してしまって、何かに結びつかないかと思いましたが、別にプロ棋士などになれるほどの棋力はもちろんなくて単なる趣味になりました。しかも、いまはその将棋もメチャ弱くなりました。指さないと弱くなりますね。本当に。時期は羽生善治が活躍していたときですが、自分は米長邦雄の雀刺しばかり刺してました。

ゲーム好きだったのでプロゲーマーのような職種、当時はプロゲーマーという職業は日本ではマイナーだったので、ゲーム雑誌のライターみたいなのが適職なのかもと思ったことなどもありましたが、思っただけでした。

結局は中学生から高校生の時期にパソコンに興味をもちはじめて、高校生のときにはVisual Basic でプログラミングをはじめて、その後に C/C++で仕事をしている人たちが交流しているメーリングリストに入り浸るようになりました。

大学生のときにはソフトウェアハウスでのアルバイトを通して業界の当たり前を知っていくことになりました。
この時期にものすごい量のソフトウェアマネジメントの書籍を読んで、マネジメントというものについて勉強しました。マネジメントは勉強しておくと関わってはいけない上司がすぐにわかるようになるので、プログラマの方々も勉強することをおすすめします。

すでにソフトウェアエンジニアの世界に片足つっこんでいて、惰性でそのままエンジニアになった感じですね。

第二の人生

会社員になってから40歳になるまでの人生。

どうやら、自分は世間の人と比べるとちょっと変わり者だったのでかなり苦労がありました。

この「変わり者」という言葉は誤解されやすいのですが、変わり者だからといって勝手に何かの才能が芽生えたり、天才になったりするわけではないです。単に他の人とどうにも違う考え方などをしがちだった、ここではただそれだけの意味で「自分は変わり者」と記録しています。なんのことはない、ただ普通とは違うというだけのことですが、それだけで自分にとってはいろいろな経験や苦痛になりました。

新卒で大企業に入るも馴染めず、社会的なストレスから愚痴っぽくなり、インターネットにそういったことを書いていたら「宮本洋一」という人間から、繰り返し犯罪行為をされました。このときはとてもつらかったです。どんな犯罪行為であったのかは機会があったのでまとめてあります。ちょうどこの時期、宮本洋一氏からの嫌がらせによる風評被害で落とされた採用があったのでこういった文書が残ることとなったのですよね。実害は発生しています。実害を防ぎたい意図で書ききってしまったところがあり、いま読むと焦りからの誇張が散見されますが95%くらいは事実です。

宮本洋一氏は逮捕されなかったからといって、彼の犯罪行為はなかったことにはならないです。むしろ、逮捕されなかったのだから司法などでは償うこともないわけです。罪を償わないという卑劣さと悪質さ、ぜひ死ぬまで犯罪者である自覚を背負い続けてほしいものです。自分の家族は同じようなインターネットのインシデントがあると「宮本洋一が世界にはたくさんいる」といった表現をするようになっていますし、完全に「宮本洋一」という言葉は自分の周りでは悪質な人間を表したり、犯罪行為を表す言葉となってしまいました。これはもう自分にはどうしようもありません。すみません「日本姓氏語源辞典 (人名力)」著者の宮本洋一さん…

他の会社経験では明確なパワーハラスメントについてCTOに相談するも「仕事ができていないからハラスメントを受けて当たり前、仕事でパフォーマンスを出してからそういった相談をしなさい」というアドバイス(パフォーマンスが出ないのはハラスメントが起因なので、これは無限に解決に結びつかないアドバイス)が返ってくる会社でのつらい労働と会社都合退職。

技術力のないCTOが率いるベンチャー企業でハラスメント(後に冤罪であることを伝え聞いている)の疑いをかけられて会社都合退職。

いろいろとありました。

だいたい疲れる話ですね。何か掘り返されたときにそれらしい自衛ができそうな音声やメモなどの記録は残してありますが、可能であれば使うことなく墓まで持っていきたいです。

全体として第一の人生で豊かになった人生をすり減らして生計としていた時期なのだろうと、いまとなっては感じています。

仕事だけではなくてプライベートもすり減ることが多かったです。

基本的に悪人に騙されやすいんですよね。

どうしてこんなことになったんだろう…って思うこともありますが、変わり者なのだから仕方ないと思っています。たまに「変わり者だから」などの理由で済ませるのではなくて、諦めずに気合いを入れて変わり者をやめなさい、というようなことを言ってくる人がいますが、できたらやってますし、人の根幹について簡単にアドバイスをしようとするのは頭がおかしいと思っていますので、頭がおかしい人たちは相手にしないことにしています。すみません。


第三の人生

先月の11月12日が40歳です。第三の人生と書いているのは、40歳からの人生の予定とまでは言わないですけれど、生きていて感じていることですね。

ちょっと第二の人生での仕事が格闘技で例えるなら、有刺鉄線デスマッチや極真空手みたいな刺激の強い仕事が多くて疲れを感じました。

第三の人生ではスポーツチャンバラのような楽しい仕事を主軸にしていきたいと思っています。

すり減った人生を豊かにすることを主軸にしたいというわけです。

第一の人生で育んだようなものを再び取り戻さないと今後に不安があります。

60歳くらいになったらまた心をすり減らせるような人生を送る必要があるかもしれませんが、それはそのときに考えます。

楽しく過ごせて、それが続けられればいいんですけどね。

直近、なにやってんの?と言われるとフリーランスで仕事をしたり、していなかったりします。その時の気分によって体力や精神のすり減りがなるべくないことを重視しています。仕事を続けることよりも健康の方が大切です。

なんだかんだで精神的な豊かさがいちばん大切なのだな、と思うようになりました。

観測範囲では、同世代のエンジニアが頑張って知識を身につけていたり、技術力を向上させていたりする傍ら、なにか大切なものや精神をすり減らして言動がおかしくなってしまう方たちをたくさん見るようになってきてそう思うようになりました。第二の人生のわたしも何かおかしかったのでしょう。そう思って苦労やおかしかった言動は過去のものにしていきたい。だいぶ、この文章も苦いものがありますがね。

さしあたりは生まれ育った街で平穏に生きたいと思います。

この文章はツッコミどころある感じで書いてしまいましたが、どうせ所属している会社がないのですから会社に回りくどくこの記事をどうにかしてくれとか連絡されることもないし、たまにはいいでしょう。

40歳にもなって脇が甘いことがわかっている文章を適当にインターネットに書くくらいには稚拙です。でも、それが自分なのです。


今年の Ruby

Rubyist のアドベントカレンダーですし、Ruby committer なので Ruby についても書きたいと思います。

予定は未定とはいえ、今年に入れたい、入れられればよいと考えている修正があります。

振り返ると、昨年に FreeBSD の Dtrace 対応を無効にしないとコンパイルできないので規定を無効にするというコミットを入れました。

Ruby 3.0.0 のリリース前に微力ながらコミットした話

それから、じっくりと三ヶ月ごとくらいに調べていたのですが、どうやら FreeBSD のツールチェインが変わったのでリンクができなくなった、というような内容をどこかでみました。

しばらく、ツールチェインが元のように修正されないのか LLVM の動向を追っていたのですが、どうにもそういった雰囲気はなく、次のバージョンの LLVM 12 でも同じ挙動でリンクに失敗することを確認しました。FreeBSD のバージョンアップを待っていても解決するような問題ではなさそうです。

どうしたものか、と考えていたのですが、ふと ports の状況はどうなっているのかを見たら、Ruby と Dtrace についての議論を見つけました。比較的大きな修正を make する前にパッチして Dtrace を有効化してコンパイルが通るようにするというような処理が ports に入っていることを確認できました。

Bug 257527 - lang/ruby27: add DTRACE option

クリスマスまで残り少ないですがこの修正を Ruby の本体に入れることができないか見てみようと思っています。パッと見ではこれを取り込んでもライセンス的には問題ないはず。

留意するべきこととしては FreeBSD の ports は FreeBSD のバイナリを作ることができればうまく機能しているということになりますが、これを Ruby 本体に入れるとなると Dtrace が提供されている他のプラットフォームでも妥当性のある修正かどうかを判断する必要があります。

FreeBSD はおそらく ports で適用される修正をそのまま適用した状態で Dtrace が機能するのでしょう。Dtrace は他にも Solaris や macOS でも提供されている機能なので、その修正が Solaris と macOS で Dtrace を有効化したときに正常に機能するのかを確認したいところです。

Intel 64 macOS はどうにかなりそうな気配がありますが、M1 macOS ではどうなのかということや Solaris での確認に少し不安が残りますね。ports でのビルドで適用される修正が他のプラットフォームのことも考慮されているものならよいのですが、その確認はまだできていません。

ちょっとここまで積み残してしまったというか、気付くのが遅かったので今年に間に合うかは微妙ですが、手をつけたことについては最後まで追っていきたいと思っています。

あいさつ

今年もさまざまな方のおかげで、無事に年を越せそうです。
来年もよいお年を。

2021年2月18日木曜日

デブサミのCiscoのブースでDevNetとCMLいうものを教えてもらった

 とりあえずのメモ


DevNet

https://developer.cisco.com/


DevNet 紹介記事

https://gblogs.cisco.com/jp/2018/10/cisco-devnet-introduction/


DevNet 紹介スライド

https://www.slideshare.net/CiscoJapan/cisco-modeling-labs-cmldevnet


公式が提供している DevNet についての日本語の情報ポータル

https://learningnetwork.cisco.com/s/jp-devnet


Cisco Modeling Labs
CML は Cisco Modeling Labs の略

https://developer.cisco.com/modeling-labs/


Cisco Code Exchange

CML でのコード例などはこちらから探せる

レポジトリが GitHub などと結びついている

https://developer.cisco.com/codeexchange/


あとできちんとした記事にする…かもしれない。

2020年12月25日金曜日

Ruby 3.0.0 のリリース前に微力ながらコミットした話

概要

今年もクリスマスです。Ruby 3.0.0 がリリースされました。
微力ながら Ruby 3.0.0 には自分の変更も取り込まれたのでそのメモです。

 FreeBSD では Ruby 3.0.0 がビルドできない?

3.0.0 のリリースを調整しているチャットで「どうにも FreeBSD 12-RELEASE では Ruby 3.0.0 がビルドできないらしい」という噂を聞きつけたのが24日の18:00くらいのことでした。

3.0.0-preview1 と 3.0.0-preview2 と 3.0.0-rc1 などの 3.0.0 の系列は configure のときに --disable-dtrace を指定しないとバイナリが生成できないなあ、というところまでは24日に実機で切り出して原因を特定しました。

その後はプライベートで Zoom 忘年会があったのでたらふく酒を飲んでしまい修正のことなどすっかり忘れる。寝る。

以下参考。

チケットとしては存在していたもののチケットを追えておらず、たまたまリリース前のワチャワチャでコアメンバーが話題にしているのを見なければスルーしていたと思う。

プラットフォームが FreeBSD のときは DTrace を既定で無効にする

翌日の25日は10:00くらいにモソモソ〜っと configure のときの既定が --disable-dtrace に倒れていた方がよかろうと autoconf のための configure.ac をいじりはじめる。久々にいじったので気持ち悪かった。

11:30 ほどに形が定まって、手元でのテストなども終わった。コアメンバーに報告し、そのまま「コミットしてください」という反応を成瀬さんからもらった。はやい。すごい。聖人。

ところが、いままで Ruby にコミット入れるのは Subversion で ci.ruby-lang.org にアクセスしてやっていたもんだからイマドキの方法が分からん。

GitHub.com からでもよいですか?と聞いたところ、これにも成瀬さんから PR でいいですよ、という返事をすぐにいただけました。

ササッと github.com/takano32 に fork して PR を作りました。ありがとうございます。


ちょいちょい CI の様子をみてもらってそのままマージしてもらいました。助かり。

GitHub.com での主張がデカい

これがマジでマジにリリースの直前の取り込みだったそうで面白いことが起こった。
GitHub.com では git でタグを打つとそのタグについてのページが生成されるのだが、Ruby 3.0.0 のリリースページは以下のように生成されました。


なんか少し笑ってしまった。

これじゃあ、このページを見たひとは Ruby 3.0.0 は @takano32 ってヤツがリリースしたんだってよ。みたいな様子に見えなくもないじゃないか…主張がデカい!!!成瀬さん、リリースありがとうございます。


Ruby 3.0.0 についての所感

さまざまな変更や改善があり期待できる。メジャーな部分については周りのブログなどを見ていただきい。

個人的にテンションが高まったのは Erlang のように読み書きできそうな機能が増えたことです。


最後に

FreeBSD ではこの記事で扱った変更を取り入れる前までは Ruby 3.0.0 をインストールするときに下記のようなオプションが必要な状態でリリースに向く形でした。

CONFIGURE_OPTS='--disable-dtrace' rbenv install 3.0.0

この記事で紹介させていただいた変更によって以下のコマンドで入るようになりました。手元でも動作を確認済みです。

rbenv install 3.0.0

FreeBSD で Ruby 3.0.0 をビルドするという特殊な状況に向けての修正ですが、少ない変更の割には多くの方の時間を節約することができそうな修正になったのではないかと思います。

詳しく調べてみると LLVM がデグって DTrace のオブジェクトをリンクできなくなっているようなので、新しい LLVM がパッケージで降りてきたら、これをリバートするような変更を忘れないようにしたいと思います。

では、みなさんもよい Ruby 3.0.0 ライフを。

メリークリスマス!!!

2020年12月12日土曜日

今泉研究室では2006年にプログラミング言語Haskellの洋書を輪読していた

この記事は

Imaizumi Lab Advent Calendar に寄せた記事である。

Haskell との邂逅

 2006年のわたしは Haskell というプログラミング言語に憧れをもっていた。

ところが、日本ではあまり話題になっておらず、Haskell の技術関連書籍はすべて洋書。

そんななか、今泉研究室は研究で英語の論文を読解できるようになるための訓練も兼ね、ゼミで洋書を輪読するという話を聞いた。

その日以来、研究室では周囲を言いくるめ、なんとかしてゼミで Haskell の洋書を輪読する方角へと誘導する私がいたのである…

そして、ゼミでは Haskell を使って関数型プログラミングを理解する Introduction To Functional Programming Using Haskell を輪読する流れにすることに成功したのであった!

当時の Haskell 事情

日本ではあまり話題になっておらず、というだけではイメージがしにくいと思われるので当時の Haskell 事情を簡単に列挙しておく。

  • Haskell の最大派閥となる処理系は GHC ではなく hugs 98
  • hugs 98 の仕様がコロコロ変わっており、書籍のサンプルコードが修正なしでは動かない
  • hugs 98 のキラーアプリは Audrey Tang が実装した Perl 6 の処理系となる pugs くらいしかない
上記のような状況であり、なぜ Introduction To Functional Programming Using Haskell の輪読の誘導に成功したのか分からない…

わりと積極的にやりたいことをやろう!と言えばやらせてもらえたが、言わなければ放置される研究室だったと当時を振り返る昨今である。

Chapter 12: An automatic calculator

Functional Programming Using Haskell のなかでも最難関の章を担当したときの資料とコードがでてきた。
An automatic calculator という証明系の処理系を作成する章である。難易度に容赦がない。
多くはすでに記憶にないのでコードと実行結果のみを示しておく。
書籍でこられのコードについて解説されていたという分量にも驚きだが、いくつかの自明なコードについては記述さえなかったと記憶している。 断片的にそのままの写経では動かなかったため、きちんと証明が動いたときにはうれしかった記憶がある。 そのうれしさにかまけて、後日ラムダ計算の簡約器を作ることになったのだが、それはまた別の話…

所感

短いが、今日の記事は以上である。上記の解説をまとめたスライドとレジュメを作成し 2006年3月20日に研究室で発表を行ったという記録が残っていた。
また、その他にも Functional Programming Using Haskell で担当した章はいくつかあり、すべてについて hugs 98 での動作を確認している。
くどいようだが書籍の写経そのままではコードは動作せず、動かせていた学生は自分だけだったと記憶している。
もっと詳しく知りたいなどのことがあればさらに解説を加えたり、別の章について言及するかもしれない。
記憶がある部分についてでご容赦いただきたいが…

輪読の様子

なお、難しいことが英語で書かれていたのでゼミの発表内容の多くは壊滅的だったもよう。🙈

2018年8月7日火曜日

CoD: BO4 の Private Multiplayer Beta Weekend 1 に参加

Call of Duty: Black Ops 4 の Private Multiplayer Beta Weekend 1 に参加した。

プライベートベータテスト

よくオープンベータテストというのは聞くと思うが、プライベートベータテストというのには耳慣れない方も多いのではないか。

簡単に説明すると、オープンベータテストは参加する意思があれば参加できる、というようなテストになる。それに対してプライベートベータテストは参加するのに対象となるプロダクトの予約などをしている消費者が参加できるテストとなっている。

しかしながら、今回の CoD: BO4 のプライベートベータテストは少し特殊で PS4 については製品の購入をしなくても参加できるものであった。
PlayStation Store でプライベートベータテストの権利が販売されていた様子をみた方もいると思うので補足をすると、この販売は 100 JPY で行われていたものであるが、プライベートベータテストが終わった後には払い込みのあった決済手段に払い戻されるそうだ。
なぜそんなことをしているのか、ということについて憶測にはなるが、これはクレジットカードが使えることを確認することによってレーティングが守れている状態でプレイされているということをシステム的に保証するものだと思われる。
なお、プライベートベータテストの参加については Amazon.co.jp でもプロダクトコードを発行していたのでクレジットカードがなくてもそちらを経由して参加することはできたと思う。

ちなみに、オープンベータテストやプライベートベータテストとは別にクローズドベータテストという言葉もよく耳にすると思うのだが、これはオープンベータテストやプライベートベータテストが原則的に参加する意思があれば参加できるというものであるのに対して、クローズドベータテストでは参加する意思がある希望者からさらに抽選されたりする場合が多い。

おすすめのプレイ

閑話休題。

自分は CoD: BO シリーズについてはプレイ経験はあったものの、家庭用ゲーム機で参加という経験は浅かった。パソコンで慣れた操作に比べるとぎこちない。率直に表現すれば死にまくる、殺されまくる、ということになる。

プレイリストにある Search & Destroy は実力がないと同じチームメンバーに迷惑をかけてしまいそうと感じる。Chaos TDM(Team Death Match) については撃ち合いがうまくないとゲーム内経験値が蓄積されにくいと感じる。

個人的に初心者におすすめなのは Control だ。これは新しいゲームモードでなかなか他でも見かけない感じがするけれどもスプラトゥーンでいうところのガチエリアみたいなヤツである。ポイントを占領して維持することで戦績となる。

Control が初心者におすすめできる理由はその目的が故にキルデスに依存しなくてもゲーム内経験値を稼ぐことができる、ということである。
ポイントの占領と維持が目的なので占領に参加するだけでも経験値を積むことができる。
ポイントの占領は敵チームメンバーを排除して一定時間、ポイント付近に滞在すること、滞在の間にキルされない、という行動で可能になる。
これに貢献すればよいので、味方がクリアーしてくれたポイント付近に一緒に残り、防衛するという、初心者にとって比較的難易度が低い消極的な参加方法でも経験値を積める。
初心者すぎて狙いがままならないようなプレイヤーでも索敵をして相手に撃たせて、すぐに逃げるといった行動でも十分に貢献できるのでよいと思う。
逃げ回って占領だけするキャンパーになれというわけではなく、貢献しつつ育っていけばよいのではないか、ということだ。

おすすめのスペシャリスト

同じような理由で CRASH くんがいい。

あとでかく

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 らしさがマシマシになってよりハッカーにとって優れていると思うんですがね。なんでわざわざ英字配列を選択しちゃうの…もったいない…

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

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

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

じゃあの。