一つ一つを上手くやる その３
昨日はちょっとしたスクリプトの話をしました。
今回はその逆に複雑な問題を一つのシステムで片付けるという考え方について記事にします。
こういった事をするシステムで僕がすぐ思いつくのはMS製品ですね。
MSoffice系のソフトやMOSSなんかは一つのシステムで多くの問題を解決してしまおうというコンセプトなんだろうと思います。
どう考えても機能過多ですからね（汗）
別にこの考え方自体は悪くないのですが、この考え方に習っていきなりものを作ろうとすると出来上がるまでに相当時間がかかります。
一つのプログラムに必要なコードの量を考えればイメージつき易いかもしれませんが、1000文字の文章を誤字なく書くのと10000文字の文章を誤字なく書くのでは難易度は格段に代わります。
僕なんてこのブログ書くのですら誤字脱字していないか結構神経使っています。
しかもミスしたら、何処をミスしたか確認して直してテストするというのを繰り返す必要があるのです。
こういった作り方をするよりも、出力結果が非常に単純で軽量なプログラムを結合させてものを作っていく方がよっぽど楽ですね。
少なくともきちんとしたプログラマ（？）がいる場合は、一つ一つを再利用しやすいように作り上げて必要になったら使えるように自分や周りの人のための道具として共有していたりします。
githubなんかを覗いてみると、そんなコードがいっぱい転がっていますので、興味がある人はコードを読んでみるのも勉強になると思います。
github
https://github.com/
もちろんものにもよりますが、自分で何か作る時は出来るだけ小さなプログラムを書き結果を別のプログラムに渡す事念頭において書いてみると、自分の道具も増えて勉強にもなっていきます。
忙しい人の場合は、必要なところだけ抜き出し組み合わせて自分の好きなシステムに組み直すといった事も出来ますね。
そういえばこんな格言もあります。
格言
よいプログラマはよいコードを書く。
偉大なプログラマはよいコードを借りてくる
見る目がある人は、どれが使えるのか見極めて効率よくシステムを作ってしまうのです。
今回はここまでです。
最後まで読んで頂いてありがとうございました。
一つ一つを上手くやる その2
シェルを題材にそれでは、簡単な例を挙げてみたいと思います。
手頃な例としては下記webサイトに掲載されていたワンライナーのスクリプトです。
CLIマジック：使って役立つワンライナー入門
http://sourceforge.jp/magazine/09/01/14/0134202
ps -eo user,pcpu,pid | sort -r -k2 | head -6
内容：手元のシステムにて実行中のプロセスのうちでCPU時間を最大限に消費しているもの上位5つを特定する
パイプ（｜）のマークはコマンドの実行結果を次のコマンドに引き渡す記号になります。
実行内容については参考先のURLに任せるとして、これらのコマンドは其々独立したプログラムで、サーバ管理なんかをしているとこのようなコマンドを組み合わせる事によって、１からコードを書かずに欲しい結果を最短で得る事が出来るようになる。
もう少し付け加えると、スクリプトの動きを理解していると少ないコードでバックアップ用のプログラムを動かしたり、障害が発生した時にアラートをメールで送信するといったものも簡単に作れます。
運用・保守といった業務をこなしている人には楽する為には必要な技術となります。
では、これが何故出来るかというと、それぞれの部品を作っている制作者は実行結果を受け渡す事を前提作っているからコマンド間の連携がとれるのですね。
ものによっては非常に複雑な動作が出来るコマンドもありますが、多くは単純なテキストベースの実行結果を元に次に引き渡しやすいように出力する。
それぞれがフィルタリングの動作をとっているのですね。
そうする事によって、複雑な事を簡単にする事ができるのです。
先人の努力に感謝ですね。
こういった工業製品のようなものを一つ一つ積み上げていくと、何れは大規模システムを支える監視システムみたいに動かす事が出来るかもしれません。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
一つ一つを上手くやる
前回からの続きになります。
前回は無駄を省く事についてピックアップしていましたが、それだけではまだまだ利用し易いシステムにはなりません。
無駄が無いだけで局所的な環境でしか動かないとしたら、次はどこにでも移植出来るようなシステムでないと不便です。
ある一つの物事に対してスペシャリストであるのは良いのですが、他の場所では全く使えないというものだと、また１から作り直しになってしまいます。
それに比べて、移植性のあるものはシステムは使い回しが効くので、同じような仕事に対しても直に対応できます。
多くのシステム開発者は後者の方を出来るだけ目指してシステムを作り上げているのですが、どうもパッケージ化したあたりから雲行きが怪しくなる事が多いです。
特定のパッケージソフト（社内向けとか）は始めからどんな環境でも使えるように移植性を考えて作られているのであれば良いのですが、ものによっては社内で作ったシステムの資産を売ったら一儲け出来るのではという考えから販売されているものも中にはあります。
僕が９回の転職をしてきた限り、社内のルールが標準的だった現場というのはみた覚えがありません。
人と一緒で、会社毎に個性というのはしっかりあります。
これを自覚せずに自分たちが勝手に標準だと感じているものをみんな使えば便利だよねとおもい売り込んでくる人達の口車にのってパッケージを購入すると、その後には結構悲惨な結末になる時がありました。
こういった、一つ一つの違いにを吸収するための一つの手段としては一つのシステムをパーツ毎に明確に分離しておいて組み立て易い状況にしておくというのは一つの手段なのですが、これをやるには一つのモジュールを無駄なくコンパクトにしておいて、後で流用しやすい形にしておく事が大切になります。
そうすると、いざ必要になった時にわざわざ最初から作る必要がなく、無駄なくシステムを構築していく事が出来ます。
これは例え小さな仕事でも後でも流用出来るようにしておくと格段に仕事のスピードがあがります。
インフラをやっているとこれを実感出来るのはシェルスクリプトですね。
次回は一例としてシェルについて触れたいと思います。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
無駄を省く その４
今回は無駄が多くなるケースについて今回は記事にします。
実際に中小規模までであれば少ないと思いますが、それなりに社内でシステムを抱えてしまった場合、しかも経理や人事などのワークフローに関わるものを別々に構成してしまった場合、非常に無駄の多い仕組みが出来上がる事が多いように感じます。
本来はもっとコンパクトな業務の改善だけをしたかったものが、要求が雪だるま式に膨らみ色々な人の野望や欲望をフレーバーに育ったシステムは結構目も当てられないですね。
これはシステムという言い回しだけでなく組織の仕組みとして結構厳しい所が多いのが現状でしょうか。
このケースで僕がイメージしているのは縦割り行政的なシステムになります。
利用者の利便性よりも別の問題を解決するために導入されたり作られたものですね。
これは結構多く世の中に蔓延っているように感じます。
こういったシステムが生まれる経緯としては、最初に書いたように野望や欲望といった欲求に任せてシステムの要件をまとめた場合に起こり易いと思います。
こういったものを避ける方法の一つとしては先に「やらない事」を決めてしまう事とそれに対して関係各所に合意を得る事が挙げられます。
禁止事項を決めないと、後であれできないの？これできないの？という事を何時までたっても言ってくる人や、聞かなかった振りをして平気で要件に混ぜてくる人もいますので、この辺りはしっかりと抑えておかないと後々面倒な事になる事があります。
この辺りはアジャイルプロセスとウォーターフォールプロセスの開発についても記事にしていきますので、その時とりあげはしますが結構人って容赦がないので、分かってくれる"だろう"で事を進めると大変な面倒な事に巻き込まれます。
そういった状況から回避する事も会社でエンジニアをしていくには必要なスキルになるので是非注意してみて下さい。
今回はここまでです。
最後まで読んで頂いてありがとうございました。
無駄を省く その3
実際に無駄を省くにはどうすれば良いかといえば、ボトムアップで構築していく方法が一番手っ取り早いと思います。
必要になったら作る。
その作ったものは常に流用出来るように作る。
必要になればその流用したものを使う。
こういう事をコツコツ積み上げていけば無駄の無いものを作る土台が出来てきます。
更に欲を言えば、この作ろうとしたものに対して既に作っている人間がいないかを確認すると作る行程すら無しに必要なモノが手に入ります。
rubyであればgem
perlであればcpan
pythonであればPyPi
など、この辺りを調べてみたりgithubでソースを見つけてくるなどをする事で一から作る手間を軽減する事も出来ます。
まぁ、この辺りのコードを流用するにあたり色々と気にしないと行けない事というのはありますが、ソースコードというのはネット上に公開されているものが有るという事を知っておくだけでも、web系の開発の仕事とする時に有利に働く事が有ります。
後は、其々が動くインフラを構築してしまえば良いので、提供したいインフラの設計決めれば、ある程度の規模までなら開発出来る準備は整っている状況だと思います。
社内インフラだと、javaでないとダメとかあるのでそういった開発言語や環境に縛りがある場合は諦めるしかありませんが、そもそも今後そういった案件を受けるのはあまり得策では無いと感じますので、技術の知らない人間の一般的とか標準という言葉を鵜呑みにせずに、本当にこれから活きる言語を学んでいけば、作り手として職を心配する必要は無いのではと感じます。
職業でエンジニアをやる場合は、僕の方法は難しいかもしれません。
ただ、職人としてエンジニアの道を進んでいくなら、本当に活きた言語や環境に手を染める事をオススメします。
それだけでも、普通の人と差をつける事ができます。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
鋭く斬る
Unixの哲学の話は20:00にアップしますが、今書いている「無駄を省く」という事について居合道の中で学んだ事について少し記事に書いてみます。
実際に刀で仮標（水に浸けた畳表を巻いたもの）を斬る時に僕が師範からよくに受ける指摘の中に「迷い」や「考える」と言う言葉が出てきます。
実際に肝心な所で二の足を踏んで考えてしまっているので、対象を一刀両断に出来ておらず不完全に斬っている状況になりがちです。
斬っている状況はある程度見えているので迷いが原因で有る事は理解は出来るのですが中々こういったものは治す事が難しい部分でもあります。
まぁ、理解して出来れば苦労はしないですから、この辺りは鍛錬して何とかしていくとして、無駄を省くというのはこういった所から実体験で学んでいます。
物体を斬るというのは多くは論理で片付きます。
要は斬れる様に斬れば良いというだけの事。
物体の繊維に沿ってその繊維が分断出来るように加重がかかりさえすれば両断する事が出来るのですね。
ただ、頭で理解する事と身体で実践する事では大きな違いがあり。
ここに実践による学びが生まれます。
鋭く斬るというのは、その斬る直前から自分が空っぽになっている状態で、後は身体に任せてしまう位の感覚になっていないと僕の場合中々上手くいきません。
空っぽの状態であれば、変に迷ったりせずスパッと斬る事が出来るのでどうにかこの心境を何時でも持てるようにしていくよう鍛錬しています。
感覚としては座禅している状況と変わらないのですが、どうも環境が変わってしまうとその心境を保つ事が出来なくなるようです。
いつも行っている鍛錬は状況に流されないようにするための最小の心境を保てるようにしていくものだったりします。
しかし記事を書いて改めて感じますが、道を実のある言葉にするのは難しいなと感じます。
まだまだ修行しないと全然追いつかないですね。
今回はここまでです。
最後まで読んで頂いてありがとうございました。
無駄を省く その２
その１より
この考え方で流用できるのは、何もシステムだけでは無いと思います。
組織にしたって、動作にしたって無駄なものは無いにこした事はないですよね。
最初はシンプルなものでも、更新や修正を加えるうちに複雑になってしまうのは仕方ないのですが、あまりやりすぎてしまうと更新するだけで時間が大きくかかるものです。
そう言うのをさける為にドキュメントを多く残しはするのですが、途中からそのシステムを運用保守する人にとっては関連するドキュメントを最初から読み進める必要があり引き継ぎに時間を要してしまうケースも少なくありません。
状況によっては３ヶ月くらい勉強しないとまともに仕事に取り付けないという現場もありますので、複雑化しないというのは工数を抑えるという観点からも大切な事ですね。
最初はキレイにやる時間が無いのでまずは、目標を達成するためのシステムが出来上がります。
次に、そのシステムに対して不満点が多くなり、外部の人間が良いものにしようと色々な機能を取り込み始めます。
この時に、意味も無く複雑なモノが出来上がりやすいのですね。
プロトタイプは使う人を選ぶというか制作者の為のシステムである場合が多いので、まずは自分が使える事を前提に作られていきます。
量産機は色々な人が扱えないと不便なので、それが可能になるように色々な制限と機能を持たせます。
MicrosoftOfficeやWindowsなんかが代表格になりますでしょうか。
どちらも成功例ではありますが、バージョンが変わる毎にPCサポートなどをしている人は右往左往したのは良い想いで（？）ですね。
一つのバージョンアップにユーザにどんな影響があるのかそれを一つ一つしらみつぶしに対応するのはあまり現実的では無いと感じます。
大体が人手で何とかするという対応をしているので、何とかなっているのが現状ですが、企業などで扱うシステムはOfficeだけでは無いのでシステムの分だけ対応が必要になるのですね。
これらのシステムをシンプルに構成していれば変更点に対して問題の有る無しは、即答出来るケースだって出てきます。
こういった分かりやすく変化に強いものを作っていくというのがITエンジニアの本来の仕事ですね。
単純に入れるだけでなく、利用し続ける事を考えたものを提供していく場合に無駄を省いておくと問題を絞れるのではないかと思います。
今回はここまでです。
最後まで読んで頂いて有り難うございました。
