読者です 読者をやめる 読者になる 読者になる

gaaamiiのブログ

悪気なく間違ったことを書いているときがあります。コメントやTwitter、ブコメなどでご指摘ください

速さを測りたい

とりあえず http://yomomo.net をたたき台にしてやってみたい。何から始めたらいいんだろう

参考

メモ

ツールはいろいろあるけれど、それが解決している問題とかアイデアに注目すると立ち向かえそうな気がしてくる。一つ一つのコマンドを覚えるとつらいけど、もっと大きい枠組みで見ていくと楽しい。技術がわかると、普通に使っているものが、どうやって実現されているのか理解することができて楽しい。ただ頭が悪いので、時間止まればいいと思ってる。

もっとも楽しいのは、普段使っているものをバラバラに砕いて理解できたとき。なので、例えば以下の様なことについて、上から順に疑問を潰せていけると楽しい。

  • プログラムを書いてから実行されるまで
  • リンクをクリックしてからページが表示されるまで
  • git clone でプロジェクトが手元にコピーされるまで
  • cd hoge でディレクトリを移動するときに起きていること

1年職場でソフトウェア開発に関わってみてわかったのは、余計なことを自ら知ろうとしないと、ツールを使う手順にばかり精通してしまって内側については何も習熟しないということ。普通に使ってるツールをいつでもバラバラに解体したり仕組みを説明できるようになりたい。

wdim 遅い

この前作ったやつ。

https://rubygems.org/gems/wdim

Ruby起動が遅くてあまり気持ちよくない。 対話型にすればいいような気がしてきた。

バージョン管理システムってなんだ

職場でSubversionを使ってるはずなんだけど、自分含めてみなさんかなり理解が怪しい。そもそもバージョン管理とは何か、というのをまとめたいのでこっそり書き足してまいります。

バージョン管理史ざっくり

RCS(Revision Control System)

  • 初版:1982 年

CVS(Concurrent Version System)

  • 初版:1990年

Subversion

  • 初版:2000年

Git

  • 初版:2005年

参考

http://psyto.s26.xrea.com/misc/svnbook/svnbook.ja.pdf

Emulsification ってなんだ

料理

パスタをゆでて食おうと思ったときにレシピ検索をしたら Emulsification(乳化)って言葉を知った。英単語で呼ぶとかっこいいっす。

r.gnavi.co.jp

まず、乳化とは何かというところなんですが、本来混ざり合わない水と油が、均一に混ざり合った状態のことを言います。

とは言っても、水と油だけでは完全に混ざり合いません。ドレッシングをイメージすると分かりやすいでしょうか。

市販の瓶に入っているドレッシングって、普通に置いておくと下の部分に水分、上の部分に油分があって、食べる直前に振りますよね。振ると水と油が混ざり合ったようになるけど、またしばらくすると分離する。

しかし、マヨネーズは酢(水分)と油が混ざり合い、戻ることはありません。それは、たんぱく質(たまご)が入っているからです。たまごが乳化を安定させる役目をしています。

では、パスタソースの場合はどうなのかと言うと、茹で汁に溶け出したパスタのでんぷん質が、その役割を担います。

この乳化によって、オリーブオイルと水分が混ざり合い、とろみのあるソースとなり、麺によく絡んで美味しく食べられるというわけです。

わかりやすい。

ソフトウェアエンジニアってなんだ

自分の頭の中にあるソフトウェアエンジニアについて書いておく。ここには頭のなかにあるものを出すだけなので間違いがある。ツッコミがあればください。

これといった目的はありませんが、家族や友だちに何をしているのか説明できないとつらい、という苦しみがちょっと動機になってます。頭の中が整理できたら、家族や友だち向けに書き直したい。

ソフトウェアとは

まず、ソフトウェアとはなんでしょうね。 [ここにソフトウェアの歴史について良い文量で小話を入れる]

コンピュータ上で動く

僕は、ソフトウェアとはコンピュータ上で動く発明品とかアイデアグッズのようなものだと思います。逆に、同じだけの価値を持つ発明品でも、魔法瓶やアンパンマンの落書きボードとかはソフトウェアじゃない。

ソフトウェアの種類

アプリ

