GitHub みたいなサービスを今一から作るならどの言語・フレームワークを使うか GitHub の次は何かを考えてみるのは、現実に実現困難なのを忘れれば、なかなかに楽しいことではあります。ここではその妄想をやっていきましょう。 GitHub の抱える課題を分割すると、Git の問題と、 GitHub の提供する機能の問題に分けられると思います。自分は、Git をベースとして GitHub に勝つのは現代ではなかなか難しいと考えています。MS による買収と実際に注ぎ込まれてる資本を考えると、よほど斬新な切り口でないと、 同じ Git を使っても優位性は出せません。 なので、 GitHub に本質的に勝つには、その基幹となる VCS から考え直すとよいのではないか、と考えています。幸いなことに(?)、Git はその優秀さは認められていますが、学習の困難さや特定のユースケースで機能しないことが知

オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer

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

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

Next.js に Prisma ORM を導入する方法について解説します。 Next.js プロジェクトの雛形を作成 $ mkdir hello-next-app && cd hello-next-app $ npm init -y $ npm install next react react-dom --save $ npm install typescript @types/node @types/react --save-dev $ code src/index.tsx

この記事は、 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

この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

この記事は、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 の歴史、それを踏まえた勉強方法 2020年でJavaScript学ぶならきっとブラウザ向けJSガン無視していきなり初手node.js（ただし暫く何も足さない）がいいんじゃないかというメモ - min.t (ミント) Node.js を教えることについて、自分は賛成なんですが、その学習パスが整理されてないなと思っていたのと、学習パスがなぜ整理されていないかについて書きます。 はじめに 問題意識として、今のプログラミングスクールや独学勢が Ruby on Rails に偏っていて、 Node.js の人間としては、歯がゆく感じているんですが、実際 Node.js を教えるとしても問題も多いと認識しています。 歴史の話は、当時の実情や政治を省いて結果だけを書きます。具体的には第一次ブラウザ戦争、第二次ブラウザ戦争を言及しませ

blitz-js prisma rails 倒し方 を書いた時、こういう疑問がありました。 この db はクライアントでもサーバーでも呼べるようにみえる。ここが blitz のキモで、サーバーではそのまま prisma として実行されるが、内部実装を読んでいないので想像だが、 この db はクライアントでは同じ API の RPC に変換されている？ (ここにセキュリティ上の不安はある。すべてをクライアントから呼べてしまう恐れはないのか？ あとで blitz のコードを呼んで、どうやって実現しているか確認する) この件についての調査をしました。 Isomorphism: クライアント・サーバー同型 blitz では、次のようなコードをクライアントでもサーバーでも呼ぶことができます。 // app/auth/mutations/login.ts import { Ctx } from "bl

とくに断りがない限り、引用文は Workers Durable Objects Beta: A New Approach to Stateful Serverless を Deepl で翻訳したものです。 前提知識として、 Cloudflare Workers 自体の解説はしません。こちらを参照してください。 Cloudflare Workers それは Frontend / Node.js が CDN Edge Side まで拡張されるもの 要約すると Cloudflare Workers は CDN Edge で低遅延、低スペックCPUの Node.js の Worker が高速に動くサーバーレス環境です。 Durable Objects とは 注意: まだクローズドベータです。 本来は、手元で動かしてから記事を書くつもりでしたが、クローズドベータに申し込みしてから待てども待てども解禁

やりたいこと リポジトリ A は npm package を publish したことを リポジトリ B に通知したい リポジトリ B は 通知を受けたら package.json を更新する PR を作成したい 個人のリポジトリでの依存ならこの需要は少ないかもしれませんが、社内でリポジトリを分割してたりすると、更新漏れが発生したりします。それを機械的に防ぎたい。でも手動マージはしたくないのでPR作成まで。そのぐらいの温度感を実現したい、という感じ。 また、リポジトリ B は リポジトリ A の通知によらず、手動でそのタスクを実行できるようにしておきたいです。 (ネタバレすると、先に手動のタスクがあって、その上でリポジトリ間通知を実装しました) (構成要素とレシピ紹介がメインで、コード自体は動いてたコードからの切り貼りなので、そのままは動かないかも。後で要確認) 実装方法 GitHub A

この記事の内容 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 にはない機能を使うことで、それを感じてみたかった、というのが一番の理由です。 優れたプログラマ、そして優れた書き手には相応の対価があるべきです。 オープンなコミュニティでは、それが称賛や承認となって返ってきますが、人間はそれだけでは生きていけません。 今までのエンジニア界隈では伝統的にオープンなコミュニティで稼いだ名声を使って、良い企業への転職で高い給与をもらう、というのが今までの実質的な「稼ぎ方」でした

zenn 本体へのフィードバックです。 この記事を書いた感想です。 Article で有料にしたい note などで有料記事を書く場合のテンプレートはほぼ決まっています。 前書き 無料公開範囲 有料公開範囲 です。今回は Book の作法に則り分割しましたが、煩わしかったので、このテンプレートで有料記事を作れると楽です。 有料記事を買われた際は push 通知してほしい serviceWorker の push notification で通知してほしいです。これでかなりモチベーションを刺激することができると思います。普通に作るとうざい機能ですが、この用途ならアリだと思います。 未決済の金額で他人の記事を買いたい 法律関係で難しいと思いますが、自分の口座と紐付けてお金をおろすのが面倒に感じたので、その場で全部散財できないか考えました。無理でした。 あるいは、金の代わりに貯めた Like で

本記事は、 「なぜ仮想 DOM という概念が俺達の魂を震えさせるのか」 https://qiita.com/mizchi/items/4d25bc26def1719d52e6 の 2020 年版のリライトです。 2014 年当時、日本においては React は未だ知る人ぞ知るライブラリ、という位置づけでした。それが、この記事によって一気にメジャーになったように思います。 オリジナルは2014 年末の情報によって書かれたもので、さすがに 6 年経った今では情報が古くなっており、当時の暗黙のコンテキスト、古いリソースの参照、初学者の混乱を招く表現が残ったままになってしまっています。 定期的に更新しようとも思いましたが、そうすると 2014 年末の歴史的な背景を失ってしまうため、あえてそのまま残し、新しい記事を投稿することにしました。増補改訂版というより、ほぼ書き直しです。 この記事は本来なら