mise はミーズと読みます。 mise とは *env や *vm が担っていた言語環境(コンパイラ・インタプリタ)のバージョンを管理するツールです。 rbenv や nvm のように単一言語に対するサポートではなく、標準で Go、 Node.js、 Python などの複数の言語に対応しています。 類似のソフトウェアに asdf が存在しますが、 mise はその精神的後継となっています。asdf が shell で書かれていたのに対し、 mise は rust で実装されており、起動速度も asdf と比べて格段に早くなっています。 mise は The front-end to your dev env. と自称しており、上記の言語環境のみならず、アウトオブボックスで使用できる複数の開発向けの機能を提供しているので、本稿で紹介します。 言語環境の用意 mise が提供する言語環境は

togetter.com この話は私の見聞きしている状況、特に我が家の子どもが感じていることとも一致していると感じた。 「自分が怒鳴られているわけでなくても、誰かが怒鳴っているのを見るだけでストレスがきつい」、という話だ。 このtogetterに対して、たくさんの人が「それは昔からストレスだったものだ」と述べている。確かにそうだろう。怒鳴り声は交感神経を亢進させるシグナルであって副交感神経を亢進させるシグナルではない。交感神経の亢進を他人に伝染させるシグナルですらあったかもしれない。 元々、怒鳴り声はそのようにできていて、そのように流通してきたのだから、怒鳴り声を聞いてリラックスする人は太古の人間社会にもいなかったはずである。 問題なのは「１．それが昔からストレスだったかどうか」ではなく「２．そうしたストレスがありふれた性格のものだったのか、それとも大きなストレスとして受け取られる性格のも

落合陽一 Yoichi OCHIAI @ochyai 私はこの世界の誹謗中傷を減らすために色々なことを考えていますが，最近考えた回答が，「誹謗中傷や悪口を生業としている人物や団体」に「あなたは反社会勢力ですか，誹謗中傷を是とする存在ですか」と聞くことです．ご協力ありがとうございます． 落合陽一 Yoichi OCHIAI @ochyai 私は私を誹謗中傷する人にとってとても後味が悪い人間なので，開示請求はめっちゃしていますが，「開示請求してこんなやつが誹謗中傷してました⭐️」みたいなSNS映えの報告はしません．後味が悪くなるようにしています．

技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL はじめに 新たに書きました。 MySQLを使っても会社は潰れない 久々に記事を書いたのでどうぞお手柔らかに... 私が過去2年間で行った技術選定の成功と失敗を振り返り、その学びを共有したいと思います。 文才無いので淡々と箇条書きでいきます Twitterエンジニア垢作りました。エンジニアのお友達がいません。 @uncode_jp 注意 意見を押し付けるものではありません。ただ建設的な議論は大事だと思う。 自分の意見は明確に、歯切れのよい表現を意識している。人それぞれだよねみたいな感じに逃げたくない。技術選定に結論はある（過激）。 ただし技術選定にはコンテキストがあり、例えばプロダクトのフェーズや組織の事情によって当然結論は変わる可能性がある。 OSSの開発者さん達は偉大ですごい。あ

以下の記事、内容がひどくて空いた口が塞がらなかったのだが、 （はてブで）ブックマークして下手にホッテントリにでもなったら嫌だなと思いそっとブラウザのタブ閉じた。 が、しばらくすると残念ながらホッテントリ入りしてしまったので、はてブにコメントを軽く書こうとしたが100文字に収まらなかったので増田にした。 技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL まず、「特定条件下では MySQL は我々のプロダクトには不向き」を「MySQLを使うと会社は潰れる」なんて表現するのおかしいでしょ。 以下の記事からの引用だが Uber のエンジニアは「PostgreSQLではアーキテクチャに制限がありすぎてUberのシステムを支えきれない、MySQL＋InnoDBに変えたら全部解決した」と主張している。 UberエンジニアがブログでPostgre

デジタル大臣を務める河野太郎氏は8月26日、自由民主党（自民党）総裁選への立候補を表明した。その記者会見の場で河野氏は、X（旧Twitter）上で一般ユーザーをブロックしている自身の行為への指摘について「誹謗中傷してきた人をブロックする行為は当然で、ブロックが批判される風潮は危険だ」と反論した。 会見で河野氏は「一般ユーザーをブロックする行為が総理大臣の資質としてふわさしいのか」という問いに対して、次のように回答した。 （以下、河野氏の発言） 「SNSでの誹謗中傷が増えてきている。Twitterの場合はXと名前が変わってから誹謗中傷あるいはフェイクニュースがあまり管理されなくなってきてしまったのではないかと残念に思っている」 「誹謗中傷がある程度野放しになったことで、政治家や芸能人、さらにはオリンピック選手なら誹謗中傷して良いんだと、誹謗中傷される対象がどんどん広がっている。あるいは一般の

