2018-12-04

Firebase で在室管理Web アプリを作った

制作物

CPS Lab アドベントカレンダー 12月3日(グリニッジ標準時) の記事です。 adventar.org

f:id:elzup:20181204001313p:plain

この研究室は「教員があっちこっち行く」「残留の民が多い」ということで在室管理の需要があったのでアプリを作りました。

成果物

メイン画面 f:id:elzup:20181204002134p:plain

設定画面 f:id:elzup:20181204002648p:plain

現在会社のオフィスと研究室・院生室に設置しています。

PWA 対応(アイコンとCRA標準)しました。別プロジェクトで Cloud Messaging 通知を使ったのでこのアプリにもつけたいです。 f:id:elzup:20181204001012p:plain

ソースコード

github.com

構成

ほぼ全部 Firebase に乗っかって作りました。 Mac アドレス監視の方式を使ってます。

Firebase function→ロガー用API
Firebase reactime database
Firebase Hosting
Firebase Authentication→Google認証

を使っています。

f:id:elzup:20181204001452p:plain

ロガー

アクセスポイント内に Mac アドレスを監視し続けるロガーを設置しています。

f:id:elzup:20181204002834j:plain

Raspberry Pi Zero W を使うとUSB電源一つでコンパクトに収まります。

ロガーは1分間隔で Python スクリプトを叩いています。

認証方法

Web アプリは Google 認証でログインできます。 Macアドレス(複数可)を登録して、実際にロガーが設置されているアクセスポイントで検知されると正式登録と判定します。

フロントエンド

react, Redux
flow
s2s
material-ui

を使ってます。

ソースコード github.com

ロガー github.com

2018-01-09

ACM-ICPC 0完でも競技プログラミングがしたい！

ACM-ICPC 2017 Asia Tsukuba Regional | ACM-ICPC 2017 Asia Tsukuba Regional 358組中43組の国内予選を通過し、アジア予選に参加してきました。

まず結果について

0完(1問も解けなていないこと)についてはショックが大きいです。汚点を残したとか、期待を裏切ってしまったとか結構考えさせられました。他校からすると全然気にならないかもしれませんが。帰って寝るまで辛かったです。起きたら元気でした。

毎年直前になんとか集まるグループ

自分の大学には競プロサークルなどは無いです。毎年ACM-ICPC参加登録 1ヶ月前くらいに誰か一緒に参加してくれる人を探して、僕の趣味に付き合って貰う形で出来たグループで挑戦しました。今年の国内予選は僕にとってはラストで、3回目にして始めて通過しました。電機大から一昨年は1グループ、去年は3グループ、今年はなんと6グループ集まりました。

なぜ0完だったのか

単純な実力不足です。コンテストの経験不足、英語コンテストへの挑戦回数が全く足らなかっただけです。結局実力はそれに費やした時間です。

冷静に取り組んでいればA問題は絶対解ける問題でした。思い返すと言い訳ばかり書きたくなってしまうので書かないでおきます。

VMが配られていたので本番環境で練習しておいたのは本番であたふたせずにすんでよかったです。ただやっぱりどんなに焦っていても休憩は入れるべきでした。(競プロにかぎらず)

失敗から学ぶべきものは何もないので、今まで競プロをやってて思ったことをまとめておこうと思います。

初心者から見た競技プログラミングについて

僕の競プロ歴は4年(冷めてる期間多すぎて実質6ヶ月くらい)です。そんな自分からみた競プロについて書きます。

自分の好きな言語で解きたい

競プロに使うプログラミング言語ですが、自分の好きな言語で挑戦したいです。競プロ楽しいと思う部分はアルゴリズムやデータ構造を使って設計、戦略を考える部分です。知らない言語の仕様について勉強するのは僕にとっては無駄な時間に感じました。

ドキュメントやノウハウが充実するためにはプログラミング言語が偏っているのがしょうがないかもしれません(あとは実行速度など)。オンラインジャッジサービスだと様々な言語が充実していることや ACM-ICPC でも Python が使えるようになったのはいいことだと思いました。

問題文の英語について

英語力と競プロは両立はしたくなかったです。コンテストなどでグローバルに平等性をもたせるために問題が英語なのはしょうがないことですが。

普段から英語のドキュメントは読むので特に抵抗はないです。でも問題の「文章」を理解するためにかける時間は無駄に感じました。

