67kg、筋肉、骨盤
67kg
去年の5月から10月にかけて 81kg から 67kg まで減らして、しばらく維持していたのだが、寝正月をしていた正月太りと、フリーランスになる準備として毎日誰かしらと会って飲んでたら 69kg 近くまで増えてしまった。
ちょっとヤバイなと思って、3月末から再び少しずつダイエットして、今67kgに戻った。誤差の範囲といえば誤差だが、一瞬70kg見えてたので、体重計に乗って67kg前後だと安心感がある。
そして筋トレしまくってる。
筋肉
最初は腕立て10回でヒーヒー言ってたが、今は30回で物足りないと感じる程度には筋肉がついた。腕周りが明らかに太くなった。筋肉が増えて体重は変わらず、なので、相対的に体脂肪率が減ってる、はず。
あと、リモートワークしていた弊害だと思うが、下半身の筋肉が上半身に比べると落ちていて、大腿はでかい筋肉なので鍛えて代謝を上げておくと、体重の維持に役立ちそうな気がする。今後はスクワットを増やしたい。
本来は、肩こり解消のために筋トレを始めたのだが、残念ながらそこに影響はない。
骨盤
健康のためにダイエットしてBMI30からBMI22に減って、多少期待していたことだが、腰回りは全く細くならかなった。痩せて筋肉が多少ついたとは言え、標準よりはまだ重く、腹の肉がまだ削れるのはわかりつつ、ウエストのサイズが変わらないのは、そもそも骨盤がでかい、ということが分かった。骨なので、頑張ってもあんまり変わらない。そういえば58kgだった高校の頃にも「安産体型じゃん」とからかわれてたの思い出した。
結局、一番でかいサイズから一つ小さいサイズでやや苦しいぐらいに落ち着いてしまっている。サイズで言うとLLになる。体重減ってその辺期待してたが、多分これ以上落としても無理そう。
明日の準備
明日はアレの日なのでちょっと仕込みをやる
現場.fm というフロントエンドの現場について話すラジオを始めた
現場.fm
- 現場.fm https://genba.fm/
- 第0回: https://genba.fm/react-vs-angular/
- RSS: https://genba.fm/podcast.xml
- Podcast(審査中): https://genba.fm/podcast.xml
mizchi(主にReactの人) と armorik83 (主にAngularの人) でフロントエンドで現場の肌感などを話すラジオです。混沌としたフロントエンドの雰囲気などでみなさんのやっていく気持ちなどをサポートしたいという意図。
Jxck さんの mozaic.fm が未来の仕様とかを話すのに対して、こっちは現場の愚直な話がメインとしています。
Podcast は死ぬほど雑なアイコン(Atomのスクショ)にしたので怒られて再審査かも。
このメンバーの意図
React vs Angular、みんながこのタイトルで求めてるのはプロレスなんだろうけど、React の人と Angular の人でやろうとなったのは、どっちかの立場で喋ると偏るから、バイアスを中和するための対立軸という設定です。
第0回の反省
- 生なら大丈夫だろうと対面でとったが、録音環境があまりよくなかった
- 生配信やろうとしたが準備不足で失敗した
- そもそも生配信やるんだったら22時ぐらいからやらないと人が集まらなさそうだった
編集後記
やってみようとしたログであって、本編と無関係
- ホスティングサイト、 hexo 使ってみるか
- どうせなら AMP 縛りでやってみるか
- どうせならドメインとるか
- この辺の構成しばらくやってないから、復習しておくか
- Route53 で ドメイン購入
- Route53 で CNAME 設定
- => ドメイン取ったらSSL証明書取り直しでAMPで効かないじゃん
- ACM で証明書取得
- => AWSのバージニアのリージョンでとらないと有効にならず
- バージニアで再発行
- cloudfront に CNAME と証明書を設定
- 証明書が動かない
- =>
*.example.com
はexample.com
を含まない - 証明書再発行
- cloudfront に証明書を再設定
- 動いた
- ホスティングサイトに戻る
- organization の公開に失敗し続ける
- => organization の公開は gh-pages ブランチではなく master 縛りがあった
- hexo がローカルにインストールしたプラグインを認識できない
yarn global add hexo
したのを消してyarn global add hexo-cli
したら治った
- 記事更新してもなんか動かない
- => hexo のローカルキャッシュ更新のタイミングを理解してなかった
- 成功
- atom フィード生成
- S3 直受け配信がまずそうなので、cloudfront をかます
- cloudfront の設定ミスってキャッシュ同士でリダイレクトループ発生
- => invalidate 教えてもらってキャッシュ捨てさせた
- cloudfront がS3バケットの相対パスを解決してるのに気付かず
- => ホスト側と同じ raw-assets フォルダ切って相対パス設定
- cloudfront 周りが落ち着いて podcast フィードを生成できるようになる
- podcast フィード生成
- podcast 審査中
マストドンについて所感
鉄は熱いうちに叩け。
- 表面上はただの Twitter、というかTweetDeck
- フェデレーションの抽象は一般ユーザーには理解が難しすぎる
- せめて Yammer ぐらいは倒してほしい
フェデレーション(連邦)
ユーザーレベルだとTwitterと同じサーバー抽象にみえるが、その上流にサーバーレベルP2Pとでもいうのだろうか、サーバー同士が接続して大きなストリームを形成する。
fshinさんが指摘するように、リモートの削除に難があるが、炎上するような連中はそこまで考えないので、普及するとした場合、それが普及のボトルネックになることはないと考えている。これは善悪でかくあるべしという話ではなく、そうならざるをえないという話。
マストドンに関する現時点での解釈と感想 | F's Garage
中のコード
https://github.com/tootsuite/mastodon 読んだ。
Rails / Postgres / Redis / React / Redux / Node Websocket
素直。愚直。という印象。ISUCONの教材として殴り合うといったインフラエンジニアのおもちゃとしていいのではないか。
希望
Twitterはマイクロブロギングという文脈では今までこれといった競合がおらず*1、UIが商業的にどんどん邪悪に、サードパーティ開発者を締め出してどんどん傲慢になった上で、収益化に失敗という、割とどうしようもない落とし穴にハマっている。サードパーティ開発者の信頼を取り戻すことに取り組むという声明はでているが、信用されてはいない。正直言って、今が頂点で、落ち目のサービスになってしまっていたと思う。
マストドンに期待するのは、邪悪で傲慢になり続けるTwitterに対する競争相手になってくれることで、理想的には、Twitter側が GNU Social に対応せざるを得なくなるぐらい落ちぶれて、マストドンの1つのサーバーというレベルにまで蹴落とされるのが望ましい。UIとインフラで差別化してほしい。そうするとGNU Socialというマイクロブロギングの1プロトコルという立場で、オープンなプロトコルとして、互換サービス郡のエコシステムが花開くだろう。
昔はTumblrがそうなると予想していたが、そうならなかった。
で、流行るの
これが未来とか言うつもりはない。結局SNSは生まれては飽きられる運命にあるし、僕らは常に最新の棺桶に乗り換える永遠の流民であり、アーリーアダプターの居心地の良さはすぐ失われれる。もう失われつつある。一瞬流行ったけど、そんなものもあったね、で終わる可能性は高い。
自分が使うかというと、微妙。自分は2回データ吹っ飛んだので、だるい。とりあえず定点観測する。Twitter への圧力としてがんばってほしいですね、おわり。
筋トレ、スカイクロラ
肩こりは治らないのは筋力が足りないからだ、という仮説のもと、最近毎日腕立てをするようにした。左肩だけ異常に凝ってる。右利きなので、左の筋力が足りないのでは?という仮説がある。
最初は12x2で死にそうになっていたが、徐々に回数を増やして、今日は 20x5 やった。やりすぎたと思った。が、全然肩が痛くない。筋肉は増えたと思う。肩こりが治ったかというと、多少良くなった気がしないでもないが、あまり関係はないのではないか。
どちらかというと、必要なのは背筋・広背筋で、ラットプルダウンを家に買おうと思って調べたが、それなりのやつが4万円する。場所も取るし、もっと別のトレーニングから入ったほうがいいかもしれない。家でできるトレーニングを調べている。
読書
スカイ・クロラの一巻を読み終わった。森博嗣はあんまり読んでなくて、この前「すべてがFになる」を読んだぐらいだった。自分の読書スタイルは、SFのオールタイムベストから入って、その周辺に及ぶという感じなのだが、読み終わって、面白いとは思ったのだけど、ちょっと引っかかる部分があった。
ドッグファイトのスピード感を演出するために、短文で改行するスタイルが、とてもライトノベル的演出だと感じてしまって、ラベリングで忌避するのは良くないとわかりつつ、苦手なジャンル的演出だという意識が先行して、その部分だけ冷静に読むことができなかった。たぶん逆で、ライトノベルが部分的に森博嗣的なのだろう。
そこでふと思ったのだけど、戦闘機モノは他にも、トップガンとか戦闘妖精雪風あるわけだけど、あれにロマンを感じる筆者の熱意は伝わってくるんだけど、自分には、それをイメージする力が足りてなくて、読んでいて多少歯がゆく感じる。想像力を補うのに、映像作品から入ったほうが良かったのだろうか。自分はミリタリーには疎くて、ミリタリーとしての戦闘機モノにはあまり興味を惹かれないのだが、SFとしてのロマンがそこに生まれるのはわかる。わかるが、及んでいない。歯痒いなぁ。
とりあえず今はスカイ・クロラの2巻を読んでいる。
フリーランス一週間目、不安、人格、Redux
契約先
週3でアカツキ様、週2でリクルートテクノロジー様で開発に関わらせてもらっている。どちらも公開の許可を貰った、というかむしろ宣伝してくれと言われた。アカツキは @seizans さん、 リクルートテクノロジーズは @yosuke_furukawa さんの繋がりで仕事をとった。事前に面識がある人に相談することで、人格面や技術面のすり合わせが楽で、ゼロベースの信頼関係にならず対人関係のストレスが減るようにコントロールした、つもりではある。
全く違う仕事をしているのではなく、どちらも redux 周りをやっている。みんなそこで苦しんでいる。今、界隈を絶望させているのは react-router v4 であり、これが諸悪の根源であるといって差し支えない。既に辛い気持ちなっている。絶対に倒したい。
ネットの人格
契約先の話で思い出したんだけど、僕はネットで暴れてる方と、リアルで卑屈になってる人格に乖離があるので、前者のせいで警戒されている、と感じていて、そのイメージは崩していきたい、と2年ぐらい前から思っている。ブログだと、まだ冷静なんだけど、Twitterは、本当に思ってもないことを言っている。言い訳すると、フォロワーが多くて言いたいことを言うには、マジレス避けに多少気が狂ってるふりをする必要がある。
木を隠すなら森。
Redux について
いくらか誤解があった。リクルートテクノロジーズで koichik さんと議論して幾らか解決した。いろいろとネガってきたので、あとで別途記事を書くが、要は middleware はいわゆる middleware ではなく、 input: Aciton => Promise<Action>
とでも表現する、 mapAsync な層だという話。名前が悪い。
それとは別に、やっぱまだ好きじゃない気持ちがあり、しかしコミュニティの力は偉大で、我々はそれに巻かれるしかない。それがマーケティングの敗者の敗戦処理。僕は、そこに訴求できる人間になりたかったのだけど、国内はある程度できるとして、海外の趨勢は何とも言えない。
とはいえ、猫も杓子も redux という世界観は絶対に間違っていると思う。
不安
これはしゃーないと思っているのだが、最初はどうしても環境構築/キャッチアップから入るので、自分のやりたいレイヤーにたどり着くまで時間がかかる。で、まだ2つの環境では、まだキャッチアップしかできていない。 また、使ってるフレームワークの、使い方がそのプロジェクトでどう決まってるか、どこからドメインなのか、で、頭の使い方が変わる。コンテキストスイッチもある。
あと、自分が知らないことを、周りの人がみんなが知っていて(勿論ドメイン知識の差だというメタな認識がありつつも)、卑屈になりがちで、ハハァソウナンデスネースゴイとなりがちで、こんなんでいいのか、もっと短期にバリューを出さないと、フリーランスとして価値が出せてると言えないのではないか?という焦りもある。新しい環境とはこんなもんだ、というのもある。
自分より凄い人がいて、自分が劣っている、という劣等感は常にあるんだけど、実はあまりマイナスのものだと思っていなくて、自分がプログラミングを覚えて、その後成長したのも、それがあったからだと思っているので、この劣等感は大切にしたい。勿論、これを感じることによるストレスを扱いきれるかどうかは、その人次第なので、みんながこうあるべきとは思わないが、自分はそうという話。
あと、最近わかったのは、自分は不安を感じると事務作業に逃げる傾向がある。不安の種が別の不安を生むので、小さい不安をとりあえず排除したくて、税金周りの手続きを、徹夜ですませたりした。むしろ、不安がないと楽観しすぎてこの作業が進まないので、たまに必要だという気がする。不安がなくてもやるべきだが。
休日のとり方
フリーランスの休日というものが、よくわからない。週のうち何日働くという契約だが、GWとかどうなるんだろう。お伺いを立てるんだろうけど…。
結局この週末は知識が追いついてない不安を排除するために勉強時間にあててしまっている。一回倒せば2年ぐらい大丈夫そうなんで、やっておくが。
今後の技術的な方向性
- redux middleware を倒す
- flowtype の普及に努める
- Backend For Frontend
- next.js
- さらにその間の層として ServiceWorker がありそう
- react-native?
Reactはもう僕が宣伝しなくていいステージにきていて、ぶっちゃけView基盤としてのReactは簡単で、特に教えるものはないと思っていて、やはりその周辺、redux middleware 周りにドメイン知識の差が出る。
フロントエンド特化から Backend For Frontend までレイヤーを一つ増えた感じはある。
react-native は需要の高まりを感じており、モバイルというものそのものが嫌いだが、react-native の技術的な方向性は好きで、需要から逃れきれない雰囲気などもあり、Universal JavaScriptの文脈で、とりあえずキャッチアップはし続けておく。
読書
移動時間が増えたので、Kindleに積読を増やして消化していっている。最近は「高い城の男」を読み終わって「スカイ・クロラ」読み始めた。あと Rebuild.fm の未消化のやつ。
ニンジャスレイヤーの第三部の真ん中から先を読み直したいのだが、1年読んでないので忘れてしまっている。
スプラ2試射会感想
https://topics.nintendo.co.jp/c/article/1e79cd99-ec4b-11e6-9aaf-063b7ac45a6d.html
6回中、4回参加
15キル #Splatoon2 #試射会 #NintendoSwitch pic.twitter.com/ARl12CIcy9
— これはネタバレなんですけど (@mizchi) 2017年3月24日
たのしいよ #Splatoon2 #試射会 #NintendoSwitch pic.twitter.com/zl5Qg40hG9
— これはネタバレなんですけど (@mizchi) 2017年3月24日
リスキルしてた #Splatoon2 #試射会 #NintendoSwitch pic.twitter.com/JBanb0617V
— これはネタバレなんですけど (@mizchi) 2017年3月25日
よかった時のを貼ってるだけで、実際のキルレは2.0ぐらい。ほとんどローラー持ってた。試射会2時間前からスプラ1を久しぶりに起動して、仲間内のナワバリでエイムを温めていた。やっぱ1年放置してると鈍っている。
雑感
どうしても初心者狩りになりがちで、すまんという気持ちはありつつも、興奮が抑えられず、安全圏から離れた敵は見つけ次第狩りにいってしまっていた。とはいえ初心者とそれ以外をゾーニングするのは任天堂がマッチングでなんとかしてほしいんだが…。後半ほど手応えがあったので、内部レートがあったような気がする。わからん。
回線、自分は一度も落ちなかったが、8人中、誰か一人は落ちてて、ワンサイドゲームになりがちだった。これは改善してほしいが、自分が一度も落ちてないことを考えると、そもそも改善品質に問題がある人(テザリングなど)がそれぐらいで紛れてる可能性はある。
ブキ
スペシャルが基本的に抑え目。打開というより、全体的に安全圏から落ち着いて使わないといけないような技に寄せられてる。スプラ1が無敵ゴリ押しゲーになってる現状、無敵は今後も追加されないか、なんらかのトレードオフとともに実装されるだろう。
ローラーの縦振りは足りない射程が得られるがエイム要求が厳しい。外すと死を覚悟するやつ。ローラー同士だと落ち着いて横振りを出せる方が勝てる印象だった。発生も同時なら横振りのが速い。とはいえローラーの腐りがちな中距離戦で選択肢が増えたのはいいことだと思う。スーパーチャクチは初見殺しで強かったが、試射会終盤だと徐々に見切られていたので、実際の運用できる使い方は限られる気配がある。壁際に追い込んで使うか、完全に意識の外から使うか、どっちか。無理に距離を詰めるムーブは既に試射会中でも見切られていた。
マニューバは何一つシューターに勝てておらず最弱という仲間内の評判。レートか飛距離が上がらないと未来はなさそう。ジェットパックは操作に慣れてる人がおらず、あんまり脅威ではなかった。
シューターはいつもどおりの性能。サブ次第でこれからもトップメタ張り続ける気がする。ミサイルランチャーは追い込み用で、単独でキルを取るというより、索敵兼、退路を固定して追い込んで狩る用という感じ。今回のスペシャルの中では一番使いやすい。
チャージャー、わからん。あたらん。上手いチャージャーは無限にうまい。
発売まで
夏になったら起こして。
今、SPA/ReactNativeにとっての必要な PaaS を考える
当方ボーカル、フルスタックPaaS募集
ほしいもののコンセプト
- SPA職人としてそこに全力を尽くしたいので、それ以外を全部やってほしい
- とはいえストレージへのアクセスはAWS Lambda/Cloud Function等を介してちゃんとしたコントロールをしたい
- プロトタイピング時は何も考えずにORMを叩いていたい
- 運用フェーズでは金を払ってスケールしたい。とはいえボトルネックは常に監視したい。極端にやばいスケールサイズはどうせ人を雇うのでその先は考えなくていい。
より細かい要求
- 認証はPaaS側が全部持ってほしい
- JSONSchema でクライアント/サーバーサイドのアクセス制限を定義したい
- サーバーはフルマネージド
- Lambda/CloudFunction で関数単位でパフォーマンス監視/障害検知
- ローカルで本番と同じ構成が建てられる
- アセットは勝手にCDNに投げといてほしい
- バックエンドストレージは、 BigQuery/Mongo風の列指向DBで、インデックスが貼れて、オートスケールしてほしい
- 無停止でなくてもいいから任意なバックエンドに引っ越すのが簡単であってほしい
- Google だったら Datastore で初めて、辛くなったらSpannerとか。
- AWS だったら DynamoDB => Aurora とか
- 結局SQLじゃんってのはわかるが、適切なActiveRecordみたいなのがあれば問題ないと思っている。
- ちゃんとしたNodeのORMがほしい。joinの抽象は…必要かどうか悩む。非同期アクセッサはどうやってもNodeで表現しづらい。
- ORMは型を書きやすいインターフェースでないとこの先ダメ
- たとえ相手がNoSQLだろうがMigrationがないとダメ
- MongoQuery風のクエリがほしい
- 無停止でなくてもいいから任意なバックエンドに引っ越すのが簡単であってほしい
妄想したAPI
const schema = { definitions: { todo: { required: ['title', 'done'] properties: { id: { type: 'string', primary: true }, ownerId: { type: 'string', index: true }, title: { type: 'string', }, done: { type: 'boolean' } } } } } const todoStore: Store<Todo> = new Store({ storeName: 'todos', schema: schema.definitions.todo }) const main = async () => { await todoStore.save({ title: '朝食', done: false, ownerId: 'mizchi' }) const todos = await todoStore.where({ownerId: 'mizchi'}) console.log(todos) } main()
これが無限スケールしてほしい。いや、このAPIを再現するだけなら簡単だが、運用まで含めると考えることは無限にある。マイグレーションとか、実際 store.save 関数の中身がどこに飛んでるのか、とか。バッチアップデートはどうするんだ、認証は?
それらを全部クリアした上で、あとはフロントエンドとしてReact/ReactNativeに繋いで、終わり!って感じ。いや自分のメインの仕事はそこからはじまるんだけど。
現実の課題
これらを落とし込んだソリューションというか、「正解」なスタックというか、そういうのがない。みんな手探り。
実際今どうするのが正解か
AWS Lambda / Dynamo
調べると、Lambda が RDS とコネクションヒープが持てない関係で相性が悪く、スループットを出すにはDynamo を使え、という感じになっている(たしか公式ドキュメントにもそう書いてある)。Dynamo を使ってみたが、スループットのコントロールはAPIでコントロールしたり、金で解決できるんだが、場合によっては取得を諦めたりするし、挙動が難しい。何も考えずに使えるものではない。返り値もなんか変で、毎回整形するのがめんどい。ラップすりゃいいんだが。
S3, API Gateway, Lambda, それらの複合を考えていくと、k8sやTerraform とか使うのが最近の流行りっぽいが、完全にAWS沼/コンテナ沼だと認識してるので、今は距離をおきたい。ビルドツールにDockerを使うのに抵抗はないが、デプロイされる環境まで自分はやる気がない。
Google Firebase
Firebase hosting という機能があって、元々はGoogleのクラウドにSPA、というかindex.html をデプロイするだけの機能だったんだが、どんどん機能が増えて、最近 cloud function のインテグレーションがきた。Firebase Realtime Database はローカル制御の限界があったが、ストレージへの保存時の検証をクラウドでやれるようになったので、実質今までのサーバーと同じような運用ができる。
https://firebase.google.com/docs/functions/
とはいえ、Firebase Realtime Database はリアルタイムストリームに優れるけど、ストレージのサイズの料金とreadの料金が高いので、真面目に作ると他のバックエンドに接続する必要がある。しかしそれも cloud function 経由でできるから、もしかして怖いものはないのでは、それが RDS/Lambda みたいな問題がなければ、と思っている。
GCPの範囲内なら、実際の繋ぐ先は、ホビーユースなら Cloud Datastore 一択らしい。Google Spanner がいいらしいって雑な情報で値段を調べたけど、 1ノード1時間 $0.9 で何もしなくても軽い試算でも月7万円ほどかかる。これはない。けど、月7万も必要なサービスを回せるんだったら、売却含めてその時点で何かしらマネタイズできると思うので、まあ考えなくてよい。AWSエンジニアを月100万で雇うのと比べれば7万は誤差。
認証系も組み込まれて強力。アクセス解析やAdMobの組み込みがある。僕はAdMobは使ったことがないので不明だが。
というわけで、最近はFirebaseを掘っている。
Firebaseに足りないもの
GCP全体に言えるが、なんとなくどれもBeta版っぽくて、ベストソリューションもないから、これとこれとこれ!って選択ができなくて、Railsみたいな選択の迷いのなさが生む生産性には遠い。
Node視点だけで見ると、次のものが足りない。
- Lambda/Cloud Function の抽象化レイヤー
- バックエンドのアダプターが充実したORM
- これらを実践した運用の体験談
たとえば、 Rails Tutorial 相当のことを、同じかそれ以下の分量で違和感なく記述するフレームワークがポンと提案されたら、みんなそれに乗ると思う。
自分がそれを作るから金をくれーといいたいのはある。いや、自分はGoogle技術の専門じゃないんで、GCP周りは専門にする他の人にはまだ劣ると思うが、実際にSPAと組み合わせて、オールインワンで諸々隠蔽した上での開発環境のスタックの構築は、自分のようなスキルセットの人間に強みがあると思うので、フリーランスの仕事の幅になるかなと思って勉強中。現状、半年分の仕事は埋まってるけどなんかあったら依頼をください。現場からは以上です。