はてなブックマーク

ゼロランタイムのミニマルな静的サイトジェネレーター『dodai』の開発と JSX First な世界観について2023/01/27 本記事では来たる2/3のKyoto.js #18に備え、年末年始に npm パッケージとして公開した『@potato4d/dodai』という静的サイトジェネレーター(以下SSG)について紹介します。なお、開発にあたって本ブログも @nuxt/content からこの dodai へと移行しています。移行作業の所要時間は 30 分程度でした。 @potato4d/dodai について dodai は 1~5 つ程度の固定ページと、Nつの動的なページを持つ Web サイトの構築を想定した静的サイトジェネレーターです。 元々は私が複数の Web サイトの管理で使っていた Node.js 用の Script 群をパッケージとしてまとめたものになります。 技術的には複数

Node.js での devServer の構築では初手 unjs/get-port-please の導入が便利2022/11/14 業務で複数の devServer を同時に立ち上げたいケースがあり、チーム内で「React.jsプロジェクト(APP_A)を起動してからNext.jsプロジェクト(APP_B)を起動するとNextが気を利かせてくれるが、Nextを起動してからReactだとポートが専有されていてエラーになっていて地味に不便」という声が上がっていた。 かねてから課題ではあったものの、それぞれ実装を進めることから、同時に立ち上げる機会がそこまで多くなくこれまで放置されていた。しかしそうは言っても不便ではあった中、get-port-please の存在を思い出したので試しに導入してみることにした。 結果として、好感触でなかなか良いライブラリだったので本記事で紹介したいと思う。 un

2022年にもなって HMR ではなく普通の Hot Reload を実装する機会に恵まれたので、現代的な API でできるだけローコストに実現してみることにしました。 重厚な JavaScript を使って Front-End を表現するわけではないため、実現したい機能はシンプルに以下に通りです。 監視対象となるファイルの内部をリアルタイムで監視し続ける 対象のファイルに変更が入ったとき、特定の処理を実装し、完了したらブラウザをリロードする 今回はファイル監視後に Node.js を利用してのビルド処理が挟まるため、 Node.js で実装します。 Hot Reload 用サーバー サーバー側の実装は、 Node.js 標準の http と chokidar で実装します。 Zero Dependencies のほうが取り回しは良いものの、 fs.watch はあまり優秀ではないため採用

これ僕らの物語であり、僕と君の物語であるかもしれない。 数日前、友人が言った。「久しぶりに Rails を書いたけれど、Node.js の良さに敵わない」と。 その言葉に同意しながらも、他方で少し不思議に思う。 いつから僕らは Node.js しか使わなくなったのか。あれだけ話していた Rails などの多くの Web 技術にときめかなくなったのか。と。 もちろん、使えないというわけではない。寧ろ今現役で十分な活躍をしているフロントエンドの人間は、等しく皆「主役であるバックエンドのサブとして存在するフロントエンド」を経験してきている。 書こうと思えば書ける。だがその中で、敢えてフロントエンドとその技術を選んできた。 だけど今はどうだろう。フロントエンドエンジニアはもはや「JavaScript を扱うソフトウェアエンジニア」となり、一般的なバックエンドは勿論、Node.jsが一級市民として存

早いものでLINE株式会社に入社して3年が経ちました。今日から勤務4年目となり、業界としてはそれなりに長く働いている側に足を突っ込んできた自覚があります。仕事もエンジニアからマネージャーになり、役割も変わってきたところ。 現職でまだやりたいこともあるだけでなく、明確にバリューを出せていて組織からも評価されている現状、しばらく転職する予定はないのですが、一方で、私は常に他の選択肢がないかを探し続けています。 そして一緒に働く同僚やチームメンバーには語弊を恐れずに言えば「常に転職活動をしながら仕事をしてほしい」と思っています。 現職についてのエントリに興味がある人はそう多くないと思うので、3年目が終わった節目として、今日は市場を見て仕事をすることの重要性について書き記すことにしました。 自社に満足しているときほど、外部の働き方を知る必要がある 「あなたは今の仕事に満足していますか？」と聞かれた

