ランカ(制限かかりやすいです💦少しの間いいねのお返し控えさせてもらいます🙇‍♂️) @ranka_1109 息子が6年間住んでたワンルームのマンション、大学卒業で引っ越すことになったけど退去費用が75万円！高すぎないかい？これってどうにかならないのかな😐消費者センターに連絡したらガイドラインに沿って見直ししてもらったら良いと言われたらしいが、専門的でよくわからんらしい pic.x.com/qiS407oXSP 2025-05-06 21:54:05

昔DeNAの新人が入社後半年だかの振り返りのプレゼンの中で「うまくモチベーションが上がらなくて」ということを言った時に、南場社長が「社会人がモチベーションで仕事をするな」とすごく怒ったという話*1があって、とても印象に残っている。 また、これは実体験だが、その当時所属していた会社のけっこう中心的な人物が退職する送別会で、その人が受け持っていた客の話になった時、「あれもこれも大変なお客さんですね。私たちに引き継ぎできるものですかね」と残された側が不安をこぼすと、その人は「仕事やろ」とピシャリと言った、という場面をよく覚えている。 どちらも胸に氷を刺されたような、うすら寒い気持ちになったからだった。 私は、社会人だが、どうにも好き嫌いで仕事をしている節があった。やるべきことを淡々とこなすのではなく、やらなくてはならないことの中に何とか自分の興味が持てるようなテーマを見いだして、努力の為のエネル

テストコードを実装する際に単体テストで書くか、統合テストで書くか迷う場面はないでしょうか。本エントリでは、私なりのテスト戦略についての考えをまとめました。 概要 対象アプリケーション 本エントリにおける単体テストと統合テスト 単体テスト（ユニットテスト） 統合テスト（結合テスト、API テスト、フィーチャテスト） 単体テストと統合テストの特徴 テスト方針 テスト戦略 単体テストのみ 統合テストのみ 単体テストと統合テストを組み合わせる コンポーネント別のテストガイドライン 統合テストによるテスト テストピラミッドとテストダイヤモンド 統合テストの懸念 統合テストが無い 共有データセットが辛い 実行時間が遅くなりそう まとめ 参照 概要 単体テストと統合テストの特徴 テスト戦略 統合テストの懸念への対応 NotebookLM による音声概要を作成しました。よくまとまっているのでこちらもどうぞ

Reactにおいては、コンポーネントは純粋であるべきだとされています。これはReactのルールの一部であり、ルールを守らずに非純粋なコンポーネントを作った場合、さまざまな不都合が発生する恐れがあります。 書いた通りの挙動にならない（ように見える） 今はうまく動いていたとしても、関係ない箇所を修正すると急に壊れる 最適化（React Compiler）によって挙動が変わり、バグの原因となる Reactの新機能と互換性が無くなり、新機能の恩恵を受けられなくなる Reactのアップデートで壊れてしまったり、破壊的変更の影響を受けたりする 単純にコードの可読性が低下し、保守性が悪化する では、コンポーネントが “純粋” であるとは、具体的にどういうことを指すのでしょうか。Reactを使いこなしている人は経験的にこのことを理解していますが、正確に説明しろと言われると困る人も多いのではないでしょうか。

Chrome 135でサポートされた::scroll-button()疑似要素は、疑似要素としてインタラクティブなスクロールボタンを作成できます。さらに::scroll-marker()疑似要素は、スクロールコンテナ内の関連するすべてのアイテムに対してフォーカス可能なマーカーのセットを作成できます。 これらを使用すると、これまでJavaScriptなしでは実装できなかったカルーセルをCSSだけで実装できるようになります。その実装方法、CSSで実装したさまざまなカルーセルを紹介します。 Carousels with CSS by Adam Argyle 下記は各ポイントを意訳したものです。 ※元サイト様のライセンスに基づいて翻訳しています。基づいてというのは、貢献部分に関して同ライセンスも含みます。 はじめに ::scroll-button()と::scroll-marker()の新しい疑似

