持辺高志 @highmotivation8 プログラム全然読めなくてNullと0の違いすらわかってなかったけど 醤油取ってって言った時に0は「いま醤油0ですよ」ってことで Nullは「醤…油…?」ってこと? 2026-07-01 23:14:56
昔の引きこもりって凄い 今の引きこもりはネットを介してコミュニケーションしてるから認知機能は保たれてるけど、それ以前は全く新たな刺激がないまま引きこもってたはず 引きこもりの方の研究はネット時代以降のしかないから、それ以前の彼らは医学的にどうだったかもう分からないけど気になる— Lebenstrieb (@Kohler_volnt) 2026年6月6日 たまたまXの相互フォローの人がこんなことを投稿していたので、思わず「今でもネットを繋げない、社会的ひきこもりに当てはまる人はけっこういらっしゃいますよ」とreplyしてしまった。社会的引きこもりの定義に該当する人は百万人単位で日本には存在しているが、そのなかにはインターネットをまったく使用していない人が少なからず存在している。少なくとも精神医療にかかわっているとそういう社会的ひきこもり該当者を見かける頻度はかなり高く、まったく珍しくもない。
"Reading Gravity(読書重力)は、ユーザーの視線が左上から右下へと自然に引きずり落とされる力学である。インターフェースの設計者は、この重力に抗うのではなく、重力が最も溜まる『底』に何を置くべきかを思考しなければならない。" — Edward C. Arnold (Gutenberg Diagramの提唱において)人間(特に西洋的なテキスト文化圏のユーザー)の視線は、Gutenberg Diagram(グーテンベルク・ダイアグラム)やNielsen Norman GroupのF-Shaped Patternが示す通り、左上から始まり、右下へと向かって流れるそうです。 その視線の動きに合わせて、UIのレイアウト・配置をデザインするにあたって、より助けになるような考え方を自分の言葉で表現しようと思いました。表題のとおり、風と重力で例えます。 左から右への「風」は、時間の経過や、コン
はじめに 業務システムを作っていると、退会したユーザーや削除した記事を「消えたことにしたいけれど履歴は残したい」という要件によく出会うかと思います。 このときによく見るのが論理削除と呼ばれる手法で、deleted_at のような列を足して WHERE deleted_at IS NULL で取り出すというものです。 導入は手軽な反面、実際に運用していくとじわじわと辛さが出てくる手法でもあるかなと思っています。 クエリの度に WHERE deleted_at IS NULL を書く必要があり、一箇所でも書き忘れると削除済みのレコードが返ってきてしまいます。 ORM のデフォルトスコープで隠すという手もありますが、今度は削除済みを含めたい場面で抜け道を作ることになります。 さらに、同じメールアドレスが削除済みと未削除で 2 件並べてしまえるためユニーク制約が機能しなくなる、外部キーの参照先が生
居酒屋経営者です。正直「ノンアル客」より「ノンアル客は迷惑だと主張する人」の方が迷惑です。 その理由を説明します。 SNSで「ノンアル客は迷惑だ」「居酒屋から出ていけ」と声高に主張されると、それで集客が減る店もあるのです。 その主張を真に受けたお客様が「そっか、じゃあ行くのやめよう…」と委縮して、うちの店に来なくなったら、あなたはどう責任を取ってくれるのですか? うちの大切なお客様を、部外者が、勝手に追い出さないで頂きたい。 昔の居酒屋には「酔うのが目的の場所」としての需要があり、安酒をたくさん飲ませて利益を得る、という構造がありました。 しかし、その構造は既に崩れています。 物価高だけが原因ではありません。 ストロング系チューハイに顧客を奪われているのです。 昔の居酒屋のメインターゲットであった「酔うのが目的の客」の大半は既にストロング系に流れ、 残るは「グルメ客」と「ノンアル客」の二極
概要重要だが緊急でない仕事は、長期的に取り組むべきと推奨される一方で、着手すると組織のパフォーマンスを停滞させる厄介な性質を持つ。 重要だが緊急でない仕事をプロジェクト化しても緊急の割り込みに時間を奪われ、メンバーはタスクを先延ばしに、MTGは欠席を繰り返し、定例会はちょっとしたタスクのやれたことの共有になり、ずるずると長期化する。 この長期化によって兼務を生み、マルチプロジェクト化を促す。結果として着手から完了までのリードタイムは数倍に伸びることになる。 どうすればいいか。時間が空いたからといって重要だが緊急でないことに手を出さないこと。これは直感に反し、ついよかれと思って新しいプロジェクトを始めてしまう。 解決策はメカニズムに基づくオペレーション設計である。通常は緊急な仕事だけをシングルプロジェクトとして最速で完了させ、手が空けば次に緊急なプロジェクトへ参加する。緊急がなくなった場合の
AIに文書やPDFを読ませると要約して説明してくれるため、長い契約書などを読ませて内容を把握したりリスクチェックをしたりと活用できます。しかし、AIによる文書レビューは「人間が画面上で読んだ文章とAIが内部的に読み取った文章は同じである」という前提で行われています。法律文書向けソフトウェアを開発するTritium Legal Technologiesの創業者であり、企業法務の弁護士およびソフトウェア開発者として10年以上の経験を持つドリュー・ミラー氏が、人間には普通の文章として読める一方でAIには別の文章として読ませる「Noroboto」という攻撃手法を紹介しています。 Tritium | Noroboto: Lying Fonts and Mitigation in Rust https://tritium.legal/blog/noroboto ミラー氏によると、問題の鍵となるのは文書
技術的負債という言葉を本来の意味以外で使わないようにしよう 言葉の定義が間違っているからっていう理由ではありません。 技術的負債を詳しく知りたい方は、このブログよりも t-wada さんのブログ【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明を読んでください。 Ward Cunningham 氏はなぜ後悔しているのか Ward Cunningham 氏が金融系ソフトウェア(WyCash)を開発していた頃に思いついた比喩です。 お金を借りて、事業をいち早く拡張し、それによって収益を増やすことで、利子を返済してもよりたくさんの収益が得られるからってやつです。多分ですけど。 「技術的負債」という言葉が、メンテナンスできないコードを許容する言い訳に使われていることを嘆いているようです。 返済するつもりもないのに「技術的負債だから」と言い、メンテナンス可能なコー
こんにちは! 最近、YouTubeで質問を見ていると、「AIに残される仕事って、結局なんなんですか?」みたいなやつが相変わらず多いです。 まあ、どんどんと進化している上に生活とかに直結するので、一番気になりますよね、と。 んで、少し前までは、例えば「ラストワンマイルの作業とか、ウェットな現場対応とかじゃないですかね」と答えていたんですが、 最近、そうだとしても、さほどハッピーでもないかもしれない、と思い始めました。 というのも、 AIに残される仕事は、結局AIに呼び出される側の仕事になる 呼び出される側のモジュールは、安泰ではない その仕事は、Uber Eats 配達員みたいな仕事の形になっていく みたいな感じじゃないのかな、と思ったのです。 今日はこれを順番に書いていきます。 なお、以下の記事に大いに刺激を受けておりまして、マジでそうだなと思っているので、重複するところとかもあります。
しばらく前のことですが、近所のファミレスに入ったら、店員に「こちらのシート席にどうぞ」と言われたことがあります。ん? シート席!? 「シート」は「席」の意味だから、それじゃあ「席席」になっちゃうだろ! と思わず心の中で突っ込んでしまったのですが、どうやらその人は、椅子席じゃなくてソファーの席、という意味で使ったようです。まあ、気持ちは分からなくもありません。 考えてみれば、昔からそれに類する表現はいくらでもあります。そこでちょっと、類似の表現で思いつくものをリストアップして、語源を調べたりしてみました。ただし調べたと言ってもWikipediaなどが中心なので、不正確な情報も混じっていると思われます。あくまでこの手の単語を集めてみただけ、ということでご承知おきください。 例えば地名で言うと、こんな例があります。 「アムダリヤ川」の「ダリヤ」は「海、川」の意味 (ペルシア語 daryâ) 「イ
ダッシュボードの数字は伸びているのに、現場の手応えはどんどん悪くなる。営業のKPIは達成しているのに顧客は離れていく。コードレビューのコメント数を測り始めたら、本当に直すべき問題が指摘されなくなった。 こういう「指標を導入した結果、本来の目的が遠ざかる」現象には、別々の分野で別々の名前がついている。同じ話に聞こえるが、失敗の所在は違う。観察対象の選び方の偏りなのか、指標と目的の取り違えなのか、指標を目標化した結果なのか、制度全体への波及なのか。 街灯効果 観察の場所選択そのものに偏りが入る現象。鍵を街灯の下で探す酔っ払いの寓話に由来する。鍵を落としたのは街灯の下ではないと自分でも分かっているのに、「ここの方が明るいから」と街灯の下を探し続ける。観察可能性が探索範囲を決めてしまう。寓話自体は社会科学では Abraham Kaplan が1964年に "drunkard's search" と
Excelに長い文章を書き込みたいとき、 結合したセルに「折り返して全体を表示」してもいいのだが、 巨大なセルを作るとスクロールするときに不便だったり 周囲のセルとのバランスが崩れたりする。 そんなときのために複数行に ひとつの文章をうまく割り当てる方法があるのだが、 たまにしか使わないテクニックのため、 備忘録として記録しておく。 手順 まず、複数行にまたがる形で文章の入力欄があるとする。 (本来はExcelは長文を記録するツールではないのだが、 実際には多くの組織でこういう使われ方をしているだろう) まずは文章欄の一番上のセルに目的の文章を入力する。 この際、右側にはみ出したり セルが勝手に大きくなっても気にしない。 次に文章欄のセルを選択する。 このとき、行数は関係なく横幅だけを見ているので 入力欄の横幅に合わせて1行のみ選択すればよい。 (横方向に複数のセルを選択しても問題ない)
エンジニアの認知戦略はなぜすれ違うのか ソフトウェアエンジニアとして業界に長くいると、現場や SNS 上でのエンジニアどうしの「すれ違い」を何度も目にします。技術力の優劣ではない、性格や趣味嗜好の問題とも少し違う、なのにこの「すれ違い」は、驚くほど普遍的に業界内に存在しています。 この記事では、わたしがそのような「すれ違い」を何十年も観測し続けた末にたどり着いた一つの認知モデルに基づく見解です。科学的に証明された理論ではありません。しかし、この視点を持つだけで、日常の摩擦の見え方がかなり変わるはずです。 チーム内での症状 チェックリスト: あなたのチームで以下の状況を見たことはありますか? コードレビューで同じ PR に真逆の指摘が出る。 設計について、すぐ手を動かしたい派と全体像を合意してから着手したい派で割れる。 「なぜこうしたか」は誰かの頭の中にあり、その「誰か」を探す必要がある。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く