先日の ua-parse-js のハイジャックの件 を受けて、業務の中で毎日動かしている On-premise Renovate の cron を土日祝に停止させたいという話が上がった。 業務の合間に書く時間がちょっと捻出できそうになかったこと、加えて汎用的なコードということもあり、プライベートでも使えそうだったので一般化した範囲でコードを書いてしまって、業務で社内用に調整する形で決着させたので、せっかくなので共有しておく。 社内が基本的に CircleCI なので特化したものと、一般的に使えるものでバリエーションごとに2つのパターンを用意した。 祝日に停止させるアプローチ ひとまず今回は内製の Bot の運用のため、以下のような特徴があった。 土日の設定自体は cron で曜日指定ができるため祝日にフォーカスして良い 厳密性を重視しない ミッションクリティカルな領域の話ではない 以上を考

(以下、本文における「エンジニア」はすべてソフトウェアエンジニアのことを指します。) 私はエンジニアが所属組織の採用イベントに出演することにはかなりポジティブな作用があると考えています。もちろんそれには明確な理由があるのですが、それがなぜなのかをアウトプットしてこなかったので、試しに書き連ねてみることにしました。 なお、採用に関する情報をオープンにしない組織も非常に多く存在するため、あくまでも閉じた範囲に限定せずオープンにしている組織のことを前提とします。 採用イベントと技術イベントについて 「採用イベント」と一口に言っても、エンジニア向けの催しには直接的な採用へのコミットを意識したイベントと、中長期的を見据えての接触機会の増加や組織のブランディングを重要とした技術イベントの２つがあります。 前者は採用説明会などと呼ばれることが多く、後者は Meetup や Tech Talk などの名称

Stencil でつくられた Custom Element を React/TypeScript 環境から呼び出したい2020/09/16 会社で Stencil で作られた Web Component の NPM パッケージが OSS として公開されていて、Vue.js のアプリケーションではこれまでも利用していたけれど、React でも利用したくなった。が、やってみるとドキュメント以上の工夫が必要だったのでメモ。 ちなみに使ったものは @uit/glitch-image というパッケージ。 一応免責として 2020/09/16 時点での公式ドキュメントにない範囲のハマりであり、連休にでもドキュメントに Pull Request でも送ろうかな。と思っているので、割とすぐに outdated な情報になるかもしれません。 Stencil の吐き出す Custom Elements と型定

rehype-plugin-auto-resolve-layout-shift を利用した Markdown ドキュメントにおける Layout Shift の解消2021/02/22 このブログは @nuxt/content で運用しており、執筆環境としては非常に快適に利用できている一方で、Markdown ベースの宿命として、Markdown 記法で画像を貼り付けている限り Layout Shift が発生するという課題が存在していました。 暫定的な対処としてしばらく <img> で置き換えてきましたが、根本的に対処するため、連休を活かして rehype-plugin-auto-resolve-layout-shift を開発しました。 この記事では、かんたんにその報告と紹介をしたいと思います。 Markdown の Layout Shift について Markdown は # で h

2020 年は一般的なソフトウェアエンジニア。というよりは少し経路が違う仕事を主にやっていたので、良い機会なのでまとめようと思います。 やったこととしては多岐に渡って価値を発揮できたかなと思う一方、心情的にはしっくりこない一年でした。 要約 業務内容だけ見たい人は実際の業務についてへ 採用ブランディング/DX改善/コミュニティ活動などを行うチームを設立し、回していた それと並行して、採用活動や選考フローの改善、LINE DEV DAY 2020 Frontend の管理を行った 来年はまた事業側の仕事をやっていくつもりである 出来事 先に今年は大きな出来事が2つあったので、その変遷を紹介します。 Front-End Advocates TF を立ち上げた 今年の 3 月に Front-End Advocates TF という Task Force(以下 TF) を社内で設立しており、それの

