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で発表してきました

2016年03月01日

ハッカソンのゲームデザイン

ハッカソン界隈が非常に盛り上がっています。ハッカソンという言葉が一人歩きした結果だから「まあそういうことも起きますよね」としか思えないのですが、いいタイミングなので、4-5年ぐらい前から考えていたことをまとめてみます。

ハッカソンという名の対人リアルタイムシミュレーションゲーム

ハッカソンという名前がバズワードとして広まり、いろいろなイベントのタイトルとして使われています。ただ、本来使われてきたハッカソンとは意味が違ってきています。こちらにオフラインの勉強会のスタイルの分類をまとめているのですが、ハッカソンはどちらかというと開発合宿スタイル。集中的に何か動くものを作ってみよう、という形のイベントです。

@technohippyさんが良いリンクをTweetしていたのでこれも参考に貼っておきます。

一方、企業協賛のものは商品や賞金が出るということもあって、優劣を決めるイベントです。これを明確に表している分類は「コンテスト」の方が適切かと思います(数年前の感覚では)。ただ、言葉の定義というのは、神から与えられた正しい意味みたいなのはなくて、人々が使っている中で、誤用とかも含めて定着していった結果です。オリジナルの由来のみを正しいと信奉して「送り狼」を褒め言葉で使ったらたぶん友達がいなくなります。送り狼にも諸説あるみたいですが。コンテスト相当のものを「ハッカソン」と呼ぶというのはこのまま定着しそうな気はします。

「コンテスト」であれば勝敗をつけるイベントというのが明確なので当然「レギュレーション」をどう定めるのか、その中でどうパフォーマンスを出すのか、というところに参加者や審査員の意識はフォーカスします。「ハッカソン」と呼んでしまうと、「クリエイティビティを発揮しよう」みたいな印象を与えがちで、あまりルールや縛りにフォーカスしようとはしなくなるんじゃないかと思います。そういうポジティブな印象を与えたい、という主催者側の意図が「ハッカソン」という言葉を使わせている気はしますが、それが逆にハッカー気質な人がハッカソンという言葉に対してネガティブな印象を持ったり、今回の関連記事等にかかれていたように、一部の参加者「技術を発揮しないのに違和感を感じる」という悲劇につながっているのかなと思います。

ハッカソンをゲームと例えるなら、準備フェーズでスキルを成長させて相手を殴りに行くMOBAとか、RTSに近いかもしれません。この手のゲームで「この設備を最初に作っちゃえば勝ちが確定」みたいなのがあると対戦は面白くないですよね。

対戦ゲームはバランス調整が肝

続きを読む
posted by @shibukawa at 18:28 | TrackBack(0) | 日記 はてなブックマーク - ハッカソンのゲームデザイン

2016年01月10日

僕のプログラマ人生を賭けてITエンジニア本大賞2016に推薦したい本はこれ

岩切さんがITエンジニア本大賞の募集をしていました。技術書とビジネス書の2カテゴリがあるんですが、それぞれのカテゴリで、2015年に出会った本で、「やばい、これは10年以上待ち望んでた次の時代の道標になる本だ」というものがあったのですが、清き平等な一票ではこの気持ちは伝わらないと思い、筆を執った次第です。

一応僕のことをあまり知らない人も多いと思うので一応説明しておくと、学生のころに日本XPユーザグループの設立準備から関わっていて、アジャイルという言葉が出る前から「仕様書通りにしかコーディングできない世界つまらなそうだし、XPなんか面白そうだな!」と思っていて、イベント運営をしてみたり、C++やらPythonやらRuby(とちぎ)やらのコミュニティに参加したり、ドキュメントツールのSphinxのユーザグループを設立してみたり、いろいろ趣味で検索エンジンやら自然言語処理関連やらGUIフレームワークやらのOSS開発をしています。本も、アジャイル系の本の執筆や翻訳もするし、言語系の本の執筆や翻訳もしてます。昨年はWebのMVCのMithrilの本も出して、損益分岐点は超えたらしいので、ホッとしているところです。そんなバックグラウンドがある人間が推薦していると思ってこの駄文を読んでいただけたら、と思っています。逆に研究的な観点とか大規模分散とかDevOpsみたいなのは弾幕薄め(経験少なめ)です。

