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

何か着ていればいいよ

ソフトウェア技術者の日常や技術の話を書こうと思います。

Soft Skills の日本語訳本が出ていた!

キャリア 技術書 プログラマー

僕は昨年、@higeponさんのこの記事

d.hatena.ne.jp

から惹かれて英語版を半年かけて読んだわけですが
やはりその間に翻訳が進んでいたんですねー。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

いやー。いい本なんだけどアメリカ固有の話題も多かったので日本語版ではどうなっているのか気になるし。
どうやらMatzが解説書いてるっていうんで気になる。 でも、日本語版かったら負けな気がするけど、早くも負けそう。 Kindle版が出たらたぶん買います。

PHP BLT #4 に参加しました

PHP 勉強会

今回、まとめブログ枠で参加したこともあり、のエントリーです。

参加理由

正直、PHPの勉強会は今回が初めて。
JavaRubyEcmaScriptのコミュニティと同じなのか違うのか、一週間前くらいからワクワクしていました。

発表内容

PHP fukuokaの紹介

speakerdeck.com

ITSの話から入って急展開
ITSのツアー申し込みのPDFまで自動化 => 今後、Fax送信まで自動化したい

BLT

speakerdeck.com

最初何も喋らないので、何事かと思ったらPHPBLTのLine.botで始まりの挨拶から。 んで、詳しいところはよくわからないけどLineBot用のオレオレフレームワークを、某@uzullaさんに影響されて作ったとのこと。
本当に作るところが凄いですね。

wikiについての今昔物語

speakerdeck.com

Wikiは凄いね(例:PukiWiki, MediaWiki)。でも、wiki記法やデザインが残念。
そこで、ババーンと作ったよ!というお話。URIの話とか確かにwikiって先進的だったんだなと思えました。

僕とPHPの4年間

speakerdeck.com

初LTとのことでしたが、そうは思えない安定感で良い話を聞けました。
まとめると、4年に一度オリンピックイヤーに動くWebアプリを若かりし頃に作ったが、今度二度目の稼働日が来たよ。
そして、諸々アップグレードしたら過去の自分からの成長が感じられたという話。
なんだろう、自分の社会人1年目とか4年目とか思い出すと何が違うんだろう?というくらい違う。凄い。

実践DIコンテナ on Laravel

speakerdeck.com

正直、Java界出身でPHP歴半年ほどの自分が一番親近感を感じたのがこの話です。 DIの便利さや使い所はJavaとほとんど同じですね。*1

PSR-7 middle ware

ミドルウェアを自作する話
ちょっと、このエントリーを書いている段階では資料がない状況。 なかなか熱い話で、Javaだとサーブレットコンテナが担う役割の部分な気がしました。
告知: yapcっぽいカンファレンスをやる7.2/3

PHPカンファレンス北海道2016

speakerdeck.com

↑に行ってきた話。
全国PHPカンファレンス スタンプラリーとか楽しそう!

ソーシャルゲームの高負荷とかじゃない地味話。

資料が見当たらず
観葉植物を枯らすところから入る、順調な立ち上がり、からバッチの話へ。
PHPのバッチは自社も多いけど、正直他でもやっているとは意外でした。

PHPカンファレンス北海道に行ってきた

資料が見当たらず
前の方とかぶった・・・。ように見えて結構違う北海道話。

オンプレミスJenkinsを葬り去った

speakerdeck.com

去年、オンプレミスのJenkins社内に立てたばっかりなんで、「え?」ってなったけど・・・。
内容としてはJenkinsおじさんの老害化の話でした。

憂鬱なSQLのためのあれ

niconare.nicovideo.jp

PHPカンファレンス北海道でcomposerの話しした方
みんなPDO大好き、からの超展開でした。

STREAMで遊ぶ

speakerdeck.com

普段はcomposerの遅さと戦っているとのこと。
PHPのStreamってURIのスキームと密接絡んでいるようで、CやJavaのStreamとは結構概念が違うように思えました。
それ以外は、柔軟な言語はこんなこともできるだという新選感あり。

サービスが成長すると

  • PHPrails ちょっと、ビール飲みすぎでトイレ行ってました。すいません あまり聞けなかった。

Word物語

資料見あたらず
福岡から来ました、真面目な方のPHPERさん
VAddyのマネージャーさん

  • レポート用Wordを自動生成
    • PHPword

まとめ

