詩と創作・思索のひろば

ドキドキギュンギュンダイアリーです!!

今すぐオススメしたい!ノベルっぽいゲーム3点

なるほどですね! そんな同僚に個人的にオススメしたいノベル系ゲー(ADV)を選んでみました!

セカンドノベル 〜彼女の夏、15分の記憶〜(PSP)

セカンドノベル ~彼女の夏、15分の記憶~

セカンドノベル ~彼女の夏、15分の記憶~

数年ぶりに戻ってきた故郷で再会したヒロインは、高校時代の「事故」以来、15分しか記憶が保てなくなっている。主人公はその彼女がある物語を思い出しながら語る手伝いをすることなる。主人公は物語を「フラグメント」にまとめながら、ヒロインの「ストーリー」づくりをサポートするんだけど、その切り替えは現在と過去との行き来にもなっていて、しだいに「事故」の真相が明らかになっていく……という趣向。物語を語るって物語。

ひとこと: 主人公の声ありでやるのがオススメです。

公式サイト: セカンドノベル ~彼女の夏、15分の記憶~

銃声とダイヤモンド(PSP)

銃声とダイヤモンド

銃声とダイヤモンド

これはノベルゲーってわけではない。プレイヤーは交渉人の一人となって、いくつかの事件をその手腕で解決していく。タンゴのメロディにのせてリアル調の画で交渉を進めていくんだけど、選択肢を間違えるとクールで頼れるはずの主人公の言動がどんどん変な方向にずれていくのが面白い。交渉はリアルタイムに進み、選択肢で立ち止まるということができないんでトライアル&エラーがちょっと面倒。

ひとこと: 夜は雨になる。

公式サイト: 銃声とダイヤモンド | ソフトウェアカタログ | プレイステーション® オフィシャルサイト

あの、素晴らしい をもう一度/再装版(PC、iOS)

あの、素晴らしい  をもう一度/再装版

あの、素晴らしい をもう一度/再装版

記憶を失くした主人公が、時間が経つとある時点までの記憶が消え去ってしまう(「くりかえし病」)ヒロインに出う、剣と魔法の世界。ふたりは旅をしながら情報をあつめ、この状況の元凶に挑むのだけれど、失敗すればその力により記憶を消され、スタート地点まで時間を巻き戻されてしまう。特徴的なのは前の周回で得た経験が次の周回の新たな分岐を作り出すシステムで、これがストーリーにも組み込まれているので、はっきりと繰り返し世界の物語です。面白いし、気づいたら iOS 版が出てたのでやるべき。

ひとこと: ググらずに頑張ってください。

公式サイト: 『あの、素晴らしい をもう一度/再装版』


いかがでしたか? 他にもおすすめあるだろって方はコメントで教えてくださいね! ではでは。

追記: こんなゲームが好きな人におすすめです ⊂(^ω^)⊃

Spike The Best 428 ~封鎖された渋谷で~

Spike The Best 428 ~封鎖された渋谷で~

BEST HIT セレクション EVER17  ~the out of infinity~ Premium Edition

BEST HIT セレクション EVER17 ~the out of infinity~ Premium Edition

Steins;Gate (シュタインズ・ゲート) (通常版)

Steins;Gate (シュタインズ・ゲート) (通常版)

ゴースト トリック NEW Best Price! 2000

ゴースト トリック NEW Best Price! 2000

ダンガンロンパ 希望の学園と絶望の高校生 PSP the Best

ダンガンロンパ 希望の学園と絶望の高校生 PSP the Best

ISUCON4 ダメでした #isucon

こないだの ISUCON で平凡な結果を取ってしまったのでお知らせします。

チーム名は「マカレラーズ」、メンバーは songmu & y_uuki でした。

予選

予選のエントリを書いてなかったので、いっしょに書いておく。具体的なポイントについてはもう覚えてないので、日記です。

予選はオンラインだったのでチーム全員がバラバラの場所で参加であったけど、Sqwiggle と Slack で十分だった。むしろ普段どおりという気もした。あらかじめ作戦を立てていたわけではなかったけど、自然と分担ができていて、アプリの細かい改修にくわえ、デプロイ周りやプロファイングは自分がやった。これがいい感じに回ったので、本戦でも自分が進んでやることになった。普通に愚直に実装して予選枠を取ったという印象だけれど、いい順位ではなかったし、おそらく次の ISUCON ではもっと参加チームも増えているだろうので、こんな感じではいかんのだろうと思う。

本戦

予選では完全リモートチームだったので三人顔を突き合わせてやるのは珍しい感じ。二人とも同じTシャツ着てるなーと思ったら Mackerel Tシャツで、自分のやつがどっかいってるのを思い出した。GitHub Tでしたすみません……。