技術書大賞に推薦したい本はこちら!

技術書大賞に推薦したい本はUnreal Engine 4で極めるゲーム開発です。もうこれはあらゆる面で圧倒的でした。

ゲーム開発系の人はもうこの本の背景とかは説明せずともいいと思うので、ゲーム畑以外の人向けにこの本の技術面での凄さを伝えたいと思っています。凄さは大きく2つに分かれていて、この本がターゲットとしているUnreal Engineそのものの凄さと、懇切丁寧なまでにそれを伝える著者の凄さの両面があります。

SI系の人たちがずっと待ち望んできた世界を(10年前から)実現してしまっていたUnreal Engineの解説

続きを読む
posted by @shibukawa at 01:27 | TrackBack(0) | 日記 はてなブックマーク - 僕のプログラマ人生を賭けてITエンジニア本大賞2016に推薦したい本はこれ

2015年10月29日

プライベートを犠牲にして勉強することについて、5年前に考えたこと

プライベートを犠牲にして勉強することの可否についてのブログエントリーが話題になっています。JavaScriptは3ヶ月おきぐらいに新しいフレームワークやツールがでてきてワイワイ盛り上がっています。「勉強しなきゃ」「新しい物に最近触れてない、やばい><」みたいに追い立てられてしまう気持ちもよく分かります。

もう5年ぐらい前になりますが、つまみぐい勉強法という本を@nomicoxさんと一緒に書いて技術評論社から出版しました。当初から「すぐに陳腐化するような話は書かない」という企画で書いたおかげか、ジュンク堂の長田さんに今月聞いた所によると、ジュンク堂の池袋店では細く長く売れ続けていて、そろそろ出版社の在庫も無くなりそう、とのことでした。ありがたいことです。5年経っても、定期的に本に書いているようなことが話題に上がるので、本を書いたのはムダじゃなかったし、改訂も必要はなさそうです。

書き始める前のミーティングで話が出たのがまさに「勉強会ブームにおける勉強会疲れ」の話です。当時は「勉強会いいよ」ということを紹介する本も一冊もなく(その後直前に一冊出ましたが、勉強会に出れば本を買わなくてもいいよというアレゲな本でした)、勉強会について紹介することになったのですが、当時から問題になっていたのが勉強会疲れでした。勉強会に出れば出るほど、逆に勉強できてない人が多いのでは?ということです。そんなことも考えて書いた本です。

家庭とのバランスについても触れています。僕のコミュニティデビューは大学時代で、XPユーザグループとかでは経験は出せない代わりに、時間を出して貢献しようと走り回っていました。また本の出版当時は働いていましたが独身でした。ずっと不思議だったのは、アジャイル系のコミュニティを引っ張っている人たちは結構家庭持ちが多く、子供も3人以上で多かったりしつつも家族を大事にするようなお父さんたちだったので、「僕よりも可処分時間が少ないのにどうやってコミュニティに対して時間を捻出したり、勉強したり、本や雑誌を書いているんだろう?」というのが疑問だったので、多くの家庭を持つ人にアンケートを取ったりして一章まるごとその話題について説明しています。

元のブログは「IT(というよりウェブ系?)」「勉強」という文脈だったんですが、もっと広い文脈で考えていこうと思います。

仕事外の時間を使う活動

続きを読む
posted by @shibukawa at 13:26 | TrackBack(0) | 日記 はてなブックマーク - プライベートを犠牲にして勉強することについて、5年前に考えたこと

2015年09月23日

iOSの広告ブロックの今後を考えてみる

iOS 9でリリース後の話題をさらったのは広告ブロックが許可されたことですよね。実際に広告ブロックを入れるような人はクリックすることもなく、アクティビティが低いから広告主のためにもならないから広告ブロックをした方が良い、という意見もあります。とはいえ、今後の可能性としてはそう穏やかに終わらない可能性もあると思っています。

