<y>

Splatoonプレイヤー兼Webエンジニア

自分の現況

ポエム

7月からwebエンジニア始めて、もう半年弱経ったけど今の自分どうなの、というやつ。
年末に見返すことになると思う。

  • 今何が足りないか？
    => 金、精神的余裕、技術力
    • それらはどうしたら足りるようになるか？
      => 金は今すぐは無理で普段の業務をしっかりこなすことで増やすのが現実的。あと実家に戻る(来年本当に戻るかも)。技術力はまず書くコードの量が少なすぎ。精神的余裕は、どうすればいいか分からない。
    • 普段の業務をしっかりこなせているか？
      => no. 作業の遅延、集中力の欠如、その他問題だらけ。
      • その問題を解決しようと努力しているか？
        => 半分yes. 実際に解決できたかは別として取り組んだことはいくつか。
      • 具体的に何に取り組んだ？
        => ブルーライトカットメガネ買う、睡眠時間増やす、定時後の人が少ないときにガッと進める
      • それらは上手くいっているか？
        => 全部は上手くいってない。定時後でも集中切れるし、結局寝るの遅くなる日もまだ多い。今日もこれ書いてるからそうなると思う。
      • どうしたら上手くいく？
        => 意識の問題だけど習慣化できてない。ルーチン化しなきゃいけない。
  • 毎日のルーチンはどんなことをこなしているか？
    => wikihubの日報コミュニティに毎日日報を書くことと腹筋ローラー。
    • どれくらい続けているか？
      => 日報は半年弱くらい毎日、腹筋ローラーはつい最近始めた。
    • 日報はしっかりとした内容か？
      => 正直内容は薄い。毎日書き続けることが最優先だけど、それは出来てきているので、もう一段上のレベルを目指さなくてはと思う。
  • 毎日業務以外でコードを書いているか？
    => 書いていないし、これができていないのはかなり良くないと思う。
    • そもそも業務以外で毎日コードを書くためにはどうすればいいか？
      => 作りたいものを決める、気になる言語やフレームワークのチュートリアルをやる、とか色々ある。
      • それを毎日こなすためにはどうすればいいか？
        => これも習慣化だけど、結局習慣化するためにはモチベと強制力が必要。時間は無理やり捻出する。
      • 無理やり捻出する時間をどう作るか？
        => 結局普段の業務の密度を上げて作業時間を減らして早く切り上げるしかない。
      • 普段の業務の密度を上げるには？
        => 睡眠時間、あと分からないところが出てきたら質問する、「分からないこと」のハードルを下げる(自分の分からないという感覚を信用しない)、Twitterばっか見ないで最速で終わらせて業務後に時間作る、そのときにTwitter見ればいい。
  • 普段何かしらの知識や技術をインプット、アウトプットしてるか？
    => インプットはしている日としていない日がある。していない日は当然として、インプットをしている日でもアウトプットはほとんどしていない。
    • アウトプットを増やすためにはどうすればいいか？
      => 無理にアウトプットのことばかり考えるのはいいことかどうかわからないが、現状はしていなさすぎるので、せめて一週間に一回ブログ書くとかする。
    • インプットがない日はどう減らすか？
      => インプットが全くない日は体調悪いとか寝不足とかの日が多い。まずそれをなくすべき。
    • 技術情報を仕入れているか？
      => Qiitaで気になる記事はすぐストックするようにはしている。
      • その記事をしっかり読んで理解しているか？
        => そもそもストックして読んでいない記事がたくさんある。
      • どうやって記事を消化していくか？
        => 一日一記事、と思ったが、記事の内容量には差があるしどうすればいいか検討。
  • そもそもなんでSIerからweb屋に転職したんだっけ？
    => 知り合った強いエンジニアのように自分もなりたいし、コードたくさん書きたいと思ったから。
    • SIer時代に比べて自分は技術的に強くなったか？
      => 少なくとも前職のときよりは強くなった。でも所詮その程度。
    • 知り合った強いエンジニアと比べるとどうか？
      => 足元にも及ばないし、むしろ差が開いている気がする。
  • 何が足りないのか？
    => 習慣化する力と自分を律する力
    • どうすれば力はつくか？
      => 習慣化する力は少しずつついているはず。日報で。ただまだ足りないので、もう一つ、もう二つくらい習慣化する。一つずつ増やす。今は腹筋ローラーだけど、腹筋ローラーはあまり時間を割かなくてもできる。だから、もう一つ、毎日することを決める。
    • 具体的に何をするか？
      => 業務以外のコードを書く、というのが理想だけど。今それをやると挫折する気がする。Rails Tutorialを毎日30分やる、パーフェクトRuby on Railsを毎日10ページ進める、それのどっちかが現実的だと思う。まずRails Tutorialやる。年末を迎える頃にこれを読み返している状況でRails Tutorial終わっていなかったらかなり恥ずかしい。
    • どうすれば自分を律する力が手に入るか？
      => これは本当に自分のやる気次第な気がするが、もっと具体的で現実的ないい案はないものか。
  • その他に今の自分が変えるべきところは？
    => 土日遊ぶのはいいんだけど、予定がないときに何もしていなさすぎ。勿体無い。コード書く絶好のチャンスなのにだらけすぎ。