PHPの勉強会は初めてだったけど、ノリが結構javajaな感じでビビった。
年齢層は結構高め、なんとかんPHPコミュニティはC++Javaが辿った道を進んでいるような印象 です。*2 ただ、居心地は良かったのでまた参加したいですね。
あわよくば、LT側の人間として。

*1:そういえばPHP界隈ではAOPとかないのかな?LLはそこは勝手に動的にコード書き換えろよという思想なのだろうか?

*2:良いも悪いも関係なく、なんとなく似てる印象ってだけ

Meguro.es #3に参加しました。

JavaScript 勉強会

こちらの勉強会に参加してきました。
第三回ですが、自分は二回目の参加です。

meguroes.connpass.com

会社から徒歩で目黒駅近辺なら行けるということが分かったのが最初の収穫ですね。
開始時間ギリギリになってしまいましたが、ドリコムさんの綺麗なミーティングスペースはとてもいい雰囲気でした。

なぜ勉強会に参加したのか。

普段、Webアプリケーションを作っている(部署にいる)ソフトウェアエンジニアなのですが、比較的周りのJavaScript熱が低いという印象。
ここは差別化のためにもJavaScript界隈の技術を取り入れて強みにできたら良いなという思いで参加しました。
あと、第一回の時に参加したのですが、いい感じのゆるさが気に入ったのもあります。

参加しての感想

勉強会の中身については、割愛。
思ったことをつらつらと。

jQuery辛い

完全にjQueryオワコンになってしまっていて、過去の功績は認められつつも技術的負債の責任を押し付けられたかのようにDisの対象になっている。
というのは前回もうっすら感じたのですが、はっきりしてきたと思います。
自分自身、量は多くないもののjQueryの恩恵にはあずかっており悪いフレームワークとは思いませんが、技術の進歩により相対的にデメリットが表面化してきている点については流れの速さを感じてしまいます。

Reactのデファクト

「Reactはみんなやっているから詳しい説明は省くね」みたいな話が随所にあり、React触ってもいないマンの自分は「え?Reactっていつの間にそんな存在になったんだろう?」というところ。
確かに、AngularとかBackboneとかに比べて目にする機会は多かったかも。
自分のように、情報感度が低い人間はこういう勉強会で人の話を聞いて初めてわかることも多いんだな。

サーバーサイドはRails

特に何も言わなきゃRailsっしょという雰囲気もひしひしと感じて、そういうコンテキストの人たちが集まりやすい勉強会だったんだけど、やっぱりな感あり。

うーん、並べるとここ最近の勉強会では同じような感想を抱いているようなきがする・・・。 今週はPHPの勉強会にも参加するので、文化の違いとか感じられたら楽しいかも。

遅読の自分を許すこと

ポエム 技術書

すべての元凶はこの本

Soft Skills: The Software Developer's Life Manual

Soft Skills: The Software Developer's Life Manual

最初の一章を読んだ段階で、これは凄い本だと。何があっても読み切ってやると心に誓ったのが事の発端でした。
さして、得意でもないのに洋書をこれだけ熱いパッションで読むことになった経緯と自己肯定をちょっと書き残しておきます。

きっかけは@higeponさんのこの記事

d.hatena.ne.jp

そこまで、絶賛なら読んでみようと軽い気持ちでkindle版を購入した行為が、この半年の自分の時間の使い方を左右するとは思いもしませんでした。

そんな"Soft Skills"の読書もかれこれ、去年の10月半ばから半年かけて読んでいていよいよ本文は読み終わり、付録も最終章にさしかかりました。
いやー長かった。
朝晩の通勤時間と昼休みと休日の隙間時間をかなりの割合で読書に割いてるつもりだけど、それで半年なので計り知れない。

じつはこの本を読んで2,3カ月で半分いくかどうかの時に自分の読む遅さにいい加減嫌気がさしていたんですね。
「俺はこの本にどれだけ人生の貴重な時間を費やしているんだ?」とか、技術ブログや技術書を紹介している記事を読んだりして
「この人若いのにこんなに本読んでるよ!それに比べて俺何なの?」みたいな焦りというか自分が読んでいる本そのものではない本質的ではないところでのよく分からないモチベーション低下に悩まされていたわけです。

でも、読んでよかったなと肯定的に今は思っています。
もちろん内容が良い本だったからという部分もありますが、比較的平易な英語で書かれているとはいえ技術者向けの洋書を読み切るというのは自分にとって初めてでとても自信になりました。
確かに、日本語の簡単な技術書を選べばこの期間で4,5冊読めたかもしれません*1
正直、アウトプットもおろそかになっていました。*2

