良いあそなすちゃん

良い方のあそなすちゃんです!

ゲームの攻略の仕方

Wikiとかでゲームの攻略法が確率されてその通りにしか動けないプレイスタイルよりは、ゲーム内のフィードバックを瞬時に判断して適切な行動ができる方が楽しめると思うんだけど、どうなんだろ。

透明人間の骨

shonenjumpplus.com

最近読んでるWeb漫画。作風が好きな同人作家さんに似ていたからすわ商業デビューか!と思ったけど、違った。ちなみに作風というか、髪の毛が黒ベタで着色されているとツボという謎の癖なので、曖昧にそういう作家さんを好きになる傾向がある。

もとより、現実世界の延長線でサスペンスな設定がキチンと考証みたいなのがされている作品が好き。物語も1話目で様々な事が簡潔に説明されていて、その後の展開につながっていくのが読んでいて気持ちよかった。

以下余談。Web漫画、会員登録をしてると通知が来たりして新作を読めたりするんだけど、Web漫画のプラットフォームの数だけアカウントをつくるのはとても面倒だし、漫画を読むことに対して、なんだか本質的じゃないと思う。

その点少年ジャンププラスはなんろRSSを配信していて、RSSリーダーに登録しておくと自分のタイミングで新作を読めるという点がとてもよい。RSSリーダー自体があんまりメジャー(?)じゃないというのもわかるんだけど、だからといってRSSなくてもいいや、というのはどうなんだろうなぁと思った。ちなみにスマートフォンのアプリなどで来る通知は便利だと思う(スマートフォンの画面で漫画を見る体験が最良かはさておき)。Web漫画でブラウザの通知はあんまりうれしくないような?という感じはしている。RSSを配信することでどれほどのメリットが事業側にあるのかは定かではないんだけど、でも、RSSほしい。ここまで書いてて思ったんだけど、RSSリーダー使っている人、もしくは定期的に何らかの方法でRSSを購読している人って日本だけでどれぐらいいるんだろうなぁと考えてしまった。

余談のほうが長くなってしまった。とにかくいいたい事はWeb漫画のプラットフォームでRSS配信をしていて、漫画自体もすごく面白くて、個人的にいま一番アツい、ということです。

松竹梅の案を出す時の心理

何らかの機能の実装や要件などを決めるときに松竹梅でランク付けした案を提案することがあるんだけどこの時に自分の中に心理戦みたいなのがあってそのときの思考の流れを書いておこうと思った。

そもそも松竹梅とは

いわゆるジャパニズムなランク付けで松が最上級、ついで竹、梅という感じ。古い旅館に行くとよく見るやつ。*1

開発する時の状況にも寄るけど以下のような感じ

  • 松が最高の実装だけどコストも高い。
  • 竹が妥当な現実的なコストとパフォーマンス。
  • 梅が妥協したり幾つかの機能や要件を削ったりする。

ざっくりこんな感じ。あんまり明確には決まってないけど以下の様にメリットがある

メリット

まとめると、チームやプロダクトの最高の状態を共有することができる。

ほとんどの場合は松の案は採用されないけど、この松案にはチーム内で「じゃあ、今足りてないものはなにか、それを解決するための最高の解決策はなにか」ということなので、(コスト度外視で) 自分たちのプロダクトを最高にするための案が集まる。

そうすることで今のチーム内でぼんやりとしていたことがだんだんと明確になる。夢を見るのは楽しいよね。

多くの場合は松の中から竹案を考えることが多い。このときに松案の中に要件を満たすのに本質的じゃない項目があると竹案がぼんやりしてくるので、好き勝手に松案を豪華にはしないことが重要。わびさび。この段階ではコスト(実装コストとかお金とか)の話もあるので見積りもやっておくとよい。松案でコストの話をしても巨大な妄想の場合には避けたほうがよいかも。

梅案はランクは一番下だけど、「ここは譲れない」とか「これは必須」みたいなものが残る。これもチームメンバーが普段どのようなことを考えているのかを共有することができる。つまり松は最高のチームやプロダクトを目指すための方針、梅はチームやプロダクトに必要なことが集まって、竹はお互いの良いところどり、という感じ*2

デメリット

松竹梅を考えるときに、プロダクトに集中しすぎたり、チームに集中しすぎたりすると、メンバーに合意してもらいやすいような材料を用意してしまいがち。外堀を埋めるみたいなのは重要だけど、どちらかと言うとなるべくフラットな状態で会話していきたいところ。

