冥冥乃志

ソフトウェア開発会社でチームマネージャをしているエンジニアの雑記。アウトプットは少なめです。

follow us in feedly

2016年8月の読書メモ

MPの制約が緩くなったので、何がしたいのかってくらい読んでしまいました。Kindle Unlimitedと図書館が悪い。

今月の読書量

22冊、だと。。。

野田と申します　1巻

野田ともうします。（１） (Ｋｉｓｓコミックス)

野田ともうします。（１） (Ｋｉｓｓコミックス)

スター・レッド

スター・レッド (小学館文庫)

スター・レッド (小学館文庫)

私の恋人

私の恋人

私の恋人

春の呪い

春の呪い: 1 (ZERO-SUMコミックス)

春の呪い: 1 (ZERO-SUMコミックス)

銀河鉄道の夜

銀河鉄道の夜

銀河鉄道の夜

ペンギン・ハイウェイ

ペンギン・ハイウェイ (角川文庫)

ペンギン・ハイウェイ (角川文庫)

世界から猫が消えたなら

世界から猫が消えたなら

世界から猫が消えたなら

図解ピケティ入門

【図解】ピケティ入門 たった21枚の図で『21世紀の資本』は読める!

【図解】ピケティ入門 たった21枚の図で『21世紀の資本』は読める!

世界で戦うプロダクトマネジャーになるための本

世界で闘うプロダクトマネジャーになるための本　トップIT企業のPMとして就職する方法

世界で闘うプロダクトマネジャーになるための本　トップIT企業のPMとして就職する方法

ゆらぎの森のシエラ

ゆらぎの森のシエラ (創元SF文庫)

ゆらぎの森のシエラ (創元SF文庫)

コンピューターは、むずかしすぎて使えない

コンピュータは、むずかしすぎて使えない!

コンピュータは、むずかしすぎて使えない!

パタリロ　1～2巻

パタリロ!―選集 (1) (白泉社文庫)

パタリロ!―選集 (1) (白泉社文庫)

パタリロ!―選集 (2) (白泉社文庫)

パタリロ!―選集 (2) (白泉社文庫)

ダンジョン飯　三巻

ダンジョン飯 3巻 (ビームコミックス)

ダンジョン飯 3巻 (ビームコミックス)

ランド　三巻

ランド(3) (モーニング KC)

ランド(3) (モーニング KC)

建築家が見たマンガの世界

建築家が見たマンガの世界 「よつばと! ・ジョジョの奇妙な冒険・ヱヴァンゲリヲン新劇場版・ペルソナ4 の経済編」

建築家が見たマンガの世界 「よつばと! ・ジョジョの奇妙な冒険・ヱヴァンゲリヲン新劇場版・ペルソナ4 の経済編」

トーマの心臓

トーマの心臓1 萩尾望都Perfect Selection 1 (フラワーコミックススペシャル)

トーマの心臓1 萩尾望都Perfect Selection 1 (フラワーコミックススペシャル)

BONES

BONES ― 動物の骨格と機能美

BONES ― 動物の骨格と機能美

屍者の帝国

屍者の帝国 (河出文庫)

屍者の帝国 (河出文庫)

沈黙

沈黙 (新潮文庫)

沈黙 (新潮文庫)

やつがしら

やつがしら

やつがしら

旅したら豆腐メンタルなおるかな？

旅したら豆腐メンタルなおるかな？ (コミックエッセイの森)

旅したら豆腐メンタルなおるかな？ (コミックエッセイの森)

モザイクラセン

萩尾望都作品集 (〔第2期〕-15) モザイク・ラセン (プチコミックス)

萩尾望都作品集 (〔第2期〕-15) モザイク・ラセン (プチコミックス)

今月のベスト本

「ペンギン・ハイウェイ」一択です。読後も爽やかだし、成長に伴う痛みもよく描かれているし、何より周りの大人がかっこいい。森見登美彦は今まで読んでなかったけど、これから読んでいこうと思いました。

第2回 【岡山】 Atlassian ユーザーグループ 中国地方で発表してきました

augca.connpass.com

まとめはこちら。

togetter.com

スライドは一部出していいのかダメなのかわからないところがあるので、現時点での公開は差し控えたく候。

セッションについて

