タグ

ブックマーク / note.com/konpyu (5)

  • noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦|こんぴゅ

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

    noteの決して止まらないカイゼンを支える、エンジニアリングへの挑戦|こんぴゅ
  • noteのフロントエンドをNuxt.jsへ刷新します|こんぴゅ|note

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

    noteのフロントエンドをNuxt.jsへ刷新します|こんぴゅ|note
  • GraphQLはRESTの置き換えではない|こんぴゅ

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

    GraphQLはRESTの置き換えではない|こんぴゅ
  • すべてをjsにまとめる思想を理解する - webpackハンズオンシリーズ|こんぴゅ

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

    すべてをjsにまとめる思想を理解する - webpackハンズオンシリーズ|こんぴゅ
  • 趣味プロダクトづくりの現場|こんぴゅ

    エンジニア趣味で自分のプロダクトを作ることが昔から推奨されている。いちからフルスクラッチでサービスを作るのは開発以外の目線が身につくし、普段使ったことがない技術の素振りに丁度よい 。何より、自分が欲しいものを作るのは楽しいのである。 ※ちなみに、業界ではよく知られているのだけど、就活や転職活動では趣味プロダクトをやっていることは良いアピールで抜群にウケる。それでも、実際に作っている人は少ない。 では実際のところ、趣味プロダクト開発はどのように進むのか。僕のケースについて紹介してみたい。 StartMapの場合東京のスタートアップを一覧できるStartMapというサイトを作った http://startmap.info/ 2015年の大晦日前、みんな帰省して暇だしなんかつくるかという話になり、友人の @tejitakさんと@tyshgcさんとで三茶のデニーズでブレストをした。「これだ!」と

    趣味プロダクトづくりの現場|こんぴゅ
  • 1