Hatena::ブログ(Diary)

T-hi6shiの日記 このページをアンテナに追加 RSSフィード Twitter

2013-02-18

一つ一つを上手くやる その1

| 01:17 | 一つ一つを上手くやる その1を含むブックマーク 一つ一つを上手くやる その1のブックマークコメント

前回からの続きになります。

前回は無駄を省く事についてピックアップしていましたが、それだけではまだまだ利用し易いシステムにはなりません。

無駄が無いだけで局所的な環境でしか動かないとしたら、次はどこにでも移植出来るようなシステムでないと不便です。

ある一つの物事に対してスペシャリストであるのは良いのですが、他の場所では全く使えないというものだと、また1から作り直しになってしまいます。

それに比べて、移植性のあるものはシステムは使い回しが効くので、同じような仕事に対しても直に対応できます。

多くのシステム開発者は後者の方を出来るだけ目指してシステムを作り上げているのですが、どうもパッケージ化したあたりから雲行きが怪しくなる事が多いです。

特定のパッケージソフト(社内向けとか)は始めからどんな環境でも使えるように移植性を考えて作られているのであれば良いのですが、ものによっては社内で作ったシステムの資産を売ったら一儲け出来るのではという考えから販売されているものも中にはあります。

僕が9回の転職をしてきた限り、社内のルールが標準的だった現場というのはみた覚えがありません。

人と一緒で、会社毎に個性というのはしっかりあります。

これを自覚せずに自分たちが勝手に標準だと感じているものをみんな使えば便利だよねとおもい売り込んでくる人達の口車にのってパッケージを購入すると、その後には結構悲惨な結末になる時がありました。


こういった、一つ一つの違いにを吸収するための一つの手段としては一つのシステムをパーツ毎に明確に分離しておいて組み立て易い状況にしておくというのは一つの手段なのですが、これをやるには一つのモジュールを無駄なくコンパクトにしておいて、後で流用しやすい形にしておく事が大切になります。

そうすると、いざ必要になった時にわざわざ最初から作る必要がなく、無駄なくシステムを構築していく事が出来ます。

これは例え小さな仕事でも後でも流用出来るようにしておくと格段に仕事のスピードがあがります。

インフラをやっているとこれを実感出来るのはシェルスクリプトですね。

次回は一例としてシェルについて触れたいと思います。

今回はここまでです。

最後まで読んで頂いて有り難うございました。

2013-02-17

鋭く斬る

| 11:00 | 鋭く斬るを含むブックマーク 鋭く斬るのブックマークコメント

斬る心-刀

Unix哲学の話は20:00にアップしますが、今書いている「無駄を省く」という事について居合道の中で学んだ事について少し記事に書いてみます。

実際に刀で仮標(水に浸けた畳表を巻いたもの)を斬る時に僕が師範からよくに受ける指摘の中に「迷い」や「考える」と言う言葉が出てきます。

実際に肝心な所で二の足を踏んで考えてしまっているので、対象を一刀両断に出来ておらず不完全に斬っている状況になりがちです。

斬っている状況はある程度見えているので迷いが原因で有る事は理解は出来るのですが中々こういったものは治す事が難しい部分でもあります。

まぁ、理解して出来れば苦労はしないですから、この辺りは鍛錬して何とかしていくとして、無駄を省くというのはこういった所から実体験で学んでいます。

物体を斬るというのは多くは論理で片付きます。

要は斬れる様に斬れば良いというだけの事。

物体の繊維に沿ってその繊維が分断出来るように加重がかかりさえすれば両断する事が出来るのですね。

ただ、頭で理解する事と身体で実践する事では大きな違いがあり。

ここに実践による学びが生まれます。

鋭く斬るというのは、その斬る直前から自分が空っぽになっている状態で、後は身体に任せてしまう位の感覚になっていないと僕の場合中々上手くいきません。

空っぽの状態であれば、変に迷ったりせずスパッと斬る事が出来るのでどうにかこの心境を何時でも持てるようにしていくよう鍛錬しています。

感覚としては座禅している状況と変わらないのですが、どうも環境が変わってしまうとその心境を保つ事が出来なくなるようです。

いつも行っている鍛錬は状況に流されないようにするための最小の心境を保てるようにしていくものだったりします。

しかし記事を書いて改めて感じますが、道を実のある言葉にするのは難しいなと感じます。

まだまだ修行しないと全然追いつかないですね。

今回はここまでです。

最後まで読んで頂いてありがとうございました。

無駄を省く その3

| 20:00 | 無駄を省く その3を含むブックマーク 無駄を省く その3のブックマークコメント

