はてなブックマーク

今年もRubyKaigiが始まりましたね！noteはrubyスポンサーとして協賛しています。三重の会場にきている方は、ぜひnoteのブースにも足を運びください。 さて、noteはRuby on Railsを用いたwebサービスとして2014年にリリースされました。現在でも継続してRailsのコードベースを利用しています。 しかし、多くの機能がリリースされ、開発者も増えたため、モノリスの巨大化が進んでおり、開発効率に影響が出始めていました。 今回はそれらの問題を解消するために、noteが継続的に取り組んでいる・取り組んできたバックエンドの改善プロセスについて説明していきます。 モジュールでサービスを構成するモノリスは大きくなるとメンテナンスが難しくなります。Railsは、MVCの各層に全てのドメインがフラットに並び、レイヤごと・レイヤ間の結合度が高くなる設計思想で、巨大モノリス化への対処が難

このポエムでは、webサービスを運営するにあたってのコアはなにかという話をしてみたいと思います。 データが命webエンジニアは、やれReactでSPAをソリッドに作るやら、Railsをつかって高速に実装やら、Firebaseで工数を抑えつつスマートにPMFやら、Spring BootでJVMの資産を活用しつつ構築やら、どういったスタックでワシの考えた最強のサービスを作っていくかをベースに議論しがちです。 それはそれで必要だし深いトピックなのですが、webサービスのコアはクオリティの高いデータを集めることであり、全ての要素技術はよいデータの収集装置・機構（= 手段レイヤ）と考える必要があると思います。 では、クオリティの高いデータとは何か？これは、いくつかの側面に分解できますが、大きく分けるとシステム軸と定性軸に分けることが出来ます システム軸システム軸はデータの保存形式や整合性、容量などが

このポエムでは、IT屋なら避けては通れない障害について話してみたいと思います。 システム障害と体験的障害システムの安定性を表す指標としてSLAが業界でよく使われています。これは、障害時間を稼働時間で割ったパーセンテージでして、99.9％以上正常稼働するならスリーナインが保証されているシステム、といった感じで使います。 これはこれで便利でわかりやすい指標です。しかし、個人的には、サービス運営においてはこういったシステム障害に関する紋切り型な指標だけを拠り所にする運用は避けたほうが無難と考えています。 たとえば、あなたはCtoCのSNS系サービスを運用しているとします。このとき、障害をもっと大きく捉えると.... ・コンテンツを投稿して数時間たっても何も反応がない ・おすすめコンテンツ紹介メールが送られてきたので開封してみたが、なにも刺さるコンテンツがなかった ・読み込みが遅くてストレスが貯ま

このポエムでは、エンジニアの実装解像度についてはなしてみたいと思います。 実装解像度が高いとは？エンジニアの初心者と上級者を分ける能力差のひとつに、実装解像度があると思います。 たとえば、あるまったく同じ1行のコードを初心者と上級者が書いたとしても、その価値は実は違うんですよ、という話です。 初心者がコードを書くとき、とりあえず動けばいいや的にコードを書きがちで、結果的にコピペや依存の逆転などがよく発生するのに対して、上級者がコードを書くときはあらゆる面から多角的に検討をします（そしてそれは多くの場合、無意識下で高速に行われます）。例えば.... ・このコードが入った結果、描画処理やDBに余計な負荷をかけてしまわないか。その結果レスポンスに悪影響は出ることはないか ・既存コードとの整合性を崩さないか。同様の実装をしている既存箇所はないか。多重実装になりそうなら適度に抽象化して切り出せないか

Developer Summit 2020にて、「noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦」という発表をしました。そのスライドや補足など。 この発表では、下記のようなことについて話させていただきました。 ・noteチームが重視するサービスのグロースサイクルとは？ ・そのグロースサイクルを円滑に回すために、開発チームをどう組織したか？データをどう活用したか？ noteのグロースサイクル noteをどう伸ばしていくかが表現されたのがこのグロースサイクル図です。"ブロック"が達成したい指標で"矢印"が具体的な施策にあたります。作者が集まれば、コンテンツが増え、読者も集まり、さらに作者が増え……という構造です。各指標をバランス良く伸ばすことでサイクルが回り、正のフィードバックでどんどんグロースしていきます。 ですので、単一のKPIだけを追うことはしません。たとえば売上だ

