■
むり つらい
現実逃避がてらコードを書いてた #337
現実逃避
研究が空中分解してしまったので相談がてら研究の相談をボスとしたくて雨の中研究室へ向かったのですがボスがいなかったので一日現実逃避してました(オイ
僕はレポートはTeX使って書く派なのですが、世の中にはWordを使って書く人種がいるそうで。どうしてそんな苦行をするのか。。。(ここでいうレポートは情報系のレポートでソースコードとかを貼る必要性があるという前提です。普通に文章書くだけなら別にWordでいいんですけどね)
んで、ソースコードを貼るときにだいたい必要になるのが行番号。Wordで行番号入れる方法調べるとExcelに貼ってオートフィルで行番号入れてコピーするとかいうスーパークレイジーな方法がヒットするらしいですがありえないと思ったのでサクッとツールを作成しました。(見た目をいい感じにしてたら地味に時間食ってしまったがロジックはサクッと作った)
追記:catのnオプションは勧めたのですがWindowsでは使えないということで却下されてしまいました
行番号追加して吐き出してくれるだけ。そんだけ。一応Reactで書いてはいますが殴り書きなのでなかなか酷いコードです。使ってくれる人がいたらリファクタリングしようかな。(これ使ってくれる人が多いのは嬉しいようであまり嬉しくないですが)
デプロイもGitHub Pagesで楽チン。
これ使うとブランチ切ってコミットとプッシュまでやってくれる。すげー楽。
コンソールに面白いの仕込んだのでもしよかったら見てみてねw
Golang
今日も今日とてGolang〜
基本文法はさらったのであとは書いて覚えるかなぁというフェーズ。
フロントエンドの勉強してる時も思うんですが、勉強用に何か書きたいって時みんな何を書くんですかね。誰か教えて。
雑談
研究〜………
過ちに気がついてしまって凹んだ #336
過ち
ここ2週間くらい研究室のボスから降り注ぐタスクを適当に避けつつ研究の下調べ的なのを進めていました。
英語と格闘したりしていたのはまさにそれ。
今日も英語と戦いつつ調べ物を進めていたのですが、どうやらやろうとしていたことはとっくに解決していた模様。さっき知った。これは流石に研究にできないですね。
研究にできないというだけで学びはあったと思うので後ほどQiitaかどこかにまとめてみようかとは思っていますが……辛い…………！！
追記：ここに全部まとまっているのでQiitaに書くことなかった。 blog.jxck.io
僕がやろうとしていたのはこの記事の終盤に出てくるHTTP/2のServerPushをCDNなどの1st partyリソース以外で用いる方法を考えていたのでした。
とは言っても、私が考えていたのはCDNに対して行われるアクセスの統計を取って、個々のアセットの関連を自動的に生成して投機的にServerPushすればおもしろいのではないかといったことでした。
追記ここまで。
先行研究されてましたーとかだとあるあるかなぁと思うのですが、研究の段階はとっくに通り越して標準化されてたなんて…。無知にもほどがあって悲しいですね。
まぁ気持ち入れ替えて頑張っていくしかないですね。
Golang
これまた研究に使おうかと思って勉強を始めたところでした。
Goを選んだ理由としては、Real world HTTPのサンプルコードなどからも感じたのですが、ネットワークを扱うに当たって標準ライブラリでも十分な機能を持っていそうなこと、そして型がある…w
まぁ流行ってるっぽいし研究で使うなら一石二鳥かなと思ったと思ったというのもあるかも。
こちらはとりあえず研究死んだけど引き続きやっていこうと思います。
雑談
しかも研究でやろうとしてたことの話、数ヶ月前にちらっと聞いていたということが発覚したんですよね。
あの時、興味をもって調べていれば………。
英語の記事と格闘していた #335
英語の記事
Performance Calendar » HTTP/2 Push: The details
この記事。
TL;DRを読んだ感じ、現実的な世界でのHTTP/2サーバープッシュの活用方法について書いているんだと思う。
あまりにもわからなすぎるので原文の記事を横に置いてesaに翻訳しながら読んでいきました。
いまは1.4付近まで読んだ。TCP slow startのあたりとかバッファのあたりを読んでて、TCPに関する知識の圧倒的不足みを感じた。これはいかん。
とりあえず、昔買って放置してあるTCPの本を読むことにした。
Windowsに進捗を飛ばされた
ただのグチなんですが。
とある資料づくりでパワポを使いたくて研究室のWindowsマシンを使ってたらトラブルに見舞われて再起動したらパワポで作りかけてたスライドが消えました。再起動前に確認くらいしてくれればいいのに…。
雑談
記事読みながらesaに翻訳を書く作業、iPadでもできるからすごい。
電車の中でも座れさえすれば作業できるからかなりいい。
(家帰ってきてから再現スクショ)
iPad、良い買い物だったなぁ。
FirebaseをちらりとみたりReact書いたりしてた #334
Firebase
名前だけ聞いたことがあったのですが、今作っているアプリケーションに活かせるかもと思ってみてみた。
私が使いたいのはRealtime database。JSON形式のデータを呼んだり書いたりということをクライアントから行えて、その上変更をサブスクリプションできるのでチャットアプリ的なリアルタイムさが求められる用途にも使えるらしい。(あとは、クライアントがオフラインになっても利用を継続できて、オンラインになったときに同期を取ってくれるみたいな機能もあるらしい)
とても良さげだとは思ったのですが、すでに書きかけだけど自前でゴリゴリ書いたサーバー側があることに加えて、ユーザー認証的な機能をつけようとすると、別途Firebase Authenticationというやつをつかってあげないといけなかったり、今回作ろうとしているものにはちょっとオーバーなので採用は見送りました。
(Authenticationの方はGoogle・GitHub・Twitterといったサービスを使ったログインや、通常のパスワードとIDを使ったログイン・電話番号認証つきのログインなどを実装できるプラットフォームのようです。自前でユーザーの情報を管理しなくてもいいのはかなり良さげですね。)
React
てなわけで、Firebaseの採用は見送ってゴリゴリとフロントエンドを書いてました。
今回作ろうとしているアプリケーションはリアルタイム通信が必要だったので、ちょっとレガシーかなと思いつつもSocket.ioを採用してみました。
そして、フロント側で以下のようなUtilを作って叩くようにしてみました。
export default class Api { public socket: any; constructor() { this.socket = io('http://localhost:8000'); } async join(name: string) { this.socket.emit('Join', name); return new Promise<User>(resolve => { this.socket.on('Joined', (user: User) => { resolve(user); }); }); } }
(一部抜粋)
叩く側からはWebSocket使っていることを意識しなくて済む…と思ったんですが、上のコードに示したような処理なら普通にAPI立てればそれで済んだ気がしてきた。
リアルタイム性が求められる情報だけをsocket使ってやりとりした方がコード綺麗だったのでは…。
雑談
筋肉痛すごいんだけどなんか自分健康って感じがしてすごいいい最高
— ううたろ (@uutarou10) 2018年4月15日
ボルダリングはいいぞ。
というかFirebaseすごいっすね。(超今更)こういうものがあるって知らなきゃ使えないし、常にアンテナ張っておくのは大事なことなんだなと思いました。
SA / 障害原因探求の旅 #332
SA
昨日に引き続きSAさんでした。
人に正しく教えることの難しさ……………！！！
とにかく痛感しました。言語化、大事………！
割りに合わないけどお金をもらってやってることなので、ちゃんと責任感持って、間違ったことを絶対に言わないように……なんて考えながらやってたら精神めっちゃ磨り減ったっぽくめちゃめちゃ今胃が痛い。何故。
（ちなみに教えてることはただのHTMLやPHPのど基礎なのです）
障害原因探求の旅
先輩から引き継いだシステムが起こしている障害をサグルベク本番のサーバーでうりゃおいとしてた。
SQLiteに触ってたんだけども、.mode htmlってやるとコマンドの出力がHTML形式になるという素晴らしくどうでもよい知見を得た。マジでどうでもいい。（SELECTの結果をHTMLで吐いて何かするんだろうか。
雑談
SA意外と時間食うなーという印象。
とはいえバイトしてるのと比べれば学校内だし無駄な時間なしで動けるからしゃあないのか。
帰りの電車でボスと会った。
ボスやはりすごく、研究のヒントになりそうなことをぽろっと言っていたので早速メモった。
とりあえず時間がない。勉強してどんどん手を動かさねば。