書いてて情けなくなってきた。だけどこれが現実だし、現実を見ないことには始まらないんだよな。

第五回splathonに参加してきた。

Splatoonが発売してから1年以上が経った今でも、その楽しさが色褪せることはない。
8/27(土)に開催されたsplathonも、それを象徴する楽しいイベントだった。

splathonとは

splathonとは、2015年5月28日に任天堂から発売されたWiiU専用ソフト「Splatoon」と、「marathon」(マラソン)を足した造語だ。
似たような言葉にハッカソン(hack + marathon)という言葉がある。こちらの記事によると、短期間でソフトウェア開発を行い、そのアイデアや技能を競う競技だ。
splathonは、株式会社Speeeさん発祥の言葉で、「数時間から数日間の短い時間、Splatoonに没頭して複数の参加チームで競い合って楽しもう」という、IT企業のSplatoon対抗戦イベントのことである。
詳しくは第四回のSpeeeさんのブログを参照するとよいかも。

参加までのいきさつ

基本的にはsplathonは企業対抗戦のため、企業毎にチームを組んで出場するのだが、今回は知り合いのバースト・インカーさんに誘われて即席チームで出ることになった。splathonは前から名前だけはちょくちょく耳にしており、楽しそうだな〜という印象を受けていたため、バースト・インカーさんが募集していた時にはすぐに飛びついた。
splathonまで残り一週間ちょっとという時期に即席で組まれたチームだが、自分以外ウデマエS+カンストというとんでもないチームになった。ちなみに自分の最高ウデマエはS+74、基本的にチャージャー(特にリッター)しか持てない。
当日までにある程度連携を深めるべく、毎夜タッグマッチや対抗戦を行っていた。毎夜Splatoonに没頭していたこの時点で、もうsplathonは始まっていたのかもしれない。

当日

会場は六本木にあるSpeeeさんのオフィス。非常に綺麗でオシャレ。

また、お菓子や飲み物などとにかく充実していて素晴らしかった。

参加チーム紹介

企業名パワーに圧倒された。相当レベルが高い。
自分は即席チーム「ポッポ」で参戦。なんとなく周囲のイカ界隈が「ポ」という感じだったからこうなった。雑ですまんな。

要注目はイカナカマを開発・運営し、前回のsplathonで大人相手に20キル以上出したという圧倒的戦績を出したスーパー小学生、通称"スパショ"を擁するしくみ製作所の「瀬賀高等学校水槽学部」、そして前回優勝チームKADOKAWAの「K/D2016」だ。

ルール

第五回splathonはイカのようなルール。

  • 全チームによるスイスドロー形式で試合進行。1回のラウンドで2試合行い、2勝なら勝点3、1勝1敗なら勝点1、2敗なら勝点0を得る。
  • ラウンド4か5まで行い、勝点上位4チームが決勝トーナメントに進む。
  • 1試合目は先攻チームがルール(ガチエリア/ガチヤグラ/ガチホコ/ナワバリ)を決め、後攻チームがステージを決める。2試合目は後攻チームがルールを決め、先攻チームがステージを決める。
  • ギアは「逆境強化(アタマ専用)」「インク回復量アップ」「スペシャル減少量ダウン」で固定。サブスロットにはなにもギアパワーがついていない状態。
  • 勝点等の理由で決勝トーナメントに参戦するチーム数が合わなかった場合や、決勝トーナメントで対戦成績が1勝1敗だった場合は、ステージランダムのナワバリバトル一本勝負を行う。

第1ラウンド

VS しくみ製作所

