サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
都知事選
blog.ojisan.io
encraft #2 までの間、スキーマスキーマした話をたくさん書きたい。 OGP は昨日食べた火鍋だ。Fire 感があるのでこれを使おうと思った。(Firebase の記事を書く時は炎の画像を使っていたのに、炎系のフリー素材をたくさん使いすぎて似た画像ばかりになりストックがなくなったことは秘密) firestore は withConverter で validation できる なんか似たようなブログを書いた気がしていたのだが、どうやら firestore の入出力に型をつける で withConverter を紹介していた。なので詳しくはそれを見てほしい。 export const sitemapConverter: FirestoreDataConverter<SitemapSchema> = { toFirestore(sitemapDto: SitemapSchema): Do
Next.js v13 で app directory を有効にして Static Generation する2023-04-17 OGP は Astro 回でトロを食べてしまったので罪悪感で具無しホットドックを食べている画像だ。新年度、もうすぐ健康診断だ。そろそろ走り始めないといけない。 前回までのあらすじ 原神の TODO リストを Astro Component 使って書いたら辛かった ので、React on Astro するか Next にするか悩んだ。 選ばれたのは Next でした 結局 Next を使った。Astro ver は丸一日くらいかかっていたのが i18n 含めて 1 時間くらいで移行できた。Next 最高! 移行の最中、Static Generation が App Dir に対応したと知ったのでせっかくなので App Dir で SSG してみたログを書く。 a
宣伝 4/25 に Encraft #2 サーバーとクライアントを結ぶ技術 というイベントで JSON Schema について喋る。いま現在進行形で IDL として JSON Schema, GraphQL, Protocol Buffer, zod, joi を使っているのでそれらを食べ比べる発表をするつもりだ(明らかに JS 上でしか動かないものを IDL と呼んでいいか不安になってきた)。そしてスキーマ駆動開発(code first なアプローチをスキーマ駆動と呼んでいいのか不安になってきた)を推進する上で、その中では大人の事情に柔軟に一番対応できるのは JSON Schema だという悲しい話をする。だが、私はこの JSON Schema を書き過ぎたせいで話したいことが大量にあり、JSON Schema の話だけで 1 時間超えそうな勢いなことに気づいた(発表時間は 20 分)。
画像は明日トロに見せかけた昨日トロだ。iPhone の謎のカメラ設定使ってみた。この OGP を作るために昨日大急ぎで閉店前にくら寿司に駆け込んだ。びっくらポンは全部外れた。 古来よりゲームの攻略ツールを作ることでプログラミングができるようになるとある。そのような期待を持ち、paimon.moeで満足できなくなった私は原神の TODO リストを最近作り始めた。原神はリポップの時間がイベントやアイテムでバラバラなのでそれを管理するためのツールだ。iOS 向けの Push 通知のサンドボックスだったり、OSS として公開して yaml で入稿する口を用意することで自分でセルフホストして自分に都合の良い TODO リストを作れるようにもしようとしていた。が、技術選定を間違えたなと思っていま作り直している。その間違いについて書く。 原神は去年の11月くらいからすっかりハマっている。 FYI: ht
URL は 2023-no-gatsby だが、これは 「2023 の gatsby」であって「NO!」ではない。「YES!」だ。 定期的に 「Gatsby は良いぞ」なブログを書いていますが今日もそれを書いていく。 ブログが新しくなりました(2 ヶ月前に)ので、その報告と技術的な解説 なぜ私は Gatsby でブログを作っているのか Gatsby3 はいいぞ Gatsby は React を使ったハイパフォーマンスな静的サイトジェネレータの先駆け的な存在だ。リリース当初から チャンク最適化、画像の最適化、CSS の最適化などが実装されており、後のさまざまな SSG FW に影響を与えた。 Next.js もその一例であり、v9 あたりで SSG がサポートされたときにはこれらの多くの機能が入り、定期的に Gatsby の機能を取り入れている。残念ながら Next.js で SSG ができ
お願い 「C10K 問題とは何か」がわかる方は是非 Issue や Twitter などで教えてください。 追記: 自分の立場 1req ごとに 1 native thread を割り当てていたら、クライアントの数が増えれば増えるほど負荷が高まるのは当然だ。ただハードウェアの性能的に余裕があっても性能が劣化することがあり、それを C10K 問題と呼ぶ。C10K 問題は fd, pid の枯渇、スレッドを固定長サイズで確保することによるメモリの無駄遣い、コンテキストスイッチコストを含む。これを解決する方法が 1req ごとに 1 native thread を割り当てない技術で、シングルスレッド+イベントループ+IO 多重化といったテクニックや M:N モデルにつながる。 追記: @naoya_ito さんに解説してもらった当時の歴史的背景 https://twitter.com/naoya
はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ?」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自
YAPC::Kyoto 2023 にで話します!そしてチケットを今すぐに購入しましょう!! にある通り YAPC に登壇しました。 デカデカと垂れ幕にあったりクロージングトークが言うには「ブログを書くまでが YAPC」らしく、まだ書いていないことを思い出したので書きます。やっと YAPC が終わる(?) なにを話したのか そもそも Perl エンジニアでもない僕が YAPC に申し込んだのはサブタイトルが Try::Catch だったからです。というのもここ 3 ヶ月ほどエラーやアラートだけ見続けるという仕事をしていまして、エラーやアラートに一家言あったからです。 元々その取り組みについては で話したりしていました。 またそのときに理想のエラーハンドリングはどうあるべきかを考え、 My new error... や Sentry SDK 完全理解 を書いていました。 しかしエラーハンドリン
ドタバタしてたら 1 ヶ月以上期間が空いてしまった。仕事の都合で Sentry を完全理解する必要があったので SDK 読んでみた。 知りたいことは エラーの収集方法 どこにエラーを送っているのか エラーの情報として何を送っているのか だ。そこで SDK を呼び出した時にどういうコードが実行されるか一つずつ見ていく。Repository は https://github.com/getsentry/sentry-javascript だ。 ブラウザ版と Node.js 版があるが、Node.js の方を読んでいく。Node.js では一般的には import * as Sentry from "@sentry/node"; // Importing @sentry/tracing patches the global hub for tracing to work. import "@se
一昨日くらいに 「DIP してもどうせ辛くなるよね」的なことを適当にツイートしたら引用 RT や RT 後言及やエアリプで言及された上に「こいつは設計を何も理解しとらん」みたいなことを言われた。「俺は本当に何も理解していないのか?」と不安になったので、自分の考えをちゃんと書いておこうと思った。先に自分の立場を言うと、なんたらアーキテクチャとか SOLID 原則は有用だし自分も使うが、それを厳守しようとは思っていないと言う立場だ。 DIP とはなんだったか DIP(依存性逆転の原則)は SOLID 原則の一つで、一言で言うと「抽象に依存させると依存関係が逆転する」といったものだ。何のことやらという風になるので例だけ挙げると、UserRepository と UserService があってこのように定義すると class UserRepository { get() { return dat
定期的に並行プログラミング入門 を丸パクリするようなブログを書いているが、1 年以上かけて最近ようやく 6 章を理解できて自分の言葉で説明できるようになったので書く。これ本当に良い本だから買ってね。6 章 マルチタスク は初めて読んだ時は何も分からなかった。いきなり FFI の準備をさせられてアセンブリを書かされるからだ。 ちょうどその章に入って1年、あらためて 6 章を読むとようやく理解できたのでその理解を書いておく。 普段 thread をどう使っているか native thread を使う際、 use std::thread; use std::time::Duration; fn main() { thread::spawn(|| { for i in 1..10 { // やあ!立ち上げたスレッドから数字{}だよ! println!("hi number {} from the
求職エントリというものを書く。このブログは会社の人にも読まれているのを知っているので先に弁明をしておくと、転職をたくらんでいるわけではない。ただの求職エントリだ。社内にも向けて自分はこういう経験を積みたいと言うことを言っておきたくて書いた。社内外問わず仕事のマッチングは個人側が発信しないことにはマッチのしようがないと思っているからだ。またいざ転職市場に出てその時点でのマッチングを探すよりかは、先に希望だけ書き置いておけば長い時間軸でのマッチングでも出来て効果的だと思って書いている。それに転職のお誘いをもらったときに「自分はこういうこと考えています」と正確に伝えられるようのリファレンス(目的としてはこれが一番デカい)としての役割も期待して書いている。なのですぐ転職しようとして書いているわけではないことを先に弁明しておく。 改めて書くとこの文書の目的は “自分がどういう経験を積みたいかを考えて
最近 React のコードリーディングに付き合ってくださる方がいらっしゃいましてコードを読んでいるのですが、読むにあたってはそもそもユーザーが書いた React がどう実行されるかエントリポイントをはっきりさせたくなりました。 たとえば const App = () => { const [state, setState] = React.useState(0); return ( <div> <p>state: {state}</p> <button onClick={() => { setState(state + 1); }} >click me</buttn> </div> ); }; のようなコードを実行したときのエントリポイントは分からないわけです。 なので JSX で書いたコードを変換かけて読む環境を作りました。 babel での変換 まず一般的に JSX は React の
2023 年度の僕のエラーハンドリング について書きたい。 昨日Safe Data Fetching in Modern JavaScriptを読んでいて、fetch に限った話ではないが一家言ある内容だったので書きたくなった。 おそらくやりすぎだとか非効率と言われる点はあると思うので、みんなの一家言も教えて欲しい。 対象は Typescript での サーバー開発想定だが、TS であればクライアント開発にもほとんどに当てはまる話だと思う。 例外のスローではなく Result 型を使う Result は失敗するかもしれないという文脈を与えてくれる型 エラーハンドリングの戦略として例外を投げるのではなく、Result 型を返すやり方がある。 Result 型というのは export type Result<T, E> = Ok<T> | Err<E>; export interface Ok
自作ブログはチラシの裏として使っても怒られないのでチラシの裏として使う。 今年の目標の一つに自作グリーンスレッドの上に自作アクターモデルというのがあって、4 から勉強している最中だ(去年から勉強しているので 0 ではないの意)。まずは先人を見習おうと言うことで 12 月あたりから tokio を読んでいたのだが、そのとき解消できなかった疑問がある。まとめたので詳しい人は教えて欲しい。Twitter 、もしくは Discord(sadnessOjisan#5541) で教えてくれると助かる。 タイトルは tokio 分からん 2023 冬だ。つまり春もあるはず。ずっと続きそう。死ぬ間際も「なんも分からん人生だった」って言ってそうな気がする。 実行される poll の実体はどれか tokio では
プログラミングとヘアサロン、実はこんなところに関係性がある。 もしかすると皆さんも思い当たることや見たことあるかもしれない。 そんな事例を今日は紹介したい。 Unix 1 つ 1 つのことをうまくしてくれるのかもしれない。 lima yaml でセットできるのかもしれない。 lucet edge なスタイルを追求できるかもしれない。 syn flood なシャワーかもしれない。 他にもあったら自由に追加してね Patches are welcome. 余談 目薬どれ買えばいいかわからないからとりあえず V ロート買ってる。 だってロゴが・・・ねぇ。 ぶっちゃけそういうロゴとか名前にすることでエンジニアの購買意欲を誘い、売上が少し伸びているってのは色んなところで発生していると思う。 僕もいつか喫茶店を開くときは、カフェ Script にすると思う。もちろんオススメメニューは モカ・ジャスミン
まだまだ 2022 年の振り返りが終わらないぜということで今日は dotfiles の振り返り。dotfiles はその変遷を見ると面白いので、毎年やろうと思い早速やっていきたい。 ちょっと前に M2 の MBA 買って、dotfiles を一新した。 これが今の dotfiles だ。 https://github.com/sadnessOjisan/dotfiles コンセプト 自分は Mac しか使わない が、WSL 環境も持ってるのでシェル周りの環境は移せるように作っておく(原神しかしないけど・・・) make all だけでセットアップが完結する 手作業はしない なるべく標準に準拠し、プラグインやライブラリへの依存を減らす。入れる場合も単体で剥がせるものを選ぶ。 シンボリックリンクを貼って、dotfiles の変更が即時に反映されるようにする .config など XDG に準拠
忘年会の時に、「おじさん(私のこと)って自分のことをできないエンジニアであるふりをするけど、どうして?」って言われたのだが、いざどうして自分がそういうふりをするのかを言語化しようとしたら難しかったので、時間をかけて言語化してみた。 ぶっちゃけ自分はできないエンジニアではないと思っている まず「できる」「できない」の定義だが、ここではしない。 いろんな人と比較されて「できない」側の人間として扱われてきた自分にとってその定義は考えたくない。 「できない」の定義は人を傷つけると思うのでしたくない。 なのであくまで読者の感覚的な尺度で解釈して欲しい。 自分はいわゆる別業種からの転向組で、エンジニアとして働き始めたのは 2018 年なので今年で 5 年目エンジニアだ。別業種からの転向ということでコンピュータサイエンスを大学で学んだ者・小学生の頃からバリバリやってきた者・新卒でエンジニアになって研修や
今年の振り返りをしていたら今年初めて街コンに行ったことを思い出したので、忘れないうちに書いておこうと思います。街コンに悪い印象を抱いていたけど実際に参加すると良かったので、そのことについて書きたいです。ところどころボカしていますが、詳細が気になる方はなんらかの懇親会とかで捕まえて聞いてください。 これまでの婚活 実は今年の 1 月に一緒に年明けした独身仲間に「今年こそ結婚する!」(※毎年言っている)と宣言したところ、誕生日にマッチングアプリ代金という名目でアップルカードを渡されまして、3 ヶ月ほどアプリをしていました。 ただ、恋活アプリとして名高いアプリではあるものの恋愛を頑張らないといけないということからは逃れられず、それが苦手な自分は頑張れなくて結局誰にもメッセージを送らずに終わりました。 友人からは「金返せ!」と言われました。 ただそのおかげでマッチングアプリはとても苦手なものである
moment.js アドベントカレンダー -1 日目は sadnessOjisan が担当します。 必要性に駆られて moment を理解する必要があったので読んでみました。 エントリポイントはどこか package.json の main は moment.js だが、これはビルド済みファイルであり、CONTRIBUTING.md に Starting from version 2.10.0 the code is placed under src/. moment.js, locale/*.js, min/*.js are generated only on release. DO NOT submit changes to the generated files. Instead only change src/**/*.js and run the tests. とある。なのでコー
ライブラリを使わない非同期処理(後編) 先日、前編 を書きました。今日はその後編です。Executor や Schedular の実装を見ていきます。 Executor があると、非同期処理を完了させるために開発者が poll を何度も呼び出さなくても良くなります。 詳解に入る前に概念的な説明 非同期処理とは本質的に何でしょうか。非同期処理がない世界では、タスクの到着に対してその場で実行し、それが完了するまで後続のタスクは実行できません。もしタスクの中に長い時間がかかる IO が含まれていたら、その IO 待ちの間は後続のタスクが実行できません。そこで生まれたアイデアが、IO の待ち時間は別のタスクをするという考えです。 IO の完了を通知する仕組み IO の待ち時間は別のタスクをするためにはどうすればよいでしょうか。 よくあるのは、IO 完了時に完了後の処理を行うように登録だけしてしまう
この記事は Rust アドベントカレンダー 5 日目の記事です。OGP 画像は間に合わなさそうな画像です。 Rust そのものには非同期処理の仕組み自体はありますが、非同期のタスク群をスケジューリングして実行する仕組みがありません。これはユーザーもしくはライブラリに任されています。例えば代表的なライブラリである tokio は schadular や executor を提供します。 非同期処理は関係してくる分野が多くさまざまなレイヤーが重なるのでとても難しいと思っています。そこで非同期処理を深く理解するために tokio を使わなければレイヤーをひとつ剥がせて理解が深まると思いました。そこで tokio を使わずに Rust の公式 crate だけで非同期処理を実現してみましょう。 ちなみに前編とついているのはアドベントカレンダーに間に合わせるために志半ばで切り上げたからです。という
OGP はマイグレーション作業感を出そうと「工事現場 鉄骨 クレーン」で AI 生成した。前から思っているのだが大体生成に失敗する。あまり精度が良くないのは古くからある無料のものを使っているからなのだが、そろそろ自前でお絵描き AI をホスティングしてもいいかもと思いつつある。 Next.js の codemod 今回の v12 から v13 へのアップグレードガイドでも紹介されていますが、Next.js ではマイグレーションを支援する codemod が存在します。 FYI: https://nextjs.org/docs/upgrading#upgrading-from-12-to-13 codemod はいろんなところで耳にはするものの改めて考えるとどう意味かわからなかったのですが、一般的な言葉かは知らないものの調べたところ https://github.com/facebookar
Scala の cats のドキュメント群が Monad に関する説明としてすごくわかりやすかったので、そこで学んだことをまとめておこうと思った。 モナドを理解したい モナドを理解したいというモチベーションをずっと持っている。Wasm 文脈で Rust に入門しそこで Option や Result と出会い、OCaml で Monadic Parser を意味も分からず実装し、そのための勉強で Parsec を知りH 本で Haskell と一緒に勉強したり、同僚に Scala と cats を布教されたりで、長いことモナド周りの技術に触れている。しかし今でもきちんと理解できている自信がない。何が理解できないのだろうか。 H 本で学んだこと H 本は型クラスについて解説したあとに Functor の説明に入る。ここでは文脈を持った値、文脈を維持したまま関数を適用できる関数として fmap
仕事の都合上、Django を覚える必要が出たので、その素振り課題が欲しい + スプラトゥーンを強くなりたいというニーズが出会って スプラトゥーン 3 反省会会場 を作りました。 色々技術的な挑戦をしたのでそのまとめをします。 スプラトゥーン 3 反省会会場とは スプラトゥーン 3 反省会会場は、自分のスプラトゥーン3プレイ動画を録画して、後から見返して反省をするためのサイトです。ただ反省文を書くためだけに作っていたのですが、どうせなら改善点のアドバイスなどがもらえるようにと思って Youtube への紐付けと反省文を外部から見られるようにしています。 反省文を書こうと思ったきっかけはウデマエを上げたいからで、普段同じようなミスをしている気がしているのでしっかりと反省することと、その反省すべきシーンだけを後から何度でも検索して見返せるようにすることが目的です。 いまではご飯を食べる時は常に
明日、トロ w 最近 Astro を触ったのでそのときに調べたこと。 Dynamic Routing Routing 自体は Next.js と同じようにできる。つまり pages/ に [id].astro のようなものを作れば良い。それが URL になる。 この id は const { id } = Astro.params; のようにして取れる。Next と違って context は無いが、Astro という名前空間から取ってこれる。 getStaticPaths Next にある getStaticPaths も Astro には getStaticPaths としてある。 export function getStaticPaths() { return [ // Generates: /dogs/clifford { params: { dog: "clifford" } }
スプラトゥーンをうまくなりたい スプラトゥーン 2 は 3 年ほど遊んでプレイ時間 1400 時間でウデマエが S+0 が限界でした。 ゲームをつけっぱなしにしていたので実際はそんなに遊んでいないとは思いますが、それでも 1000 時間は遊んでいたと思います。 ただそれだけ遊んでもウデマエは X になりませんでした。 これはとても悔しくて、3 では最高位までウデマエを上げたいなと思っていました。 キャプチャーボードを買った そんなときスプラトゥーン上達の方法としてキルされたときに switch の録画機能で録画して反省文を書く練習方法を教えてもらいました。これいいなと思ったので、あとから動画を見返すために無限のストレージである Youtube にあげるべく、switch のプレイを録画するためのキャプチャーボードを買いました。 Amazon で調べたところハイエンド品は 20,000 円ほ
昨日ブログのアナリティクスを見ていると転職サイトからリファラが付いていることに気づき「ほほ〜〜ん」となったのでブログ書く。どこの転職サイトかは書かないし、少し前に 転職ドラフトに参加した なんてものも書いているからここに疑いの目が向けられるかもしれないが、ここかどうかという情報も全部含めて何も喋らない。GitHub 連携する系の転職サイトはどこも 3 年くらいアカウントを持っているので各媒体で日々レジュメが更新されている状況だ。 転職サイトからリファラが付くと何が怖いか もし所属企業のテックブログに寄稿している場合、そのページに対して "転職サイトからリファラが付いている、もしくはその数が急激に増えている" ことが検知できれば、その社員が転職しそうなのを会社側が察知できる。 なぜ転職サイトはリファラを付けてはいけないか 転職サイトは自分の所属企業に対しては自分が表示できないようにすることが
次のページ
このページを最初にブックマークしてみませんか?
『blog.ojisan.io』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く