Diary

@ssig33

かに

24 Oct 2019 Thu 16:14

Windows が生成する EFI System Partition (ESP) を拡張する ということをしたくなることがあるかと思います。具体的には

  1. Windows が入ってたところにマルチブートで Linux 入れたい
  2. Windows が生成した ESP を boot として使いまわしたい
  3. しかし Windows が生成した ESP は 100MB しかないのでカーネルが複数入らない
  • Linux 用に ESP 別途生成すればいいんですかね? ESP mutiple とかで検索しても「ESP を複数作る必要はない、使い回せ」みたいなことばっか書かれていて辛い

というような状況。

という Q&A を読むと、 MiniTool Partition Wizard Free を使うとよいであろう、とあります。これで実際に希望の要件を達成することができましたが、若干面倒な操作が必要でした。

Windows を何も考えずにインストールすると

  • ESP :100MB
  • Microsoft Reserved (MSR): 16MB
  • C:

の 3 個が生成されることが知られています。で、この MSR がなんなのか俺は知らないし知ろうとも思っていないのだがとにかく消してはいかんらしい。

MiniTool Partition Wizard Free では C: を縮小して後ろにつめることもできますし、 ESP を拡張することもできるのですが、 MSR を処理することは一見できないように見えます。

そこで Google に聞くと

What you can do is to Copy the MSR partition to an unallocated space block

とあるので信じます。すなわち MiniTool Partition Wizard Free 上で

  1. C: を縮小して後ろにずらす
  2. MSR を後ろにコピーする形でずらす
  3. もとの MSR を削除する;
  4. ESP を空いた部分に拡張する

という操作を予約し、適用します。すると期待どおりに ESP が拡張されますし、 MSR をこのように移動させても Windows の挙動に問題はないようです。ようですと書いたのはこの操作をしてからまだ 10 時間程度しか経過していないために副作用があるかどうかを知らないからです。

とにかくこれで Windows が生成した ESP を拡張して /boot に沢山のカーネルを入れることができて便利になりました、よかったですね。

19 Sep 2019 Thu 14:00

CircleCI (Performance Plan) vs. Github Actions

結論: CircleCI を買おう

現在ユビレジでは CI は CircleCI (Performance Plan)と TravisCI を使っていて、

  • CircleCI:
    • サーバーサイド(いろんな言語がある)
    • Web フロントエンド(Rails アプリのなかで webpack が動いていたり、 create-react-app で作られたペラっとしたものがあったりいろいろある)
  • TravisCI:
    • iOS アプリ

というような感じで使い分けている。 Performance Plan なんだから iOS のも Travis から引っ越せばいいんじゃねえの?と思わんでもないのだが、

  • Travis の annual 課金がまだ残ってる
  • iOS の CI と TravisCI と CircleCI に全部詳しいかつやる気がある人はいない

という事情があり、このようになっている。

ここで CircleCI の Performance Plan について簡単に説明すると

  • 課金体系は従量課金
    • 使ってる人数*月15ドルの固定課金
    • 使ったインスタンスの時間あたりの課金
  • 並列数は無制限
    • 昔は UI 上 200 並列が上限であるように見えてたけど実際どうなのかは不明。この表示自体はシステムを従来プランと使い回していた故のように思える
    • 200 並列にまだ頭ぶつけたことないので実際どうなのかは知らない、気になる人は営業に問い合わせてみましょう
  • 開始時に営業に問い合わせが必要
    • 日本ブランチはあるので日本語でやり取り可能です

といった特徴があります。簡単に言うと安くて便利。というわけで CircleCI Performance Plan でテストを回していたプロダクトの一つで Github Actions を使ってみることにしました。

Github Actions はだいたい以下のような特徴があります

  • リポジトリごとに 20 並列までいける
  • OSS なら無料、 Private は 11 月から有料化
    • プランはまだ未発表
  • 裏側には Azure Pipelines というものが使われている