初戦でいきなり要注目チームとの試合が決まった。スパショぶっ潰す、社会の厳しさを教えてやるなどの物騒な発言を聞かなかったことにしつつ、戦いへ。
1試合目、2試合目ともに勝利、勝点3をもぎ取って第2ラウンドを待つ。

この間、他のチームの対戦で回戦トラブルが相次ぐ。

会場にはWiiUが16台もあり、いろいろと難しい模様。

はせがわさんが開発したこの4画面観戦システムで、待機中も楽しい時間が過ごせた。はせがわさんは寝過ごしたり逆方向の電車に乗ってしまったりと災難続きだったようだ。ほんとお疲れ様です。

第1ラウンド終了時点ではこんな感じ。

第2ラウンド

VS KADOKAWA

回線落ちによる再戦が相次ぎ、ポッポチームは第1ラウンドから第2ラウンドまで3時間ほどあった。自分も軽くウトウトしていたが、前回優勝チームとの戦いということで気合いを入れいざ出陣。
しかしまあ、対戦相手が対戦相手ということもあって緊張したのか、結果は2敗。それも結構ボコボコにされた。
マヒマヒエリアはリッターの得意なステージだったんだけど、焦りまくって振りかぶったダイナモを射抜けなかったりなどした。無念。ポ。

関係ないけどこういう素晴らしい環境でイカができて素晴らしかった。

第3ラウンド

VS BookLive!

ルールに少し変更があり、回線落ちによる再戦等で時間が押しているため、第3ラウンドまでの勝点で決勝トーナメント進出チームを選出することに。第2ラウンドで勝点を上げられなかった我がチームはこの試合が重要なポイントとなった。
しかし、決勝トーナメント進出の懸かる重要な試合でも冷静さを欠くことなく2勝。キンメダイホコで出したスコアが自分の第五回splathonにおけるハイライトとなった。

第3ラウンドが終了した時点での順位。

この時点で勝点9のKADOKAWA、勝点6のしくみ製作所と我等ポッポは決勝トーナメント進出が決定。残りの1チームを決めるためにこれから壮絶な戦いが始まる。

  • 勝点4の3チーム(pixiv、楽天、CyberAgent)の代表者がじゃんけんで勝者を1人決める。勝者の所属チームには謎の勝点1が与えられる。
  • 勝点5の3チーム(シャープ、NHN、四社連合)+謎の勝点1付与により勝点5になったチームの計4チームでステージランダムのナワバリ一本勝負のトーナメントを行い、優勝したチームには謎の勝点1が与えられる。
  • 勝点6以上の3チーム+謎の勝点1付与により勝点6になったチームの計4チームで決勝トーナメントを行う。

まずは熱いじゃんけん大会、勝ったのは楽天。続いて熾烈なナワバリバトルを制したのは四社連合だった。

決勝トーナメント1回戦(準決勝)

VS 四社連合

へへへ、repeatedlyさんへの日頃の恨みを晴らしてやるぜ…！(※日頃の恨み等の感情は一切ありません)

1試合目はハコフグエリア、2試合目はキンメダイエリアだった。見事2勝、完全にチームメイトのおかげ。キンメエリアで20k出したロンカス持ちのタイビィくん、ダイナモとスシコラとロンカスとホッカスとハイカスでカンストしてます。いみわからん。いっこわけてほしい。

決勝戦

VS KADOKAWA

決勝の相手は、準決勝で"スパショ"率いるしくみ製作所を倒し、第2ラウンドで我々も辛酸を舐めさせられた因縁の相手KADOKAWA。 1試合目はモンガラキャンプ場ガチヤグラ。自分は普段から使っているリッターを持たなかった。このステージはメガホンレーザーが刺さりやすく、相手にリッターがいない状況(今までのKADOKAWAの試合を観戦して考察)なのでメガホン持ちのスプラスコープワカメを持った。
熱い展開が続く中、自分達がカウントリードを奪った状態で相手がヤグラに乗り試合は延長戦へ。

しかしここでヤグラを止めることができず、カントリードを奪われ逆転負けを喫する。

メガホンレーザーを撃って試合を終わらせに行こうとスペシャルゲージを貯めたものの、メガホンを撃つ前にキルされる始末。おお情けないことよ…！

2試合目はキンメダイホコ。
タイビィくんが空中ホコ直撃を何回か決めていなければ負けていた。タイビィゲーである。いやほんと何も出来なくて申し訳ねえ…KADOKAWAマジ強いんですよ…。
というわけで、なんとか1勝1敗に持ち込んだ。運命はステージランダムのナワバリ一本勝負に託されることに…。

