いつでも発展途上

ITとゲーム漬けのシャチ。とくにブログのテーマはなく、メモ代わりに書いています。

スパイダーソリティアF、定番パズルの心地よい再構築。

Switch の スパイダーソリティアF を全問クリアしたので感想を書きます。

f:id:windish:20181011135731j:image

 

スパイダーソリティアF は、Windowsにも入っているあのスパイダーソリティア同様(たぶん)のゲームです。

ランダムに配られた8山のトランプカードをルールに沿って並べ替え、同スートを全て揃えるとカードは消えます。これを繰り返し、すべてのカードを消すことを狙います。

この手のゲームはランダム(or ものすごく多いパターン)でカードが配られて、てきとーにプレイ開始して詰まったらやり直し…みたいなラフな遊びかたをしちゃいがちなんですが、スパイダーソリティアF はきっちり 100 問あり、同じ問題である限りは、何度やり直してもカードの積まれかたは一緒です。

つまり、詰めスパイダーソリティア なのです。

このため一問一問に真剣に向き合う必要があり、プレイ密度が高まります。

とはいえ難易度の上がりかたはゆるやかであり、最初の Easy はスートが一種類しかなく、次に Normal で二種類…というふうに徐々に慣らされていきます。

こうして遊び手は「詰めスパイダーソリティア」の世界に引き込まれ、Hard では作り手が遊んで欲しかったであろう(きっと) 4種類のスートでプレイすることになるのです。

タッチ操作には未対応ですが、キー操作はわかりやすく軽快で、ストレスは感じません。

音楽もどっかのカジノバーにいるみたいなオシャレなもので、気分を引き立ててくれます。カジノバーに行ったことはありませんが。

個人的に猫ちゃんデザインのカードがとても好き。ツボ。

そんなわけで、かなり面白かったです。お値段も 500 円と激安で本当に良いんだろうか的な。

販売元のフライハイワークス、Switch で良作を連発していますが、これからも目が離せません。

 

 

技術書展5に行ってきました

エンジニアたちの同人即売会 技術書展 に行ってきました。

初参加です。あ、出展はしてません。一般参加です。

熱いうちに感想を書いておきます。

 

めっっっっっちゃ楽しかったです!!!!!!!!!!

 

f:id:windish:20181009195929j:image

テンション上がって買いすぎ。

 

当日朝 9:45 ぐらいに会場に着いたときは、すでに 200-300 人ぐらいの人が並んでいました。

運営の方の誘導が巧みな印象。

 

11:00 の会場とともに事前にチェックしていたサークルをぐるっと周り。

ぶじ、お目当ての本をゲットできました。

 

ネコを支える技術。

f:id:windish:20181010081736j:image

ネコ愛とIoTと生物学的知見にあふれた楽しい読み物。電子版も出るそうです

 

完全SIer脱出マニュアル。

f:id:windish:20181010082155j:image

楽しく働きたいすべてのエンジニアに向けた転職入門書だそうです。

その名の通りのノウハウがみっちり詰まってます。

前回記事の「Onestop転職」もそうですが、こういう本は同人誌ならではですね。

 

ほかにもいっぱい買いましたがとりあえず読んだ本だけ。

運営のみなさま、ありがとうございます。

また参加してみたいです。

 

 

OneStop転職という最高に面白い同人誌を読みました

あまりにも久しぶりのブログ更新です。

Twitter でお世話になっているせとあずささんから「OneStop転職」という同人誌をいただきました。これが最高に面白かったのです。

f:id:windish:20180831132714j:image

この本は「ITエンジニアのための転職ノウハウ本」です。 

錬金術Meetup」というなんとも心踊る名前のコミュニティによる執筆です。その名に恥じず、ITで稼ぐためのきわめてリアリティに満ちたエッセイがつづられています。

同人誌でないと書けない(エージェントが実名だったり…)内容がもっとも面白いところですので、機会がありましたらぜひ本書をお読みください。