きまた・せいごう／大阪キリスト教短大客員教授 元岐阜女子大学副学長、元週刊文春・月刊文芸春秋編集長。1955年京都市生まれ。78年早稲田大学政治経済学部政治学科卒、同年文芸春秋入社。『週刊文春』『文芸春秋』の編集長を経て、2015年常務取締役、18年退社。現在、大阪キリスト教短大客員教授を勤める。関わった主な記事は、江川紹子との坂本弁護士失踪事件追及、野坂参三密告の手紙、少年Ａこの子を生んで、ジャニーズ追及キャンペーン、田中真紀子秘書給与疑惑、村木厚子独占手記、田中角栄の恋文、尾崎豊の遺書など多数。著書に『文春の流儀』。 元文春編集長が「今」語りたいこと 元週刊文春、月刊文芸春秋編集長が、豊富な取材経験を基に、注目の事件・事象を独自の目線で解説。読者に世の中を読み解く上での「気づき」「教訓」を与える。 バックナンバー一覧 知性派からタカ派、「若気の至り」まで 各総裁候補を辛口寸評 今回の総

こんにちは、データベース愛好家のみなさん！今日は、データベース設計で永遠の議論となっている「テーブル名、単数形 vs 複数形問題」について、徹底的に掘り下げていきます。私は単数形派です！でも、なぜそうなのか、一緒に深掘りしていきましょう。 イントロダクション：我らが主人公、単数形くん みなさん、こんな経験ありませんか？ You: テーブル名って、users? user? どっちがいいんだろう... 先輩: いや、絶対usersだよ！Rails使ってるし。 You: でも、user_idって書くときは単数形だよね？ 先輩: あ、そうだね...でもやっぱりテーブルは複数形！ You: （心の中で）なんかモヤモヤする... 実は、この「モヤモヤ」には理由があるんです。今日はその理由を解き明かし、単数形テーブル名の魅力をお伝えします。準備はいいですか？Let's dive in! 言語の壁を突破せ

箕輪厚介 @minowanowa GW明けだからか子供が小学校をサボろうとするから学校行けって言ったら、ホリエモンが学校行かなくていいって言ってると返された。むずい 冒険家ゆたぼん@高校1年生 @yutabon_youtube 日本中を旅した元不登校YouTuber。現在15歳！日本航空高等学校通信制課程メタバース工学科！週に6日ボクシングクラブオキナワで練習！高卒認定試験7科目合格予定！あとは英語のみ！お問い合わせはこちら→ yutabon.jp/form/ 人生は冒険だ！サブ垢→ @yutabon_boxing m.youtube.com/channel/UCMod1… 冒険家ゆたぼん@高校1年生 @yutabon_youtube ホリエモンが「学校に行かなくていい」って言ってるからといって学校をサボって、大人になってから困ってもホリエモンは責任を取ってくれない。人生の責任は自分自身。

でかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。 SQLの記述順序と思考の順序が違うので書きにくいし、エディタの補完機能の恩恵が受けられないのが嫌だ、という意見はもう大昔からある。何度も何度も何度も繰り返されてきた議論である。以下の2011年のスレッドでも「SQLはFROM句が最初に来るべきではないか？」という問いが提起されている。すぐに出てこないが、筆者はこれより古い文書も見た記憶がある。

はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？　予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。

ﾍﾟﾛﾍﾟﾛチンチン @majikitchy 絶対に『挨拶しても無視する人』が職場に居て、なにも知らない新人さんが「あっ！」ってなって手話で挨拶しだして周りは肩震わせるし本人は恥ずかしくなって顔赤くしてたって話思い出した

これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は2つあります： 同値分割の分割の基準が不明確であること 後述するいくつかの仮定を満たさない場合、ある同値パーティションの代表値の出力が正しければその同値パーティションの他の値の出力も正しいといえる根拠に乏しいこと この2つから、不明確な基準の同値分割はその信頼性の説明ができないこと、同値テストは後述するいくつかの仮定が満たされたときのみ有効な手段でありいずれかの仮定が満たされない場合はさして信頼できないことが導かれます。 この記事ではこの結論に至るまでの過程について詳しく説明していきます。なお誤りのご指摘は大歓迎です。ぜひ皆さんで議論しましょう。 同値分割とは 後述する複数の文献の同値分割の説明に共通しているのは以下の2点です： 入力