今回何故か Beta 開始日から我々の組織では Actions (CI)を使うことができたので、今回僕が面倒(?)をみているプロダクトの一つで Github Actions を使用してみました。 create-react-app で開始した SPA で(現在では eject 済み)、純粋に Web フロントエンドだけが存在しているリポジトリです。テストは全て E2E テストで、 jest-puppeteer を使っています。あんまり関係ない話ですがどうも Web フロントエンド界隈ではコンポーネントのユニットテストと型でアプリを守るという思想が流行っているようですが、これらは全て無意味だと僕は思っています。型は VSCode の補完で便利という程度に捉えておくほうがよいと思う。ユニットテストはクソ。

リポジトリごとに 20 並列という制限は、大規模なモノリスがあり多くの従業員がそこで作業をしているという場合簡単に頭をぶつけることになるでしょう。ただし今回僕が Actions を仮投入してみたプロダクトは開発者が 3 名しかいないプロダクトでしたのでそこが問題になることはありませんでした。

プランについては発表しようにも評価のしようがありません。

裏側である Azure Pipelines というか CI の実行部分については、これはもう悲惨としか言いようがない水準です。

今回 CircleCI と平行するかたちで Github Actions の利用をはじめ、落ち着いてきたら Actions のほうだけに統一みたいなつもりでいたのですが、一向に落ち着くことはなかったので 8/13 に使用しはじめた Github Actions ですが 9/4 で使用を中止し CircleCI だけに戻しました。

あまりにもサービスの品質に問題を感じるため、周囲のエンジニアにインタビューをとってみましたが、 Azure Pipelines 自体が悲惨な品質で、リリース以来あまり改善されてこなかったという話をいくつか聞くことができました。

なお、今回のプロダクトでは CI で実行するあれこれの処理を Makefile に記述し、 CI の設定ファイル内では make hogehoge みたいのだけを書くようにしていたこともあり、 Github Actions の利用開始自体は 30 分もかからずに行なうことができました。このあたり一切面倒なところはありません。

全体として、 Github Actions は非常にストレスフルなプロダクトで、仕事としてやっているプロダクトで金銭的な出費が許される場合には CircleCI の Performance プランを使用することを強くオススメします。11 月に発表される料金がかなり安かったとしてもそれはそうで、出費を節約した結果 CI の不可解な挙動でエンジニアの生産性が落ちるようでは話になりません。

Azure Pipelines の改善が進まなかったことには、そもそもサービスのユーザーが多くなくメトリクスなりユーザーの意見なりを十分に収集できていなかったという可能性はあります。今後 Actions 経由でこれを利用する開発者が増えれば改善されていく可能性はあります。ただし、僕はこれまで Azure のマネージドサービスについて多くの場合において品質面での問題を感じていました。今回だけまともになることあるかなあ、、、

来年の夏ぐらいにまた検証してみたい。

17 Sep 2019 Tue 14:01

待遇にも文句ないしプロダクトにも愛着は強いんだけど 環境への飽きみたいのが出てきていて、これはまあどうしようもないねえ。

20 Aug 2019 Tue 12:01

最近同人誌即売会いっても 机全部みればいいじゃんみたいな感じで事前にカタログみたりしなくなっちゃって。なんかでも机全部みるのってそれはそれで見落しありそうということでティアズマガジンちゃんと見てみることにした。

20 Aug 2019 Tue 12:00

ここのバックエンド Cloud Run にしたらほとんど運用費タダになった。 そこそこアクセスあったからどうなんだろとか思ってたけど Fastly がほぼ全部吸ってくれるから最高。

07 Jul 2019 Sun 01:27

だるい

05 Jul 2019 Fri 18:56

はい

05 Jul 2019 Fri 18:56

Host ヘッダー上書きしたらアプリの動作おかしくなった けどまあなんとかなるだろう。

05 Jul 2019 Fri 18:29

ここのバックエンド Cloud Run にした

ここはもともと Cloudflare (HTTPS化) => Fastly (キャッシュ) => GKE というかんじで動いていて、 GKE の部分を Cloud Run に差し替えた。

Fastly から Cloud Run を使うには、 Fastly に Host ヘッダーを上書きしてもらえばいい。そのものズバリな説明があって最高便利、よかったですね、 Fastly 最高、金払ってないけど。

05 Jul 2019 Fri 18:28

React で Android 向けとそれ以外でインタラクションを分ける

コンセプトとしては

const Android = ({children})=>(
  isAndroid() ? children : null
)