Booth で 9/30 まで頒布されているようですが、それ以降の頒布は未定だそうです。

 

個人的に面白かったのは「こんな場面にあったら転職を考えよう」です。MacがすべてWindowsにリプレース…なんていかにもありそうな話ですよね…!

「企業の素性を調べよう」も良かったです。帝国データバンクでの調査とか思いつきもしませんでした。

www.tdb.co.jp

番外編の「就活ファッションについての持論と考察」もネタっぽいですが面白かったです。「スーツであることより、着こなせているほうが大事」という考察は斬新でした。

というかいろいろ書いていますが面白くない記事というのは無かったです。本当に面白い本でした。

 

 

なお、私自身はこれまで5回、転職を経験しています。

しかしどれも必死というか、ネズミが川に落ちて溺れまいと足掻いているごとくの見苦しい経験しかないため、転職というテーマについてこれほどスマートに面白く記述することができる…というのは衝撃でした。

この本を読んで技術書展にも興味が湧きましたので、次回は行ってみようかと思っています。

YAPC::Asia Tokyo 2015 に行ってきた #yapcasia

yapcasia.org に行ってきました。IT系のイベントに行くのは本当に久しぶりです。

木〜土 3日間通しのイベントですが、私は 8/21(金) だけ参加しました。有休を取って。 YAPC::Asia Tokyo は今年が最後の開催とのことですが、私は初参加でした。

聴いたセッションは次の4つです。

メリークリスマス! - Larry Wall

Perlの父、Larry Wall のセッション。おぉ〜!生Larry!!とか感動しつつ、会場にてお借りしたヘッドセットで同時通訳にて聴く…この同時通訳のクォリティがまた異常に高くてびっくりでした!ありがたいことです。

内容は Perl5 → Perl6 の変化を、トールキン作品の比喩をまじえつつなめらかな語り口で説明するもの。なんかこう、聴いていると、大昔にオライリーの「プログラミングPerl」や「Perlデスクトップリファレンス」などで読んだ Larry の序文そのものの雰囲気で、なぜか懐かしい気持ちになったりしました(同じ人だから当然といえばそうなんですけど)。

指輪物語ホビットの冒険も原作を読んだので、楽しいお話でした。映画も原作も見てない人だとかなり辛かったかも…。「わたしもいつか灰色港へ旅立つ時がきます」という言葉にはグッときましたなあ…。

そうそう、15年間作られ続けた Perl6 が、2015 年クリスマスにとうとうリリースされる!………かもしれない、とのことでした。

togetter.com

世界展開する大規模ウェブサービスのデプロイを支える技術

任天堂ゲーム機むけ Web サービス「Miiverse」のデプロイ手法を、任天堂はてなのエンジニアの方が解説。ゲーム好きで任天堂スキーな私としては見逃せないセッション。感想としては、意外に地道というか泥臭いんだな〜…というものでしたが、いろいろと次の手法を模索されているようで期待してしまいます。ところで DeNA との協業が本格的になったらどうなるんだろう……

togetter.com

TBD

Rubyの父、まつもとゆきひろ(Matz)さんのセッション(本当にこのタイトル)。LarryとMatzのセッションを1日で両方聴けるなんて、贅沢ですね。

内容は割りとゆるめな感じ(失礼)で、自分で言うから許されるRubyの悪口・に始まって新言語 Streem の話まで、盛りだくさんでした。ジョークも交えつつ笑いの絶えない60分でした。

togetter.com

Conway's Law of Distributed Work