この記事の概要 tmuxとneovimを組み合わせている様子… こんにちは！食パン🍞と申します🏜 普段はフロントエンドを中心にパソコンをｶﾀｶﾀしている者です💻 私は普段のコーディング時のメインエディタとして、ターミナル環境下で、Neovimを用いています。 (Neo)Vimは、その独特な操作体系ゆえ慣れるまでがちょっぴり大変ですが、一度習熟すると非常に効率よくテキスト操作を行えるため、日々愛用しています。 また、開発作業の過程では、複数の画面を都度切り替えながらコーディングをしたり、複数のシェルを用いてコマンド操作を実行したくなる機会が多々あります。 例えば、 Viteでフロント開発環境を立ち上げてリアルタイムでコード変更を確認したい docker composeで複数のコンテナを立ち上げつつターミナルでログを確認したい それはそれとしてNeovimも並行して使いたい といった具合

単著ならではの一貫性と、筆者のノウハウをありったけ突っ込んでやろう！というあっつい想いを感じる素晴らしい書籍です。 「2018年から2024年、コンテナ界隈もいろいろ変わったもんだなぁ…（しみじみ）」 献本いただいた「Docker/Kubernetes 実践コンテナ開発入門 改訂新版」を眺めながら、ハマコーはそんな感慨にふけっておりました。 5年前、Docker始める人はまずこれ！書評「Docker/Kubernetes 実践コンテナ開発入門」で旧版の書評を書いたご縁で、著者の山田さんより改訂新版の献本をいただき、今この場にその本があるというわけです。 改めて中身読んでいたのですが、単著でこれはマジでやばいです。今コンテナを使った開発を進めようとしたときにでてくるであろう、開発〜運用面でのトピックが幅広く凝縮されている本で、「これ一冊読んどけば、マジはずれないよ」というぐらいの力が入った書

「Uizard」はAIを使ったUIデザインツールで、ワイヤフレーム、モックアップ、プロトタイプを短時間で作成できます。最新の「Generate with Autodesigner」サービスはUI画面を自動で生成可能。今回は実務に根ざしたサンプル生成で、UIの精度を検証します。 こんにちは。CXデザイナー事業本部のスギヤマです。普段はモバイルアプリケーションやLINEアプリケーション開発に携わっております。 「Uizard」は、デンマーク コペンハーゲンのソフトウェア企業が開発しました。AIを利用したUIデザインツールで、ワイヤフレーム、モックアップ、プロトタイプを短時間で作成することが出来ます。手書きスケッチもワイヤフレームに変換し、簡単にプロトタイプ化すること出来ます。 以前から、「手書きのUIスケッチを美しい画面デザインに変換してくれるサービス」として話題だった「Uizard」ですが、

RHEL互換ディストリビューション、SUSEも参入へ。制限なく誰でも利用できるRHEL互換OSを開発していくと エンタープライズ向けのLinuxディストリビューション「SUSE Linux Enterprise Server」などを提供するSUSEは、Red Hat Enterprise Linux（RHEL）をフォークし、制限なく誰でも利用できるRHEL互換ディストリビューションを開発し保守していくと発表しました。 同社はこのプロジェクトに今後数年で1000万ドル（1ドル140円換算で14億円）以上を投資し、プロジェクトをオープンソース財団に寄贈すると次のように説明しています。 SUSEは、オープンソースコミュニティと協力して、RHELとCentOSのユーザーのための長期的かつ永続的な互換性のある代替製品の開発に取り組んでいます。SUSEは、このプロジェクトをオープンソース財団に寄贈し、

こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想

Red HatにRocky LinuxとAlmaLinuxが反論。OSSの精神と目的に違反している、ダウンストリームのリビルドは価値をもたらす、など Red Hatは6月、Red Hat Enterprise Linux（RHEL）のクローンOSベンダに対して排除する方向性を打ち出しました。このことが、多くの議論や影響を引き起こしています。 Red Hatが起こしたアクションは2つです。1つはCentOS StreamをRed Hat Enterprise Linux（RHEL）関連の唯一パブリックなソースコードリリースのリポジトリにすると発表し、事実上、RHELのソースコードの一般公開を取りやめにしたことです。 参考：Red Hat、今後はCentOS StreamがRHEL関連のパブリックなソースコードの唯一のリポジトリになると発表 RHELのソースコードへのアクセスは有料のサブスクリ