2017年11月11日

2桁億円分ぐらいの価値がある本:ソーシャルアプリプラットフォーム構築技法を読みました

ソーシャルアプリプラットフォーム構築技法――SNSからBOTまでITをコアに成長するというお金の匂いがすごくする本が技術評論社から出版されました。その筋の人には有名な、田中洋一郎さんの渾身の一冊です。

田中洋一郎さんはソーシャルプラットフォームに長年携わってきました。その数々の経験から生み出されたのがこの本書です。技術書のカテゴリーではありますが、ソースコードよりもソーシャルプラットフォームが備えるべき機能の概要設計およぼそのチーム編成やガバナンスが中心です。ちょっと上流な本です。とはいっても技術の部分で見てもなかなかの太さです。洋一郎さんさんGoogle API Expertという、今はもうない肩書のホルダーです。たしかOpenSocialのExpertで、それゆえに認可認証周りとかの説明が手厚くなっています。このあたりは規格を見ても「何のために?」がよくわからないのですが、「なぜこうしなければならないのか」「それを実現するにはこの規格を実行すればよい」というのがクリアに説明されています。

また、時代の流れにあわせて、スマホアプリのソーシャルネットワーク認証周りとかも、iOS/Androidに向けてそれぞれ書かれていますし、ハマりがちな落とし穴とか、注意すべき点とかもたくさん書かれています。また、近年話題にあがることが多いチャットをベースにしたソーシャルアプリであるBOT周りとかもいろいろ書かれています。インターネットに絡む技術のうち、何を使ってどうすればいいのかを照らす松明のような本です。

この本が一番すごいのは、やはりSNSを運営するための組織体系とか、利用規約などについて、事細かに書かれています。おそらく、長年の経験による積み重ねのベストプラクティスです。法務やサポートなども含めて、本にかかれているとおりに実践しようとすると、軽く20人とか30人以上の大所帯のチームが必要になります。どんなにコンパクトで必要最低限に作ろうとしても、軽く年間で億の単位で、しばらく継続すると2桁億はお金がかかるでしょう。それだけの経験を得ないと書けないような本です。つまいは2桁億円分の価値があるといえます。また、これだけお金がかかってもなぜ企業はSNSを作るのかというと、それによって大きな収入を得たいからです。この本も、そういうチームを組織しつつ、きちんと「お金をいただく」というところを逃げずに書いています。なかなかこれほどお金に真摯な技術書はなかなか珍しいかと思います。

(お金の面で)こんなに(完全な)実践が難しい本もなかなかないからといって、それ以外の人に無駄ということはありません。本書のターゲットであるソーシャルネットワークを作る人と、それに乗っかるアプリケーションを作る人では、人数比は1:9以上だと思いますが、前述の技術的なところの内容は後者の人にも十分に役に立ちます。いや、まじで認証周りの情報が整理されている点だけで元とったと思える本です。

もうちょっと田中さんの目線で解説がしてほしかった項目も少しあります。例えば、僕が知っている内容だと、モバゲーの簡単会員とかはちょっと特殊だけど「なるほどなぁ」という仕組みだったりします。後は、最終章のBOTのAPIだとSlackがウェブフックも、ストリームもサポートしつつ、OAuth2認証のアプリマーケットまで備えたりとかなかなかリッチなので誰かに詳しく説明してほしいなぁとちょうど思っていたところです。まあ全体からすれば小さい話ですし、後者もまだまだ変わる可能性があるので本で扱うのはちょっとむずかしいかな、という気もしています。

それ以上に少しこの本が損しているな、というポイントは「ソーシャル」という言葉がタイトルに入っていることなんじゃないかと知人が指摘していました。確かに「ソーシャル」という言葉を使う機会は相当減っているような気がします。確かにSNSの最初のSはソーシャルですが、もはや「SNS」という用語みたいになっています。本書で書かれているプラットフォームは、たとえばGitHubだったり、アプリマーケット全般にも有効な話ばかりです。SNSだとマインドシェア1位以外は生き残りが難しいレッドオーシャン、みたいな印象がありますが、「アプリマーケット」という別の領域でも活躍できる話ばかりです。

