isyumi_netブログ

isyumi_netがプログラミングのこととかを書くブログ

『あのアーティストの代表曲は』の技術詳解

 

こういうWebアプリを作った。
https://famous-song.app/

本人は企画として面白いと思っている。
せっかくなので、どういう技術で作られているかについて解説する。

概要

まず、認証とRPCは全てFirebaseを使っている。
サーバーサイドはFirebase HostingとCloud Functions。
フロントエンドはTypeScript/React/Redux/typescript-fsaあたりを使った。
投票ページはSPAで、それ以外の結果表示ページはSSRしている。

意図

SSR

最近はSSR不要論も多い気がする。
ただ、フロントエンドでSPAと合流するようなSSRならともかく、ペライチのHTMLを生成するだけならSSRしたほうがロードが速いし実装も楽だと思う(そこに反対する人はいないと思う)。
SSRにはReactのtsxを使った。
tsxを使うと、引数にTypeScriptの型をそのまま使えるので簡単である。

SSRのCache-Controlにはこれを指定した。
public, max-age=10, stale-while-revalidate=1000
キャッシュが古くてもとりあえずCDNのキャッシュを返し、その間にCDNからCloud Functionsにアクセスしてキャッシュを入れ替える。
こうした理由はコレだ

  • Cloud Functionsはそこそこ重い
  • リアルタイム性が超重要というわけではない
  • ユーザーも、おかしいなと思えばリロードするくらいのリテラシはあると思う

コマンド化

フロントエンドからRealtime Databaseの公開データを直接書き換えるのではなく、
フロントエンドからサーバーサイドにコマンドを送って、サーバーがそのコマンドを元に公開データを書き換える仕組みにした。
こうした理由は、この方がバリデーションやアクセス制御の点で楽だからだ。

この方式には1個欠点がある。
フロントエンドでサーバーの処理待ちがしづらいことだ。
RESTであれば、POSTを投げてからサーバーで処理が終るまでグルグルを出しておくということが簡単にできる。
しかし、Firebaseでコレをやってしまうとグルグルを消すタイミングがわからないという問題だ。
そこで、サーバーで処理が終わったこともRealtime Database経由でフロントエンドに通知することに指定ある。
その部分を抽象化してあるので、フロントエンドはasync/awaitで簡単に処理の待ち合わせができるようになっている。

フロントエンドでの正規化

それなりに大きいフロントエンドであれば、フロントエンドでも状態を正規化して持つべきだ。
正規化というのはRDB用語かもしれないが、要するに

  • 値段は三桁ごとのコンマを入れずに数値で持つ
  • Dateはタイムゾーンを統一しておく
  • 省略可能なものに関しては必ず省略する
  • RDBと同じように関係で表せるものは関係で表す

というよううなことだ。
タイムゾーンに関しては、YYYY-MM-DDの文字列で持つというのも結構優秀だ。
省略可能なものというのは、例えば誕生日・現在時刻・年齢や直角三角形の3辺など、二つが確定すれば残り一個も確定するようなものに関してはその1個を省略して持つほうが扱いやすい。
関係で表すとは、例えば、商品一覧とユーザー一覧と購買一覧があるなら、無理にオブジェクトで親子関係を作らずに配列を三つ持つということだ。

重要な点は、そのデータがどのように使われるかをあえて意識せず、データとしての完全性を最優先した型で持つことだ。
一見、そのデータがどのように使われるかに応じて型を決めたほうが後の処理を楽に作れる気がする。小さなアリケーションならこういう考え方もあると思う。
しかし、そういう考え方だと早晩コードが散らかってカオスになる。データの使い回しがしづらくなる。
やはり、データは極力完全な形で持つべきだ。

タブレイアウト

僕は、タブレイアウトって素晴らしいと思っている。
昔rebuild.fmでもそういうことを言っている人がいた。
2ch専ブラのJaneStyleやTabtterなど、人気のツールはだいたいタブレイアウトだ。
だから僕もタブレイアウトにした。
Webというものはクモの巣状にリンクが広がっていくモデルなので、ネイティブアプリと違って階層構造で画面遷移を表現しづらい。
それならば全てはタブであるという一般化をしたほうが認知しやすい。

