25日目、最終日です。していきたいかについて技術編と機能編に分けて書こうと思います。細かく直したいところはいっぱいありますが、大きめトピックだけいくつか書きます。キャッシュについては19日目の記事に詳しく書きました。呼び出してレンダリングしているので、キャッシュすることでパフォーマンスをあげたいと思っていますが、コスト(お金)がかかる問題をどうにかしないと...。使えるようにして同一コードでサーバー/クライアント両方動くようにしたいですね。書く必要がありそうです。動かすのは、たぶんやればできるんじゃないかなと思ってますが、確証はないです。サーバーが不要になり、真のサーバーレスにできます。真のサーバーレスになると圧倒的にコスト削減できるはずなので、取り組んで見る価値はあると思います。したい今はテストは手元で実行するだけになっているし、デプロイも手元からやっているという、プロとして恥ずべき状態です。使ったことないのでやってみたい。どれも実際にやるかどうかはわかりません。機能編サービスをシンプルに保ちたいので、そんなにたくさん機能を追加するつもりはないのですが、現状でいくつかやりたいことはあります。探しやすくする今カレンダーを探すのはテキスト検索ぐらいしかないので、もう少しカレンダーを探しやすくするような機能をいれたいです。具体的にはカテゴライズ、スターを導入して人気順、募集中のものだけ検索、などを考えています。ちなみにカテゴライズについては過去のカレンダーを手動でカテゴライズしてみたのですが、ジャンルが幅広すぎて、あってもなくてもあんまり変わらないのでは、という気になったので一回置きました。機械学習でいい感じにカテゴライズできたりするかな。地味な問題ではあるんですが、今年一番お問い合わせが多かった問題です。側のアイコンが更新されるタイミングが難しい感じになっています。地味なんですけど、アイコン大事なのでどうにかしたいですね。アプリどちらかというと技術的な興味によるものです。いい体験が提供できるんだろうか。やってみないとわかりません。作り変えてみるなんていうのも技術的には面白そうではあります。お気軽に書いてください。日本語でも大丈夫です。まとめ書ききりました。使ってくれた方、ありがとうございました。利用してきた技術がどのように変わってきたのかを書こうと思います。2012年リリースした年です。専用のサービスを作ったら使いやすいんじゃないか、というので作りはじめました。使ってホスティングしていました。値段も安かったし簡単だったんですごくよかったんですけど、今はもう終了しちゃってます。見つけてきた当時の様子はこんな感じでした。やる気がなさすぎるw2013年ほぼ一人でやっていたところに、june29、ayumikoという強力な仲間を得て、飛躍的に完成度が高まった年です。さんにはクソダサかった見た目を見違えるようなデザインにしてもらいました。利用できなかった(ような気がする)あたりが理由だった気がします。利用するようになったようです。当時流行ってたんですよ。当時のデザインはこんな感じだったみたいです。12月になったらカレンダー一覧でなく記事一覧をトップに出したりしてました。背景の画像がなんかかっこいいですね。2014年この年は軽微な変更で、特に大きい変更や技術的チャレンジはないみたいでした。エントリを書いてました。流行りはじめぐらいで、試してみたいなーと思っていたので投入してみた。知見はほぼない状態だったので色々と苦戦した覚えがあります。乗っかれるし、アーキテクチャとしては今でも悪くない気がしてます。流行りはしないと思うけど。詳しくは前に発表したときの資料がありました。軽微な変更のみで大きな変更はなかったみたいです。今年はHerokuからAWSに移してDocker/ECSにしてhttpsになったりHTTP/2に対応したりしました。インフラを作ってみたかったというのが動機です。難しくて大変だった記憶があります。今年のほうが大変だけど。移して月1000円ぐらいで運用できるようにしました。使い始めたりしました。よるデプロイになりました。戻らなかった理由は覚えてないけど、なんでだっけな...。ほうが安かったからかな。2019年とにかくモダンな構成にしたいと思ってがんばって作り直しました。戻ってるかも知れないです。できてからの歴史を振り返ってみました。2013年に基本的なかたちができてか大きい機能や見た目の変更はなく、個人サービスなので技術的なチャレンジを色々とやってみる実験台みたいになってます。今後も大幅な機能変更とかの予定はないけど、できるだけ使いやすくはしたいし、長くサービスを継続できるようにがんばりたいし、技術的チャレンジももっとやっていきたいと思います。明日はいよいよ最終日です。今後のAdventarの技術的チャレンジや方向性について書こうと思います。オープンソースにしました。ツールやライブラリ、言語などのソフトウェアであれば今の時代オープンソースというのは山程ありますが、サービスがオープンソースというのはそんなに多くないと思うので今回はそうした理由や、いい点、悪い点などについて書こうと思います。クローズドである意味もないので、オープンソースにしたいとは前々から思っていて、昔のコードはオープンにしづらい履歴もあるし、システムリニューアルのタイミングでちょうどいいので、このタイミングでオープンにしました。オープンソース支援で料金を補助してくれたりするし(試しに申請してみる予定)、いいことばっかりです。頂いて、オープンにしてよかったと思えました。ありがとうございます。マンなのがバレる)また、オープンにすることであまり雑にできない、という緊張が生まれるのは良いですね。実際コードを読んでる人はほとんどいないでしょうが、見られる可能性がある、誰かの参考にされる可能性がある、というだけで、ちゃんと書かないと、という意識になります。コードとかはけっこうひどい感じではあります。懸念点セキュリティ少し大変なのは、オープンになることでセキュリティリスクが高まることかなと思います。世の中のはオープンソースのソフトウェアで溢れていて、それに対して脆弱性もばんばんでているわけで、アプリケーションのコードだけ隠しても劇的にセキュリティが強固になるとは思いません。オープンよりはクローズドのほうがセキュリティリスクは減ると思いますが。クローズドだと雑にリポジトリ内に入れられるような情報を、オープンだと入れられない(ので環境変数などにする)、みたいなのは多少ありますが、より健全になるだけなのでこれについてはオープンのほうがいいですね。コードをオープンにするかはけっこう迷いました。ネットワークまわりの設定を間違えていたりすると危険だし、あまり外に出したくない情報ではあります。インフラ構成はどは特に外には出さないので、こういうものこそ誰かの参考になれば、という気持ちでオープンにしました。危険な設定を見つけたらこっそり教えてください。サービスを真似される危険オープンソースにしたときに聞かれたことがあったので一応書いておきます。他には雑なスパムみたいなコピーサービスが増えるみたい可能性もありますが、それは別にクローズドでも見た目を真似ることはできるし、結局コンテンツがないと意味がないので心配してません。https://github.com/thepracticaldev/dev.tohttps://gitlab.com/gitlab-org/gitlabこれらのサイトはオープンですが特にそれを使って類似サービスがでたりはしてないし、心配するだけ無駄だと思っています。まとめ今日はサービスをオープンソースにして開発する意味や懸念点について書きました。歴史について書こうと思います。系の細かいネタを投下します。そのまま使っています。リンク切れになってしまいます。なると、ひどいと以下のようなってしまいます。デフォルトアイコンを設定するようにしたいところです。アクセスしてみないと取得できるのかどうかわかりません。イベントをトリガーしてデフォルト画像にフォールバックしています。やっていてもう少し複雑ですが、こんな感じのイメージです。実際のコードは以下です。https://github.com/adventar/adventar/blob/c175ac9bd7fd9c12a74bd86202129394ba13e41f/frontend/components/UserIcon.vueこれでさっきの画面は以下のようになります。呼び出し待ちなどにローディングを表示するのはユーザーに状況を伝えるのに重要なアクションですが、ローディングを表示するのはできるだけ小さい範囲に留めるようにしています。結果を待たないといけないので、返ってくるまでしばらくラグが発生します。そのとき全画面ローディングにしてもいいのですが、以下のように、必要な部分だけをローディングにすることで、可能な限りユーザーに速く画面を見せます。8日目の記事に書いたのですが、最初のログイン処理にやや時間がかかってしまうため、その間ローディングを出したいのですが、これもログイン情報が必要なところは多くないので、必要なところだけローディングにして体験を損ねないようにしています。これでだいぶ初期表示が速くなり、体験がよくなります。吹き出しの位置のこだわりこれは本当に細かいのですが、カレンダーで登録情報を編集するポップアップがあるのですが、この吹き出しの位置に微妙なこだわりがあって、端の登録を押したとき、スマホなどの画面幅が狭い場合は以下のようになります。可能な限り選択した吹き出しに近い位置に出して、吹き出しの三角は選択したセルを指します。画面幅が広いデバイスで見た場合は左右に余白ができるので、端のセルでも中央にポップアップを表示したいところです。書いてみると当たり前の動きな動きすぎてなんでこれを紹介しているのか自分でもよくわからなくなってきましたが、この動作をあらゆる画面幅で動作するように実装するのが思いの他大変だったので紹介したくなっただけです。実装を見返してみると色々ハードコーディングしてあったりして泥臭くてだいぶひどい感じですが、がんばった後が見られますね...。本当に細かすぎてすいません。オープンソースで公開した話を書こうと思います。縮小するだけで、スマホでは非常に使いづらいサービスでした。多いという言い訳のできない証拠があったので、モバイル対応だけはやることにしました。出し分ける方法があります。機能やレイアウトがガラっと変わるのであれば出し分けのほうがよいですが、スタイルの変更だけで要件がまかなえるのであればレスポンシブのほうが楽な場合が多いです。あった機能がスマホだとなくなっているという体験が嫌いなので、今回はレスポンシブで対応しました。採用し、以下の3パターンに絞りました。開発するのでモバイルの確認が漏れがち、などの理由があり、モバイル向けの画面をプライマリで作り、そこから幅を広げた場合の画面を作っていくことにしました。使うのがポイントです。480pxをブレイクポイントにしてスタイルを変更するケースを考えてみます。