1024

      前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ５章 ソフトウェアのテコを有効に活用する 5章では主にソフトウェアのテコとシェルスクリプトのメリットについて書かれている。 よいプログラマはよいコードを書く。偉大なプログラマはよいコードを借りてくる 自分の仕事に他人の成果を取り込むことで、先人の努力を活かし、コードの有用性を一段と高めることができる。 独自技術症候群を避ける 既存のアプリケーションをゼロから設計し直すことは模倣であっても創造とは言わない。最も成功する会社は、他からソフトウェアを「借用」し、独自拡張を行う会社である。 コードを他社がテコとして使うのを認める ソフトウェアの寿命をコントロールしようとしても、プログラム開発への投資を一時的に保護することができるだけで、ソフトウェアそのものを保護することはできない。 すべてを自動化する コンピュータにできることを人間が手作業で行うのは時間の無駄。 シェルスクリプトのメリット テコの効果と移植性を高めるシェルスクリプトには何十ページ、数百コマンドラインに渡り、そこから呼ばれる各コマンドの背後にあるC言語のコードはものすごい量となる。これこそがテコの効果である。 時間が節約になる コンパイル段階を省略できるので、開発作業に集中できる。 Cより移植性が高い あるUNIXシステムで動作するスクリプトはほとんど修正なしで動作する。コンパイルはもちろん、どのような実行のための変換も不要。 C言語で書き直すという誘惑に負けない シェルスクリプトを次の年のマシンで使えば、もっと速く実行できるようになる。非常に移植性が高いのが普通だから、次の年のマシンに移植するのに特別な作業はほとんど何もない。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、６章へつづく。

    前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 ４章 ソフトウェアが短命で終わるか否かは移植性を重視して作れるかどうかにかかっている ４章では効率より移植性が重要であり、例え効率を求めたとしてもそれは間もなく新しく来るスペックのものが来た時に残念ながらその努力はあまり意味を成さないものとなってしまうことがAtariの例も挙げられながら書かれている。 これはデータでも同様のことが言える。 取り巻く環境が変化することを前提にソフトウェアを書いていくこと。 その為繰り返し呼ばれている様な箇所以外で最適化にリソースを割き過ぎると環境が変化した時に対応することが困難になる。 その為にもまずは移植性を重視する必要がある。 環境が変化して、新しいハードウェアが登場しそこに移植さえ上手く出来れば前の世代のハードウェアで懸命に最適化して得られた効果よりももっと大きな効果を得られる。 昨今、もはやデファクトになり移植性の為にも無くてはならない存在になっているDocker。 従来以上に開発からサービスのリリースまでのスピーディーさが求められてる世の中になっている様にも感じるし、その為の環境もかつてよりかなり整備されてきている。 こういった環境の中で、効率性を上げるというよりかは、移植性を上げる方が将来的な環境の変化のことを考えると喫緊の課題と言える。 そもそも効率化や最適化を余りにも重視したところで、環境が変わって動かなくなれば元も子もないのだから。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、５章へつづく。

  前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 3章 最初から上手くやろうとするより、最初は上手く行かないことを前提に考える ３章では最初の仕様に変更が無いことは稀で、状況に応じて仕様の変更を加えていかないといけないこと、そしてその為には早めの試作を行い、リスクを軽減する必要性について書かれている。 第一のシステムから第三のシステムというものまで存在するが、第三のシステムの様な機能と性能が最適化されたエレガントなシステムを最初から作れる訳ではない。 第一、第二、第三と順に過程を経ることで到達するものであり、第三のシステムから見れば第一のシステムやましてや第二のシステムは劣る様にも感じられるが、それは後から見れば結果そうなのであって、その時その時ではその各々のシステムが求められている。 章の最初の方にも書かれていたが、ソフトウェア技術者を始めとした常にスキルのアップデートが必要な職業の人々はソフトウェアと同じで、最初から完璧に出来る訳ではない。 長い時間をかけてスキルを洗練させていくものであって、試行錯誤を行いながら学び続ける必要がある。 このことは様々な学習や他のスキル習得にも当てはまるなと。自身も最初から全てを完璧に習得しようとして途中で躓いた経験が何度あったことか。そもそも完璧に習得なんて考え自体が傲慢だし、あり得ないことなのだが。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、４章へつづく。