さて、本戦はじまってからコードを読んでみるとどこから手をつけようかなーと考えあぐねてしまった。ログをファイルに書き出してるところは明らかに改善の余地があったので、そこを Songmu さんがやるということになって、そのあいだ自分はデプロイの設定を書いたりしていた。最初に8000点取って暫定一位を取ったのはうちのチームだったと記憶しています(ぼくは何もしてない。共通の Redis を使う、くらいはやったけど)。

しかしそこから早くも伸び悩んでしまった。公平性ボーナスが意外とうまそうだったので配信アルゴリズムを変える必要は感じなかったし、レポートの部分もそれほど数はなかったはず。アプリのプロファイルを取ってみるとやはりファイルアップロードと配信のあたりが重かったのでそこをどうするかというのでいろいろ試行錯誤したが、結局大した効果はあがらなかった。ベンチマークが安定した得点を叩き出してくれなかったのにもつまづいてしまって、今思うとアプリケーションレベルの最適化に逃げてしまっていたと反省。結局動画も Redis から配信のままであり、ファイルで配信するくらい試してみればよかった。

ふり返ってみると、アプリのプロファイングと高速化という視点に拘りすぎて、ウェブサービス全体としての最適化という視点に欠けていたなーと思う。翌朝用事があって結果発表までいられなかったのだけど、新幹線の中でチームメイトが 304 案件、と発言したログを見てあーあーとなったのであった。nginx のプロキシ設定くらいなら書けるがより深いところになると勘でしか分からんのでほかの二人の話についていけなかったりする。

最後までいられなかったのは残念だった。けどやっぱり今年も楽しかったです! 運営の皆様おつかれさまでした&ありがとうございます!

ごはん写真

渋谷といえば吉野家

去年に引き続き今年もビビンバ弁当を頂きました✌

突然寿司があらわれてうまかったです

イシュー管理にお役立ち。GitHubのIssue/PRの状態が一目で分かるバッヂ

f:id:motemen:20141026214110p:plain

