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

伊達要一の書棚と雑記

伊達要一の読んだ本の紹介と書評、それと雑記

今月のSoftwareDesign(2015年1月号)

半年以上も雑誌の積み残が残っている状況だったのですが、このまとまった休みを活用して一気に消化してみたいと思います。というわけでこの記事は休み時点で書いておりますが、恐らく仕事でテンパッてまともに更新出来ないタイミング(多分休み明けすぐだと思うorz)で公開となります。
ぶっちゃけ雑誌の種類によっては過去の話題になり過ぎているところはすっ飛ばしたり、自分の興味関心領域外については物凄い勢いでスルーをかますような状態になりますがご容赦をば。


Hosting Department 105 「クラウドファースト」から適材適所のクラウドホスティング

クラウドという技術がバズワードに進化して、そこからクラウドが第一選択肢になる(クラウドファースト)過程を経てようやく「使い分け」というゴールに辿り着いた感がありますね。実際、極端に大きい企業であれば自社LAN内クラウド資源があって、殆ど同じようなことが出来る反面、外のセグメントに欲しい場合にはAWSなんかを使うようになってきました。
これからは「クラウド」というバズワードに依拠してきたようなところはどんどん消えていく一方で寡占的になっていく事業者が果たしてリーズナブルなサービスを継続して提供していくかが気になるところですね。

第1特集 使うほどなじむ「Vim使い」事始め プログラマ・インフラエンジニア・文章書きの心得

冒頭に「Vimは最初の敷居が高いエディタ」ってあるんですけど、まさにそこが最大のネックなんですよね。特にタチが悪いのが、新人にVim(酷いとVi環境)をぶん投げて四苦八苦しているのを眺めてニヤニヤしている年寄りどもですわ。しっかり教えれば物凄く便利に使えるものを苦労させて敬遠させるのはただの嫌がらせですよね。

第1章は「犬でもわかる!?」って表現が個人的には好きじゃないけど、前回のVim特集よりも理論に寄せた記事で新人さん向けで非常によろしいですわ。特にそこそこVimを使ってコードやら文章を書いている私もキーマップの書式やヘルプの使い方なんかはかなり勉強になります。プラグインに関してはもうneobundle.vim一択なところがあって、これに慣れておけばもう十分って感じですかね。
ただ、一点だけ気になるところが。

set nocompatible
" (SoftwareDesign 2015年1月号 p21)

これ、実のところ非推奨の書き方なんですよね。細かい話だけどこっちの方が無難かと。

" unset vi compatible mode (set vim mode)
if &compatible
	set nocompatible
endif

この理由についてはこちらのリンクを参照のことということで。

rbtnn.hateblo.jp


あと、個人的にはWindows環境で使うなら出来ればcygwinに導入するケースもちょっと読んでみたかったところです。自分の環境に導入するときにいつも四苦八苦するので。

第2章のところはソースを弄るときに結構四苦八苦しているのでうまく活用してみたいところですね。特にタグファイルはもっと活用したいんですがなかなかうまくいきません。入力補完は.vimrcを修正するときにも物凄く助かっています。

第3章は昔古いSolarisでViしか無い環境で使っていた身からすると身につまされるといいますか…… ぶっちゃけた話シェルとかをサーバ上で直接編集するとかいう頭が痛くなるような運用をしていたんですよね。今から考えるともうちょい何とかならないのかと思ってしまうわけですが。
末尾にある「Vimの豊富な機能を無理して使いこなそうと考えなくても良いです」の一言は色々と救われますね。Web上のVimmerってもうなんというか凄すぎてついていけないってのが正直なところなので。

第4章については、正直無理やり文章書きでVimを使わなくても…… と思う次第です。Linux環境であれば仕方がないにしても、Windows環境であれば文章書き向けのエディタは大量にあるわけで…… ただ、はてなブログをゴリゴリ使っている身としては、Vimはてなブログ向けの拡張が作れないかなぁと思っていたりします。特に下書きをテキストエディタでゴリゴリ書いている(ってかちょうどこの読書メモも秀丸エディタで書いていたり)身からすると、いちいちはてなブログのコンソールページでコピペするのが非常にめんどっちいんですよね。
……いや、全部英語でやればいいじゃんって突っ込まれると辛いんですけどね。

第2特集 SI崩壊を乗りきる3つの方法 ソフトウェア開発の未来 請負・受託開発は変わるべきか

現状の仕事がどちらかと言えばユーザ部門そのものな感じだったりするので、実のところあまり実感が湧かないところがあるんですが、一応本業はSIerだったりするので他人ごとではないといいますか。

第1章のケースは比較的巧くいっているケースの紹介という位置付けですね。特に準委任契約と請負契約をアジャイルに適合させるやり方としてはケーススタディとして取り上げるべき事例かと思います。価値創造契約はうちのところでも活用出来ないか検討課題にしてみたいところですね。

第2章については現状の要約という位置付けになるかと思います。受注請負型SIビジネスが何故無くならないかという点――ユーザサイドが必要とする理由のところは、思わず吐き気がしてくるほど良く見る光景です。ぶっちゃけた話、ユーザ部門的な振る舞いをせざるを得ない自分も似たような頭の痛い状況に陥って力技(自分で手を動かす一人情シス的動き)で乗り切ったこともあったりなかったり……
正直自分の中ではもっと技術に舵を切りたいところではあるんですけど、如何せんスキルが不足していてそれどころじゃないという事情が辛いところであります。
非常に読むべきところは「設計する力こそすべて」というところですね。実際、事前の設計(これは一括請負方式のシステム構築に限らない)が物事の全てのようなところがあって、ここらへんが疎かになっているケースは大概失敗しています。ってか、そこで酷い目に遭ったことも何度と無くあります。

第3章はユーザ企業の「一人情シス」というあたり、すがちゃんこと菅雄一さんを想起しますね。実態として私自身が(無茶な分量のタスクを丸投げされながら)やっている仕事であって、ここで書かれているようなSIerサイドとユーザサイドとのギャップはよく感じているところであります。
極端な規模の大企業であれば別ですけど、それこそ東証に上場しているような企業でも規模によっては「一人情シス」プラスαでもなんとかなるわけで、それこそヘンなSIerで燻っているくらいなら…… ってのは読んでいて思う次第ですね。
末尾にある「顧問プログラマ」のように規模の小さい企業における顧問弁護士のような形での情シス担当者が増えていくことを望む次第です。

サーバーワークス瑞雲吉兆仕事術 最終回 エンジニアに求められる技術の変化

この連載は過去何度か取り上げましたけど、結構勉強になりました。
今回も非常に参考になる内容で「T字型の知識」――アプリならアプリレイヤだけ、インフラならインフラレイヤだけというわけじゃなくて、広く浅くの部分と深堀してプロフェッショナルとして通用する知識領域というあたりや、「説明能力」のところなんかは物凄く身につまされます。