僕自身は変な広告を見るのが好きだし、Facebookの居住地はUSのままにしているので「英語圏だと、こういう広告で攻めてくるのかー、これは面白いな」みたいな気づきもあるので、入れることはありませんが可能性をいろいろ考えてみました。僕は広告の専門家ではないので、用語とか変なところがあるかもしれませんが、ご容赦ください。

一番穏やかなケース

広告を表示するものの、クリックする確率が低いユーザが減りました。出稿した広告数に対するクリック数が増えて、広告を出す費用に対して広告効果がアップしました。めでたしめでたし。

難易度ハード

続きを読む
posted by @shibukawa at 21:35 | TrackBack(0) | 日記 はてなブックマーク - iOSの広告ブロックの今後を考えてみる

2015年09月15日

SIerの未来は明るい?

XP祭り2015に参加してきました。スタッフの方々お疲れ様でした。今回は、あまり外に情報が出てくることがないと思われる、社内SE業で成果を出すために実践してきたことを発表してきました。

前のブログのエントリーでも書きましたが、今回考えさせられたのが岩切さんの発表の「在庫切れのメカニズムの原因となる事象を把握していたのが、社内の情報部門の人間だけだった」ということです。また、その後の質疑でも、「金融系もそうだった」という話が出ました。ここで説明したいと思っていたのが「業務はどんどん狭く深くなる」ということですが、内容が膨れてきたので前のエントリーに分けました。

だいたいビジネス書とかで語られているような仕事効率の基本原則は、同じ時間で成果を上げるためには、儲かる部分にフォーカスして儲からない部分は削るということです。時間あたりのビジネスの効率があがれば、忙しさを抑えてインカムも増えてハッピー、歩合制の仕事であれば、空いた時間でさらに多くの仕事をこなせて2倍美味しい、というストーリーです。実際には、サラリーマンだと後者のインセンティブはなかったりもしますが、だいたいそんな感じの内容が多いですよね。

儲からない部分を削るには、うるさいだけでお金を出さない客を切るということと、定型的な仕事は自動化/省力化するという主に2つの方法があります。省力化/自動化は脳の力をなるべく使わない(脳で酸素をムダに使わない)方法と言い換える方法がありますが、コンテキストスイッチを減らしたり、繰り返しのルーチンワークを効率化したり、情報の伝達のムダを減らすにはコンピュータが活用があります。企業としても利益率向上は存在理由に直結する部分なので、がんばる時間を設定したり、ITに投資したりして改善をします。分業を徹底的に行なって1つのタスクにフォーカスして成果をどんどん上げる、そして他の人との情報のやりとりは必要最低限にフィルタリングされて、余計な情報に煩わされることはない、という姿が理想型でしょう。

企業が意思を持ってそのような変革をしなかったとしても、仕事をする中でそのような方向への変革のフォースは常に発生しています。Aという仕事が得意な人と、Bという仕事が得意な人が同じチームにいれば、自然と分業されていきます。「相手を信頼して任せる」「現場に権限移譲」が成功の秘訣です。

このように業務内容が変わらないと想定しても、分業は進んでいくと考えられますが、競争力を保つためにより高度な仕事の仕組みを作り上げていったり、高度な商品の開発を行っていくと、仕事はどんどん深くなっていきますし、1人が面倒を見切れる範囲には限界があるので、その分対象は狭くなって専門化していきます。これは前回のエントリーで書いたことです。

ドメインエキスパートはどこにいる?

続きを読む
posted by @shibukawa at 23:53 | TrackBack(0) | 日記 はてなブックマーク - SIerの未来は明るい?

2015年09月13日

仕事はどんどん狭く深くなる法則

XP祭り2015の感想を書き始めたのですが、脱線した内容が爆発してきたので、単独のエントリーにしました。その感想で紹介しようと思っていたのが、僕がぼんやり考えてきたことで「業種問わず、仕事はどんどん狭く深くなる」ということです。

例えば、ソーシャルゲーム業界は、どこもガラケー時代に比べて利益率が落ちていますが、これは必然です。これは、ファスト&スロー(上) あなたの意思はどのように決まるか? に書かれている、「平均回帰」で説明できます。少ない手間でたくさん利益を生むような「金鉱」的な市場が開拓されたとします。その初期にはたくさんの好収益企業が出てきます。チャンスを狙って多くの会社が新規参入してきますし、コンソールゲームを出すよりも利益いいんだったら、こっちに参入したほうがいいよね?みたいな話も出てくるでしょう。そうなるとプレーヤーが増えてきます。

