ルニラボ

lni_T の長文置き場

マイナンバーカードが初めて役に立った話

概要

  • マイナンバーカードを使用する。あなたは任意の枚数の住民票を得る。

内容

数年住んだ住処を離れて別の街に引っ越すことになった次第のルニ君
新しい部屋の物件契約時に住民票が必要に

平日はおしごと、土日は夕方まで寝てるマ ンで役所に行くのが大の苦手なルニ君は困り果てていたわけだが
この度便利な方法が見つかったのでメモ

www.lg-waps.jp

こちら、マイナンバーカードを掲げることでコンビニで住民票の写しが手に入るというもの。

実際の感想

セブンイレブンで試してみた。
コンビニコピー機にマイナンバーカードのIC読み取らせてパスワード入力すればそのまま住民票が取得できる感じ。

おわりに

マイナンバー、こんな風に人間の手を介さず認証できれば便利そうだったんだが…どうしてこうなった…
まだ人間に認証認可は早すぎたのだろうか…
とりあえず役所の人はゼロ知識証明のページをチラッと読んで欲しい

ゼロ知識証明 - Wikipedia

ちなみに転出・転入届もマイナンバーカードがあれば書類を発行せずに役所の職員がシステムに入力にすれば完結するらしい。そのシステムWebに公開してくれ頼む。

名探偵コナン から紅の恋歌 感想【ネタバレ有り】

はじめに

劇場版名探偵コナン 見てきました。

コナンに登場する女の子の中で誰が一番好きかっていうと和葉ねーちゃんなので、こりゃあ見に行かねばなとなって行ってきた次第。

というわけで、ネタバレ有り感想をTwitterに書くのは外道のすることなので、こっちを活用していきましょう。 百人一首がキーワードになっている映画ですが、授業で習っただけで全然分からんので、そっちと絡めた感想はないです。

ちなみにネタバレ無し感想は↓

ネタバレ有り感想は「続きを読む」から

続きを読む

Jenkinsの「シェルの実行」でgrepやdiffを使った際途中でジョブが失敗してしまう問題の解決法

問題の現象

  • Jenkinsのビルド手順の「シェルの実行」でgrepコマンドやdiffコマンドを使った際、実行結果が"不一致"だった場合のみジョブが中断され失敗扱いになってしまう問題が起きたので困っていた
  • すんなり解決できたのでメモ

解決方法

  • 「シェルの実行」先頭に以下を記載する
#!/bin/sh
  • 詳細は下に記載

詳細

原因

  • Jenkinsのシェル実行はデフォルトでは/bin/sh -xeで実行される(実行結果参照)
  • それぞれのオプションの意味は以下
  • このeオプションが原因となって発生している
    • grepの検索やdiffの比較は、一致しなかった場合0以外の終了コードを返す仕様になっているため、スクリプトがexitしてジョブが失敗してしまう

解決方法

  • 「シェルの実行」先頭に以下を記載する
#!/bin/sh -x
  • これを記載することで、-eオプションを指定しないシェルでコマンドが実行されるため、途中で0以外の終了コードが返っても続けて実行することができるようになる

リスク

  • 当然他のコマンドが0以外の終了コードを返しても処理が続くため、本当に予期せず失敗したコマンドがあってもジョブが中断されず処理が進んでしまう。成功/失敗検知を正しく行わないととJenkinsは「成功」と判定してしまうため事故の元になる

参考資料

結婚式に招待された場合のTips

2回ほど結婚式にお呼ばれしたので、忘れがちなノウハウを今後のためにメモする

準備

服装

スーツ

  • なるべく早めに無事かどうかを確認する
  • 白っぽい汚れがあったらエタノールまたは重曹水を吹きかけてキッチンペーパーで叩くように拭く
  • ダメそうならクリーニング
  • 安否確認が済んだらティッシュをポケットに入れておくとイザという時活躍する

ズボン

  • 無事かどうかを確認する
  • ダメそうなら洗う
  • 洗う時はポケットにティッシュが入ってないことを念入りに確認すること

ネクタイ

  • 明るい色で

ベルト

  • フォーマルな奴を枕元に置いて寝る

ポケットチーフ

  • 意外と忘れがちなので注意
  • 寝る前に折ってジャケットのポケットに挿しとくと良い