「Atlassianという言葉が入ってれば、何をやっても良い(誤読」とのことだったので、年末の内容をブラッシュアップしてセッションしました。まあ、スライドの使い回し部分はほぼ前説に相当する部分のみですが。一番言いたかったことは、

ツールは選択に過ぎないから、自分たちでちゃんと選べるチームになろう

ということに尽きると思います。

勉強会について

他のセッションはデモを盛り込んでいたので、Atlassianツール同士の連携の良さを見ることができました。目がGithubやredmineに慣れているので、少しデモが早かったですが。JIRAを軸に開発だけではなくて、ビジネスのライフサイクルを回すツールの展開をされているんだな、と感じました。

Portfolio欲しい

デモでは触れられなかったんですが、セッションを聴きながら公式サイトを見てたらPortfolio for JIRAというのを見つけて、俄然欲しくなりました。

ja.atlassian.com

長沢さんもブログで紹介されていますね。

www.evangelism.jp

完全に私が下記エントリでやろうとしてたフローと情報をカバーしてます。

mao-instantlife.hatenablog.com

今までの転記やキャッチアップの人的コストはなんだったんだという。。。いや、もう、買い切りライセンスあるし、チームの人数少ないし、これができるんだったら個人の財布からでも良いよ(デブサミ関西終わってから。

Neo4Jの検証メモ

Programming

SpringBoot 1.4が対応したみたいなので、これから先に予定している機能のこともあり、用途の検討も含めて少し使ってみました。なお、SpringBootからの利用ではなく、Neo4Jそのものの検証です。

そもそもNeo4Jとは？

大体以下から大まかに抜粋。

neo4j.com

Neo4j - Wikipedia

レコード(Neo4J的にはNode)と関連のグラフ構造でデータを表現するグラフデータベースです。データ構造がリレーションモデルではないので、当然系譜的にはNoSQLなわけですが、他のNoSQLとは違ってKeyValue形式ではないのが特長です。

で、他のグラフデータベース(ぶっちゃけ他に何があるか知りませんが)と違うのは、

といったあたりで、Enterprise Editionの可用性とともに、この辺結構プッシュしてた感じです。

ライセンス的にはCommunity EditionとEnterprise Editionがあります。クエリエンジンや基本的なデータベースとしての機能において両者の違いはなく、クラスタリングやキャッシュなどの運用面において違いがあるようです。なお、Community Editionは無料。

使ってみての諸々

インストールはダウンロードして展開してアプリたちあげるだけなので割愛。特に困ったことはありませんでした。

基本

先ほども少し触れましたが、データモデルは「ノード(Node)」「コネクション(Connection)」で表されます。ノードとコネクションのデータ構造管理とクエリ発行がグラフデータベースシステムの役割です。

ノード

今までのRDBMSで言えばレコードに相当します。考え方としてタイプよりもインスタンスを元に作成されるので、レコードほどスキーマ基準の考え方をしなくてもいいようです。

ノードは属性とラベル(グルーピングのために使ったり、スキーマっぽく処理したり)を付与することができます。ノードの属性に指定可能なタイプは以下の通りです。

  • boolean
  • byte
  • short
  • int
  • long
  • float
  • double
  • char
  • string

Javaで作られているので、この辺は基本的にJavaと一致すると思えば良いかと。

コネクション

ノードとノードを結ぶ関係のことで、RDBMSなら外部キーやら制約やらに相当するかと思いますが、Neo4Jではコネクションそのものに値が持てます。コネクションもインスタンスベースとなるので、ラベルなどによるグルーピングはできますが、厳密なスキーマ運用はシステム上ではしていないです。

インデックス、トランザクション

構文やプロシジャのサンプルにもありましたが、今回は使っていません。全文検索インデックスもある模様。

Neo4J用クエリ Cypher

御本尊はここ。

neo4j.com

細かいシンタックスに触れると単に公式ドキュメントの引き写しになるので、使ってみたときのハマりどころとか気づきを主に。

ノードとコネクションのCRAETE

例えば、知り合い同士の関連を表す場合(公式のサンプルから引っこ抜いてきました)。

CREATE (js:Person { name: "Johan", from: "Sweden", learn: "surfing" }),
(ir:Person { name: "Ian", from: "England", title: "author" }),
(rvb:Person { name: "Rik", from: "Belgium", pet: "Orval" }),
(ally:Person { name: "Allison", from: "California", hobby: "surfing" }),
(ee)-[:KNOWS {since: 2001}]->(js),(ee)-[:KNOWS {rating: 5}]->(ir),
(js)-[:KNOWS]->(ir),(js)-[:KNOWS]->(rvb),
(ir)-[:KNOWS]->(js),(ir)-[:KNOWS]->(ally),
(rvb)-[:KNOWS]->(ally)

(js:Person { name: "Johan", from: "Sweden", learn: "surfing" }) がノード、 (ee)-[:KNOWS {since: 2001}]->(js),(ee)-[:KNOWS {rating: 5}]->(ir) がコネクションの定義です。

  • ノードのシンタックス： (value:Label {属性1:値,属性2:値})
  • コネクションのシンタックス： (ノード条件)-[value:TYPE {属性:値} ]->(ノード条件)

コネクションのノード条件については省略可能で、シンタックスはノードと同じ、条件の value 以外は省略可能です。

ノードもコネクションもクエリ投げる時の注意点は value で、同一ステートメントの中でしか有効じゃありません。というか、ノードに value で名称がつくわけではないようです。これに気づかずにつまんないハマり方をしまして、一度CREATEでノード作った後に別のステートメントでコネクション作ろうとして同じ value 指定してCREATE投げたら、当然別ステートメントだから参照されず、目的のノード間に対するコネクションが作られず、宙ぶらりんな謎ノードがこれでもかと作られました。

というわけで、一度作ったノードに新しくコネクションを貼るときには、MATCH とCREATE を組み合わせて使いましょう。

すでにノードが存在する可能性があるときはMERGEを使います。検索してみて、見つからなければCREATEしてくれます。

スキーマレスなので、属性のあるなしでエラーは多分出ないです。ぶれても大丈夫。

検索の基本、MATCH

ノードとコネクションの関係を表すパターンで検索をします。

ノードの条件検索

ノードに設定された名称を条件に検索します。

MATCH (ee:Person) WHERE ee.name = "Emil" RETURN ee;

コネクションのパターンから検索

ある条件のノードと KNOWS という関係を持つノードを検索します。ルートになるノードに検索条件をつけます。

MATCH (ee:Person)-[:KNOWS]-(friends)
WHERE ee.name = "Emil" RETURN ee, friends

RETURN は複数の項目セットを返すことができます。

コネクションのパターンは一つで終わらせる必要はありません。友達の友達から趣味が合いそうな人をお勧めするみたいなクエリも書けます。

MATCH (js:Person)-[:KNOWS]-()-[:KNOWS]-(surfer)
WHERE js.name = "Johan" AND surfer.hobby = "surfing"
RETURN DISTINCT surfer

関連の長さを指定するパターン

関係の本数が3以上で5を最大とする関連、みたいな長さを基準にしたパターンも可能。

(a)-[*3..5]->(b)

実行計画(PROFILE or EXPLAIN)

クエリに PROFILE や EXPLAIN をつけると実行計画を出してくれるようです。

ユーザ定義プロシジャ

Neo4Jではユーザ定義プロシジャーを作って CALL で呼ぶこともできます。必要なAPIはmavenリポジトリで公開されていて、Javaのクラスで作ります。

neo4j.com

関数の読み込みも、プロシジャーを作ってjarに固めてpluginディレクトリに入れておけばOKです。

とりあえずサンプル写経して、自分でプロシジャを作ってみたリポジトリがこちら。

github.com

普通に gradle build してできたjarをpluginに入れてNeo4Jを起動すれば関数が使えました。

テストをサポートするライブラリなんかも用意されています。サンプル通りにテストコード書いて実行すると若干起動が遅い上に以下のような出力が出るので、jerseyでNeo4Jを起動しているのかもしれません。

8 08, 2016 1:11:41 午後 com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
情報: Initiating Jersey application, version 'Jersey: 1.19 02/11/2015 03:25 AM'
8 08, 2016 1:11:41 午後 com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
情報: Initiating Jersey application, version 'Jersey: 1.19 02/11/2015 03:25 AM'
8 08, 2016 1:11:42 午後 com.sun.jersey.server.impl.application.WebApplicationImpl _initiate
情報: Initiating Jersey application, version 'Jersey: 1.19 02/11/2015 03:25 AM'


Process finished with exit code 0

とりあえず単体で呼ぶことはできたんですが、例えばこれをMATCHの結果から計算してそのままセットする、みたいなことは、まだCypherのシンタックスがよくわかってないのでできませなんだ。。。

まあ、そもそもですね、こんな関数的なプロシジャ作るべきではなくて、もっとバッチっぽい用途でビジネスロジックをデータベースエンジン側に寄せるようなやり方に使うべきで、プロシジャの中でクエリ投げろ、ということですね、きっと。

まとめ

まあ、SpringBootのサポート状況はさておき、グラフデータベース自体は結構使えるんじゃないかという感触です。可用性については、公式サイトの導入事例が結構でかいところなので、現段階ではあまり気にしてないというか。

仮説検証力を高めるためにSFを読もう

その他

まあ、何か煽りたいわけでもないんですがね。なぜ自分がSFが好きなのか、自分の考え方に何か影響を与えているのか、というあたりを少し書き留めてみて、SF語りできる人が増えるといいなあ、と。

SFが私に与えた影響

前にどれかのエントリで書いた記憶があるのですが、私が好きなSFは「科学技術の進歩が人間の有り様に影響を与えざるをえない世界で、科学技術の文脈から人間の有り様を変えてしまうような仮説をシミュレーションする」タイプの作品です。これは、小松左京のSF観から影響を受けているというか、彼の作品の中でもその色が濃いものが特に好きだったからではないかと思います。

で、この「人間の有り様を変えてしまうような仮説」って完全にイノベーションじゃないですか。

  • 大きな嘘(仮説)がないと始まらない
  • 仮説に対する検証のアプローチは科学を使う
  • その結果の以前以後で別れるような人間の有り様の変化がある

テクノロジーが世の中を変える様子とそっくりです。やっぱりテクノロジーで世界を変えたいと思ってるエンジニアはSF読むべきなんですよ。彼らの嘘のつき方と検証の仕方を学ぶべきなんですよ(無理矢理)。

この基準に照らし合わせて好きなSF

で、この基準に照らし合わせて、今までの私の読書体験の中で大きな印象を残している作品を幾つか紹介したいと思います。SFにもいろいろあって好きな作品は他にもありますが。

果てしなき流れの果てに

この作品を手に取ったのは高校生くらいの時で、今までの小説というのは何だったんだ、と感じさせてくれる体験でした。衝撃度合いという点では、私の中での小松左京の最高傑作です。

歴史と時間に対する異議申し立てであるとか、人間が縛られている秩序とその先にあるものとか、時間と空間において人間の想像が到達しうる限界に挑戦しています。それでいて、物語の最終的な到達点が日常に近いところは非常に日本的だなあ、と感じるところではありますが。ちなみに、妻もこの作品が好きですが、最初と最後は蛇足だと感じたそうです。

果しなき流れの果に (ハルキ文庫)

果しなき流れの果に (ハルキ文庫)

華竜の宮

どちらかと言うと続編の「真紅の碑文」は、仕事をするとはどういうことか？ってことにフォーカスが合ってたと思うんですね。それはそれで心が滾って好きなんですけど、人の在り方を地球規模で考えてそのビジョンを示す、という意味ではこっちの作品の方がより描けていたと思うんですよね。それから、科学と倫理の在り方についての問いかけと、人が選択しうるある一つの答えを丹念に描いているというのも素晴らしいです。

最後の終わり方が小松左京の「果てしなき流れの果てに」とか「虚無回廊」っぽいというか、人の先にあるものは何か？という物語につながっていく気がして、こっちも書いてくれると嬉しいな、と思います。

華竜の宮(上) (ハヤカワ文庫JA)

華竜の宮(上) (ハヤカワ文庫JA)

華竜の宮(下) (ハヤカワ文庫JA)

華竜の宮(下) (ハヤカワ文庫JA)

地球へ...

たまに本気で言うんですが、S.D体制って少子化対策にはいい気がするんですよね。人間が自分の能力を超えてしまった人工知能に対して、その種としてのいく先を預けてしまうのは選択支の一つとして出てくるでしょう。そういう社会が厳密であればあるほど、弾かれる人は出てくるわけで、この作品は弾かれた側がポストヒューマンであった場合に何を選択していくのか、ということを描いています。

その結果として提示される未来は、必ずしも合理的ではないのかもしれませんが少なくとも相互の理解と共存に期待の持てる内容であるとは思います。アニメもいいぜよ。

地球(テラ)へ… (1) (中公文庫―コミック版)

地球(テラ)へ… (1) (中公文庫―コミック版)

地球(テラ)へ… (2) (中公文庫―コミック版)

地球(テラ)へ… (2) (中公文庫―コミック版)

地球(テラ)へ… (3) (中公文庫―コミック版)

地球(テラ)へ… (3) (中公文庫―コミック版)

地球へ・・・Vol.1 【完全生産限定版】 [DVD]

地球へ・・・Vol.1 【完全生産限定版】 [DVD]

Beatless

連載された雑誌が雑誌だから、美少女バトル物みたいな空気をまとい過ぎていてもったいないんですが、これもいく先預けるという点では同じですね。主人公がの性格がクソほど嫌いなんですがね。。。自分はああいう選択はしないと思いますが、ポストヒューマン側が人間を同列に扱ってくれるのであれば、こういう未来もありかな、とは思います。

My Humanityのスピンオフ作品もいい感じです。

BEATLESS

BEATLESS

My Humanity

My Humanity

というわけで

SFを読もう。というか、SFを語ろう。

ここ1ヶ月くらいの雑多なメモ

その他

主に仕事関連で、自分の中での体系化を待つ暇もなく仕事としてやらなきゃいかん状況なので、この辺りを手探りしてるよ、というのをメモってみます。それぞれトピックとして体系化してきたら、後で個別に掘る感じです。

サービス(プロダクト)のマネジメントとか

こういうのリリースしたんです。

MallNavi モールナビ

まだよちよち歩きのサービスではあるんですが、私がプロダクト全体をマネジメントした初めてのリリースです。これからユーザの皆様とプロダクトを成長させていきたいと思っています。

でまあ、やりたいことの100分の1もできていないし、やりたいことに向かうための最初の一歩をどうするかという点においては非常に難産だったわけです。正直な所、最初の一歩が決まってしまえば、サービスの要求作るのは楽でした。とはいえ、やるべきことを考えていると自分でコード書いてる余裕はないわけで、すますんがいなかったら半年リリースが遅れてたと想います。

だいたいやってることは以下の通りで、次の次くらいのリリースを見据えて関係者と話をする、というのがお仕事になってきています。

  • リリーステーマの決定
  • 要求をユーザストーリーマップに起こす
  • ステークホルダー、社内ユーザからの意見集約
  • コードレビュー
  • インフラ系の意思決定
  • 事業計画(マネタイズはどのポイントでどのくらい、とか)

ロードマップはハンドリングできてるから、健全な意思決定の偏らせ的な所は割と出来てる気がします。ステークホルダーへの説明が一番難しいですが。今は情報が行き渡る仕組みと、短いスパンでの説明で泥臭くやってる感じです。この辺りスマートにならないものか。

なかなかうまくいってるのは、ステークホルダーミーティングのリハーサルをすますんとやってることですかね。アジェンダを読み合わせて気になる所をチェックするレベルですが、内容をすり合わせた上でミーティングに望めるので、脱線や未決事項が少ないです。

開発のフローについて

ツールの中心は、GithubとWaffle.ioですね。

FeatureMapでユーザ体験の視点から要求を管理して、イテレーションの最初で見積もりしてからGithubからIssueにあげる、その進捗はWaffle.ioで可視化する、という感じです。

IssueやPRあげる時のタイミングだとかは週次のふりかえりで改善して行っています。今は、Issueはイテレーションの最初で見積もりしたらReadyにして、PRはやり始める最初に出してWaffle.io上でIn Progressになるようにしています。Issueとしての完了条件はコードレビューが終わったら。要求として完全に閉じるのはFeatureMapに記載している受け入れ条件を満たしたら、です。

IssueとFeatureMapがひも付けられないのが残念な所なんですよえ。まだこの辺のツールにあまりお金かけられないので、API使えればひも付けて色々とできる気はするんですが。。。

ツール、テック系

コードは書いてないけど、テック系のツールは使ってるよ、ということで。

ElasticBeanstalk使った

MallNaviはAWS ElasticBeanstalk + Dockerで環境構成して運用しています。デプロイとイメージ管理周りの構成は以下を参考にプライベートレジストリを作ってローカルマシンでイメージビルドしてからpushする具合。

aws.typepad.com

サービスとして投入するのは初めての組み合わせですし、運用開始したばかりなので、大した知見も溜まっていません。ただ、デプロイ周りは楽になったな、と見てて感じました。リリースで多少引っかかりはありましたが、ElasticBeanstalkがどうこうという話ではなかったですし。

ログをElasticsearchに吐いているのですが、このあたりの構成がちょっとスマートでないので、SpringBoot 1.4対応で変更しようかな、と話している所です。

kibanaとGoogle Analytics

今の所はより多くの利用者に使っていただくことが至上命題なわけです。そのためには現状を把握して、機能のロードマップとともに具体的な目標を立てなければなりません。

というわけで、追いかけるべき数字が少ない今のうちにkibanaとGoogle Analyticsの使い方を勉強中です。kibanaについては今後も使い続けるかは微妙な所で、ElasticsearchのSQLでのクエリに対応したらre:dashに乗り換える予定。

Neo4j

SpringBoot 1.4のリリースノート読んでたらNeo4jに対応とあったので、これからの機能展開も含めて採用を考えようかと思って検証中。もう少しまとまったら整理してエントリ書きます。とはいえ、ググって出て来るレベルのことしかないと思われるので期待は無用で。

まとめ

まあ、仕事がごちゃごちゃしてますねえ。自分の仕事はこれです！ってはっきり言えればいいんですが。。。プロダクトに責任のあるOSSANたちと新橋会したい。