まとめ

メンバーの思っていることをアウトプットさせるのに松竹梅は結構有用だけど、俯瞰して全体像を見失わないこと。

*1:今調べてみたけど明確な優劣があるわけではないとのこと 松竹梅 - Wikipedia

*2:なるほど、そういう意味ではWikipediaに書いてある明確な優劣がないということにもなんとなく納得がいく

スクリーンショットとるアプリケーション

ずっと昔からSkitchが好きで使っていたんだけど、Skitchさんの立場がふにゃ〜とし始めてから色々な機能が使えなくなったりとかバグったりとか起動するとエバーノート(cv三石琴乃)のログイン画面が出たりしてウーンとなっていた。まぁそれでもシュッとキャプチャしてちょこちょこっとテキスト書いたりするのにはシンプルで便利に使えてるからまぁいっか〜となっている。

けど、最近また挙動が怪しくなってきて、D&DでGitHubのIssuesに画像をぽいっと投げてもキャプチャしたひとつ前の画像がアップロードされてしまい、サポートにも連絡はしたものの、もういいか、という気持ちになり sora_h がおすすめしてくれた Monosnap を使い始めた。

monosnap.com

かつては img.ason.as*1 っていうドメインで自分の撮ったスクリーンショットホスティングしていて、画像配信をしていたけど、もともとはギョームでCDNを入れる一環の素振りとしてやって今はスクリーンショットで撮った画像をアップロードすることもなくなって、単に軽くお絵かきと文字が書き込める程度で満足してしまうようになってしまった。*2

というわけで今までありがとう Skitch 、これからよろしくMonosnap

*1:自分のVPSに画像を置いてAnazon CloudFrontで配信みたいな構成

*2:この画像配信も元はと言えばSkitchのSFTPによる画像アップロードがうまく動かなくなってからやめた

高専DJ部 #15 2017/10/21

そういえば最近ブログで告知してなかったなということで告知です。

普段の活動は mixcloud を見てると「お、なんかDJやっとるな」というのがわかると思います。ジャンルが相変わらず定まらない感じで、テンポがだいたいあってるやつを自分のツボにあう感じでつなげているのでよかったら聞いてやって下さい

www.mixcloud.com

というわけで告知です。

kosendj-bu.in

10/21日(土) 14:00 からです。場所は早稲田にある茶箱というところでやります。高専DJ部は高専出身の人たちが集まってDJをやるイベントで、特に高専生しか入れないイベントでもないので一般の方もお気軽にいらしてください。

そして今回は久しぶりのトリをやります。

なんでトリをやるのかっていうと、僕がインターネットを初めたのが97年か98年ごろで、当時はインターネットで音楽を聞くといったらMIDI音源IEに組み込まれたQuickTimeプラグインなどを使ってて再生していて、なぜかたまに再生できなかったりするので、ページ内にリンクされている.midiを見つけて直接アクセスしてファイルに保存していたような時代から始まり、muzieを使ったり、なぜかMySpaceなどで投稿される音楽を聞いていたり、それこそ2000年代に入ってからは、記憶が正しければ2008年ごろにインターネットで始めてマルチネレコードにエンカウントしたようなきがする。2007年にはニコニコ動画にアカウントをつくってVIP板とかで盛り上がってたネタが音楽になったやつを聞いてた(VIP STARとかムネオハウスとか)。それからは2008年だか2009年のころからSoundCloudを利用を初めて今で言うところのBootleg*1みたいな作品を聞きまくっていたことがある。

当時は野蛮でiTunesで音楽を管理するという概念はあまりなくて、パソコンを買い換えるたびに1からiTunesライブラリを構築し直すみたいなことをやっていて、2010年ごろまでの音源はほんの一部しか残ってないのが悔やまれる。当時音楽がMacのHDDを圧迫しまくるので聞きたい曲があったら都度外付けHDDから音楽を持ってきて聞くみたいな運用をしていたのを覚えている。

このまま2010年代の僕が見てきた音楽の文化を書いてもいいけど、今回のDJのテーマとしては00年代の懐メロなので10年代以降の話はまた10年後とかに。

