手段としてのソフトウェア

作りたいものが見つからず不安なので,せめて何か蓄積したいと思いました。

(いまさらながら)リーダブルコードを読んだ

たいへん久しぶりに更新します。

いろいろあってメンタルの調子を崩し,1年以上休職中ですが,やっと調子が上向いてきました。

全体的にレベルの低いこのブログでございますが,カレン・カーペンターも "Don't worry that it's not good enough for enyone else to hear." とうたってくれたし,そもそも自分のために書いているので,恥ずかしくても,このままいきます。

 さて,前置きが長くなりました。今回はこちらの書籍から学んだこと,感じたことをまとめておきたいと思います。

www.oreilly.co.jp

 

「コードをよく考えて書くのって,楽しかったんだなあ」と思いだすことができました。

ここ数年,仕事ではソフトにかけられる時間が一番少ないという状態が続いていたので,ただただ時間に追われ,修理しながら走り続けるみたいな,もう最後に自分がケツ持つしかないんだろ!みたいな,ああそうですね,基板はひとりじゃ無理だけど,コードはみんな帰ってからでも1人でも書けますもんね!みたいな・・・まあ,自分の話はいいのですが。

この本では,「最も読みやすいコードは,何も書かれていないコードだ」など,そもそもの話というか,身もふたもない表現もユーモア混じりにたくさん出てきます。明らかにコードを書きまくってきた人の話しぶりで,すんなりと腑に落ちます。

読みながら,果たして自分はどうだったか,と振り返ると,「このコードはもっと読みやすく書けないか」なんて考えを深める時間は,ずいぶん取れていなかったなあ,サボってしまっていたなあと恥じ入るばかりでありました。

 

この本からは,「コードを読みやすくするには,こういうテクニックや考え方があるよ。だけど, 絶対のルールなんてものはないから,いつも考えることが大事だよ」という暖かいメッセージを感じます。何かと断定的な表現をしないところに,実態をよくわかったうえで書いてくれているなと共感を覚えます。自分たちで考えるための余白が取ってあるので,いろんなプロジェクトにおいて,指針として共有するのにも適しているように思います。

 本文中でも触れられていましたが,この本の内容をまず自分自身で実践し,チームのメンバーと共有し,可能ならさらにその外へと「読みやすく書く技術」を習慣として定着させ,相互に高めあっていくことができれば,開発が本当に楽しくなるだろうと思えました。

私などがいうことでもありませんが,読みやすく良い本でした。

 

メモを取りながらゆっくり読み,たくさんの気づきがありましたが,最後に,いまの自分に特に足りないと思えたものを,自戒をこめてメモしておきます。

 

  • ライブラリを知ること。簡潔なコードを書くのに必要なのは,ライブラリが何を提供してくれるかを知ることだ。("12.2 ライブラリを知る" より)
  • あとでテストするつもりでコードを書くと,おもしろいことが起きる。テストしやすいようにコードを設計するようになるのだ! ("14.8 テストに優しい開発" より)

 

マイコン上でOSレスで,8kBのRAMをやりくりしてると,デバッガもstdioも使えないし,テストコードもなかなか・・・なんてものは言い訳でした。これからは,新たな気持ちでコードを書けそうな気がします!

 

データとの向き合い方

統計学は最強の学問である 実践編」をやっと読んだ。読んだつもりになっていた時点から相当時間が経っていて自分でも笑えるが,何もしていないよりはマシだろうし,途中でちょこちょこ実務にも役立っていたので良しとする。

 

まず何より大切なのは,データに対する姿勢を身に着けることだと思う。どういう手法があり,それぞれどういった強みがあって,結果をどう受け止めるべきか,そのあたりの実務に必要な内容が良い具合に書かれていてたいへん助かった。

数学的にどうか,というところは,これから必要に応じてコツコツやっていこうと思っている。

 

自分がプログラマの端くれであることもあって,機械学習がどうとか,そういう高みというか流行りに乗りたいという下心があって読み始めたが,無意味にオーバースペックな手法を適用するより,エクセルでできることを,まず手を動かして確かめてみることの大切さみたいなものが良く分かった。

 