アイキャッチの自動生成

Twitterなどにリンクを投稿する時のOGPのことだ。
実装の詳細はここに書いた。
https://qiita.com/isyumi_net/items/ee94a5e2d963958eb515
頑張ってレイアウトを計算すれば画像処理の延長で生成自動化は可能だが、
今使っている技術の延長で画像を生成できるということで、puppeteerを使った画像生成をした。特にBootstrapを使えるのでデザインが統一できて良い。

あのアーティストの代表曲は

 

序文

あのアーティストの代表曲は何だと思うかについてのアンケートサイトを作った。

https://famous-song.app/

きっかけ

たまたまいろんなアーティストのCD売り上げランキングを調べていた。
このランキングは、僕の主観におけるそのアーティストの代表曲と一致していない場合があり面白いと思った。

例えば、B’zで一番売れた歌は『愛のままにわがままに 僕は君だけを傷つけない』だが、B’zといえば『ultra soul』な気がする。

という話を会社でしてみた。
そこから、あのアーティストの代表曲といえば何だという話になった。
これが大変盛り上がった。

なので、アンケートサイトを作ってみた。

集計方法

とりあえず、CD売上ランキング上位30人を事前に入力しておいた。
その他のアーティストも入力できるようにしてある。
Twitterに放流してみたものの、あまり広まらなかったのでシュフティで50円くらい払ってアンケートに答えてもらった。

結果

B’zはもちろん『ultra soul』だった。
意外だったのはEvery Little Thingの代表曲にfragileを選んだ人が一番多かった。ここは絶対『Time goes by 』だと思ってたのに。
他にも色々おもしろい結果が出たから見てほしい。
https://famous-song.app/

思ったこと

まず、ちょっと古い。そもそもアーティストのCD売上ランキングというものを取ると、2000年前後のアーティストが大半を占める。
今の10代~20代前半の人にはピンとこないのではないか。
ここには二つの理由があると思う。
一つはCDという媒体の問題。
もう一つはポップカルチャーが細分化してしまったという問題。おそらく、未だにCDという媒体が続いていたとしても、アーティストのCD売上ランキングはほとんど変わらなかったと思う。

プログラミングが上達しない人の特徴

結論

型が言えない。

概要

初心者ではない。会社では一人前扱いされている。それでも、プログラミングが遅い。バグが多い。必要な知識はちゃんとあるはず。
そういう人を何人か見た。

その人たちに型が言えないという共通点があると思った。

まず、型が言えないとはどういう状態か説明し、解決策を提案する。

自己紹介

多分本当に速い人。

業務のプログラミングは速い。
AtCoderで容問を速解きするだけなら相当上位。

本題

型が言えないとはどういう状態か

例えば、極単純な電卓アプリの型を考えてほしい。
二つの数値に四則演算をして計算結果を画面に表示するとする。
この際、値域や未入力の状態やゼロ除算の対応やカーソル位置などは全部置いておこう。
この電卓の型を言うならこんな感じだろう。

{
  input1: number,
  input2: number,
  method: "+" | "-" | "*" | "/",
  output: number,
}

一応、オペランドだとかそいういう用語が存在するがそういうのも置いておこう。
とりあえずこれで十分なはずだ。

当たり前だと思った人はこちら側の人間だ。おめでとう。
どうも、大多数のプログラマーはこれができないらしい。
かなり適当な統計だが、どうも職業プログラマーの半分強の人はそうっぽい。

では、その人たちはどうしているか?
実装を書きながら必要に応じて型定義を書くしか無いのだ。

こういう人がプログラムを書くとどうなるか。

