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