こんにちは、ピースオブケイクのコンです。先週、noteのドメインがnote.muからnote.comに移転されました 移転の詳しい背景はこちらの記事を参照いただくとして、本稿では技術的側面からこのドメイン移行について振り返ってみます 2000万MAUのサイトを移転する技術webサービスがドメインを移転する事はたまにある...といえばあるでしょうが、noteのようにそれなりに複雑で、2000万MAUもあるサイトをドメイン移転するというのは聞いたことがありません。 2019年2月にcomを取得後、具体的に移行の作戦を考え始めたのですが、ググって成功事例を探しても「理屈は分かるけど、ウチの規模だと、どこにどう影響出るか完璧に把握するのは難しいな...」と思いました。それでもやるしかない状況だったわけです。 なので、今後、ドメイン移転を実施するサービスのスタッフ（特にエンジニア）さんの参考になれば

noteの記事ページがリニューアルしてパワーアップしました。記事の読み込み、描画が格段に高速化されています。 noteのフロントエンドはAngular.jsの1系で運用されてきましたが、実行効率が悪く表示速度が遅いという問題がありました（特に古いスマホで顕著）。問題を根本解決するためにNuxt.jsへの移行を進めていました（詳しい経緯は以下の記事をごらんください）。 今年から、おすすめページ、マガジンページ、コンテスト一覧ページなど部分的にNuxt版に置き換えていきました。nodejsやNuxt.jsサーバーの運用が初めてだったので一気に置き換えるのではなく少しづつリリースして様子を見ながら進めました。 運用を2ヶ月ほどしてみて、インフラ面、実装面で問題なさそうなことが確認できたため、noteのトラフィックの多くを占める記事ページ（このページがまさにそうですね）のNuxt.js版リリースを

webサービスのUXを向上させるために、表示速度は非常に大切です。 しかしながら、noteはリリース当初からフロントエンドの実行速度が遅い=表示が遅いという構造的な問題を抱えており、継続率や離脱率など重要指標に悪影響を及ぼすリスクが強くありました。 noteチームはnoteを本格的なメディアプラットフォームへ成長させるスピードを加速していきます。それを踏まえ、手遅れになる前に技術的な負債を解消し、最新のベストプラクティスに沿ったフレームワークに移行することで、高性能なサービスを提供する基盤を作っていくという決断をしました。 本ポストでは、移行プロジェクトの技術的背景や移行手順を説明します。また、途中成果のデモをUPしているのでご紹介します。 技術的な背景noteの現在のフロントエンドはAngular.js 1系で構築されたSPAです。Angular 1系はかなり複雑なUIでも簡単に構築でき

ソフトウェアエンジニアリングの世界では、ここ数年明らかに「分散」ブームが来ている。巨大システムを小さく分割して柔軟にする「マイクロサービス」の方法論や、膨大なビッグデータをクラスタに分散させて効率的に集計する「hadoop」が完全に認知された。そして、いままさに、分散台帳技術（ブロックチェーン）に乗ったビットコインが世間を賑わせまくっている。 「分散」の逆は「中央集権」になるわけだが、きょうび、中央集権的なアーキテクチャは古臭いものと見られがちな風潮すらある。しかし、GoogleやFacebook、Twitter、いくつかの著名OSSはソースコードの管理に中央集権的なアプローチを明確な理由をもって採用している。そのワケを紹介してみる。 ソースコード管理の設計思想ソースコードの管理を担うシステムはバージョン管理システム(VCS）と呼ばれる。現在、ポピュラーなVCSは分散的な設計のgitで、g

GraphQLは最近注目されているWeb APIのための問い合わせ言語だ。 現在主流のRESTfulなAPIはURLとmethodでリソースを表現するわけだが、GraphQLは単一エンドポイント（ex: "POST /graphql"）だけ存在し、欲しいリソースをHTTP POSTのbodyに明示的に記載してリクエストする。 ↑JSON APIをGraphQLの形式でコールする（引用: how to graphql ) 徐々に実装例が増えてきており、2016年にはGithubがAPIの実装を全面的にGraphQLに移行させたのが注目された。 色々調べていくと、GraphQLは単にRESTの代替ではなく、開発・運用フローを一新させうるほど豊かな思想・機能を含む事が分かって来たので現状の整理をしてみたい。 APIリクエストを束ねて効率化RESTではURLがひとつのリソースを表すため、複数のリソ