全体の流れを型で見通すということができないので、そこかしこにparseIntが氾濫する。
手戻りが多すぎて時間がかかる。
本来Aという処理とBという処理をどうつなげるか考えて型を書くから静的型付き言語は間違えにくいのに、Aという処理を書くことに集中している時に型を書き換えるから間違いが増える。
そこをどういう値が通過するかは言えるが、どういう値が通過することはないかを言えないので、極力狭い定義をしようとしない。

型が言える人とはどんな感じか。

自分の場合であれば、作るアプリにどういう機能があるかわかっていたら、こういうものはだいたい事前に全部列挙できる。

  • RDBの定義
  • RESTのエンドポイント
  • いろんなオブジェクトの型
  • 各クラスにどんなメソッドがあるか
  • URL設計
  • 何をDIしないといけないか

先に列挙しておいて型と型をつなぐように実装を書いている。
だからあんまり間違えないし、ほぼ何も考えなくても正しいコードになっている。

僕だけの特殊技能ということでもないようだ。できる人はみんなほぼ無意識にできるっぽい。

どうすればいいか

練習するしか無いんじゃないかと思う。
gitの練習サイトのようなものがあるから、似たような練習アプリを作ってあげたらいいんじゃないかな。

僕はプログラミングがとても速いのだ

 

概要

僕がいかにプログラミングが速いかについてAtCoderの成績を元に説明する。
どちらかといえば、AtCoderのことをよく知らない人向けに書いた。ところどころ厳密ではない書き方をしたが、わからない人を混乱させないための言い回しなので、詳しい方はご勘弁願いたい。
正直言って、自分でこんな記事を書くのはダサくて恥ずかしい。
でも、自分で言わないと誰もわかってくれないから書く。
なんでわかってもらう必要があるかと言うとオチンギンガ……

経緯

僕はAtCoderで水色である。
正直、水色というのは凡庸な成績だ。
なぜこのような成績になってしまうかと言うと、僕に難問を解く力がないからだ。
逆に、簡単な問題を速く正確に解くのは得意だ。
なので、AtCoderのレートではなく簡単な問題を解く速さと正確さをアピールしたかった。

前提

AtCoderの難易度について

AtCoder界隈では問題の難しさを色で区分する習慣がある。
これは、主観ではなく解答できた人のレーティングを元に算出した客観的な分類だ。
簡単な順に

  1. 灰色
  2. 茶色
  3. 緑色
  4. 水色
  5. 青色
  6. 黄色
  7. 橙色
  8. 赤色

である。
灰色が一番簡単である。
だいたいどのくらいのレベルかと言うと、灰色の中で一番難しいのがこのくらいの問題である。

X,Y,H,Mが与えられる。
時計の長針と短針の長さがそれぞれXcm,Ycmである。
H時M分の時、2つの針の先の距離は何cmか?

決して難問ではないが、そうそう即答できるわけでもないと思う。
AtCoder未経験者が想像する「一番簡単な問題」よりは難しいと思う。
諸説あるが、大体普通のお仕事でWebアプリケーションを開発する仕事の難度は高くて茶色前後だと思う。
ちなみに、僕はこの問題を10分で解いた。参加者の中央値は50分だ。
(それ以前の問題を解くのにかかった時間を引いた)

調査方法

AtCoder Beginner Contestの中で直近26回のコンテストを対象にする。
これは、これまで僕が出場した全てのAtCoder Beginner Contestだ。

問題は緑問題以下を対象とする。
これはざっくり言って、参加者の上位1/3が正解できる難易度の問題だ。

制限時間以内に正答できなかった人は制限時間である6000秒で正答できたとみなす。

集団の偏りについては、AtCoderの参加者は世間一般のプログラマーよりプログラミングが上手なのか下手なのかは色んな意見があるが、ここではだいたい一緒とみなして話をすすめる。
また、そもそも他の参加者は全力を尽くしているのかという問題があるが、そこは考えないようにする。
例えば、AtCoderのルールでは強豪ユーザーはAtCoder Beginner Contestでいい点を取るメリットは全くないが、彼らも一生懸命問題を解いていると想定する。

