技術的負債という言葉がある。もともとは、「楽するために導入したが、メンテにコストがかかるようになってしまった技術や構成」くらいの意味合いで使われているように思う。しかし、そもそも全部が負債ではないか、というのがこのメモの趣旨である。 負債 同僚とSlackで会話していると、「けっきょくどの言語を利用しても負債になるときはなるし、大抵負債になる」といった話になった。言われてみればそうで、基本的にコードというものは書いたそばから負債になっていく。去年書いたコードのことも思い出せない。 そんな中で思ったのだが、そもそも、負債になるコードと負債にならないコードとがあったり、技術が「負債化する」のではなく、コードや技術そのものが負債なのではないか。そして、どの言語で書こうが負債からは逃れることができない。負債にならないコードは存在しない。ゆえに、コードや技術は無ければ無いほど良い、ということになる。

あなたはポジティブっつー言葉は好きですか。自分はそんなに好きじゃない。好きじゃない人に読んでほしい気がする記事。 自分はひねくれているのでポジティブという言葉があまり好みではない。精神論っぽいし、どうしたってポジティブにならない物事もあるからだ。たとえば人が死んで落ち込んでいるときにポジティブになれというのはもはや無謀だ。ポジティブという言葉には価値判断が練り込まれている。だから無闇矢鱈にこの言葉を使っても現状を歪めるだけになる。現状を歪めるとおかしなことが起こる。だから好きではない。 とはいっても、ポジティブであったほうがよいのは確かだ。 そんな中、楽観的(optimistic)、だったらすごく便利そうだなと思った。これは現状に対する価値判断を含んでいない。現状を肯定した上で、じゃあどういう態度を取りますか？という言葉だ。 そもそも楽観的とはなんなのか。自分だったらこう考える。暮らしのレ

こういうツイートが話題になっていた。 「配列のすべての要素が条件を満たすならtrueを返す」関数を定義するとき、空の配列を渡したらfalseを返すかtrueを返すかが、良いプログラマかどうかの一つの境目だ— ふみ (DJ Monad) (@fumieval) 2023年5月29日 つまりScalaで言うと次のようなコードが何になるか、というものである。 val xs = Seq.empty[Int] xs.forall(_ == 42) 結論から言うと、このような関数は常にtrueを返す。 なぜだろう？その理由をこれから説明する。 ちなみに他に以下のような意見があった: 仕様による 例外を投げるべき いずれもまぁありえなくはないが、やめておいたほうが良いと思う。もし仮にfalseを返すような仕様があった場合、それは数学から乖離しているのでいずれ仕様内部で矛盾する可能性が高いし*1、最終的に

あまり調子が良くないので、2023年7月現在おすすめしません。なにか他の実装を選ぶことをおすすめします rinsuki.hatenablog.jp 先日Cloudflareから面白いアナウンスがあった。Cloudflareの基盤で動作する、Mastodon(おおむね)互換のソフトウェアWildebeest*1(ワイルドビースト、ウィルドビーストみたいな発音っぽい)がリリースされたのだ。 blog.cloudflare.com 自分はけっこう前から@windymelt@mstdn.takuya-a.netというMastodonアカウントを保有していて、最終的にオドアケルによってイーロン帝が廃位されてTwitterが滅亡してもネット知り合いとのつながりを保てるようにしている。 mstdn.takuya-a.net 今回新たに作成したWildebeestのアカウントは@windymelt@ap.

