はてなブックマーク

_ ライティングソフトウェア 翔泳社の野村さんから1ヵ月前くらいにもらったライティングソフトウェア を 連休に読んでみるかと開いたら、想像しているものと違って驚いた。 タイトルからコードの本かと思ったら、全然違う。 そもそもよく見たら副題が「プロダクトとプロジェクトを泥沼から救う工学的手法」とかある。 さすがに、それはこけおどしだなという点も見られるが（リスクの計算のためにΣを持ち出して来て、それは確かにリスクは最初の時点からリリースした後までどんどこ積みあがるものだから正しくはあるけれど）そこで持ち出して来ているコストをリスクが上回る点を求める関数の正しさは保証できないのだから、現実的な正しさとはつながらない。 と書いてふと気づいたが、そういうレベルの話ではないのか。 そうではなく、説得力のある見積もりを提示するための基礎資料を作成する必要がある場合に、過去の類似プロジェクトなどから求め

_ Rails6.1とReactJSの組み合わせは最強ではなかろうか？ Vueとか使ってないからわからんけど、とりあえず、Rails6.1で新規にアプリケーションを作れる状態になったので作り始めたわけだ。 で、プロジェクトを作ったら、app/assets/javascriptsのCoffeeがなくなっていてapp/javascript/packsとかができている。 面倒だなぁとWebpackerの仕組み調べたりyarnとか入れたりしながらいじくっていて、以前のアプリケーションからの持ち越しがあるので、CoffeeからES6に書き換えたりして、少なくともJSよりも1億倍Coffeeのほうがよい理由のラムダ式（というかfunctionとreturnを書かないで済む）はあるし、しかもreduceとmapが使えるからES6のほうが良いじゃんといじっているうちに、なんとなくReactJSで作りたくな

_ 反三国志というアンチ FBで知人が反三国志について書いていたので（最近Kindle版として復刊したのだな）思い出したが、翻訳が出てすぐ買って読んでうんざりして、同じく三国志好きな父親（小学5年か6年のころにおもしろい本はないか？ と聞いたら吉川英治の三國志を読めといって全10巻を買ってくれたくらいだ）に貸したらなんてつまらん本だといって返してきたのだが、存外アマゾンでの評価は高くておもしろい。 とはいえ、四半世紀前にはゴンタの新釈（曹操が主役なのはともかく董卓がマッチョでかっこよかったり陳宮が見るからに文弱だったり孔明が酒色に溺れるのが大好きな軽いのりのやつだったり、劉備はほら吹きのお調子者、関羽は義理人情大事のやくざそのもの、と新釈なのに史実に近くて（さすがに董卓の外見のかっこよさについてはそれはないと思うが、とはいえ人望と実力がなければあそこまで専横を振るえるわけがないのでその意味

_ JavaScript Primer アスキーというかドワンゴの鈴木さん（いつもありがとうございます）からJavaScript Primer 迷わないための入門書 をもらったので読んだ。最近、JavaScript使いまくりプログラムをいじくっているのでありがたいタイミングだった。 JavaScriptのハードコアな本をちゃんと読むのはオライリーの犀本以来で、その後はおもにMDNとECMAの仕様書で済ませているわけだが、やはり日本語の（信頼がおける）文書は読みやすい（MDNはMSDNほどではないが、やはり微妙なところではEnglishに言語設定しないとわけがわからない）。 本書は基本的には通読すべきで（必ずしも精読は必要ないと思う。どこに何が書いてあるかを漠然と記憶して後から参照できるようにするため）、要は一昔前っぽいガチなプログラミング言語の入門書（言語仕様と10日でわかるチュートリアル

_ スケーラブルデータサイエンス データエンジニアのための実践Google Cloud Platform 翔泳社の野村さんからもらったので、なんとなく（ちょっと表紙のセンスが良いのと内容が想像できないこともあって）読み始めたら、これは妙だ。おもしろい。新しい。勉強になる。必読書の類にみえる。 とりあえず1章まで熟読、あとは流し読み時点で書いている。 内容は、GCPでこんなことができるよ（サンプルはhttps://github.com/GoogleCloudPlatform/data-science-on-gcpにあり、Cloud Shellで実行できるらしい）なのだが、読んだ限り単なるGCPの宣伝（こうすればダミー頭でも使えるので明日からデータサイエンティストみたいなやつ。ただしCloud Shellの使い方は図入りで解説されていて、かつ注で1年以上前のことだから今は違うかもみたいなことも

