前ほど Fastly がアグレッシブにキャッシュしてくれない気する
死んでなかったわ
CDN のキャッシュ飛ばすサーバーが死んでる気がする
このサイトの 404 まともに実装してなかったのでやった
Travis CI でビルドが失敗したときだけ Slack に通知したい ということがあるかと思うのですが、残念ながら Travis の Slack 通知にそんなに細かい制御ない。
という方法で僕は対処していますが、なんだかなあという感じですね
React の Hooks で state に Object を使う
const [obj, setObj] = useState({});
const [value, setValue] = useState(1);
みたいなことをしているときに
useEffect(()=>{
obj.hoge = value;
setObj(obj);
}, [value]);
としても、コンポーネントはレンダリングされない。なぜかというと、オブジェクトが変わってるかどうかを React は表面的にしか確認しない(これは利点でもある、不必要な変更の走査やレンダリングがはしらない)。
明示的にレンダリングをさせたい場合、以下のようにすればよい。
setObj(Object.assign({}, obj))
新しいオブジェクトをメモリにつくって乗せてしまえば、オブジェクトのなかにあるデータが全く同じものでも、 React はレンダリングをかける。
こういう感じなので Object を Hooks の State に突っ込むのはいい考え方とは言えない(↑のドキュメントにもほかにもいろいろあんま相性よくないからオススメしないよと書かれている)。
全体的に Hooks はマイクロコンポーネントというか、末端のコンポーネントがとにかく強い力を持つべきみたいな世界観で作られているので、親に巨大な state をもって子にバケツリレーするみたいな実装とあまり相性がよくない。
これは React 全体の思想としてそうという話かもしれない。
プログラミングが出来る と一言で言ってしまうのはあまりよくなくて、ある程度分割して考えるほうがいいと思っている。
おおまかにいって「プログラミングが出来る」というのはこの3個のスキルに分割できるのではないかと思っている。そして、これらはそれぞれあまり関係がない。
という人達がいると思う。「プログラミングが出来ない」という問題は
こういうパターンが考えられる(もちろんこれで全部ではない)。それぞれ必要な訓練は全く別なのだが、これを全部「技術をより深く知ること」で解決できるような気がしてしまうがそれは間違っている。
実際のところ「技術をより深く知ること」により転職がある程度楽になり、転職することで金と時間と気持ちの余裕が手に入りやすくなり、それによりあらゆる問題の解決は楽になる可能性があるのだけど、それが最短のパスである可能性は実はそんなにない。
「プログラミングが出来ない」というのは解決すべき問題としてはあまりにも曖昧すぎるので、自分や周囲の状況を観察してこれを細かいタスクに割っていくことが解決の一助になるし、またそういう課題の捜索と分析という作業を繰り返し行なうことでプログラミングが出来るようになる。
捜査関係事項照会の実務について俺が見てきたこと
俺はどういう人間か: 法律関係のことはあまり知らない(弁護士とキャバクラの値段が同じということぐらいは知っている)。ネトゲや Web サービスの開発を 10 年以上やっている。大量の個人情報を取り扱い金銭化するようなサービスの開発、運営に従事したことはない。高等教育の類いはいっさいうけていない。
警察の捜査関係事項照会について、俺がこれまで見てきた会社ではだいたい管理部門かカスタマーサポート部門が対応していた。法務兼 CS みたいな人もみたことがある。俺がみたものだと、 URL やスクリーンショットをそえて、この投稿者の IP アドレスやホスト名をよこせみたいなかんじであることが多かった。だいたいそれを見れば警察がどういう捜査をしているのかは分かることが多かった。あきらかに不当な照会だなと感じられるものはこれまで見たことがない。
捜査関係事項照会について「お答えできません」という類の回答をするとハイ分かりましたということで終わりになる。その後令状をもってやってくる場合もあるが、なにもないこともある。令状をもってやってきても、ハードウェアとかアカウントとかを取り抑えられるという対処になったのは見たことがない。令状をもってやってきて、規定によりログが残ってませんとなると「なんとか探してもらえないか」ということになるが、それ以上何かという話でもない。
捜査関係事項照会をスルーしている現場をみたことがあるが、そのあとどうなったのかよくは知らない。すくなくともそこの会社の人が令状をもった捜査員とやり取りしているという場面を見てはいない。
国税局から調査関係事項照会書というのがきたことがある。この場合所属していた会社では照会に応じる対処をとったので、国税のをハネた場合に強制調査になるのかとか、その場合の実際の作業はどうなるのかとかは俺は知らない。国税の態度はずいぶん警察より酷いものだと感じた。
捜査関係事項照会に応じるかどうかは本当に企業によって違っていた。このあたり明確なポリシーをもっていると感じられる組織は見たことがない。俺が働いている、働いていたことのある会社ではないが、 LINE は明確なポリシーをもってレポートを公表している珍しい企業だ。ここまでやっている現場を自分でみたことはない。公平性のために言っておくが、俺には LINE 従業員の友人がおそらく 20 名以上存在しているし、 LINE がこのようなレポートを出していることも従業員から聞いて知った。
実務的な話でいうと、 CS 部門、管理部門的には対応工数の最小化に目がいきがちだと思う。これは俺がみてきたことではなく、単なる意見だがこのあたりの対処方針がブランディングに関わるというのが現代では明らかになっているので、広報やマーケティング部門を巻き込んだ対処が必要になってくるのかもしれない。
おそらく実際に捜査関係事項照会で一番おおく行なわれているのは犯罪発生現場近傍の防犯カメラの映像の提供依頼なのだと思うがそのあたりの実務についても俺は何も知らない。個人の位置情報を保存するサービスを運営したこともないのでそういうことを捜査関係事項照会で聞いてくることがあるのかも知らない。俺が警察官なら、被疑者や被害者の名前と電話番号をもとに CCC に「この人どっかの店舗で T カード使用した記録とか出せる?」みたいなことを聞きたくなるよな気がするが、それも想像だ、何も知らない。 CCC の持っている情報はわりと野放図に検索可能であることを知っているが、実際の運用について詳細を知らない。またこれを何故知っているかは言えない(NDA はない)。
警察官や査察官も含めて皆が個人的に知っていることはそれぞれ限定的だ。こういうことについて知っていることを書く人が一人でも多ければいいと思う。
material-ui でカレンダーな UI を作る
こんにちは、金をよこせ死ね。こういう素晴しい書き出しでアメブロを書いている異常者がいたんですがとっくの昔に消えました。アプリ開発をやっているとカレンダーっぽい UI が必要になることはそれなりにあるかと思います。従来 Web だとそういうの非常にだるかったものですが、 material-ui という React Component 集だとそれが簡単にできます。
material-ui 。それにしても酷い名前ですね、何様のつもりなのか。 material-ui にはいわゆる Grid システムをやっていくための Grid という機能があるのですが、それとは別に GridList というコンポーネントをもっています。これはデモをみると
みたいな感じであきらかに汎用的なレイアウトを作ることは想定していないと思うのですが、実際 UI のレイアウトをこれで組むと話が早い。
こんな感じのカレンダーが以下のようなコードで実現できます。
const uuid = require('uuid');
const weekdays = ['Sun.', 'Mon.', 'Tue.', 'Wed.', 'Thu.', 'Fri.', 'Sat.'];
const cardStyle = { margin: 1 }
const Calendar = (props)=>{
const begining = new Date(2019, 0, 1);
const calendar = []
Array.apply(null, {length: begining.getDay()}).map(Number.call, Number).forEach((e)=>{
calendar.push(<GridListTile key={uuid()}><Card /></GridListTile>);
});
Array.apply(null, {length: 32}).map(Number.call, Number).forEach((i)=>{
const day = new Date(begining.getFullYear(), begining.getMonth(), 1+i);
if(day.getMonth() === begining.getMonth()){
calendar.push(
<GridListTile>
<Card style={cardStyle}><CardContent><Typography>{day.toLocaleDateString()}</Typography></CardContent></Card>
</GridListTile>
);
}
});
return <Paper>
<GridList cols={7} cellHeight='auto'>
{
weekdays.map((w)=>{
const styles = {};
if(w == 'Sun.'){styles.color = 'red'}
if(w == 'Sat.'){styles.color = 'blue'}
return <GridListTile key={w}>
<Card style={cardStyle}>
<CardContent><Typography style={styles}>{w}</Typography></CardContent>
</Card>
</GridListTile>
})
}
{calendar}
</GridList>
</Paper>
}
記述短くしようとしたらかえって分かりづらくなった気しますね。まあいいや。なんかそれっぽい感じでいろいろ一瞬で書けるので material-ui いいと思う。名前が酷いが、、、
2018 年買ったもののうちゴミまとめ みたいな記事書こうとして買ったものをまとめていたが、一切ゴミを買っていない、反省している。 2019 年はどんどんゴミを買っていきたい。
中国製のとあるキットをかったんですが まあそれがなにかは今は言えないのだが、とにかくこれがすごい。あらゆるコネクタが色や形を適切に分けてあって、どうやったって絶対に間違えて接続することがないように出来ている。
最初キットにろくなマニュアルがなくて「ハァ?」ってなったんだけどこれならたしかにマニュアルはいらない。どんな低能でも組み立てることができる。このジャンルの商品で日米独のものをこれまで触ってきたんだけど、こんなに組み立ての UX が練られているのははじめてみた。
中国の外観デザインというのは 2018 年になっても正直かなりダメな水準だとは思うのだが、こういう UX というか Developer Experience というかそういう分野はすごく進歩している、などと思って中国人に話をしたら俺が買ったメーカーだけがすごいとのことでした。
マネージャーという役割で仕事をしているだけで偉い人ではないです みたいの誠実ではないと思っていて、実際偉いし権威は与えられてるわけでしょう。採用したり、解雇できたり、給与を決定できたり(あるいはそれらの判断に参与できる)するし、大抵給料も高い。
「権威に見合うだけのスキルがあり、組織やプレイヤー個人のキャリアに貢献できるので信用してください」と言い切ればいいし、言い切れないなら別の職が向いているのでは、と思うんだけどそう言い切られると反発する人が多いからこうなってんだろうなあ。
一瞬でつくる家中本
着地点としては
そういうわけで pic.twitter.com/URqbuVYOv1
— 小池 陸@ハイチ垢 (@ssig33) December 16, 2018
こう。これがわりとすぐに出来ます。中本といえば
で構成されています。麻婆豆腐については各自のレシピで作ればよいでしょう。私の麻婆豆腐は炒めた挽き肉に豆板醤を加え、創味シャンタンを溶いた酒を入れ、豆腐を入れ、酒がとんだらとろみをつけたというだけのものです。これが麻婆豆腐かどうかは議論の余地があります。普段は食う直前に大量の花椒を入れるので一応麻婆豆腐の定義は満たしている気がしています。
で、味噌スープをどうするかというのが問題で、これがまあ普通にやると面倒なのですが、業務用食材でショートカットしていきましょう。
というものがあります。これは非常によいものです。使い方としては水か中華スープで 10 倍希釈せよとありますが、 50ml のピリ辛スープに 300ml ぐらいの創味シャンタン汁をまぜるのがよいと思います。
辛い野菜についてもこやつにまかせましょう。適当に野菜にこれをまぜながら炒めるとよいでしょう。今回野菜をスーパーにあった「ラーメン用野菜」という適当なカット野菜をつかったので構成要素があまり中本と一致していませんが、まあこれでも味としてはだいぶ中本です。
麺もスーパーにあった適当なやつを使いましたが、もともと麺にそんなに特徴があるタイプのラーメンではないのでそんなんでも十分だと思います。
とにかくこのピリ辛スープはすごく、これを使うだけで 20 分もかからずに家で中本を作れて便利です。一番会社から近い中本新宿店の店長が女にしか話しかけないのが見ていると本当に辛くて、でも中本のラーメンは好きだったのでだいたい同じようなものを家で作れるようになってまりあとってもとってもうれしいです。
デスクトップ Linux を 15 年ぐらい使っている のだが、あまりこの 15 年困ることはなかったと思う。
Vine Linux 2.6 あたりから常用する環境が Linux だったので、だいたい 15 年ぐらいそんなふうであると思う。 GUI にかんしてはいろいろとフラフラした結果、 2005 年ごろから JWM というのを使っていたが、最近いろいろめんどうになって LXDE に引っ越してしまった。
今日常的に起動している GUI なツールは Chrome と Franz と LXTerminal と Steam だけで、まあこれなら OS なんてなんでもいい。昔は Emacs でメールと原稿を読み書きしていた記憶があるのと Skype が必須の時代とかもありましたね。
別段 Linux だから辛いみたいなことはそんなに無かったような気するけど、記録をみると sid 常用してた時代とか 2-3 ヶ月に 1 回ぐらいインストールしなおしとかしてたから、もはや単に記憶が薄れただけかもしれない。
辛いことがすくなかったのは、なんでも Linux でやろうみたいな気持ちがなかったせいかもしれない。ゲームは普通に Windows でやっていた。
やはり革命的だったと思うのは Docker の登場で、これのおかげで「新しい MySQL を使うために sid を使う」「複数バージョンのあれこれを共存させるためにやったものがゴミになって共存させなくなったあと苦しむ」とかが起きなくなった。こういう経験があったので、 Docker とは非常に富豪的なパッケージマネージャーなのだみたいな認識がまずある。
そして なんでも Docker を介して行なわれるようになってきた現代は常用環境が Linux というだけで苦労が減る。
そして Steam Play はかなり革命的な存在で、ゲームもだいたい Linux でやるようになった。
Windows や Mac と比べてこれが使いやすいのかどうかはよく分からない。四六時中 Web アプリを作っている俺にはこれが使いやすいが、非開発者だと Chrome だけ動けばいい時代なんだから ChromeOS のほうがいいんじゃないとか思います。
Linux ずっと使ってるけど「Linux 使ってる、他の環境はクソ」みたいなことを大声でインターネットで叫んでる人みると本当に辛い気持ちになる、これがなぜそうなるのかは自分でもよく分からない。
Cloudflare Workers 試してみた
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
if(request.headers.has("X-Testing")){
return new Response("Hello Peaceful Shit World!")
} else {
const response = await fetch(request);
return response;
}
}
みたいなクソワーカーをデプロイすると以下のようになる
まあこの例はともかくとして Fastly だと VCL でゴチャゴチャ書いてた部分を JavaScript でゴチャゴチャ書けるようになるのはいいですね。契約形態的にも Fastly よりクイックスタートできるのでよい。
この層でゴチャゴチャしたものを書くべきではないという話はあるんですが、この層でこういうことをやらねばならない人達はいて、そしてそれは私のことです。
dep から vgo に移行した
$ go mod init
$ go build
とするだけで dep から移行できたので楽でよかった、楽でよかったんだけど dep でいいじゃん感は強いし異常者の異常な思いつきを移行ツールなどで必死にカバーしているという印象は強い。
「ライブラリ作者が URL ベースで互換性を維持しつづければ複雑なベンダリングツールも中央集権ライブラリリポジトリもいらない」という初期の発想が間違っていたことを認めて gogems をはやく作ってほしいですね。
最近めっちゃ運用安定してる
ママチャリ問題
ママチャリで画像検索するとこう
ママチャリ 電動 だとこう
ここで問題となるのが、電動のほうででてくるこれが「ママチャリ」という共通認識を得られているのか?ということです。このタイプの小径、低重心、長ホイールベースの自転車、今東京の子育て世代の多くの人が乗っていて、東京では本当にこれを頻繁に見ます。しかし東京以外の都市でこれが氾濫している印象はありません。
ではメーカーがこれを何と呼んでいるかについてですが、
パナソニックは「子乗せ」です。
ママチャリという用語は性やその役割についての現代の認識からするとアナクロであるので使っていないのかなとも思いますが「ママ」ともありまあママが使うこと前提でいろいろ謎です。単に「これはママチャリではないよな」と思っただけかもしれない。
ブリジストンは「子ども乗せ 電動アシスト自転車」です。
ブリジストンはあきらかに男女平等に配慮しています。
ヤマハは「ファミリーモデル」です。
などの様々な理由があり「これがいったい何であるのか」という共通の理解が発生していないと僕は考えています。みなさんはこれが何だと思いますか。
Docker を用いてソフトウェアをデプロイするとソフトウェアの品質が上がる
http://b.hatena.ne.jp/entry/bonotake.hatenablog.com/entry/2018/09/06/072800 ここをながめていて思ったことなんですが。
Docker はデプロイにのみ関連するツールであって、ソフトウェア開発の本質には一切関係ないものだ、という考えの人をたまに、いや、よく見る。これは全く間違っていて、 Docker を用いて継続的にソフトウェアをデプロイしているだけでソフトウェアの品質は上がります。ソフトウェアの品質のような問題について考えている人は Docker とそのメンタルモデルに興味をもつべきです。
本来こうした問題について僕がなにかを言う必要はなくて The Twelve-Factor App という文章を読めば十分です。あるいは 大切なことはだいたいHerokuで学んだ というこの文章も非常に有用だと思います。いやこれ Heroku の話じゃんとか思わないでください。 Docker はもともと Heroku クローンである dotCloud の実行エンジンとして開発されたものであり、 Heroku は Docker とそのエコシステムが目指すもの、そして乗り越えるべきものだったのです(部分的には乗り越えていますが、 Heroku は未だに有力なプラットフォームです)。
ところで Docker を使っているだけで何故ソフトウェアの品質が上がるかということを簡潔にまとめたものを改めて書いておくのは悪いことではないと思ったので書いておきます。
ほかにもいろいろあるとは思いますが、すぐに思いつくこととしてはこんな感じですかね。
ここ数年いろんな勉強会でずっとテストの実行に関する話をしてきて 分かったことがあって、やはり多くのソフトウェアエンジニアはテストに興味をもっていない。コストとしか意識していないのだろう。ただし少数のエンジニアが熱烈にこの分野に関心を持っているということもよく分かった。
あんまり健全じゃないよね、これ。
CircleCI あんま好きじゃない
Firebase でバックエンドエンジニアがいらなくなるは正しくない と思っている。
用語定義が曖昧だが、「バックエンドエンジニア」という言葉でなんとなく想像されるものとしては、 Rails とか Laravel とかでデータベースに CRUD する Web アプリケーションを書ける人を指すと思う。違いますかね。そんなに違ってないと思うが。
Firebase でこれらの知識をもつ人が不要か?というとある程度の規模、機能を持つアプリを作ろうと思うとこれは必須になる。 Firebase のデータベースは機能が少なく(とはいえ Firestore はわりと「これで十分じゃん」ではあるが)、なにか複雑なことをしようとすると、すぐに Cloud Functions という機能に頼ることになる。
Cloud Functions はようするに Firebase の Lambda + API Gateway で、 Firestore になにかが保存されたことをトリガーにして「サーバーレス」のコードが起動される。
典型的にこのトリガーを使うのは以下二つの用途であろうと思う
そして Cloud Functions には API Gateway 的な機能が高度に統合されており、 AWS でやるよりも簡単にサーバーレスな API を作成、デプロイすることができる。
典型的にはこれは以下のような用途で使用されると思う
こうした API を作成するのに必要な知識は、
などであって、極普通にバックエンドエンジニアの知識であろうと思う。
Firebase で本当に不要になるのは「インフラエンジニア」だが、これも実際にアプリが大きくなってくるとどうなるか分かない。すなわち
といったタスクが出てくることは明らかで、これを解決できるのは、その人がその会社でどのように呼ばれていようと「インフラエンジニア」であろうと思う。
しかし、 Firebase を使う場合でもこうした人達が必要で、結局 Firebase を使う意味はなく、従来のとおりのアプリ開発が結局優位性を持つのか、というとそうではないと思う。
といった事情で極めて強力、2018 年に 1 からアプリを作る場合最も有力な選択肢の一つだと思う。
ghq で clone したものを peco で検索したあと cd して tmux を開く というようなことをコマンド一発でいけるようにした。
前提となる環境としてはghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blogあたり見てほしい。
結論からいうと以下のようにした。
alias opentmux='tmux -2 new-session -s $(pwd | awk -F "/" '"'"'{ print $NF }'"'"') || tmux -2 a -t $(pwd | awk -F "/" '"'"'{ print $NF }'"'"')'
alias gcd='cd "$(ghq list --full-path | peco)" ; opentmux'
を登録しました。ぼくは以前から tmux でとにかくぐちゃぐちゃにセッションを作ってしまい、同じディレクトリを開いているセッションが大量に作られたりして破滅していたのだけど、これでかなり便利になった。
ConoHa 捨てる作業完了した
Lightsail 安くなって ConoHa を捨てる決心がついた
2ノードだと落ちるときは落ちるな