控えめな App Router と持続可能な開発 - PWA Night vol.59
PWA Night vol.59 ～フロントエンド設計の振り返り〜 (2024.01.17) https://pwanight.connpass.com/event/306410/ で使用したスライドです。本編 20 分。 ===== ▼ 元データで参考リンクとして張っていた URL たち ※ SpeakerDeck でダウンロードできる PDF はスライド中のリンクが有効です Offers「オファーズ」 - エンジニア、PM、デザイナーの副業・転職採用サービス プロダクト開発組織/エンジニアリング組織のマネジメント・パフォーマンス最大化 | Offers MGR（オファーズマネージャー） turbo/examples/basic at main · vercel/turbo Web フロントエンドの推しディレクトリ構成と Next.js App Router なコードベース | Offe
ブログをAstroに移行した
ブログを Astro に移行した Astro とは Astro の公式サイトの説明を見てもらうのが早いかもしれない Astro is an all-in-one web framework for buildingfast, content-focusedwebsites. コンテンツ主体のウェブサイトを高速に作れるオールインワンウェブフレームワーク、という説明だが実際使ってみた感じ概ね合っていると思う. 特徴的なのが Astro で採用している Island Architecture と呼ばれるアーキテクチャで、UI の各コンポーネントを Island (島）のように見立ててそれぞれ独立したマイクロフロントエンドのように扱うことが出来る構成になっていること。 完全に Static な HTML とレンダリング後に Hydration (静的な HTML に後からイベントハンドラを設定)し
当ブログを GatsbyJS で作り直した
式年遷宮です。54. YATTEIKI の本が商業書籍化決定！ そして Coinhive の話 でも少し話題にしたのですが、元気を出したいときはブログを作るのがよくて、定期的にブログを作っています。思い返してみると、この習慣はプログラミングをしたことがないような頃からありました。それこそガラケーでHTMLタグ打ってたような時から。その時代にできる一番テンションの上がるスタックでブログを組むというのが楽しい。 まずはデザイン含め Rails で組んでいたブログの構造をそのまま GatsbyJS に移行するというところからはじめました。見た目変わっていないので、以前から知っていた人は違いに気づかないレベルかと思います。ちょくちょく改良を加えていきたい。 GatsbyJS GatsbyeJSというのは React 製の速度に特化した静的サイトジェネレーターです。自分のフロントエンドスタックとして
JavaScript無効時代
一週間JavaScript無効で過ごしたけどすごく良かったという記事を読んだ。大雑把な感想を言うとするとそりゃそうだろと言えるような内容であり、特に面白みはない。しかし広告に特に触れずにFSFと絡めて説明するのは比較的珍しかったので、興味深くはあった。 この種の問題にはプライバシーということがとかく強調されるが、対価が見合っているかいないかという側面も持つ。適切な対価があるのならプライバシーに属する情報を提供しても良いと考える人は少なからずいるだろう。僕は比較的そういう傾向が強い。 例えばこのウェブサイトであるならば、Analytics経由で提供することになるデータはコンテンツの提供に対してそれなりに見合っているはずだ(よね？)。ただしAdSenseとなると広告配信者が一方的に得をしていると考えられ、僕もユーザーも少し損をしていると見ることもできる(けれど外すつもりはあまりない)。 対価以
ブログの脱WordPressとJamstack化 | 初歩からの無職
このブログをWordPressからJamstack構成にしました。具体的にはフロントエンドはGatsbyJS、バックエンドはContentful、GithubでビルドしてNetlifyでホスティングしているという構成です。まだ細かい部分は作れてないですが、ある程度移行は完了したので移行に関する備忘録として残しておきます。 移行のモチベーション サーバー代つらたん 移行のモチベーションの大きな部分として、放置気味のブログに対してサーバー代が割りに合わないという不満がありました。移行前はConoHa VPSにWordPressをインストールして運用していました。VPSサーバー代はサーバーサイドの勉強代として自分を納得させていましたが、Kusanagi環境に移行してからは自分で弄ることもほぼほぼなくなり、世の中も何となくサーバーレスイケイケな雰囲気を出しているので、徐々にこのまま払い続ける意味は
「Webアプリ」の解釈が広すぎる話 - ジンジャー研究室
最近Webフレームワーク周りで無駄に摩擦が生まれてるなー、と思うことを詩的に書いてみる。 そもそも何が作りたいのか 古くはjQueryから始まって、最近だとReact(+Redux)とかAngular2とか色々あるわけだけれども、そもそもそれらを使って作ろうとしてるものはみんな一緒なの？っていうのがあって、色んな話を聞いているとかみ合ってない感がすごい。以下の分類は別に細かくちゃんと定義しましょうとか言っているわけではなくて、「例えばこういうのがあるんじゃないの？」という一例。いま自分が関わっているのは主に３と４なので、その他で間違ってたら指摘して欲しいんだけど、この前提を共有していないために「複雑すぎる」とか言ってるんじゃないかという仮説がある。 1.Webサイト 基本的に静的なWebサイトで画面遷移するんだけど、ところどころ動きがあったりするのでフレームワークが必要。SEOが重要なので
Next.js + Tailwind UI を使うとたった6時間で技術ブログのプロトタイプを作れる - パンダのプログラミングブログ
Gatsby から Next.js に載せ替えた動機 本ブログを Next.js でリニューアルしました。 元々このブログは Gatsby で作っており、2019年3月にリリースしましたが（最初の投稿）、ついに Next.js に移行しました。移行のモチベーションはバージョン追従を避けたこと、デザインを一新したいこと、また記事が表示されないというバグが発生する事象があったことです。 まず Gatsby のバージョンアップについて。現在、Gatsby の最新バージョンが4系です。しかし、自分が使っていたテンプレートは3年前に1系から使い始めて、2年前に2系にバージョンアップしました。その後、自分は業務と個人開発で Next.js を使い始めたため、このブログでしか使っていなかった Gatsby の情報を追うのを止めて、記事だけ追加する運用をしていました。 その頃にはバージョンアップをするより
Nuxt.js × Atomic Designのサービスデザインフロー
2019/6/1 初夏のJavaScript祭りで使用したスライドです。 Atomic Designの考え方をNuxt.jsのコンポーネント分割に取り入れてサービス開発してみました。フロントエンドエンジニア、デザイナー両面からの視点でやってみて良かったことやハマりどころをご紹介します。
Web における技術の解釈とエコシステムによる合意形成プロセスについて | blog.jxck.io
Intro 「ユーザが意図する挙動」とは何か。技術的に可能であるが「やらない方が良いこと」は、誰がどう決めるのか。 Web には仕様、実装、デプロイ、そしてユーザの利用とフィードバックによって、そうした合意がゆるやかに形成されていく仕組みがあると筆者は考えている。 しかし、これは明文化されているわけでもなく、その全体像を把握するのは一般には難しいだろう。 今回は、ちょうど何度目かの議論が再発している ping 属性を例に、この合意形成の概観について解説を試みる。 リンクの ping 属性 <a> には ping という属性があり、以下のように URL を指定する。 <a href=https:example.com ping=/path/to/report>example.com</a> HTML Standard - ping Attribute このリンクは、クリックすると https
RESTが日本で受け入れられていった頃の話( #mozaicfm の補足) | 栗林健太郎
mozaic.fm第7話のRESTの話で、RESTが日本で広く受け入れられていった頃、というか、その端緒の頃の話が出ていて懐かしかったのだし、細部にやや不正確なところがあるのが気になったりもしたので、補足を書いておきますね。 まず、いわずとしれた@yoheiさんがRESTをまず知ったのが2003年とかそれぐらいの時期とおっしゃっていて、それから数年経ち、RESTがWebエンジニアに広く受け入れられていったのは、2007年末にリリースされ、resourcesという機能を取り入れたRails2からというのは、@t_wadaさんがおっしゃっている通り、事実だろうと思います。 また、Podcastの中では、主催のJxckさんが、それはそれと認めた上で、彼自身にとってはAjaxの登場が大きかったということを述べた上で、@yoheiさんの主催された第八回XML開発者の日での高橋征義さんとid:seco
React + Apollo Client (GraphQL) により変化するアプリケーション設計
Node 学園祭2018のトークで使用したスライドです。 https://nodefest.jp/2018/schedule.html#conference-5-8
Nuxt.jsとGraphQLから見えたWeb開発の未来
Challenging Assumptions About LCP Best Practices (with data!)
HTML5で実現できる！環境光に合わせたレスポンシブなUI
HTML5で実現できる！環境光に合わせたレスポンシブなUI Tomomi Imura（Slack） フロントエンド開発やデザインに携っている皆さんにとって、ここ数年間「レスポンシブ・ウェブ」についての話題は避けて通れないものとなっているでしょう。モバイルやタブレット上でも、ユーザー・エクスペリエンスを失うことのないウェブを表現するには、CSS3 Media-queriesが欠かせないものとなってきました。 それでは実際、レスポンシブ・ウェブとは何についての対応（レスポンシブ）なのでしょうか。 現在のところ、私たちがいうレスポンシブ・ウェブデザインとは、どんなスクリーンの幅や表示領域、デバイスの画面解像度や画面の縦横の向きにも対応したウェブデザイン、というのが事実上の定義となっているようです。 そこで今回、私はその定義を超えたレスポンシブ・ウェブのユースケースについて考えてみました。 太陽光
GatsbyJSでポートフォリオをつくった
追記: GatsbyJS@2 以前の古い記事です。最新のチュートリアルはこちら 以前 neet.love というハローワークの対義語みたいなドメインを購入したのですが，こんなクソみたいなドメインに使い道なんてあるわけもなく，あろうことかスクワッティング状態になってしまっていたのでポートフォリオを作ります．求職してなさそうですね． MediumのReactタグで「GatsbyJSでポートフォリオ作ったで」というような記事を拝見したので今回はGatsbyJSを採用します．（どの記事だったかは忘れました） GatsbyJS is 何GatsbyJS（ギャッツビージェイエス）は，React用の 静的サイトジェネレーター です．「静的サイト」というのは与えられるパラメータによって情報が変化したりしない純粋なHTMLページのことですね． 類似プロジェクトとしてGitHub Pagesでよく用いられてい
ヘッドレスブラウザ Chrome + Chromy で操作した内容を録画する
Chromeのブラウザ内（もしくはデスクトップ）操作をJavaScriptで録画するに続いて、今度はヘッドレスブラウザ (Chrome) で操作した内容をビデオ録画する方法を紹介します。今回は Chromy というライブラリを利用します。 機能的には Chrome DevTool に用意されている startScreencast を利用します。Chrome ヘッドレスブラウザのライブラリといえば puppeteer という感じがあるのですが、 Chromy は startScreencast のラッパーを用意してくれているので、サクッと使えるのが良いところです。 サンプルコード 指定のページを開いて startScreencast をした後、なんらかの操作をします。その後、 stopScreencast で処理を終了すると startScreencast コールバックで受け取ったキャプチャ
CSS Paint APIでJavaScriptからCSS用のグラフィックを動的に生成する
Houdiniというプロジェクトをご存知ですか？HoudiniはJavaScirptからアクセスできるCSSの機能を広げ、プログラマブルなCSSを実現するためのものです。Houdiniが実現すれば、まるでハリー・フーディーニのように物事を自在に操れるようになること間違いなしです！ そんなHoudiniの中で、CSS Paint API（CSS Painting API）がChrome 65で実装予定です。 CSS Paint APIを使って、ブラウザの上の魔術であるHoudiniを体験してみましょう。 CSS Paint APIは、CSSで用いる画像をJavaScriptから動的に生成するためのAPIです。生成した画像は、background-imageやborder-imageで利用可能です。今までcanvas要素で無理やり実現していた複雑な背景なども、CSSの枠組みの中で実現することが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドで作る理由
Yuki Uehara | Profile page
フロントエンドにおける「関心の分離」は間違っていた - fsubal
Vue CLI UIが想像以上に便利だった話 - Qiita