販売終了：「Vue.jsとFirebaseで作るミニWebサービス ~初めてのサーバーレスSPA~」 PDFダウンロード版 #技術書典 ※内容が古くなってしまったため販売を終了しました。 4月22日に開催された"技術書典4"で頒布し、現在800部以上売れている「Vue.jsとFirebaseで作るミニWebサービス 〜初めてのサーバーレスシングルページアプリケーション〜」のPDFダウンロード版になります。 この本の目的・ターゲットは？主に簡単なWebサイトを作った事があるWebフロントエンド初心者の方が、本書を通じてSPAの基本を掴み、簡単なWebサー ビスが作れるようになることを目的として

javascriptの開発では、sassやtypescriptなどのコンパイル、minifyやautoprefixerでの最適化、依存関係を解決しbundleするなど多様な工程があるので、属人化・職人依存を避けるためにタスクランナーでの自動化が昔から当たり前に行われています。 webpackはこの手のツールのデファクトです。webpackはタスクの自動化支援ではなく、なんでもjsにまとめるという仕事をうまくやる事に特化しています。gulpやbrowserifyで行なっていたようなタスクの自動化はnpm scriptで十分やん、という割り切りを感じます。 なんでもjsで扱えるようにするので、cssや画像やhtmlもjs内にロードでき、設定が煩雑になりにくくなります。 webpackのloaderという仕組みがjsへの組み込みや最適化をうまくやってくれるのですが、どういうものか検証していきまし

「あらゆる産業はソフトウェア化する」とマーク・アンドリーセンが主張した通り、ITが様々な分野を侵食している。そのなかで、重厚長大な建築産業にも情報化の大波が来ているらしい。 BIMの普及BIM(Building Information Modeling)という、コンピュータ上で構築した3次元モデルをベースにしたワークフローが爆発的に普及し始めているという。 BIMでは、あらゆる建材・設備をモデリングし、コンピュータ上で組み立てていく。モデルにはコストや環境性能などのメタデータが付加されており自動的にコスト計算を走らせられる。平面図は3次元モデルを輪切りにすればすぐに取得できるし、図面に変更を行いたい時は、３次元モデルを編集するだけで自動的に追随するので生産性が非常に高い。プレゼン用のCGも、3次元モデルをレンダリングするだけで作成可能だ。デジタルファブリケーションが普及しているのでモデルデ

世の中にビジネスホテルは多数あって激しく競争しているわけだが、エンジニアが泊まるのに適した性質を備えたビジホは限られていると思う。そんな中で、東横インは完璧に技術屋のニーズに応えており頭一つ抜け出ている。それは一体どういうことか？を説明していきたい。 冪等性が完璧に担保されている冪等性が担保されているとは「ある操作を何回実行しても、同じ結果が返ってくる、同じ状態になる」という意味で、ソフトウェアが備えているべき重要な性質の一つである。 なんと、東横インは全国各地どこに泊まっても、結果が同じになる。部屋や家具のレイアウト、シャワーの温度や水圧、朝食、アメニティ、ベッドや照明の具合など、それこそコンピュータのような精緻さでどの館も同じである。チェーンなので統一感があるのは当たり前なのだが、それを超えて区別不能の域に達している。 エンジニアのメンタルモデル的には、コマンドが期待通りのタスクだけを

Herokuはwebアプリをインターネット上にデプロイする場所として広く使われている。web業界の人は誰もが一度は触った事があると思う。 何が便利なのかというと、デプロイ作業が極めて簡単なことだ。コマンド一発でサーバーが用意され、これまたコマンド一発でデプロイが出来る。一般に、webアプリは依存するライブラリが多種多様あり、それらを漏れなくインストールしないとデプロイ出来ないのだが、代表的なwebアプリケーションの作り方に添って作っている限り、後は構成を検知してよしなにやってくれるのだ。noteのリリース時の検証にも大活躍してくれた。 別にHerokuの回し者ではないのだが、一旦これを経験すると、VPSを借りてLinuxのセットアップをしてミドルウェアいれて....といった一般的な構築作業が気の遠くなる工程に思えてくる。 しかし、HerokuはUSとヨーロッパにサーバーがあり、日本からの通

