2018年2月13日火曜日

DroidKaigi 2018のWebサイトとか振り返り

DroidKaigi 2018が終わりました。今年もWebサイト関係やってました。

当日の担当は公式Twitter警備がメインでした。 ちょっと体調が完全じゃなかったので無理せず控室でもくもくとやってようと思ってたんですが、流石にその他諸々な雑用とかもしてましました。

以下、主にWebサイトについての振り返り。

Webサイトについて

去年の7月くらいだったか。サイト班のwm3さんとpsideさんたちとハングアウトで会話して、今年のサイトの方針についていろいろ決めました。

この2人がかなり動いてくれて、更にその他のスタッフもサイト更新を手伝ってくれたお陰で今年はかなり楽でした。 むしろ2人がかなりやってくれて、俺いらなかったんじゃないかレベル。 ありがてぇありがてぇ🙇🏼

droidkaigi.jpへドメインを変更

2017まではGitHub Pagesを使っていて、ドメインもgithub.ioでした。 今年からはdroidkaigi.jpというドメインに変えています。 実のところGitHub Pagesでホスティングしてるのは変わらないんですが、カスタムドメインにすることで将来的に何かしらバックエンドのシステムを持つ場合に差し替えやすいようにする目論見です。

ドメインはCloudflareを使ってSSL対応してます。

サイトジェネレーターとしてGatsbyを採用

GatsbyはReactを使ったサイトジェネレーターです。 2017まではGitHub Pagesの機能を使っていましたが、色々辛かったので全く異なる形に変えました。 流れは大体こんな感じだった。

🍏「Liquid辛いいいい」
pside「nokogiri辛いい」
wm3「もうReactでいいのでは」

※Liquid（HTMLテンプレートエンジン）もnokogiri（HTMLパーサー）もGitHub PagesのRubygemが依存してる。

サイトのアーキテクチャ構築もwm3さんがやってくれました。 その後の改修などはもちろん俺もやってましたが、React童貞だったのでおっかなびっくり触ってました。

個人的にはLiquidの仕様上の制約により辛かったタイムテーブルページの実装をなんとかできたのが大きいです。

NetlifyやCircleCIを使ったContinuous Deliveryっぽいの

最終的なホスティング先はGitHub Pagesなんですが、 別途Netlifyも使っていました。

PRを作るとその内容でビルドしたサイトがNetlifyにデプロイされて皆ですぐ確認できる形になります。 Google App Engineみたいに複数のバージョンをデプロイできるので、PR別(ブランチ別)に バージョンをデプロイする感じです。

PRをNetlify上で動作確認してmasterにマージするとdroidkaigi.jpをホストしているGitHub Pages用リポジトリにCircleCIでpushする流れです。

スポンサー一覧

サイト上のスポンサー一覧は、ベースをサイト班で作った後はスポンサー班が直接PR出してどんどんマージしていく運用でした。 途中ちょっとサイズ感の調整のためにデータ構造を変えた以外は、スポンサー班がサイトへのスポンサー様ロゴ掲載をやってくれました。 去年までは俺がIllustratorいじくりまわして頑張ってたなぁ。

Sessionizeとの連携

今回は応募トーク管理にSessionize.comを使用することにしました。 KotlinConfでも使われていて、トークの募集・レビュー・採択・タイムテーブル作成まで行える優れものです。

API経由でjsonデータも取り出せます。 当初Webサイトでは応募トーク一覧や採択トーク一覧を直接このAPIを叩いて書き出していました。 しかし、流石に大量に頻繁にアクセスされることを想定したものではなかったようで、アプリから参照されたりすることも考えるとパフォーマンスに不安がありました。 最終的に、一旦jsonを落としてきてから静的にデータを持っておく形になりました。 データはCircleCIのcron機能で日次で更新していました。

他方、基本的にSessionizeをマスターデータにしたいものの、サイト側やアプリ側の表示制御のために独自に追加したい項目もあったりしました。 そのために、サイト上に置いているjson(タイムテーブルの描画にも使ってる)はビルド時に加工したファイルになっています。

次回のDroidKaigiに向けて