リモートワークのノウハウを共有してくれる話です。リモートワーク、私の身近でもわりと使われだしてることもあり、興味津々でした。

  • チャットにbotを入れたりすることで遠隔地と楽しみを共有できる
  • スクリーンシェアが有効(操作を教えたりとか…)
  • commit メッセージはとても大切、実装の意図を伝えるために
  • コードレビュー大事。統計的にもバグを 60% 減らすことができる
  • カレンダーの共有ツールは選択肢が少ない。Googleカレンダー、Exchange
  • リモートワークを始めるには、全員が強制的に一週間リモートワークを体験してみることが良い
  • 定期的にオンサイトで会うことが重要
  • 自分の個性をみんなに知ってもらう。仕事以外の話ができるチャットルームを用意するなど
  • リモートだと相手が仕事してるかどうかわからないので、知らせる必要あり
  • CAP定理 - Wikipedia とリモートワークの共通点について

togetter.com

Perl6 on JVM: It works??

Perl6 は JVM でも動くので実用的かも! というお話。これまで遊ぶことすらままならなかったのが、遊べる段階になった!ということでした。まあ、今年リリースされますし!?期待しましょう。

togetter.com

LT大会

自作プロダクトのデモや同人誌の製作過程など盛りだくさんでした! 皆さんレベル高すぎ。

ほか雑多な感想

  • 無限コーヒー美味しかった
  • Tシャツカッコ良い
  • 会場が広くて快適だった
  • WiFiが快適で驚いた
  • MBAのバッテリが切れて悲しみに暮れていたが、隣の人が電源を譲ってくれた。ありがとうございました
  • Larryのセッションの最後のほうでおトイレに行きたくなって集中できなかった。無念すぎる

まとめ

スタッフの皆さま、素晴らしいイベントをありがとうございました。来週からまた頑張ります。

ドラクエ10の提案広場で見つけたちょっと好きな話

ゲーマーを自称する自分ですが、DQ10が面白すぎてほかのゲームに手がつけられないのでわりとだめっぽい状態です。おもしろいんですよDQ10
このDQ10、公式サイトにユーザーからのご提案を受け付ける「提案広場」っていうのがあるんですが、そこがわりと提案広場っていうよりも不満広場って感じになっていて、どれだけ実現可能性が低い提案ができるか競っているのではというぐらい日々カオスな提案が読めます。
「2ヶ月に1度バージョンアップとか言ってるけど、本当はもうできてるんでしょう?はやく出してよ」とか、「お金を倍払うからもっと早く機能を追加して」とか、一応 IT 屋さんのはしくれとしては寒気がするような提案もたくさん載っている、なかなかスルリングなところです。
で、そこにこんなステキな意見が載っていまして、ブクマまでしたのですが元記事が消えてしまっていたのでバックアップのためここに引用しときます。

タイトル:同じでなくたっていい
書いた方:キョウ
内容:
勇気を振り絞って放った渾身のギャグがスベったとき、みんなと感覚がズレてる人が居てその人だけ大爆笑・・・みたいな経験ありませんか?
こういうことに限らず、ズレてる人に救われることってあると思うんです。
同じ感覚の人が集まると、摩擦も無くて心地良いですけど「調和を乱す奴は許さない」みたいな空気になりがちな気もします。
悪い方向へ向かい出したときに歯止めが利かない怖さもあります。
自分の感覚から見てズレてると思う『変な人』っていうのを少しだけ認めて、自分の世界の片隅にその存在を置いておくと、それがいつか自分を助けてくれる事があるかもしれませんよ。
大多数が「変な意見」と思ったからといって、その意見を排除できてしまうような提案広場にはならないで欲しいと思います。

これを読んで、いいこと言うなぁ、とわたしはしみじみディスプレイの前で思ったのでありました。

kobo Touch を買ったので感想とかを書いてみる

じつは先週、楽天 kobo Touch を入手してました。発売日に。
この手の電子書籍リーダを所持していなかったので(iPad除く)興味本位で注文してみましたが、

  • 初日にアクティベーションできない人(私含む)が続出
  • EInkの扱いに戸惑う人々の不満続出
  • その他いろんな不具合がどどんと続出
  • 楽天レビューは大荒れで封印→非難を浴びる