革靴

  • だいたいホコリ被ってるのでキレイにする
  • キレイにしたら革靴以外の靴を全て靴箱にしまい、革靴だけ出ている状態にしておく
    • 出発準備整えて玄関に行く時はだいたい油断してるので靴を履き間違える確率が高い

持ち物

御祝儀袋

  • 組み立てが簡単そうな奴を買う
    • 飾りとかが付けにくそうなのは避ける
  • 「筆ペン」の準備を忘れない
  • 内袋はのりづけしなくてもよい
  • 慶事の場合は袋の上側->下側の順に折る(袋の下側が上に来るように折る)
    • 弔事の場合は逆
  • 招待状に名前が書いてある場合はその書体をお手本にして名前を書くと書きやすい

新札

  • 平日に銀行には行けないので潔く諦める(ごめんなさい)
  • コンビニATMガチャで出てきたキレイなレア諭吉に重石を乗せてピン札にしよう
    • タオルの上からアイロン当ててもいいらしいがやったことはない
  • 経験者曰く開ける時は「ヒャッハー!金だー!」ってなってるらしいので厳密に新札でなくとも許されるか…!
    • 大事なのは金額ハートだ

ふくさ

  • 御祝儀袋が完成したら前日の内にふくさに入れてジャケットの内ポケットに入れておく

Google

  • 以下をググっておく
    • ポケットチーフ 折り方
    • ナプキン 折り方
    • ナイフ フォーク 順番
    • パン 食べ方
    • (目的地へのルート)

当日

出発前

  • 鼻炎薬を飲んでおくと式場で楽

式場

  • 想定と違う食器が置いてあったら説明を待つ
  • メシの量が少ないのと洋食ならワインがメインなのでいつも以上に酔いに注意
    • 緊張してれば酔わないとかのたまう奴も居るがそういうのは元々飲めるやつの台詞
    • 無理そうならお水をもらう

終了後

  • スーツを干しておく
  • ネクタイ・ポケットチーフ・ふくさをセットにして保管しておく
    • できれば筆ペンもセットで失くさないように
  • 引き出物のカタログギフトは申し込み締切に注意

結月ゆかり誕生記念生放送 最新発表情報メモ

放送

live.nicovideo.jp

情報

覚えてるとこだけメモ

  • 描きおろしイラストによる新衣装追加
  • 結月ゆかりExVOICE単体ダウンロード販売
  • 結月ゆかりシルバーリング
  • 結月ゆかりキーボード
  • 結月ゆかり自転車
  • AHSボカロライブ
    • 2/28のゆかオン即売会後に開催
    • 12/21(月) 20時の生放送で続報
  • ドイツ開催のイベントでゆかりさんコンサート
  • MMD公式モデル配布
  • 結月ゆかり凛フィギュア制作中
  • 結月ゆかり等身大フィギュア制作決定
  • チヒローズ誕生祭 1/24
  • 12/21(月)の生放送重大告知
    • 業務中だぁぁぁ

IkaDB! と 個人サービス開発の楽しさと学び

はじめに

本記事は Splatoon Advent Calendar 2015 - Adventar の12日目の記事です。
一時は枠が埋まっていたカレンダーですが、ふと見ると1日だけ枠が空いていたのでノータイムで飛び込んだ所、「深夜リリース」->「RubyKaigi1日目」->「今日」というコンボをくらい自爆してしまいました。
そんな訳で、今日は個人で開発したサービス「IkaDB!」と、開発時の楽しさ/学び をいくつか紹介します。

IkaDB!とは

ikadb.herokuapp.com

IkaDB!は以下の機能を備えたWebサービスです。

  1. ブキの条件検索ができる!
    • 「ダイオウイカかバリア持ちのブキ」「射程が#{自分の使うブキ}以上のブキ」など、知りたい条件のブキを一覧化できます。
  2. ギアの条件検索ができる!
    • 「メインがマーキングガードでサブに攻撃力アップがつきやすいギア」「Ver2.3.0で新しく増えたギア」など、こちらも知りたい条件のギアを一覧化できます。
  3. ギアパワー影響を含めたダメージが計算ができる!
    • 「攻撃力アップ」「防御力アップ」によるダメージ増減を計算し、何発当てれば相手を倒せるかを計算できます。
    • 倒すのに必要な弾数が増減するギアパワー数が分かるため、「ギアパワーを何個積むのがいいか」の考察に利用できます。