ラストのナワバリのステージはモズク農園に決まった。自分はリッター持ちたい！って言ってリッター持ったけど、正直モズクのような広いステージだったら、もっと塗りブキで来るべきであった。キル重視のスタイルで味方の塗りを促進できれば…と思っていたが、最終的なキルデスは1/0というなんとも貢献できていない感の滲み出るスコアとなった。
このナワバリで勝負あり。優勝はKADOKAWAで、我等ポッポは準優勝となった。

KADOKAWAさんほんとおめでとうございました。

懇親会

splathonにはIT企業所属員のチームのみが参加しているため、凄いエンジニアの方がたくさん来場していたりする。
自分も7月から新米のエンジニアとして働き始めた身なので、色んなエンジニアの方と交流したい！という思いがあった。が、人見知りが盛大に発動して、情けないことにほとんど誰にも話しかけられなかった。非常に勿体なかった。次の機会があれば、色んなエンジニアの方と交流するチャンスを絶対に逃さないようにしたい。

寿司肉ピザで全員優勝。

LTタイム

今回は「スプラトゥーンにおける自分なりの立ち回り」というお題で数名の方がLTするという企画があった。

こんな感じでLTの評価は高く、聞いていて面白かったしとても有意義だった。
LTの資料はイカに貼っておくので、ぜひ見てみてほしい。

speakerdeck.com

speakerdeck.com

speakerdeck.com

閉会

初参加な上に即席というチームだったが、今回は準優勝することができた。 チームメイトの素晴らしい活躍に感謝したいし、もっとチームに貢献できるようなチャージャー使いになりたい。

帰宅してなおSplatoonに勤しむ面々

今回は声優志望の方が実況で場を盛り上げてくれた。実況があると楽しさが増して非常に良かった。 実況してくれた方はこちら。

終わりに

改めて運営してくださった皆さんにお礼を言いたい。
非常に楽しむことができたし、次回があればまた参加したいと強く思えるようなイベントだった。
次こそは優勝するためにもこれから鍛錬を続けていきたい。
本当にありがとうございました。

日報 2016/08/16

今日ちょっと正規表現の沼に足を取られてしまったのでそれを書いていきたい。

やろうとしたこと

Ruby on Railsでアプリケーションを作っていて、「お知らせ」(notification)というモデルを新規に登録する際に起きた話。
「お知らせ」にはタイトルや登録日といったプロパティがあるのだが、今回問題になったのはURLというプロパティ。URLにはwebページのリンクが入るのだが、このURLリンクをユーザーが入力する際のバリデーションをどうするかという話になった。
「rails url バリデーション」といった言葉でググると色々出てくるのだが、結論として「こちらがどんなに精密にURLのバリデーションチェックをしようが、ユーザーが存在しないURLを入力したら意味がなくなる。形式的なバリデーションは出来ても、ユーザーの入力によっては無力だ」という話になった。これにはまあ色々な意見があると思うのだが、今回作成しているアプリケーションは、一つの企業の組織内の人間だけが利用するものなので、精緻なバリデーションは不要だろうということになった。

本題

今回のバリデーションの内容は、「全角と半角カタカナのみを禁止にする」というものになった。早速ググッて色々調べたらなにやらよさげな正規表現が。

 /^[ -~。-゜]*$/

正規表現において、^は行頭、$は行末を表す。つまり上記の正規表現は、行頭〜行末の間に、半角の文字が一文字以上入っていれば大丈夫という旨だということ。
なるほど、これなら良さそうだと思い、モデルクラスに

validates :url, format: { with:  /^[ -~。-゜]*$/ }

と記述してサーバーを再起動し、お知らせの新規登録画面に遷移しようとした。 そして表示された画面がこちら。 f:id:yklitter:20160818000454p:plain

エラーなのかと萎えつつエラー内容を読んだら、
「その正規表現は複数行向けのアンカー(^と$)を使っているけど、脆弱性があるよ。\Aと\zって知ってる？それとも:multilineオプションをtrueにするの忘れた？」という内容だった。(英語が苦手なので誤訳があったら大変申し訳ない)
脆弱性？と思い調べてみたら、Rubyの正規表現機能はデフォルトで複数行モードになっているとのことだった。
例を挙げると、/^[a-z]*$/という、「半角小文字アルファベットだけで構成された文字列ならおk」という正規表現バリデーションに、