そういう中で売上上位を獲得するにはどうすればいいでしょうか?それは開発期間をかけてよりゲームとして深みのあるシステムを組み込んだり、デザイナーを多数起用して美しいグラフィックを隅から隅まで配する他ないでしょう。幸い、スマホの性能はガンガン上がっているため、コストに見合うビジュアルは出せます。そうして開発費が高騰すれば利益率が下がっていきます。最近では広告の投入も必要です。で、他のゲーム開発と同程度までは落ちる可能性があります。もちろん初期には(今でも少しは)変化球なゲームが突発的に人気になったりしますが、アイディア一発だと類似ゲームも出しやすいので、よっぽど真似しづらいブランドを獲得しないと(マンボウとか、ねこあつめとか)同じく平均回帰が起きます。

続きを読む
posted by @shibukawa at 23:29 | TrackBack(0) | 日記 はてなブックマーク - 仕事はどんどん狭く深くなる法則

2015年08月07日

世界最速でMithril本をリリースした話

DSC_5516

オライリー・ジャパンから、Mithrilの本を出しました。今まで本は何冊も出してきましたが、今回が初の単著です。O'reilly Authorの帽子もいただきました。出版にあたってはいろいろな方々にお世話になりました。ありがとうございました。もちろん、購入していただいた方、興味をもってシェアしていただいた方々もありがとうございます。

ちょっとお酒が入って酔っぱらっている状況ですが、本について紹介しようと思います。

Mithrilのどこに惹かれたのか?

続きを読む
posted by @shibukawa at 02:38 | TrackBack(0) | 日記 はてなブックマーク - 世界最速でMithril本をリリースした話

2015年05月22日

HTTP/2とES 6 Modulesで、concatはいらなくなるのか?

サーバーサイドpushはまあ現実的に使えるのか難しいよね、サーバーサイドpushに夢求めすぎてたよねっていうのは一度は誰もが経験するところではあって、みんな夢は覚めたと思うけど、場合によっては使えるかもねと思うケースは1つあります。起点となるhtmlの最終更新日を見てそれよりも新しいファイルがあれば一括で送りつける、というのは可能かもと思います。サーバ側でシーケンシャルな日付のリストを用意しておけば難しくないですし。ただ、ダウンロード失敗等を考えると、前回ダウンロードに成功したファイルの中の一番新しいファイルの更新日時を送ればより安全かなぁ、と思います。index.htmlがサーバで動的生成されるファイルだとまた話はややこしいのですが・・・まぁ、確実でムダのないサーバーサイドpushは難しいですよね。上記のブログに書かれている手法で本当に行けるのかな?と思うてんを列挙します。

ファイル一覧をダウンロードする方式でES6 Modules使えるのか?

続きを読む
posted by @shibukawa at 20:48 | TrackBack(0) | 日記 はてなブックマーク - HTTP/2とES 6 Modulesで、concatはいらなくなるのか?

2015年03月24日

cURL as DSLとは何だったのか。あるいは細かすぎて伝わらないcURL as DSL。

DSL Internet Access
By Jeremy Brooks under CC BY-NC

先日、cURL as DSLというツールを公開しました。その後、何度も同じような質問を受けたりしたので、ブログにまとめてみます。

なぜこのツールを作ったの?

RESTfulというものは大分一般的になってきました。HTTPでAPIを提供というのもよく見かけます。ですが、僕はこのRESTfulというやつが嫌いです。