主にwikiが取り扱っている情報の引き出しを楽にする機能を搭載しています。

月間のセッション数は約3万、ユーザー数は1万ちょっとまで伸びており、当初の考えよりも多くのユーザーさんにご利用いただいております。

作った理由

Splatoonは発売直後に会社の休憩室でプレイ(WiiUは先輩の私物)しドハマリし、その後ヨドバシに直行して本体ごと購入して日がな一日プレイする生活を送っていました。
※その時のわたし

その頃(ゲーム発売後の6月頃)、装備についての情報収集源といえばwikiくらいしか存在せず、「量が多いしCtrl+Fで探すの大変!」という状況でした。
その時の「じゃあなんとかするかー」の精神で生まれたのがIkaDB!というサービスでした。

他にもいろいろ理由はあった気もしますが…

  • こういう系のサービスが登場するのは時間の問題だな…!なら今すぐ作らねば先を越される!
  • 就職して以来ほとんどできていなかった趣味開発がしたい!そろそろ何か自前でサービス作ってみてもいいんじゃない!?
  • 会社に閉じこもって、働いていればそれでいいの…?
  • 彼女にフラレたので現実逃避先が欲しいー

元々自分の困ったを解決するためのもので、深く考えず勢いで作ってしまった感があります。 こうして、IkaDB!は6月末にサービスを開始しました。
ゲーム発売のだいたい1ヶ月後で、振り返ってみるともう半年近く前で驚いています。

使っている技術/知識

開発面

Railsに関しては業務でもメインで使っているので慣れていたのですが、AngularJSやHerokuに関しては全く分からんマンでした。
とはいえ、せっかくなので触ったことのないものも触っていきましょうスタイルで開発しています。

ゲーム面

ブキ/ギア検索

スプラトゥーンの装備品のデータ構造はごくごくシンプルです。

  • ブキ
    • メインウェポン(射程とか威力とかの情報含む)
    • サブウェポン
    • スペシャルウェポン
  • ギア
    • ギアパワー
    • ブランド
      • (付きやすいギアパワー)
      • (付きにくいギアパワー)

上記で全てが完結してしまうので、どちらかというと実装よりデータのインポートの方が大変という程のシンプルさです。

IkaDB!では、それら装備品各要素のレコードが入ったDB、検索可能なAPIAPIにリクエスト送信/レスポンスを表示するJSで完結する簡素な構造になっています。 ゲーム1つ程度の情報量なら最初に全て読み込んでおいてフロント側で解決するほうが画面操作スピードは早くなりそうですが、 データの追加/修正がたびたび発生することを懸念して、画面更新不要で常に最新の情報を表示すべく、 検索操作毎にAPIサーバーにGETリクエストを投げる方式をとっています。

ダメージ計算

ダメージ計算式についてはここが詳しいのですが、本記事にも記載しておきます。
(計算式を解明した @acple 氏には足を向けて寝られません…)

スプラトゥーンの攻撃のダメージ量は、ブキの基本ダメージ × ダメージ倍率(ギアパワーにより変化) により求める事ができます。
が、このダメージ倍率の計算がかなり面倒で、じゃあここをJavascriptでやってしまおうかというのがこの機能になります。

ダメージ倍率は以下の計算で求めることができます(wikiの記載を借用)。

# ギアパワー数の合算
a = [攻撃メイン] * 10 + [攻撃サブ] * 3
d = [防御メイン] * 10 + [防御サブ] * 3

# 攻撃防御それぞれの倍率の計算
A = ((0.99 * a) - (0.09 * a)^2) / 100
D = ((0.99 * d) - (0.09 * d)^2) / 100

# 差分から最終倍率の計算
a >= dの場合(攻撃側が大きい場合)
倍率 = 1 + (A - D)
a < dの場合(防御側が大きい場合)
倍率 = 1 + (A - D) / 1.8

