I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
こんにちは、よしこです。 株式会社ナレッジワーク というスタートアップで、2020年4月の創業時から一人目のフロントエンドエンジニアをしています。 初期に考えて組み上げたスタックで1年半ほど開発・運用してみて、なかなか快適に日々開発ができているので 新規開発のプロダクト立ち上げ時にどのようにフロントエンドを構築したのか? 立ち上げから1年以上開発・運用を続けてきた今、それらの選択はどうだったのか? を記事にして振り返り、公開したいなと思いました。 (プロダクトの内容はステルスで進めていてあまり対外的な発信ができないので、かわりに技術的なところはどんどんオープンにしていきたいなという気持ちがあります) いろいろな項目ごとに振り返りたいので、この記事は各項目を横断するindexとして項目ごとの概要を簡単に説明し、深堀りは項目ごとに追って詳細な記事を書いていく予定です! 前提 プロダクトとしての
この記事は 2021 年 9 月、React v17 相当時点での情報に依存しています。 React の Suspense による非同期処理は未だ Experimental な機能ですが、いくつかのデータフェッチ系ライブラリや状態管理ライブラリのインターフェースでサポートされています。 公式ドキュメントに例示された実装 Suspense を利用するときのエラー処理には、公式ドキュメントで ErrorBoundary を使う事例 が紹介されています。「データ取得のエラーの処理はレンダーのエラーと同様に動作」することに由来しています。 エラーレポートと一緒に使うと困る Sentry 等のエラーレポートサービスを利用していて、データ取得の準正常系にあたるエラーは検知したくないが、実行時エラーのような異常系は検知したいときに、この例示を素朴に採用するのでは困ることに気づきました。 ところで、Err
こんにちは。ソウゾウの Software Engineer の hiroppy です。「連載:「メルカリ Shops」プレオープンまでの開発の裏側」 の最後は、Web フロントエンドの紹介をしたいと思います。メルカリ Shops は既存のメルカリアプリの中に独立した Web アプリケーションとして動いています。本記事では、どのようなライブラリを選定し、どのようにアーキテクチャを設計してきたかを解説します。 なぜ Web なのか? アプリの上で動いているのであれば、WebView ではなくても良いと感じる人はいると思います。今回採用した 1 つの理由としては、リリースが柔軟な点が挙げられます。iOS/Android の両方に対して開発サイクルを早めることが可能であり、また機能追加やバグ修正が容易です。どのように WebView で動いているかについては、6 日目のメルカリ Shops のため
【結論】 5ヶ月かけて無事完了しました。あー長かった。 新規の機能開発を止めないために一般的な開発チームでは今回のようなフロントエンドのフルリプレイスで一部新規の機能開発を止めながら開発を行うことがあると思います。 コードフリーズとなど呼ばれているものですね。 しかしログラスのようなスタートアップではプロダクトを絶えず進化させていくことがとても重要です。 機能開発を止めてしまえばたちまち大きな開発チームをもつ競合に追い抜かれて会社が負けてしまいます。 本記事ではフロントエンドフルリプレイスを新規機能開発を止めずに走らせる方法を解説していきます。 リプレイス概要本題に入る前に今回リプレイス対象となったLoglassについてとプロジェクトの概要について説明します。 【Loglassについて】 「プランニングクラウド Loglass」はBtoB SaaSのサービスの一つです。 基本はSSGやSS
本当にどうしようもない,あらゆる高レベルな最適化を行ってなおコンポーネントが重いというような極限状態では記事の内容は役立つかもしれない
2021年1月現在、Next.jsでXMLサイトマップを生成するライブラリとしてはnextjs-sitemap-generatorが最も人気のようです。 nextjs-sitemap-generatorのドキュメントを軽く読む限り、Next.jsのCustom Serverを使用してビルド時にサイトマップを生成する仕組みのようなので、以下のようなケースでの使用には最適とは言えません。 Custom Serverは触りたくない コンテンツ追加のタイミングでビルドが走らないユーザー投稿型のサイトでも、サイトマップを一定間隔で更新したい 個人的に色々と試してみたところ、思った以上に簡単にXMLサイトマップを動的に作ることができたので、その方法を共有します。 Next.js + TypeScriptで動的にXML Sitemapを生成する 以下のような方針で実装します。 sitemap.xmlをN
室見川“Web フロントエンド”の悲しみと明るい未来という記事を読みました。 これについては全く同感です。 next.js が vercel を提供して CDNからサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。 それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。https://anond.hatelabo.jp/20210105164149 というのも、これは私達がvte.cxを提供してからずっと感じていた課題だ
仮想DOMは本当に“速い”のか? DOM操作の新しい考え方を、フレームワークを実装して理解しよう 最近のJavaScriptフレームワークで利用される「仮想DOM」について、リアルDOMの違い、メリット・デメリット、仮想DOMを使ったフレームワーク開発などを、ダーシノ(bc_rikko)さんが解説します。 はじめまして、ダーシノ(@bc_rikko)です。さくらインターネットでフロントエンドエンジニアをする傍ら、NES.cssというファミコン風CSSフレームワークを開発しています。 さっそくですが、皆さんは、ReactやVue.jsといったJavaScriptフレームワークを使ったことがありますか? そういったフレームワークで使われている、仮想DOMについて知っていますか? 「聞いたことない」「聞いたことはあるけど、どう実装されているかは知らない」「熟知している」。いろいろなレベルの方がい
この記事では面倒なので名前に .js が付いているものは省きます。例えばNext.js は Next と表記します。 まず結論から日本ではVueはReactと二分する人気があるように観測されますが、世界的な数字で人気・シェアを見るとReactが圧倒的です。 シェアだけで見るとAngularとAngularJS(Angular系の1.x系)の合計値はVueよりも高いですが、「今後はもう採用したくない」と考える率が高く、Angular/AngularJSの人気が低下しているということは間違いありません。 ※追記: Angularのシェア、人気度に関しては、Angular及びAngularJS両方を含む数値であり、AngularJSとAngularは別物であるものが混ざってカウントされているため、Angularのシェア及び人気度はあやふやかもしれません。他の数値に関して信頼性を疑うべきかどうかは
こちらは React Advent Calendar 2019 7日目の記事です。 目次 Reactの誕生とその背景 ReactのOSS化 Reactと周辺環境の時系列 Reactの誕生とその背景 2011年後半、Facebook Ads(Facebook広告の管理ツール)のUIにおいて、機能が増えていくことによりコードが複雑になり保守が困難な状況に陥っていた。 それを解決するためにFacebookの社員であるJordan Walke氏が、FaxJSというReactのプロトタイプを開発しプロダクトに導入した。 そのときのコアな発想としては、f(data)がUIになるといったように、関数にデータを与えることによってUIを生成するというものだった。 FaxJSによるコンポーネント宣言 TestProject.PersonDisplayer = { structure : function()
フロントエンドの開発に用いられる人気のフレームワーク(ライブラリ)に、ReactとVue.jsおよびAngularがあります。これらフレームワークのフロントエンド開発における役割と、3つの違いについて簡単にご紹介します。 データバインディングとコンポーネント化 フレームワークReactとVue.jsおよびAngularは、いずれもHTMLの要素(DOM)をデータと関連づけて(データバインディング)、データの変化に応じた動的なページ構成を行います。 DOMの操作には、かつてはjQueryが用いられました(今だに、使われていることは少なくはないでしょう)。けれど、モダンブラウザが対応するECMAScript 2015(ECMAScript 6)以降でしたら、標準JavaScriptでもDOMの操作は難しくありません。 動的にページを構成するコンテンツの典型は、シングルページアプリケーション(S
パフォーマンス改善ハンドブック ウェブページにおけるパフォーマンスに関する問題の見つけ方や考え方の事例をまとめた Webフロントエンド パフォーマンス改善ハンドブックを公開しました。 URL: https://dwango-js.github.io/performance-handbook/ このハンドブックでは過去に行ったWebフロントエンドのパフォーマンス改善の事例を中心に紹介しています。 注意点としてWebフロントエンドは常に変化しているため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを用い、映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのWebフロントエンドを扱います。 具体的にはニコニコ生放送(以下「生放送」)で行った事例を中心に書かれていま
注意。実装はまだないです。思考実験的な意味合いが強いです。 持論 Reactやredux/Rxのデータモデリング手法の発達で、ツリー構造の末端に渡すまでのデータモデリングが主戦場になりつつあります。これはロジックを注入する部分と、プレゼンテーショナルなものが明確に分離されてきたことを意味します。 僕は個人的に、 GUI にまつわるものは、本来GUIで設計したい、という気持ちがあります。そう、僕が作りたいと思っているのは、悪名高きホームページビルダーです。 とはいえ、プログラミング抜きでxxxできる!というものではありません。むしろプログラミングとGUIを横断するイメージで、Unity や UnrealEngine のような開発環境を想定しています。 今やりたい理由 ブラウザの仕様が安定してきた 色々と使えるパーツが増えた JS で複雑なツールを作れるようになり、インブラウザな開発ツールが作
ここでは、フロントエンド開発の概要について説明していきます。 *元記事はこちらです。(英語) この記事でカバーしているものについてSingle-page Apps (SPAs)New-age JavaScriptUser InterfaceState ManagementCoding with StyleTestingLinting JavaScriptLinting CSSTypesBuild SystemPackage ManagementContinuous IntegrationHostingDeploymentSingle-page Apps (SPAs)かつてはサーバーサイドレンダリングという、別のURLを開くごとにページをリフレッシュしてサーバーから新たなHTMLページを送る手法が主流でしたが、最近のSPAsではクライアントサイドレンダリングというものが主流になっています。
ギークハウス Advent Calendar 2016の12月22日の記事です。 他の方とは、全然違う雰囲気になってしまいましたが、読んでいただけると幸いです。 なぜVue.js?? 普段の仕事では、Ruby/Railsなので、フロントエンド周りは、jQueryにCoffeeScriptで片手間感覚... ↓ しかし最近のフロントエンド界隈は、良くも悪くも盛り上がっていて楽しそうだなあと思う日々。 ↓ いろいろ、ググって調べてみると、ES6、Babel、Reactふむふむ...🤔 ん?? Webpack? JSX?? Flux?? Redux?? 「落ち着け!とりあえず日本語でOK」状態。。正にこの記事で書かれている状態そのものでした。 ↓ Reactとかでイケてるフロントエンド開発をちょっと試したいと思っても、BabelやWebpackの設定など環境構築でつまづき、肝心のアプリケーショ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く