Diary

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

こう。これがわりとすぐに出来ます。中本といえば

1. ピリ辛味噌スープ
2. 辛めの野菜
3. 麻婆豆腐

で構成されています。麻婆豆腐については各自のレシピで作ればよいでしょう。私の麻婆豆腐は炒めた挽き肉に豆板醤を加え、創味シャンタンを溶いた酒を入れ、豆腐を入れ、酒がとんだらとろみをつけたというだけのものです。これが麻婆豆腐かどうかは議論の余地があります。普段は食う直前に大量の花椒を入れるので一応麻婆豆腐の定義は満たしている気がしています。

で、味噌スープをどうするかというのが問題で、これがまあ普通にやると面倒なのですが、業務用食材でショートカットしていきましょう。

あみ印 ピリ辛スープ 1L

というものがあります。これは非常によいものです。使い方としては水か中華スープで 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 をはやく作ってほしいですね。

最近めっちゃ運用安定してる

ママチャリ問題

ママチャリで画像検索するとこう

ママチャリ 電動 だとこう

ここで問題となるのが、電動のほうででてくるこれが「ママチャリ」という共通認識を得られているのか？ということです。このタイプの小径、低重心、長ホイールベースの自転車、今東京の子育て世代の多くの人が乗っていて、東京では本当にこれを頻繁に見ます。しかし東京以外の都市でこれが氾濫している印象はありません。

ではメーカーがこれを何と呼んでいるかについてですが、

パナソニックは「子乗せ」です。

ママチャリという用語は性やその役割についての現代の認識からするとアナクロであるので使っていないのかなとも思いますが「ママ」ともありまあママが使うこと前提でいろいろ謎です。単に「これはママチャリではないよな」と思っただけかもしれない。

ブリジストンは「子ども乗せ 電動アシスト自転車」です。

ブリジストンはあきらかに男女平等に配慮しています。

ヤマハは「ファミリーモデル」です。

• 「ママチャリ」という用語自体がもともとメーカーや公共団体が使う正式の用語ではなかったこと
  • 「軽快車」のような言葉が使われている
• 「ママチャリ」という用語が現代の性の問題においていささか不適切であること
  • パナはこのあたり無頓着のようにみえますが、、、
• 東京周辺でしか本格的に普及していないこと
  • 坂が多く道路環境も比較的過酷、かつ都市が無秩序に広がっており長距離移動を求められるにも関わらず駐車場が不足という東京の環境に高度に最適化している
  • 値段が 15 万円前後と高価であり地方の所得からすると手が出づらい
• 根本的な問題として日本語およびその文化においてある概念に名前をつけて把握しようという考え方が薄い

などの様々な理由があり「これがいったい何であるのか」という共通の理解が発生していないと僕は考えています。みなさんはこれが何だと思いますか。

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 を使っているだけで何故ソフトウェアの品質が上がるかということを簡潔にまとめたものを改めて書いておくのは悪いことではないと思ったので書いておきます。

• サーバーのファイルシステムなどの「状態」に依存することが出来ないので、ソフトウェアの可用性が上がる
  • よりスケーラブルになる
  • メンテナンス性が上昇する
• 本番環境、検証環境、 CI 環境、開発環境などで同じコード、同じ環境を使用することが出来るので、不具合が早期に発見される
• ログの集約が簡単なので、不具合の発見がはかどる
• いざとなれば簡単にロールバックできるという環境では、大胆な変更も許容されるから、最終的に得られる品質は高くなる

ほかにもいろいろあるとは思いますが、すぐに思いつくこととしてはこんな感じですかね。

ここ数年いろんな勉強会でずっとテストの実行に関する話をしてきて 分かったことがあって、やはり多くのソフトウェアエンジニアはテストに興味をもっていない。コストとしか意識していないのだろう。ただし少数のエンジニアが熱烈にこの分野に関心を持っているということもよく分かった。

あんまり健全じゃないよね、これ。

ゴリラ

ねむい

CircleCI あんま好きじゃない

Firebase でバックエンドエンジニアがいらなくなるは正しくない と思っている。

用語定義が曖昧だが、「バックエンドエンジニア」という言葉でなんとなく想像されるものとしては、 Rails とか Laravel とかでデータベースに CRUD する Web アプリケーションを書ける人を指すと思う。違いますかね。そんなに違ってないと思うが。

Firebase でこれらの知識をもつ人が不要か?というとある程度の規模、機能を持つアプリを作ろうと思うとこれは必須になる。 Firebase のデータベースは機能が少なく(とはいえ Firestore はわりと「これで十分じゃん」ではあるが)、なにか複雑なことをしようとすると、すぐに Cloud Functions という機能に頼ることになる。

