Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
アンチパターンで学ぶDB設計 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
「我々の仕事の成果を最終的に使用する人々は、（中略）我々がただ最善を尽くすだけでなく、実際に機能するものを作ることを期待しているのです。」 — ジャン・フィリップ・ピエトルチェク 彼の言葉は、私たちが書くコードをそれに依存する人々の観点からとらえている点で非常に印象に残りました。目まぐるしく変化するこの世界では、ユーザーは私たちが可能な限り最高のコードを記述し、開発したソフトウェアが実際に機能することを期待しています。このレベルの期待に応えるのは当然容易ではなく、だからこそ、開発スタックにおいてはテストが重要な要素になるのです。テストでは、仕事の質を評価し、さまざまなシナリオに照らして検証を行うことで、顕在化する前に問題を特定します。 テストピラミッドは数あるテスト戦略の内の一つです。2012年に紹介されて以降、おそらく10年近くは主要なテストモデルとして利用されてきましたが、最近は以前ほ
派遣PGが出会ったパワハラ上司図鑑
多重派遣プログラマを20年以上やっていた就職氷河期高卒増田が出会ってきたパワハラ上司、パワハラ顧客たちの記憶。全部昔の話。 ①派遣が結婚？？男増田が結婚した時のこと、新婚旅行で1週間休むと伝えたら「派遣社員なのに結婚するんだ？」と高笑いした某銀行システム部の50代社員。 そうなんすよーと答えつつ、ホントにこういう奴っているんだ！と感動した。 ②タクシー男ここは20年以上前の銀行合併の現場。 タクシーで帰ることが認められていた。 プロパーのリーダーは毎日15時すぎに出勤して24時にタクシーで帰るのである。 私は朝9時に来て、毎日21時～終電あたりで帰っていたが、タクシー男、自分より早く若者が帰るのが気に入らない。 ある日嫌がらせで、後に聞いた話だと「あいつは絶対出来ない」と他者に語っていた課題を渡された。 アホくさいのでその後は毎日昼すぎに出勤してタクシーで帰る生活にした。労働時間はさほど変
パンダとおくだが、Web業界の当たり前を「これって本当にそうだっけ？」と問い直すラジオを配信しています Value Object（値オブジェクト）は3種類あった Value Object（値オブジェクト） の意義と使い所がわからなかった。そこで調べてみたらなんと3種類あった。面白かったのでその調査過程を紹介する。 なお、現在では DDD の意味での Value Object がメインであること、またこれは自転車置き場の議論であり、DDD Quickly の Value Object の章を読む方が有意義であることを先に記しておく。 1. Data Transfer Object 1つ目は、Data Transfer Object（DTO）の意味だ。これは PoEAA に少しだけだけ出てくる。かつてのJava界隈の一部では（？）DTOのことを Value Object と呼んでいた。だが、現
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Futureアドベントカレンダーの3日目のエントリーです。昨日は@yamat2667さんのFlutterの記事でした。 デザインパターンというと、普段のプログラミングから一歩踏み込んで設計力を上げたい人が履修すべきコンテンツのように思われているようなツイートなりを見かけます。オブジェクト指向言語全般に使える知識だ、とか、開発者同士のコミュニケーションに使えるぞ、とか、コードの質が上がるぞ、とか。 一方で、パターンを詰め込もうとすると逆にコード量が増えて、パターン由来の変なクラス名が増えたりして、設計が歪むぞ、というのも当初から言われてき
こんにちは！アルプのデザイナーの大澤 (@Tadaki) です。 先日デジタル庁でデザインシステム勉強会の記事が公開されましたね。活用事例として私が所属するアルプでのデザインシステムについて紹介できればと思います。 アルプではサブスクリプションビジネスを行う企業向けに、今まで手作業や自社開発がスタンダードだった契約や請求の管理を SaaS として提供する Scalebase というプロダクトを開発しています。 Scalebaseの開発では、日々プロダクトチームのメンバーとデザインをすり合わせをしつつ開発を進めています。その話の中で「画面Aの保存ボタンと画面Bの保存ボタンが微妙に高さが違うのですがどちらかに統一できませんか？」といった Component レベルの調整は、最初に定義してしまい相談せずとも理解できる方がお互い楽です。 デザインシステムを運用することで、UIの考え方やルールをチー
｢わかりました｣を"I understood."と言ったらブチギレられた…通訳者が教える｢中学英語｣の意外な落とし穴 文法を気にし過ぎると大きな誤解を生んでしまう
「I’m fine, Thank you.」よりこなれた返し ここでは実際に僕がネイティブと会話する中で、鬼のように恥をかいた体験談と、そこから学んだ対策やフレーズをご紹介します。恥をかいたからこそ、僕の身体には刻まれましたが、僕みたいに恥をかきたくない方はぜひ読んでみてください。 英語の挨拶は、「How are you？」が最も一般的で、直訳すると「調子はどう？」という意味。答え方は、「I’m good（元気だよ）」などと、シンプルな返しでOKです。 日本語の感覚からすれば、基本的には「こんにちは」と同義なので、本当はそこまで気にする必要はありません。 しかし留学当初の僕は、「調子どう？」になんて答えればいいかわからず、「え、調子……？ いや別に、んー」と毎回頭が真っ白になっていました。 英語の挨拶には多くの種類がありますが、基本的には意味は同じ。にもかかわらず、ある日友達から「How’
同僚が書いた Go初学者へのコードレビューでよくあったコメント20選 では、Go初学者へのコードレビューでよくあったコメント20選を紹介しました。 今回は私が コードレビューでよくお願いするコメント追加のお願い について紹介します。 前提：コメントを書いて欲しいわけ コードレビューでコメントを書いて欲しい理由は以下の通りです。 プロダクト、サービスの持続可能な開発を支えるため 人が入れ替わっても開発の迷いを可能な限り減らすため 具体的なコメントの追加パターン ①変数やパラメーターの説明を書く コードを書く人にとっては必要があって構造体や変数を定義しているので自明ですが、第三者からすると解釈に悩むことがあります。 そのため誰が見ても自明でしょうという変数以外については注釈をいれます。 たとえば、User 構造体における ID は自明（どのような採番ルールか？みたいな疑問は出るが、ID を入力
[はてブ]関連ページ・RSS一覧
はてブについて、情報検索したりクエリを投げたりして調べてまとめてみた。自分用メモとして書いたもので、極少数の人しか興味を持たない内容かと思うが、読んでいただければ幸い。 公式等[1・2（参照したページURLを最後に記載。以下同様）]で詳細を確かめられず素人の憶測で説明した箇所がいくつもあり、簡潔明瞭でも網羅的でもない解説だがご容赦を。 トップページホットエントリと新着エントリの一覧への導線がある。 URL1. https://b.hatena.ne.jp/ 1a. https://b.hatena.ne.jp/hotentry/{1}（引数に"all"を入力した場合、1のエイリアス） 1b. https://b.hatena.ne.jp/ctop/{1}（カテゴリトップ[3]が過去に存在していた場合、1aにリダイレクト） 1c. https://b.hatena.ne.jp/hotentr
こんにちは！ブロックチェーンチームでエンジニアをしている id:dorapon2000 です。最近買ってよかったものは「潮の華 あおさといわしふりかけ」です。 今回は Git の Squash マージについての知見を共有したいと思います。端的に言うと、 チーム開発で Non Fast-Forward マージをやめて Squash マージを採用し、再び Non Fast-Forward マージに戻した経緯の説明です。Squash マージを運用に導入するか考えたことがある方の参考になればと思います。 Squash マージとは マージには 3 種類ありますね。みなさんはトピックブランチを main へマージする際にどのマージ方法を利用していますか？ Fast-Forward マージ git merge --ff-only Non Fast-Forward マージ git merge --no-f
1991年にMy Bloody Valentineが「Loveless」をリリースして以降、彼らがシューゲイズというジャンルに多大な影響を及ぼした事は説明するまでもない。 しかしそのあまりに特徴的なサウンド故に「Loveless」の影響下のシューゲイズが「マイブラっぽいサウンド」としてパターン化されてしまう流れの起点にもなってしまっている。影響を受けつつもオリジナリティのあるシューゲイズを作り出すにはどうすれば良いのか。 という訳で今回はマイブラの功績を分析するだけではなく、模倣に留まらない新しいシューゲイズの方法論について考察していこうと思う。 My Bloody Valentineの特徴オリジナリティのあるシューゲイズを作る為に、まずはマイブラのサウンドの特徴を知る必要があるのでざっくりとおさらい。 彼らについてキャリア全体を参照するとあまりに膨大なので、代表作である「Loveless
特徴 女性らしいイメージがやや多い 下記のような柔らかい印象のイラストが多いです。 【ガジェットストック】 ガジェット関連のものを使用したい場合は、下記を使用すると良いと思われます。 【アイコン系】 【human pictogram 2.0】 オリンピックで流行ったやつです。 本サイトでは、アタッチメントをつけたりすることでかなりカスタマイズ性が高いのが特徴です。 【EXPERIENCE JAPAN PICTOGRAMS】 特徴 海外から見た日本が表現されている これはシンプルにUIが凝ってたので紹介します。 和テイストを演出したい場合は、良さそうですね！ 【ICOOON MONO】 こちら色・サイズも変更可能です！ 【Icon-rainbow】 ICOOON MONOと異なり、こちらは、中が肉抜きされているのが特徴。 【IFN FREE ICONS】 このデザインはどのようなパターンにマ
これは はてなエンジニア Advent Calendar 2023 の 18 日目の記事です。昨日は id:gurrium による private-isuで70万点取るためにやったこと - ぜのぜ でした。私は 50 万点ぐらいで満足してしまっていたので、しっかり詰めていて凄いなと思う。 developer.hatenastaff.com Web アプリケーション開発において、「キャッシュは麻薬」という言葉がインターネット上をよく飛び交っています。YAPC::Kansai OSAKA 2017 の id:moznion のトークでよく知られるようになったワードじゃないかな。 初出はちゃんとは分からないんですが、少なくとも 2011 年には言われていますね。 「キャッシュは麻薬」とはよく言ったものだ。— TOYAMA Nao (@nanto_vi) November 5, 2011 キャッシ
My new error...
2023 年度の僕のエラーハンドリング について書きたい。 昨日Safe Data Fetching in Modern JavaScriptを読んでいて、fetch に限った話ではないが一家言ある内容だったので書きたくなった。 おそらくやりすぎだとか非効率と言われる点はあると思うので、みんなの一家言も教えて欲しい。 対象は Typescript での サーバー開発想定だが、TS であればクライアント開発にもほとんどに当てはまる話だと思う。 例外のスローではなく Result 型を使う Result は失敗するかもしれないという文脈を与えてくれる型 エラーハンドリングの戦略として例外を投げるのではなく、Result 型を返すやり方がある。 Result 型というのは export type Result<T, E> = Ok<T> | Err<E>; export interface Ok
列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2. switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi
SQS + Lambda という⾮同期処理 ⻩⾦パターン再⼊⾨ #AWSDevDay / SQS-Lambda-DevDay2022
Talked at AWS Dev Day Japan 2022. - 解説動画 : https://www.youtube.com/watch?v=hT7Se0oFEkU - イベントページ: https://aws.amazon.com/jp/events/devday/japan/ - Pr…
認可のベストプラクティスとDDDでの実装パターン
最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います！ 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ
ゲームコントローラーの戦犯はSONYじゃない
https://b.hatena.ne.jp/entry/s/togetter.com/li/1983333 これ見て思いつきでブコメしてる人多いからちゃんとまとめておく ファミコン時代ファミコンより前まで遡ってもいいけど面倒なのでファミコンからスタート ファミコンは B A の順番 Aで決定、が多かったように思うがSTARTの方が多かったかも？ スーファミ時代スーファミも B Aの順番で、Y Xが増えた これも決定はAを使う 一方でセガ陣営のメガドライブはA B Cボタン メガドラ2になってX Y Zが増えたが、基本的にはA B Cを使う そして重要なのだがメガドライブでは決定にCを使う いや、Aでも決定できたような気はするけど基本的にCを使ってた なので一番右側のボタンで決定というのはスーファミと変わらなかった プレステ時代プレステはご存じの通り□ △ × 〇 決定は〇ボタンなので、一
Googleフォームの設定ミスによる情報漏えいが多発～あなたのフォームは大丈夫？ 原因となる設定について解説～ - ラック・セキュリティごった煮ブログ
デジタルペンテスト部の山崎です。 4月から「セキュリティ診断」の部署が「ペネトレーションテスト（ペンテスト）」の部署に吸収合併されまして、ペンテストのペの字も知らない私も晴れてペンテスターと名乗れる日がやってまいりました！（そんな日は来ていない😇） そんなわけで、新しい部署が開設しているブログのネタを探す日々を送っていたのですが、最近、Googleフォームの設定ミスによる情報漏えい事故が増えてきているようです。 どのような設定が問題となっているのでしょうか？ 同じような事故を起こさないよう、設定項目について見ていきたいと思います。 情報漏えいの原因となりうるGoogleフォームの設定について Googleフォームから情報漏えいとなっている事例を見てみると、大きく分けて以下の２パターンのいずれかが原因となっているようです。 １．表示設定で「結果の概要を表示する」が有効に設定されている ある
はじめに 画像は記事に全く関係ないカニのフィギュアです👋 近年、善良なパッケージを騙ったマルウェアが配布されているケースが増えてきています。 これらのマルウェアはパッケージマネージャ上で配布され、開発者端末やそれをビルトインしたシステムを利用するユーザー端末で悪事を働きます。 これは俗にいうサプライチェーン型攻撃で、 これらの関連ニュースを目にする機会が増えてきていることを、多くの開発者が体感されていると思います。 ただ、これらのサプライチェーン型攻撃の記事は、 どうしてもエンドユーザー（パッケージを利用する開発者側・それらを組み込んだアプリを実行するユーザー側）の対策に焦点が当てられたものが殆どのように感じています。 そこで本記事では、このエンドユーザー側の対策だけではなく、 パッケージマネージャメンテナーたちがどう対策しているのかも含めて、 「パッケージマネージャ上で行われるマルウェ
どうも、sakitoです。 今回は私の推しフロントエンドディレクトリ構成と気をつけたいポイントを紹介します。ちぇけら！ 2023年5月29日 追記 この記事を読みにきていただきありがとうございます。 私が記事を書いた時期はまだNext.jsのApp Routerが発表されたばかりで、App Routerを使用したディレクトリ構成の考慮はされていません。 先日、App Routerがリリースされ、Next.jsのドキュメントにApp Routerのディレクトリ構成について記事が出ているので、Next.jsを使用されている場合は、まず参照することをオススメします。 はじめに 今回、私の紹介する推し構成は、機能単位で設計するパターンです。 Reactのディレクトリ構成のベストプラクティスを集めたBulletproof Reactで紹介されているパターンにかなり似ています。さらに詳細なプロダクト構
数日前に𝕏上で「日本のDevRelって何なんだ？」という議論が巻き起こり、エンジニアや今DevRelを名乗っている人たち周辺で大きな話題となりました。わたしもかつてDevRelという名前のチームで働き、その活動に意義があると思っているので話題を整理してみたいと思います。今や様々な役割を内包する名称としてIT・WEB業界で一定の認知度を得ているDevRelとは何をする人なんでしょうか。 ここに書いたものはあくまでも個人的な視点と意見ですが、関連する皆さんは一緒に考えてみてもらえると嬉しいです。𝕏でもブログでもPodcastでもYouTubeでもなんでもいいので、是非ご意見ご感想をお寄せください。 この記事を人力で三行でまとめると アメリカ式のDevRelが日本で改変されて使われるようになったよ なんでこうなっちゃったか考えてみるよ 本来的なものだけを残して、ほかは名前を変えるのもいいんじ
はじめに こんにちは、ゆずたそ（@yuzutas0）です。この連載では、ソフトウェア開発者からプロダクトマネージャーに転向した筆者が、多くの失敗を経て重要性を痛感した「プロダクトマネージャーのマインドセット」を解説します。 主な対象読者としては、同じようにソフトウェア開発を出自とした方で、「同じような失敗経験のある方」「これから失敗を経験するであろう方」を想定しています。連載の前提条件の詳細、免責事項などについては、第1回の冒頭を併せて参照ください。 トレードオフが生じる場面 今回は意思決定について扱います。たとえステークホルダーの協力を引き出し、どれだけ試行錯誤しても、どこかでトレードオフが生じることになります。関係者全員が問題と向き合い、議論を整理した上で、それでも一つの結論にならないという場面が訪れます。そこではプロダクトマネージャーとして意思決定を求められます。 画面に表示するテキ
【Atomic Designに懐疑的なあなたへ】改めて考えたい React / Next.js のデザインパターン
フロントエンド開発は一般的に複雑性との戦いです。放ったらかしにしておくとますます複雑になり、変更するのが難しくなります。これまでにも、このような複雑さをどうにかして制御しようとして、Atomic Designをはじめとした様々な設計手法（デザインパターン）が考えられてきました。 しかし、React / Next.js を使ってチーム開発を行う際に、現状のデザインパターンでの運用では「どうもうまくいかないな」と思う場面に多々遭遇しました。そのような経験を踏まえて、「コンポーネントをどのように設計するか」「どのようにディレクトリを分けるか」を徹底的に考え、新しいデザインパターン「Tree Design」にまとめました。 Tree Design はまだまだ仮説段階です。今後弊社チームで運用していく中でブラッシュアップする予定です。しかし、他のフロントエンド開発チームがデザインパターンを再考する際
自分に正直になる習慣 フランスの哲学者アランは名言を遺している。 「幸福だから笑うのではない。笑うから幸福なのだ」 そのとおりだと思う。アクションから本質が生まれる。本質はあくまでも事後的に発生するものであって、本質という抽象はそれ単独で先行的に存在するものではない。 ぼくは中学生時代、プログラミングに夢中になった。よくわからないまま手さぐりでパソコンを使っているうちに、多彩な処理システムを構築できるプログラミングの魅力にどんどんのめり込んでいった。それがやがてビジネスにつながり、ぼくはそのビジネスでさらに成功を収めるべく野心をたぎらせていった。 要するに今日にいたるぼくのキャリアは、プログラミングとの出合いがすべてだ。プログラミングに出合わなければ、それはそれでまたまったく別のキャリアを描いていただろう。 あらかじめ目指すキャリアがあって、プログラミングに足を踏み入れたわけではないのだ。
ソフトウェア開発の成果は、エンジニアの特性に大きく左右される。たとえば “コードを理解する能力” がその代表例だ。 こうした特性は、作業負荷や認知負荷に直結し、開発生産性に影響を与える。この観点からの評価も、成果を正しく捉えるうえで欠かせない。 もし、理解しづらいコードを書いてしまったら、現在および将来の開発生産性が損なわれる。技術的負債とは、そうした “開発生産性の低下” を「利息を支払う」ことにたとえた概念だ。 本稿は、技術的負債を10のカテゴリに整理したGoogleの文献を参考にしつつ、技術的負債との付き合い方を考える。 🎧 本記事のAI音声解説版をポッドキャストで公開中 （AI解説版）Googleが抽出した10個のカテゴリで技術的負債を捉えなおす - FLOW(er)ラジオ：チーム指向とソフトウェア開発をめぐる対話 | Podcast on Spotify 【ご視聴時の注意点】A
// 追記（2023/12/9） なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ ２年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分（未経験からエンジニアになって１年くらい） こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、そのうえで自分なりに勉強をしているはずなのに、実務ではなかなか手が動かない 変更指示に対して、「先輩が言っているんだし正しいんだろうな」とその場では指示の理由や目的が分からないまま修正を行うことがある（分かっていないため別の機会で同じ指摘を受けることがある） 自身のコーディングには判断基準や根拠がなく、なんとなくの判断に頼ることがある 上
テストでのデータベース単位の捉えかた - 日々常々
データベース（に限らずあらゆる永続化リソース）を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで
【究極】まじん式プロンプトv3｜まじん
こんにちは、まじんです。 お待たせしました。ついに新作 「まじん式v3」 が完成しました！ 構想から完成まで、100時間以上を費やしました。 まずはこれまでの進化を簡単に振り返りましょう。 （はじめてまじん式を使う方は過去記事から読んでください！） Ver.1（2025年8月16日 公開）： 【神回】Googleスライドが一瞬で完成する"奇跡"のプロンプト教えます こちらのnoteがなんと今日時点で8796スキ！ しかしこのバージョンは構文エラー率が高く､不便さを感じているユーザーも多かったはず。 Ver.2（2025年8月29日 公開）： 【必見】"改良版"まじん式プロンプト！ こちらも多くの反響をいただき、もうすぐ3,000スキ！ エラー対策も実装しつつ､スライドパターンは13種類から19種類に増加。UI操作だけで自社仕様にカスタム可能｡ ただし、プロンプトが約95,000文字あるため
チームの自律性を重んじるだけでは組織がうまく回らない / 「Spotify’s Failed #SquadGoals」を読み解く - mtx2s’s blog
「Spotifyは "Spotifyモデル" を使っていないし、あなたも使うべきではない」という一文からはじまる文書「Spotify’s Failed #SquadGoals」が公開されたのは、2020年4月だ。Spotifyモデルを紹介する書籍『ユニコーン企業のひみつ』の日本語版発売が2021年4月。そこから1年も前の出来事である。 今となっては古い話題ではあるが、Spotifyモデルが失敗したとされる原因について改めて掘り下げようと思い、「Failed #SquadGoals」をあらためて読み直してみた。その内容を本稿に整理する。 もちろん、Spotifyモデルを批判する意図は微塵もなく、失敗したと断定する気もない。純粋に、当該文書に記された失敗理由の数々が、多くの組織にとっても考慮すべき示唆を含んでいると感じただけだ。言い換えれば、一般化できる知見が豊富に含まれているのではないか、と
こんにちは！逆瀬川 (@gyakuse) です！ Claude Code v2.1.80で待ちに待ったステータスライン用のrate_limitsフィールドが追加されました。これがないために本当にみんな頑張ってきたのです。本当につらい世界でした。 何が変わったのか 2026年3月19日リリースのv2.1.80で、ステータスラインに渡されるJSONにrate_limitsフィールドが追加されました。 changelogの記載はこうです。 Added rate_limits field to statusline scripts for displaying Claude.ai rate limit usage (5-hour and 7-day windows with used_percentage and resets_at) これにより、Claude Codeのサブスクリプションの使用量
【満開開花】催眠＋生配信・動画配信シュエーション【CG・イラスト】 サークル：満開全席 タイトル：催眠で家族がHなちゅーばー生活～催眠導入編～ 作品販売日：2021年08月21日 DLsiteで発売されている「CG・イラスト」作品を紹介しているまとめ記事です。 記事内ではネタバレ込みの感想を語っているので、気にされる方は注意して下さい。
トポロジー最適化で得られたヒートシンクの形がサンゴに似ていると話題に→制約条件に基づく最適な「形」とは、トポロジー最適化の社会実装を目指す阪大・矢地謙太郎准教授のポスト
矢地謙太郎(Kentaro Yaji) @yajikenotter 阪大 准教授 ←テキサス大学オースティン校Oden Institute 訪問研究員・阪大 助教←京大←松江高専。#トポロジー最適化 の研究者。特に流体関連分野における最適な「形」を日夜探求。特技はボートを漕ぐこと(U19/23世界選手権元日本代表)。 sites.google.com/view/yajiken
コンテンツブロックが有効であることを検知しました。 このサイトを利用するには、コンテンツブロック機能（広告ブロック機能を持つ拡張機能等）を無効にしてページを再読み込みしてください。 なお、Microsoft Edgeをご利用のお客様はプライバシー設定が影響している可能性があるため「追跡防止を有効にする」の設定を「バランス（推奨）」にしてご利用をお願いいたします。詳細は下記のFAQページをご参照ください。 https://help.toyokeizai.net/hc/ja/articles/33846290888345 ✕
お手伝いの @helloyuki_ です。今回はポエムです。 今回は、Rust を始めた当時、プログラミング言語は Java しかまともに触ったことがない新米若手 Java エンジニアだった私[*1]が「見たことがなく、使いどころがわからなく理解が難しい」と感じたポイントについて紹介します。対象とするソフトウェアのレイヤーが低いか高いかを問わず、とにかく Rust をやってみて理解するまでに時間がかかり、難しいと感じたポイントについて紹介します。 Rust の「メモリ安全」って、結局何 所有権とライフタイム 参照 スマートポインタ 代数的データ型 関数が第一級である モジュールシステム self 型クラスという側面でのトレイト まとめ 私が Rust をある程度使いこなせるようになるまでの話 「難しい」って何？、の話 Rust の「メモリ安全」って、結局何 そもそも論ですが、Rust が取
プロンプトインジェクション対策: 様々な攻撃パターンから学ぶセキュリティのリスク - GMO Flatt Security Blog
はじめに こんにちは、GMO Flatt Security株式会社セキュリティエンジニアの石川(@ryusei_ishika)です。 近年、ChatGPT や Gemini などの大規模言語モデル（LLM）をはじめとする生成 AI の活用が急速に進んでいます。その一方で、これらの AI モデルに対する新たな攻撃手法である「プロンプトインジェクション」が注目を集めており、そのセキュリティリスクが問題視されています。 この記事では、プロンプトインジェクションが実際にどのような脅威となり得るのか、具体的な事例を交えながらそのリアルなセキュリティリスクを解説します。さらに、開発者や経営者が取るべき具体的な対策についても、分かりやすくご紹介します。 また、GMO Flatt Securityは日本初のセキュリティ診断AIエージェント「Takumi」や、LLMを活用したアプリケーションに対する脆弱性診
オタクのためのギャル入門｜江崎びす子
前回、『非リア・非モテは何故ギャルへのリスペクトが無いのに都合よく消費したがるのか。』という記事を書いたところ、大変大きな反響をいただきました。 ただ、いくらオタク層に『雑誌を読め』『本物のギャルを研究して解像度を高めろ』と言ったところで、そもそもファッションそのものに対する興味や関心が薄ければ難しいのだろう、とも思います。 そこで今回は、『ここを押さえておけばギャルイラストの解像度が上がる』という具体例を細かく解説しつつ、平成を代表する主要ギャルの系統を紹介した上で、それぞれのギャルをもっと知るためにおすすめの雑誌媒体も紹介したいと思います。 ※あまり細かく書きすぎると覚えきれないと思うので、今回は最低限覚えておくべきポイントに絞ります。 ● 平成を代表する主要ギャル系統 ギャルという言葉は80年代のバブル期に生まれ、当初は若い世代の女性を総称して呼ぶ言葉でした。おじさん的に言えば“ピチ
ブログでの記述にPAL方式は1秒25コマとありますが、実際は1コマ内に奇数列と偶数列で違う2枚分の絵が存在するので、秒50枚の絵を表示しています。専門用語を使うと25フレーム、50フィールドと言います。詳しくはググってください。 日本のNTSC方式では秒30フレーム、60フィールドとなります。 60コマの絵が使えるので、フィルム24枚の絵を60コマに振り分けていくことでテレビ放送に対応させています。具体的には11/222/33/444…と、フィルムのコマを2フィールドと3フィールドずつ順番に振り分けます。そうすることで、視覚上さほど気にならないレベルで24コマのフィルムを60フィールドに振り分けることが出来ます。 ではPAL方式ではどうかというと、50フィールドでは違和感無くフィルムの24コマを振り分けることが出来ません。この問題を解決するには2つの方法があり、ひとつはブログでもご指摘され
『Cult of the Lamb』を遊んで考える「もはや“ローグライト”は再定義しなければならないのでは？」という疑問
昨今のインディーゲームでは「ローグライト」というジャンルが流行っている。このジャンルの人気はかなりのもので、筆者がたまたま遊んでいた『Cult of the Lamb』もその作品に該当する。 『Cult of the Lamb』は、うんこを拾いまくり信者を生贄にしまくるカルト教団経営シムと、入るたびに構造が変わるダンジョンに挑むローグライト・アクションの要素を兼ね備えた作品だ。乱暴にいえば「きたないどうぶつの森」といった内容で、2022年8月18日にリリースされわずか数日で100万本を突破した人気タイトルだ。 本作はIGN JAPANのレビューで8点を記録しており、確かに楽しいゲームだ。しかし、遊んでいると「ローグライトってなんだ？」とばかり考え込んでしまう内容でもある。 そもそも「ローグライト」というジャンルは流行しているものの、かなり曖昧な言葉だ。定義がゆるいだけでなく、“同じジャンル
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テストピラミッド万歳 | POSTD
値オブジェクト（Value Object）は3種類ある - パンダのプログラミングブログ
2024年末にデザインパターンについて考える - Qiita
業務を効率化させるデザインシステムとは？｜Tadaki
コードレビューでよくお願いする、コメントの追加のパターン7選
Git の Squash マージをやめた話 - Mobile Factory Tech Blog
「Loveless」の革新性、その先にあるシューゲイザーの可能性｜ピアノ弾き
【爆速UI設計術】モダンなwebデザイン素材集 - Qiita
「キャッシュは麻薬」という標語からの脱却 - id:onk のはてなブログ
Enumとてもつらい、でも負けない - エムスリーテックブログ
パッケージマネージャで配布されるマルウェア、対策と課題について - ぶるーたるごぶりん
私の推しフロントエンドディレクトリ構成と気をつけたいポイント
日本におけるDevRelとは何なのか、現状と課題と今後 - 941::blog
再現性と質を高める「意思決定のフロー化」 ―― 開発畑のプロダクトマネージャーの失敗から学べ
堀江貴文｢やりたいことがない人｣3つのパターン まずは自分に正直であれ､損得勘定は挟むな
Googleが抽出した10個のカテゴリで技術的負債を捉えなおす - mtx2s’s blog
新人プログラマ アンチパターン：原理原則多すぎて脳みそOOMエラー - Qiita
Claude Codeの使用率がステータスラインに表示できるようになったので表示用のスクリプトを作った話
海外支援サイトで作品を永久に消せと通告を受けた話 - DLチャンネル みんなで作る二次元情報サイト！
新NISAも｢インデックスファンド｣だけで十分だ 金融機関の巧みな｢営業｣に乗ってはいけない
Javaエンジニアだった私が当時困ったRustのコンセプト - paild tech blog
ヨーロッパ映画の日本版DVDは音程が変わっちゃってる！！ | Jazz Maffia BLOG
AWSアンチパターン集 AWS Expert Online 19
ztjapan.com
www.hokkoku.co.jp
iret.media
sironeko1944.hatenablog.com
momoizumi.hatenablog.com
iret.media