GETのURLをシェアすればいつでも同じページがある(変な状態を持たない)、みたいな思想はいいんですが、HTTPのAPIはどうも使いにくい。ドキュメントのHTTPのサンプルを見て、ドキュメントをじっくり読み込んで、パラメータをJSONやらXMLで組み立ててボディに乗っけて(しかも大抵パラメータがアホのように多い)、いろいろ決められたルールで認証してヘッダに埋め込んで・・・・ちょっとでも違うと、400しか返してくれないとかザラです。どこがうまくいかないのかきちんと情報を返してくれればいいんですけどね。やりたいこと(機能を1つ呼び出す)に対して、そこまでなかなか遠い。だいたい、ここを読んでいる人たちも、RESTful APIと、自分が使っている言語(RubyでもPythonでもnode.jsでも)のクライアントライブラリの両方があったら、迷わず後者を選びますよね?RESTful APIを触っている時の気持ちは、libffi経由でCで書かれた共有ライブラリを呼び出しているのと似ている気がします。で、バリデーションは送信側にしろ受信側にしろ、出て実装しないといけない。

だいぶ前にやったXMLRPCの方がまだ開発のしやすさは圧倒的に高い。また、WSDLとか、CORBAとか、我々人類はもっと便利なものを一度は手にしたのに、なぜ退化しちゃっているのか?ブラウザ主体だと、JSができることがメインとならざるを得なくて、それでXMLHttpRequestとかjQueryのAjax APIなんかで扱いやすい仕組みとしてRESTfulが主流になってきたのかなぁ・・・とか考えていますが、実際のところはよくわかりません。

RESTful時代にドキュメントとして書かれるのはHTTPのテキストと、たまにcURLコマンドです。それらのドキュメントの中にある情報の断片でクライアントが作れれば、試行錯誤の回数は確実に減ります。人間向けのドキュメントを機械が読んでくれたらうれしいですよね?本当はセマンティックウェブを実現しているSphinxのhttpドメインを使いたかったんですが・・・

とは言え、便利に使いたい、というだけであれば、Swaggerもあるし、これの開発を初めて、1-2個の言語出力ができるようになった時に、GoogleがgRPCを発表しました。使えるのであれば絶対にこっちの方がいいと思います。インタフェース生成の仕組みのお陰で、送信前に変なリクエストは事前に除外できますし、バリデータを自分で書かなくてもいいし、開発の効率は良いと思います。

用途としては、ウェブアプリのテストとか作るのが簡単になったらいいなぁ、とちょびっと思っています。

GolangのHTTPのAPI

続きを読む
posted by @shibukawa at 03:21 | TrackBack(0) | 日記 はてなブックマーク - cURL as DSLとは何だったのか。あるいは細かすぎて伝わらないcURL as DSL。

2014年11月19日

iOSはなぜAndroidの半分のスペックでも快適なのか

この記事が突っ込みどころが多いと話題になっています。初期の頃はiOSのなめらかな動きと比べたらAndroidは劣化版と言われても反論できない感じでしたが、Nexus 4/Nexus 5ともなるとだいぶ快適で乗り換えても違和感なく使えるようになりましたが、同じぐらいの快適さが得られるハードウェアを比べてみると、メモリも半分で、コア数も半分で、クロック周波数も半分で、バッテリーにやさしいハードウェアになっていることは確か。なぜそれでやっていけるのか、ということについて僕なりの理解をまとめます。元の英語記事は読んでません。

メモリ管理方式の違い

Androidはマーク・アンド・スイープ方式のGCで、iOSはNSAutoreleasePoolにしろ、ARCにしろ、基本的にリファレンスカウントです。リファレンスカウントはプリミティブなGCです。マーク・アンド・スイープは処理全体を止めるので、あまり発生させたくないです。そのため、同じようなプログラムを実行して同じようなユーザ体験を得るためにメモリを多めに積んで置いてGCさせないようにするのはあるかと思います。また、断片化したメモリの対策もないので、徐々に性能が落ちると評判でしたし。あと、Androidは2.3あたりからコンカレントGCが入ったという記事を見かけます。コンカレントGCだとGC用スレッドが別に動くのでマルチスレッド性能もしくはCPU速度が欲しくなりますよね。

Android 5.0だとパーシャルマーク・アンド・スイープでGCが改善して停止時間が短くなっていたり、断片化の解消の機能が入るらしいので、少ないメモリで動かした時の快適さは改善するんじゃないでしょうか。

VM方式か、ネイティブ方式か