解答の速度と正確さを評価することにする。

速さ

解答の速さは

  • 自分が正答するのにかかった時間を他の参加者の中央値と比べる
  • 自分が正答するのにかかった時間が参加者の上位何%か調べる

正確さ

AtCoderでは、解答を提出するとその場で正誤がわかる。
誤答をするとスコアが下がるので、一般的に参加者は極力誤答を提出せずに正答を提出しようとする。
なので、正答するのに要した誤答の数が少ないほど正確なプログラミングが出来ると言える。

結果

解答の速度

問題を解いた時間をグラフにした。

f:id:isyumi-net:20200820174842p:plain

左に行くほど簡単な問題である。
茶色の真ん中あたりからオレンジのグラフが全て6000に張り付いている。そもそも半分の人は解けていないのでこういうグラフになっている。
これを見ると、大体中央値の1/3くらいの速度で正答できていることがわかる。

 

次に、これは解答速度が参加者の内上位何%だったかを表したグラフだ。

f:id:isyumi-net:20200820174901p:plain

大体、上位15%であることがわかる。
計算した所

  • 灰色問題までは平均13%
  • 緑色問題までは平均18%

であった。

解答の正確さ

僕が一度も間違えずに提出できたのは
100回中85回 で、成功率は85% であった。
これは48,990人中3,4662位で、上位7%である。
中央値は50%なので、1.7倍正確にプログラミングができると言える。

結論

簡単な問題(とはいえ、一般的な仕事の基準では十分難問)を解くことについて、僕はこのくらいのスキルだと言える。

  1. 僕のプログラミングの速度は、一般的なプログラマーの中で上位15%くらいである
  2. 僕のプログラミングの速度は、一般的なプログラマーの3倍くらいである
  3. 僕のプログラミングの正確さは、一般的なプログラマーの上位6%くらいである
  4. 僕のプログラミングの正確さは、一般的なプログラマーの1.7倍くらいである

僕が設計だと思うもの

設計について

自分はソフトウェアの設計を担当している。
ところで、会社によって設計という業務の指す範囲が異なると思う。
ただ『設計をしている』というだけでは、自分の持つスキルが伝えられないのではないかと考えた。
そこで、自分が実際にどのような作業をしているのか、そして、どのような考え方をもってその作業に当たっているのかを記そうと思う。
ここで言うソフトウェアの設計とはビジネスの設計やプロジェクトの設計の話ではない。よって、ビジネスモデルや人員配置というような話ではなく、狭い意味のソフトウェアの設計の話だと思ってほしい。

信念

  • 設計通りに作って動かなかったら設計した人が悪い
  • 設計に解釈の余地があったら設計した人が悪い

設計書と称して何を読み取ればいいのかよくわからないポンチ絵を作って満足している人が多いようだ。
しかも、えてしてそのような人は「上流工程」と呼ばれて、その人の仕事の不出来を下位団体に気軽に押し付けられるようだ。
それでは仕事をしたことにならないだろう。
「設計した」というのであれば、そのとおりに作ったら意図したとおりに完璧に動くべきだ。

具体的にやっていること

これを決めている。

  • RDBスキーマ
  • Redisの型
  • サーバーサイドプログラムのモデルの型
  • RESTの型
  • フロントエンドのモデルの型
  • フロントエンドのビューモデルの型
  • フロントエンドのURLと画面の対応
  • IndexedDBの型
  • その他各種DIしなければいけない副作用の型

Redisの型とは、RDBとRESTを見比べて、どんなキャッシュがあれば全てのRESTの処理を現実的な計算量に出来るか考えるということも含む。
RESTの型の中には、各エンドポイントの権限とCDNの設定を含む。
IndexedDBは、WebフロントエンドではなくAndroidアプリやiOSアプリの場合はSQLiteになる。
DIの型というのは、例えば乱数や現在時刻のことだ。

核心の技術

僕は、「ある対象を見ると、その型を正確に言うことが出来る」という特技がある。
例えばこのツイートの型を考える。