こんな感じに使えますっていうウェブアプリ+Chrome 拡張のはなしです。(ちなみに例はこれ

GitHub ではイシューへのリンクが "#829" という風に番号になって表示されますが、イシューをバリバリ使っていてこれらの間の参照が多く発生するような場合に、これって誰がやってるんだっけ、もう終わったんだっけ、と分からなくなることが多々ありますよね。こういう時、文中に画像で埋め込まれているとパッと見て分かりやすい。

デモ

http://github-issue-badge.herokuapp.com/

にデプロイしてあります(トップページは GitHub Pages にリダイレクトされますが)。

次の画像: motemen/test-repository#1http://github-issue-badge.herokuapp.com/badge/motemen/test-repository/5)が正しく表示されればオッケー。403 と出る人は /auth を訪れて OAuth 認証してください。プライベートリポジトリにまで権限を与えたくない場合は /auth?only=public へどうぞ。

http://github-issue-badge.herokuapp.com/badge/:owner/:repo/:number という URL で、SVG のバッヂ画像を配信しています。バッヂのパーツは左からイシュー番号、ステータス(open/closed/merged)、作成者もしくは担当者、それからラベル(の色)となってます。

以下に書くように、自前でデプロイするのも簡単です。その場合は GitHub:Enterprise 用に立てることもできます。

自前でデプロイする

リポジトリはこちら: https://github.com/motemen/github-issue-badge

お好きな方法を選んでください:

  • 一番簡単なのは Heroku にデプロイする: Deploy
  • もしくは Fig を使って: fig up
  • または普通に rack アプリとしてデプロイ。

設定

環境変数として以下が指定できます。(app.json に詳しいです)

GITHUB_OAUTH_CLIENT_ID, GITHUB_OAUTH_CLIENT_SECRET

画像にアクセスするクライアントに OAuth 認証させて API を使う場合はこのふたつを設定してください。

GITHUB_OAUTH_ACCESS_TOKEN

アクセストークンを予め生成しておき、これに設定しておくと、クライアントはいちいち OAuth 認証しなくてもバッヂを見ることができます。GHE や小さな組織で利用する場合はこれで十分です。

GITHUB_API_ENDPOINT

GHE を使う場合は指定してください。http://ghe.example.com/api/v3/ とか。

REDIS_URL

Heroku か Fig を利用する場合は不要。

Chrome 拡張

で、冒頭のスクリーンショットのようにリンクを画像に差し替えるためには GitHub の Content-Security-Policy を書き換えてやる必要があり、拡張にしてます。GitHub イシュー内でイシューへのリンクを画像に差し替える拡張。

https://github.com/motemen/chrome-Embed-GitHub-Issue-Badges

GHE ユーザや個人でデプロイした人もこの拡張を使えるように、GitHub および github-issue-badge の URL をカスタマイズした拡張をビルドできるようになってます。README にも書いてますが、src/ts/config.ts を

export var badgeOrigin  = 'http://github-issue-badge.yourcompany.example.com';
export var githubOrigin = 'https://github.yourcompany.example.com';

という風に書き換えて、

npm install
npm run build

すると build/ ディレクトリ以下にその設定に応じた拡張が生成されます。これを chrome://extensions から追加してください。

Fig

Fig 使ってみたけど便利だった……。というか Redis とか Ruby とかの公式イメージが配布されてるのが便利で、とくに Ruby は FROM ruby:2.0-onbuild などとするだけで bundle 済みのイメージが簡単に作れてしまう。ちょっとしたアプリの配布とデモにはとても役立ちそう。

ghq バージョン 0.5 を公開しました

Releases · motemen/ghq · GitHub

表題の通り、いろいろ滞っておりましたが ghq バージョン 0.5 を公開いたしました。あわせて homebrew-ghq も更新しております。

go get -u github.com/motemen/ghq

ghq import がシンプルになりました

今回の変更の目玉は評判のよくなかった ghq import を一新し、ウェブサービスからリモートリポジトリのリストを取得するのではなく、単純に標準入力から URL のリストを受け付ける、という風にした点です。ついでにビルドに Mercurial が不要になりました(笑)。

% ghq import < FILE

とはいえ個人的には便利なコマンドではあったので、エイリアス的にサブコマンドを設定できるようになっています。自分は以下の設定で go-pocketgithub-list-starred を使うようにしてます。

[ghq "import"]
pocket = !pocket list --domain github.com --format '{{.URL}}'
starred = !github-list-starred

例えば以上の設定で ghq import starred motemen などとすると、内部では github-list-starred motemen が実行され、その標準出力の各行がリモートリポジトリの URL と解釈されそれぞれに対して ghq get が試みられる、という寸法です。

その他の主な変更

たくさんのプルリクエストありがとうございます。その他の主な変更として、

  • ghq root コマンドが追加されました。
  • brew によるインストール時にデフォルトで zsh の補完も入るようになりました。

@fujimuraさん、 @mkanaiさん、 @eagletmtさん、 @aaa707さん、 @syohexさん、 @itiutさん、ありがとうございました。

これから

大きな変更になりそうだったので今回のバージョンには含められなかったのですが、バージョン 0.6 には Subversion 対応 が入る予定です(ありがとうございます)。今後もイシュー、プルリクお待ちしております!

はてなMackerelチームの開発フロー(スクラム、リモート)について話しました #nanapi_study #hatenatech

nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー - nanapi勉強会 | Doorkeeper

【nanapi x はてな】はてなとnanapiの開発フロー in Kyoto - connpass

nanapi さんとはてなで開催した勉強会に登壇し、東京・京都で Mackerel チームの開発フローについて話してきました。自慢できるようなカッコイイことをやっているわけではないけれど、今こんな風に頑張っています、ということをお話したつもりです。

Workflow at Hatena Mackerel Team // Speaker Deck

チームみんなで勉強する

スクラムの導入時もリモートワーク開始時にも、チームメンバーには何冊か本を読んで予習しておいてもらいました。そうすることでチームメンバー全員が同じだけの知識を持って(全員その道に関しては初心者だったので)、ワークフローを取り進められるようにです。

スクラムマスターとして、自分は以下の 2 冊を読みました。両方 Kindle で読める。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

チームメンバーには WEB+DB PRESS の以下の特集を読んどいて、としました。

WEB+DB PRESS Vol.78

WEB+DB PRESS Vol.78

  • 作者: WEB+DB PRESS編集部編,栗林健太郎,安詮院康広,山口良平,尾上忠輔,大川高志,坂本寛樹,青木峰郎,増井雄一郎,中島聡,江島健太郎,中島拓,柴田博志,伊藤直也,登尾徳誠,片桐崇,後藤秀宣,佐藤鉄平,近藤宇智朗,長野雅広,奥野幹也,渡邊恵太,A-Listers,家永英治,はまちや2,川添貴生,原田勝信,和島史典,城倉和孝,安達俊雄,Akira,川嶋賢一
  • 出版社/メーカー: 技術評論社
  • 発売日: 2013/12/21
  • メディア: 大型本
  • この商品を含むブログ (5件) を見る

みんな新しい仕組みを面白がってくれて乗り気だったので、助かったというのも大きい。リモートワークについては、以下の本。これは短くて読みやすい。モチベーションを上げるためにもよいと思います。

強いチームはオフィスを捨てる

強いチームはオフィスを捨てる

  • 作者: ジェイソンフリード,デイヴィッドハイネマイヤーハンソン
  • 出版社/メーカー: 早川書房
  • 発売日: 2014/04/01
  • メディア: Kindle版
  • この商品を含むブログを見る

高い山を細かく刻んで登る

スクラムを導入してよかったなと思ったのは、「サーバ管理ツール」という社内に実装があり、プロダクトオーナーである id:stanaka さん(もちろん開発メンバーも)の脳内にも高い理想がすでにできあがっているプロダクトを作る時にも、迷わず着実に進んでいくことができたことです。大きな目標を達成するために直近で僕達がやらなければならないことは何か、ということについてチームメンバー間できっちりと合意を取りながら進めていけた。

スクラムの進め方自体も模索していた最初期にはスプリント期間を一週間としていたのもよくて、だんだんとチームにフィットする形式になっていったと思います。疲れるので今は二週間になってるけど。

みんなが対等の環境で働く

はてなはもともと(2008年ごろから)エンジニアがみんな京都にいて、最近になってようやく東京開発センターができたというのもあり(デザイナにはすでに東京で働いている人もいました)、京都-東京間でエンジニアの数に大きな差があります。普通に働いていると「京都のみんな」対「東京のひとり」という状況になりかねないので、朝会などはテレビ会議を使って京都と東京で向かいあうのではなく、みんなが一人ひとりオンラインミーティングを通じて会に参加するという風にしてみています。これが本当にうまくいくのかはまだ分からないというのが正直なところ。

リモートだとどうしても話の細かいニュアンスが抜け落ちてしまうもので、後ろの雑談が耳に入って口を挟む、というような状況がリモートではどうしても発生しない。ここをどう拾いあげるかは今後の課題です。

勉強会の感想

一緒に登壇した @Vexus2 さんの話を聞いてると、開発フローの構築・改善に燃えてるなーっと感じてこちらもやる気が出ます。開発フローに新しい仕組みを導入して定着させる立場の人のための心構えなど、勉強になりました。こうやって他の人たちの話を聞くことで、自分たちのやり方にはまだまだ改善するところがあるのだな、とはっきり気付かされるのは、とてもよい機会でした。

IGNITIONチームの開発フローについて話してきた #nanapi_study #hatenatech - PhpStormと僕

「記憶に残る風景」 #地元発見伝

「記憶に残る風景」 #地元発見伝

https://www.google.com/maps/preview?q=35.670695%2C139.658516

世田谷区, 東京都

初めて一人暮らしした町。もはやうろ覚えだけど、地下道を作る計画が頓挫したらしく中途半端に地下に降りる階段があったのがよかった。写真のすぐ右にサンクスがあるんだけど、立ち読みしていたらマンガの中にこのサンクスが描かれていて、へんな気持ちになったのを覚えている。

地元の魅力を発見しよう!特別企画「地元発見伝

http://partner.hatena.ne.jp/jimoto/

「次の連休」のRSS配信を開始しました

次の連休 は次の連休まであと何日かひと目で知り、共有できるサイトで、 Google からも高く評価されています。

連休の近づきを誇り高く世界に発信している上のツイートをご覧ください。IFTTT 経由でツイートしているのがお分かりかと思います。ついに連休が RSS に対応し、フィードリーダーや IFTTT から簡単にアクセスできるようになりました!

URL: http://japanese-long-weekends.herokuapp.com/rss

フィードは一日一回(ベストエフォート)更新され、次の連休までのカウントダウンを配信します。

f:id:motemen:20141008095034p:plain

feedly で購読してみた様子

唯一のオプションとして ?d= というクエリパラメタに数字を指定することで、残り日数がそれらのいずれかに合致するものだけのフィードを生成します。例えば、?d=7,3,0 で連休7日前、連休3日前、連休中のみ更新されるフィードになります。

IFTTT 連携

冒頭のツイートはこの RSS と以下の IFTTT レシピで実現されたものです。デフォルトでは ?d=7,3,2,1,0 となってますので、ご利用の際はお好きなタイミングに変更してみてください。

IFTTT Recipe: 次の連休は N 日後です connects feed to twitter

次の連休は N 日後です by motemen - IFTTT

Heroku で Ruby と PhantomJS を使う

久々に Heroku 使ってみた。クライアントサイドで連休を算出するサイトなので、フィードの生成のコア部分には PhantomJS を使っています。PhantomJS を使うのも非常に簡単で、stomita/heroku-buildpack-phantomjs を使うだけでよい。検索するとこれを使用後に PATHLD_LIBRARY_PATH の設定が必要だという文献も見つかるけれど、現行のものではその設定もしてくれるので不要らしい。実際には Ruby も使いたいので ddollar/heroku-buildpack-multi を通じて利用しています。

という話も、app.json を置いてるので、これを見れば分かるはず。(app.json Schema | Heroku Dev Center