はてなブックマーク

最近pnpmのドキュメントを眺めていたんだけど、そこでよく知らない依存関係の種類が出てきた。なので、理解したことをまとめてアウトプットしておく。 そもそも依存関係とは？ package-lock.jsonとは？ といった話は理解できている前提で書く。 dependencies 最も基本となる依存関係。npm installするとdependenciesに書かれたものは全てインストールされることになる。 なので、本番環境で使うものしかここには入れてはいけない。 devDependencies 「dependenciesには本番環境で使うものしかいれてはいけない」と上で話した。「ではそれ以外のものはどこにいれるのか？」となるが、その答えがここ。 繰り返しだがこの話自体はいろんな記事やカンファレンスのトークで擦られ続けているので、もうお腹いっぱい感がある。 一応書くと、devDependenci

cittyを使ってみたところめっちゃ良かったのでメモがてらエントリを書く。 citty unjs.io Nitroとかh3とかいろいろいい感じのライブラリを作ってるUnJSのライブラリの一つ。いい感じにCLIツールを作れる。 準備 npm install citty 公式のサンプルソースを拝借。 import { defineCommand, runMain } from "citty"; const main = defineCommand({ meta: { name: "hello", version: "1.0.0", description: "My Awesome CLI App", }, args: { name: { type: "positional", description: "Your name", required: true, }, friendly: { ty

Firebase Remote Config で、Firebase Admin Node.js SDK v12.1.0 以降を使用したサーバーサイド構成がサポートされるようになった*1。これを試してみる。 Feature Flag自体の説明はしないので知らない人はこれを読んでほしい。 codezine.jp アプリケーション自体はFireabase SDKが入ればなんでもよかった。今回は環境作るのが爆速で個人的にも好きなHonoを使う。 環境 Hono (4.7.2) Firebase Admin (13.1.0) Honoの環境を作る hono.dev 秒で終わる Firebase Adminを初期化 ドキュメントに書いてあるとおりやる。Firebase Projectはあらかじめ用意しておく。 firebase.google.com Remote Configを用意する 地味にわかりづ

タイトルだけ見ると球技の玉拾いの技術に見えるがそうではない。"落ちてるボール"とは、 誰かがやらないといけないが、誰も手を付けていない状態のタスク "誰かがやらないといけない"ことを他の関係者も認識している状態 のことを指すものとする。 この定義が普遍的かは知らないがニュアンスとしては伝わると思う。そしてこれはソフトウェアエンジニアリングに限った概念ではない。自分の経験上は他人と仕事をしていれば自然発生するものだ。"仕事"というほど厳密でなくてもよいと思う。例えば学生の頃の"文化祭の準備"とかでも観測できそうな概念だ。 この「"落ちてるボール"を誰が拾うか？」はしばしば見聞きする問題だ。そしてこの問題は自然発生する以上、発生したものに対症療法することになる*1。すると、この問題に対するスタンスは基本的に二つしかないと思っている。 自分が拾う 他人に拾ってもらう この二つのうち、このエントリ

本当の本当にただの自分向けのメモです。メモだけど、見られて困る内容じゃない。なら、他の人も見れる方がよい。そんな思考でブログにしている。 書くのはSNS界隈では定期的にマウント取りに使われる*1二分探索の計算量について。定期的に忘れてはいちいち理屈から考えるを繰り返している*2ので、もうメモにしておくことにする。ちなみに結論だけ言うと二分探索の計算量はだ。 指数と対数 二分探索の計算量を考えるにあたってこれが必要。いや、それ抜きにしても指数対数は重要なんだがそれはおいておき…なんで指数と対数が出てくるかというと、二分探索の計算量は対数的に増加するからだ*3。そして対数を説明するにはセットで指数を説明する必要がある。なのでこの順番で説明する*4。 それぞれひとことで説明するとこんな感じ。さすがに指数は分かるだろう。が、普段意識しない対数は忘れがち。 指数 = xをk回かけたらnになる。n =

ShellCheckはシェルスクリプトの静的解析ツールだ。文法エラー、バッドプラクティス、セキュリティリスクを指摘してくれる。チェック内容はWikiをみてほしい*1。 www.shellcheck.net はじめの一歩 Macの場合はbrew install shellcheckでインストールできる。早速以下のシェルスクリプトに対して解析をかけてみる。 #!/bin/bash echo "Deleting files in $DIR..." rm -rf $DIR 解析はshellcheck vulnerable.shで実行する。結果、以下のように表示される。 GitHub Actions 次にこれをGitHub Actions*2で解析することを考える。実はGHAにはデフォルトでShellCheckが装備されている。 なので、GHAでシェルスクリプトを実行する前に静的解析をかければ良い。

言いたいことは、「タスクはさっさと片付けて次のタスクに取り掛かろう」ということ。そのため心がけてることを書いていく。 積まれ続けるタスク タスクを次々とこなす。そう言うと「どんどんタスクが積まれて死んじゃう」と声が聞こえる気がする。 けど、お金を稼ぐには何かしら仕事をし続けなければならない。なので「タスクを積まないで」とは言えない。ならばさっさと片付けて次の仕事をした方がお金をもらえていいだろう。「サラリーマンなら仕事をどれだけこなしても一緒」と思っているなら、それはマインドか評価してくれない職場に問題がある。 フリーランスであったり、副業をしているとやればやるだけ売上につながる。サラリーマンであっても評価されるにはたくせん成果を出す必要がある。たくさん成果を出すには、たくさんタスクをこなす。当たり前のことだ。 ここではタスクをたくさんこなしたいことを前提する*1。そのうえで、タスクを消化

思い立ってから10分くらいで頭に浮かんだものをつらつらと書いた。なんとこれらは全て無料で読める。他にもあるかもしれないので、それは思いついたら都度追記していく。必然的にだが、僕にとっての長澤まさみ枠な人たちが名を連ねている。 行動をするときに「自分には向いてないかも」と悩む時間は必要ない soudai.hatenablog.com id:Soudaiさんの記事。特に前川さんの「もし、お前に才能が無かったとして、じゃあお前はどうするんの？そのifの中に実装があるの？何も無いんだったらそのifについて考える時間は無駄じゃん。必要なくない？」っていう言葉が核心付いててめっちゃ好き。年に何回か訪れる気持ちがマイナスになった瞬間とかに読みに行くことが多い。 長く活躍できるエンジニアになるためには？ 技術者として大切にしたいこと speakerdeck.com id:naoyaさんのスライド。先のそー

klibsを眺めていたところ面白そうなものを見つけたので試してみた。 sqldelight.github.io これが結構面白い。リポジトリのAboutに「Generates typesafe Kotlin APIs from SQL」とあって「ORM？」と思ったけど、どうもちょっと違う気がする*1。ORMはオブジェクトを定義して、オブジェクトを操作することでSQLを扱う。が、SQLDelightは逆で、SQLを元に型安全なコードを自動生成するというアプローチを取っている。正しく表現できてるかアレだけど、簡単に違いを表にしてみる。 特徴 SQLDelight 典型的なORM SQL操作 SQLを直接記述し、それを元に型安全なコードを生成 SQLを抽象化してオブジェクトとして操作 型安全性 SQLを元にオブジェクトを定義する。オブジェクトの作成はSQLDelightが自動で定義してくれる。

先輩SWEたちと話していると往々にして「健康が一番大事」という話をされるので、20代のうちから健康でいたいと思い始めてこの本を読んだ。 ヘルシープログラマ ―プログラミングを楽しく続けるための健康Hack 作者:Joe KutnerオライリージャパンAmazon 読んだうえで、書かれていることを実践するために作った環境を勝手に語っていく。 ヘルシープログラマとは この本の造語。脚の上での思考・座っていることの有害さ・起立の真実の3つを理解することで健康を保ちながら少しでもキャリアの中でコードを長く書こうという考え方を総じてヘルシープログラマと名付けているらしい。 脚の上での思考 歩く くらいの軽い運動により脳は成長する 歩くことは副作用のない抗うつ剤を飲むのと同じ 米国心臓学会の研究ではウォーキングの習慣があると心臓病のリスクを50%下げられる 似たような話は「脳を鍛えるには運動しかない！

このエントリが結構反響あった。 blog.inorinrinrin.com ので、同じく榊巻さんのシリーズの『世界で一番やさしい会議の教科書』で学んでから実践してる会議のコツについて書こうと思う。 世界で一番やさしい会議の教科書（日経BP Next ICT選書） 作者:榊巻 亮日経BPAmazon 相変わらずおすすめだし、明日からでもできることがたくさんある。構成自体は物語仕立てだけど、途中途中でテクニックの部分だけでもまとめてくれてはいる。なので拾い読みするだけでも結構効果があると思う。 前置きはこのくらいで詳しく話す。 いちばん大事なこと: 会議の前に4つのPを作る 基本的にこれに尽きる。この4つが準備できてない状態で会議を設定すると、自分の経験上は十中八九何も決まらずに終わる。 Purpose (目的・終了条件) People (参加者) Process (進め方) Property

書籍はこちら。 現場のPython──Webシステム開発から、機械学習・データ分析まで Web＋DB PRESS plus 作者:altnight,石上 晋,delhi09,鈴木 たかのり,斎藤 努技術評論社Amazon 元々WEB+DB PRESS plus で連載されていた内容をまとめた本。連載期間は2020年6月〜2023年8月のものだったらしいけど、書籍化にあたって加筆されているらしい。 初版の発行は2024年9月と最近である。 この本を読もうと思った経緯 仕事で少しだけPythonを使うことになったから。作るものは簡単なツールだったんだけど、それにあたって環境周りやらLinter、Formatterとかは最近は何を使うといんだろう？っていうのをキャッチアップしたかった。 こればっかりはとっかかりがないことにはドキュメントを見に行くこともできないので、いい感じにまとめられてる情報を