_ 進化的アーキテクチャ（続） 読んでいて気になった点については書いたので、本書について書く。 本書は書名の通り、進化的アーキテクチャについて書いたもので、アーキテクチャの対象はエンタープライズ（少なくとも複数のサービスから構成される規模）、書籍の分類としてはアーキテクチャパターン（だと思うが、本書ではアーキテクチャスタイルという表現をしていて、実のところこの2つの言葉の差異をおれは具体的にはわからない）についての本となる。アーキテクチャそのものを構成するデザインパターンについての本ではない（それはすでにエンタープライズアーキテクチャーがあり、まだ現役だ）。 したがって、最上位のソフトウェア設計のネタ本である。 問題意識は、今やエンタープライズレベルのソフトウェアはとんでもなく複雑化していて数10年前からのレガシーなものから最近の流行のものまでが混在していて、オンプレミスとクラウドが平然と

_ 進化的アーキテクチャ 島田さんからもらった進化的アーキテクチャを読了した。 良い本だと思うし、サジェスチョンと確認と方向づけなど有意義な内容に満ちている。 なので、現在のエンタープライズアーキテクチャー（あるいはある程度の規模、たとえばモデルが8クラスを越えたあたりのWebアプリケーションなど）を構築する場合、あるいはなんらかの改造、修正、移行をする場合には一読しておきたい。 要点と勘所をメモもかねて書く。 ただ、もらっておいてなんだが、本書は良くない点も多い。 最初に、（というのは、要点と勘所を書く前に明らかにしておきたいからだし、正誤表的なメモを最初に掲示しておく意味があると思えるからだが）苦言を書く（もしかすると、このエントリーはそれで終わるかも。最初にネガティブなことを書いて後から誉めるのは悪手だが、それでも本書については最初に苦言を書くべきだと思う）。 本書は、読みにくい。

_ 進化的アーキテクチャ、クリーンアーキテクチャ（最初の部分） 同僚が「エンタープライズアーキテクチャーのTo Beってどういうものがあるのか？」とSlackに投げたので、考えた。 モノリス（これだけでは意味を持たないが、良く結合された3層構造以外の選択肢は現在は考えにくい。ただし、プレゼンテーション層としては別にWeb（それがレスポンシブであろうが）にこだわる必要はなく、デスクトップを含めたネイティブアプリケーションであっても良い）はもちろんある。規模が小さければ他に選択の余地はほぼない。 規模が大きければ、SOAが当然の選択肢となる。 ただ、すでにこれらはTo BeというよりもAs Isだ（今が21世紀で良かった）。 マイクロサービスアーキテクチャーはどうだろうか？ このあたりがAs IsとTo Beの分水嶺のように見える。 問題はマイクロサービスアーキテクチャーは理屈の上では正しいと