採用技術問わずWebサイトに設置できるソーシャルシェアボタンを Web Component として開発する2020/12/08 先日、「”地上最強”のエンジニア向け情報サービス」を謳うTechFeed Proが新規アップデート。様々な機能追加がなされ、更に多くの情報収集が可能となりました。 今回はそんな TechFeed のアップデートで追加された URL 共有機能の導線として、 techfeed-share-button パッケージを OSS として公開した記録を紹介します。 本記事では、 依存側の技術要件が不明または多岐に渡るケースの選択肢としての Custom Elements NPM パッケージとして提供と CDN SDK としての提供の両立 あたりの情報について紹介できればと思います。 ※ TechFeed との関係性について TechFeed Pro については構想段階で相談を

年の瀬なので、私自身が今年利用した技術をベースに技術スタックをまとめてみようと思います。 とはいえ Web Standard といった広い対象から、フレームワークやライブラリまで、粒度の違うものを全て言及するのは無理があるというもの。特に強く言及できるものは個別で説明しつつ、最後に利用する機会がなかったものも最後に記載する形で。 以下常体。 追記: マイナー企業のようなので一応書いておきますが、筆者は本業ではLINE株式会社という組織でいわゆるエンジニアリングマネージャーと言われるような業務とその採用に関わる仕事をしています。 利用した技術一覧 HTML/CSS/JS みたいなことを書いてるとキリがないので、独断と偏見で区分けして適宜漉いています。特に利用する機会が多かったものは太字でピックアップ。 Frontend Language/Platform TypeScript JavaScr

LitElement を利用した Custom Element の開発をしていて、 enzyme や vue-test-utils のようなコンポーネントのテストを記述したい。 ただ Custom Element 開発はブラウザの文脈に依存するものが非常に多く、Open WC などがツールを出しているみたいだけれど、ちょっとしたコードを書くには1からキャッチアップするのも大変。ということで、 Cypress で End-to-End でテスティングすることにした。 Jest + Puppeteer で自作しても良かったけれど、Shadow DOM にうまくアクセスする方法を持ち合わせていなかったので、試しも兼ねてというところ。 ローカルで一通り動いたので、CI に載せたくなったのは良いものの setup が少しクセがあったのでまとめておく。 GitHub Actions で動作させるために

サーバーサイドのテンプレートエンジンと Vue.js が混在しているプロジェクトを経験したことがある人には馴染み深い(?) Vue の delimiters オプションですが、Vue 3 になってからコンポーネント単位で設定できるようになっていました。 仕事で Nuxt.js の app.html の仕様の説明ついでに、 mustache 記法について説明を行った際に書いた Vue 3 サンプルで初めて気づいたので、メモ程度に残しておきます。 ちなみに Nuxt.js の app.html のテンプレート機能は lodash/template で実現しているみたいです。 delimiters とその挙動について 以下のサンプルコードとその挙動をみると割と簡単にイメージがつくと思います。パっとイメージがつかない場合、 delimiters の部分をコメントアウトしたり、またコメントアウトを解

9/25(金)に Moment.js の送別会を YouTube Live / Discord で行いました。フロントエンドから卒業することになった Moment.js の思い出と、今使っている時刻操作ライブラリなどについて語る会となります。 この時点では特に何も決めておらず、オフィシャルに言及されている Day.js や date-fns、 Luxon の話を交えつつ、 Temporal の話題などができると良いなくらいの気持ちでいました。 しかし、なんだかんだ話題が広がって最終的に同時に Discord で議論に参加してくれていたメンバーが 10 人程度いるなど、かなりの大所帯になったのは良い意味で予想外なイベントとなりました。 イベント本編について その場の流れで決まった企画ではありますが、イベントはイベント。せっかくなので、送別会として、これまでとこれからの話をゆるーくすることにし

JavaScript での時刻操作に Moment.js ではなく Day.js を利用し続けている理由2020/09/21 昨日、拙作の Nuxt.js プラグインである @nuxtjs/dayjs の v1.2.0 をリリースしました。 このプラグイン自体は2019年3月に開発をはじめて、おおよそ一年半ほど管理してるのですが、それ以前から JavaScript での時刻操作では Day.js を使ってきました。 Moment.js のプロジェクト終了が告知され、時刻操作ライブラリに注目が集まっていることなので、今一度 Day.js の採用理由についてまとめてみます。 Day.js について iamkun によって開発されている時刻操作のライブラリです。Moment や date-fns などは Organization によって管理されていますが、時刻操作ライブラリとしては珍しく個人に