なお、この本はとてもきれいな(クリーン&読みやすい)日本語で書かれています。本文で丁寧に説明されていて、脚注などはありません。しかし、「◯◯をしてしまうとトラブルが発生したときに大変です」みたいな日本語の裏には、きっと表に出せないようないろいろな修羅な体験があったのではないかと想像に難くないです。ぜひとも、洋一郎さんが、人には言えない数々のトラブル事例とかを紹介してくれるディナーショーとかあるなら参加したいですね。そういうのを想像するだけでもなかなか楽しく読めます。

posted by @shibukawa at 22:44 | TrackBack(0) | 日記 はてなブックマーク - 2桁億円分ぐらいの価値がある本:ソーシャルアプリプラットフォーム構築技法を読みました

2017年10月19日

ASCII.jpの連載「Goならわかるシステムプログラミング」がパワーアップして書籍化されます

Real World HTTPに引き続き今年2冊目の書籍が出版されます。ASCII.jpの連載をまとめて、加筆修正したものになります。最初は、連載をつなげて、はじめに、と次回予告を書き換えてつなげればOKという感じからスタートしましたが、章構成を書き換えたり、書き始めのときに「そのうち連載で触れる予定です」を「◯◯章で説明します」に書き換えたり、せっかくだから内容を追記しようとか考え始めたり、レビューアのメンバーが「これは並列・並行の結果であって原則とは違う」みたいな細かい定義のところまで指摘してくれて説明を大幅に書き換えたり、蓋を開けたら前から最後までかなり時間をかけて修正することになりました。せっかく転職で有給消化が一ヶ月あったのですが、この原稿の修正で一ヶ月がするっと溶けました。

11/16追記 Amazonでも販売がはじまっています!

大きな修正ポイントは次の通りです:

  • 連載の分量の関係で、同じテーマを何回かに分けていたのをまとめた
  • 並列処理の記事からチャネル関連を抜き出して、加筆を大幅に加えて独立した章に
  • タイマーやクロックについての章を追加
  • セキュリティについての章を追加
  • Go 1.9で追加されたもろもろを追加
  • 締切の一週間前に、連載で紹介したIntelliJ IDEAのCommunity版で、Goプラグインがダウンロードできなくなったというレビューの報告を受けて急遽Visual Studio Codeに差し替え
  • 高尾編集長の徹底的な修正で日本語が大幅に改善した
  • 雪だるまの絵が、妻の書いたフクロウに変わった

これ以外にも数多くの修正を加えています。紙の書籍にするにあたって、数多くの知人に協力してもらって、レビューしていただいたのですが、1ページにつき1件というペースに近い300件近い意見をいただきました。これは連載をしていたので、一度細かい所まで見て修正したので些細なミスはあまりないはず、というところからの出発でしたが、遠慮なく徹底的にみてくださったレビューアのお陰で、かなり改善されています。ASCII.jpの連載終了から440コミットありました。

元は、LLでウェブアプリケーションフレームワークを普段作っているけど、低レイヤーを学ぶチャンスがなかなかない人に向けて本を書くといいのではないか、とラムダノートの鹿野さんと雑談したところから始まった連載でした。Real World HTTPも通信の低レイヤーではありましたが、こちらはOSの方面の低レイヤーになります。C言語を使った、読む側にもそれなりの知識が必要とされる本はいくつもありましたが(とても良い本です!)、本書はそういう既存の本よりも読みやすい本が提供できたのではないか、と思っています。アプリケーションレイヤーの応用例もイメージでき、古い本では紹介されているけど、現実的にあまり使われていないものは省き、逆に最近のトピックに触れるといったことで違いを出しました。

販売計画