ほげふが全角
hogefuga

という複数行の文字列を通そうとすると、通ってしまう。
これは、半角小文字アルファベットだけで構成された文字列「の行がある」という理由でバリデーションを通過する。「^」はあくまでも行頭であり、行の頭であれば問題無いと判断されるようだ。
これではバリデーションが意味をなさなくなってしまい、セキュリティリスクがある。そのため、^と$の代わりに「\A」と「\z」を使う。「\A」は文字列の先頭、「\z」は文字列の末尾を表すとのことで、なるほどこれなら複数行でも問題なさそうだ。
railsはこのようにセキュリティリスクがある正規表現をArgumentErrorとして表示してくれるのか…と感動してしまうワンシーンだった。

その後

\Aと\zを使って、/\A[ -~。-゜]*\z/に書きなおしたぜ！と意気揚々と「あいう」という全角文字列をURLの入力欄にぶち込んだら、あっさり通過してしまった。あれ…。
全角アルファベットが含まれているとしっかりとエラーメッセージを吐くのだが、日本語のみだとすんなり通る。
マジか…とげんなりしていたところ、どうやらShift_JISの場合のやり方らしい。正規表現沼と文字コード沼はつながっていた…。
で、まだどうするかを模索中。
沼は深い。

参考にしたサイト

Ruby正規表現で全角と半角のチェック(バリデーション)する

正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう | 徳丸浩の日記

qiita.com

近況

ここ最近こちらで書いていなかったので、書いていこうと思う。

日報

WikiHubには変わらず毎日ちまちまと日報を書いている。
内容は薄いけど、毎日書くことに意味があるのかなと思うし、その日の夜にどんな感じだったかな〜というのを思い出すっていう行為をしているだけでも有意義なものであると思う。

業務

基本的にはRuby on Railsを用いて一般的なCRUDの機能を持ったアプリケーションの開発をしている。
何度も書いているが、Ruby on Railsに関しては完全に初心者なので、とにかく分からないことは聞いたり調べたりしながら無理やり進めている。
本当に暇な時間にRailsチュートリアルを少しでも進めておくべきだった…。今はまだ3章途中で、ゴリゴリ進めていきたい。
あと最近はロジックの部分が大体できてきたので、SQLとかjavascriptとかも触っているのだが、とてもつらい。
postgreSQLを利用していて、ストアドプロシージャ作ったりしている。PL/pgSQLって何…という状態だったのでそれなりにヤバい。

メモ

普段から分からないことだらけなので当然のように調べたことをメモしたりしている。
最初は色々メモアプリを探していたのだが、結局OS Xにデフォルトで入っているメモアプリが一番使いやすい感じだったので今はそれを使っている。
最近よく予期せぬ理由で頻繁に落ちるので納得いかない。

集中力

特に今週顕著だったのだが、集中力が全然ないことに気付いた。今更だけども。
昔から集中力がなかったのだが、もはやそんなことを言っていられないので、どうすればいいのかを少し考えている。 一日中ずっと集中力がないわけではない。集中できるときは集中しているのだが、できないときは本当にできない。
少しの時間帯に強靭な集中力を発揮するのではなく、コンスタントにそこそこな集中力を発揮したい。
集中力が切れるタイミングは、まあ普通に疲れた時もそうなのだが、最も顕著なのは、
「やらなきゃいけないことに対して分からないことばかりすぎる(自分の知識だけで解決できそうにない)時」
だと思っている。
新しいことを自分の頭に取り込むときは刺激があり楽しいのだが、それが「分からないことに直面したから調べる」という状況だと、体力の消耗が激しい、気がする。
体力の消耗が激しければじゃあ体力をつけろという話になる。実際、肉体的な体力は非常に重要なポイントだと思っているので、筋トレをすることはかなり有益だと思う。筋トレしようかな。

小目標の可視化

ダラダラと目標もなく作業しているとだらけがちになるので、小さい目標をいくつも立てていって、更にそれを可視化することで、やらなければいけないことを明確化して作業効率を上げようと企んでいる。
方法として、メモアプリで以下のように記述して明確化している。

  • 小目標を書く際は"#"を文頭に書く。
  • 小目標を達成したら、"#"を文末に書く。
  • 達成していない小目標より下にはメモを書かない。

具体的には↓

メモメモ〜〜〜メモメモ〜〜
メモhogeメモfuga
# 目標1 #
メモメモpiyopiyo
# 目標2