Conventional Commits にも参照がある chore や doc 形式のコミットメッセージが、standard-version でリリースノートに含まれないことが不満に思っていたけれど、昨日ようやくカスタマイズ方法を知ったので残しておきます。 結論 とりあえず楽したい人はプロジェクトルートに .versionrc.js の名前で以下を配置しておくと全て解決します。 module.exports = { preset: require.resolve('conventional-changelog-conventionalcommits'), types: [ { type: 'feat', section: 'Features' }, { type: 'fix', section: 'Bug Fixes' }, { type: 'chore', section: 'Chor

rehype-plugin-image-native-lazy-loading を NPM package として公開した2020/09/19 9/2 に書いた記事で紹介した、 nuxt/content で Markdown 内の画像に Native Lazy-Loading をつけるコードに需要がありそうだったので、rehype plugin としてそのまま切り出しました。 既にこのブログの lazy-loading の付与ロジックは該当パッケージに差し替わっています。 https://github.com/potato4d/rehype-plugin-image-native-lazy-loading ネイティブの lazy-loading のサポートブラウザについて iOS Safari を除く全てのブラウザで動作します。 また、loading attribute については、存在し

結論: Gyazo API のアップロードは Content-Type が不要だがなぜか fileName については暗黙的に要求する 以前の記事でも話した通り、私はパーマネントな画像をすぐに展開できるストレージとして日常的に Gyazo を使っています。 日常的なスクリーンショットでは Gyazo の Desktop App で事足りていたのですが、ちょっと個人的な用事で Bot に画像を添付したいモチベーションが出てきて。 Bot 自体はステートレスに管理したく、また投稿先も Slack なのか何なのかまだ決めていないのもあって、とりあえず Node.js から Gyazo API を叩いてアップロードすることにしました。 ただ5分くらいで終わるかと思ったら、なんやかんや 20 分くらいかかってしまったのでハマりメモとして残しておきます。 Gyazo API について Gyazo には

2020/09/13 追記 「GitHub Actions の規約違反では？」というコメントがありましたが、追記時点の規約では特別禁止されていません。 https://docs.github.com/ja/github/site-policy/github-additional-product-terms#a-actions-usage 唯一グレーラインに相当する可能性のある『サーバーレスコンピューティング』も日本語訳に残っているだけものであり、英語の原文からは既に削除されている項目のため、問題ない利用方法となります。 昔は cron といえば Heroku と Heroku Scheduler だったけれど、Heroku Scheduler が遅延するようになってから、自分用の定刻バッチを楽に動かせる手段がなくてしばらく困っていたり。 しっかりとしたプロジェクトを作成する場合なんかは F

nuxt/content で作成した Web サイトで Markdown 内の画像を Native Lazy-loading を行う2020/09/02 普段ブログや技術メモを書くとき、お手軽な画像ホスティングとして Gyazo を利用していたりします。 Patreon を開設していた頃に OSS の README に貼る GIF をサクッと取りたいという動機で Gyazo Pro を契約後、もう2,3年 Pro を継続。画像アセットの管理が結構面倒なのもあって、無限に使えてちゃんとホスティングされることが担保されていることから、このブログでも画像は全て Gyazo に載せていたり。 あと個人的に増井さんのファンなのもあって、長らく愛用しています。 Gyazo 自体は便利で愛用している一方、無計画にスクショを撮って Copy Markdown Snippet をし続けると当たり前にサイトが

自明だと思っていたけれど、割と見かけるので。 Factory 関数やそれに相当するようなものは、得てして作成時点、あるいは将来的にかなりのオプションを取る可能性があります。 例えば HTTP クライアント。 初期開発では環境変数で切り替えられる baseURL の設定があるだけで良かったものが、場合に応じて Authorization Header が必要であったり不要であったり、何かしらの nonce を付与したかったり、 Content-Type が 'application/json' ではなかったりするケースに直面する。というのは、 SPA を開発しているとよくあるシチュエーションではないでしょうか。 こういったときに、引数が 2,3 のときに妥協して createAPIClient(baseUrl: string, token?: string) みたいな作り方をしてしまっている