使う人と一番近いところをアプリケーションと呼んだりする。なんでソフトウェアのユーザーに近い部分がアプリと呼ばれるようになったのかなど歴史を調べると楽しそうです。

アプリといっても色々ある。

モバイルアプリ

iPhoneAndroidで動きます。

ブラウザアプリ

Google ChromeSafari で動きます。

デスクトップアプリ

WindowsMacで動きます。

サーバー

Webサーバーが起動したところ

サーバーは、必ずしもアプリに必要なものじゃない。データをずっと保存しておいたり、他のユーザーと共有したりするときに必要になる。


※ここの分類は大事なので何回か書き直す予定。

Webサーバ

要求を受け取ってアプリケーションサーバーに投げる

アプリケーションサーバ

いろいろな処理をしたりデータベースサーバからデータを取得したりいろいろする

データベースサーバ

何かしらのデータを良い感じの分だけくれる(※かなり理解が怪しい)。

総じて言えるのは、要求元があるということ。じゃないと、サーバーという言葉の意味がよくわからなくなる。

※書き直す予定範囲ここまで。


(ついでに)ネットワークについて

サーバーはアプリの便利度を高めてくれたり、事業者・開発者・運用者がユーザーデータを収集することを可能にしてくれます。しかし、ネットワーク環境が無ければサーバーは存在できません。サーバーと絡むことがあるエンジニアはネットワークについての知識も必要です。

たとえば、iPhoneInstagramのアプリを起動した時に、どんな通信が行われているのかというのを説明できるようになりたいです。要求の流れは最も単純にはこんな感じでしょう。

iPhoneのInstagramアプリ --「データくれ」--> Instagram のサーバ

ユーザーは日本の東京にいながら「データくれ」という要求をどこに存在するのかもわからないInstagramのサーバに届けることができます。これを実現しているのはどんな技術か。

[ここに簡潔でわかりやすい説明]

組込み

あまり良く知らないけど組込みという大きな世界があるらしいけどよく知らない。

ソフトウェアの特徴

複製が楽

複製が楽。gem install とかすればいい。

配付が楽

配付が楽。Githubとかにpushすればいい。

修正が楽

修正が楽。テキストエディタで文字列が保存されたファイルを書き換えればいい。

材料費いらず

材料費いらず。まあでもサーバー代とかかかるか。発明だけなら金はいらない。人を雇おうとすると金はたくさん必要っぽい。

ソフトウェアエンジニア

ソフトウェアを作る人、また、運用する人。ソフトウェアはだいたい作って終わりじゃないから、ソフトウェアエンジニアはそれを運用するためにも頑張る必要がある。

ソフトウェアエンジニアがやることについて、以下に書きます。

  • 作る
    • 設計する
    • コーディングする
    • リリースする
  • 運用する
    • テストする
    • 改善する
    • 協業する
    • 障害に備える

作る

ここではソフトウェア作りを3つに分けます。

設計する

やりたいことから実現する方法を定義していくのが設計だと思います。

ソフトウェアを作ろう、となったときはまず機能が列挙されます。ただそれだけではごちゃごちゃになるので、機能群を整理します。

また、ソフトウェアで必要な機能の下から上まで全てを自分たちで0から作ることはほとんどありません。たとえばiPhoneアプリならAppleが提供している機能を使いますし、WindowsのデスクトップアプリのプロジェクトならMicrosoftが提供している機能を使います。やりたいことが100個あったとしても作る必要があるのは10個だけかもしれません。

コーディングする

メモ帳を開いてHTMLとJavaScriptを書くこともできるし、プログラム作成支援ソフトを開いてボタンを押すことでプログラムの雛形を作ることも出来ます。

リリースする

作ったものを使う人たちに配ります。

運用する

運用する。

テストする

すごい無責任な話、自分でポチポチつかってみて一回動いたからOK、ということもできる。できるけど、たいてい何か問題が起きる。

テストにはいくつかの方法がある。テストの粒度は書かずに大雑把に二つに分ける。

人が使う

最も原始的なテストは、人がそのアプリを使うこと。ただ、それだけではテストにならないのでこんな感じになる。

  1. 前提条件と期待する結果を定義する。
  2. 使う
  3. 結果を確かめる

エビデンスとしてExcelスクリーンショットを残す文化の職場もある。というか自分は今そういうところで働いている。