Androidは長らくDalvik VMでした。iOSは、C言語にオブジェクト指向ランタイムを乗っけたObjective-C。ネイティブの方が当然パフォーマンスは良いのでクロック周波数を無理にあげなくても大丈夫です。VM方式はそのままでは遅いのでJITを使って高速化を行います。こうすると、バイトコードと同じ役割のネイティブコードがメモリにいたり(確証はないけど、たぶんバイトコードの開放はしてない気がする)、JITするホットスポットを見つけるためのログを保存したり、JITコンパイラ自身がメモリにいたり、メモリにはやさしくないことは確か(そこまでメモリは使わないという話も聞くけど)。また性能もネイティブに比べると劣る。

Android 5.0から事前コンパイルをするARTが搭載されます。中間コードをネイティブにする方式と、最初からネイティブだと、後者のほうがまだパフォーマンスは良いとは思いますが、ベンチマークの性能もだいぶ上がっているとのことなので(自分では測ってない)、CPUのクロックをもっと下げても快適な動きをするようになると思います。記事によってはメモリ消費量は犠牲になるという気になることを書いているのもあるので、まだiOSの方が多少は有利だと思いますが。

バックグラウンドタスク

Androidの方がバックグラウンドでやれることが多く、iOSの方が少なかったので、コア数やメモリが少なくても問題なかったというのはあると思います。メモリが半分というのはここが一番大きな差かな、と思っています。ただ、iOSも少しずつこのあたりの機能が増えてますし、どちらも通知機能がリッチになっていく方向に進化しているので差は減ってくると思います。

解像度

Retinaを打ち出したAppleの方が最初でしたが、その後はAndroid勢の方が解像度アップに積極的で、Full HDはおろか、MacBook Pro 13 with Retina並みの解像度の端末まで出てくる始末。解像度って液晶の消費電力にも影響あるし、メモリも食うし(VRAMが別にあれば問題ないと思うけど)、GPUの負荷もあがります。当然性能にも影響あります。直近の例だと、Nexus 9とShield Tabletですね。同じTegra K1だけど、解像度が小さいShield Tabletの方がフレームレートが上がります。算数の世界の話。

個人的にはiPhone 5の細かさで全然問題ないので、これ以上上げないで欲しいです。

まとめ

スペックに影響がありそうなところを適当にピックアップしました。これ以外にも、3GS時代にはAndroidにはストレージ速度の問題がありました。Galaxy S初代と3GSでは体感で倍以上違う感覚がありました。その分、データを事前にメモリにロードしておかないと、みたいな作りが必要でした。また内蔵メモリが少なくて、より低速なSDカードを使わせる機種も多かったですからね。今どきはそこまでストレージ速度に差はないみたいです。

元記事見てもiOSにメモリが1GBしかない理由がかかれてないというツッコミもありますが、どちらかというと、Androidが性能差を埋めるために必要なメモリ量が2GBでした、という方が近いのかなという気がしました。今後のARTのこなれ具合と、64ビット化でこの差がどれだけ縮まるのかは個人的に愉しみにしています。

posted by @shibukawa at 13:17 | TrackBack(0) | 日記 はてなブックマーク - iOSはなぜAndroidの半分のスペックでも快適なのか

2014年10月27日

SphinxCon JP 2014でOktaviaの宣伝してきた

スタッフ、会場提供のVoyage Groupさま、参加者のみなさま、お疲れ様でした。スライドのビュー数も一晩で2300超えと、今までSlideshareに上げたスライドの中では一番伸びがいい気がします。PyCon JPの時の発表を日本語で再演するのでいいから出てください、と言われてたのですが、末永さんの検索本もちょうど直後に出てて説明省けたし、転置インデックスの検索の説明はざっと削って、あらたに進捗をちょびっと足しました。

イベントの前に、こんなリポジトリをでっち上げました。Markdown形式でOSSライセンス文を集めたリポジトリがあったので、手でフォーマットを直しました。Sphinxで何かしらのツールのドキュメントを書くときは、この中のファイルをコピーして入れるとお手軽ですね。LICENSE.rstという名前で入れておいて、index.rstに .. include:: LICENSE.rstを入れておくのが僕のマイブームです。後から考えれば、PanDoc使えばよかった!