そんな、高速にコンテンツが生成され、高速に消費され、高速に廃れていく*2世になって久しい中で音楽という文化も同様の道を歩んでいるわけだけど、そこにも盛衰があり色々なインターネットレーベルが登場しなくなっていく中で、僕の見ていた世界では2chなどでアホみたいに音MADがつくられてそれが各種うpろだにアップロードされていきリンクがスレに貼られて共有されていく流れから、YouTubeニコニコ動画SoundCloud、インターネットレーベルの登場によって様々な音楽体験を生み出してきた。それが僕の00年代であり、その時の体験で得られたものを、2017年の今DJとしてやるのだ。

とはいえ、仮に今の20歳の人が来たとしても、彼ら彼女らを置いてけぼりにするつもりもないし、ちゃんと*3DJはやっていくので、若い人には「へー、こういう音楽があるんだ」と思って貰えれば良いし、僕より歳が同じか上の人には「わかる〜〜」みたいな気持ちになって欲しいし、僕と同じような音楽体験をした人は感動して泣いてほしい。そういうDJをやっていく。

というわけで改めて、告知です。

10月21日(土) 14時から早稲田の茶箱 にて。僕の出番は19時20分からです。途中からでも全然いいので今も音楽好きな人はきてほしいな、と思うのであった。

*1:Bootlegの概念自体は昔からあったと思うんだけど、それがBootlegと呼ばれ始めたのって2010年代入ってから?という認識でいるんだけど、もし違ったら出典と一緒に教えてください。

*2:高速を大量に置き換えてもよい

*3:何を持って「ちゃんと」かはよくわからん

RubyKaigi 2017に行ってきた

2011年は一般参加者として、2013年からは何かしらのスタッフなどで携わってきて、今年はネットワーク班と写真撮影班とちょっとサイネージ班をやってました。

ネットワーク班

今年はsorahを班長としたネットワーク班がいて会場のネットワークの構築と運用を担っていた。僕はそこまでネットワークに詳しいというわけではないんだけど、人手が要りそうな気配だったので色々やってきた。

sorahの記事がネットワーク等々くわしく書いてあるので先に読んでおくといいかも。この記事はあくまでも僕の視点でのお話です*1

RubyKaigi 2017 で Wi-Fi を吹いてきた #rubykaigi - diary.sorah

事前の準備では、LANケーブルのラベリングと敷設と撤去が主たる作業内容で、全体のLANケーブルは1.5kmぐらいあるぽくて、業者から届いたLANケーブルはスパイラルな状態で届いてるので一度解いて八の字に巻き直したり、両端にラベリングをしてた。八の字に巻き直すのは大変だったんだけど、30m級のLANケーブルぐらいだったら5分ぐらいで巻き終えるぐらいの練度にはなった。50mを超えると左手で持てなくなったり意識が低下するなどもあったけど、そこは各位の協力体制でなんとか。最初は20m級でも二人がかりでやってたけど、だんだん慣れてくると1人でも出来るようになってて練度の向上を感じる。業者さんから届きたてほやほやのLANケーブルを触り続けていると粉っぽいのが手にめっちゃ付着するので、ウェットティッシュ的なものが必要だということがわかってて、本番当日でも養生テーブが足りなくて買い出しに行くときに追加でウェットティッシュを購入した。

今回は当日スタッフに現地の学生さんたちがいらっしゃって敷設と撤去時に手を借りることができてめっちゃよかったです。敷設時にはLANケーブルのラベルを見ながらAPと譜面台を担いで設置してLANケーブルを差し込んで床を這わせて養生テープで床に固定してみたいなのを各会場(フェニックス、ダリア、コスモス、ヒマワリ、ホワイエ)でやっていました。機材の運搬や荷解きは終わっていたので最初の説明をしたあとは流れ作業のようにできたのがよかったです。

元々他所で色んなイベントのオーガナイズをしているのもあってスタッフの方々への指示出しには自信があって、今回の場合、sorahがSPOFなのを危惧して予め準備や片付けの内容、ゴミ箱の位置などなどを聞き出しておいて、それを僕から学生さん達に連絡、学生さん達からの質問は僕が受けて僕が答える、どうしてもわからないものがあれば僕からsorahにトランシーバーで聞いて答えるような体制にしてました。

コツとして片付けのシミュレート*2をしていて、「回収が漏れてたAPをどこにもっていくの?」とか「ゴミ箱の位置どこ?」とか想定される疑問とその答えを用意しておくのがよいですね。今回のNOCのチームは少人数だけど、手のあいた別チームの学生スタッフの方々が続々とお手伝いに来てくれるという体制だったので事前のブリーフィングとかはできないと思い、来た人に対してその時々の指示を出すようにしていました。

