Git と GitHub の次を妄想する
GitHub みたいなサービスを今一から作るならどの言語・フレームワークを使うか GitHub の次は何かを考えてみるのは、現実に実現困難なのを忘れれば、なかなかに楽しいことではあります。ここではその妄想をやっていきましょう。 GitHub の抱える課題を分割すると、Git の問題と、 GitHub の提供する機能の問題に分けられると思います。自分は、Git をベースとして GitHub に勝つのは現代ではなかなか難しいと考えています。MS による買収と実際に注ぎ込まれてる資本を考えると、よほど斬新な切り口でないと、 同じ Git を使っても優位性は出せません。 なので、 GitHub に本質的に勝つには、その基幹となる VCS から考え直すとよいのではないか、と考えています。幸いなことに(?)、Git はその優秀さは認められていますが、学習の困難さや特定のユースケースで機能しないことが知
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
Next.js API Route の実装時に同じファイルでクライアントコードも実装すると嬉しい…
tl;dr API Route でクライアント用のコードも一緒に実装すると型安全に実装しやすい ただしセキュリティは気をつけてね 発想 Next.js から Prisma ORM を利用する という記事で、 Next.js の getServerSideProps で prisma のコードを使う例を紹介しました。 これは pages というユニバーサルなエンドポイントで、クライアントとサーバー用のコードを両方記述しています。 import type { GetServerSideProps } from "next"; import prisma from "../lib/prisma"; type Props = { count: number; }; export const getServerSideProps: GetServerSideProps<Props> = async
React Server Component の Isomorphism について解説する
Next.js + React Server Component のリファレンス実装が出たので、手元で動かしながら理解したメモ。 vercel/next-server-components: Experimental demo of React Server Components with Next.js. Deployed serverlessly on Vercel. これを書いてるモチベーションとして、Twitter を見る限り React Server Component のことを 「ただのサーバーサイドへの先祖返り」とか「SSR 結果を dangerouslySetInnerHtml してるだけでは？」みたいな反応があったので、そのへんの誤解を解きたい。 Introducing Zero-Bundle-Size React Server Components – React Bl
サードパーティスクリプトの極限環境向け Svelte
この記事は、 Svelte Advent Calendar 2020 - Qiita の 22 日目です。 昨今では、フロントエンドの JS を減らす圧が強くなってきています。とくに来年 4 月に導入される Core WebVital は SEO に関わるため、 マーケティング文脈でもフロントエンドの改善施策として、パフォーマンスを上げる圧が強くなっています。 Google の UX 指標「Core Web Vitals（コアウェブバイタル）」とは？LCP・FID・CLS を解説｜ ferret JavaScript よ。文明を捨て、自然に還れ。 ::ハブろぐ で、ユーザー体験を遅くするものとしてやり玉に上げられるのが、サードパーティスクリプトという、サイト外から読み込まれる第三者の script です。代表的なものが Google Tag Manager や Twitter や Face
Re: Rails を主戦場としている自分が今後学ぶべき技術について
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
2021年 は Fullstack Next.js 元年なので、有望な Next.js 系フレームワークを全部試した
この記事は、Next.js Advent Calendar 2020 の6日目。 突然だが、2021年 は Fullstack Next.js 元年になる。 その理由として自分は以下のものがあると思っている。 ベストプラクティスとしての TypeScript のデファクト化 Next.js の Dynamic Routes による動的パス、 getStaticProps/getServerSideProps による使い勝手の向上 Vercel によるISRの発明 prisma の成熟 Vercel / Serverless / Cloudflare Workers / Cloudrun 等による Node.js サーバーの運用コスト減 参考: Frontend Study #1: 基調講演 - Frontend 領域を再定義する Blog - Next.js 9.3 | Next.js R
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法
プログラミング初心者のための JavaScript と Node.js の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js（ただし暫く何も足さない）がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ
Frontend Study #1: 基調講演 - Frontend 領域を再定義する
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
blitz-js prisma rails 倒し方
この記事の内容 blitz-js が生まれた背景 prisma の紹介 blitz で簡単なブログを作ってみる blitz を vercel にデプロイしてみる tldr blitz-js は next.js + prisma で rails を再現しようとしているフレームワーク Prisma ORM それ自体が良い。blitz の理解のためにも、まず Prisma を学べ blitz-js 自体はまだ α 品質だけど、今から注目しておく価値はある。デファクトになるかは不明。思想は継承されそう。 はじめに next.js はとても良いフレームワークだが、永続層を持たない。なのでフロントエンドとフロントサーバーに閉じている。 永続層、つまり DB を持たないので、初学者や流行りのプログラミングスクールの教材に選ばれない。また、JavaScript の学習資料が散らばっている。 要は Rail
有料記事の技術ライターで食っていけるか
2020年版: なぜ仮想 DOM / 宣言的 UI という概念が、あのときの俺達の魂を震えさせたのか | Zenn という記事を500円で販売しました。その経緯と現時点での結果について。 なぜ書いたか Qiita の開発から離れて久しいのですが、 もし Qiita で有料記事を出せたらどういう体験になるんだろう、というのは当時からずっと考えていました。 zenn に搭載された Qiita にはない機能を使うことで、それを感じてみたかった、というのが一番の理由です。 優れたプログラマ、そして優れた書き手には相応の対価があるべきです。 オープンなコミュニティでは、それが称賛や承認となって返ってきますが、人間はそれだけでは生きていけません。 今までのエンジニア界隈では伝統的にオープンなコミュニティで稼いだ名声を使って、良い企業への転職で高い給与をもらう、というのが今までの実質的な「稼ぎ方」でした
2020年版: なぜ仮想 DOM / 宣言的 UI という概念が、あのときの俺達の魂を震えさせたのか
本記事は、 「なぜ仮想 DOM という概念が俺達の魂を震えさせるのか」 https://qiita.com/mizchi/items/4d25bc26def1719d52e6 の 2020 年版のリライトです。 2014 年当時、日本においては React は未だ知る人ぞ知るライブラリ、という位置づけでした。それが、この記事によって一気にメジャーになったように思います。 オリジナルは2014 年末の情報によって書かれたもので、さすがに 6 年経った今では情報が古くなっており、当時の暗黙のコンテキスト、古いリソースの参照、初学者の混乱を招く表現が残ったままになってしまっています。 定期的に更新しようとも思いましたが、そうすると 2014 年末の歴史的な背景を失ってしまうため、あえてそのまま残し、新しい記事を投稿することにしました。増補改訂版というより、ほぼ書き直しです。 この記事は本来なら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Next.js から Prisma ORM を利用する
