ありがちな「なぜ”デスクトップLinux"は普及しなかったのか？」へのありがちな反論
ITmedia エンタープライズに、なぜ“デスクトップLinux”は普及しなかったのか？という記事が載っていました。デスクトップLinuxの失敗については今まで何度も色々な人が書いており、どうということは無い記事なのですが、
AppleのUIを最高と考える私にとって、“Macより劣るWindowsの劣化コピーでしかない”デスクトップLinux（当時はRHEL4でした）は、苦痛でしかなかったのを覚えています。コンシューマーデバイスにおける一貫したUIの大切さを実感したということですね。
・・・という、Apple 信者が何度も何度も何度も蒸し返す誤った理論が述べられておりムカついたので、大人気なく反論しようと思います。
続きを読む.app ドメインで、サーバーレスアプリを公開する
奥が深い症候群
ソフトウェア開発の職場でよく発症する症状
奥が深い症候群
使いにくいツールに「奥が深い」と言ってのめり込む症候群。往往にしてもっとシンプルな解決策が他にある。
Tex、C++、Perl、Vim、Emacs、弊社フレームワークなどで発症しがち。
理由があるはず症候群
不合理（に見える）仕組みを見つけた時「こうなっているのにはきっと理由があるはず」と推測して、手をつけようとしない症候群。
実際には、
- 過去に必要だったが現在では不要になったものだったもの
- 継ぎ足しで実装して複雑になってしまったもの
- 原作者の無知によって誤った実装をしているだけのもの
といった、特に理由なく不合理になっているケースも多く、こういったものは取り除くべきである。
また、理由があって変わった仕組みになっている場合も、「きっと理由があるはず」と推測するのではなく、作った人やドキュメントに当たって本当の理由を調べるべきだ。
レガシープロジェクトのメンテで発症しがち。
現実を見ろ症候群
ソフトウェアのバージョンが古い、テストが未整備であるなどの問題について「だが、そんな時間は無い。現実を見ろ！」と、無視してしまう症候群。
ビジネスでは時間や人手を効果的に配分しなければならないが、果たして、メリット・デメリットを十分評価した上で、PHP 4.0 を使い続ける判断をしたのだろうか？新機能を使えないプログラマーが不満を持つというだけでなく、セキュリティホールを抱えてしまう恐れもある。
また、「時間がない」のはテストが不十分で、不具合修正に追われているからかもしれない。
こうすればイケるよ症候群
ツールの欠陥を、ツール自体の改良ではなく、使い方で回避しようとする症候群。奥が深い症候群に似ているが、プログラマーよりもプログラムを使う社員に発症しがち。
購入したソフトウェアだと、不具合報告しても直してもらえず（「それは仕様です」なんて言われたり）、運用でカバーするしかないことが多い。だが、内製のソフトウェアでそれをし出すと、結局は誰の得にもならない。
エンドユーザーは社内SEに忌憚なく不満を伝えるべきだ（もちろん、社内SEが真摯に対応するという前提の下での話）。
だってわかんないもん症候群
こうすればイケるよ症候群が悪化した状態。
ツールの機能を深く理解せず、目先の目的を達成するためだけの誤った使い方をし、副作用が無視できないほど巨大化した段階で社内SEに持ち込み尻拭いをさせる症状。
「どうしてこんなになるまで相談しなかったんですか？」という質問に「だって、難しくてわかんないもん！」「俺たちは素人だもん！」と感情的に反発するのが特徴。
なお、プログラマーでも発症することがある。PlayやRailsなど（患者から見て）エッジなフレームワークを触ることになったとき発症し、作法をよく理解せずに実装、バグをしこんでしまう。
発症するときは、ツールの利用側と開発・運用側とが没交渉であることが多い。まず、顔を合わせて話すことから始めよう。
あとがき
書いていてどこかで読んだことがあるな、と思ったら、この本でした。
この記事より、もっと多く、もっと深い内容が書かれているので、お盆におじいちゃんにもらったお小遣いで買って読んでください。
アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン
- 作者: トム・デマルコ,ピーター・フルシュカ,ティム・リスター,スティーブ・マクメナミン,ジェームズ・ロバートソン,スザンヌ・ロバートソン,伊豆原弓
- 出版社/メーカー: 日経BP社
- 発売日: 2009/10/22
- メディア: 単行本
- 購入: 10人 クリック: 156回
- この商品を含むブログ (46件) を見る
今までに使ったプログラミング言語
仕事でまともに使っている言語
Ruby
Ruby on Rails のために使っている。 汎用言語としてはRubyが一番完成度が高いと思っている。 「標準ライブラリのメソッドが豊富」といったレベルだけではなく、 周辺ツールが充実している。依存関係したければBundler、カバレッジにはSimplecov、スタイルチェックしたければRubocopと、定番がありそれらを使っていれば100%困らない。
Scala
Playのために使っている。
静的型なのに、Rubyに近い自然な書き方ができるのだが・・・いま一つ「これじゃない感」がある。 必要だと思う機能はあるが、それを上手くアレンジできていない感じ。 例えば、「case classの "case" は形容詞ですか？」といった所。
また、Rubyに比べて周辺ツールが未成熟な感じがある。 sbt で依存関係をダウンロードするのに２時間も３時間もかかるのは辛い。
Java
レガシープロジェクトの触ることがある。
不具合修正しかしないせいか、Javaのコア言語は世間で言われているほどひどいとは思わない。
ただ、DIとかアノテーションとかビルドツール等が、ブラックボックスになっている感じがある。 機能も落とし穴もいっぱいありすぎて理解できない。 Javaに習熟したオジサンたちには分かるんだろうが・・・。
JavaScript
WEBアプリを開発するのに当然書くのだが、オマケ程度であり、 ガッツリ書くことは無い。 また、半分は純正のJavaScriptではなく、JSX (Reactの方。DeNAのではない）を書いている。
嫌いと言うほどではないが、Arrayを配列に使えなかったりするのがタマに辛い。 また、１年おきにパッケージマネージャが変わるのも辛い。
CoffeeScript
既存のRailsプロジェクトの不具合修正で触れる。
昔は「スゴい！画期的だ！JSはいずれCSに置き換わるに違いない！」と 思ったのだが、そうはならなかった。まあ、JSの機能が充実してきてるのだから、仕方がない。
でも、「.coffee を .js で書き直した」というコミットを見ると悲しい。
シェルスクリプト（Bash）
ちょっとしたコマンドを書くのに使っている。リリースやCIのスクリプトとか。
エラー処理等をちゃんとするなら、Rubyなどの高級言語で書くべきなのだが、 Bashで書く方が圧倒的に楽。
最近使わない言語
Python
かつては（今も？）Windowsでまともに使えるLLはPythonしか無かったので、 Windows PCしか持っていなかった学生時代にフリーウェアを書くのに使っていた。 仕事では何故かPythonプロジェクトを担当する機会が無い。
言語としての機能は、RubyやJavaと同等と言うか好みのレベルだと思う。
ただ、パッケージマネージャが長年中途半端な状態が続いているのがタマにキズ。 例えば、pip をインストールするのに easy_install が必要だったり、 setup.py を正しく書くのが難しかったり。 最近は pip が（ようやく）インタープリタに同梱されるようになったりしたようだけど。
また、近頃は統計や機械学習の分野で人気のようだが、これも仕事では縁がない。
Elm
Haskell ベースのAltJS。すごく未来的な感じがしたが、実際にはELMを使う未来は訪れなさそうだ・・・。
しかし、しれっとRailsが5.1からElmをサポートしていたりする。
十進BASIC
教育用言語。高校レベルのグラフを書くのには最高だと思うが、高校は卒業してしまった。
direnvで、使用するdocker-machineを指定する
.envにこんな風に書けるようにします。
# .env
use docker-machine my-rails-app
ディレクトリに移動すると、自動的にdocker-machineを（まだ起動していないなら）起動し、docker-machine envで環境変数をセットします。
$ cd ~/Documents/my-project direnv: loading ~/.direnvrc direnv: loading .envrc direnv: using docker-machine my-rails-app Starting "my-rails-app"... Machine "my-rails-app" is already running. direnv: export +DOCKER_CERT_PATH +DOCKER_HOST +DOCKER_MACHINE_NAME +DOCKER_TLS_VERIFY $ docker ps # my-rails-app のコンテナ一覧が表示される
インストール
git clone git@github.com:doloopwhile/direnv_use_docker-machine.git ~/direnv_use_docker-machine echo '. ~/direnv_use_docker-machine/direnv_use_docker-machine.sh' >> ~/.direnvrc
使用目的
docker-machineではdefaultホスト1個しか立ち上げていない人が多いと思います。
docker-composeなどを使えば、コンテナ名が被らないようにできるので、 それで困ってないのかもしれません。
しかし、プロジェクト毎にDockerホストを立ちあげると便利なことも。
- ポート番号がかぶらない（複数のWEBアプリを同時に
docker-compose upさせておける） - ホストごとにDocker Engineの設定を変えられる
docker psなどのリストがスッキリする- 混乱した時は
docker rm -f $(docker ps -a -q)してリセットできる。
反面、イメージをホスト毎にインストールする手間などもあります。
Docker開発はまだ試行錯誤が多いのですが、この方法も案外便利かもしれませんよ。