const NotAndroid = ({children})=>{
  isAndroid() ? null : children
}

というようなコンポーネントを用意しておいて

<Android>
  <アニメーションとか使わない地味なインタラクション>
    <HogeFuga>
      <Nanika />
    </HogeFuga>
  </アニメーションとか使わない地味なインタラクション>
</Android>

<NotAndroid>
  <豪華なインタラクション>
    <HogeFuga>
      <Nanika />
    </HogeFuga>
  </豪華なインタラクション>
</NotAndroid>

とかこんなん。まあ Android と NotAndroid の中身は適当に想像してください。

なんでこんなことをしたいかというと、

  • iOS 端末については年々 GPU が進歩している
  • Windows についても Intel の IGP すらわりと進歩している
  • 一方で Android 低価格機の GPU はショボいまま

という問題があるので。 Windows 環境でも若干そういう傾向はあるが、特に Android 機において低価格機の GPU は「表示できれば十分でしょ」から進歩しない。なんでこんなことになってんだと思うけど、もうそういうものとして考えていくしかないと思う。

とすると、 Android にだけアニメーションとかを適用しないショボいバージョンを見せる、という選択肢がでてくると思う。 React を使っている場合、しっかりコンポーネントを設計していれば、↑のような感じでそれなりによろしく書いていったりできるんじゃないかな、、、という考え。

実際に現時点でこんなことを実務でやっているわけではないです。今は全体にたいしてなるべくアニメーションとか使わないようなものを出していこうという方針でものを作っています。

ただ、エフェクトの有無が UX に影響するみたいなことが分かってきたら、なるべく多くの環境向けにエフェクトを出そうとかなると思うし、そうなると↑みたいな対処になるのかなーとか。

みんなこういうのどうしてるんだろう。

https://scrapbox.io/shokai/CSS%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B7%E3%83%96%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%82%92SPA%E3%81%A7%E4%BD%BF%E3%81%86%E3%81%A8%E7%A0%B4%E6%BB%85%E3%81%99%E3%82%8B からインスパイアされてこんなことを考えています。

22 May 2019 Wed 16:45

ここの裏側 Go から ruby にもどした

16 May 2019 Thu 17:55

仕事と給与と評価の関係

(1) 仕事の成果を適切に評価することは困難です

営業なら売り上げだろ?違います。売り上げまくってるけど CS 部門に迷惑かける客ばかりつれてくる人とかいますよね。 CRM 使えばそういう人を適切に評価することができるかもしれませんが、大抵おとぎ話でしょう。

(2) 給与ははっきりいって適当に決まります、運です

評価制度やグレード制度が決まってる場合でも結局その運用は最終的には人手なので、、、

(3) 「会社の利益を意識せよ」と言ってくる経営者を信用してはいけない

そういうことはスタッフグレードの人が考えるのであって、現場はそんなことを考えないといけないのであれば組織が成り立ってない。「会社の利益を意識する」というのは「情報の収集と評価」とより抽象化できるが、それは非常に高度で専門的なミッションであって、そんなことを片手間にやると業務執行の質がガタ落ちします。下級管理職やワーカーが利益につながる仕事をできるようにするのが上の人の仕事。

(4) どこかでダメでも別のところでならいける可能性がある

給料上がんなかったら異動願いか転職かしてみましょう

(5) とはいえどこいってもダメみたいな場合もあるかもしれない

まあ、人生いろいろある

24 Apr 2019 Wed 17:52

かに

12 Apr 2019 Fri 12:15

ここの実行環境 Cloud Run にしてみた

わりと気軽でいいですね

12 Apr 2019 Fri 08:57

谷甲州 『硫黄島航空戦線』

https://www.amazon.co.jp/dp/4125013993/

この記事を先に読んでいただければと思います。

先生の病状は明らかにさらに悪化しておられます。展開は常に意味不明で物事の前後関係は判然とせず、登場人物の人格は常に混沌としています。設定には多くの不整合があり、とても以前の谷先生の作品とは比べられるものではありません。

さらに読んでいて辛くなるのが、おそらく谷先生自身そうした自身の頭脳に迫りくる問題を、認識する瞬間があるのだろうということが文面から伝わってくるからです。