上記の例だと、目標1は達成済み、目標2は未達成ということになる。
こんな感じでやっているのだが、何もしないよりはまあマシという感じになっている。
他にいい方法があれば教えてください…。

その他

他に集中力を高める方法としてはガムを噛むというのがあって、これが地味に効いている、と思う。
あとはやっぱりちゃんと睡眠をとること。これが本当に大事。まだ自分に最適な睡眠時間とかしっかり把握できてないので、しっかり把握していきたい。
あとお金貯まったらいい寝具を買いたい。絶対貯まらないと思う。

日報 2016/07/25

最近サボっているというわけではなく、別のところに日報を書くことにして、こっちはそのまとめ的なものとして使おうかなという体制にしようと思っている。
ので、サボってはいない。

WikiHub

今日報を書いている場所はWikiHubの日報コミュニティ。そもそもWikiHubは、r7kamuraさんが作ったWikiで、色々なコミュニティがあったりする(とても雑な説明だが)。
ここでは「日報」というコミュニティがあり、色々な方(主にエンジニアが多い)が日報を書いている。
エンジニアが気軽に書いた日報を気軽に読めるというのもあって、はてなブログよりも記事の公開に手間がかからず気楽だし、自分もここで日報を書いてみようかな〜と思い始めた。
はてなブログでは毎日書くことはほとんど叶わなかったが、WikiHubはより手軽感があり、それに加えて"進捗とかプログラミングのこととかじゃなくても、とにかくなにかを日報として書いた方が長続きしそうだな"という個人的な所感もあって、WikiHubを日報の場にすることにした。
はてなブログには、WikiHubで書いた日報を軽くまとめたりしていく形で更新しようかなというスタンスで行こうと思う。

ポケモンGO

Lv.14だけどイーブイに2回遭遇して2回とも逃げられたからまだイーブイがいません。

業務とかプログラミングのこととかはまた別の機会に(もう寝ないとつらい)

日報 2016/07/18 -今日は特に何もしていない-

Ruby on Rails

この三連休で何かしたというわけではないんだけど、とりあえず今引っかかってるところを書いてみようと思う。

確認画面

例えば、記事を投稿するにはnew、記事を編集するにはeditというactionを利用するのだが、両者ともに「確認画面」というものを表示したい。
記事を新しく書いて「確認」ボタンを押すと、書いた記事の内容とかがバッと表示されて、良ければ「投稿」、修正したければ「戻る」ボタンを押す、という構造は見たこともあるだろうと思う。
で、例えば「タイトル」「記事」「公開設定(全体とか知り合いだけとか)」みたいな項目を入力して公開し、修正したいなと思ったら編集ボタンから上記の内容を編集できるといった、ごく一般的な機能をRailsで作成している。
新規投稿する際も編集する際も、ユーザーが入力する項目には変わりないので、Viewを使いまわしたいと考えた。
流れとしては

一覧画面
↓
action: new / action: edit
↓
新規投稿画面 / 編集画面
↓
action: confirm
↓
新規投稿確認画面 / 編集確認画面
↓
action: create / action: update
↓
一覧画面

といった構成にしたい。 routesにconfirm書いたりして周辺準備は整えたのだが、どうも上手く動かない。
「一覧画面→編集画面」に遷移して既にある記事を編集し、「確認」ボタンを押下して確認画面に遷移するのだが、遷移先が「新規投稿確認」になってしまう。
確認画面でnew_record?メソッドを使って新規か編集かを確認で表示しているのだが、編集画面から遷移した場合でもtrue(新規)と表示されてしまう。

ぶっちゃけ全然分からない

この三連休でなんとかして原因を探り解決しようと思っていたが、予定が入っていたり未だにネットが繋がっていなかったりして作業時間を確保できなかったため、とりあえず疑問を投げるだけのブログを書いていてる。
ネットに関しては、Try WiMAXでお試し15日間無料で無線ルーターを借りることに成功したので、それでどうにかネットには繋いでいる。
そろそろ眠くなってきているので、明日辺り業務で解決したら解決した旨の記事を書こうと思う。こんな記事で申し訳ねえ。

ざっと近況

あまりにも内容が薄いので、今回は近況をメインにした記事だということにしようと思う。

金銭面

とにかく金銭的に余裕がなく、どうしようもないくらいお金が無い。
今週はお昼も近くのスーパーで安く済ませてどうにか凌ぐしかないと考えていて、栄養〜とかコスパ〜とか野菜〜とか言っていた一ヶ月前の自分とはおさらばすることにした。でないとやっていけない。 後述の理由で自炊する気が現状起きないので、どうすればええんやといった感じ。