重回帰分析,クラスター分析,なんだか身構えてしまう手法だったけれども,分類をいろいろ試してみて,しっくりくるものを選ぶためのツールだ,とか,とりあえずやってみるための大切な初めの一歩を教えてもらった。

 

アタマが悪いなりに,一歩ずつ進んでいこうと思っている。

PyCharm Communitiyさえすんなりといかない

早くも放置しかけている。気持ちはあるのだけれど,能力がないのです。はずかしい。

 

とりあえずメモしておこうと思うのは,Windows10,64bitマシンでPython2.7を動かそうと思ったら,以下に気を付けようということでした。

  • 素直に32bit版でそろえる
  • scipyのインストールは無理せずインストーラ superpack でやる
  • PyCharmでvirtualenv使っててTcl/Tk関連エラーが出るときは,[Settings]->[Build,Execution,Deployment]->[Console]->[Python Console]->[Environment Variables]に,TCL_LIBRARY=C:\Python27\tcl\tcl8.5(など,tclが実際にインストールされているフォルダ) を追加する

 

たったこれだけのことでも,結構はまりました。

 

ブログ書くほど勉強が進まない話

今は英語と統計の基礎を少しずつ勉強しなおしているのですが,さっぱり進んでいきません。オバマ大統領のスピーチを聞きながら勉強するというスタイルが致命的に間違っている気がしてきました。

 

仕事のほうでも,製品にたいするアイデアをひねり出すということとか,すでにあるデータをどう使おうかとか,というか,今年度何をやろうかとか(未だに)考えていたりして,基本ずっと考えています。

 

技術はそれ自体が目的ではなく,やりたいことに対して適切なアプローチをとるための道具が欲しいと思っているのですが,やりたいことがおぼろげすぎて,先に道具を手に入れないと目的地が見えてもこない,みたいな,この思いつかなさは,手法を知ればなにか打破できるのではないかというぼんやりとした夢のような,疲労と暑さと寒暖の差,長い通勤時間にまみれてだんだん気持ちよくなってきたような毎日吐きそうになっているようなそういう,

 

かんじです。

気分転換にいったんPythonとかそっちにいこうかな。

手段としての統計

さて。

あまりに数学的に理解できず恥ずかしくて涙が出そうだけれども,まずは使っていきたいなと思う内容を書いておこう。なかなかPythonの勉強まで進まない。とほほである。

 

分散,標準偏差

データがどのあたりに散らばっているのかを掴むために使う。二つの要因を比較するときにも使えたりする。明らかにグループ間で分布が違うよね,みたいな。見ればわかることなんだけれども,まずは裏付けになる。

正規分布とは,データのうちの95%が±2SD (標準偏差) の範囲に収まっている状態を指す。

標準誤差

有限個のデータを収集し平均値を調べたいというときに,真の平均値がどの範囲に存在するかを推定するのに使える。また,誤差範囲はどの程度まで許容できるかを最初に定義しておけば,標準誤差は計算で求められるので,誤差が許容範囲内に収まるようにサンプルサイズを設計するのにも役立つ。

 

検定 (z検定,t検定,正確検定など)

ある仮説を検討する際,その仮説に対する帰無仮説が成立する確率 (つまり,仮説が大外れである確率) がどの程度かを推定するために使う。

データ数が1,000件以上得られるようならz検定を用いて問題ないが,数十程度であればt検定を用いたほうが無難である。また,データ数が多い場合にt検定を用いるのは問題ない。結果はz検定と一致する。

回帰分析

ある要因が,結果に対してどの程度影響があるかを調べるのに使う。結果をy (縦) 軸,調べたい要因を x (横) 軸に取ってデータを散布図にプロットしたとき,この x, y の関係を仮定して数式化した一次式 (y = ax + b) による回帰直線を考える。実際のデータから得られた x, y の値と,そのときの x を一次式に代入して計算される y の値の差,つまり「実データと回帰直線のy方向でのズレ」の2乗(=分散)の合計が最小になる (=最小二乗法) ような直線が回帰直線である。  