Cloud Functions はようするに Firebase の Lambda + API Gateway で、 Firestore になにかが保存されたことをトリガーにして「サーバーレス」のコードが起動される。

典型的にこのトリガーを使うのは以下二つの用途であろうと思う

• 全文検索
  • Firebase に全文検索が実装されていないので外部の全文検索エンジンを使う必要がある
  • 2018 年現在、 Algolia というサービスを使うように推奨されている
    • Firebase の話をあんまり関係ないがこの Algolia は出来がよく大変に便利、 Firebase を使わない人も検討の価値あり
• BigQuery
  • 集計クエリとかは BigQuery に吐いてもらう必要があるだろう、 Firestore への保存をトリガーに BigQuery にコピーするコードを書くのは簡単

そして Cloud Functions には API Gateway 的な機能が高度に統合されており、 AWS でやるよりも簡単にサーバーレスな API を作成、デプロイすることができる。

典型的にはこれは以下のような用途で使用されると思う

• 全文検索
  • Algolia で検索行なうときにアプリの設計次第では適切に権限が制限されたアクセストークンを発行する必要があるが、これをクライアントサイドで行なうことは原理的に不可能なのでサーバーサイドで行なう
• BigQuery
  • BigQuery に実際に SQL を投げて結果を返す API はサーバーサイドに作るほうが何かと楽だし、適切にクオータなどもかけられる
• 認証
  • Firebase が公式に認証フローを用意していないサービスでも Cloud Functions などを使ってサーバサイドを実装すれば Firebase へのログインに利用可能、これについては前に書いた
• 決済
  • Firestore への保存をトリガーに決済を行なう形式は危険、なぜならトリガーは「確実に一回実行されること」が保証されない。複数回走る可能性がある。

こうした API を作成するのに必要な知識は、

• node.js で普通に Web アプリを作る知識
• HTTP ヘッダーを使って認証をする現代で普通のやり方

などであって、極普通にバックエンドエンジニアの知識であろうと思う。

Firebase で本当に不要になるのは「インフラエンジニア」だが、これも実際にアプリが大きくなってくるとどうなるか分かない。すなわち

• CI/CD 環境の整備
• 各種デプロイ、データアクセスの権限の整備
• Cloud Firestore などのデータベースの運用
• Cloud Functions 経由で MySQL などを利用する場合はそれらの整備

といったタスクが出てくることは明らかで、これを解決できるのは、その人がその会社でどのように呼ばれていようと「インフラエンジニア」であろうと思う。

しかし、 Firebase を使う場合でもこうした人達が必要で、結局 Firebase を使う意味はなく、従来のとおりのアプリ開発が結局優位性を持つのか、というとそうではないと思う。

• 多くのことをバックエンドエンジニアとインフラエンジニアに頼らず出来る
  • 彼等は不要にならないが、少なくはできる
• Realtime Database によるデバイス間同期は極めて強力

といった事情で極めて強力、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'

1. ディレクトリ名で tmux のセッションを作ろうとして、失敗したらその名前のセッションをアタッチするという alias
2. ghq で検索して cd したあと ↑ を叩くという alias

を登録しました。ぼくは以前から tmux でとにかくぐちゃぐちゃにセッションを作ってしまい、同じディレクトリを開いているセッションが大量に作られたりして破滅していたのだけど、これでかなり便利になった。

ConoHa 捨てる作業完了した

Lightsail 安くなって ConoHa を捨てる決心がついた

2ノードだと落ちるときは落ちるな

えび

多摩のビル火災が AWS の予定地だったことを報じる必要はないとか言ってる人たちに言いたいことなんですけど

Amazon が普段通販サイト Amazon への納入業者を買いたたく感覚で建設業者を買いたたいた結果無理な工程で安藤ハザマのようなダメ会社に発注することになって、安全管理がずさんになってこの大事故につながったみたいな可能性結構あると思うんですよ。

IT で無理してもせいぜいが精神壊す人がでるぐらいだけど建設で無理すればこういうことになるし、今回はまあ死んだの作業員だけだけど周辺住民にだって被害が出た可能性もある。 Amazon に発注者としてこの事故に責任があるかどうかとか検証し報じる価値のあることだし、第一報でとりあえず「発注者は Amazon らしい」と報じることに意味はある。

自分たちの身の回りの狭い常識だけで話すんなよ、死者出てるんだし。

転送量課金で滅んだ

かに

ここは Heroku に戻した

CDN でごまかしつつバックエンドは GKE のヘボいサーバー みたいな構成に急速に移行している。

ラーメン

ねむい

バックエンドを Heroku から GKE に切り替えてみた