Mike Gancarz著の2001年発売のかなり有名で既に読まれた方も多い著書だとは思うのだけれど、今も通じる大切なことが多く書かれていると思うので、自分なりに書評をツラツラと書いていければと思います。 これからもし読まれる方の参考になれば幸いです。 １章 UNIXの考え方におけるそれぞれの定理はシンプルで一見簡単に見える １章ではこれから述べられるUNIXの考え方の定理が簡単にまとめてあり、その中でも１〜３の内容は他でもよく言われていることだが、意外といざ実践となると分かってはいても難しいことに気づく。 特に１の「スモール・イズ・ビューティフル」と２の「一つのプログラムには一つのことをうまくやらせる」を意識するかどうかでも実装が変わってくると思うので、常に頭の片隅に置いておきつつプログラムを書いていきたいし、その為の定石も自分の中に蓄積していきたい。 そう言えば高校の時に数学の先生がいつも「Simple is the best!」って言っていたのをふと思い出しました。 後、UNIXの成り立ちをみていてやはり基礎研究の厚みって重要だなと。基礎研究の中から企業がプロダクトにして世の中に価値提供が行われる好循環があってこそUNIXシステムやその他のオペレーティングシステムが発展してきたと思うので。 ２章 とにかく小さいプログラムは素晴らしい ２章ではシンプルで小さいプラグラムの素晴らしさについて書かれている。近年柔軟性を兼ね備えたマイクロサービスアーキテクチャの様な手法が新しいものの様に取り上げられているが、実はUNIXの黎明期からそういう手法というのは存在していて、基本は変わってないのだなと。 逆に言うと近年になってもマイクロサービスアーキテクチャが取り上げられるということは裏を返せば、各々分かってはいるものの中々実際には多くの困難が伴うことを表していて、新しいサービスであればまだしも既存のサービスを変えていくことはそれだけ難しく、それは世界中の多くのサービスが抱えている問題でもあるのかなと。 それから ls コマンドがここではUNIXの理想から離れた例としてあげられていたのだが、普段全くそんなこと考えもしなかったので、UNIX力まだまだだなぁと感じました。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、３章へつづく。

 はじめに 前回の「 Terraformのど基本 - その３ 」ではTerraformでAWSのリソースを扱っていく為の準備として、TerraformのインストールとIAMそしてAWS CLIの設定までを行った。 今回はいよいよになるが、Terraformを使って実際にAWSのリソースを操作する簡単なデモを行ってTerraformのど基本シリーズを締め括りたいと思う。 本来であればEC2やVPCやS3と言ったリソースやAWSといったサービス毎にファイルを分割して管理・構築する方が実践ではオススメではあるがここでは内容理解に重点を置きたいので main.tf という一つのファイルにまとめて進めていく。 今回構築する内容としては非常にシンプルなものではあるが、AWS Profileの情報を利用してEC2インスタンスを立ち上げるというのを行っていきたいと思う。 前準備 まずは再度の確認にはなるが前回行ったIAMユーザアクセス権があることを確認したい。 aws sts get-caller-identity のレスポンスが返却されればOKだが、もしここでレスポンスが返却されていない様であれば、前回の「 Terraformのど基本 - その３ 」のAWS CLIの設定の項目で復習して欲しい。 名前は何でも良いのだが、任意のディレクトリを作成しその中にここでは main.tf という名前のファイル名を作成しておこう。 例: test/main.tf main.tf では早速main.tfを記述していく。細かい箇所に関しては後ほど解説する予定なので一先ず下記の通り記述をお願いしたい。 それではブロック毎に内容の記述内容の解説を行っていく。 variable ここで理解して頂きたいことは default と type である。これはその名の通り変数のデフォルト値であったり型宣言の部分となる。 variable 内の様々な記法に関してはこちらの ドキュメント を参照 terraform 次に来るブロックが terraform と書かれたブロックである。ここには必要とするモジュール名であったりバージョン情報などを記述する。 terraform 内の様々な記法に関してはこちらの ドキュメント を参照 provider そして次に来るブロックが provider のブロックとなる。...

 はじめに 前回の「 Terraformのど基本 - その２ 」ではTerraformを使用していくにあたってのよく使う基本のコマンドそしてそのコマンドを利用した大きな流れを確認した。 今回は早速Terraformを使ってサンプルでデモと行きたい所だが、まずはその為の下準備をここで行っておきたい。 ちなみにここではAWSを使用してサンプルを作成していく予定である。 準備 まずは何はともあれTerraformのインストールから行っていく。 続いてはAWS CLIを使える状態にしていく。ここで簡単にAWS CLIについて説明しておきたい。 AWS CLIとは？ 一言で言い表すとコマンドでAWSの各サービスを扱う為のツール群である。AWS CLIを用いることによって、GUI上から操作していたものをコマンドに置き換えることが可能となるので、IaC化, DevOpsの流れとも相まってよく使われる様になっている。 AWS CLIのインストール それではAWS CLIをインストールしていく。AWS CLIにはバージョンが１と２とが存在するが、基本的にはバージョン２をインストールすればOK。 AWS公式のダウンロードページ より最新のパッケージのダウンロードを行い、インストーラーを起動しAWS CLIをダウンロードしていこう。リンクはmacOSのものだが、同ページには他のOSに関しても記載があるので都度参照されればと思う。 インストールが完了したら次はインストールの検証を行い、AWS CLIが意図通りインストールされているか、パスとバージョンを確認していく。下記の様なパスとバージョンが表示されればインストールは完了となる。 IAMユーザーの作成 既にAWSが使用出来ている時点でrootユーザーのアカウントは作成されているかと思うが、実運用ではrootユーザーを使用するのはベストプラクティスではない為、新規でIAMユーザーを作成してAWSのリソースを扱っていく。 それでは早速新規でIAMユーザーを作成していこう。特に迷う点は無いと思われるが、ユーザー名を入力した後はアクセスの種類を選択する際に プログラムによるアクセス と AWSマネジメントコンソ...