斬る心-CLI

その1

その2より

実際に無駄を省くにはどうすれば良いかといえば、ボトムアップで構築していく方法が一番手っ取り早いと思います。

必要になったら作る。

その作ったものは常に流用出来るように作る。

必要になればその流用したものを使う。

こういう事をコツコツ積み上げていけば無駄の無いものを作る土台が出来てきます。

更に欲を言えば、この作ろうとしたものに対して既に作っている人間がいないかを確認すると作る行程すら無しに必要なモノが手に入ります。

rubyであればgem

perlであればcpan

pythonであればPyPi

など、この辺りを調べてみたりgithubでソースを見つけてくるなどをする事で一から作る手間を軽減する事も出来ます。

まぁ、この辺りのコードを流用するにあたり色々と気にしないと行けない事というのはありますが、ソースコードというのはネット上に公開されているものが有るという事を知っておくだけでも、web系の開発の仕事とする時に有利に働く事が有ります。

後は、其々が動くインフラを構築してしまえば良いので、提供したいインフラの設計決めれば、ある程度の規模までなら開発出来る準備は整っている状況だと思います。

社内インフラだと、javaでないとダメとかあるのでそういった開発言語や環境に縛りがある場合は諦めるしかありませんが、そもそも今後そういった案件を受けるのはあまり得策では無いと感じますので、技術の知らない人間の一般的とか標準という言葉を鵜呑みにせずに、本当にこれから活きる言語を学んでいけば、作り手として職を心配する必要は無いのではと感じます。

職業でエンジニアをやる場合は、僕の方法は難しいかもしれません。

ただ、職人としてエンジニアの道を進んでいくなら、本当に活きた言語や環境に手を染める事をオススメします。

それだけでも、普通の人と差をつける事ができます。

今回はここまでです。

最後まで読んで頂いて有り難うございました。

2013-02-16

無駄を省く その2

| 20:00 | 無駄を省く その2を含むブックマーク 無駄を省く その2のブックマークコメント

斬る心-CLI

その1より

この考え方で流用できるのは、何もシステムだけでは無いと思います。

組織にしたって、動作にしたって無駄なものは無いにこした事はないですよね。

最初はシンプルなものでも、更新や修正を加えるうちに複雑になってしまうのは仕方ないのですが、あまりやりすぎてしまうと更新するだけで時間が大きくかかるものです。

そう言うのをさける為にドキュメントを多く残しはするのですが、途中からそのシステムを運用保守する人にとっては関連するドキュメントを最初から読み進める必要があり引き継ぎに時間を要してしまうケースも少なくありません。

状況によっては3ヶ月くらい勉強しないとまともに仕事に取り付けないという現場もありますので、複雑化しないというのは工数を抑えるという観点からも大切な事ですね。

最初はキレイにやる時間が無いのでまずは、目標を達成するためのシステムが出来上がります。

次に、そのシステムに対して不満点が多くなり、外部の人間が良いものにしようと色々な機能を取り込み始めます。

この時に、意味も無く複雑なモノが出来上がりやすいのですね。

プロトタイプは使う人を選ぶというか制作者の為のシステムである場合が多いので、まずは自分が使える事を前提に作られていきます。

量産機は色々な人が扱えないと不便なので、それが可能になるように色々な制限と機能を持たせます。

MicrosoftOfficeやWindowsなんかが代表格になりますでしょうか。

どちらも成功例ではありますが、バージョンが変わる毎にPCサポートなどをしている人は右往左往したのは良い想いで(?)ですね。

一つのバージョンアップにユーザにどんな影響があるのかそれを一つ一つしらみつぶしに対応するのはあまり現実的では無いと感じます。

大体が人手で何とかするという対応をしているので、何とかなっているのが現状ですが、企業などで扱うシステムはOfficeだけでは無いのでシステムの分だけ対応が必要になるのですね。

これらのシステムをシンプルに構成していれば変更点に対して問題の有る無しは、即答出来るケースだって出てきます。

こういった分かりやすく変化に強いものを作っていくというのがITエンジニアの本来の仕事ですね。

単純に入れるだけでなく、利用し続ける事を考えたものを提供していく場合に無駄を省いておくと問題を絞れるのではないかと思います。

今回はここまでです。

最後まで読んで頂いて有り難うございました。

2013-02-15

無駄を省く その1

| 20:00 | 無駄を省く その1を含むブックマーク 無駄を省く その1のブックマークコメント

$斬る心-CLI

前回の「技術に振り回されない為に」

その1

その2

その3

その4

より続きます。