というかんじで世間的には散々な出だしだったようです。が、個人的にはけっこう気に入ってます。
なんといっても 軽い です。毎日持ち歩いても気になりません。私みたいな体力がスライム級の人間にはこれほどありがたいことはありません。これだけで自分の中では他の端末に大勝利です。
が、初代 iPad を毎日持ち歩いても平気な方には関係ない話かもしれません。
そして USB でつないで手動でファイルを放り込めば読めるというぞんざいな わかりやすい扱いができるのも良いです。達人出版会 とかで買った本を読むとかなり快適です。
が、これも手持ちの .pdf やら .epub なファイルが無い人には関係ない話かもしれません。
逆にあんまり気に入ってない箇所は、セットアップがとにかく超めんどくさかったことと、ストアで本が探しづらいところ、そしてオライリーの PDF な ebook が読みづらいことです。特に最後のは痛かった。
ストアについては、わたしにもっと英語力があれば、洋書がたくさん買えるみたいなのでお得感が増したかもしれないです。いろんな意味で今後を見守って行きたい kobo Touch です。

「塹壕よりScrumとXP」読書メモ (3)

前々回前回 にひきつづき「塹壕よりScrumとXP」の読書メモです。自分用ですので全くまとまっていませんし、誤りがあるかもしれません。(まさかこんなに長くなるとは…)

スプリントバックログ(続き)

  • スプリントを始めるたびにきれいなバックログが作られる(紙を張り替える)
  • 重要度の高いストーリーを上に貼る
  • バーンダウンチャート
    • 縦軸にストーリポイント、横軸に日付を取った折れ線グラフ
  • 危険な徴候
    • 線が上にふくれる:見積りより遅い。バックログアイテムを減らす
    • 線が下に下がる:見積りより早い。バックログアイテムを増やす
    • 下のストーリーから終わってる:重要度を間違ってる!
    • 計画外アイテムばかり終わってる:スプリント計画が…!!
      • 計画外アイテムとは、文字通りスプリント計画になかったアイテムのこと。
      • (アイテムって言葉は、ストーリーまたはタスクのことかな?)
  • トレーサビリティはどうなってるんだ!
    • 毎日デジカメで撮る
    • でも、そんなに重要じゃないはず
    • 気になるならホントの価値を見積もってみよう
  • 見積単位
    • 1実効人日=6実効人時
    • (7や8じゃないし、ましてや10や13なんかじゃない!)
    • ストーリーは時ではなく、日単位で見積もっている
    • 0.5が最小

チームの部屋をどう改造するか

  • 設計コーナー
    • のびのびと設計できる(日本じゃ難しそうだ〜)
    • 重要な設計ドキュメント、タスクボードなどを貼る
  • チーム全員同席!!
    • 席を移動するのはめんどい。でも、効果的なチームを作りたいなら他の選択肢はない
    • 大事なこと:声の届きやすさ、目の届きやすさ、隔離されていること
    • 専用の部屋があれば一番良い
    • POはチームと同席すべきじゃない (近くにはいたほうがいい)?
    • マネージャやコーチは、緊密に関わるべきだが、あるときは自律に任せること

どうやってデイリースクラムを実施するか

  • タスクボードの近くで、毎朝、立って話す。ポストイット、バーンダウンチャートを更新する
  • ルールを決めて、それを一貫させること
  • スクラムマスタが全部やるのは非効率
  • (最初に運営ルールをまとめておくのは大事そうだな)
  • 遅刻したら缶にコインを入れる。溜まったお金はチームのイベント等に使う(これ面白い)
  • やることがない人がいたとき
    • タスクボードを流して、考えさせる
    • ペアプロする
    • 終わってないものがないかチームに尋ねる
    • 次のスプリントから追加する (POに知らせること)
    • それでも駄目なら…
    • (なるべく自律的にタスクを発見できるように人を育てるのが大事ぽい…)

