プロダクトマネジメントと事業開発に関する私的な振り返り - 下町柚子黄昏記 by @yuzutas0
TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説
同じTypeScriptという言語を利用する場合においても、トランスパイラによってTypeScript自体の機能制限がかかったり、思わぬトラブルを招く場合があります。それぞれのトランスパイラの特徴を踏まえた上で、それにより生じる問題も見ていきましょう。 1-1. tsc TypeScriptの開発元であるMicrosoft純正のTypeScriptトランスパイラです。TypeScriptを利用する際に typescript パッケージをインストールする必要がありますが、それに同梱されています。 公式ツールなだけあって最も早く最新バージョンのTypeScriptに対応したり、言語すべての機能を利用することができる一方で、バンドラではないためminifyやchunkの設定はできません。また、Path Aliasesの未解決や旧ESへの互換性が不完全であることが欠点として挙げられます。 tsco
最強の振り返りメソッド「KPT法」で、失敗を反省するどころか、長所も希望も見つかった話 - STUDY HACKER（スタディーハッカー）｜社会人の勉強法＆英語学習
日々の失敗を反省し改善していくことで、人は成長できるわけですが、なかには「失敗するとひどく落ち込んでしまい、反省するのがつらい」という人もいるはず。ですが、そんな人でも「KPT法」という振り返りのフレームワークを使えば、前向きに日々の振り返りができ、改善につなげることができますよ。 今回は、KPT法とはどういうもので、どんなメリットがあるのかを、わかりやすく解説していきます。筆者が実際にKPT法をやってみましたので、その模様も画像つきでご紹介しましょう。 KPT法とはなにか KPT法とは、取り組んでいる仕事や活動を改善するための振り返り方法のひとつ。現状を見直す際に、「Keep（このまま継続すること）」「Problem（課題）」「Try（解決策）」という3つの項目、すなわち「KPT」を書き出し、今後どうするかを考えるものです。シンプルな手法でありながら、ひとりでも集団でも活用できるうえに、
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho
とってもやさしいフロントエンド入門
まず、新しいアイデアが提案されると、ステージ0の「Strawman」と呼ばれる段階に入ります。ステージ0のアイデアが価値のある提案として見なされ、大まかな形で問題点や解決策を説明できるようになると、ステージ1の「Proposal」と呼ばれる段階に進みます。そして、提案がある程度まとまって仕様の草案として認められると、ステージ2の「Draft」と呼ばれる段階に上がります。さらに細かいところまで練り上げられて、仕様がほぼ完成した状態になると、ステージ3の「Candidate」の段階になります。最後に、2つ以上のブラウザがその機能を実装していて、ECMAScript の編集者に承認されると、ステージ4の「Finished」と呼ばれる段階になります。 ステージ4に上がった提案は、毎年 6 月のタイミングで ECMAScript の新しいバージョンとしてリリースされます。リリースする際は、ECMAS
こちらの記事は、Jonathan Saring 氏により2019年12月に公開された『 11 Must-Know FrontEnd Trends for 2020 』の和訳です。 本記事は原著者から許可を得た上で記事を公開しています。 ランチ中のフロントエンドトークでスマートに見られる方法！ チームのランチトークでスマートに見られることは、最新のフロントエンドのトレンドを常に把握しておくための大きな理由であることは言うまでもない。 それは、あなたがより良い開発者になり、より良い技術とより良い製品を作るのに役にたつかもしれない。 たぶんね。 だから、いくつかの興味深い方向を示すことで、この名誉あるクエストを君が簡単に達成できるように少し時間をもらいたい。 すべてのコンセプトについて1から10まで説明するのではなく、そのコンセプトとそれがどのように有用であるか紹介しよう。最後にはさらなるリソー
この記事は7/3午前中に記載したもので、まだKDDI社長の会見内容を反映していません。 今回のKDDIの障害が具体的にどういうサービスに影響が出るのものか、モバイルネットワーク初心者としてLTE/EPC/IMS周りの挙動の勉強のためにまとめてみた。 はじめにまとめ モバイルの通信には音声通話とデータ通信があり、今回主に長時間の障害を受けたのは音声通話(IMS)の方だった。 7/2(土)の日中帯はデータ通信はできるが音声通話やそれに付属するサービスが利用できない状態が継続していた。データ通信も不安定な状態になっていた。 端末の実装(主にAndroid端末)によっては音声通話ができないとデータ通信も止めてしまう挙動があった。これによりLTEを回線として使用しAndroidベースで構築された決済システムなどが利用不可能な状態が継続した。 音声通話(IMS)が利用できないと、通常の電話はもちろん、
筆者はES6以前のVanilla JSがあまり好きではありませんでした。 そこで、バニラJavaScriptをなるべく書かなくていいように、2000年代を通じてさまざまなアプローチを追求してきました。最初はRJS（Ruby-to-JavaScript）、次はCoffeeScriptでした。どちらのアプローチも、バニラJavaScriptより楽しく書けるソースコードを、ブラウザが実行できるバージョンのJavaScriptへトランスパイルするものです。ある程度は、うまくいっていました。 とはいえ、これは明らかにその場しのぎの手段に過ぎず、ブラウザがより洗練されたJavaScriptを理解できる日を待ちわびていたのです。ただ、そんな日が来ることはなく、永久にその場しのぎでやり過ごすのかと思われる時期がしばらく続きました。 しかし、幸いなことにJavaScriptは改善を続け、2015年にはES6
(社内用ドキュメントの公開版) テストのポリシー 前提として、ユニットテストを導入するコストを、限界まで低くすることを目指す。テストが根付いていない言語環境や文化では、放っておくとテストが書かれないまま実装が進行し、結果としてテスト不可能な巨大な雪だるまが完成する。こうなるとメンテコストが高いE2Eを大量に書かないといけなくなり、テストの実行時間が膨れ上がっていく。 そうなる前に、ユニットテストを書きやすい環境を維持し、ユニットテストとして問題を切り分けられるような環境を維持する。とにかく書きやすさを重視し、一つのユニットテストを書くオーバーヘッドを限界まで下げる。 最初の一つを早い段階で書く 自分の経験的には、ユニットとテストの最初の一つを書いたらあとは自然とその周辺で増えていく。サンプルがあったら人はコピペする。逆にいうと最初の一つを書かない限り一切書かれない。まず一つ用意するのが大事
Intro ちょうどタコピーの原罪が流行ってるのでこのタイトルにしたけど結構気に入ってる。 d.potato4d.me この話を読んでの感想とここまで大きくなった Node.js の振り返りをしようと思う。 どんなプログラミング言語であってもみんなから使ってもらって開発者をハッピーにしたいと思ってる。ただ最初は良かったと思ってた機能がなんか古臭くなったり、他にクールな機能を持ったものが登場したことによって徐々に飽きられていき、最終的に他の言語に乗り換えられる。 まぁどんな言語も同じだと思う。C言語だって生まれた当初はすごくクールでみんなをハッピーにしてた。今丁度「戦うプログラマー」を読んでるが、C++が出てきて、周りのエンジニアが C++ を使おうとするシーンが出てくる。そこで、「あんなの使って何が良いんだ、Cで十分だろ」とWindows NT 開発リーダーのデーブカトラーが言ってたりする
ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
フロントエンドの新規開発でNext.jsの採用を見送った話 - バイセル Tech Blog
※こちらはバイセルテクノロジーズ Advent Calendar 2023の10日目の記事です。 前回の記事は、金澤さんのAuth0とEntra IDを扱うプロダクト同士を繋げるためのIstio設定あれこれでした。 はじめに こんにちは、開発3部の神保です。 バイセルでは、お客様宅への出張訪問による買取が買取チャネルの主力となっています。現在開発3部の弊チームでは、この出張訪問買取で使用されるWebアプリケーション「Visit」の新規開発を進めています。 VisitのフロントエンドにはReactを採用しましたが、Next.js等のフレームワークは使用せず、Vite + ReactによるSPA (Single Page Application)構成を選択しました。 技術選定の過程では、社内での採用事例などからNext.jsも検討の対象となりましたが、最終的にはその採用を見送る結論に至りました
IE First を避ける
まず、去年の実績として、IE のシェアが 9% から 5% になっています。 Browser Market Share Japan | StatCounter Global Stats 世界だと 1.4% です。これは途上国などでは Android Chrome が支配的だからです。 https://gs.statcounter.com/browser-market-share/all 国内で「IE シェア」などでググって出るサイトは 9% と出ていますが、これはデスクトップのみの数字で、モバイルを含めた数字は 5%前後です。日本はさらに Chrome ベースの新 MS Edge の正式リリースがコロナと確定申告の影響で延期されており、リリースのタイミングでさらに減ることが予想されます。 去年の実績値でいえば、来年度には 2% 台、再来年には 1%を切っている可能性があります。これは to
Front-End Study #1「Cloud Native時代のフロントエンド」 - connpass の発表内容のテキスト版です。 発表に載せられなかった参考資料集 StatCounter Global Stats - Browser, OS, Search Engine including Mobile Usage Share The "Developer Experience" Bait-and-Switch - Infrequently Noted JavaScriptよ。文明を捨て、自然に還れ。 ::ハブろぐ Deno - A secure runtime for JavaScript and TypeScript Rome Toolchain Blitz.js - The Fullstack React Framework | Blitz.js ⚡️ Prisma - Da
フロントエンドのビルドツールが色々ありすぎて、何がどうなっているのかがわかりづらいため、 各ツールができること、特徴 ツール間がどのように依存しあっているか を一気に調べて整理した。(情報は2023/10時点) 概要 ツールの依存関係整理 上層: dev server付きのバンドラ/ビルドツール。アプリ開発者が直接configなどを書いて取り扱うのはここが多いと思われる。(Next.jsに関しては、ビルド機能に着目した場合) 下層: やや基盤的なdev serverなしのツール群。 矢印は、明示的な依存関係を表す。実際には、明示的な依存関係がなくても、下層のツール群は上層のバンドラ(やRollup)に対してプラグインを提供していることが多い。 各ツールのできること整理 ツールごとに、大まかな機能区分で、できることとできないことをまとめた。 各機能区分の定義は次セクションを参照。 ツールごと
moment.js や day.js と似たインターフェースを実装した高速・軽量の JavaScript ライブラリ『cdate』をリリースしました。→ https://www.npmjs.com/package/cdate cdate の主な特徴： moment.js や day.js、Luxon よりも高速 moment.js と同じ .format("YYYY-MM-DD HH:mm:ss") 出力フォーマットに対応 strftime と同じ .text("%Y-%m-%d %H:%M:%S") 出力フォーマットに対応 moment.js と同様に .add(1, "month").startOf("week").endOf("day") のような計算に対応 .tz("Asia/Tokyo") あるいは .utcOffset("+09:00") のようなタイムゾーン（時間帯）指定に対
年内に間に合わなかった… 2021年に主にお世話になった言語・ライブラリ TypeScript React chakra-ui dnd-kit Node Vite esbuild Docker(=> lima) とりあえず挙げてみたが、なにか特定のライブラリを使う、という感じではなく、レイヤーが一つ下にいった感じがあり、実際にはなんかもうちょっと下のミドルウェアみたいなものを作っていることが多かった気がする。ASTをいじるコンパイラ周辺ツールを作っていることが多かった。 サクッとなにか作る場合、 React + TypeScript + Vite(esbuild) が鉄板という感じで、 esbuild が異次元に速すぎて、typescript の変換もバンドルも、もはやこれ一本でいい気がしてる。 microsoft/typescript はもはや言語仕様の定義と型検査がメインであって、コン
ちょっと複雑なシェルスクリプトをJavaScriptで書く - lacolaco-engineering
ちょっと複雑なシェルスクリプトを https://github.com/google/zx を使って書くとJavaScriptプログラマにとってはメンテナンスしやすい /lacolaco/lacolaco.iconはzx歴 3-4ヶ月ってところ (2021-08) 嬉しいところ async/awaitが使える 配列が扱いやすい モジュールで再利用しやすい 他のNode.jsライブラリと併用できる Prettierでフォーマットしやすい Lintしやすい エディタ支援が安心 Made by Google 微妙なところ JavaScriptプログラマ以外にとっては無用 とはいえシェルスクリプトによほど慣れてる人以外はよく整理されたJavaScriptのほうがセマンティクスを読み取りやすいのではないか スクリプト自体はこんな感じ（公式READMEより） code:js #!/usr/bin/en
こんにちは、CX事業本部Delivery部サーバーサイドチームのmorimorkochanです。 突然ですが「あぁ〜管理画面作るのめんどくせ〜」って思うことはないですか？ 例えばRDBと接続されたRESTfulなAPIサーバーを作っていて、一部の管理者向けに管理画面を作りたいが管理画面にこだわりがない場合などなど。 そんな時に便利なのが、Admin.jsです。Admin.jsは管理画面を簡単に作成できるフレームワークです。オープンソースとして公開されており、クラウドにデプロイされているサービスを利用する場合は月額料金がかかりますが手動でサーバーに組み込んでデプロイする場合は無料です。 Admin.jsを使うと、RDBで管理される各テーブルごとにCRUD画面を簡単に作成することができます。これによってRDBと同じプロパティを何度も定義したり同じようなCRUDコードを何度も記述する必要はありま
Modern web apps without JavaScript bundling or transpiling
August 12, 2021 Modern web apps without JavaScript bundling or transpiling I didn't much care for vanilla JavaScript prior to ES6. Through all of the 2000s, I chased different approaches to avoid writing too much of it. First there was RJS (Ruby-to-JavaScript). Then there was CoffeeScript. Both transpiling approaches that turned more enjoyable-to-write source code into the kind of JavaScript that
Ruby言語によるWebアプリケーションフレームワークの最新版となる「Rails 7」が正式リリースされました。 Rails 7.0 FINAL: The fulfillment of a vision to present a truly full-stack approach to web development that tackles both the front- and back-end challenges with equal vigor. https://t.co/WxJ0nKYfE7 — Ruby on Rails (@rails) December 15, 2021 Rails 7の最大の変更点は、フロントエンド開発環境が刷新されてNode.jsを用いない構成がデフォルトとなったことでしょう。 Rails 6では、優れたフロントエンド開発環境を実現するためにトランスパ
Rails 7.0ではフロントエンドサポートが刷新されます。新たなライブラリが多数導入され、選択肢が増えるため、「Rails公式のものを選べばOK」という戦略が通用しなくなります。 本稿では、Railsでフロントエンドを書くための選択肢について、その歴史と実装を踏まえて比較検討します。 結論から言うと(まだアルファ版なので今後も状況が変わる可能性はありますが、) 新規アプリケーションではSprocketsの役割は無くなりそうです。新しいライブラリとして Propshaft, importmap-rails, jsbundling-rails, cssbundling-rails が登場し、主要な選択肢として以下が提供されます。 (各ライブラリの詳細については後述します) Propshaft + importmap-railsデフォルトの選択肢。Node.jsが不要。トランスパイルを含め、複
はじめにlink 最近受けるNode.js + TypeScript環境の相談の中で、CommonJSやECMAScript Modulesのあたりで落とし穴にはまっている人が多いという事に気づいた。 Node.jsは歴史的にCommonJSとECMAScript Modules（以後ESMと表記）がどうしても入り乱れる環境にあり、これにTypeScriptのモジュールが加わると組み合わせでさらに複雑度が増すのが現状である。 説明する際に口頭より整理した文章が欲しいと思ったので記事にする。 以下のリポジトリで検証コードを管理している。 https://github.com/koh110/module_test Node.jsモジュールチェックシートlink まず最初にNode.jsにおけるCommonJSとESMの挙動について整理する。 いきなり書かれても把握できないかもしれないが、一旦こ
結合テストを書くときはコードベースを分離している
新規開発の設計支援や古いコードベースを甦らせて欲しいという相談をもらったときに、最初にちょろっとコードだけお手本的なコードを書いてから引き渡しているのだが、そのときに必ず結合テストを書くようにしている。 3, 4年前から僕と付き合いがある人からすると、 「「「あの sadnessOjisan がテストを書くだと！！！」」」 という感じだと思うのだが、最近はテストに思うところもあってちゃんと書いている。 そしてそのテストコードだが、基本的にはアプリケーションから分離して書いている。その話をしたい。 OGP OGP は野方ホープで海苔が分離されて出てきた時の画像だ。 アプリケーションから分離したテストとはどういうことか 最終的にはテスト対象のサーバーを Docker コンテナで固めて、そのコンテナに対して HTTP リクエストを投げてその結果や DB の中身を検証するコンテナを docker
Deno で 学ぶ React のサーバサイドレンダリング - 30歳からのプログラミング
Deno で React のサーバサイドレンダリング（以下、SSR）を実現する方法をハンズオン形式で書いていく。 自分が調べた範囲では、単に JSX で HTML を構築して終わり、という記事が多かった。それではあまり実用的ではないので、この記事ではハイドレーションまで行う。 また、React で SSR する方法を調べたところ、ほとんどの記事が Next.js を前提としていた。確かに Next.js を使わずに SSR するケースはあまりないだろうし、記事としても需要がないのだと思う。 しかし、Next.js のようなフレームワークが裏側で何をやってくれているのかを知ることで、SSR に対する理解を深めることができる。 事実、私は SSR をほとんど使ったことがなかったが、この記事を書くことでかなり考えを整理することができた。 Deno のバージョンは1.11.2で動作確認している。
textlint - Linterの作り方
[fit] textlint - Linterの作り方 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info Book: JavaScript Primer アジェンダ Linterを作る人向けの話 Linterの考え方とアーキテクチャを一致させる 使うものを作ろう、作るために使おう textlint とは 自然言語(日本語や英語など)に対するLinter MarkdownやHTMLなどのマークアップ言語に対応している ビルトインのルールは0 利用できるルールは100以上ある 多くのルールはオフラインで動くので、外部に入力してる内容を送信しない CI/CDに組み込める自然言語のチェッカー(表記揺れ、スペルチェック、誤用、読みやすさのチェックなど) textlint users Translation: Angul
jQuery 4.0.0 has been in the works for a long time, but it is now ready for a beta release! There’s a lot to cover, and the team is excited to see it released. We’ve got bug fixes, performance improvements, and some breaking changes. We removed support for IE<11 after all! Still, we expect disruption to be minimal. Many of the breaking changes are ones the team has wanted to make for years, but co
tl;dr はじめに 2024 年の 4 月 24 日に Node.js 22 がリリースされました。ESM を 条件付きで require する機能や、--run フラグによる npm スクリプトのパフォーマンス改善などが v22 で追加され、2009 年に Ryan Dahl が Node.js をリリースしてから 15 年が経つ今も、Node.js は進化を続けています[1]。 こうして Node.js 自身が強化されていくにつれ、以前はサードパーティーのパッケージを使用して実現することが一般的であった機能が Node.js のみで実現可能となり、当該パッケージが不要となるような場合があります。冒頭に引用した Ben Holmes の動画では、そのように不要となったパッケージとして dotenv node-fetch chalk mocha が挙げられていますが、この記事では「これら
No Bundle ツールの流行: vite / snowpack モダンブラウザは Native ESM を備えているので、開発時は高速な localhost アクセスを頼って直接 import する、外部ライブラリだけ事前にコンパイルしておく、という手法が流行ってきている。プロダクション用は今まで通りビルドする。 webpack はすべてを一つにバンドルするためにメモリ上にファイルの実体と依存グラフを持っているが、これによりメモリと CPU を圧迫する問題があった。特に巨大なリポジトリではそれが顕著になる。 No bundle ツールの実装として vite と snowpack がある。 https://github.com/vitejs/vite https://www.snowpack.dev/ vite は使ってみた限り、更新時の差分ビルドが爆速で、明らかに体感が良い。 Vue
TypeScript 4.7 で “module” という名前で始まる Compiler Option がさらに追加されて、さすがに何が何やら感あるので、役割を軽く整理。 この記事では雑な紹介に留めるので、それぞれの詳細は TSConfig Reference を読みに行ってください。 対応関係ソースコードとそれぞれのオプションが何に作用しているのかを雑に図示するとこんな感じ。 重要なことどのオプションをいじっても、import 指定子 (上図の “./hoge” の部分) がコンパイル時に書き換えられることはない。 これが頭に入っていれば、.mts, .cts といった TypeScript のファイルで import "./foo.cjs" と書くことや、 --moduleSuffixes がソースコードの探索にしか影響しないことに得心できるはず。 --moduleTypeScript
見つけた GitHub の Issue を片っ端から subscribe している - mizdra's blog
あるライブラリを使っていてバグっぽい挙動に遭遇した時、ほぼ必ず当該ライブラリの Issue を検索するようにしている。加えて、見つけた Issue の subscribe ボタンを押して、https://github.com/notifications に通知がいくようにしている。バグ遭遇時以外にも、何らかの理由で Issue に到達した時にその Issue を subscribe してる。 ハマったバグの Issue を見つけた時 欲しい機能の feature reuqest の Issue を見つけた時 例: Docker for Mac の VirtioFS 対応の Issue その他面白や動向をチェックしたい Issue を見つけた時 例: TS 4.7 のリリース計画について議論している Issue 例: Jest の ESM 対応の Meta Issue 例: ESLint の
2022/11/26(土)で開催された JSConf JP 2022に関する、現時点での公開資料と Twitter アカウントリンクをまとめました。 よろしければご活用ください。 ※2022/11/28追記 ねぎしさんからいただいたコメントを元に、各講演に時間指定をした YouTube リンクを追記しました。 （時間指定をすると流石に動画埋め込みはできないようだったので、リンクでご容赦ください🙏） はじめに 登壇者名は敬称略させていただいています。 Twitter アカウントについては、ご本人が当イベントで登壇されることに言及されている、スライドに記載など、確認できたものを記載しております。 リンクの間違い等ありましたらコメントいただけると助かります🙏 アーカイブ動画 当イベントは、3つのトラックに分かれて講演が行われました。 その3つともアーカイブ動画が残っているので、後から見直すこ
こんにちは！ラクスルの灰原です！ 軽量かつ高速なWebフレームワークであるHonoと、新進気鋭のJSランタイムであるDenoを使って、社内ツールを作ってみましたので紹介します。 作ったツール 技術スタック index.tsx の内容 Tips HonoでTwindを使う HonoのJSXでAlpine.jsを使う Hono+Denoでesbuildを使う おわりに 作ったツール テックブログ向けのアイキャッチ画像ジェネレータを作りました。 タイトルを入力して、 背景画像と文字色を選んで、 文字の位置と大きさを調整して、 後は「Download」ボタンを押せば画像が手に入ります。 これは以前、弊社デザイン組織で作られた「Zoom背景ジェネレータ」に多分に影響されています。 こちらのデザイナーブログも是非ご覧ください！ note.com 技術スタック このツールは利用頻度がそこまで多くないと思
Denoのフロントエンド開発の動向【2021年春】
はじめに ここ最近、Denoのフロントエンド向けのエコシステムについて、色々試してみたり、調査などをしていました。 そこで、この記事では、2021年現在のDenoのフロントエンド開発の状況であったり、所感などについてまとめます。 フレームワークについて Node.jsにおけるフロントエンド開発では、以下のフレームワーク[1]が使われることが多いと思います。 React Vue.js Preact これらのフレームワークは、すでにDenoでも動作します。 またこれらをベースにしたフレームワークがいくつか開発されています。 Aleph.js Aleph.jsはNext.jsに影響を受けたReactベースのフレームワークです。 以下のような機能が提供されています: HMRをサポートするdevサーバを提供 ファイルシステムベースのルーティング SSR/SSGをサポート CSS Modules 開発
サーバーサイドエンジニアがじっくり学ぶVue.jsチュートリアル【1. Installation】 | DevelopersIO
こんにちは。DA事業本部の春田です。 普段の業務では全く扱わないフロントエンドの世界に飛び込んでみたいと思います。最近3系が登場しましたがまだ情報が少ないので、2系のチュートリアルを進めていきます。サンドウィッチマンでいう「ちょっと何言ってるかわからない」ポイントは、その都度調べていきます。英語版の公式ドキュメントがベースです。 今回は、一番最初のInstallationです。 はじめに 互換性の注意 最初のセクションは「互換性の注意」についてです。ECMAScript 5とun-shimmableが、早速「ちょっと何言ってるかわからない」ポイントだったので調べてみました。 Vue.js uses ECMAScript 5 features that are un-shimmable in IE8 ECMAScript5は2009年にリリースされたJavaScriptの標準仕様のことで、プ
IE終了により、webpackやbabelを使う必要がなくなるのか、フロントエンドからビルドステップを完全に消し去ることはできるのか。 そもそもなぜフロントエンドを「ビルド」していたのか そもそもなぜwebpackやbabelを使ってJavaScriptをバンドル（1ファイルにまとめる）していたのか 1. HTTP/1.1とモジュールシステムの相性の悪さ ブラウザにはES Moduleというモジュールシステムが導入されています。これはimport文で他のファイルを読み込むことができるシステムです。 HTTP/1.1については、ブラウザ側で同時接続数制限があります。これは、ファイルを多数読み込む必要があるES Modulesには不向きでした。 2. ブラウザのES Module対応率の低さ ES ModulesはIE非対応です。開発するWebサイトがIEをターゲットにしたい場合、ES Mod
本記事で記述した Node.js ESM 対応は2022 年 5 月に TypeScript 4.7 で正式版としてリリースされました。 本記事の内容との差分はmodule:node12がmodule:node16に変更されたことぐらいです。node16では top-level await が使え、現時点ではnodenextとの差分はありません。 他に関連する機能としてresolution-modeや--moduleDetectionが追加されましたが、一般利用者が意識することはないでしょう。 先日リリースされた TypeScript 4.5 Beta で、待望の Node.js ESM 対応がアナウンスされました。 その後、ユーザーからのフィードバックを経て、TypeScript チームは TS 4.5（11/16 リリース予定）では ESM 対応を stable リリースせず、Nigh
Node.js Dual Packages (CommonJS/ES Modules) に対応した npm パッケージの開発 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。フロントエンドエキスパートの平野（@shisama_）です。 フロントエンドエキスパートチームでは業務時間の 30 % の時間で技術探究を行っています。 今回は探究した技術の中から Node.js の ES Modules（以下 ESM）についてと Dual Package (CommonJS/ES Modules) に対応した npm パッケージの開発について紹介します。 ES Modules の特徴 ESM はブラウザ互換 ESM は Strict モード ESM は非同期 ESM は静的解析可能 Node.js の ESM 対応について Dual Package（CJS/ESM）に対応した npm パッケージの開発 Conditional Exports によるファイルの指定 .mjs と .cjs require など CJS 特有の機能を使う ESMから CJS ファ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TypeScriptをプロダクト開発に使う上でのベストプラクティスと心得 - Qiita
Re: Rails を主戦場としている自分が今後学ぶべき技術について
2020年の11の必見のフロントエンドトレンド - Qiita
KDDIの通話・通信障害メモ - show log @yuyarin
JavaScriptのバンドルとトランスパイルが不要なモダンWebアプリ | POSTD
(自分の) JavaScript のユニットテストの書き方
Node.js の原罪 - from scratch
Webpack チャンク最適 テクニック - Qiita
Frontend Study #1: 基調講演 - Frontend 領域を再定義する
JavaScriptビルドツールの整理 各ツールの機能と依存関係
moment.js・day.js よりも速くて軽い cdate ライブラリ - Qiita
2021年のまとめ・反省 - mizchi's blog
Admin.jsを使って面倒な管理画面をサクッと作ろう | DevelopersIO
Rails 7.0正式リリース、Node.js不要のフロントエンド開発環境がデフォルトに
Rails 7.0でアセットパイプラインはどう変わるか | Wantedly Engineer Blog
Node.js + TypeScriptのモジュールを整理してみる
jQuery 4.0.0 BETA! | Official jQuery Blog
Node.js の進化に伴い不要となったかもしれないパッケージたち
Native ESM 時代のフロントエンドビルドツールの動向
TypeScript におけるモジュール関連オプションの整理
JSConf JP 2022 公開資料・Twitterリンクまとめ
HonoとDenoで社内ツールを作ってみた - RAKSUL TechBlog
IEが終了したので、webpackやbabelは不要？ - Qiita
TypeScript 4.5 以降で ESM 対応はどうなるのか？