自分のウェブサイト( http://www.3qe.us/ )をCloudFront+S3構成からCloudflareを使った構成に乗り換えたので、ひっかかった点やつまづいた点などをメモしておく。 結論としては普通に移行できたが、メールとの兼ね合いでDNSまわりでちょっと配慮が必要な部分があるかも、といった具合。試したいときは全部読んでからチャレンジしよう。 ウェブサイトの静的配信にCloudFrontとS3を使っていた モチベーション: ALBのコストが高い Cloudflare 構成 Cloudflare Pages Cloudflare+ Denoflare + R2 修正 R2のstatic hosting機能を直接使う 手順 Webサイト追加 R2バケット作成 APIトークン作成 Denoflareでworkerをデプロイする 完了 まとめ オチ 参考文献 ウェブサイトの静的配信

文脈: blog.arthur1.dev 自分は割とガンガンアウトプットする方で、たまにバズって嬉しいという品質のブログ(これ)をやっている。普段どのような心構えでやっているのか、そして続けるコツみたいなものについて書いてみようと思う(参考になるかは全くわかりません)。 あと一応断っておくと、タイトルにある "去年書いた182本の記事" は非-技術的な記事も含んでいる(けど、だいたい技術記事なので許してほしい)。 どういうときに書くか どういうモチベーションで書くか どういうときにバズるか どのようにして続けるか 余談: 箇条書きの型を統一する 参考文献 あわせて読みたい どういうときに書くか 自分は基本的にブログを「1年前(後)の自分が泣いて喜ぶ記事」というテイで書いている。自分が知りたかったことは他人も知りたかったはずだという仮説で書いていて、それを知りたかった人の総量はその技術のシェ

Common Lispの処理系であるSBCLをインストールしようとしたら、追加でlibzstd-develというのを新たに要求されるようになっていた。見るからに圧縮系のライブラリだけれど聞き慣れないのでちょっと調べてみた。 ちょろっと調べたところ、以下のことが分かった: Zstandard(ゼットスタンダード？)というのが正式な名前。 Facebookが開発した。 Deflateよりも速いことを主眼においている。 BSDライセンス。 Linuxカーネルまわりで使えるようになっているほか、一部のディストロではパッケージの圧縮フォーマットとして使われているようだ。 Webというよりはどちらかといえばバックエンド的な箇所で使われている印象がある。 facebook.github.io zstd コマンド使ってみた 他の名だたる圧縮アルゴリズム同様、Linuxで直接ファイルに対してこれを実行して圧

PGP鍵を交換しました。というのも、元々使っていたPGP鍵はYubikey上で生成して使っていたところ、数ヶ月前にYubikeyを紛失するという赤っ恥の行いをやらかしてしまい、とっとと失効させて作り直す必要があったからです。ありがたいことに手元に旧い鍵の失効証明書があったので、失効は終わっています。そのまましばらくPGP自体使っていなかったのでそのままにしていたのですが、最近PGPを使う用事が発生したのでちゃんと作ることにしました。 本当は、旧い鍵の主鍵で新たな鍵の主鍵に署名したり、Key Transition Statementというのを作成して両者の鍵で署名したりして、「正当に鍵が移行しましたよ」ということを表明しなければならないのですが、いかんせん旧い主鍵を使えない形態で旧鍵を運用していたので、これができません。しょうがないので、たとえばhttps://www.3qe.usに公開鍵情

普段はPerlとScalaを書いて暮らしていて、Rubyを書くのはcapistranoを使うとき・・・という位のWebアプリケーションエンジニア、 id:Windymelt です。株式会社はてなで、はてなブックマークを開発しています。 普段は、関数型テクニックの話をよく記事に書いています。ちょっと見てやってください。 blog.3qe.us 今回、近所の言語の動向も見てみたい!! && 知人エンジニアにRubyistが多い && 今回の開催地は比較的近所 というわけで参加することにしました(三重県津市での開催でした)。 うおーうおー　#rubykaigi pic.twitter.com/2XCGMN2Iiw— Windymelt (@windymelt) 2022年9月8日 撮影した日はちょっとどんよりしていましたが、二日目以降はよく晴れました 自分の暮らしに生かせそうだなと思った知見 B

先日食洗機を買ったけれど、フライパンだけは取っ手が食洗機に収まりきらずに洗えないという問題があった。仕方がないのでフライパンだけ手で洗っていたけれど、手で洗うためにはスポンジや通常洗剤を常時シンクに露出させておく必要があるがために、プログラミングで言うとフライパンのためだけに各種実装が行われているという不健全な状態になっていた。統一的に洗い物ができないのであれば、食洗機を導入したメリットが半減してしまう。 この問題を解消するためには、フライパンの大きさを小さくするか、取っ手が外せるフライパンを導入するしかない。今回は後者のアプローチをとることにした。 取っ手が取れるフライパン 最強 取っ手が取れるフライパンといってもいろいろなメーカーがある。例えばアイリスオーヤマも出している。一般に知名度でいえばティファールのフライパンが有名。 どう選ぶか。とりあえず一番知名度が高いということは、ユーザの

今日は有休にしていたので会社の朝のスピーチを聞いてないのだけれど、同僚の生活が崩壊していて、チンするごはんとレトルトのハヤシライス、そしてポテチで生活していたところ順当に崩壊しているらしい。このままではチームが崩壊してしまう。なんとか私が防がねば。 さて、自分の生活もまあまあ崩壊しているが、崩壊を押し止めるために様々に対処しているので、そのテクニクスの一端をお見せすることで、同僚の生活の崩壊を防ぎ、あまつさえ生活が崩壊していない同僚からのアドバイスをいただこうという、持続可能性に配慮したエシカルな記事である。 カレーやハヤシは炭水化物枠です 鍋作ると良い パンより米のほうが良い気がする ちょっとはらへったら炭酸水買うと良い / 浄水器買うと良い 冷凍食品買うとよい おやつ 便利な野菜 暮らしその他の知見 エコバッグ 時間錬成したほうがよいし、条件分岐減らしたほうがいい、ステートレスだと良い

最近とあるサイトの新規リリースにかかわることができて，そこで得られた学びをフィードバックするという活動をやっている．具体的には運用で使えるIssue Templateを整備したりしているのだけれど，自分やチームの進捗管理みたいな分野でもフィードバックすることができたのでメモしておく． 毎日エンジニアMTGを開く 毎日Scrapboxに残タスク・進捗を書きチームで共有する 毎日の適当な時間を割いてMTGを開く MTGでやること 結果どうだったか 個人レベルの話 ページの内容 1日の流れ 終わり 毎日エンジニアMTGを開く スクラムっぽい話題?かもしれないけれど，自分のチーム(エンジニアは2人)の規模ではこれでうまくいった． 毎日Scrapboxに残タスク・進捗を書きチームで共有する 昨日からコピーしていく 毎日の適当な時間を割いてMTGを開く 話すことそんなになくても予定は作るしMTGは開く

ついに厨二病になったんか？違います． チーム開発や長期的なプロジェクトにまったく触れることなくWebアプリケーションエンジニアになった自分はソフトウェア開発の中で見積りや仕様を詰めていく箇所が一番苦手でした．新卒4年目になっても未だに，プロジェクトというものを成し遂げていくということについては，まったく自信が持てずにいたのです． とりうる仕様がいくつかあって，どれでも実装できそうだがどうすればよいのかわからない この見積りで本当に良いのかという不安 本当にこれで良いのかという漠然とした不安 ひょっとして自分はこの仕事に向いていないのではないかという不安 そんな中同僚は次々とプロジェクトを導いていく...今年のボーナスが不安だ... などなど... こういった悩みがいつもべったりとくっついて，心は沈みがちでした． 不確実性の闇を祓う そこで，考え方を変えてこの状況を打開しようとしました．そも

宣伝です。 買おう 2020-04-24 (金) に発売予定となっているWEB+DB PRESS Vol.116に寄稿いたしました！！！！！！！！！！ 『Perl Hackers Hub』という連載にて、 『GitHub ActionsとAmazon ECSを使ったDockerアプリケーションの自動デプロイ』という記事で担当させていただきました。 発売日は2020-04-24(金)となっていますが、一部書店ではなんと2020-04-16(木)から発売されるようです。疫病が都に流行っているのでお近くの書店に足を運びづらいそこのあなたには、電子書籍もあるので安心してくださいね。 gihyo.jp さて気になる内容ですが、Docker化されたPerlアプリケーションをGithub ActionsでECSにデプロイする、という記事となっております。 すっかりDockerが普及し、手元のローカルな開

かつて，僕が所属しているチームではPull Request(以下PR)のフォーマット，特に「どうして変更するのか」「どう変更したのか」といった経緯などの要素があまり充実していなかった。このためエンジニアのみならずデザイナーやプランナーも含めたチーム内の意思疎通を潤滑にするために，適切なテンプレートを作成してそれに従おうというムーブメントがあった。 とはいっても「この形式が最強」みたいなものをインターネットに見出すことができなかったため，とりあえず『考える技術・書く技術』に範を取って「状況(今どうなっている)・複雑化(それを困難にしている新たな状況の出現)・結論(どうする)」というフォーマットを僕が導入してみた。 それ以前はカッチリしたテンプレートがなく，各自で「こういう感じなのでお願いします」という文言を考えていたので，PR作成者の負担を減らす効果をテンプレートに期待していた。 考える技術