こうして得られたダメージ倍率にブキの基本ダメージを乗算することで最終ダメージを算出することができます。 ただし、各ブキにはダメージ上限があり、相手を倒すのに必要な弾数が減らないギリギリの値でダメージが上昇しなくなります。
例えば、わかばシューターは基本ダメージ28で相手(HP100)を倒すのに4発攻撃が必要になります。
ここで相手に防御力アップをメイン2つ・サブ2つ積まれてしまうとダメージが24.847となり、倒すのに5発攻撃が必要になります。
しかし、攻撃力アップをたくさん積んでもダメージ上昇は33.3で止まるため、3発で倒せるようにはなりません。

こう書くと攻撃力アップが無意味そうですが、そういう訳ではなく、「防御を積まれても必ず相手を4発で倒せる状態」となるため、相手の防御力アップを無効化するためには有効な手段となります。
わかばシューター以外にもこの現象が発生します(.52ガロン系やスプラシューター系など)
その他にもメイン直撃+クイックボムカス当たりの合計ダメージをキル圏内まで引き上げたりと、合計ダメージ100の境界で熾烈なギアパワーの読み合いが行われています。

この計算はどうしても機械に頼らざるを得ないせいか、提供している機能の中でもダントツの人気を誇っています。

サービス開発時にやって良かったこと

有識者との協力・使ってくれるユーザーの所へ持っていく

サービスできたての頃はまず知り合いのSplatoonプレイヤーや昔のギルドメンバーに見せていましたが、「ふーん」程度のリアクションでした。
使って貰える人を見つけようと考えた所、「自分は元々wikiを見ていたのだから、wikiユーザーに使ってもらえば良いのでは?」ということで、
スプラトゥーン(Splatoon) for 2ch Wiki*管理人である@prairial氏とコンタクトを取り、wiki内ページからリンクを貼らせてもらえることとなりました。
おかげでユーザー数も大きく伸びる結果となりました。

また、ゲームのアップデート仕様についてはprairial氏よりたびたび情報提供を受けており、IkaDB!の運営に大きく協力頂いております。
この場を借りて御礼申し上げます。

ページのアクセス解析

Google Analytics

IkaDB!ではページビューをGoogleAnalyticsで収集しています。これがかなりモチベーションアップにつながりました。 リリースした機能が使われているかどうかがらくらくリアルタイムで検知できるのでとてもニヨニヨできます。Fluentdとかの導入よりずっと敷居が低い。
ページ表示時以外にもJS内の任意のタイミングでトラッキングイベントを送信することでフロント側の任意の処理回数を集計することもできるのがGood.

リファラスパム排除

解析開始当初はアクセスきてるぜひゃっほーいと浮かれていたのですが、 どうもトップページ以外へのアクセスが少なく不審に思って調べてみると 「リファラスパム」(リファラ付きでアクセスしてそれを見たサイト管理者にアクセスさせる)がほとんどで人間のアクセスはほぼ0という悲しい事件がありました…

サラッと調べるとGoogleAnalyticsは「フィルター」機能で特定条件のアクセスを弾けるようで、「これで下記URLのリファラを弾け!」といった記事が多く見つかりました。
が、これだとイタチごっこ感がすごいので、「OSが(not set)」「言語が(not set)」とかの人間ぽくないアクセスを弾いて対応しています。

単体テスト

ド正常系が通るだけのテストコードでも書いておくと随分役に立ちます 書いてないとこういうことになります。

いろいろな事件を受けて一応、以下の単体テストフレームワークを導入しています。

  • RSpec (バックエンド用)
  • Jasmine (フロントエンド用)

が「c0なにそれおいしいの」レベルでカバレッジ低い(計測すらしてない)のが現状です…
とはいえ、テスト書いてる部分は通る事が保証されるので、幾分心安らかに開発を進めることができています。

また、Jenkinsによる自動テストの仕組みも導入を進めています。この辺は社内のCI環境がJenkinsなのでそれの勉強も兼ねています。

サービス開発時にやるべきだったこと

検索性の考慮

IkaDB!の致命的な弱点の1つとして、「ページの検索性が悪い」という点が挙げられます。
これは当初なんとかしようとしたのですがどうしてもGoogle上位に持ってこれず、検索結果 -> はてブnaverのリンク頼りになっています。

原因の1つとしてはサービス名が悪かったのかなあ…というのがあります。
初期の検索結果では、英字入力(ikadb)だとGoogleタイプミスではないかと疑われ、かといって日本語入力(イカDB)だと淫夢ネタに汚染されており…と散々な状態でした。
SEO周りはどうすればいいか今もよく分かってない状況です。