衛生面

7/4に害虫駆除業者に対策施工してもらって依頼、生きたGは見ておらず、ホイホイにかかったヤツも見ていない。
しかし、昨日の昼間に玄関を開けた瞬間足元を横切った大型のヤツがいたりとか、今日トイレの床にめっちゃくちゃちっちゃいヤツがいたりとか(コイツはGかすらわからなかった、即潰したので)して、何かとやっぱり不安が高まってきておりなんなら実家に戻りたい。おかーさんの作った料理が食べたい。駅前のギャーギャー騒いでる学生がうるさすぎてつらい。
自炊する気が起きないのは、自炊して出た生ゴミだったりをゴミ出し日まで放置したくなさすぎたりするのも理由の一つ。
マンションだったらゴミは即出しに行けるのだが、生憎とアパートなのでゴミは指定日にしか回収してもらえない。
それまで生ゴミを家の中で放置しとけと言われると、Gが大量に出た経緯からすると、いくら業者の施工があったとは言え抵抗がある。
来年の3月くらいに、実家が引っ越しするそう(と言っても今は賃貸に出しているマンションの一室に戻るだけ)なので、そのタイミングで実家に戻ろうかとすら考えている。
一人暮らしを始めた理由が部屋不足と独立経験を積むことと転職してキリがいいことだったので、別に実家に戻ることに抵抗はないし、なんなら余計な出費が減るので戻りたい。
もう少しお金を貯めたら、多少高くても快適なマンションの一室で一人暮らしをしたい。Gと馬鹿騒ぎする学生はもう勘弁である。

仕事面

入社して二週間経ったが、勉強の毎日でわりと充実感がある。
「業務」というよりは「勉強」といった感覚が強く、前職で感じていた作業感や時間を無駄にしている感はない。
金銭面に直結するのだが、未経験で入ったため賃金は最低なので、それが今ダイレクトにダメージになっている。
年俸なので残業代は出ない(自分は年棒制推しなのでそれは問題ないのだが)ため、月にもらえる額は固定である。残業と言っても、自分が納得できるキリがいいところまで頑張っていたら夜遅い時間になってた、という感じである。
とにかく今は戦力になることを目指して地道に努力するしかないことを痛感した。

まとめ

全てにおいて努力が足りないので頑張りましょう 。

はー金ない。

日報 2016/07/13 -Ruby on Railsのform_forとform_tagの違いで悩んだ-

Ruby on Rails

今日ちょっと業務でハマったところがあったのでそれについて書く。

form_forとform_tagについて

作っているやつ

転職して二週間弱経ったが、自分の理解力の無さと知識吸収力の低さに辟易しつつ、Ruby on Railsを使って業務をしている。
Viewの部分をhtml.erbを使って書いているのだが、「アカウント新規登録の際のパスワード」と「確認用パスワード」の二つの項目をControllerにPOSTで送信する際に、どうしてもエラーが消えないという躓きに出会った。
値の受け渡しの流れは以下の通り。

  1. View(html.erb)で"新規パスワード"と"確認パスワード"の二つの項目をPOST形式で送信し、Controllerでパラメータとして受け取る
  2. strong parametersを利用して「新規パスワード」「確認パスワード」のみをpermitする
  3. 受け取った二つの値を比較し、一致していればモデルのインスタンスにパスワードを設定してsaveメソッドを呼び出す
  4. 値が異なっていれば、エラーメッセージを設定し、新規・確認パスワードの入力画面に戻る

具体的なコードはこんな感じ。

html.erb

<%= form_for(@model, action: :index, method: :post) do |f| %>
  <div class="new_password">
    <%= f.label(:new_password,"パスワード新規登録") %>
    <%= f.password_field(:new_password) %><br>
  </div>
  <div class="confirm_password">
    <%= f.label(:confirm_password,"登録パスワード確認用") %>
    <%= f.password_field(:confirm_password) %><br>
  </div>
  <div class="password_submit">
    <%= submit "登録" %>
<% end %>
controller.rb

  def create
    param = strong_params
    @model.password = param[:new_password]
    @model.onetime_password = ""
    if param[:new_password] != param[:confirm_password]
      @model.errors.add(:base, "パスワードが一致しません")
      render :new
    elsif @model.save
      session[:model_id] = @model.id
      redirect_to :index
    else
      @model.error.add(:base, "エラーが発生しました")
      render :new
    end
  end

  private
  def strong_params
    params.permit(
      :new_password,
      :confirm_password
    )
  end