「YOUはどうしてエンジニアに？」は開発現場のエキスパートから滋養深い洞察を聞き出し、皆様のキャリアにお役立てればというインタビュー企画です。エッジな人がどういう考えをお持ちなのか、気になりますよね。第一回は @kitak さんをお迎えしました。（聞き手：こんぴゅ） こん: 今回はkitakさんにお越しいただきました。めちゃんこ出来るエンジニアだと僕は尊敬してるんです。さっそくなんですが、YOUは技術領域ではどこがお得意ですか？ kitak: webのフロントエンドを仕事で担当しているのでそこですかねえ。前職ではRailsをやってました。Vagrantやpuppetを使って環境構築をしたりするのも得意でしたね。 こん: そすよね。とりあえずフロントエンドで困ったらkitakさんに聞いちゃいます。そんなプロフェッショナルなkitakさんですが、YOUの仕事道具でこだわりポイントはあります？

今週、Mozilla FoundationのエンジニアであるRobertさんが書いたエッセイが話題になっていた。「インディペンデントなブラウザをメンテするのはめちゃ費用がかかる」という主張だ。 Maintaining An Independent Browser Is Incredibly Expensive http://robert.ocallahan.org/2017/12/maintaining-independent-browser-is.html ここでいうインディペンデントなブラウザとはもちろんFirefoxのことで、インディペンデントとはMozilla FoundationがGoogleやApple、MSのような超巨大企業がつくるブラウザとは独立した立場を取っているということだ。 10年以上前の牧歌的な時代とは異なり、現代はブラウザに盛り込まれる仕様が非常に増え、それぞれに

日本経済新聞は国内を代表する経済誌だ。その電子版はwebでの継続課金を大成功させ、いまや50万以上の有料会員を擁するモンスターサイトだ。 その日経電子版が11月6日に全面リニューアルしたのだが、公開後、web業界がにわかにざわついた。表示速度が爆速だったのだ。日経公式もモバイルで2倍の表示速度を達成したと堂々と宣言していた。 webサービスは継続率こそ神KPIで、その継続率には速度が大きく影響する。 これはチェキらないとヤバイと感じ、友人のkitakさんとスピードの秘密を調査してみた。 Fastlyをコンテンツキャッシュに使う殆どのデータはFastlyを経由して取得されていた。Fastlyは最近注目を集めているCDN（世界中にエッジサーバーを配置し、高速にコンテンツを配信するサービス）で、非常に高機能でユニークなサービスだ。 一般に、CDNはいったん世界中にコンテンツをばらまくと、それを無

ケーブルが増えるのがとにかく嫌いである。 線が床に着地しているとルンバが引っかかるし、絡み合うと面倒だし、延長タップはダサいし....とイイことが全然ない。特に、家電の中でも専用アダプタ・専用端子が必須なタイプの製品は、付属の線を無くすと大変に困る（メルカリに泣きつくハメに）ので更に最悪だ。 そういうわけで、USBが出てきた時はかなり嬉しかった。昔はPS/2やらRS232CやらIEEE1394やら機器ごとに色々端子がありややこしかったのだけど、USBでかなりスッキリした。端子のフォーマットなんて機能を満たすなら必要最低限でいいはずで、あるべき姿ではある。 しかし、USBは登場からだいぶ時間がたち、そろそろ他のフォーマットと比べると速度や性能面で弱点が目立ちはじめてきた。なにより裏表を間違って時間を無駄にするという半端ないBad UXをなんとかしてほしい。そんなこんなで、USBの次世代フォー

先月あたりから、オープンソースソフトウェア（以下、OSS）のライセンスのあり方について、Facebookを火種にして侃々諤々の議論が起こっているので解説してみる。 ASFがFacebookにNOをつきつけることの始まりは、Apache Software Foundation（以下、ASF）という著名OSSプロジェクトを多数保有する非営利団体が、Facebookが自社OSSに付加している独自ライセンス Facebook BSD+Patents license を「Category-X」リスト（禁忌リスト）に追加したことだ。 ASFプロジェクトは、Category-Xに含まれるOSSに依存してはいけない決まりがあるため、Facebook製のOSSに依存しているプロジェクトは、8月31日以降はそれらの依存を取り除いてからではないと新しいリリースが出来ない。影響を受けたプロジェクトは少なくとも C