AtCoder では多言語化にも力を入れていて素晴らしいと思います。僕は昔 AtCoder で競プロを知ったのですが、問題が英語だったら触ってなかったかもしれません。

快適にコーディングしたい

競プロなのに Lint や変数名や保守性などにこだわるつもりは無いですが、最低限のデバッグ環境は必要だなと思いました。構文チェックやInspection(未使用、未定義、型とか)があったほうが全然集中しやすいです。

そのへんは言語ごとに IDE があれば問題ないです。ただ Mac, C++ の(この組み合わせだけかもしれませんが)デバッグ環境を整えるのは大変でした。

理想を言うとデバック環境やサンプルケースの自動テスト(test ファイルの配布など)環境も欲しいなと思います。ちょっとした CLIを作ったりもしました。競プロでサンプルケースをテストするCLIを作った - Qiita

そのへんは TopCoder や CS Academy は提出前にサンプルケースのチェック出来て、ブラウザエディタの発展による解決もありかなと思いました。

競プロの勉強の仕方について

周りにやってる人がいないのもあって、なかなか学習の道しるべが見つけられませんでした。

簡単な問題への挑戦やコンテストへの参加への敷居はすごく下がっていて素晴らしいと思います。誰でも Online Judge ですぐに始めることができます。

ですがそこから先の勉強方法がなかなか見つかりませんでした。最初は AtCoder の解説で初めて聞いた名前があると調べるなんてことを繰り返してました。最終的に基礎的なアルゴリズムのリストアップは AIZU ONLINE JUDGE: Programming Challenge がまとまってたかなと思います(僕が知る限りでは)。

本で勉強できない自分が悪いのは別の話になってしまうのですが、蟻本などは最初の方だけ読みませんでした。モチベーションの話にもつながるのですが分野によってはオンラインのドキュメントが充実しているので、自分にとってはそこが勉強のしやすさの差を感じてしまいます。

蟻本の問題をすべてAtCoderに移植したらみんな幸せになれるのでは...
— not (@not_522) 2017年12月29日

たとえば↑はとても欲しいなと思います。

github.com

↑こういうロードマップの競プロ版が欲しいなと思います。

github.com

↑ここをみても、コンテストやオンラインジャッジのサービスは充実してるけど知識は書籍が主流なのかなという印象もあります。

本当に競プロの入門についてのドキュメントなかなか見つけられませんでした。いろいろ欲しいと言っていますがまだ出会ってないだけの可能性をずっと感じています。競技プロサークルは羨ましいなと思います。

モチベーションについて

競プロをやっていて「楽しい！」「この問題おもしろい！」と感じる瞬間は確かにあるのに、勉強がなかなかつづきませんでした。

継続のモチベーションで言うと AtCoder problems などがとてもよかったです。AOJもそうですがやった問題ははっきり色がついてるとわかりやすいし埋めてくのが楽しくいです。

大学に競プロのコミュニティが無いですが、2016年の春は学内で勉強会などを何度か開いて講師をしました。https://github.com/elzup/tdu_procon_lecture 勉強会も続きませんでした。

競技プログラミングの意義について

競プロのスキルが就職で優遇されるのを見かけるようになった来ました。しかし競プロで得た知識が実用できたという話のはあまり聞きません(機会がないだけかもしれない)し、なぜ優遇されているのかわかりません。

自分は競プロの問題を解くのが楽しいのでやっていました。きっかけとしてはいいと思いますが、就職で有利になるために競プロを勉強するのは辛いだろうなと思います。

競プロで身につけた知識が研究に役立つのかわかりません。その実感はまだない段階で、自分には機会がないかもしれません。ただ問題に合わせてシンプルなデータ構造を捉えられたとき、トリックを発見したとき、実装してACしたときの達成感が好きです。今の自分にとっては競プロは趣味でしかないので他のことを優先するし、このペースやモチベーションだとなかなか成長しないと思います。

4年間やっていて競プロはモチベーションの波は激しくて今は小さいです。

ここまでダラダラ書くつもりはなかったのですが、意外と競プロについて思うことが多かったみたいです。

ACM-ICPC を終えて思うところがたくさんあったので今の自分の視点として残しておきます。競プロのつながりを持っていないのでフィードバックがあれば嬉しいです。

2017-06-20

Armadillo-X1 を動かしてたメモ