いざパスワード登録！と登録ボタンを押したところ、いわゆる「ぬるぽ」が発生した。 発生箇所が

elsif @model.save

の行だったのと、DB内でパスワードが入るカラムにはNOT NULL制約がかかっていたのもあり、「パラメータで受け取った二つのパスワードの値がnilっぽい」ことが分かった。

form_tagを使わなくてはいけなかった理由

原因が分からず唸りながらググッていたところ、こんな記事を見かけた。

qiita.com

html.erbでフォームを作成する際、form_forとform_tagという二つの選択肢がある。 正直違いがあんまり分からないし、前までform_for使って上手くいってたからform_for使おう、という軽い気持ちでform_forを使っていた。 簡潔に書くと、

  • form_forは第一引数で指定したモデルに基づいたフォームを作成する時に使う
  • form_tagはモデルに基づかないフォームを作成するときに使う

ということになる。
今回はパスワード新規登録とパスワード確認用の二つの値だけで、特に基づくモデルがないため、本来ならform_tagを使うべきだった。
そのため、以下のようにコードを修正した。

html.erb

<%= form_tag(action: :index, method: :post) do %>
  <div class="new_password">
    <%= label(:new_password,"パスワード新規登録") %>
    <%= password_field_tag(:new_password) %><br>
  </div>
  <div class="confirm_password">
    <%= label(:confirm_password,"登録パスワード確認用") %>
    <%= password_field_tag(:confirm_password) %><br>
  </div>
  <div class="password_submit">
    <%= submit_tag "登録" %>
<% end %>

こうすることで、無事にパスワードを登録することができるようになった。

form_forでもぶっちゃけ問題なく動作する

form_tagを利用してめでたしめでたしという感じだったのだが、ぬるぽが起きた具体的な理由は別のところにある。
順を追うと、

  1. ぬるぽが起きた原因としては、saveメソッドを呼んだ際に@model.passwordの中身がnilだったから
  2. @model.passwordの中身がnilなのは、strong_paramsでpermitされた値ではないから
  3. ではstrong_paramsでpermitに指定したnew_passwordとconfirm_passwordがpermitされていないのはなぜか

結論から言うと、strong parametersでネストを正しく表現していなかったからである。
form_forはモデルに基づいた値をPOSTするため、Controllerに送られる値は以下のようなネスト構造になる。

  • params
    • model
      • new_password
      • confirm_password

strong parametersでは、permitするパラメータがネストしている場合は、それを反映させなければならない。
つまり、

def strong_params
  params.permit(
    [:model][:new_password],
    [:model][:confirm_password]
  )

のように書かなくてはならない(もっとうまい書き方はあるだろうが…)。
パラメータがpermitされなかった理由は、ネストをしっかりと記述していなかったからである。
from_tagを使うと、

  • params
    • new_password
    • confirm_password

というネスト構造になるので、最初に書いていたstrong_paramsで問題ない。
結局、直し方としては

  • View(html.erb)をform_forからform_tagに修正する
  • strong_paramsのネスト構造を修正する

という二通りがある。
「html.erbでform_forをform_tagに直すよりstrong_paramsのネスト構造を直した方が楽じゃね？」と感じる方もいると思う。まったくもってその通りだ。
しかし、今回はあくまで「パスワードの登録」であり、「基づくモデルが存在しない」ことである。password.rbというモデルを作成して…とやっていたら、細分化しすぎて逆に分かりにくくなる。userというモデルにnameとmail_addressとageとpasswordいうプロパティがあり…という方が自然だ。大変分かりにくくて申し訳ないが、一画面でuserモデルの全てのプロパティを入力するフォームを作成するならform_forを利用すべきだが、今回は「新規登録パスワードと確認用パスワード」を入力するフォームだったため、モデルに基いていないということだ。
上記の点を考慮すると、form_forを利用してstrong_paramsを修正するのは、実質的には間違いと同義であるということになる、と考えられるのではないか。

まとめ

分からないことに対する知見が得られたときはとても嬉しい。ド素人なのもあって正直これで結構悩んだので、解決できたときはわりと嬉しかった。
今見返したら相当見にくい文章だということに気付いた。qiitaで読みやすい記事書いてる人、端的に言って尊敬する。