言いたいことは以前の記事に全部書いたからあまり言葉を重ねたくはない。言いたくないことなのですが、中央公論新社で編集を担当されている方、なぜこれを出版してよいと思ったのでしょうか。本当によく考えてほしい。

17 Mar 2019 Sun 21:17

Android 機の GPU ってめっちゃショボいことが多いから Web アプリでも Android 向けにはなるべくアニメーション出さないみたいな対処をやっていく必要がある。

React 使って普通に Web サイト書いてるだけなのに iOS と Android 向けにめっちゃコード出し分けていかないといけなくてほんとうに辛い。

iOS にもアニメーション出さない的な方向性でもいいとは思うんですけど、ユーザーテストとかするとアニメある方がずっといろいろよかったりするわけです。

15 Mar 2019 Fri 17:07

React Hooks 使いまくったプロダクトリリースしました

07 Mar 2019 Thu 17:39

cookpad TechConf 2019 にいってきた

面白かった、参考になったトーク

スライドとかは Qiita に cookpad がまとめを作っています

藤井 謙士朗 - 新規サービス開発を加速させる技術とデザイン

このサービスについて、エンジニア視点で書かれた紹介記事はあって Firebaseでバックエンドエンジニア不在のアプリ開発 クックパッドが体感した、メリットと課題 これは結構面白い記事で、レスとしてこんなものを書いたりした。

KomercoではReactでWebの管理画面やティザー画面を作っていて、デザイナーがコードを書いているので、フロントエンジニアもいないんです

と何事もないかのように書かれているところに実際何があるかをデザイナーが何をしているかというのをデザイナー視点で話していた。紹介されているツールや技法は非常に興味深い一方で、

というような一面があったことも否めない。ただ強いデザイナーは強いのでどのように採用するかとか育成するかとかそういうことは常に考えたほうがいいんでしょうね。

水谷 正慶 - スケーラブルなセキュリティ監視基盤の作り方

大企業におけるセキュリティの実務の実際を何一つ知らないので聞いてもへぇとしかならないのだけど、既存の業務においてとにかく膨大な量の手作業がつまっていることはなんとなく感じられた。

リスク評価を Lambda に置いた Go で書かれたプログラムでやってることぐらいしか正直伝わってこなかったんだけど、膨大な手作業をこなしているであろうチームがこうした施策を積極的に取り組んでいることに強い敬意を覚えた次第。俺には無理だわ。

宇津 宏一 - 新規アプリ開発を支えるユーザ・決済基盤

社内向けの基盤みたいなのは非常に大変だろうし、 cookpad もガラケー時代から連綿と伝わるユーザー基盤、決済基盤などがあるなかでこういう作業をやっていくのは本当に大変なことだろうと思う。とにかく大変そう。

その他

https://tabedori.jp/ のたけのこ鳥みたいなキャラがかわいい。

img

ダメだこりゃというやつ

宇野 雄 - クックパッドが目指す、これからのデザインとプロダクトのあり方

2 月入社の方がクックパッドはダメですという話をして、ひたすら抽象的なトークをするというセッション。「私がクックパッドのデザインプロセスを破壊します」という話をこの人がしたあと、そのあとべつのデザイナーが「既存のクックパッドのデザインプロセスを紹介します」というトークの構成になっていて、当初は聞いていて「これ宇野さんの後の話なんの意味もないよね」と思っていたのだがまあいろいろあるらしいです。

成田 一生 - 基調講演

これは非常に悪いと感じた。「クックパッドは料理を楽しくする会社で、地球人がみな料理を楽しめるようにすることが目的」という内容だった。

この問題について、この基調講演でも触れられていたが、貧困により、料理をせざるを得ない人達というのがいることが「料理が楽しくない」ということの本質的な原因であろうと思う。この問題を解決するにあたって、今クックパッドが取り組んでいる「料理のプロセスを改善する」という方法は殆ど無意味なのではないか。

料理というプロセスがどれだけ改善されたところで、そもそも料理をしたくない人がせざるを得ないという状況があるかぎり、どうにもならない。