不具合情報の収集

一応動作確認はしているつもりなのですが、どうしてもバグだったりデータミスだったりが偶に混入します。にんげんだもの。
その辺からの学びの一つとして

  • 「直接バグ報告してくださるユーザーさんは貴重」

ということがあります。基本的に不具合は気にされないか、Twitterでぼやかれて終わってしまうようです。
サービス提供開始からしばらくの間はこの辺がおろそかになっていて、新機能をリリースしたものの、 メンション等で報告もらうまでしばらくバグに気付かず、気づくと既に何人ものぼやきツイートが流れていた…などという事故が多発していました。

  • 情報収集 大事

個人開発の楽しさ/嬉しさ

普段使わない技術を使える

普段の業務においては納期や保守について考慮する必要が有るため、ホイホイと新技術突っ込んだりもできず、またそういった時間が取れないことも多いのですが、 個人開発ではそういった制約もなく、のびのびと自由に開発することができました。
業務グラミングと趣味グラミングはやはり別物ですね。

普段はRailsB2Bの業務アプリケーション開発を行っているので、事前知識で持っていたのはRailsとDBの知識のみで、 AngularJSやHeroku、その他諸々突っ込んだものはほぼ知識0の状態からのスタートでした。 触ったことのないものを制約なくぽこぽこ触れるのは楽しいものです。

おかげで「ふろんと全く分からん」から「社内での議論に参加はできる」程度にはウデマエアップしたので、いい感じに実利も得られたのではないかなと思ってます。

感想がもらえるのは嬉しい

「自分用に作った」とは書いたものの、感想や改善提案がもらえるのは嬉しいものです。夜中に部屋でひとりニヨニヨできます。
なんだかんだ単純なもので「便利!」や「すごい!」などの声が聴こえるとウホホホーイとなるものです。
直接送信は気がひけるのであればツイートするだけでも作者に届いて糧になったりします。

万が一の事態が起きても…?

不具合発生などの失態をしても、業務に比べると遥かにダメージが少ないです。
もちろん発生後は落ち込むし反省もしているのですが、業務での失態の場合はどうしてもお金や信用、同僚や上司、その他諸々の要素に多大な影響があり、本当に胃の痛い事態になります。
それに比べればなんと楽しくお気楽でスピーディーな開発なのでしょうか。

ちなみに以下の様なことも起きました。

業務ならハラキリ不可避な事象が起きていますがどこか楽しそうです。 また、この後無事復旧して何食わぬ顔で運営を続けられています。
普段会社で大量の問題処理票消化や再発防止策提出に頭を悩ませている人は、 個人サービス開発で運用環境フッ飛ばしてカタルシスを感じてみるのもいいんじゃないでしょうか。

何を得て、何を失ったか

個人開発により得られたもの

  • 強さ

カンストどころかSにも届かねえ… (ヽ´ω`)

個人開発により失ったもの

  • 健康

  • 本業とうまく両立しましょう

おわりに

いろいろありましたが総じて楽しいことばかりだったので、日々モヤモヤを抱えている人は それを開発にぶつけて鬱憤を晴らしてみるのはいかがでしょうか!何か状況が変わるかも!

さらっと書くつもりが、IkaDB開発の総括のような内容となり、かなり長くなってしまいました…
最後までお付き合い頂きありがとうございました。 明日は13日目 @bkzenさんの記事となります。

夜勤メモ

  • 初夜勤だったので自分向けノウハウメモ
  • 効果には個人差があります

前夜

  • だいたい12時間くらいは眠っていられるので、出勤時刻の少し前までしっかり眠れるように前日夜更かししておく。
    • アニメ消化
    • スプラトゥーン
    • プログラミング
    • etc
    • やめどきを見失わないようにする
  • 近隣が工事中で昼間うるさくなりそうな場合は備えておく
    • 窓を閉める
    • 市販の睡眠薬を飲む
    • 耳栓
      • きもちわるくて使えなかった

当日

  • ビル内コンビニは24時間営業でない事もあるので兵糧に注意
  • 割り込みはないが、だらだら業務しても効率がでないので注意
    • 気付かない間にだらけやすい

後日

  • なるべくさっさと寝てリズムを戻す