続きを読む
posted by @shibukawa at 23:17 | TrackBack(0) | 日記 はてなブックマーク - ASCII.jpの連載「Goならわかるシステムプログラミング」がパワーアップして書籍化されます

2017年05月17日

「Real World HTTP」が出版されます!

昨年から書いていたReal World HTTPがAmazonのページに表示されるようになりました。最初にコミットしたのは昨年の8/1ですが、たぶん、その数ヶ月前から書き始めていたと思うので、ほぼ丸一年です。途中でASCII.jpのシステムプログラミングの連載が始まったり、Software DesignにSphinxについて寄稿したり、もう1つ別の翻訳の企画があったり、三女が7/4に生まれたり、なかなかハードな一年間でした。

なお、表紙は皆さんが知っているものとはちょっと違うのですが、系統的に一番近いのがハシビロコウさんらしく、和名もそれしかないそうです。狙っていたわけではなく、そもそも出版時期にはアニメも終わってしまっているし、話題の動物は辞めたほうが良さそう、という話をしていたのですが、偶然これが選ばれました。

本の内容の紹介

裏表紙の紹介はこんな感じです。


本書はHTTPに関する技術的な内容を一冊にまとめることを目的とした書籍です。HTTP/1.0、HTTP/1.1、HTTP/2と、HTTPが進化する道筋をたどりながら、ブラウザが内部で行っていること、サーバーとのやりとりの内容などについて、プロトコルの実例や実際の使用例などを交えながら紹介しています。 GoやJavaScriptによるコード例によって、単純なHTTPアクセス、フォームの送信、キャッシュやクッキーのコントロール、Keep-Alive、SSL/TLS、プロトコルアップグレード、サーバープッシュ、Server-Sent Events、WebSocketなどの動作を理解します。 これからウェブに関係する開発をする人や、これまで場当たり的に学んできた人にとって、幅広く複雑なHTTPとウェブ技術に関する知識を整理するのに役立ちます。HTTPでは日々新しいトピックが登場していますが、本書によって基礎をしっかりと押さえることは、さまざまな新しい技術をキャッチアップする一助にもなるでしょう。

目次はこんな感じです。

  1. HTTP/1.0 のシンタックス:基本となる 4 つの要素
  2. HTTP/1.0 のセマンティクス:ブラウザの基本機能の裏側
  3. Go 言語による HTTP/1.0 クライアントの実装
  4. HTTP/1.1 のシンタックス:高速化と安全性を求めた拡張
  5. HTTP/1.1 のセマンティクス:広がる HTTP の用途
  6. Go 言語による HTTP1.1 クライアントの実装
  7. HTTP/2 のシンタックス:プロトコルの再定義
  8. HTTP/2 のセマンティクス:新しいユースケース
  9. Go 言語による HTTP/2、HTML 5 のプロトコルの実装
  10. セキュリティ:ブラウザを守るHTTPの機能
  11. クライアント視点で見るRESTful API

内容としては、HTTP/1.0、HTTP/1.1、HTTP/2というおおざっぱな期間ごとに次の3つの章を繰り返してその時期に登場した技術のトピックをいくつか紹介し、最後にセキュリティとRESTfulの章が追加されている感じです。

  • HTTPのシンタックス
  • HTTPのセマンティクス
  • 実際にコードを書いて試してみる

実際にはHTTPのバージョンは時期的な目安なので、そこまで厳密ではありません。消化不良にならないように読みやすく分割するための分け方です。人間の記憶はエピソードとともに知識を固定する方がやりやすいので、そういったことを心がけています。普通のHTTPのプロトコルの技術的紹介だとなかなか詳しく紹介されないであろうトピック(TLS、認証/認可、セマンティックウェブのその後、セキュリティを守るためのブラウザ技術)についても、多くの方々の強力なバックアップのもとに概要をきちんとつかめるように書きました。