パフォーマンスチューニング

続きを読む
posted by @shibukawa at 21:40 | TrackBack(0) | 日記 はてなブックマーク - SphinxCon JP 2014でOktaviaの宣伝してきた

2014年09月19日

Qtにもパッケージマネージャが欲しい

JSXのパッケージマネージャ(npmへのあいのり)対応のパッチを書いたりもしましたが、今どきのプログラミング言語ではパッケージマネージャは必要不可欠なインフラだと思います。Qtももっといろいろなコードが流通するといいと思うのですが、いまだに、昔ながらの強力なコアAPI + 人力で努力みたいなノリなのかなぁ、と思ったり。欲しいのは、パッケージというかモジュールというかライブラリの流通インフラ。以下妄想。モデルはnodeのnpm。

  • qpm(仮称)コマンドで、必要なライブラリを取得。
  • システムのフォルダには手を加えない
  • qt_modulesフォルダにファイルが入る。孫依存もフラットに並べる。
  • qt_package.jsonに依存関係が書かれる。依存は、ビルドに必要、ライブラリの利用にも必要の2種類。
  • パッケージは基本的にgithubに置く。ブランチ、タグで指定
  • ブランチとタグはgithub APIで取得可能。タグブランチ
  • バージョンは、メジャー、マイナー、パッチを指定することである程度柔軟な組み合わせができる
  • パッケージはソースコード(gitリポジトリチェックアウト)、バイナリ(リリース)のどちらかで提供。
  • パッケージには、追加すべきファイル情報を持つ。
  • アプリのプロジェクトのルートは必ず、subdirs形式。その中に同名のルートのプロジェクトが入る。
  • ビルドが必要なソース形式のパッケージは、ルート直下にライブラリのプロジェクトとして追加。
  • ルートのプロジェクトの.pro、アプリのプロジェクトの.proは、qpmが作るをインクルードする。このファイルは機械生成で、依存ファイル利用に必要な情報などをすべて含む

なんとなくできそうな気はしてきた。パッケージ作成支援の部分もうちょっと考えると良さそう。configure使うのは、パッケージマネージャがかわりにビルドというのも手かなぁ。

追記 9/27

  • 静的リンクもしくはソースコードとして提供するなら、subdirsじゃなくてもいい。階層構造じゃない素の構成の方がわかりやすいかな。
  • ソースコード提供はqt_modules内にgit cloneが良いかも。パッチ当ててpull request出したりしやすい
  • git ls-remoteで、cloneしなくてもリポジトリのタグとかブランチ情報は取ってこれる
  • ファイル形式は.jsonじゃなくて.iniにしたい。コンフリクトに強いし、素のQtで扱える。
posted by @shibukawa at 11:53 | TrackBack(0) | 日記 はてなブックマーク - Qtにもパッケージマネージャが欲しい

2014年09月18日

PyConJP & 引っ越し

久しぶりにPyConJPに参加しました。きけば500人を超える人数とのこと。石本さんのブログによれば、10年前のPyConが400人ということで、それよりも大きな人数を集めたというのはすごいですよね。日本の10年前のイベントでは、仕事で使っている人はごく少数で、多くの人はPythonに興味があって、いつか仕事で使いたいなぁと夢見る若者たち(ほぼ男性)だったのが、今回は実際に使っている人たちが大勢集まっていました。大きなカンファレンスなんだけども、当初のグループのメンバーというだけでオリジナルの趣旨とは全然違う話題も取り込むことで延命しているイベントもあり、なおかつ知名度と情報量と書籍の量で国内ではRubyが圧倒的な中、Python 100%でここまで大きなイベントができるというのは10年前は想像できませんでした。タカノリさん、寺田さんをはじめ、多くの方々の頑張りに拍手です。

Oktavia

