控えめな 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
ちょっと見てて面白かったので : As Sloth As Possible
なんか金縛りにあって眠れなくなったのでTwitter見てたら面白いやりとりをみかけた。すげー大雑把に要約すると、こんな感じ。 Railsの勉強をしてる人が「なんでHello worldしたいだけなのにDB必要なの！？DB使うにしたってMySQLなんか今必要じゃないしチュートリアルではSQLiteとかにしといてくれたっていいのに！プリプリ！」みたいな呟きをする 「いやRails使うんなら普通DB要るでしょ。なんでそこに文句言ってるの。」とツッコミが入る 「とりあえずチュートリアルは一番簡単なやり方書いといてくれた方が親切じゃないですか。」と反論 「いやだから、Railsを使うのに一番当たり前の構成を作るのにはどうしたらいいかがチュートリアルでしょ。それが必要ないんなら別なの、例えばSinatraとか使えばいいじゃん。フレームワークの特性も分からずに使っておいてチュートリアルがおかしいとか筋違
ブログを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 製の速度に特化した静的サイトジェネレーターです。自分のフロントエンドスタックとして
ブログを書くためのブログ記事（RWordPress and knter）
アドカレにエントリーでもしないと，わざわざブログ書いたりしないよねー，な毎日を送っておりました。実際いまアドカレの記事に追われていると言う謎の執筆環境にあります。 ところで私のサイトは，コードや数式を入れることがたまにあります。 サイトはWordpressで運用しているんですが，コードや数式が含まれるような奴は基本，RStudioで書いているのです。 RStudioのRmdで書いて，それをアップロードするのもRのコード。パッケージRWordPressを使えば，Rmdをうまくknitしてアップしてくれちゃう。 使い方はこんな感じ。 library(RWordPress) library(knitr) options(WordPressLogin = c(yourID = 'your pass'), WordPressURL = ...your URL.../wp/xmlrpc.php') o
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が重要なので
Rust+ActixWeb+DieselでRealworldプロジェクトを登録した話
Rust+ActixWeb+Diesel で Realworld プロジェクトを登録した話 ども、Nash です。 この記事は、学習用に作成した Rust による Realworld プロジェクトが完成して公式に登録されたので、そこまでに学んだことなどをまとめた記事です。 はじまり 仕事ではフロントエンド寄りのフルスタックエンジニアとして働いているのですが、前々から Rust が好きで個人的に学習していました。 その一環として Realworld プロジェクトに ActixWeb のプロジェクトが登録されていないことに気付いたので、いい機会なので自分で作成して登録してもらうところまでを目標にプロジェクトを作ってみました。 Realworld プロジェクトとは GitHub - gothinkster/realworld: “The mother of all demo apps” — Ex
2005～2009年あたりのWeb開発がどんなのだったか - Crieit
現在Web開発といえばバックエンドであればRuby, PHP, Python, Node, Elixir等、フロントであればReact, Vue, Angular等を自由に選び、インフラもHeroku, Firebaseやその他サーバーレス構成で無料運用など選んで使え、バラエティに富んだ方法で自分の個性にあったものを使い楽しく行うことができる。 でも、2005～2009年頃はそうではなかった。ふと思い出したので色々調べつつ色々書き出してみる。（個人の知識をベースにした内容のため、知らない部分を含めると間違っている部分もあるかもしれない。また各年の記述はWikipediaでざっと調べたので違ってる可能性もあるかも知れない） プログラミング言語 確かWeb界隈で主に使われていたのはJava, PHP, Perl, Ruby, JavaScriptだったと思う。会社での業務でどうだったかは知らな
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!)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
フロントエンドで作る理由
Yuki Uehara | Profile page
フロントエンドにおける「関心の分離」は間違っていた - fsubal
Perl ウェブ開発の中世〜CGI と Plack の間〜