スプリントデモをどうやるか

  • デモは、何があってもしなければならない。たとえできていなくても!
  • 厳しいルールだが、得られるものは大きい
    • 目標が毎週達成されるので士気があがる
    • チーム外の人にも結果がわかる。チーム間のやりとりが発生する
    • お客から生のフィードバックがある
    • 確実に作業を「完了」できる (99%の未完より、少ない完了)
  • チェックリスト
    • 成果物がなにかを説明できてるか
    • 準備に時間をかけすぎてないか(派手なプレゼンは不要)
    • 美しくより、手際よく
    • 技術より、ビジネス視点で
    • できれば見ている人に触ってもらう
    • あんまり細かすぎる話はしない
  • 「10000ユーザの負荷テスト」みたいなデモできない話は、テスト結果レポートを見せて説明する、のでもよい

スプリントのふりかえりをどうやってするか

  • 起こったことを明確にする。改善の大切な機会
  • チームの外の部屋ではやらない
  • PO+チームで実施
  • スプリントバックログを見ながら、できごとを一巡りする
  • 見積と実際の速度がちがうところは、要因を分析してみる
  • 次スプリントへむけてのブレスト。良かったこと、もっとよくできそうなもの、改善点 (KPT?)
  • それらにチームで投票し、次にやることを決める
  • チームが得たナレッジは他のチームにも共有した
    • マネージャが非公式に動き、他のチームのふりかえりで広めたりした
  • 問題を明確に認識さえすれば、それは自然と解決していく
    • なにか不平を言うたびに新しいやり方を導入していると、みんな問題をあげるのが嫌になってしまう
  • 典型的なふりかえり事項
    • 「ストーリーをブレイクダウンする機会をもっと増やそう」
      • 問題を認識したことで、次のスプリントでは皆がそう動く
      • 繰り返し起こるならスプリントの期間を長くする
    • 「外部の邪魔が多い」
      • フォーカスファクタを低くする
      • 邪魔する人をメモっておく
      • スクラムマスタかPOを通すよういっておく
      • 持ちまわりで「ゴールキーパ」を設定し、そこに全部の邪魔を流すようにする
    • 「仕事抱えすぎた」
    • 「作業環境がうるさい、汚い」
      • 環境を改善するか、いっそ移動する。上位管理者への働きかけ
      • (これは気にする人と気にしない人の同居がむしろ問題になったなー、自分の場合)

スプリント中の休憩期間

  • 休まないと死ぬる
  • スプリント間に休憩期間がまったくないと、チームもPOも情報を整理する期間がなくなってしまう
  • スプリント振り返りとスプリント計画はちがう日にする
  • 「自由研究日」を設ける (Googleみたく)

リリースの計画と価格確定させた契約をどうするか

  • この質問に答えるよう試みる:「この新しいリリースバージョン 1.0 を、最も遅い場合、いつ納品できるのか」
  • 価格確定された契約の場合、最終的になにを納品すべきか判別するために、重要度に「しきい値」を設ける
    • 例:重要度100以上のアイテムは1.0に含めないと死刑に処される。
    • 例:50〜99は含めるべきだが、速やかな追加リリースでもいいかもしれない。
    • 例:etc...
  • 重要度の高いアイテムは、あらかじめ見積もっておく必要がある
    • 正確さのため、チームに見積もらせること
    • あまり時間をかけすぎないこと
    • 見積は確定したものではないことを理解すること
  • フォーカスファクタを決め、チームのスプリント速度を見積もる
  • ここまでできたら、最終的な納品日までの期間に、ストーリーを重要度順におさめていく
  • 現実はそのとおりにはいかない。スプリントごとにお客さんと調整しよう
  • 真剣に学びたいなら「アジャイルな見積と計画づくり」を読もう (うう、買ったけど未読…)

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