色々改善できたり新たな試みを試した結果、欲や改善点も出てきました。

  • もっとCMS化したいかも
    • 他のスタッフも作業しやすいほうがいいよね
    • 公式Twitterやアプリとの連携も
  • 日英だけじゃなく両方の言語というセッションがあった…
    • これは急遽言語区分を追加して対応した。来年は最初から考慮しよう。
  • スポンサー情報のマスター化
    • アプリ側との連携を考えずにスポンサーページを作ったので、あとから無理やりスクレイピングしてスポンサー情報jsonを作るという辛み溢れる状態になっている。
    • 来年は最初からマスターデータの形を考えておこう。
  • Sessionizeとの連携をもっと楽にやりたい
    • 一旦jsonを持ってくるとかちょっとアレ
    • 間にFastlyか何か挟むとか
    • Fastly使ってみたいだけとも言う

その他

最近裏方業ばっかりなので、今年は登壇とか増やしたいななぁ。

とか思ってたら、まだ動画やスライドの公開作業あったよオイ。

投稿者 mstssk 0 コメント ラベル: , ,

2018年2月1日木曜日

Safariでposition:stickyが動かないとき

投稿者 mstssk 0 コメント ラベル: , , ,

2018年1月21日日曜日

AngularでFailed to execute 'send' on 'XMLHttpRequest'とか出た時にやること

Angularで開発していて、ビルド時やテスト時にFailed to execute 'send' on 'XMLHttpRequest' というエラーが出てわけわからん場合がある。
ng test --sourcemaps falseのように--sourcemapsオプションを切って実行してやると、詳細なエラー情報が出てくれる。

参考

投稿者 mstssk 0 コメント

2017年12月4日月曜日

🍺について

この記事はBeer Advent Calendar 2017の12月4日です。 ビールについてならなんでもOKらしいので、🍺について話します。

この記事を読んでいる皆さんは「🍺」がどう見えているでしょうか？

  1. ジョッキに注がれたビールに見える
    • あなたはモダンブラウザでこの記事を読んでいますね
  2. ビールに見えるが白黒
    • まだAndroid 4.3使ってるんですか
  3. 「�」に見える
    • 文字化けとるやん

2と3の方は今すぐ使っているPCかスマホを更新しましょう。

さて、1の方は具体的にどんなふうに見えているでしょうか？ そして、あなたが見ている🍺は他の人も同じ🍺に本当に見えているでしょうか。

PCやスマホで表示される絵文字は結局はただの書体の一つに過ぎないので、環境によって表示が異なります。 次のURLにはいろんなメーカーやアプリでの🍺の表示リストが載っています。 https://emojipedia.org/beer-mug/

いろんな絵がありますが、いずれも「ジョッキに入ったビール」として認識できると思います。 この絵文字はUnicodeで「beer mug」として定義されており、 その指針に従ってどのプラットフォームも 表示を実装している からです。

また「🍻」という絵文字もありますね。 こちらは「clinking beer mugs」です。

しかし、絵に過ぎないので、度々不幸なミスも発生 します。

Android 8.0での🍺の絵文字は泡とビールの間に謎の空間が出来てしまっています。 この不具合はAndroid 8.1で修正されています。

他の 絵文字にはさまざまな問題が起きていますが、幸いながら🍺については上記のちょっとした表示ミス程度しか問題が起きていません。 皆さん、安心して🍺を使っていきましょう。飲んでいきましょう。

投稿者 mstssk 0 コメント

2017年8月30日水曜日

ページ右下に熱盛を出すだけのUser Styleを書いた

ものすごく邪魔。

@mazamachiさんの「たまに熱盛が出てしまうextension」が面白そうだったので作った。

中身はコレ。

StylishといったUser Styleを設定できる拡張機能を利用したりして使う。

transitionやらanimationやら設定して忘れた頃に「熱盛！」ってドンと出る実装はできそうだけど、ここまでやって満足してしまった。

問題があって、Stylishでやるとiframeの中にまで熱盛するので、Twitterのタイムライン中の埋め込み動画やBloggerの画像アップロードダイアログの中にも熱盛が出てしまい、笑いをこらえながらこの記事を書いています。

投稿者 mstssk 0 コメント ラベル:
登録: 投稿 (Atom)