僕が発表したのは自分で作った検索エンジンですが、ブラウザ上で動かしたいという偏った同期からスタートしているのであまり一般的な題材ではなかったと思います。なんとか前日にPython版をPyPIにリリースして、発表資料も一晩で作り上げて、原稿も作らず練習もせずに英語でぶっつけ本番ながら、時間を枠内に収めることができました。欧米圏の人に、アジアの言語だと検索のアルゴリズムそのままだとツライんだよ、というのを説明するのが第一の目的でしたので、一応自分としてはそこはクリアしたつもり。

数年前のPyConJPと比較して、客層が大きく変わった気はしましたが、ウェブ系の人の人数はそのままに、データ解析系の人がプラスで追加された感じでした。セッションも、データ系とか機械学習の数が多くて人気そうでした。一方で、Pythonのコアとか処理系に対する話とかはそれほど数が多くなく、毛深い(Python用語)発表の割合は減ったかなぁという気がしました。

僕自身、最近は仕事でもPythonを書くことがなくて、たまにちょこちょこ趣味コードを書くぐらい。PyConJPの客層のメインストリームからは外れた気がしました。とはいえ、触り始めが古いだけの人が幅を利かせているのは健全ではないし、外れること自体は正しいことなので、この勢いで、現在Pythonと触れる機会の多い人がどんどん進出して、めだって、活躍して欲しいと思います。Python界の新アイドルも出てきましたし、Pythonの未来は明るいです。ラーメンの大盛りを注文しては後悔するような年齢になってしまったおじさんは、今後はポスターセッションか何かで、実用とはほど遠いかもしれないマニアックなネタで細々と生きていこうと思います。あと、The History of Pythonもきちんと訳さないとなぁ。来年のPyConJPまでに。

10月はSphinxConもやりますよ。Sphinxオンリーイベントが開かれるのは日本だけ!

引っ越し

日本に帰ってきて、不動産屋に行ったり下見をしたりして家を決めたまではすぐだったのですが、2ヶ月ぐらいたってようやく入居しました。まだ開けてないダンボールもいくつかありますし、ちょこちょこメンテのために業者に来てもらったり、表札の完成待ちだったり、タスクはいろいろありますが、だいぶ快適です。スペックは、丘の上の中古の庭付き一軒家です。4人家族の広さだと、家賃補助をプラスしても渋谷周辺は高くなってしまうし、買ってしまったほうが月々の支払いがだいぶ少なそうなので買いました。駒込時代よりも2.5倍の広さで月々の支払いはほぼ同じで通勤時間はそれほど変わらずです。ウィッシュリストはこちらです。そのうち、親しい仲間を呼んで、ハウスウォーミングしたいですね。

posted by @shibukawa at 01:40 | TrackBack(0) | 日記 はてなブックマーク - PyConJP & 引っ越し

2014年07月30日

「納品をなくせばうまくいく」を読みました!

著者の倉貫さんから、「納品」をなくせばうまくいくの献本をいただきました。ありがとうございます。

日本人の日本人による日本人の顧客のための本

今まで出ていたソフトウェア開発方法論の関連の書籍の多くは、英語から翻訳された本でした。また、基本的にメインの想定読者はソフトウェア開発側のメンバーです。当然、ソフトウェア開発者の言葉を使って書かれています。翻訳者もみなプログラマ側のメンバーでした。もちろん、読んではいけないということはないし、読んでもらった方がメリットがある本も数多くありますが、必要な部分とそうじゃない部分をうまく切り分けつつ、欧米の文化と日本の文化の違いを考慮に入れつつ、自分の立場に合わせて情報をカスタマイズしつつ読むのは簡単ではないでしょう。

本書は、徹底的に「日本のお客様」視点に立って書かれている本です。「ソフトウェアがビジネスに必要なのは分かるんだけど、ソフトウェアの開発とかわからんし、エンジニア雇うのも簡単じゃないし、ぼったくられたらいやだ」という日本の顧客むけです。実際のお客様の言葉なども盛り込んであって、お客さんの不安を解消し、成功しそう(失敗しなさそう)という気持ちになってもらう、という姿勢が徹底されているなと思いました。

アジャイル本として

続きを読む
posted by @shibukawa at 01:46 | TrackBack(0) | 日記 はてなブックマーク - 「納品をなくせばうまくいく」を読みました!
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2016年12月 >>
        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 31
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