ScrumとXPの結合

  • XPはプログラミングに、Scrumはマネジメントと組織に、それぞれフォーカスしている
  • かぶってるプラクティスはScrumに従った
  • ペアプログラミング
    • コードの品質が高まる
    • 相互チェック「おいおい、この機能はほんとにこのスプリントに必要かい?」
    • 非常に疲れるので常にやるのは無理
    • 知識がすごい早さで共有される
    • ペアプロがあわない人もいる
    • コードレビューも兼ねられる
    • 強制はしないこと
  • TDD
    • 難しい。習得に時間がかかる
    • ペアプロで習得するのが効率的
    • 設計によい影響をあたえる
    • 新しく立ち上げたチームで始めるには時間がかかる
    • しかし、得られるものは大きい
    • 既存の(TDDでない)システムでTDDするのはとても大変
    • 手動の回帰テストを楽にする方法を先に考えること。TDDはそのあとでもよい
  • インクリメンタルな設計
  • CI
    • CIサーバは審判
    • チェックイン→ビルド→失敗するとメールが来る
    • 仕組みをつくるのは手間がかかるけど、その価値はある
  • コードの共同所有
  • 情報満載の仕事場
  • コーディング規約
  • 安定したペース、活気ある作業
    • すぎた残業は、生産性と品質を犠牲にする

テスト

  • 受け入れテストは避けられない!
  • チームのコード品質をあげることで期間短縮はできる
  • テスタをチームに入れる
    • テスタは「完了」を通知してくれる。デモにも最適
    • まだテストするものがないときは、環境づくりをする
  • スプリントの作業量を減らし、受け入れテストサイクルを短くする
  • 次のスプリントで、受け入れテストチームが発見した前のスプリントのリリースのバグを直すはめになる
    • 混乱する
    • うまい解決策はあるのか?
    • 1:古い機能が未完成であるうちは、新しい機能に手を付けない
    • 2:新しい機能に手をつけてもいいが、古い未完成の機能を優先する
    • スプリントの間に長さ不明なリリース期間を設けるのは、スプリントのリズムを崩すのでお薦めしない
  • 受け入れテストから戻ってくるバグフィックスを考慮にいれてスプリント計画を立てる
  • 良いテストツールや自動テストを使おう

複数のScrumチームを運営する

  • 大きすぎる少数のチーム > 小さな分割されたチーム
  • バーチャルチームの存在
  • チーム分割は本当に難しい
  • 最適なチーム規模は 3-8 人
  • 複数チームのスプリント期間は同期させたほうが効率的
  • チーム割り当て
    • 最初だけえらい人が決めて、あとは自律的な解決にまかせる
  • コンポーネント(DB, フロント等) に特化したチームはうまくない
  • チームを再編成するときは、それが一体化を壊す可能性を意識する
  • 「一時的なチームメンバ」を入れることはよくない
    • ("客先常駐"の商売とは相性が悪い考えですな)
  • Scrum of Scrum
  • (この項、あまり理解できていない)
    • だいたいは報告の場になる。大抵の人は情報に飢えている
    • デイリースクラムを同時に行わないことで、POやマネージャが参加しやすくする
    • 火消しチームにScrumチームを守らせる
  • 複数チームがいる場合も、POとバックログは1つ

地理的に離れたメンバーがいる場合

  • Webカメラ、ヘッドセット、会議マイク、デスクトップ共有などのツールを駆使する
  • 別の拠点につながる「遠隔ウィンドウ」をつくる
  • 定期的にお互いを尋ねる(物理的に)
  • オフショア開発
    • 離れたチームではなく、離れたチームメンバからはじめた
    • 最終的には、離れたチームに行き着くだろう
    • (あまのりょーさんの MY JOB WENT TO VIETNAM? を思い出しました)
  • 在宅勤務
    • 全員同席プラクティスとの兼ね合い
    • Skypeでデイリースクラムに参加
    • 特定の日だけ在宅にするとか
    • (チームによって適切な方法はかわりそう)

Scrumマスタチェックリスト

ここまで。明日のCSMが楽しみ!
大切な事は、自分の仕事の現場で最良な方法をつねに模索し続けることだと理解しますた。