上述のような体制を準備して、撤去時には主にsorahとhanazukiにAPやスイッチ・ルーターなどの機材の回収に専念してもらうようにして、僕とHolyGrail、takano23は学生を従えてモリモリLANケーブルの撤去をやっていました。sorahのブログにもあるように皆さんのお手伝いによって19時半には撤収完了してその後のpixivさんがスポンサードしてくれたアフターパーティにも参加することができてめっちゃよかった...!!!

写真撮影班

今回ネットワーク班の仕事は当日朝と最終日だけだったので、ベストエフォートで各会場の発表者の写真を撮ってきました。

DSC_1981.jpg

DSC_2161.jpg

DSC_2378.jpg

実は前回も写真は撮ってたんだけど、SDカードを紛失して撮った写真を全て無くすというのをやらかしてしまっているので今回は撮った先から手元のMacBook Proに取り込んで休憩時間にLightroomで現像をするというのをやっていた。ホテルに帰ったら持ってきたハードディスクにその場でバックアップも撮っておくという体制にしてました。

ここ数年でLightroom力も上がっていて、各会場ごとの現像パラメータを用意して、それをポチポチ割り当てていって現像のコストを下げるみたいなのをやったらめっちゃ楽だった。それから、昔はブラケット撮影で露出を上下0.3ぐらい上げ下げして3枚撮ってたんだけど、結局のところその中から1枚だけを選ぶしバシバシ撮っても選ぶのが大変なのでピントだけ意識して、1枚だけ撮影するようにしました。3日目のLTのk0kubunさんみたいな激しいときにはシャッター切りまくるとおもしろい絵がたくさん撮れるのでそういうときはコスト度外視してたりもする。

なんだかんだでflickrを使っていてモヤモヤしてたんだけど、懇親会のときに、flickr以外にもGoogle Photosを初めとしたフォトストレージにも課金してるし、自宅にもNASがあって写真保存戦略大変という話題から、新しいフォトストレージサービスが欲しいとかそういう話で盛り上がって楽しかった。

というかカンファレンスカメラマンをやるなら、70-200mm f2.8もってないと人権がないですね...。当初レンタルするか悩んで荷物が増えると大変かなと思って諦めたんだけど、荷物は拠点となるサイドステージに置いておけば比較的身軽になれたので持ってくればよかったなぁ。来年は70-200mm f2.8でやっていきましょう。

以下は大場さんが70-200mm f2.8で撮影している写真です。24-70mm f2.8ではできない絵になっててめっちゃ良いですね。

20170920-DSC_1878

サイネージ班

実は去年と同じアプリケーションを利用していて、僕とhmskさんで開発をしていました。(今年は全く手が出せてないけど)

LTタイマーは去年の段階では実装されていなかったけど、hmskさんがRubyKaigi中に実装しててジョバンニぽかった。デバイスに関しては去年に引き続きChromebookを利用していて、LT時にはディスプレイを裏返してタブレットモードにして、発表者に見える形で譜面台に置いてました。

休憩時間中にhmskさんと、「ぼちぼちオープンソースにしますかねぇ」という話もしていて、「ハードコーディングされている部分とかをいい感じにしたらできるかも?」という感じなのでカミングスーン。

また、サブスクリーン的なものを運用するコツみたいなのもまた機会があれば書いていきたい。

(気がつけば1年経ってしまっている...)

*1:ちなみに僕は台風の影響で前日準備には参加できなかったので当日朝からの話になります

*2:撤収のシミュレートはRubyKaigi 2013のときにスタッフ宿のkakutaniさんのお部屋に集合して予め懸念点などを洗い出しておくのがすごいよかったのでイベント開催する時にはやってる。

zshのプロンプトに今いるブランチとmasterブランチとのdiffの行数をだすやつ

巨大なPRを連続でレビューして疲れてしまって、かもう少し細かくレビューするにはどうしたら〜〜〜と悩んでいて、とりあえず、自分のプロンプトに今のブランチとmasterブランチのdiffの行数を表示するようにした。気がついたら巨大なPRになるのはやっぱりやりがちでそういうのにPRをだす前に気が付きたい。

f:id:asonas:20170824130713p:plain

github.com

vcs_infoにそういうのがあるのかなって思ったんだけどなさそう?だったので適当にぱぱっと書いた。

developer.hatenastaff.com

追記

なんかうまく動いてないのであとで直す…