この基調講演において「健康的な食事を外食ですることは高い」という問題が触れられていたが、健康的な食事を安価に手に入れられるようになるか、地球人がみな豊かになるかすればいいわけで、農業とかエネルギーとかそういった問題に取り組んだほうが「みなが料理を楽しめる」という状態に早く近付けるのではないか。

LT

内容はすごくよかったのだけど、採用イベントで来場者を床にころがすのが適切かどうかについてはじっくり考えてほしい。会場の問題などいろいろあるのでこのあたり難しいことなのは分かっているつもりですが、、、

というわけなので義務は果した。

28 Feb 2019 Thu 15:40

Encrypted SNI は完全に無意味

政府の役人や政治家はまともにインターネット使ってないので Fastly や Cloudflare を丸ごとブロックしてくるだけ。あんなのにリソース使う暇あったら別のことやったほうがいい。

18 Feb 2019 Mon 17:43

前ほど Fastly がアグレッシブにキャッシュしてくれない気する

14 Feb 2019 Thu 15:58

死んでなかったわ

13 Feb 2019 Wed 14:45

CDN のキャッシュ飛ばすサーバーが死んでる気がする

13 Feb 2019 Wed 14:45

このサイトの 404 まともに実装してなかったのでやった

13 Feb 2019 Wed 14:34

Travis CI でビルドが失敗したときだけ Slack に通知したい ということがあるかと思うのですが、残念ながら Travis の Slack 通知にそんなに細かい制御ない。

  1. Travis の Slack 通知先を自分のサーバーに向ける
  2. そこで中身を選別してビルド失敗だけ選ぶ
  3. 選んだメッセージを本当の Slack の通知用 URL に送る

という方法で僕は対処していますが、なんだかなあという感じですね

10 Feb 2019 Sun 14:14

ねむい

08 Feb 2019 Fri 02:02

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 全体の思想としてそうという話かもしれない。

08 Feb 2019 Fri 02:02

プログラミングが出来る と一言で言ってしまうのはあまりよくなくて、ある程度分割して考えるほうがいいと思っている。

  1. 自分が必要なものを作ることができる
  2. みんながもっている共通の課題のうち、自分の技術力で解決可能なものを見つけて、解決するプロダクトを作ることができる
  3. 同僚と協調しながら製品を作ることができる

おおまかにいって「プログラミングが出来る」というのはこの3個のスキルに分割できるのではないかと思っている。そして、これらはそれぞれあまり関係がない。

  • 自分の課題を高速に解決することができるが、それを製品や OSS にまとめてリリースすることは出来ない人
  • 優れた OSS のポートフォリオを持っているが、同僚という立場の人と協調することはあまり得意ではない人
  • 業務としてプログラミングで成果を出してきているが、別に趣味で自分のためになんか作ったりはしてない人
  • ゲームを自作しているが、別にそれで食ってこうとか思ってない人

という人達がいると思う。「プログラミングが出来ない」という問題は

  • 解決したい課題に対して技術力が追い付いていない
  • 自分の技術力に応じた課題を見つけることができない
  • 業務としてのプログラミングに必要な協調性が不足している
    • こういうものは意識して訓練するかどうかにかかっている

こういうパターンが考えられる(もちろんこれで全部ではない)。それぞれ必要な訓練は全く別なのだが、これを全部「技術をより深く知ること」で解決できるような気がしてしまうがそれは間違っている。

実際のところ「技術をより深く知ること」により転職がある程度楽になり、転職することで金と時間と気持ちの余裕が手に入りやすくなり、それによりあらゆる問題の解決は楽になる可能性があるのだけど、それが最短のパスである可能性は実はそんなにない。

「プログラミングが出来ない」というのは解決すべき問題としてはあまりにも曖昧すぎるので、自分や周囲の状況を観察してこれを細かいタスクに割っていくことが解決の一助になるし、またそういう課題の捜索と分析という作業を繰り返し行なうことでプログラミングが出来るようになる。

25 Jan 2019 Fri 15:56

捜査関係事項照会の実務について俺が見てきたこと

俺はどういう人間か: 法律関係のことはあまり知らない(弁護士とキャバクラの値段が同じということぐらいは知っている)。ネトゲや Web サービスの開発を 10 年以上やっている。大量の個人情報を取り扱い金銭化するようなサービスの開発、運営に従事したことはない。高等教育の類いはいっさいうけていない。

