フィヨルドブートキャンプ
- 日報をチェック。
- 提出物をチェック。
- PRをレビュー。
その他
実家の友達と千歳烏山の居酒屋で久しぶりの飲み会。
GW1日目なのにどこの居酒屋も混んでいて予約が取れなかった。
実家の友達と千歳烏山の居酒屋で久しぶりの飲み会。
GW1日目なのにどこの居酒屋も混んでいて予約が取れなかった。
日記形式で書いてこうと思います。
ペパボさん社内で最終の成果発表+研修全体の振り返り。
@hayapi_ppbと@kenken_monasyuの発表は想像してたよりずっと良かった。
うまくいってよかったねぇ〜とい感じ。
その後ペパボすぐそばの庄やで打ち上げ。二人がもうオフィスに出社してこないというと不思議な感じだけどRubykaigiでまた会えるでしょう。
日記形式で書いてこうと思います。
以前に会社にお金がない時に仕事を振ってもらってとても助かった。キッズスターさんの締切で作業できてなかったが、そちらがリリースできたので遅まきながら再開。
棋譜を表すKIFフォーマットを出力するために盤面図などを実装していたが、最近検索したら、json-kifu-formatのparser/converterのruby版を発見。
jkfは既にDBに持っているのでこれ使えば自分で実装する必要無いんじゃね?ということで試してみたら手合割や盤面図などちゃんと動くので使ってみることに。
ソースをかなりの行数削れそう。
iyuuya/jkf: JSON棋譜フォーマット(JKF)の定義とKIF, KI2, CSAからの変換ライブラリ
研修最終日前日。最後の発表の練習を@bluerabbit777jpさんに見てもらう。
機能的にちょっとパンチがほしいなと思ってGoogleマップ上にプロットするやつをPRだす。俺が作っても仕方無いんだけどね。
ちょっと前から@hsbtさんの仕事に感銘を受けて、俺も何か手伝えることがないかと、rubyのMLやgithub ruby organizationの中にあるgem化されたライブラリ、rubygems, bundler等のissueをチェック。まだ難しい部分はわからないので雑用っぽいものが無いか探し中。
事前にレビューさせていただいた、技術書典6で配布されたRubyとRailsの学習ガイドを@igaiga555さんからいただきました。
チラみせ
これからrubyの勉強を始める人に最適のガイド。
傍らに置いておけば、わからない用語が出てきたときには「これに載ってたやつだ」となるかもしれない。
見て思ったのはむしろRuby・Railsをキーワードに勉強始めてる人の方が役に立つかもしれないということ。「これからどの方向に深めていけばいいのか」がわかりやすいので。
これとRuby超入門を読めばかなりスムーズなスタートがきれるんじゃないでしょうか。
フィヨルドブートキャンプでは新しく来る人に配ろうと思っております。
電子版がBoothで500円なので気になる人は何も考えず買っちゃっていいのでは?
去年に続いてminneハンドメイドマーケット2019に行ってきました。
今年はビックサイトでなにか別の催し物があるらしく、さいたまスーパーアリーナでした。
僕らは1日目のお昼ごろに行ったのですが相変わらずすごい人。
基本的に8割ぐらいは女性向けのアクセサリーが中心ですが、男性におすすめなのが腕時計です。
去年も手作りの時計が気になってたのですが、今年は木でできたApple Watchのバンドがあったので買っちゃいました。
Apple Watch 木製ベルト - 木製腕時計のお店 EINBAND-アインバンド-
今までは純正パチモンの金属ベルドだったんですが、これがすごく重くて、作業中は常に外していました。木のベルトにしたら凄く軽くてかなりいい感じです。
さいたまスーパーアリーナだと隣にご飯が食べられる店が沢山入ったところがあるのでそこで食べましたが、去年のようにハンドメイドマーケット内に軽食のワゴンとかのコーナーがあるとよかったかなーと思いました。(スイーツ系はあったのだけけど)
その場で教わって作るワークショップは今年は去年よりたくさんありました。
僕らは瓶の中に苔のテラリウムを作るのをやりました。
苔の成長は遅いらしいですが、最終的には太古の地球のようにモッサモサになってほしい。
minneハンドメイドマーケットは行くと「なにか作ろう!」というモチベーションが上がるのでこれからも毎年行きたい。
先日行われたRails Developers Meetup 2019でプログラミングスクールを作ってみたという発表をしました。
スクールを始めたこと自体が以前のRailsDMがきっかけだったこともあり、発表資料を作りながら、
「どういうスクールにしたいんだっけ?」
など整理して考える機会にもなりました。
実際、お金がなくなったピンチなどいろいろありましたが持ち直し、卒業生も増えつつあるのでなんとか頑張っていきたいと思います。
有料化についてはStripeでの決済機能を僕が実装終わったらスタートという感じです。(作り中・・・)
基本自分は家だと作業ができないのでオフィスに行きたい。そこで理想のオフィス環境について考えてみました。
個人や数人の会社のイメージですが、書いてみてそこまで無理じゃないなと感じた。フリーランスの人でも何人かで借りれば行けそう。
そしてこういう場所が欲しいというのは仕事をしてないとしても変わらない。結局自分は飲み会ばっかりしてるというよりも、基本モクモクプログラムを書いて、時々その成果を発表したり、それを肴に飲んで話したいのだなと思う。
お礼が遅くなりましたが、オフィスの引越し祝いにスマートロックのQrio LockとQrio Keyをいただきました。
Qrio Keyはそーだいさんにいただきました。
本業のテック系では何故か関わりがないのにスト2では大変お世話になっております。(そーだいさんのボタンさばきを楠元さんと一緒に真似して練習してます。)
Qrio Lock本体の方、どなたが送ってくださったのかわからず、もし「送ったの俺だよ」という方がいらっしゃったらTwitterででも「俺だよー」と言っていただければ幸いです!
一つ前のQrio Smart Lockを楠元さんが持っていてオフィスで使っていました。
弊社スクールに通ってくる人に対して、毎日来る人にはQrioでゲストキーを発行しています。物理キーに対するメリットは鍵が紛失しても鍵穴側を変えなくてもいいところです。(アプリで鍵を削除すればいい)
ドアが閉まっていれば必ず鍵がかかっているので「鍵をかける」ということが生活から消えました。
また「あれ、鍵かけたっけ?」ということもありません。
新しい本体は少し形がかわってるものの、基本的には変わらないですね。ネット経由で操作するためのQrio Hubも以前のものがそのまま使えます。
そして新しいQrioの一番の違いはこれ。
このチェーンのしたについている楕円の小さいのわかりますか?これはドアが開いてるか・閉まってるかを見るセンサーでです。これはドア枠側につけます。
これによって「アマゾンが来た時、ドアを開けてサインしてる間に閉まってうざい」問題がが解決するのです!(ドアが開いてるとロックされない)
これはすばらしい!
Qrio Keyは車のキーみたいなやつです。
スマホを取り出して開けるのは手間なので、ドアホンにぶら下げていて、「どうぞおはいりくださいー」といってこれで開けています。便利!
Web APIです・・・。鍵の発行や削除が手動なので、ブートキャンプにサインアップしたら鍵作成とかやりたい・・・。
idの順番に依存しないコードを書こう - komagataのブログ
このエントリーに @jnchito さんがエントリーを書かれていました。
【Rails】idでソートするか?created_atでソートするか? 〜 Re: idの順番に依存しないコードを書こう - Qiita
こちらに対する僕の考えも書いておこうと思います。(こういうのってブログっぽいですね!)
1はそのままですね。created_atでソートしない場合は貼らなくて良い。元エントリーもそれ前提で書いてました。
2は「idでソートしたい」という意図がない場合「とりあえず何らかのソートをしなくちゃ」と思ってる場合はソート自体しなくて良い。ランダムなuuidでソートするのとソートしないのと変わらんと思う。
ただ、ソーシャルゲームとかその他の超膨大なデータを処理する時にパフォーマンスの問題でこの前提をあえて崩すのは良いと思う。非正規化と似たようなもん。ただあくまで基本はidでソートしない方が良いということ。
最近レビューでよく書くのでまとめておきます。
idでソートするとか、idがインクリメンタルな数字ということを前提とするコードは避けよう。古い順に並べたいんだったらcreated_at
とかが作成日なんだから「古い順」ということをより表現していることになる。
idをuuidとかに変えた場合バグになる。
古いものを取ろうとしてidでソートしてfirst
とかやっちゃいかん。
管理画面のユーザー一覧をid降順でソートしてて、最近追加されたユーザーは一番最初にきてたのuuidにしたら並びが変わった・困るとお客さんに言われることになる。
rails+postgresでidにuuidを使う - komagataのブログ
Microsoft系のライブラリやフレームワークもuuidがidのこと多い。
railsもfixturesではidはランダムに入るのでidがインクリメンタルな数字という前提のテストはコケる。(偶然動いたりするがそのうちコケる)
もちろんだけど、こういうコードは全く問題ないヨ!
@post = Post.find(params[:id])
むしろidはidentifierなんだから本来の使い方。気をつけるのはソート。