【お約束】 投稿内容は個人の見解であり、所属する（していた）組織の公式見解ではありません。
名前：uyamazak（昔いた会社で上司が開発用Linuxサーバーのユーザー名に「yuyamazaki」が長いので勝手に作ってくれた。読み方わからないけどウヤマザク）
高校あたりからWEBサイトをやったり趣味の延長でWEB系を仕事にした感じの人間。
2020年1月から株式会社シニアジョブにジョイン。
まだ開発者の社員は２人、これからの会社なのでいいインフラからきれいな設計をしたい
アズールレーン@竹敷でモバイルのUI、UX研究中（初嫁ジャベリン）
GitHub: https://github.com/uyamazak/
これまでの主なプロジェクト
続きを読むVagrantでやっていた開発環境構築をDocker化するにあたり、MySQLのダンプデータのインポート中やビルドコマンド実行時にディスクいっぱい系のエラーにぶつかりました。
Docker Desktop for Macを使っています。
MySQLのときはインポート中に、
ERROR 1114 (HY000) at line 31537: The table 'table_name' is full
で止まる。
コンテナに入ってbashでコマンド叩いたりしてると
no space left on device
が出てmkdirすらできない状況になりました。
Mac自体のディスクには空きがあるのになんで！？と思ったら、Dockerが直接Macのディスクを使うわけではなく、Diskイメージというものを使っているそうでこれの理解が必要でした。
確認したら割当が64GBになっており、63GB以上使ってました。
DBのダンプが80GB あったんですが、通常のVolumeを使うとおそらくこのDiskイメージに書き込まれ容量不足になってました。ホストのディレクトリをマウントすると成功するのはそういう理屈かな。
ローカル環境の docker を断捨離するためにやること - Qiita
Docker for Macも仮想マシン（HyperKit）で動いているしょせん偽物ということは意識しておいた方がよさそう。
2020/1/14から株式会社シニアジョブに入社しました。ちょっと時間がたったけど転職エントリ。
同人事業部にいました。盲腸での入院を除くと賞味9ヶ月。
給料、福利厚生、人間関係とか職場環境には問題なく、キャリアプラン的な問題です。いや六本木一丁目への通勤はちょっと嫌だった・・・。
システム全体的にいい設計したいなぁとか、フルクラウドで仕事したいなぁとか、自分より優秀な人いっぱいいるからいなくていいじゃんとか。
DMMのビジネスの仕方とか強みとかを中から知ることができたり、優秀な人のコードレビュー、別業界から来た人の話とか聞けて楽しかったです。
詳しくはなんかいろいろ契約書書いたし面倒なので書かない。
一言でいうと面白そう。
名前の通り50歳以上の高齢者専門の人材会社なんですが、独自のWEBシステムによる速さ、効率を強みにしています。人材会社は差別化難しい。
正社員の開発者は自分を入れて2人しかいません。そんな状況でいろいろいじくれるとなると面白そう。
私はもう30半ばで若くないんですが、私の精神年齢的な問題か若い人と仕事するの楽しいし、これまで経営者が若くないことによる（というか変化についていけないことによる）問題を感じてたので、若い人の経営って面白そうと思ってました。
社長は1991年生まれで学生時代に起業、営業もほとんどが20代です。
corp.senior-job.co.jp
社長がビズオーシャン時代いっしょだった営業の方の中学の同級生という縁がありました。その営業の方は違う部署でいっしょには仕事はしてないけど面白い方でした。
初日はMacBook Proの初期化からはじめました。会社はWindows＋Linuxの開発サーバーだったり、家はChromeBookやGCP上なので、Macで開発するの初めて。
次は開発環境がVagrantだったんですが、今更覚えたくないし、社内でもDockerがいいよねってことでやりました。2日目にはだいたい動いたけど、細かい設定変更や、DBが肥大化しているなどの問題で1週間かかった・・・。
あとはそのDocker化した環境で簡単なHTML追加してデプロイしたり。
基本、毎朝やることを確認する開発チームと社長の朝会ぐらいしかないので、ほぼ一日中開発に集中できてます。集中しすぎて肩と背中がこりまくる。
事情があればリモート可ですが、まだリモートはやってません。リモート用の開発環境も整備して使っていきたいです。
オフィスはコレアンタウンで有名なJR新大久保駅と地下鉄の東新宿駅の間にあります。ほとんどIT系のオフィスがない場所ですが、年金事務所とかよく使う役所が近くにあっていろいろ便利だそうです。
帰る時間は遊びに来たカップルとか、女子高生などの流れに逆流する必要があるのでちょっと歩きづらい。
オフィス周辺は、1分もかからずセブンイレブン、カクヤス、ハナマサ、キャンドゥに行けるので買い物には困りません。ちょっと歩けばマツキヨとかもある。
体を動かす目的も含めてお昼は外で食べる派なので重要です。
お店の大半が韓国系、東南アジア系なので、毎日だとすぐ飽きてしまうし、観光地価格的でそんな安くはないので、みんなそれ以外を探して食べている感じ。
牛丼チェーン、ラーメンの福しんなどは近くにあるので安く済ませたいときも困りません。600円以下と、1000円程度を交互に食べて食費バランス取っていきたい。
前述した通りシステムがコアとなってる会社なので、ビジネス、プログラム、サーバー含めて全体最適化やっていきます。今やらないと大変なことになりそう。
いわゆるレガシーコード、負債がある状況なので大元から良い設計で作り直して、開発スピードを上げていきたい。
SEOも課題が多いのでできるとこはやっていきたい（はてなのAI川さんに来てほしい）
ユーザー（社内の営業・営業事務の方々）がすぐそこにいるのでフィードバックには非常に恵まれた環境なので改善には困らなさそう。
具体的には開発環境Docker化したけど、本番までコンテナ化しないと本当のメリットは出せないのでそれを進めていきたい。
あと管理画面の各種詳細ページが1ファイル4000行超えのjQueryで書かれており実質メンテナンス不可能なため、これをVue.js。こいつのせいで画面の簡単な修正すらできない。ついでにいろいろ整理したい。
お知り合いの方へ：飲みに行きましょう（酒飲めないのでお茶とコーラ飲む）。誘ってください。
前回の記事のとおり、Raspberry Pi + ホール素子 + 磁石でハムスター回転車を検知することまではできた。
そこからどうやってFirestoreに保存するかと考えると結構パターンができたのでメモ。
スマホで書いたので読みづらい。
ハードやデータ的には自転車のサイクルメーターがほぼ一緒なので、参考にしようとしたら、設置場所や稼働時間が異なるため、あまり参考にできなかった。
ラズパイ側で一定期間回転数を保持して、サーバーに保存していく形式。
5分ごととか1時間ごとにコレクションに追加していくイメージ
/wheellogs/{documentID}
{
datetime: "2019/8/28 12:00",
value: 50
}
ドキュメント数＝回転した期間の数
回転数がない時はスキップできるのでレコード数は節約できるかも。
欠点として、ラズパイの処理が落ちた場合、保存するまでの回転数は消える。あと1時間にした場合リアルタイム性は低い。
ラズパイ側は一回転ごとにURLを叩くだけなのでラズパイ側はシンプルになり、複雑な処理はFunctions側に寄せられる。開発はしやすいかも。
データの持ち方も大きく２種類考えた。
これはシンプルだけどドキュメント数が多くなるので保存と集計コストが高い。
ドキュメントのデータは、タイムスタンプだけで良さそう。
/wheellogs/{documentID}
{ timestamp: タイムスタンプ}
ドキュメント数＝回転数となる
もう一つは、一定期間ごとにドキュメントを用意して数字をインクリメントする形式。これは1と同じデータ形式となり、処理をラズパイからFunctionsに移した感じ。
/wheellogs/{documentID}
{
datetime: "2019/8/28 12:00",
value: 50
}
↑2019/8/28 12:00〜12:59:59だったら同じドキュメントのvalueを増やしていく。
どれも費用は一人で使うとしたら大したことなさそうなので度外視できそう。
どれがいいかは、どんなデータやタイミングを、取りたいかが決め手になる。
よくある1日1回のレポートはどの形式でも、問題ないが、平均値やランキングを保持し、変化があったタイミングで通知送るなどをよく考えれられれば、いい設計が出てきそう。
開発やメンテナンス性を考えるとラズパイ側の変更は最小限に済むようにして、機能追加はFirebase側で行えるのが良さそう。
というわけで今のところは最後の2.2が有力。