今回から、以前上げた9つ其々のテーマに関連した話を少しずつ記事にしていきます。

Unix哲学

 1.小さいものは美しい。

 2.各プログラムが一つのことをうまくやるようにせよ。

 3.できる限り原型(プロトタイプ)を作れ。

 4.効率よりも移植しやすさを選べ。

 5.単純なテキストファイルにデータを格納せよ。

 6.ソフトウェアの効率をきみの優位さとして利用せよ。

 7.効率と移植性を高めるためにシェルスクリプトを利用せよ。

 8.束縛するインターフェースは作るな。

 9.全てのプログラムフィルタとして振る舞うようにせよ。

まずその1「小さいものは美しい」という考え方について

この考え方自体はそれほど難しいものではないとおもいます。

「無駄を省き必要な事だけをやる」という事に集中しましょうという事です。

どういったものかといえば、必要となるのは副作用に期待せずに何が起っているか分かり易く見通しのよいものを作れということです。

規模の大きなものを作ろうとするのではなく、小さなパーツ達を丁寧に作っていくという事です。

昔のアメ車ビートルを引き合いに本書では取りあげられていますね。

その例で考えるよりも、日本であれば茶道や武道などの道のものイメージした方が分かりやすいかもしれません。

この考え方自体は僕はとても日本人的だと思うのですが、どうも大きな問題や目標が提示されてしまうとどうも頭の中から吹っ飛んでしまい。

大きく無駄の多い問題解決方法をとる道を選んでしまう人達は多いように感じます。

本来は一つ一つ確実にやる事に集中すれば良いので、問題に対して対処方法はそんなに変わらないのですね。

システムの話でも、手法はいくつかありますが本当にとれる対応策は多くないと思います。

また、複雑に問題を解決してしまうと後で修正が大変になるので、パッチをあてる度に変更点やデバックが大変になってきますので、DRYやKISSの原則は護って作る方がシステムの改修は行い易く出来ます。

あくまで状況に応じてにはなってしまいますけどね。

ちなみにDRYは

「Don't Repeat Yourself:繰り返しを避けること」

でKISSは

「Keep it simple, stupid:(シンプルにしておけ!この間抜け)」

もしくは

「Keep it short and simple(簡潔に単純にしておけ)」

の略となります。

KISSの原則は個人的にKeep it simple, stupidくらいの感覚で良いと思います。

これを護っていれば、保守しやすいコードが作れるようになっていくと思います。

今回はここまでです。

最後まで読んで頂いて有り難うございました。

UNIXという考え方―その設計思想と哲学/オーム社

¥1,680

Amazon.co.jp

2013-02-14

技術に振り回されない為に その4

| 20:00 | 技術に振り回されない為に その4を含むブックマーク 技術に振り回されない為に その4のブックマークコメント

斬る心-CLI

その1

その2

その3

より続きます。


実際にこういった哲学を利用しながらシステムを考えていく事で指針を立てる事が出来ますので、その現場の設計がどういった所に問題があるか逆算する事が出来るようになります。

方向性さえ押さえていけば、道に外れても修正はしやすいですからね。

こういった方向性を持たずに漫然と仕事をしていると、いつの間にか周囲の環境に振り回されていつの間にか望まない結果を押し付けられてしまう、という状況に追いやられるケースも有ります。

むやみやたらにピチクパーチク喚き散らすのも問題ですが、状況に流されるままというのも宜しくないですよね。

その為に、確度の高い情報をもっておくのは手だと思います。

始めは自分のもので無いので、中々なじまないかもしれませんが、しっかりとしたポリシーを持って物事に望めるようになると状況に流されにくくなったり、更には状況を創りだす事もできるようになります。

人と話す時にも、しっかりと芯をもって学んでいると複数の視点で突っ込まれても合気道の達人のように全て往なす事が出来るようになるのをイメージしてもらえると、どんな状況か分かりやすいでしょうか?

その為には、地味ではありますが基礎鍛錬が必要になります。

先人の考えを学び実際にどうやって今の環境が出来上がったか理解を深める事によって、世の中のキャッチーな技術に踊らされる事無く本当に必要なものだけをクライアントに提供する。

そんなエンジニアになる事も出来ますので、昔から現在まで残っている技術や考え方については自分の血肉に出来るだけする事は必要です。

Unix哲学だけでなく他にも多くの先人達の知恵はあるので、自身で色々と調べて身にあった考え方を取り入れるようにしていく事は追々プラスに働くと思います。

では、次回からは、「小さいものは美しい」を議題に記事にさせて頂きます。

今回はここまでです。

最後まで読んで頂いて有り難うございました。