f:id:isyumi-net:20200815140256p:plain

まず、アイコンのURLが必要だ。

表示名(日本語の所)とユーザー名(アットマークで始まる所)はそれぞれstringだ。

日付は、「10秒前」「5分前」と言った表記になることがあるので、モデルではDate型だが、ビューモデルではstringである。

また、この日付をクリックするとそのツイートのURLに飛ぶので、TweetIDを整数型で持つ必要がある(言語によってはintに収まらないので注意)。

本文もモデルとビューモデルで異なる。モデルはstringでいい。ビューモデルは改行やハッシュタグやメンションに対応しないといけないので、「通常のテキスト」「ユーザーID」「ハッシュタグ」の代数的データ型の配列の配列が正解のようだ。

その下は画像だ。画像は複数枚上げられるのでimg型のリストである。img型には画像サイズと表示領域から計算したトリミングの情報などを入れておくと画面を作りやすい。

めんどくさくなってきたのでこのくらいにするが、他にもいいね数や引用ツイートや右上のプルダウンメニューの開閉なども型に落とし込んでいける。

僕は複雑なシステムでも短時間で間違えずにこれを全て書き出すことが出来る。
これが僕の核心になる技術だ。
実は結構簡単。

これはなんなのか

要するに、GoF本などで主張されてきた『インターフェースに対してプログラミングする』ということである。
これをシステム全体に適用するということだ。
一つの大きなシステムを各部品に分け、その接合部を事前に全て決めてしまうということだ。

なぜいいのか

こうすることで、各部品が粗結合になり、コードが綺麗になる。
複数人で同時に作業できるようになる。各作業員の仕事は、ある型からある型に変換する純粋関数を書くだけになり、考えることが減る。
何が正解で何が間違いかはっきりするので、テスト駆動開発ができる。
他人の指導もしやすい。

大工さんが家を建てているとしよう。
一人の大工さんが一階を組み立て、もう一人の大工さんが二階を組み立てている。
この時、もし一階の大工さんも二階の大工さんも、それぞれ一階と二階の図面を見ながら作業を進めれば頑丈な家が建つのが理想である。
逆に、一階の大工さんと二階の大工さんが密に設計を相談しながら仕事を進めないといけないなら、手間だし本当に頑丈な家が建ったのか怪しい。
だから、工務に入る前に誰かが設計を確定させておかなければならない。
ソフトウェアの設計も同じである。

何ではないか

例えば、これらは設計の範囲ではないと思う。

もしかしたら一般的にはこういうことの方が設計と呼ばれているかもしれない。
しかし、僕はこういうのは設計とは言わないと思う。
これらは、ベストプラクティスやその会社の慣習が確立していることなので、どちらかといえば設計と言うより日頃の行いの問題だと思う。
また、インターフェースを満たしている限りそこを自由にすげ替えられるということが重要なのであって、そこを決めるのが対して大事な仕事だと思えない。

想定される反論

それはウォーターフォールの考え方だ。我々はアジャイルなのだ

短いサイクルで機能変更を繰り返していくからといって、ある瞬間には実現したい機能要件というのが確定しているはずで、そうであれば設計は出来るはずである。
短いサイクルで設計を更新して、それに合わせて実装も更新すればいいのだ。
短いサイクルで変更されるからと言って設計が出来ないとか設計が不要というのはおかしい話だ。

設計が終わらないと開発できない

それでいいと思う。
熊とワルツをに書いてある。
僕は自分が設計している間、他の人が手空きになることを全く問題だと思っていない。

僕がいるとどうなるか

  • 開発スピードがとても上がる
  • 入出力を整理しやすくなり、セキュリティを高めやすくなる
  • システムを変更したときにおかしくなりにくくなる
  • 少々スキルの低い人が混じっても大丈夫になる

まとめ

だれかお金ください。

Webが乗り越えるべき9個の課題

一人のWebアプリケーション開発者として、Webの世界に足りないと感じるものをまとめてみた。