でも、読んでよかった。読み切った。(まだ数ページのこってるけど)
時期も中途半端だけど、そんなことは関係ありません。というあふれんばかりのポジティブシンキンッでとりあえず終わっておこうと思います。*3

*1:それでも、読んでる人から比べれば少ないかな?

*2:この本にアウトプットすべしって書いてあるにもかかわらず

*3:この辺も本の影響

データベース設計時の正規化について忘れがちだけど大事なこと

ポエム 開発

これはDB設計ポエムです。
以下読むならポエムと割り切って斜め読み推奨です。

自分はこれまでDB設計を多少は経験してきました。
他人の設計を引き継いで追加設計:8割 新規に自分で設計:2割 というような割合で。

他人の設計にはほれぼれするようなものもあったけど、ほとんどは
「このクソ塊をどうしろというのだ…。」と嘆きながら引き継ぐという事態に陥っていました。
多分自分のDB設計を引き継いだ人も僕の設計を"f**k!"とか罵っていることでしょう。*1

で、そんなアンチパターンにまみれた仕事をこなす中で、これは気をつけたほうが良いなと気付いたこと。
よくあるDB設計に関する問題というか事前に共有しておくとよい前提を幾つか。

正規化はしろ!

最低限、第三正規形になっている必要がある。これは絶対!
ここが崩れていることも多いので本当に萎えるのだけどここは本当に出発点にしてボーダーラインだと思いますよマジで。

正規化崩しするなら理由・目的を必ず残す

ボイスコッド正規形から第三正規形へとパフォーマンス要件などのために正規化崩しすること*2とか稀によくあると思います。
でも、それには必ず厳密な正規化をしていない理由・目的の文書化とセットで残す。これも絶対!
でないと、DBのバージョンアップや他テーブルの変更で意味なくなった正規化崩しとかが無駄に残ります*3
元々は色々理由があって、妥当なバランスだったものが「それって単に設計がクソなだけですよね」って感じに負債化してしまったりします。

正規化崩しするならKVSの利用を検討する

だいたい今の時代、正規化を崩してまでパフォーマンス要件をあげようとという場合、KVSを利用したほうがよほど効果が高い場合がある。

経緯をどうやって残すか?

DB定義書が良いと思います。
もっと具体的に言うとDB定義書の各テーブルの定義を書く所に"備考"的な欄を用意してそこに書く。
そうすれば、設計変更する際には必ず編集するし目にとまるはず。

というのをふと思い出したので書いてみました。
なんというか、同じ地雷を踏まないための覚書みたいなポエムでした。(おわり)

*1:歴史的経緯や諸々の都合。フリーハンドで設計できるわけでもなく、決して褒められた設計をしていない自覚はありました。

*2:具体例どうよ?って言われると自分が設計の主導している限りは正規化崩さないほうに倒すのがほとんどなので思い浮かばないけど…。

*3:このパターンでかなり困った。前任者がいないと本当にロストテクノロジーブラックボックス負債となってやってられない

購入する技術書を電子書籍のみにしてみた結果

技術書 ポエム

技術書

紙と電子書籍の使い分けについて雑文を書いてみようと思います。

経緯

我々ソフトウェアエンジニアは常に勉強し続けなければ時代に取り残されてしまう哀れな生き物です。
なので、片時も技術書が手放せません。
しかし、良書と世に言われている技術書の中には分厚いものも多く、率直に言って保管するにも場所は取るし、混雑する電車内では読むのも憚られるし、で物理的に扱いやすいものではありません。
そこで、電子書籍なのですがここ数年Kindleの最初版をアメリカのAmazon.comより取り寄せて以来徐々にkindle版を購入する比率を高めていました。
そういうこともあり特に昨年は購入する技術書をほぼ全て電子書籍化するという試みを実行してみました。
その、結果を以下にまとめてみます。

要約した結論

最初に結論を言ってしまえば

  • 良いことばかりじゃないけど、悪いことばかりでもない

という当たり前過ぎて無意味な結論で、メリット、デメリットも目新しくもないよく言われていることの再確認になりました。 ただ、電子書籍で買ったほうが良いものと私の用途や現時点での有り様として電子書籍にそぐわないものとが何となくわかってきたのでそこれについてもまとめておきます。