_ TinyMCEの使い方 SimpleMDEをしばらく使っていたが色を付けたいというような要望があって、そりゃマークダウンにはないし、かといって直接spanを書かせるわけにもいかないし、というわけでいろいろWYSIWYG系のブラウザ用エディターを調べて、結局TinyMCEに落ち着いた。 が、ドキュメントがいまいちわかりにくくて、どのプラグインが追加有償なのかといったこともなかなかわかりにくい。でも、まあ、そのあたりは解決して（一番使いたいのはTextColorでこれはデフォルトプラグインだし、次に使いたいのはTableで、これもデフォルトプラグインだった）が、一番の問題点は、入力されたデータをどう扱えるか、だった。 それ以外の使い方はなんかおかしなドキュメント(懇切丁寧だが、同じことを何度も何度も繰り返して書いてあるコピペプログラミングみたいな感じ）に書いてあるし、日本語でもうすこしまと

_ Clean Architecture 達人に学ぶソフトウェアの構造と設計 アスキーの鈴木さんからアンクル・ボブのクリーンアーキテクチャをもらったので、読んだ。 おもしろかった。内容にもほぼ同意できるし、良いことがたくさん書いてある。 ただ、読みやすくない（正確ではない。350ページの本に対して付録などを除外しても本文34章に分割しているので、読むのはたやすい。ただし、内容が相当前後するし、依存関係が逆転している章もある。全体像を示してから細部へ進むと言えなくもないのだが、全体像を説明するための用語は細部で説明されるため、逆に全体像を理解するのが難しくなっている（とおれは感じた）ところもある。また、おまけが唐突に最後に来るので、なに昔話してるんだ爺さん、みたいな印象も受けることをもって、読みやすくないとここでは表現した）。 本書が最も重視して、そのためにおそらく書籍の作り方にまで影響して

_ rubyでアドホックにxlsxを読む（1:モチベーション） マスター登録系のWebアプリケーションで、一括登録させたい場合、CSVが比較的利用されていると思う。思う理由は、非プログラマーにとって、デスクトップでの入力アプリケーションといえば、Excelと相場が決まっているからだ。 Excelに入力させた情報をWebにアップロードするなら、ネイティブな形式（xlsかxlsx）が本来は望ましいのだが、ネイティブな形式はバイナリーなので伝統的にCSVが選ばれるのだろう。 CSVは文字列内の,の扱いなどそれなりに厄介なので、タブ区切りのtsvというのが後から出てきたが、後発の悲しさでそれほど主流ではない。というか、よくわからないが、移出形式のファイルといえばcsvというのが不文律みたいだ。 で、これが本格的に厄介になったのは文字コードがからむからだ。 ビジネスの文脈で絵文字が出てくることはそれ

_ 現時点で最もRailsの美点と感じること db:migrate ――これに尽きるのではないか。 というか、コードのリファクタリングは（テストのことはちょっとおいておくとしても）すさまじく低コストにできるのだが、リレーションのリファクタリングはとてつもなく高コストなはずなのに、db:migrateによってえらく低コストになっている（と実感している）。 すでにインスタンスを永続化していても、タスクをちょろっと書いてrakeを流せば済むようにフレームワークがあるので実にお気楽にできる。 これはとんでもないなぁ。 ・結果的にデータモデルを多少バータリーに決めても、後で軌道修正が無茶苦茶簡単にできる。 _ 複数のリレーションと1対多でリレーションシップを持たれるリレーションをどうActiveRecordで実現するか 例としてタイヤのテーブルと、自動車のテーブルとオートバイのテーブルがあり、自動車

_ ヘッドレスChromeでPDF HTMLからPDFを生成する必要があって、以下の方法を考えた。 Edgeに該当URIを叩かせて、プリンタドライバにMS純正のPDF出力を設定しておいてJavaScriptでprintを呼び出す。 で、これが確実に動くのはわかっているのだが、実行環境がGNU/Linuxなのでどうにもならない。 Firefoxはapt-getで入れられるのでメンテナンスが楽そうだが、PDFに出力する簡単な方法が考え付かない。 しょうがないので、ヘッドレスChrome（頭があって手足がないが正解な気がするが本人がヘッドレスを名乗っているのだからまあ良いのだろう）を使うことにした。 Chromeはapt-getはできないが、debが用意されているから我慢する（のだが、今、あらためてみると、どうやってdebをダウンロードしたのかまったくわからない。どうあってもWindows版をダ

_ アジャイルエンタープライズに驚いた 翔泳社からアジャイルエンタープライズが送られてきたのでありがたく読み始めた（他にもいろいろあるのだが、紙質（表紙の固さ）とか字の大きさとかが妙に具合が良かった）。 1章を読み始めていきなり衝撃をくらわされた（注）。 アジャイルという言葉に対してのすでに持っている概念とエンタープライズという言葉から、大規模開発に対してアジャイルのメソドロジーを適用するための方法論の本かと思っていたからだ。 全然違った。 一言で本書の内容を言えば、常に変化に対応することで生存し成長する企業をつくるには、どのような文化がふさわしく、いかにそれを構築するか、について説明したものだ。 注）節題が「1.1 本書の革新性」とくるので、あまりの自信たっぷりっぷりに斜に構えて読んでいたからかも知れない。 冒頭の「最も高い顧客価値に目を向けている企業を想像してください。」が額面通りだっ

_ 江添亮の詳説C++17 アスキーの鈴木さんからいただいた。 電話帳のような本を想像していたら、とんでもなくコンパクト（対電話帳比。ところで今も電話帳って存在するのか？）で驚いた。C++17の新機能に的を絞った本だからだった。 これはおもしろい。 とりあえず読み始めると、早くも本文2ページ目にして筆者がLinus翻訳で磨き上げた表現、つまりそびえたつものが出て来たりするので、単に規格書を翻訳して味付けした本ではないということがわかる。まあ、鈴木さんのところでそういう本を作ることはあり得ないだろう。というわけで、江添さんの規格書フィルターと特徴的な文体（客観的に突き放した主観表現）が特徴の本ということになる。割と好きだ。 それにしても（と読みながら思う）、プリプロセッサはクソだから捨てるべしとストラウストラップが書いていたように思うのだが、C++でポータビリティがあるコードを書くためには結

_ 独習C 翔泳社から独習Cを上梓しました。 翔泳社の独習シリーズは数年前までは海外の定番書の翻訳だったわけですが、ここ数年は日本の著者による書下ろしに移行していて、いよいよCの番となり、光栄なことに僕に声がかかったという次第です。 正気に正直に言って、Cの入門書としては素晴らしいできの、Cを学習するなら、これしかないものを作ったつもりです。 とは言え、何しろCなので、つまりは常識的に考えて死すべき言語筆頭なわけですよ。したがって声がかかったからといって当然のように即答とはいかないわけで、書き方と切り口をどうするかは大問題。 数年前はC死ねと思っていました(今も思ってます)が、へんな言語でみんな苦しんでいるという意味では近年ではObjective CとJavaScriptの死ね度の急上昇には注目したい。人類のために今滅ぼすべき言語としてはそちらのほうが優先されても良いと思います。 — Ur

_ プログラマーとお仕事をするということ読了 翔泳社の野村さんからいただいた「プログラマーとお仕事をするということ」を通勤電車の中でちびちび読んでいて、大体1か月で読了（他の本読んだりしていたからで、すごく読むのに時間がかかるというわけではない）。 内容はソフトウェア開発プロジェクトをどうすれば成功させることができるのかを、筆者の経験と統計データ（脚注でそれぞれの数字の出典が示される）を組み合わせて説明したものだ。といっても、プロジェクト運営の話かというと相当違う。どちらかと言うと、ソフトウェア開発とは何か？ 何が問題点なのか？ についてヒューマンリソースという観点から説明したものだ。 すでにアマゾン評が3つ出ていて、星5、3、2と分かれていて、それを読むと、なぜこの本が成立するのかわかる。 星3の人の評。 プログラマーとして、どういう点に気をつけるべきなのかというモチベーションで読みまし

_ nginx-unicorn-railsで大きなファイルを扱う 大体400MBくらいのファイルをクライアントから上げてもらってそれをRails側で処理する必要が出てきた。 仕組み上、400MBの送信がクライアント－nginxとnginx-Unicornで必要となる。このときnginxとUnicornが同じマシンであればこの間の通信は無駄なので避けたほうが良い。 というわけで検索したらRailsで大きなファイルを扱う際のポイントという記事を見つけたのだが、今は2018年だ。nginx-upload-moduleはapt-getでインストールできるが、実際に動作しているnginx（）では動かなかった。検索すると、自分でソースにパッチしてmakeすれば良いというようなのは見つかったが、それはデプロイを考えた場合避けたい。 さらに検索するとNginxを使ってファイルアップロードを高速化する方法と

_ はじめよう！ システム設計 技術評論社さんから（というか、羽生さんから、かな？）「はじめよう！ システム設計」をいただいた。 いきなりあとがきから読んだわけだが、問題意識が興味深い。 2017年はIT投資に企業の目が向いた年として規定される。AI、IoT、RPAの3つのキーワードと（個々人は貧乏街道まっしぐらだが資本はどんどん膨らんでいる）経済状況が背景にある。 ところが、SIerは人材流出の結果としてプロジェクトの全体構想を立案し着実に遂行する能力をほぼ失い、個々のPMの属人的な能力、つまり経験と知見だけで動くようになった結果、失敗が多い。 一方の発注側は、ITは虚業という言葉に散々踊らされた結果のIT軽視のツケと、これまでのコスト部門の弱体化（というか低予算化戦略）の結果として、これまた人材がいない。 結果として口が巧みなコンサルタントによる実現不可能な夢をトップがもって突っ走りま

_ 低レベルプログラミング 翔泳社の野村さんから低レベルプログラミングをいただいたのでレビュー（完全に読んだわけではなく、自分および少数の購買予定者のためのアジェンダ用にレビューしたというところ）。 著者はレニングラードの（こんなところで懐古趣味をひけらかしてもしょうがないが、そういう性格だからしょうがない、つまり聖ピョートルの都市のことだ）ITMO（と書いて国立情報技術機械光学研究大学、らしいのだが光学って本当なのか工学の誤記なのか謎）の先生で、多分、この本は副読本なのではなかろうか。どういう先生かというと、この先生のチームは、ACM-ICPCの国際大学対抗プログラミングコンテンストで6回優勝しているそうだ（少なくとも2017年の優勝は間違いない。というか3位は京城、7位が北京で、東京が12位なのか。韓国もすごいな）。 本書の目的がまえがきにある。7つの目標だ。 ・アセンブリ言語で自由自

_ 作りながら学ぶReact入門 2～3か月前になるけど、@yuumi3さんから『作りながら学ぶReact入門』をいただいた（サポートページ）。どうもありがとうございます。で先日読んだが、ちゃんと紹介しておくことにする。 ちょうど、Reactも見ておこうと考えていたので良いタイミングだった。 で、読み始めたら、単にReactの入門というだけではなく、現時点のJS（フロントエンドと言ったほうが正しいかな）開発についての目配せがされていて、僕にとっては、それ以上に良いタイミングの本だった。 読者はMacを使っていることを前提としている（一応Windowsとも書いてあるし動作確認はしているみたいだけど、Macのほうが良さそうだ）。 エディターを用意して、Node.jsを入れて、npmを用意したところで、3章に続く。 3章になると、モダンJS開発環境の解説となって、（2章で用意したNodeJSとn

_ @t_wadaとケントベックのテスト駆動開発 長らく絶版となっていたケントベックのテスト駆動開発（入門）が、オーム社から装いと訳者もあらたに再刊されて、しかも嬉しいことに、編集の森田さんから頂けたので早速紹介する。 くだくだしいことなどは後のほうで書くことにして（このページ群はおれにとってはその時考えたことなどを記す日記でもあるからだ）、まず本書の要点について書く。 原著は2003年、本書はそれの翻訳なので15年以上の歳月を経た準古典だ。何についての準古典かといえば、題名からわかるように開発についてで、なんの開発かと言えばプログラムだ。 一言で言えば、1人でプログラムを開発するときに、どのように開発へのモチベーションを維持しながら、開発そのものをゲーム化して楽しみながら（まあ、1人でプログラムを開発しようとした時点で、それはゲームなのだが、さらにルールをいくつか導入することでゲーム性を

_ UNIXプログラミング環境 アスキーの鈴木さんから頂いたUNIXプログラミング環境をざっと読み返して（だと思うんだけど、もしかすると実は初見かも）いろいろ考える。 1985年のまえがきがついているのだから、30年以上前の本だ。 読み始めて、すぐに、そうそう、昔（といっていいよな）はstty（セッティ）がすごく重要だったよなとか思い出す。間違えてバイナリーファイルをcatしたりviで開いたりすると、端末制御が無茶苦茶になって、改行されなかったり、エコーバックされなくなったり、操作できなくなる。かといって、Alt-F3で切り替えて殺したりとか、Xをクリックしたりして殺したりはできないから（つまり、RS232Cとかで本体と端末がつながっていて、その線にデディケート（日本語でなんと言うんだっけ？）されているから、その端末についているキーボードでどうにかするしかない。でも、Unixのシェルは忠実

_ 汐留に行く 妻と飯食いに出かけたら、目当ての店が改装中でしまっていた。 では神保町でロシア料理でもくおうかと思ったら、駐車スペースが空いてない。 では汐留はどうか？ と妻が提案する。中国飯店のカジュアル部門が入っていて、それなりに美味しい（中国飯店のクラシック部門にやたらと好きな店があるのが前提としてある）。 では行くか、と行ったらさっぱりどこに停めれば良いのかわからない。 結局、首都高の駐車場に入れたら、驚いた。4箇所ある出口がすべて右側（車道は下り側）にしかない。だが、汐留のタワー群は左側なのだ。 しょうがねぇなあと面倒だがそのうち一つから出たら、番地がない中華料理店があった、と妻がはしゃぐ。しかし、おれはそれは見損なった。 地上に出ると、異様にさびれていてびびる。はて、これが汐留なのか？ と、中銀カプセルタワービルが目の前にある。網がかかっている。 おお、こんな間近で観られるとは