Webの仕様の問題と業界の問題を区別せずに列挙した。

 

  1. 広告モデルからの脱却
  2. ネイティブUIを呼び出せるようにして
  3. お行儀の悪いアナリティクス用のJSを排除して
  4. もうサードパーティークッキーは禁止すれば?
  5. プライバシーに対する意思表示をセマンティックに
  6. ペアレンタルコントロールDNSを使うのはおかしくない?
  7. プロキシが流行ってほしい
  8. strict HTMLヘッダーの提案
  9. テキストエディタ

広告モデルからの脱却

今の所、コンテンツ提供者の収入源は広告だけだ。だから、僕は良心的理由でAdBlockなどを入れていない。しかし、はっきり言って広告はウザい。広告は画面を大きく占有する。広告は過激な色使いでチカチカしてくる。目立ちたいからだ。こっちは興味ないのに。

もっと簡単にコンテンツに課金する手段が必要だ。

コンテンツ課金の辛い点は、お金を払うことではない。サイト毎に自分の個人情報を入力することの不安と手間だ。

よって、ブラウザにその機能をもたせたい。自分の決済情報を入力しておけば、ワンタップでコンテンツを購入できる仕組みがあればいいと思う。当然こちらの個人情報は渡らないようにする。

 

https://jp.techcrunch.com/2020/03/26/2020-03-25-mozilla-scroll-partnership/

Scrollというサービスがある。もしかしたらこれが来るかもしれない。

 

ネイティブUI

Webアプリの最大の弱点はUIコンポーネントだ。

僕はAndroidアプリやiPhoneアプリも開発している。

AndroidiOSの標準コンポーネントを使えばサクサク動く。

それに対してWebの画面は常にもっさりしている。

タップやスクロールの判定がおかしくてイライラする。

所詮、HTMLとCSSは論文交換プラットフォームだ。

HTMLの表現力はネイティブの操作性には勝てない。

 

参考

 

blog.isyumi.net

 

 

少なくともGoogleFacebookTwitterですら、ネイティブアプリと同レベルの触り心地のWebアプリを作れていないのだから、これは絶対ムリなんだと思う。

 

よって、スマホのブラウザはJSからネイティブUIコンポーネントを起動できるようにするべきだ。

 

アナリティクス

広告業者やアクセス解析業者はサイトオーナーにトラッキングタグ的なものを提供している。

このスクリプトのお行儀が悪すぎる。

Chrome DevToolsのネットワークタブを見るとわかる。ページロード時にスクリプトがいっぱい無駄な通信を発生させている。

僕はマジでキレてる。

PageSpeed Insightsで95点のサイトにトラッキングタグを入れるだけで60点台になったりする。

Googleが提供するタグですらPageSpeed Insightsを10点近く下げる。

もう、トラッキングタグをJSで実装するのを禁止してほしい。

サーバーサイドでやればいいじゃん。

WebサーバーがAnalyticsサーバーにAPI経由でアクセスイベントを送信すればいい。

ちなみに、ブラウザにネイティブの機能としてそれを入れようと話し合われている。

早く何とかしてほしい。

https://github.com/WICG/conversion-measurement-api

 

サードパーティクッキー

ITPが始まった時、絶対これは無理筋だろうと思った。案の定カヲスなことになってきた。

度々抜け道が見つかるからだ。ITPの挙動自体が状態を持つ。それを悪用すればITPを使ってユーザーをトラッキングできてしまう。その度にAppleが複雑なルールを導入して対応する。イタチごっこになっている。

もう、まともな良心を持ったサイトオーナーはサイトをまたいだトラッキングは諦めていると思う。わざわざ頑張ってAppleの規制を迂回するのも面倒だ。そもそも、サイトをまたいでユーザーの行動を突き合わせてターゲティングするのは人権侵害感が出てきている。善人でありたい。

”インテリジェントな”トラッキング防止なんてできなかったんだ。