最近、生成AIサービスを契約したり、churnしたりといったことを繰り返している。その結果、自分自身が今どのサービスを、どのような目的で使っているのかが、非常に曖昧になりつつあると感じている。 そこで、一旦立ち止まり、自分のための整理も兼ねて「AIサービスデッキ」を作成してみることにした。今後、各AIサービスをどのように活用し、どれをやめて、どれに移行していくべきか。その方向性を明確にするために、現状の状況をここでまとめておこうと思う。 ChatGPT Pro 現状、間違いなくもっとも頻繁に使っているのはChatGPT。Proを解約しようかと思った矢先にo3の発表があり、そのままズルズルと課金を継続している。数週間後にはo3 pro modeのリリース予定、とアナウンスされていたのだが、現時点ではまったく続報がないため、若干信頼性に揺らぎが生じている。 ただ、実際にはo3をかなり気に入って

生成AIが直のMarkdownを読み込みやすいという話から、にわかにObdisianが注目を集めているようです。そしてObsidianが注目を集めるにあたり、Zettelkastenという手法にも同時にスポットライトが当たり始めているように見受けられます。実は両者をそれなりに使ってきたので、どう使っているかやどう思っているかについて簡単にまとめてみたいと思います。なお、勢いで書いたので事実誤認（AIでいうならハルシネーション）を含む可能性があります。厳密に見ると間違いがあるかもしれません。ご了承ください。 Zettelkasten 元々Obsidianを使い始めたのは、前職にてローカルで自分のメモ書き等を管理したいためでした。というのも前職では最初の方、いい感じに使えるドキュメント管理ツールがなく、自分のメモ書きを残す場所を探していたという事情がありました（のちにConfluenceが導入

はじめに こんにちは、ダイニーの ogino です。 この記事では、AI エージェントや MCP に入門しようとしている人向けに、エージェントの内部実装について概説します。これを理解することで、現状の AI にできることが明確になり、今後の技術動向を追う上でも役に立つはずです。 本記事の要旨 MCP の表層的なプロトコルには大した意味も革新性も無いので、AI エージェントを理解するにはまずコンテキストを把握しましょう。 素の LLM の能力と、エージェントの実装を切り分ける AI エージェントは、自律的に判断してファイル操作や Web ブラウザなどのツールを使い分けることが可能です。しかし、その基盤となっている LLM にできるのは、テキストを入力してテキストを出力することだけに限られます[1]。 以降では「LLM にできないこと」を掘り下げ、それを補うために AI エージェントがどのよう

ソフトウェア開発の現場でも、日々、苦労が絶えない。知らず知らずのうちに、エンジニアを消耗させる問題が潜んでいる。 苦労は、日常の風景に溶け込みやすい。それが当たり前の状態であり、疑問すら抱かれない。「そういうものだ」と思い込む。いや、苦労することに、そもそも違和感を持てないのだ。 日常化した苦労は、改善されることがない。違和感がないからこそ、問題として扱われない。そして、原因に目が向けられることもなく、風景に溶け込んだまま、空気のようにあり続ける。 つまり、苦労を軽減するには、日常風景の中から問題を見つけ出す必要がある。そのための第一歩が、「気づく」ことだ。問題というのは、気づかなければ解決のしようがない。学校の試験のように、誰かに出題されるものではないのだから。 本記事では、「気づく」ための視点を言語化し、手がかりとして整理している。 ソフトウェアエンジニアリング業務でありがちな苦労を、

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 皆さん、個人開発してますか？ 私はというと、プログラミングが好きで、趣味で日々コツコツとアプリを作っています。 個人開発って、ただ楽しいだけじゃなくて、ちゃんと利益が出る可能性もあるんですよね。 しかも、エンジニアとしての技術力の証明にもなるし、ポートフォリオとして使える点でもかなり魅力的だと思います。 自分の作ったアプリが実際に誰かに使われて、それが実績として残るって、なんだかワクワクしませんか？ さらに個人的に実感しているのは、作れば作るほど、次のアプリ開発がどんどんラクになっていくってところです。 最初のアプリリリースは本当に時間