警察の捜査関係事項照会について、俺がこれまで見てきた会社ではだいたい管理部門かカスタマーサポート部門が対応していた。法務兼 CS みたいな人もみたことがある。俺がみたものだと、 URL やスクリーンショットをそえて、この投稿者の IP アドレスやホスト名をよこせみたいなかんじであることが多かった。だいたいそれを見れば警察がどういう捜査をしているのかは分かることが多かった。あきらかに不当な照会だなと感じられるものはこれまで見たことがない。

捜査関係事項照会について「お答えできません」という類の回答をするとハイ分かりましたということで終わりになる。その後令状をもってやってくる場合もあるが、なにもないこともある。令状をもってやってきても、ハードウェアとかアカウントとかを取り抑えられるという対処になったのは見たことがない。令状をもってやってきて、規定によりログが残ってませんとなると「なんとか探してもらえないか」ということになるが、それ以上何かという話でもない。

捜査関係事項照会をスルーしている現場をみたことがあるが、そのあとどうなったのかよくは知らない。すくなくともそこの会社の人が令状をもった捜査員とやり取りしているという場面を見てはいない。

国税局から調査関係事項照会書というのがきたことがある。この場合所属していた会社では照会に応じる対処をとったので、国税のをハネた場合に強制調査になるのかとか、その場合の実際の作業はどうなるのかとかは俺は知らない。国税の態度はずいぶん警察より酷いものだと感じた。

捜査関係事項照会に応じるかどうかは本当に企業によって違っていた。このあたり明確なポリシーをもっていると感じられる組織は見たことがない。俺が働いている、働いていたことのある会社ではないが、 LINE は明確なポリシーをもってレポートを公表している珍しい企業だ。ここまでやっている現場を自分でみたことはない。公平性のために言っておくが、俺には LINE 従業員の友人がおそらく 20 名以上存在しているし、 LINE がこのようなレポートを出していることも従業員から聞いて知った。

実務的な話でいうと、 CS 部門、管理部門的には対応工数の最小化に目がいきがちだと思う。これは俺がみてきたことではなく、単なる意見だがこのあたりの対処方針がブランディングに関わるというのが現代では明らかになっているので、広報やマーケティング部門を巻き込んだ対処が必要になってくるのかもしれない。

おそらく実際に捜査関係事項照会で一番おおく行なわれているのは犯罪発生現場近傍の防犯カメラの映像の提供依頼なのだと思うがそのあたりの実務についても俺は何も知らない。個人の位置情報を保存するサービスを運営したこともないのでそういうことを捜査関係事項照会で聞いてくることがあるのかも知らない。俺が警察官なら、被疑者や被害者の名前と電話番号をもとに CCC に「この人どっかの店舗で T カード使用した記録とか出せる?」みたいなことを聞きたくなるよな気がするが、それも想像だ、何も知らない。 CCC の持っている情報はわりと野放図に検索可能であることを知っているが、実際の運用について詳細を知らない。またこれを何故知っているかは言えない(NDA はない)。

警察官や査察官も含めて皆が個人的に知っていることはそれぞれ限定的だ。こういうことについて知っていることを書く人が一人でも多ければいいと思う。

22 Jan 2019 Tue 16:08

material-ui でカレンダーな UI を作る

こんにちは、金をよこせ死ね。こういう素晴しい書き出しでアメブロを書いている異常者がいたんですがとっくの昔に消えました。アプリ開発をやっているとカレンダーっぽい UI が必要になることはそれなりにあるかと思います。従来 Web だとそういうの非常にだるかったものですが、 material-ui という React Component 集だとそれが簡単にできます。

material-ui 。それにしても酷い名前ですね、何様のつもりなのか。 material-ui にはいわゆる Grid システムをやっていくための Grid という機能があるのですが、それとは別に GridList というコンポーネントをもっています。これはデモをみると

img

みたいな感じであきらかに汎用的なレイアウトを作ることは想定していないと思うのですが、実際 UI のレイアウトをこれで組むと話が早い。

img

こんな感じのカレンダーが以下のようなコードで実現できます。

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 いいと思う。名前が酷いが、、、

16 Jan 2019 Wed 18:36

Next