この際、サードパーティークッキーは全部禁止したらいい。

 

プライバシーに対する意思表示

最近、西洋の会社のサイトに行くといちいちCookieを使っていいか聞かれてウザい。

どの程度Cookieを使っていいかなんて考えたらわかるだろうと思ってる。

つまらない保険を掛けるために僕のアテンションを奪わないでほしい。

そこで、そのJSONフォーマットを定めたい。

サイトはJSONに個人情報の使い方を明示してそのURLをmetaタグに書く。

ユーザーは各自自分のブラウザに自分のプライバシーに対する考え方を表明しておく。

訪れたサイトがその意思表明に合致していたらそのまま閲覧が出来る。

合致していなかったら警告が出たりする。

それで済む話だ。

 

ペアレンタルコントロール

ペアレンタルコントロールDNSのレイヤーを使うのはおかしくないか?

僕はあまりペアレンタルコントロールという物自体が好ましいと思えない。しかし残念ながら、これがないと色んな話が政治的にまとまりづらい。

例えば、ペアレンタルコントロールができないと学校でノートPCを配布できないだろう。

さて、最近はペアレンタルコントロールDNSのレイヤーを使うことが多いようだ。

確かに、アダルトサイトのDNSを引けないようにしておけばサイトの閲覧を阻止できる。

しかし、これは情報汚染だと思う。

アダルトサイトのIPアドレスが何番であるかというのは、あくまで事実かどうかの問題であって、善とか悪とかを持ち込んでいい場所ではない。それはもう一個上のレイヤーでやることだ。この辺を区別しないのはポル・ポトと同レベルだと思う。

とりあえずDNSをそういうことに使うのをやめてほしい。

じゃあどうすればいいのか、プロキシだと思う。

 

プロキシ

僕はフォワードプロキシに絶大なる未来を感じている。フォワードプロキシこそがWebの未来だと思う。

 

 

blog.isyumi.net

 

 

フォワードプロキシを使うことが当たり前になるといいと思う。

画像圧縮などが出来るようになって便利なはずだ。

これは、一時期問題になった回線事業者による勝手な画像圧縮や政府による検閲とは違う。

あくまで、個人が自分の意思で業者を選んで使うものだ。

 

しかし、HTTPSに対するまともなプロキシプロトコルが存在しない。

HTTPSのプロキシプロトコルを定めるべきだ。

 

strict HTML

JSにuse strictという機能がある。

これのHTML版を作って欲しい。

ブラウザは、少々おかしなHTMLでも正しく解釈してくれる。

閉じタグを書き忘れたりしても、なんとなくリカバリしてくれる。だがその為に余計な処理能力を使っているはずだ(僕はブラウザの実装には詳しくないので想像だ)。

ところで、僕は大体ReactのSSRでHTMLを作って出力している。ReactのSSRは綺麗なHTMLを出力する。閉じタグつけ忘れなんて無いはずだ。綺麗なHTMLを出力している開発者に何のご褒美もないのはおかしい。

そこで、HTTPヘッダーにuse-strict-htmlと書いたら、ブラウザは綺麗なHTMLが来ることを期待するという仕様を作れないか。

そうすれば、ブラウザはより高速にHTMLをパース出来る。

HTMLのバイナリフォーマットを作ってもいいかもしれない。

 

 

テキストエディタ

GUIでテキストを編集できる系のWebアプリで使いやすいものを見たことがない。

はてなブログGoogle DocsTwitterの入力画面も。

ちなみに、UbuntuChromeTwitterに日本語入力しようとするとバグる。

唯一心を許しているのはStackEditという2ペインのマークダウンエディタだ。

textareaタグを頑張ってカスタムしてテキストエディタを作るのはもう限界だ。

なんとかしてほしい。

感銘を受けた本

せっかくなので僕が感銘を受けた本をいくつかあげたいと思う。
婚活はともかく、好きな本の話はわかりやすく自己紹介できるから良い。
IT系の本は除いた。内輪ネタだからね。