プログラムからアプリを実行して結果を判定する

人間がやるといろいろ問題がある。何せ疲れる。ミスもする。

  1. 前提条件と期待する結果を定義する。
  2. 使う
  3. 結果を確かめる

上で書いたこの3ステップのうち、2と3は、全てプログラムからできるはず。少なくとも人間よりは正確に。。。

ただ、1の定義の仕方が、プログラム言語の習得並にコストがかかることがあるのでどこでも誰でもできるわけではないという問題もある。そういう文化がないところで自分が担当する部分だけテストコードを書くわけにもいかない(整備されたツールは諦めて書き捨てのスクリプトで代替する(テストを実行するのはスクリプトだが成果物はあくまでもExcelファイル)か、望ましいツール群の導入をチームに啓蒙するか、という話になるのかもしれない)。

う。。何の話をしていたんですかね。とにかく、プログラムがそのアプリを実行して結果を判定する場合、その定義を正確に記述して、テストを実行するツール群の整備などを行うのが、たぶんエンジニアの仕事になる。

改善する

ユーザーの要望も変わっていくので、ソフトウェアもバージョンアップが必要とされたりする。大きな機能追加はもちろん、小さな改善を行うのも大事な仕事だと思う。

  • ボタンを押すと画面遷移してURLも変わっていたが、ページの一部だけ書き換えれば使い心地がよくなるからそうしよう
  • APIからの応答が遅くてアプリのさくさく感がない。サーバー側で要求をもらってからの処理とデータベースへアクセスするときのクエリなどを見なおそう
  • 送信ボタン押してからくるくるボタンが長い時間回ってて気持ち悪いから画面的には成功したことにして、送信処理は裏側でやって失敗した時にアラート出すようにしよう

協業する

協業、つまり複数人で一つのものを作ることもある(仕事や人気のあるOSSだとほとんどそうかもしれない)。この場合に製造するときのコミュニケーション的な問題に対処するのも仕事になる。

障害に備える

今は動いているけど将来はバグになりそうなものを、そうなる前に直す必要もある。

アプリの設定ファイルとしてXMLファイルがあって、その値をもってアプリが動作しているようなのを例にあげる。

<GENERALSETTING>
  <SETTING1>良い感じの設定値1</SETTING4>
  <SETTING2>良い感じの設定値2</SETTING4>
  <SETTING3>良い感じの設定値3</SETTING4>
  <SETTING4>良い感じの設定値4</SETTING4>
</GENERALSETTING>
(XMLからSETTING3の設定値を抜き出すプログラム)
1. ファイル内から"SETTING3"に一致する行を探す
2. <SETTING3></SETTING3>に挟まれている文字列を抜き出す
3. 抜き出したものを設定3の設定値とする => 良い感じの設定値3

上記のままであれば動く。けれど、XMLが将来こうなるとどうか。

<SETTINGS>
  <GENERALSETTING>
    <SETTING1>良い感じの設定値1</SETTING4>
    <SETTING2>良い感じの設定値2</SETTING4>
    <SETTING3>良い感じの設定値3</SETTING4>
    <SETTING4>良い感じの設定値4</SETTING4>
  </GENERALSETTING>
  <SPECIFICSETTING>
    <SETTING1>特別な感じの設定値1</SETTING4>
    <SETTING2>特別な感じの設定値2</SETTING4>
    <SETTING3>特別な感じの設定値3</SETTING4>
    <SETTING4>特別な感じの設定値4</SETTING4>  
  </SPECIFICSETTING>
</SETTINGS>

SETTING1 というタグは二つあるので、「良い感じの設定値3」を取り出すつもりが、「特別な感じの設定値3」が取り出されてしまうかもしれません。先に書いたプログラムの例は曖昧な表現になっており、設定値をどこから取り出すのかを厳密に定義できていません。しかし、運用を始めた時に設定ファイルが持つGENERALSETTINGのSETTING3が一つしかなければ、とりあえず期待通りに動いてしまう。

とりあえず期待通りに動かすことを繰り返していると矛盾がいろんなところに組み込まれていくので、それを少しずつ解消していく取り組みが大事だと(自分のわずかな経験からですが)思います。

関連・参考リンク


yuuki.hatenablog.com

関連書籍

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)


途中です。書き足していきます。