便利な点

  • 保管や持ち運びの物理的な制約から解き放たれる。
  • 複数kindleでひとつの本を読み進められる
  • 購入がワンクリックでほぼ即時読み始められ、購入に関する時間・場所の制約がない

不便な点

  • kindleのせいか、その使い方の問題か内容を俯瞰的に見づらい
    • 紙のパラパラざっと読み感に勝てない
  • 簡単に購入でき過ぎるため不必要な本まで買ってしまう*1
  • pdfのうちkindleで読めないものがある*2
  • 電子書籍として発売されていないと読めない

そして、上記から導かれる電子書籍に合う技術書と合わない技術書は?

電子書籍に合う技術書

  • 英語の技術書
    • 理由:読みながら知らない単語をクリックして意味を辞書で引けるので
  • 分厚い技術書
    • 理由:重くて持ち運びづらい技術書も出先で読める!こんなに嬉しいことはない!

電子書籍に合わない技術書

  • 入門書
    • 理由:自分の使い方の問題かもしれないけど、入門書はその技術をどうすれ使いはじめられるかをザーッと流し読んで理解するために読むものなのだけど、そのパラパラかいつまんで読むっていうのがやりづらい。
  • 逆引きっぽいリファレンス系
    • 理由:検索はできるけど、それだったらWebで検索すりゃいいし、リファレンス自体書籍で持ってる意味ないのかも…。*3

というわけで、昨年読んだ技術書のうち特に(紙ではなく)電子書籍で読めてよかったと思えたのは以下の二つです。

物理では重い本

システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

辞書ひきながら読みたかった本

Soft Skills: The Software Developer's Life Manual

Soft Skills: The Software Developer's Life Manual

*4
でも、ぶっちゃけ最強なのは電子書籍と紙の本両方買うのが一番だと思いますよ!

*1:これは単に電子書籍のというより自分の購入プロセスの問題な気がしますが・・・。

*2:日本語が表示できない和文フォントでできているやつ

*3:でも、特定のバージョンのリファレンスとしてまとまったものが公開されていない技術とかその書籍のまとめ方の方がWeb公開されているリファレンスよりわかり易いとか存在意義はあると思うんだけど…。

*4:Amazonkindle版を買えなかったので、manningのonline storeで買いました。

2015年に読んだ本まとめ

キャリア 学習 技術書

2015年に読んだ本を読書メモから簡単にまとめておきます。

まず、ベストの一冊を先に記載し、 そのあとに読んだ本リストという形にしておきます。

最高の一冊

How Google Works

How Google Works

これを技術書と分類して良いのかな?ってところもありますが、
自分にとって技術者として進む道をある意味決定付けた一冊です。
この本に書いてある自分にとって共感できるやりたいことが
全くできていない当時の自分にとってある種の踏ん切りをつける助けになった一冊となりました。
結局、他にもいろいろありましたが、当時の職場を辞めて自分のための道を進むことになりました。

読んだ本リスト

読んだ順とかではなく、大体の分類順です。
特に感想もここには書きません。

技術書

プログラミング系

  • PHPはどのように動くのか?
  • The Java Garbage Collection
  • プログラミングの心理学
  • プロフェッショナル・シェルプログラミング

ミドルウェア

  • Ansible入門
  • Redis入門
  • 理論から学ぶデータベース実践入門
  • みんなで使うGithub
  • グラフデータベース
  • 実践Vagrant
  • 内部構造から学ぶPostgreSQL設計・運用計画の鉄則

キャリア、マネジメント系

  • 組織パターン
  • How Google Works
  • Beeing Geek
    • 再読
  • ザ・ゴール
  • Scrun Boot Camp The Book
    • 再読

テスト系

  • システムテスト自動化標準ガイド
  • テストから見えてくるグーグルのソフトウェア開発

その他

  • Web API the good parts
  • ハイパフォーマンスブラウザネットワーキング
  • なぜ、システム開発は必ずモメるのか?
    • 再読

技術書以外

まとめ

2015年はその前年がマネジメントに偏った読書をしていた影響もあってかかなり幅広く読んだと思います。
基本的に遅読なので割いている時間の割に多く読めてはいませんが、そういうものと割り切っています。
とにかくHow Google Worksは自分にとってエポックメイキングでした。
ついでに言うと、上記を読んだ人は気づいているかもしれませんが、本ブログの題名もHow Google Worksで出てきた一言から取っています。
自分がとっても好きな言葉です。