タグ

関連タグで絞り込む (176)

タグの絞り込みを解除

設計に関するt-murachiのブックマーク (168)

  • 「ヌル氏」名前のせいでビザが発行されずホテルの予約もできずインターネット契約すら解約できず他人宛の郵便物が届きまくる

    コンピューター分野では「何も示さないもの」を示す語句として「Null(ヌル)」が用いられています。この慣行が影響して姓名に「ヌル」が含まれる人は数々の問題に遭遇しています。 When Your Last Name Is Null, Nothing Works - WSJ https://www.wsj.com/lifestyle/null-last-name-computer-scientists-forms-f0a43b08 Nullはドイツ語で「0(ゼロ)」を意味する単語で、ソートアルゴリズムの「クイックソート」の発明者としても知られるアントニー・ホーア(通称:トニー・ホーア)氏によってコンピューターの世界に持ち込まれました。Nullは多くのプログラミング言語やデータベースなどで用いられていますが、中でもJavaのエラーの1つである「NullPointerException」は「ぬるぽ

    「ヌル氏」名前のせいでビザが発行されずホテルの予約もできずインターネット契約すら解約できず他人宛の郵便物が届きまくる
    t-murachi
    t-murachi 2025/02/25
    ステータスとしてのNullと文字列の"null"が混同するレイヤーがWebに存在する(ような作りになっているシステムが乱立している)ことが問題なんだよね…(´・ω・`)
  • システム構成図、ER図、フローチャートなどを描くときに無料で使える作図ツールやドローイングツールまとめ。2024

    システム構成図、ER図、フローチャートなどを描くときに無料で使える作図ツールやドローイングツールまとめ。2024 システムを開発する際には、インフラを構築するためのシステム構成図やアプリケーションの仕様を検討するためのさまざまなUML関連のダイアグラム、フローチャートやデータベース設計におけるER図など、さまざまな作図をする場面があります。 これらの作図作業を支援してくれるツールは多数存在しますが、ここでは無料で使えるツール、あるいは無料プランが利用できる有料サービスなどをまとめました。 draw.io 無料で利用できるドローイングツールの代表的な存在がdraw.ioでしょう。ユーザー登録すら不要ですぐに使い始めることができて、作図したデータはGoogle DriveやOneDrive、Dropbox、GitHubGitLab、ローカルデイバイスなどに保存できます。 GitHubにサーバ

    システム構成図、ER図、フローチャートなどを描くときに無料で使える作図ツールやドローイングツールまとめ。2024
    t-murachi
    t-murachi 2024/10/02
    最近はmermaidでできる作図はだいたいmermaidでやっちゃってる。markdownの中で書けてそのままgithub上でプレビューできるのがデカい。WYSIWYGなやつだとCacooは会社でライセンス持ってて使ってるけど割といい感じ。
  • 📗 なぜ依存を注入するのか DIの原理・原則とパターンを読んだ感想 | Happy developing

    なぜ依存を注入するのか DIの原理・原則とパターン 著者: Steven van Deursen, Mark Seemann 訳者: 須田智之 表紙には.NETやC#の文字はないのですが、前の版は"Dependency Injection in .NET"で.NETを前提したのようでした。 ただ、はじめにで 書では、.NETとC#を用いて、依存注入に関する用語や指針を包括的に紹介し、描写しているのですが、書の価値が.NETの外の世界にも届くことを望んでいます。 とありました。 RustのDIでなにか活かせる教えを期待して、読んでみました。 第1部 依存注入 (Dependency Injection: DI) の役割第1章 依存注入 (Dependency Injection: DI) の基: 依存注入とは何なのか? なぜ使うのか? どのように使うのか?まず、保守容易性(maint

    📗 なぜ依存を注入するのか DIの原理・原則とパターンを読んだ感想 | Happy developing
    t-murachi
    t-murachi 2024/09/16
    Dependency injection自体はそこまで真新しい概念ではなくて、例えばシングルトンが欲しくなるようなシチュエーションで、呼び出し側がそのオブジェクトを用意し提供できるようにするベターな手法だったりする。
  • 隈研吾氏設計の美術館が劣化でボロボロに…改修費3億円に住民衝撃 ふるさと納税で修繕計画も賛否|FNNプライムオンライン

    4日、取材班が向かったのは栃木・那珂川町。 豊かな自然に溶け込むように建てられた「那珂川町馬頭広重美術館」は、県外からも多くの人が訪れる人気の観光スポットです。 しかし、近づいてみるとある異変を発見。 黒ずみ、腐した屋根。 ところどころ木材が折れ曲がり、激しく傷んでいるのが分かります。 完成して、24年の美術館。 老朽化が進み、3億円にも及ぶ大規模改修工事の必要に迫られていたのです。 多額の費用に、町民からは「無駄ですね。撤去してもらいたい」「えー!?3億円!?大丈夫ですかね…」などと、驚きの声が広がっています。 那珂川町馬頭広重美術館を設計したのは、世界的に有名な建築家・隈研吾氏。 木材を使った日的な建築を手掛けることで知られ、国立競技場のデザインも担当しました。 老朽化が進む那珂川町馬頭広重美術館では、地元産の八溝杉(やみぞすぎ)を細く加工し格子状に並べていました。 屋根や壁に使わ

    隈研吾氏設計の美術館が劣化でボロボロに…改修費3億円に住民衝撃 ふるさと納税で修繕計画も賛否|FNNプライムオンライン
    t-murachi
    t-murachi 2024/09/05
    https://kkaa.co.jp/project/nakagawa-machi-bato-hiroshige-museum-of-art/ 不燃・防腐処理施して屋根材としても使える杉材 #とは
  • 実装する前にきちんとドキュメントを読んだ方が良い、という話 - Qiita

    どうも、初めまして。 tokeと申します。 今回は自分の失敗談を話したい、と思います。 実装する前にドキュメントを読まないと、最後になってゴールに辿り着けない可能性がある そういう経験をしたのでご紹介します。 例えば、自社で集めた顧客のデータを活用し、Marketoにデータ連携したいとします。 marketoのAPIドキュメントを調べると、顧客の情報を登録する手段では以下の2パターンがあります。 POST /rest/v1/leads.jsonを使うパターン 以下のドキュメントにあるPOST /rest/v1/leads.jsonを使って、顧客のデータを送信し、連携する事ができます。 https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/lead-database/leads [※Marketoで

    実装する前にきちんとドキュメントを読んだ方が良い、という話 - Qiita
    t-murachi
    t-murachi 2024/08/15
    非機能要件の定義の甘さとシステムテスト (性能テスト) の不十分さも要検討だ罠(´・ω・`)
  • プログラミングが設計作業であるという話 - きしだのHatena

    いわゆる「ソフトウェア設計書」が設計ではなく、ソースコードが設計であるという話。 随筆です。考えマトメ中なので、ツッコミはそのあたり踏まえていただければ。 追記:ブコメに「設計の定義は?」とあったので末尾に追加しています。 追記(2024/8/15):設計書ってなんだろう?というのも書いておきました。 ソフトウェアの「設計書」とはなんなのか - きしだのHatena このエントリで書いたのですけど、もうすこしちゃんと。 建築では多重下請けでやれてるのに業務システムでだめなのはなぜ? - きしだのHatena このエントリでは次のように書いています。まあ、これで全てではあるのだけど。 「建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも?)ビルドです」 あと「継続的デリバリーのソフトウェア工学」からの抜粋。 「継続的デリバリーのソフト

    プログラミングが設計作業であるという話 - きしだのHatena
    t-murachi
    t-murachi 2024/08/14
    あまり意味のある議論には思えないなぁ。設計にも段階はあって、画面レイアウトにせよデータモデリングにせよソースコードだけで書き表すには詳細に過ぎるからこそ文書化することで保守性を担保するわけだし。
  • 全銀システムの大規模障害、「真の原因」明らかに--全銀ネットとNTTデータが発表

    全国銀行資金決済ネットワーク(全銀ネット)とNTTデータは12月1日、10月10日〜11日に発生した全銀システムの大規模障害の真の原因を明らかにした。 全銀システムは、日常の振込や送金をリアルタイムで処理するシステムで、国内のほぼすべての預金取扱金融機関が利用している。10月のシステム障害では三菱UFJ銀行、りそな銀行など10行で、他行宛の振り込みができないなどの障害が丸2日間継続した。 障害は、全銀システムの中継コンピューターを新機種「RC23シリーズ」へ交換し、その後営業運用を開始した直後に発生した。RC23シリーズ内の「銀行間手数料を処理するためのインデックステーブル」が破損しており、同テーブルを参照する際の処理でエラーが生じたためだ。 中継コンピューターは東京と大阪に1台ずつ、冗長化として設置されていたが、2台同時に新機種のRC23シリーズに切り替えたため、2台ともにソフトウェア障

    全銀システムの大規模障害、「真の原因」明らかに--全銀ネットとNTTデータが発表
    t-murachi
    t-murachi 2023/12/02
    後戻りできない種類のリプレース、わいも最近そんな感じのプロジェクトに関わってたけど、正直色々ときついよね…(´・ω・`) 障害が2日程度で収まって本当に良かったと思うよ(´・ω・`)
  • 「2回ボタン押したら水が…」音楽フェスの準備中に男性スタッフ死亡 時速120キロの水が誤射で“直撃”【news23】(TBS NEWS DIG Powered by JNN) - Yahoo!ニュース

    14日、大阪市の音楽イベント会場で男性スタッフに倒れているのが見つかり、死亡が確認されました。当時、リハーサル中で演出で使う水が、男性に直撃したとみられています。 【写真を見る】「2回ボタン押したら水が…」音楽フェスの準備中に男性スタッフ死亡 時速120キロの水が誤射で“直撃”【news23】 ■時速120kmの水“直撃” 音楽イベントのスタッフ死亡 7月14日午前11時すぎ、大阪市のイベント会場で水を高速で拭き上げるウォーターキャノンという装置が誤作動し、スタッフの八代達司さん(40)が死亡しました。発射した水が八代さんの頭に直撃したとみられています。 会場では、7月15日と16日に開催予定だった「ウォーターボム」という韓国人アーティストらによる音楽イベントのリハーサルが行われていました。八代さんが、40台あるウォーターキャノンの操作装置を確認していたところ、一部の装置から水が高速で発射

    「2回ボタン押したら水が…」音楽フェスの準備中に男性スタッフ死亡 時速120キロの水が誤射で“直撃”【news23】(TBS NEWS DIG Powered by JNN) - Yahoo!ニュース
    t-murachi
    t-murachi 2023/07/16
    3段階ある手順がそれぞれ異なる操作内容、なら理解できるんだけど、単なる「押す」という操作を3回、だとカウント間違えは普通に起こりうるし、到底フェイルセーフとは言えない設計だと思う。
  • 1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」(※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→)

    門脇 敦司/ Atsushi @at_sushi_ Knowledge Sense, Inc. CEO東大 / エンタープライズ向け生成AIプロダクトで成長中のスタートアップ(2019年~) / ソフトウェアエンジニアを募集中(800万円~+SO)→DM開放中 / 好きな言葉は「実験と学習」/ 最新の生成AI 事情に少し詳しいです https://t.co/PwBZaT31cB 門脇 敦司/ Atsushi @at_sushi_ 1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」 (※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→) twitter.com/jasoncwarner/s… 2022-11-16 09:20:18 Jason Warner @jasoncwarner I'm convinced that o

    1/ GitHub 元CTO「マイクロサービスにしたことがアーキテクチャ上の最大のミスだった」(※少しマニアックな内容ですが、個人的には面白いと感じたので載せます→)
    t-murachi
    t-murachi 2022/11/21
    部品でしかないはずのものをライブラリではなくサービスにしちゃえば重くなるのは当然だしコードベースも別れちゃって組織としても複雑化するだけだという考えてみりゃそらそうだわなという話(´・ω・`)
  • なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena

    1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から

    なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
    t-murachi
    t-murachi 2022/08/06
    何でもかんでもオブジェクトって呼んでりゃあそら廃れん罠(´・ω・`) 言うて同じ言葉でも出たてのJavaとKotlinじゃまるで別世界やし、方法論は次第次第で変わり続けてたんでねーの?
  • 「バグを意図的にバグのまま残す」という選択肢がある

    はじめに gcc v12.1において、C++の正規表現ライブラリstd::regexに、正規表現のバリデーションを改善するパッチ(以下"改善パッチ"と表記)が取り込まれました。改善パッチによって、これまではバリデーションにひっかからなかった不正な正規表現文字列が"正しく"不正なものと認識されて例外が発生するようになりました。 これだけ聞けばいいことだけのように思えるかもしれませんが、実はそうでもなかったりします。経験豊富なかたであれば見た瞬間ゾッとしたかもしれません。記事では、この一見問題なさそうな改善パッチによって発生しうる問題、および、その具体的例について紹介するとともに、この手のパッチを当てるかどうかは難しい判断になるという知見を共有します。 結論 改善パッチによって発生する問題 発生条件 gcc v12.1以降、あるいは改善パッチをバックポートされた任意のバージョンを使ってC++

    「バグを意図的にバグのまま残す」という選択肢がある
    t-murachi
    t-murachi 2022/07/31
    std::regexは興味あってよく触ってた時期もあったけど、あれは設計自体があまりよろしくないと思う。パターンを決め打ちで埋め込んでしまうにはコストもリスクも重すぎるし、外部入力に依存するにはカジュアルさ文字数
  • 「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる

    とりあえず、よく言われてるやつから埋めていこうと思う。 構造体にライフタイムを持たせない 構造体にライフタイムを持たせるのは「基的に」避けよ、というのが重要なのは間違いないのだけど、これをもう少し実践的な内容にしたい。ちょっと考えてみたけど、こういうのはどうだろうか。 ある関数呼び出しの中でしか絶対に使わない。returnするまでにその構造体のデータは全て破棄される。static変数に退避させることもできない。アロケーションもその関数が面倒を見る。そういう一蓮托生できる関数呼び出しに心当たりはあるか? ある→ 構造体にライフタイムを持たせてもよい。 ない→ ライフタイム禁止。 そう考えてみると、DIとかReduxとかとも通じるところがあるかもしれない。「つべこべ言ってないで全部の責務を一番外側に持っていく」という決断ができるときは構造体ライフタイムが選択肢に入る。

    「Rustでやると知らないうちに詰む設計」を避けるためのTipsを集めてみる
    t-murachi
    t-murachi 2022/02/07
    最後のってどうすりゃいいんだっけ…(´・ω・`)
  • ふつうのプログラマのふつうの設計

    普通のプログラマの普通の設計 2022-01-26 編(雑談)の前振りスライドです。 https://modeling-how-to-learn.connpass.com/event/231669/

    ふつうのプログラマのふつうの設計
    t-murachi
    t-murachi 2022/01/27
    なんかこの投げやり感好き(´・ω・`)
  • なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita

    1.はじめに エンジニアの私がデザインを気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。 記事では、 SEのAさん デザイナーのBさん の二人が画面デザインをする過程を比べながら、その思考の違いを整理してみます。 3.SEのAさんの

    なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
    t-murachi
    t-murachi 2021/12/11
    すんげえ勉強になった。まさに設計やね。
  • Go言語が好きな理由

    はじめに 私はGoが好きなので、disられている場面に遭遇すると心が痛みます。残念ながらプログラミング言語について深く語れるほどの知識や経験は持ち合わせていないため、世界が平和になることを祈るくらいしかできません。 (元ネタ)Go言語を嫌う6個の理由 - さめたコーヒー それはそれとして、Goが好きな理由を語る人はあまり見かけない気がします。この記事ではGoが好きな理由を視覚に障害のあるユーザーの視点から語ります。読み終えたところで得るものは何もありませんし、長いので覚悟して読んでください。 あなたは誰? 4年ほど業務でサーバーサイドのGoを書いています。また、業務で使いはじめる前から趣味Goに触れていました。そのため無意識の内にひいきしているかもしれません。ただし、流行っているからといって理由もなくGoを勧めたりはしません。 視覚障害ならではのコーディング事情 Goが好きな理由と深く関

    Go言語が好きな理由
    t-murachi
    t-murachi 2021/09/23
    興味深い。自分は視覚障害者じゃないのに頷ける部分が多いのは、スクリプト言語らしさが共同開発におけるメンテナンス性に根ざす問題、うまくまとめたその1行をデバッグすることの手間の多さ等に共通するからかも…
  • WindowsがLinuxより優れている点は何ですか? (OSの設計に関する質問であり、利用者の使い勝手の話ではありません) 。

    回答 (6件中の1件目) 私はWindowsのカーネルを熟知しており、Linuxのカーネルについてはそれなりに知っています。 意外に思われるかもしれませんが、類似点の方がずっと多く、違いは少ないです。私がよく言う違いの1つは、LinuxのI/OモデルはUNIXから継承した同期式が基で、WindowsのI/OモデルはVMSから継承した非同期式が基であるということです。WindowsのI/Oリクエストの設計は、同期式と非同期式のI/Oを美しく管理できる優れた設計になっています。Linux(及び普通のUNIX)でも非同期のI/Oは可能ですが、そのための統一された仕組みはありません。これは...

    WindowsがLinuxより優れている点は何ですか? (OSの設計に関する質問であり、利用者の使い勝手の話ではありません) 。
    t-murachi
    t-murachi 2021/07/18
    20年ぐらい前はforkこそが本物の並列処理であってWindowsのthreadは使い勝手の悪い間に合わせのパチもんみたいな雰囲気さえあった。今やfiberとかcoworkerとか、もっと軽いものが貪欲に求められとるもんなぁ…(´・ω・`)
  • 【PHP8.1】PHPで簡単に非同期処理を書けるようになる - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? PHPは長きにわたり同期的、すなわち、あらゆる処理を上から順に実行していくというスタイルを取ってきました。 しかしたとえば、複数のURLからデータを取ってきて結果をまとめたいといった場合、時間のかかるHTTPリクエストは同時に投げたいですよね。 この用途にはGuzzleというライブラリが存在し、これを使えば同時にリクエストを投げられます。 しかし、ではHTTPアクセスとDBアクセスを同時にやりたい場合は? 時間のかかる計算を裏でやりたい場合は? などと考え始めると、こういった個別のライブラリでは対処しきれません。 ということで汎用的な非

    【PHP8.1】PHPで簡単に非同期処理を書けるようになる - Qiita
    t-murachi
    t-murachi 2021/03/18
    構文糖衣を喧伝するのでなく、最低限の価値あるコア機能で足場を整えようという発想。とても良いと思う。
  • AWS構成図おすすめツール - Qiita

    AWSの構成図を作成する際に便利なツールを紹介します。 vscodeの拡張プラグイン「Draw.io Integration」です。 インストール方法 vscodeの左サイドにあるExtensionsをクリックし、検索窓にdrawと入力するとDraw.io Integrationが表示される。そして、Installボタンをクリックするとインストールされる。 作画ツールの表示 インストール後に新規ファイル作成ボタンを押し、 拡張子を.drawioにすると自動的にvscode上でdrawioの作画ツールが表示される。 これを使って簡単なAWSの構成図を描いていきます。 構成図 VPCを作成して、その中にパブリックサブネット、EC2インスタンス、インターネットゲートウェイを作成する。 使い方 AWSアイコンの追加 下部の+More Shapesを押すと、アイコンのセットが表示される。 ここからA

    AWS構成図おすすめツール - Qiita
  • React Server Componentsに感じたフロントエンドの消失

    はじめに 新年早々に面白そうな記事を見つけました。ReactでのAPI呼出しを最適化するために「部分的にサーバサイドで実行するコンポーネントを作る」というもののようです。 あるいは去年の記事ですが気になってたものとしてBlitz.jsでReactベースのFWであるnext.jsに永続化層を持たせてRailsのようなFWにしようというアプローチもあります。 どちらの記事も書かれてる内容自体は分かる気がするものの 「それをフロントエンドでやる意味あるの?」 というのが拭えずイマイチ腑に落ちなかったんですが、単純に 「私と最前線でやられてる方々で期待してるものがたぶん違う」 という気がしてきたので、その辺を整理のために書いてみます。 注意書き Vue.js/Nuxt.jsは少し触ったことがありますが、React Server ComponentsやBlitz.jsを触ったことは無いです 「なんで

    React Server Componentsに感じたフロントエンドの消失
    t-murachi
    t-murachi 2021/01/05
    フロントとバックを分ける意味合いが希薄しているってのはわかるけど、じゃあRoRで良いじゃん、ってのは流石に乱暴だと思う(´・ω・`)。少なくともパフォーマンスに対する考え方は随分と変遷しとるような…(´・ω・`)
  • Rubyと型についてのポエム - まめめも

    zenn.dev matz はじめコミッターの型に対する姿勢にも疑問を持っています。 というご意見が自分に刺さった気がしたので、他の話題はともかくこの点に関してだけ、ポエムを書きます。 「Rubyに型が欲しい」というのは、「もっと速い馬が欲しい」だと思っています。意味を知らない人は ヘンリー・フォード もっと速い馬が欲しい で検索してください。 これは批判でも皮肉でもありません。みんなが馬の乗り方を知っている世界では、誰も乗り方を知らない自動車より、速い馬のほうが確実で合理的です。まして、自動車が当に実現できるかどうかわからない段階では。なので、他言語で型注釈を書くことによるプログラミング体験が良いと思った人が、それをRubyでも享受したいと思うのは自然だと思います。実際、Steep や Sorbet は Ruby でそういうプログラミング体験を提供することを目指していて、すでにある程度

    Rubyと型についてのポエム - まめめも
    t-murachi
    t-murachi 2020/12/15
    言及元記事でも「フレームワークや言語は死んでも、そこで培われた思想は残る」と書かれていた通りなら、TypeProfという試みもそういう意味では評価されて然るべきと思う。