アプリケーション開発だと、ウェブに関係しないシステム自体がだいぶレアになってきているので、かなり多くの人に末永く参考にしていただけるのでは、と思っています。CGI時代やJ2EE初期時代に学んだ人も、その後の知識のアップデートに役立てていただけると思います。最新のブラウザの機能(セキュリティのヘッダーとか)も、過去の経緯や機能を踏まえて追加されることがほとんどです。一通りきちっと学ぶことで、今後出てくるトピックを追いかけるのがとても楽になるはずです。「読める!読めるぞ!」とムスカになったような感動が味わえるはずです。

後は、書いていてワクワクしていたポイントは、HTTPまわりの仕様にはさまざまなエンジニアリングの創意工夫があることです。後方互換性を維持するしくみとか、サーバー・クライアントでベストな選択肢を選ぶ方法、効率の改善。こういうところに着目して読んでもらえると(上級者には)楽しいと思います。

なぜ書こうと思ったのか

続きを読む
posted by @shibukawa at 02:40 | TrackBack(0) | 日記 はてなブックマーク - 「Real World HTTP」が出版されます!

2017年05月01日

高校生からはじめるプログラミングを献本でいただきました

大学のサークルの後輩の吉村総一朗(当時呼び捨てで呼んでたと思うので、あえてこのまま敬称略で書きました)から、高校生からはじめるプログラミングを献本でいただきました。ありがとうございます。

