ここに移動しました。
Flask と Heroku と CORS
こんにちは、たかぴろです
最近はおうちハニーポットを作って LT をしました。セキュリティっぽい内容なので興味あったら見てみてください。
おうちハニーポットを作りましたhttps://t.co/iO4G0Haznx
— たかぴろ (@takapiro_99) 2021年4月24日
本題
Flask + React(Vue) での SPA Web アプリ、最近のハッカソンでよく見る構成ですよね。
でも毎回こいつが出てきます
おれ「またおまえか」
おれ「どれどれ… no-cors を指定すればいいんだな？」
レスポンス「opaque なのでレスポンスを見せられません（意訳）」
おれ「なにもわからん」
CORS ってなんなのか
CORS は Cross-Origin Resource Sharing の略で、クロスなオリジンのリソースのシェアリングです。
オリジンは「プロトコル + ドメイン + ポート番号」で、ページの配信元 と リクエストを送りたいところ の間でどれか一つでも違うとき、オリジンが異なる（クロスオリジン）ということになります。
Django や RoR などのフルスタック Web フレームワークは大体オリジンが同じですが、Flask を Heroku に + React を Firebase に みたいな、API サーバーとフロントエンドが分かれているような場合はクロスオリジンということになります。（CORS が必要）
オリジンが異なる ≒ 他人からのリクエスト なので、悪意のあるリクエストが飛んでくる可能性があり（ホンマか？）、それを回避するために、あらかじめサーバーで CORS （クロスオリジン間リソース共有）を許すオリジンを指定しておける というものらしいです。
Same-Origin 又は Cross-Origin（"おれ"は許してくれるとき）の場合
おれ → リクエスト送るね
レスポンスだよ ← サーバー
Cross-Origin（CORS しないよ）の場合
Aさん → リクエスト送るね
知らない子ですね（レスポンスなし） ← サーバー
なぜ CORS を制限するのか
セキュリティ対策なのはそれはそうなのですが、主に XSS と CSRF の２つを対策しています。（以下 Qiita 引用 *1）
XSS
CSRF
CORS 設定はブラウザ（の XHR や fetch ）だけで有効 ← 重要
対策を行いたい XSS や CSRF（しーさーふ）の攻撃は、全て「ブラウザ」と「その奥にいる人」がいて成り立つものです。
それ以外の curl でのリクエストやサーバー間通信、もしくは Python などのプログラムから通信する場合、どのオリジンからも普通にリクエストを送れます。（Same-Origin Policy がない）
不正リクエスト対策とは別に、意図していない リクエストを防げるという仕組みなのですね。勉強になりました。
個人的にはこの段落が一番の読みどころです。
CORS を許していくには
さて、具体的には、（サーバー）応答時にレスポンスヘッダーの中の Access-Control-Allow-Origin ヘッダーに、誰に CORS を許すのかを記述します。
例えば僕がサーバーを開発したとして、 example.com からのリクエストしか受け付けないぜ、としたい場合、レスポンスに
Access-Control-Allow-Origin: https://example.com
を指定します。これがあればちゃんと通信ができ、なければできません。的な感じです。
ワイルドカード（Access-Control-Allow-Origin: *）も使えますが、credential mode のときは無効にされるらしいです。
*2 MDN の CORS のドキュメント
Flask で CORS 設定
ググったら色々出てきますが、ブログ記事などはちょっと古い記事が多い印象です。
flask_cors というパッケージがあり、これを使って
from flask_cors import CORS app = Flask(__name__) CORS(app) # これで CORS 対応！
みたいに超簡単にできます。（？？？）
簡単ですよね
さすがにこれだと 全てのオリジンを許可 という状態になってしまっているので
from flask_cors import CORS app = Flask(__name__) CORS(app, origins=["https://example.com", "http://localhost:3000"]) # これで CORS 対応！
のように、ある程度絞った状態で CORS を許可するのが良いのではないでしょうか。（ベストプラクティスは分かりませんが）
*3 flask_cors 公式ドキュメント
でもこのライブラリ、前使ったときにうまく動かなくて、試行錯誤の結果 Flask のデコレータの機能で手動でヘッダーを設定してみる、というのでも動いたのでそれも載せておきたいと思います。
リクエストのパスごとに細かくヘッダー制御することも可能です。
*4 多分そのとき動かなかった理由
app = Flask(__name__) # すべてのリクエストに対してヘッダーをつけていく @app.after_request def after_request(response): response.headers.add("Access-Control-Allow-Origin", "*") response.headers.add("Access-Control-Allow-Headers", "*") response.headers.add("Access-Control-Allow-Methods', 'GET,PUT,POST,DELETE,OPTIONS") return response # 以下 @app.route('/')... などなど
動けばヨシ！みたいな精神なので、こんな感じで失礼します…
Heroku × Flask で CORS 設定
最近 Flask × Heroku で開発していた時に起きた怪奇現象を紹介します。
おれ「よっしゃこれで CORS 設定できたかな」
おれ「フロントエンドからリクエストを送ってみよう」
ブラウザ「ちゃんと通信できたよ！」
～数秒後～
ブラウザ「」
おれ「は？」
原因
まず、Heroku にアップロードしたアプリは様々な理由でクラッシュします。
再実行を試み、復活するまでは Heroku が代わりのページを表示してくれています。
が、このページでは CORS が無効なので、「リクエストは送れるけど、なぜかさっきまでできてた CORS ができなくなってる」という状況になります。
今回は、リクエストがいくつかまとまってきたら落ちる というサーバー側の実装の都合でアプリが頻繁に落ちていて、フロントエンドから見ると不思議なことになっていました。
友達と夜遅くにペアプロしてたのですが、本当に何もしてないのに壊れているような感じがして怖かったです。
感想
「CORS 対策」とか「CORS で動かない」とか言いますが、意味的には逆なんだなって思いました。
教訓
- ログをちゃんと見る
- エラー文とかドキュメントとかちゃんと読む
おわり！
2020 年、買ってよかったもの
あけおめことよろです！
それでは発表します。5 つ厳選しました。
1 位【Apple Pencil】
ノートとったり課題手書きしたり課題出すのにたくさん使いました。*1
- 発売日: 2015/10/14
- メディア: Personal Computers
↑なげーよ
apple pencil, 充電しながら書けないのぴえんすぎる
— たかぴろ (@takapiro_99) 2020年7月3日
2 位 【FILCO MINILA Air + パームレスト】
キーボードです。
FFBT67M/EB(ブラック) Majestouch MINILA Air
- メディア: Personal Computers
@IMD555 もおすすめしてます（彼はなぜか 5 台くらい持ってる）。
中括弧セットとか、アポストロフィーとか一発で打てるのが良いので英字にしました。
デフォルトだとうるさかったので静音リングを入れてみましたが、割と聞こえます。公共の場では使えないくらい
静音リング二個付けがちょうどいいです
— たかぴろ (@takapiro_99) 2020年3月28日
三個はストロークほぼなくなって打たさんない pic.twitter.com/deJF3Fspbk
正直ノーパソより打つの速いかと言われたら分からない気がしますね。それよりも、function キーを使った Home End 左手矢印キー とかが使いやすいって感じです。
ちなみに今は後継の MINILA-R が出ています。HHKB のように矢印キーが無かったり、色々違うので要検討だとは思いますが。
そしてこれはあったほうがいいです。パームレスト（1200 円）↓
サンワサプライ キーボード用低反発リストレスト（ブルー）TOK-MU3NBL
- 発売日: 2014/12/01
- メディア: Personal Computers
3 位【ノーパソスタンド】
ノーパソを載せる台です。
まっすぐ向いて作業できるので、首や背中への負担が減って good でした。
4 位【クロスバイク】
近所の自転車屋さんで買いました。
2019 年は原付だけで過ごしてたんですが、さすがに友達と遊ぶときなどに小回りが利かなかったので。
原付と違って学校内を自由に走れるし、どこでもパッと止めれたりするので良かったです。運動にもなるし。
5 位【レモネードサブスク】
1 ヵ月 1500 円でレモネードが飲み放題のサブスクです。*2
トッピング、フレーバー、シロップ。ほぼ無限の組み合わせの中から好きなレモネードを毎日飲めます。
僕が 3 か月飲んできたなかで特におすすめは「アロエレモネード」「レッドブルレモネード」「ビネガー系のレモネード」です！
外出自粛の暗い雰囲気の中、自転車をこいでレモネードを飲みに行くっていう言わば生きる希望でしたね。
左上から「普通のレモネード」「いちごビネガーレモネード」「ガラナレモネード」「キウイシロップ マンゴー & アイス トッピング レモネード」「食べる花レモネード」「ブルーベリーレモネード」です。
食べるお花レモネードはあんまりおすすめしないかも。アイストッピングは不定期でやっている模様。
あと 店員 レモネードガールたちがかわいくて元気をもらえます。
レモネードガールたち → https://www.instagram.com/cooldelemon/
番外編
【クリフハンガー】
コの字型に開き、片方にリュックをひっかけ、それを机に吊せます。
Stream Trail(ストリームトレイル) クリフハンガー L ホワイト
- メディア: スポーツ用品
リュックを床につけなくていいってスマートでしょ？
@atrn0 が使っててええやんって思ってたので買いました。
これ自分でも意外だったんですが、市電に乗るときに一番重宝しています。（腰ほどの高さの手すりにかけています）
【V-Strom 250】
レンタルバイクです。
一泊二日で稚内まで行ってきたんですが、車に比べると機動性に優れていて良かったです。
バイクほしいなあとは思いますが、コスパ的にレンタルで十分です。
まとめ
2020 年は基本的に家にいたので、モノを買うというよりはモノを整理した一年でした。
おわり！
mixi Bug Shooting Challenge #5 に参加した
エンジニアの中には CRE（Customer Reliability Engineering）という職種があります。意味はそのまま「お客さんからの信頼を上げる」エンジニアで、主に問い合わせに対応したりデータ分析をするらしいです。
今回は、デモアプリに届いた問い合わせを調査し、問題のあるものについては原因のバグを特定し、修正もするということを 二人チーム + メンターの方 という形で演習しました。あ、オンラインでした！
イベントページ → https://mixi.connpass.com/event/193415/
参加まで
選考課題のクイズが 2 問ありましたが、Rails をそこそこ知っている人ならサクッと答えられるものだと思います。僕は Rails 初心者だったため、たくさんググりながら回答しました。
当日
はじめましての @magcho くんとペアでした。（お互い個人エントリー）
やっていき#mixi_BSC
— magcho (@magcho0527) 2020年12月19日
レクチャー
デモアプリの構成についてなどの説明があり、バックエンドが Rails で、ログ収集に GCP の BigQuery （デモ環境）という構成でした。
BigQuery は聞いたことあるくらいで初めて触ったのですが、使いやすさと速度に驚きました。
BigQueryは、ペタバイト単位のデータに対するスケーラブルな分析を可能にする、フルマネージドのサーバーレスデータウェアハウスです。
メンターの方が「何してもいいよ」と言っていたので色々クエリを入れてみたのですが、数百万件のデータを数秒で処理してきたので Google すごいなって思いました。 ちなみにこれはデモ用の環境を用意してくれていて、実際に運用している環境では一日にテラバイトオーダーでデータが貯まっていくとかいかないとか。
その後 Docker で手元に環境を作り、みんなでチュートリアル問題をやりました。
本番
大きく課題が 3 問出題されて順番に 出題 → 解説 の流れで進めていく形式でした。 ユーザーからの問い合わせメールだけが渡され、それ以降は二人で方針を決めて調査・修正してね！という形で出題されました。
最初は取っ掛かりが少なくポカーンとなりましたが、すこしばかりの情報からログを辿ったり実装を見に行ったりと、できることからやっていき原因にたどり着いていきました。エンジニアとして処理を実装できるだけでなく、あとから見た人に分かりやすく書いたり、コメントを残しておくことが大切だなあ～と実感しました。
実装自体はごりごりセキュリティとかではなく、Rails や DB について基本的なことを知っていれば気づくようなものでした。むしろ方針を考えたり、実装してるのはどこだ？と調べるのに時間がかかりました。
そんなこんなで magcho くんと協力して(Rails関連はほとんどやってくれた) 3 問とも一応動くようにはできました。後で想定解の解説があったんですが、僕らが出した解決法よりもとてもスマートで本物だなと感じました。
(実際の問題が気になる方はこれに参加してみるか、こっそり僕に聞いてください。)
感想
エンジニアの仕事は開発だけではなく、保守運用も大きな役割を担っていて重要だなと思いました。バグが見つかった場合はその修正だけではなく、問い合わせ対応や SNS でのお知らせ、詫び石の配布などやることがたくさんでした。それを素早く行わなければならないので、大規模になるほど責任も大きいですね…
個人開発など、小規模なプロジェクトでは味わえない体験ばかりだったので、そういうものを知れて良かったです。
さいごに
たくさんメンターの方（実際に普段サービスに関わっているエンジニア！）と話せたり、豪華なノベルティ（お菓子セットなど）が送られてきたりと楽しいイベントに感謝です。
同じく参加していた方の記事を見つけたので、貼っておきます。 Bug Shooting Challenge #5 に参加しました - たかふぢやまとの部屋
おわり！
2020 振り返り
こんばんは。たかぴろです。
2020 年はコロナが蔓延し始めてオフラインでの活動が余儀なくされ、僕も含めて精神的にも来た人が多かったように思います。
あと数日でひとまず一区切りということで、反省会を兼ねて文章にしてみたいと思い、これを書き始めました。
一年前と何が変わったか？
僕は日記を書くようにしているのですが *1、去年の今頃のものを見てみると、バイク買いたい、macbook ほしい、道東道北行っときたい、太りたい、課題やるのを先延ばしにするのやめたい、などのことが書かれていました。
この中だと道東道北だけが達成されたような気がします。macbook 買う買う詐欺は一年もやってしまっていたのかとびっくりしました。最後の課題先延ばし癖は治ってないですね。
せっかくのテックブログなので、テックみがあることについて振り返ってみたいと思います。
インプットについて
インプットの中心は「ググる」でした。初めての技術は YouTube を一気見して雰囲気を掴み、それから公式を見ながらアウトプットに繋げていくことが多いです。ただ、最近でいうと Next.js とか Expo のようにアップデートが異常に速いなって思ったものについては、公式から始めるようにしています。そうするとあとで Qiita や YouTube を見た時にバージョンの違いがすぐ理解できました。
あとは、Twitter です。特に 無職やめ太郎（本名） さんは個人的に参考になるものが多かったです。
また、コロナが広まる前はオフラインのイベントに参加してみたりしました。主には JANOG札幌（1月）、DNS温泉（1月, 定山渓）、技育祭（3月, 東京）です。どれも記事をかけそうなものですが、アウトプット怠ってますね、これは。
JANOGでは大人たちの議論が全く理解できず、大人ってすごいんだなあと思いました。そのほかも面白い人とツイッターを交換したり、知り合えたりして良かったです。いや～実際に会うって大事だな～って思いました。
「よりオフライン体験に近いオンライン体験」、もっと加速してほしいですね。*2
本でのインプットを増やしていけたらいいなって思っています。
アウトプットについて
イベント駆動が多かったように思います。作りたかったから作った : ハッカソンや案件で作った = 2 : 8 くらいだと思います。ハッカソンも作りたいものといえばそうですが、期間が限られていたりシステムデザインをちゃんとできなかったりするので、除外です。
たくさんイベント駆動開発をした感想としては、フロントエンド～インフラまでたくさんの工程や手法を知ることができた。技術力をアピールできる制作物ができて嬉しい。といったところです。手を動かさないことには成長しないと思うので、今後も何かしらは作っていきたいと考えています。
環境について
3年目 windows ノーパソ + 安倍の10万自作 windows デスクトップ + 27インチディスプレイ + さくらのVPS(1GB) という感じでした。デスクトップが一番速いので、ほとんどリモートデスクトップしてました。（外からは自宅VPN）（10Mbpsくらいで安定してた）← 外出先からはキツかったりした *3
秋ごろ？に WSL2 の速～い Docker desktop for Windows も使えるようになったりして、恵まれていたと思います。
ただ、mac 多いなという印象はあります。急な Makefile に手元で対応できないことが何回かありました。そんな時は代替コマンドを手動で実行してなんとかし(てしまい)ました。
ずっと座っていることが多いので、最近はスタンディングデスクを試してみたいな～と思っています。
来年は
就活と研究をたくさんしていると思います。知らんけど。
おわり！
*1:毎日書いているわけではない。参考: https://xn--ztts57e.com/how-to-write-dairy/
*3:GoToトラベル + 札幌夏割 で、泊まるだけで +2000 円とかだったので夏休みはたくさんホテルにいた
ESP32 の https 通信、遅くない？
こんにちは。これは LOCAL学生部アドベントカレンダー2020 の 9 日目の記事です！
リクエスト送るの遅くない？
この前の JPHacks で ESP32 *1 を使ってサーバーに情報を送信する、みたいなことをやっていたのですが、それが遅かった（一リクエスト当たり体感 3 秒くらいだった）ので、詳しく見てみようと思いました。
きっかけは 0.1s ごとにリクエスト送れば web socket 級のリアルタイム実現できるんじゃね？って遊んでた時に気づいたことでした。笑
また、以前同じことをしたときには感じなかったし、少なくとも mqtt ではレイテンシを感じるほどじゃなかったので疑問でした。
ESP32 と無線
ESP32 は Wi-Fi に繋いで様々なプロトコルの無線通信を行うことができます。今回はサーバーに情報を送るところで HTTP 通信の PUT を使っていました。
公式が ArduinoIDE 向けに提供しているライブラリたち *2 は良く整備されていている印象で、HTTPリクエストには WiFi.h と HTTPClient.h を使いました。
実際に測ってみる
実測をしてみます。
条件
- 自宅の WiFi
- JSON PlaceHolder にリクエストを送る
- リクエストを送ってから、レスポンスを受け取るまでの時間を計測
- 10 回くらいリクエストを送り、平均を比較する。（14回計測し、上端下端で2つずつ除いたものの平均を用いました）
- 実験は今(Wed Dec 9 16:43:56 JST 2020)からやります。
とします。計測項目は
で行きたいと思います。
測定の仕方
このようなものを 5 秒おきに実行しました。millis() は Arduino の組み込み関数(?)で、起動時からのミリ秒数を取得できます。
シリアルモニタに出力された値を見て、記録していきました。
http.なんとか() で、各処理を行っています。ライブラリって便利ですね。
const char* serverURL = "http(s)://jsonplaceholder.typicode.com/todos/1"; timer = millis(); HTTPClient http; Serial.println("instanciated:" + String(millis() - timer)); http.begin(serverURL); Serial.println("set config:" + String(millis() - timer)); // String httpRequestData = "{\"device_id\": \"jfldskajflksd\",\"weight\":\"123\"}"; // int httpResponseCode = http.PUT(httpRequestData); int httpResponseCode = http.GET(); Serial.println("request done:" + String(millis() - timer)); String res = http.getString(); Serial.println("parsed response as string:" + String(millis() - timer)); http.end(); Serial.println("response: " + res); Serial.print("status code: "); Serial.println(httpResponseCode); Serial.println("request complete:" + String(millis() - timer));
結果と考察
| 項目 | かかった時間の平均 [ms] | curl でかかった時間の平均 [ms] |
|---|---|---|
| https / PUT / req body | 2185 | 112 |
| https / GET | 1749 | 121 |
| http / PUT / req body | 609 | 460 |
| http / GET | 104 | 101 |
素で通信する分には普通に PC からリクエストを飛ばすのと遜色なしでした。それほどシンプルなプロトコルだということでしょうか。
リクエストボディーを付けると +500ms くらいかかり、特に暗号化をしようと思うと +1500ms 程度の大きな時間ロスになることが分かりました。
curl で測ってもみた*3 のですが、どれもそんなに大差がなかったですね。一つ気になったのは SSL/TLS なしの PUT リクエストでしたが。。。なぜでしょうね、PCが重かったとかそういうたまたまですかね。
コードではシリアル出力をしているところやレスポンスをパースしているところがありますが、それらは 数ms だったので無視で OK です。
暗号化通信のために何をしているのか？
ログのモードを verbose (全部出す) に設定したところ、以下のものがでてきました（一部抜粋） 左端に出ているのは Verbose < Debug < Info のログレベルの格付けです。
[V][ssl_client.cpp:56] start_ssl_client(): Free internal heap before TLS 262616 [V][ssl_client.cpp:58] start_ssl_client(): Starting socket [V][ssl_client.cpp:93] start_ssl_client(): Seeding the random number generator [V][ssl_client.cpp:102] start_ssl_client(): Setting up the SSL/TLS structure... [I][ssl_client.cpp:156] start_ssl_client(): WARNING: Use certificates for a more secure communication! [V][ssl_client.cpp:180] start_ssl_client(): Setting hostname for TLS session... [V][ssl_client.cpp:195] start_ssl_client(): Performing the SSL/TLS handshake... [V][ssl_client.cpp:216] start_ssl_client(): Verifying peer X.509 certificate... [V][ssl_client.cpp:225] start_ssl_client(): Certificate verified. [V][ssl_client.cpp:240] start_ssl_client(): Free internal heap after TLS 222904 [D][HTTPClient.cpp:1025] connect(): connected to jsonplaceholder.typicode.com:443 [V][ssl_client.cpp:279] send_ssl_data(): Writing HTTP request... [D][HTTPClient.cpp:368] disconnect(): tcp keep open for reuse [V][ssl_client.cpp:248] stop_ssl_socket(): Cleaning SSL connection. [V][ssl_client.cpp:248] stop_ssl_socket(): Cleaning SSL connection.
5 行目を見てわかる通り、こいつにはルート CA 証明書がないようです。たしかに。考えたこともなかったですね。
（SSL/TLS については情報学Ⅰのテキストを見返してください）
8, 9 行目に peer X.509 certificate とありますが、誰の何を verify してるのかは理解できませんでした（残念）っていうか暗号化すらできているのか？ということも理解できていないので、深堀りが必要そうでした。
肝心の "どこ" で遅くなっているかについては、時間を割けず具体的には見つけられませんでしたが、またチャレンジしたいと思います！
追記
うろうろしていたらドンピシャな記事を見つけました。*4よしなにやってくれるそうです。この辺りは mbedTLS と呼ばれる技術らしいです。 https://techtutorialsx.com/2017/11/18/esp32-arduino-https-get-request/
目的のホストの証明書を取得し、ESP側に埋め込んでおけば普通のSSL/TLSとして使えるみたいです。これはまた今度やってみます。。。
最後に
幼稚な実験でしたが、最後まで付き合ってくれてありがとうございました。
ライブラリさえ使えればまあいいやって思ってる自分もいましたが、ちょっと掘り下げるだけで知らないことがわんさか出てきて、基礎知識の重要性を再確認できました！
おわり
*1:ESP32（と呼んでいる開発ボード）に使われている ESP32-WROOM-32 は NRND になったみたいです。今後は ESP32-WROOM-32E らしいです。
参考: https://tech.144lab.com/entry/esp32-wroom32-nrnd
*2:https://github.com/espressif/arduino-esp32/tree/master/libraries
*3:https://qiita.com/yuya_takeyama/items/baf48a3f643e743a46b4
*4:https://garretlab.web.fc2.com/arduino/esp32/reference/libraries/HTTPClient/HTTPClient_begin.html
もう12月なので一年前の自分を振り返る
これは HUIT アドベントカレンダー 2020 の、2 日目の投稿です。
HUIT を知らない人は、Advent Calendar 一日目の HUITとは？ を読んでみてください！
HUIT は北大を中心とした情報系学生コミュニティ(サークル？)です。これからさらにワイワイできるように活動を増やそうとしているところです。興味のある人はDMしてね
一年前、何してたっけ？
僕の一年前は web プログラミングに触れ始めて少し経った頃でした。友人とハッカソンに参加してボコボコにされたり、チーム開発に初めて挑戦したり、そんな感じです。
その頃のコードでもみて、感想を書いていくやつをやりたいと思います。
JPHacks 2019
つい先日 JPHacks 2020 に参加してハッカソン引退することになったはなし をしましたが、一年前にも同じイベントに参加していて、こんなものを作っていました。
作ったもの
光るクリスマスツリーを作りました。イルミネーションのパターンをブラウザから投稿でき、一定時間ごとに投稿されたデザインで光るというものになっています。
web アプリは Django で作られていて、LED の制御は毎度おなじみ ESP32 を使っています。
こちら のレポジトリでみんなで開発していました。そのときはじめての GitHub だったので、今振り返りながら見たらどんなことを思うのかを、書いていきたいと思います。
それでは行きましょう。
よかったこと
1. ちゃんとブランチを切って開発をしてた。
ちゃんとブランチを知っていました。切ってたのは一回だけですが…
そしてよく見たら PR じゃなくて master ブランチに無理やりマージしているだけでした。惜しい
2. 簡潔な DB テーブル設計
class Tree(models.Model): date = models.DateTimeField(auto_now_add=True) name = models.CharField(max_length=20) CHOICES = ( (1, 'クール'), (2, 'かわいい'), (3, 'おしゃれ'), (4, 'ばえ'), (5, '読める！'), (6, 'おもしろい'), ) look = models.IntegerField(choices=CHOICES) data = models.TextField(max_length=5000) lighted = models.BooleanField(default=False)
木の光り方のパターンを入れるテーブル (DjangoORM のモデル定義) です。アプリ全体でこれしかなかったので正規化とかいうことは考えなくてよかったみたいですね。
3. HTMLCanvas で、タッチも対応してたこと
時間なくて書くの忘れてた。ちょっとまってくれ
改善すべきだなって思ったところ
1. 命名が意味不明すぎる
ss = Tree.objects.filter(lighted=False).order_by("date").first() treedata = Tree(lighted=True) treedata.save() sss = ss.data ww = "" n = 0 for i in range(93): rr = "" bb = "" ww += rr """ 中略 """ n += 9 ww += "\r" return HttpResponse(ww)
Tree とかは分かりやすいかもです。他は意味不明です。
コメントで何をしているか記述したり、そもそも変数名だけで何をしているか掴めるようにしておきたいですね。
(僕は自分で書いたのでわかるのですが、これはどんな光らせ方をすればいいかを教えてくれるエンドポイント(の一部)でした。)
2. いたるところに .DS_STORE がいる
これは mac 特有のシステムファイルですが、別に git で管理する必要はありません。
最近知ったのですが、グローバルに git 管理から除外したいときには、ホームディレクトリに ~/.gitignore を作成すれば設定できるので、mac ユーザーでお困りの方は試してみてください。ちなみに Windows もできます。
3. 少なすぎるコミット、何をしたのかが分からないコミットメッセージ
コミットは全部で 14 回、 issue 0 件、PR 0 件でした。
そんなにコミットこまめにして何になるんだよって思ってました。ですが、あらゆる事故防止や後からどこで何をやったか思い出すためにも、やったことごとにコミットしたほうが良いです。コミットメッセージも統一性を持たせたり、prefix つけたりするとさらに分かりやすいらしい (上級編かも！)
4. なぜか自宅サーバーにデプロイしていた
その当時ジャンク PC を買って自宅サーバー！(CentOS)とか言って遊んでたので、当たり前のようにそこにデプロイしていました。
どうやってインターネットに出ていたかって…？ サーバーに固定(local) IP を設定し、自宅の ONU でポートフォワーディングをしていました。運よく固定グローバル IP が降ってくる家だったのでできたことです。当時はイケてるなと思っていたのですが、ちょっとめんどくさいですね。
最近のハッカソンでよく見る通り Heroku や Firebase といった SaaS に簡単にデプロイできるよっていうことを教えてあげたくなりました。
さいごに
こうやって人は成長していくのですね。それからどうやって成長してきたか気になると思うので、具体的なものを挙げてみたいと思います。
- YouTube を見てアプリ開発の手法を学んだ
- ハッカソンに参加して、分かる人にチーム開発を教えてもらった
- LT 会などに参加してエンジニアの人の話を聞いたり、発表したりした
- ツイッターでエンジニアをフォローしといた
あくまで僕の場合です、参考までに！
それではありがとうございました！
HUIT では初心者大歓迎です。面白いものを作りたい人やアイデアを形にしたい人がたくさん集まっています。 メンバーどうしでチームを組んでチーム開発を行うハッカソンや、アウトプットができる LT 会をたくさん企画しています。
今後も HUIT をよろしくお願いしますー！
おわり
追記
このページはどこにもデプロイされてないので、整理して思い出としてデプロイしておこうと思いました。また更新します。
JPHacks2020 参加記
今回の記事は長めです。せっかく来てくれたので最後のとこだけでも読んでください。
とても久しぶりです！気付けば B3 の後期にもなってしまいました。
アウトプットは大事だなって思うので、記事として書いていきます。
徹夜明けなのと長い文を書くのが久しぶりすぎるので日本語が小学生レベルですが、よろしくお願いします。
去年のリベンジだ
去年、ひょんなことがきっかけで web プログラミングを知り、またひょんなことがきっかけで JPHacks 2019 に 参加していました 。
ほぼ初ハッカソンで僕は全然力を発揮できず、最低限のプロダクトすら作れませんでしたね～。
今年もオンラインですが開催されてたので、 友達を誘って参加することにしました。
JPHacks 2020
テーマは、○○×Tech。 それと、"Technology for ourselves" みたいのもあった気がします。
毎度のように数時間 × 数日かけて何を作るかを話し合いました (Zoom + miro) 。様々アイデアを考え、最終的には「重さで在庫の残容量を測れるくん (IoT)」を作ることにしました。
デザインの人、フロントエンドの人、万能な人2人、ハードウェアの人(おれ) というチーム構成でした。テーマは発表されていて事前開発可なので、予選の二週間ほど前から制作物決め、進捗共有などを行っていきました。
予選通過まで
一週間前からは毎晩ミーティングを開き、進捗共有とタスク管理をしました。みんなのモチベーションをあげるには、これは大切なことだと思います。作りたいものを固め (Service design)、どうやって作るのかを決めて (System design) いきます。
今回は完全オンライン開催でしたが、会える圏内にいたのでたまーに集まって作業しました。DRIVE や 13labo を使いました。予選通過を当面の目標に建設的にタスクを消化できていたので、楽しく進められたと思います。
予選大会は 90秒 の Pitch と、アピール動画、GitHub レポジトリ で審査が行われました。プレゼンは iPad のカメラを PC にミラーリングして生デモを試みましたが、ネットワークが少し遅くなってミラーリングにラグが発生し、テンパってる間に終わってしまいました。観測してた感じ生デモをしているチームは成功確率が低かったです。
決勝まで
そんなこんなで決勝進出を決めることができました。これで去年のリベンジ達成ですね、嬉しかったです。 合否の知らせがあってから本番までには 2 週間もの時間がありました (長い)。しかもメンバーのほとんどがテスト期間と被っていてスケジュールの調整が難しかったです。(などと濁しておりますが、僕は全然タスクを消費できなかったということです)
みんなで話し合って決めたことは、UI・UX の向上 (真剣に考えたよ) と、実用化を視野に入れた実装でした。
こんなフローチャートとかも考えました。 https://github.com/jphacks/A_2016/issues/93#issuecomment-727581165
決勝
運営の方も口を揃えて言っていましたが、レベルが高かったです。「これ大学の研究じゃん、ほんとにこの一か月で作ったの？」と思えるようなプロダクトばかりでした。（そして本当に一か月で作られている）
僕たちは airbnb で取った宿に前日から集まり、開発を進めました。どこをアピールして何を実装するのか、というのをワイワイガヤガヤやるのが楽しかったです。 徹夜はしたくないな～って思いながら参加したのですが、結局朝までもくもくとやっていました。僕は発表担当だったので少し寝ましたが…
発表は 8 分間でした。また発表は動画デモにしました。不測のアクシデントのリスクは低いし映像に合わせてペラペラしゃべればいいだけなので、精神的にとても楽でした。見てる方も楽なんじゃないかなと思いました。なかなか上手く行ったと思っています。
ハードウェア製作について
次は ### 結果 かなと思ったんですが、メモ程度に僕がしたことを先に書いておきます。
重さを測ってそれを定期的にサーバーに送る。単純なタスクです。「Arduino 重さ 計測」などとググればすぐ目当ての部品にたどり着けただろうに、見当もつかずはじめに圧力センサを買いました。通販で届くまでの間が暇だったので、ハードオフなどを巡って 300円 の Wii-Fit ボードを見つけ、分解してみたりもしました。4つ足に分解能が 0.5kg のロードセルがついていました。これ4つであんなに多彩なゲームが生まれるんだなあと感動しました。
圧力センサーは上下で板挟みにするかたちで重さを計測できると考え、プロトタイプ一号機を作りました。3Dプリンターで筐体作りを手伝ってくれた ayumin に感謝です。Fusion360 初めて触りましたが簡単な形はすぐに作ることができました。データシートにも重さと比例した電圧出力をしますみたいなことも書いてあったのに、精度の問題でうまくいかずでした。タッチパネルに良く使われるみたいでした、最近の車のエアコン操作パネルとか。
ここでようやく真剣にググったわけですが。”ロードセル” という部品が良いことに気づきました。これは歪み（ひずみ）ゲージという、機械系でよく用いられる部品を応用したもので、繊細な歪みゲージの出力を増幅・補償したものです。重さに比例して抵抗が変化するらしいです。部品を買って筐体を設計して…みたいなことをしたかったのですが時間がありません。Wii Fit をハックしてた記事を見たのを思い出し、キッチンスケールで同じことをやることにしました。
メンバーと札駅を回って、いちばん安かったニトリのものを買いました。999円でした。精度は ±2g って書いてましたね、家のキッチンにあったやつは 0.1g の精度って書いてたんですが、中身どれくらい違うのかが気になりました。(家のやつの中身は見れていない(破壊的分解になるため))
よくあるキッチンスケールは大体ロードセルを使っています。ロードセルからは 4 本の線が出ていて、電源2本、出力2本です。出力はマイコンで読み取るには微弱すぎたので、汎用オペアンプで差動増幅回路を組みました。写真右下ごちゃっとしたのがそれです。楽しかったです。
久しぶりにハードなものを作ってワクワクしてます pic.twitter.com/FsMtPK5SYC
— 🎄たかぴろ🎄 (@takapitech) 2020年11月5日
それを ESP32 という Arduino互換マイコンでサーバーにリクエストを送るということをしましたが、それはまた別の何かに書きます。
結果
上位17%の予選を通過できましたが、特に賞はもらえませんでした。
16 チームが進んだ決勝で、名のついた賞は計 28 個あったので、何かもらえるかなと思っていた自分が甘かったようです。ただ一番になれなかっただけで、「使ってみたい！ほしい！」「面白かったよ！」「懇親会でさらに話を聞きたいと思った」などたくさんの賞賛のお言葉を頂けたので、爪痕を残せたようで嬉しかったです。
完成したものはこちらです。 https://ar-cana.netlify.app/
こだわりの UI です。ゲストでログインして見てみてください。
他に決勝に進んだチームはこんな感じです。→ https://jphacks.com/information/award-finalists2020/
ハッカソンって
どう立ち回ればいいのか、難しいですよね。
"技術的知見をたくさん得られる！" というモチベで今までやってきましたが、最近はどうやらそうではないと感じています。なぜなら、ハッカソンは「限られた期間ですごいプロダクトを作る」ことが高評価に繋がるし、そういう意図で開催されているものが多いからです。
ハッカソンは "新しいなにか" を作りださなければならず、「ユーザーの課題」「実現可能性」などサービス志向なノリも必要になってきたりします。アイデアを考える過程も非常に大切です。というかある程度ものを作れるようになってくるとアイデアゲーです。そういうものだったのです。
その度に全く新しい技術を学んでいては、アウトプットが追い付きません。プロダクト重視の場合は手持ちのスキルでサクッと作るのが楽な立ち回り方だと感じました。もちろん技術的にチャレンジがないと評価されずらいんですけどね、おれは "なにか動くものを作る" ということで精いっぱいだったということです。
ハッカソンは、チーム開発のノリを掴めるし、他の参加者と交流することで世界が広がってモチベーションになるし、プレゼンの経験を積むことができます。ビジコンではなくハッカソンである以上は動くものを作らなければならないので、制作物を就活でアピールすることもできます。また提供物やノベルティも楽しめます。最高でしょ？
ハッカソン引退！
今回参加したメンバーは、今春にスタートアップで起業 (残念ながらサービス閉鎖) したメンバー(+α)であり、これまで数々のチーム開発をしてきた頼れるメンバーたちでした。
就職する人がいるので 、このチームでイベント駆動開発をすることはしばらくないでしょう。
という感動的な話もありますが、僕個人としても 2020 年に既に 7 回ものハッカソンに月 1 を超えるペースで参加していました。つよつよになる！という思いでたくさん参加してきて、たくさんのものを得ましたが、学問の方が疎かになってしまいがちだし、徹夜開発でいのちを削るのはしんどいし(?)、自分の本当に勉強したいことにも手を付けたいなと思ってきてたので、とりあえず引退っていうことにしています。就活もしたいしね！
ということで運営やメンバーのみなさん本当にありがとうございました！！！以上です！またお会いしましょう～
第一回なにもしない会
こんばんは、たかぴろです。今日は昼過ぎに見た大通公園の温度計が-8℃でした。寒いです。
さて僕はおとといから春休みに突入し、なにやろうかな～みたいなことをここ数日考えたりしてます。
なにもしない会
今日はHUIT(北大IT研究会)で、なにもしない会を開催してきました。
「なにもしない会」っていう名前をつけてみましたが、要はもくもく会です。みんなちゃんともくもくしてました。
進捗を生む！！って頭のどこかで思っていても、ついごろごろしたりスマホポチポチしたりして「無駄な時間だったなー」と後から後悔する週末が繰り返されてたので、人と約束してとりあえずは出歩こうと決めて企画してみました。
一週間前くらいにslackに投げてみて、今回は４人来てくれました。
だれもこないかなって若干思ってたけどよかった。ありがとう。
やったこと
パソコンぽちぽちしたり、本を読んだりしました。基本的にはもくもく会なのでおしゃべりは控えめで手を動かしてましたが、素朴な疑問とか、技術的な話を集まったメンバーで話したりもしました。ぼくは Real World HTTP っていうオーライリーの本を読みました。
分かったことと分からなかったこと
感想
春休みは定期的に人と会わないとなって思いました。
最後に
LOCAL学生部総大会2020に参加してきた話
こんばんは、たかぴろです。
先週末にLOCALという北海道の技術系コミュニティの学生部での、総大会という泊まりこみでもくもくしようっていう合宿のようなものに参加してきました。
第11回 LOCAL学生部総大会 開催レポート
はい、僕はLOCALには１か月ほど前に参加したばっかりで、初めて参加するイベントだったんですが、みんなフレンドリーで楽しくワイワイすることができました。
当日までは部長のはいばらくんと他数人しかリアルでは知らなかったのですが、いざ自己紹介を聞くとだいたいTwitterで見たことあってウケました。みんなこれからもよろしくね。
今回の企画はブログリレーということで，みんなで進捗を出してどんどんアウトプットしようという会でした。僕は、直前に参加していた北海道LT大会に向けて制作を進めていた「LEDをブラウザからリアルタイムで制御できるやーつ」が、LT大会までには自分の思う完成には至らなかったので、その機能を完成させることを目標にすることにしました。
やったこと
一日目は、榊くんに競プロを教わったり、e-sportsをやったりしました。
榊に競プロ教わってる
— たかぴろ (@takapiro_99) 2020年1月18日
榊とe-sportsした pic.twitter.com/TKq42yc9Cf
— たかぴろ (@takapiro_99) 2020年1月18日
宿に移動してからは、たしかすぐAtCoderの企業コンがはじまり、100-200-...という感じの点数だった気がするけど100しかできずにレート下がった。榊は時間いっぱいがんばっててすごいなって思った。緑以上くらいなりたいなーとぼんやり思うけど思ってるだけじゃなんも変わらんな(あたりまえ)
その後は食堂に集まって夜のもくもく()がスタートしたけど、もくもくだけじゃなくて質の高い情報交換会になったなっていう印象でした。参加者の中には17の代(高２！)の人たちがいて、その人たちがAWS～Azure～とかVue～とか言っててマジで天才だなーって。勉強することももちろん大切だけど能動的にこう技術に取り組めるっていいですよね。刺激になりました。おれは２時くらいに寝たっけ？
やったこと(二日目)
LEDぴかぴかーの実装をメインに取り組みました。具体的にいうと、ESP32でぴかぴか情報を受け取って、それをLEDに流していくところのコーディングです。時間に追われながらなんとか動かすことができました。
ソースはこちらにあります。(ぐちゃぐちゃだけど)(あとでぜったい整理する)(というか鯖IPバレバレだけどどうすればいいんだ???)
昼を挟んで進捗報告LT会をしました。有志で発表していったけどあれ参加者みんなのLT聞きたかったな、あ、こういうことやってたのかーみたいなのが後からあった。今度はリクエストしてみよう。
なゆたの「ちゃんと勉強もがんばる」っていうのがおれにはグサッと刺さりました。勉強もがんばります。そんなこんなで地方勢のバスがあるので超健全な時間に解散。
できたもの
動画！
— たかぴろ (@takapiro_99) 2020年1月19日
ついでに同時閲覧数と謎のチャット機能つけた、https://t.co/uRtiigZ1rAの勉強になりました pic.twitter.com/yOud1bpGcR
感想
- イベント駆動開発最高だね
- すごい成長になったしアウトプットもできた気がする
- 競プロつよいひとほんとすごい
- 思いのほかDjango人気だったね(僕含め３組がDjangoer(?)だった)
- 高専勢キーボード打つのはやすぎ。。。まぢ寿司打しょ。。。
最後に
たくさんの支援、ほんとうにありがとうございました。会場を提供してくれたビットスターさん、数々のノベルティ＆スポンサーであるさくらインターネットとみたにさん、そしてLOCALのみなさんにはとても感謝です。
ブログを書いたのでぼくの学生部総大会はこれでおわりです。
近況
このイベントの後、Janogに参加したりその後にDNS温泉に行ったりと忙しくこれを書くのが遅くなってしまいました。早いうちにそいつらについても書きます。近況ですがDjango+ReactでRestAPI+SPAの勉強をしています。おもしろいからです。知らないことを知っていくのはおもしろいです。でも学校の勉強も大事でそれらもしっかりと取り組んでいいかなければなあと感じています。それとイベント行ったよ記事だけじゃなくてガンガンコードが出てくるような記事も書いてみたいなと思ってきました。今度やってみます。ここまで読んでくれてありがとうございました。
VESA非対応のモニターにアームを付けたはなし
まずはあけおめです。2020も楽しくやっていこうと思います。
(今年の目標とか決めなきゃなあ…)