ここで重要なのは傾き (a) である。調べたい要因の変化が,得られる結果にどの程度影響しているかを示している。

 

回帰係数の標準誤差

前述の傾きの標準誤差を考える。これは,使用したデータのうちの1件が変化したときに,それが回帰係数にどの程度影響を与えるのかを見積もる作業と考えていい。

だから,同じデータ数であっても,x軸の値がどの程度ばらついているか,ということも考慮に入れる必要がある。十分間隔が離れていれば,あるデータ1件のy軸の値が1変化した,といった場合でも,他のデータとの間でΔxが1だった場合と,100だった場合とでは,得られる回帰直線の傾きへの影響は全然違う。だから,この計算は残差平方和(回帰直線から予測されるy値と実際のy値のずれの2乗の合計をデータ件数で割ったもの)を,実データのx値(=説明変数) の偏差平方和 (x値の平均値からのズレの2乗の合計)にデータ件数をかけたもので割って算出する。

 

重回帰分析

単回帰分析では一見相関がなさそうに見えるものでも,さらに説明変数を増やしてみて,グループ分けして考えてみると相関が見えてくる場合がある。こういう,複数の説明変数について一気に分析するのが重回帰分析。

説明変数は,それが例えば「男女」のような質的変数の場合は,0と1のダミー変数にして考える。

 

 

IT業界はブラックなの?

見ようによってはすっかりヤバイ業界になってる気がする。特に私のような凡人にとっては。ワークライフバランス?何それ?

 

進歩が速い

いや,たいへんいいことなんだけれども。技術革新というよりは,考え方の革新といったほうが適切な気がして,素晴らしいものが素早くできてしまい,一気に広まる。

 

障壁が低い

これもいいことなんだけれども。ハードウェアやインフラのコストがとにかく下がっていて,一人当たり年間30万円あれば相当な設備が揃う。

 

競争が激しい

当然の結果として,こうなる。これも消費者側からするといいことなんだけれども。

天才と同じ土俵にいなくてはいけない。ここでいう天才っていうのは,頭の良さみたいなこともそうだけれど,むしろ,好きでたまらなくて24時間コード書いていたいような人が怖い。

 

どうやって食っていけばいいの

未来には,絶対に今よりいいものが今より安く手に入る,そんな世界になってる。時間当たりの収益を上げられる人に報酬が集中するのは当然で,それは所属する組織であったり,立場であったりする。技術力と強い相関はあると思うけど,必ずしも比例しない。地道に積み上げただけではどうにもならないことのほうが多い。

 

そしたら,会社員としてのプログラマーはこれからどうなるんでしょう?

GitHubに成果?OSSやコミュニティに貢献?イベントに登壇?終業後や休日もコード?ソフトウェア好きなら苦にならない?あれ,なにこれ?伝統工芸の後継者とかなの?

 

どこかで割り切る

目立てない人は給料上がらない。だって,いわゆる物理的な仕事量あたりで見たら,収益は下がる一方だから。稼げる組織に属せるかどうかで決まる。

仕事は仕事,休日は別の趣味に,という人はもう,給料はもうこの先増えない。下がることはあると思う。

 

というわけで,私の場合は,ソフトウェアは手段と割り切ることにしました。

読んだつもりで

実は読み終わっていなかった,「統計学は最強の学問である [実践編]」。

統計学が最強の学問である[実践編]---データ分析のための思想と方法 | 西内 啓 | 本 | Amazon.co.jp

 

何となく勉強のための本は,紙で買ってしまう。技術書とかなら,電子書籍のほうがいいんだろうなと思うし,逆に楽しみのための小説も電子書籍がいいと思うけれど,このあたりはつい,本屋で手に取って買う。

まず著者の文体とセンス,エッセンスの選び方が素晴らしくて本当に読んでいて楽しい。ご自身でおっしゃるように,実務として取り組まれた経験が生きているんだろうなと思う。楽しくてためになる。

  • 関連を見るために標準偏差の考え方を使う
  • データを多面的に見る
  • 何のために調べているのかを忘れない

バカみたいな感想しかまだ出てこないけれども,とりあえず使ってみよう,という気持ちになれて非常にありがたい。