IPを使った表紙、フルカラーの本文、高校生どころか老眼鏡を使うような人でも読みやすそうな大きな文字、「(」の記号の入力の仕方から教えるような今まで無かったというか、小学校入学前の子供をターゲットにしたたのしいプログラミング Pythonではじめよう!(ただし原著。日本語は漢字や英語の習熟の問題もあって中学生以上がターゲット)の方がストイックなぐらい。こんなにコストがかかったプログラミングの本は見たことがないです。その徹底ぶりが評価されてか、Amazonのランキングでも上位に常駐しているようです。羨ましい限りです。

内容としてはHTML/JavaScript/CSSを入力してブラウザで動かしてみよう、というノリです。かつて僕が衝撃を受けた、ラベルをウインドウに貼り付けることでコードを一行も書かずにHello WorldができてしまったVisual Basicに近いアプローチです。関数とかメソッドとかクラスとかそういうのはどうでもよく、まずは動くものを表現して、徐々に新しいオモチャを提供していくスタイルです。今日ではコードスニペットを利用することも多く、Twitterのボタンを作ってみる下りはそういった操作の紹介もされています。

どこまで初心者に配慮すべきか問題と体育の授業

「チュートリアルの記事を公開したり、インターネットで困っている人を助けるといった活動はどこまでやるべきか」というのを議論したことがあります。個人的には初心者に対するサポートという意味ではオールインワンのインストーラでWindowsユーザーでも安心だし、ドキュメントにはコピペ素材が満載のPHPというのが1つのベンチマークだと思っていました。ツールやライブラリもPHP並に初心者をファシリテートしてあげるのが大切だと思っていました。僕がドキュメントツールのSphinxのコミュニティを作ったり、Pull Requestを投げたりするのも、こういった考えからです。

しかし、そこまでモチベーションが高くなく、質問ばかりしてチューターのやる気を削っていくような人もいます。そういう人は放置すべき。千尋の谷から突き落として這い上がるやつができるやつ、みたいな考えを持っている人もいます。コミュニティ運営やドキュメント整備などを行う人のリソースの少なさを考えると、残念ながらこうせざるを得ない言語やフレームワークのコミュニティも多いかもしれません。僕もPHPを基準に考えていますが、そこまで来られなかった人は残念ながらそれ以上のサポートはちょっとムリと思っています。

しかし、子供の頃に体育の授業が苦手で体を動かすことが苦手だったけど、オトナになってボルダリングをやってみたら楽しかった、インラインスケートをやってみたら楽しかったといった体験をする人が増えています。サッカー、野球のようなスポーツではなくて、マイナースポーツ系のコミュニティに行くと「元運動嫌い」のオトナはたくさんいます。千尋の谷方式というのはこの体育の授業のようなものです。「人と比べられるのが嫌なだけで体を動かすのは嫌いじゃない」人にもまんべんなく「楽しんで継続してもらう」ことはリソースが少ないとできません。これは授業が悪いというよりも少ない教師数で30人、40人の生徒を教えるというリソースの少なさが問題です。実は才能があったかもしれない子供が早期にあきらめてしまうといったこともあったかもしれません。

この本は自習できる書籍という形で提供されており、さらに豪華な装丁で「コンピューター怖い」という人にも優しくアプローチしてくれると思います。小学校からプログラミングを、みたいな話もあります。Scratchとかになるとは思いますが、当然中学、高校と学年が進めばより実用言語の方向に進んでいくでしょう。現状のリソースでは体育の授業の「運動嫌いのオトナ」が量産されていく可能性の方が強く、個人的には子供のころからのプログラミングの授業導入はどちらかというと(僕も運動嫌いだったので)反対でしたが、こういった本が増えて、自習できたり、授業外で親が教えたりといったことで落ちこぼれない仕組みができるならもしかしたら悪くないのかもしれない、と少し思いました。

個人的にはアスキーでやっている連載のように少し自分の実力よりも背伸びした内容で、自分の好奇心も満足させながらじゃないと一冊分の集中力は続かないので、この本のような本は僕には書けないなということもあり、著者の努力はすばらしいと思います。

「献本は誤用でご恵贈が正しい」みたいなのも見かけますが、誤用とか勘違いが広まって文化になる、みたいなのが好きなのであえて献本にしました。「けんぽん」。声に出すとかわいい日本語。

posted by @shibukawa at 18:16 | TrackBack(0) | 日記 はてなブックマーク - 高校生からはじめるプログラミングを献本でいただきました

2016年12月20日

passiveな#kaneの話

これはPySpaアドベントカレンダー2016の20日目のエントリーです。19日目はPySpa界で圧倒的な存在感を誇るしうまちでした。

知人にジブラルタ生命の人がいて、その人の紹介で契約件数でトップの方を紹介してもらい、保険の見直しをしました。

渋川家の戦略

ゲームでも投資でも勝ちに行く、負けないようにする、この2つのどちらを選ぶかで指し手は変わってきますよね。 節税とかあんまりわからないし、投資で大儲けとかも興味ないというか、お金のこと考え続けるのはあんまり好きじゃないタイプなので、 基本路線としては、家族全員が路頭に迷わない==負けない方向で考えています。 勝つ方向に興味ある人は、r_rudiさんの #kaneの話 の方が面白いと思います。

会社でサポートされるケースも多くあります。昭和からある大企業に努め続ける前提なら、退職金とか会社の提供する財形とかいろいろあります。 該当するならそれに乗っかってしまえば考えることは少なくて済むでしょう。関東IT健保に入っていれば医療保険もいらないです。 でもまぁ、同じ会社に入る続けるかどうかも分からないし、大手に入っても業績が安定しているとは限らないし、年金は出ないという前提で、自衛のために生命保険でバックアップを組むことにしました。

嫁の医療保険は、お義母さんが入ってくれてくれているのがありましたが、それも今回引き取って、こちらで全部やるということにしました。

生命保険とは

続きを読む
posted by @shibukawa at 01:20 | TrackBack(0) | 日記 はてなブックマーク - passiveな#kaneの話

2016年09月21日

ascii.jpで連載がはじまりました

本日より、ascii.jpでGoならわかるシステムプログラミングという連載を開始しました。ascii.jpのプログラミング+セクションが最近作られまして、そこのコンテンツとして、遠藤侑介さんのRubyで学ぶRubyとともに連載します。遠藤さんの連載も、RubyでRubyを実装しつつRubyを学ぶというマニアックな内容で、僕の方もシステムプログラミングということで、かなり尖ったラインナップです。僕も機能はだいぶ限られていましたが、PythonでRubyを実装しようとしたこともあり、遠藤さんの連載も楽しみです。

僕自身、システムプログラミングがすごく詳しいとか、めちゃ経験があるわけではないのですが、OSに近い機能をぽちぽち分かりやすい言語で触りつつ、僕自身も学びつつ連載を続けようと思っています。内容も、よくあるLinuxのシステムプログラミング系の本で触れているようなファイル、通信、プロセス、プロセス間通信、並列処理などに触れていく予定です。システムプログラミングというと、Linuxを対象に分厚い本で学ぶ印象がありますが、サンプルを動かしつつ、WindowsでもMacでもLinuxでもなるべく平等に気軽に楽しめる連載にしていきたいと思っています。

読者層として考えているのは、スクリプト言語などでフレームワークを使ってウェブ開発をしていて「ちょっと下のレイヤーも覗いてみたいな」と思っている人です。Goを選んだのはC言語でなければやりにくかったことを短いコード行数で実現できる点と、OS間の差異で学習が引きずられることがあまりない点が優れているからです。連載の主テーマはシステムプログラミングであってGoではないのですが、他の言語はある程度知っていて、Goは余り知らないという人向けにGoの文法も必要に応じて少しずつ触れていく予定です。

プログラミング言語Goが出版され、プログラミング言語C++、Core Java的な核となる書籍がとうとう日本のGo界にもやってきました。今後はみんなのGo言語のような、脇を固める本がどんどん出て、Goのラインナップの厚みはどんどん増えていくでしょう。Goは書きやすさもあり、コンパイルでエラーチェックもしっかり行ってくれるため、Pythonと同じように「学習のための擬似言語」としてのポテンシャルもあると思います。そのため、僕の連載にかぎらず、Go「を」説明するのではなく、Go「で」説明する、という用途がガンガン増えていくと思っています。今後共よろしくおねがいします。

連載にあたっては、読者目線で徹底的に鹿野さんに文章を揉んでもらいました。当初よりも洗練され、だいぶ読みやすい内容になりました。また、タイトルも知恵を絞ってくださいました。セルフパブリッシングが来ると言われていても、きちんとした編集の方に見てもらうのは今の技術では替えられないものがあります。文章を書くということは、情報をギブするとともに、読者の方々の時間を頂く行為でもあります。その時間を少しでも有意義にしてもらえるために、内容も文章の質も高いに越したことはありません。本は十数冊関わってきましたが、まだまだ勉強させていただくことがたくさんありました。

posted by @shibukawa at 20:49 | TrackBack(0) | 日記 はてなブックマーク - ascii.jpで連載がはじまりました

2016年08月29日

技術に造詣が深く、適切に布教を行いながら学びを得ている人間(A)は存在するか?

JavaScript界隈はそれまでの業界に較べていろいろ加速しているように見えます。

  • 情報の流通がコミュニティの内輪ベース(会社、勉強会、ML、mixiグループetc)から、Twitterなどのコミュニティの壁のないSNSにうつった
  • はてなブックマーク、シェア数、Qiitaのストック数など、数字で注目度の大小が比較できるようになった

その中で新しいフレームワークが出ては大騒ぎし、「2015年のおすすめのツール集」が注目され、そして2016年にはがらっと大きく変わっている。そういうフロントエンド疲れが取り沙汰されています。その中で上記の記事は、技術に造詣が深く、適切に布教を行いながら学びを得ている人間(A)がいて、その活動はいいけどそれに乗っかってマウンティングしたがりの人たちがいるとしています。では、みなさんが思うAって誰でしょうか?でもおそらく、その人達も、かつては多分下のような、現在は滅亡してしまったものに夢中になったことがあると思うんですよね。

  • MacOS (9以前), OS/2 Warp, BeOS
  • Palm Pilot, Windows Mobile
  • Delphi(あるいはBorland社の処理系全般)
  • Vzエディタ、MIFES
  • セガのハード
続きを読む
posted by @shibukawa at 11:19 | TrackBack(0) | 日記 はてなブックマーク - 技術に造詣が深く、適切に布教を行いながら学びを得ている人間(A)は存在するか?

2016年06月23日

制約理論とアジャイル〜アジャイルとウォーターフォールは対立するのか?

Waterfall

アジャイルとウォーターフォールの対比について話題になるのは、いつものことな感じがしますが、今回はウォーターフォールを支持する側の意見がはっきりと形になっているのがちょっと違うなと思いました。とは言え、読んでいて違和感を感じるところがないこともないので、僕の考えをまとめてみます。

制約理論とアジャイル

続きを読む
posted by @shibukawa at 22:09 | TrackBack(0) | 日記 はてなブックマーク - 制約理論とアジャイル〜アジャイルとウォーターフォールは対立するのか?

2016年03月24日

ソフトウェアの世界は螺旋を周りながら進歩している

npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。

上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。

  • SourceForgeやCodeplex、Google Codeのような、プロジェクトが唯一の名前空間という世界があったが(今もないわけではない)、GitHubやBitbucketのような、個人や組織が名前空間としてあって、その中で自由に作り放題の世界ができた。
  • 地道にパッチを送って、信用貯金を得てコミット権を得るという文化から、どんどんプロジェクトを作って、フォークしてPull Requestで開発を行っていく文化になった。
  • かつてライブラリは、システムにインストールするものだったが、node.jsがプロジェクトごとにローカルにライブラリ庫を持てるようにした。Pythonはvirtualenvなどの後付の仕組みでそれを実現していたが、それが標準になった。プロジェクト間のコンフリクトを恐れずに気軽にダウンロードできるようになった。

3/25追記:
最後の項目について、はてブでJavaについての指摘がありました。CLASSPATHについては確かに指摘された通りですが、それを言ってしまうとconfigure --prefix=(ここ)でもできちゃうことではあるし、rpm/deb/CPAN/PyPIなどの依存関係解決機能付きの中央パッケージリポジトリを使ったケースで考えていました。Javaは1.2のホットスポットコンパイラすげぇ!って時に触ったっきりですが、調べてみたらMavenは共通の場所(${HOME}/.m2)に入れているようですね。最近のJava事情はよく分かってません。すみません。昔の、1回ダウンロードしたものをありがたく使い回してたのはダイアルアップ等を考慮してのような気がします。

新しいことを始めたり、コードを改善する上での敷居がどんどん低くなって、コードを書く自由が飛躍的に高まりました。今回起きたnpm、CocoaPod、Gemの話はこれらの流れとは逆行する話です。作る自由というのは壊す自由と表裏一体です。変更やアップロードが取り消したりすることができなければ、作るのにみんな慎重になります。無茶できるのは、セーフティネットがあるからです。そういう意味で、「unpublishを禁止しよう」というのはちょっと違うかなぁと思います。それでは防ぐことはできません。

壊れたアップロードもできないように制約をかけるべきか?マイナーバージョンアップでは、使われているすべてのパッケージで壊れないかを自動テストすべきか?というのを考えていっても、どんどん不自由になるだけです。

ちなみに、npmの対応を問題視している人もいますが、たぶん運営側になったらこのような対応をせざるを得ないかなって思います。全世界から使われるサービスで、「この国のこの法律に反しているんだけど」って言われた時にどこまで対応すべきか、無視すべきか、そこをきっちりガイドライン化できる人はたぶんいない。自分の国の著作権の扱いだけでもみんな頭を抱えている状態ですし、法的アクションを起こした人優先にせざるを得ないかなぁと思います。そうでなければnpm社が潰される可能性もゼロではないし、npm全体のエコシステムがまるごと潰されるよりは、指摘があったトカゲの尻尾を切り離す方が全体の保持になると思いますし。

3/25追記:
npm社も一応ガイドラインがあってそれに基づいた紛争解決はこれまでも行われてきたとのこと

The npm Blog − kik, left-pad, and npm

なるほど。そもそも名前に関する紛争解決ガイドラインがあって、semverを使ってユーザーに負担にならないように名前を移管することが推奨されてるのか

2016/03/24 14:15

Github社だって、指摘があったらリポジトリをクローズします。知人がこれをされたことがあるのですが、反論の余地は与えられなかったとのこと。ここに消えていったリポジトリの墓標があります。他の知人で、Bitbucketでリポジトリをクローズされた人もいます。まあこれはプライベートリポジトリが無制限になった時にエロ動画をたくさんアップしたという事案なのでアレですが・・・

使う側での防衛方法としては、リスクを恐れてgithubやnpmの使用をやめる、というのはご自由にどうぞ、と思いますが、現実的な落とし所は、きちんと信頼できる開発元のライブラリを使いましょう、以上のものはないかな、と思います。

ソフトウェアの世界はこれまで何度も螺旋を描いてきた

続きを読む
posted by @shibukawa at 03:09 | TrackBack(0) | 日記 はてなブックマーク - ソフトウェアの世界は螺旋を周りながら進歩している

2016年03月21日

Gopher Night #1で発表してきました

適当に作ったライブラリの紹介をしました。スライドの流れは、10数年前の、牛尾さん(当時NEC)のアジャイル原理主義のスライドのオマージュです。Goの人気ぶりを表すエピソードとして、アドベントカレンダー(3本埋まった&Goを関してない企業アドベントカレンダーでもたくさんGoの話が出てきてた)みたいなのを言おうと思ってたけどいい忘れました。あと、Goのキャラクターあざとい話で、ウルトラマンXのツインテール前髪パッツンメガネっ娘ホットパンツニーハイソックス白衣理系女子のルイルイ並にレベル高いあざとい、みたいに言おうかなとか一瞬思ったけど自粛しました。気になる人は映画館へGo!

あとは、このネタに至る道程としては、Unreal Wayの「それぞれの人が自分だけで高速にイテレーションを回せる」「プログラマーが間に挟まると、その分だけイテレーションが減る」「計画・実行までのサイクルが速いScrumであっても、1週間は要求の変更をブロックするから、それだと遅いよね」みたいなのがあったんですが、それを説明しだすと動くものを紹介するまで長くなっちゃうので辞めました。

普段サーバっぽいコードは書かないので、その点はいろいろ話を聞いて参考になりそうでした。MQとかね。そのうちちょっとやりたいなぁと思っていたので。あと、HashiCorp製のプラグインの仕組み(別プロセスでRPCでやりとりする)というのは、同じような奴をやろうとしていました。僕の方で考えていたのは、Go/Qtの通信用で、QtにあるQLocalSocket/QLocalServer互換のソケット(Windowsは名前付きパイプ、それ以外ではUnixドメインソケット)をバックエンドに使い、その上にdRubyっぽいレイヤーの簡易版(参照渡しはサポートしない)を用意して、HTTPのウェブアプリのようなパス上にオブジェクトを配置してメソッドと引数を渡すという感じでやろうとしています。Goはreflectを使って、QtはQMetaObjectのリフレクションを使ってメソッド呼び出しができるので、言語が違っても相互にやりとりできる(部分の検証はすでに済み)。Go側の実装は一通りできていて、Qt側は現在実装中です。これもそのうち公開できるかと思います。それ以外だと、SensorBeeのコードのASTをいじくるコードはなんかそのうち書いてみたいですね。

イベント主催かつ会場提供のエウレカさん、どうもありがとうございます。また次回以降のイベントも楽しみにしていると同時に、金銭的余裕があれば(キッチン内蔵の食器洗い乾燥機と、Nexus 5が壊れたり)しなければ懇親会も参加したかったです。

posted by @shibukawa at 14:30 | TrackBack(0) | 日記 はてなブックマーク - Gopher Night #1で発表してきました
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2017年11月 >>
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