公式マニュアルはここ http://manual.atmark-techno.com/armadillo-x1/armadillo-x1_product_manual_ja-1.1.1/ch01.html

最低限度で ssh で接続できるまでのメモ Host PC: macOS sierra

1. 接続する

f:id:elzup:20170619235423j:plain ↑のようにそれぞれ接続して、電源をいれる

2. serial 接続

ls /dev/tty.usb*
> /dev/tty.usbserial-A104O4GX

device を確認する。↑の場合 /dev/tty.usbserial-A104O4GX

minicom で接続 brew install minicom

minicom --noinit --wrap --device /dev/tty.usbserial-A104O4GX

初期設定ユーザとパスは atmark:atmark

3. ssh 設定

公式ドキュメント

update と ssh インストール

su - # pass: root
apt-get update
apt-get install -y ssh

ここまでの設定によりパスワード認証で入れるようになった。

2017-05-05

どこで食事するか選ぶためのアプリを作った

制作物

北千住に住み始めてだいぶ時間がたった。基本外食で済ませるのだが、いくつか問題が出てきた。飯をどこで食べるのか選ぶのが面倒くさくなってきたのである。近場に通うとすぐ飽きてしまうので、「今日はどこで食べようか」と毎日悩んでいるのである。(「料理しろ」は置いといて)
そして「店閉まってんじゃん問題」である。店前まで足を運んでから知らされ、ガッカリしたことが何度もある。情弱乙である。

あと1年は北千住にいるし、これらの問題と向き合うのはそろそろ嫌なので、ツールをつくった。

単純な話、飯屋の候補をリストアップしたいのである。レストランでメニューを見ながら食事を選ぶのと同じだ。北千住で普段行く飯屋がリストアップされていれば選ぶストレスも減るはずだと考えた。ついでに営業時間を可視化すれば悲しまずに済むのである。

そこだけシンプルに実装したのがこれである
f:id:elzup:20170505021133p:plain
https://elzup.github.io/senju-eat/
↑深夜 2時にスクショしたので24時間営業以外閉まっている。

構成はよくある「 react app から Google App Script のエンドポイントにリクエストして Google Spread Sheet のデータを取る」という流れである。

予想より面倒になったのは営業時間のデータ構造だった。曜日や祝日によって営業時間が違うパターンや、昼がすぎたら休憩時間を入れる店があるので少し複雑になった。

日常的に使いたいので「ホーム画面追加」のアイコンやスマホ表示に雑に対応した。
f:id:elzup:20170505021614p:plain

まだ、まとめてる店に偏りがあるけど、公開してるのでよかったら使ってみてね。

オマケ

開発の仕方について振り返る。
最近は「xの実装にy時間以上時間をかける価値はない」という考え方を大事にしている。「xの実装にy時間かかりそう」はどうでもいい。決めた実装時間内に終わらなかったらキッパリ諦めるのである。これが難しくて、今回も戦うこととなった。まるでギャンブルにハマった人間のように、「もう少し続ければ解決する」「せっかくここまで時間をかけたのにやり方を変えてたまるか」と心がエセヒーローになりたがるのである。
今回は本当に小規模のアプリだったので、全体的に何を使えば最小限で実現できるかもすぐに想像出来たし、gh-pages や Google Spread Sheet を使って正解だと思う。当たり前だけど最近勉強してる react-native で無駄に native 実装はしなかったし、サーバーを立てることもなければ JS の Build 構成やらプロジェクト構成にこだわり時間を浪費することはなかった。このアプリの開発に多くの時間を捧げる価値はないと初めから決めていたからだ。
最終的にポモドーロの記録のから数えると20ポモ(25分セット)使っていたので10時間ほどこれに費やしていた。どんなにグダグダやることになっても8時間くらいしか費やしたくないと思っていたのでちょっとオーバーした。それぞれの実装についてみても決めた時間が来ても実装を続けてしまうことが多かった。ただし、いらない機能を実装してる時の切り捨ては早いタイミングで起こった。例えば開店時間でソートする機能をどう実装しようかとコードを書き始めていたが、そんな無駄な事(や方法)に手をだす余裕はないのである。全体の実装に対する制限時間を意識することで実装するものの選択が洗練されることは、とても実感できてよかった。

ちなみにこの記事を書く時間の目標を決めなかったせいか、気づいたら2時間も使っていた。やはり時間を制限するのは大事だ。