一番不思議なのははてなにいる一生独身おじさんおばさんが投資とかしてどうすんのってこと今がギリギリ体も頭も動くお金を使う最後のタイミングでしょ そこで投資とかいって金を死蔵して一体どうしたいんだろう
設計に現場スケッチしてもらった部品、穴の位置が合わない→「キリの良い寸法じゃなかったので四捨五入しました」
みん@機械探求者 @mins2k 設計に現場スケッチしてもらったブラケットを取り付けに行ったのだが、、、微妙に穴位置が合わない！ 私「部品つきませんよ、ピッチ違うよ、何で？」 設「あー、、測ったらキリの良い寸法じゃなかったので四捨五入しましたけど、、」 四捨五入、、四捨五入？、、四捨五入！？ 2023-10-17 17:34:46
「ファイル名に”yyyymmdd_hhmmss”がついてますが同タイミングで動かしたらどうなりますか」とレビューされて震えた話
リンク 朝日新聞デジタル マイナカードで誤交付、自治体・富士通に報告求める 個人情報保護委：朝日新聞デジタル マイナンバーカードを使った証明書のコンビニ交付サービスで、他人の住民票などが誤って交付された問題をめぐり、個人情報保護委員会は11日、関係自治体やシステムを納入した富士通Japanに対して、報告や資… 9 ゆーしゃん.py(bot運用中) @Mr_mura_ura 客「ファイル名に「yyyymmdd_hhmmss」がついてますが、完全に同タイミングで動かしたらどうなります？」 私「こんな小規模な社内システムでそんな事無いと思いますが…エラー落ちしますね…」 客「まぁ99%無いと思いますが、念のためにね」 というレビューをつい最近受けた私、震えてます← 2023-05-11 00:02:16
「オブジェクト指向神話からの脱却」という特集をWEB+DB PRESSで書きました - きしだのHatena
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開
面倒くさい作りにしたせいで誤った使用法が広がったならそれは設計に問題がある
この機械ボタン押し続けな動かんな。せや！こうやったら押しっぱなしにできるで。生活の知恵や→こうして重大事故が起きる - Togetter フォロー・ブクマ外からクソリプ失礼します。 フールプルーフ機構を回避した結果、重大な事故が起き、更にはその回避方法によってそれが悪化するというシチュエーションについて話す場であるという前提のもとに、フールプルーフ機構の設計自体に問題がないかを設計者は考えるべきではないかという問題定義をさせて頂きます。 まず前提として、フールプルーフ・フェイルセーフを搭載しようとする判断自体は極めて正しいと思っております。 使用者に対して「完全に説明書を読み込み常に無限大の集中力を発揮すること」を求める設計は双方完全合意の極めて特別な場合以外は推奨されない設計であり、もし作る側が使用者に対してこのようなことを何の相談もなしに安易に求めるのならばそれはモノづくりとしては不誠
オオバ@UIエンジニア on Twitter: "仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR"
仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的… https://t.co/6nwzoBNKWR
型変換やオブジェクト変換の関数/メソッドに対する習慣や知見
Noriyuki OHKAWA @notogawa データ型Aとその操作を定義しているモジュールX.Y.Aてよく作ると思うけど，型Bと型Aの間の変換操作をＸ.Y.A内から露出させるときにfromA/toAはやめてくれー．toB/fromBにして欲しい．import X.Y.A as AでA.toB/A.fromBだから． 2016-11-18 09:52:37 Noriyuki OHKAWA @notogawa データ型Aとその操作を定義しているモジュールX.Y.Aてよく作ると思うけど，型Bと型Aの間の変換操作をＸ.Y.A内から露出させるときにfromA/toAはやめてくれー．toB/fromBにして欲しい．import X.Y.A as AでA.toB/A.fromBだから． 2016-11-18 09:52:37
DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。
※追記あり。最後の追記は 2021/04/25 21:40頃※ タイトルの通りのことを思っているけど、顕名のブログで書くと社内で干されるので、増田に書く。社内の心理的安全性がそんなに低い訳ではないけども、潮流が凄いので今は慎重に振る舞いたい。 この記事を見て「キミはDDDのことを誤解している」と思われた方はコメント等で優しく（易しく、ではない）ご指摘願いたい。 ※この記事では Web Application を前提とした話になっている。 DDDとは？https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88 DDD、ここがイケてる ソフトウェア開発者は開発対象のドメインのことをほとんど知らない、という問題意識およびその提起。 俗に言う「ビジネスサ
外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌
このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性
「パパの書くプログラムってif文すごく少ないね」 → 「よく気がついたな。if文をあまり書かないよう設計すると皆に喜ばれるぞ」
ミノ駆動 @MinoDriven 昨日ゲームプログラミングしてる最中 うちの子「パパの書くプログラムってif文すごく少ないね」 僕「よく気が付いたな。同じ動きのコードでも何も考えずに書くとif文だらけで読みにくくなるんだ。if文をあまり書かないよう設計すると皆に喜ばれるぞ」 とインプットしておいた。 2020-02-25 11:48:13
Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita
初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日本の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、 そこに設計書として文字と図と表を記載する方式。 メリット 一つのファイルに文字と図と表がまとめて記載できる テキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しい できなくはないが面倒くさい UMLモデ
東京のどまんなか、10平米のひみつ基地。中銀カプセルタワーで2ヶ月暮らした人のレポ
あぁ、夢の中銀カプセルタワー… 知らない方のために説明すると、「中銀カプセルタワー」は銀座にある黒川紀章設計のマンションです。 複数のカプセルから成り、それらを取り替えることで細胞のように新陳代謝されるビルとして設計されましたが、1972年の竣工から現在に至るまで、カプセルが取り替えられたことはありません。 70年代に思い描かれた「近未来」感と、退廃的な美しさに魅了されたマニアも多いです。 リンク Wikipedia 中銀カプセルタワービル 中銀カプセルタワービル（なかぎんカプセルタワービル）とは、黒川紀章が設計し、世界で初めて実用化されたカプセル型の集合住宅（マンション）である。1972年（昭和47年）竣工。 黒川の初期の代表作であると共に、メタボリズムの代表的な作品である。 それぞれの部屋の独立性が著しく高く、部屋（カプセル）ごとに交換することも、技術的には可能な設計になっているが、実
システムで「性別」の情報を扱う前に知っておくべきこと - Qiita
0は性別に関する情報が得られない場合に使います。性別に関する情報はあるのだけど1とも2とも言えない場合は9を使います。要は「0でもなくて1でも2でもなければ9」です。 これを知っていればMだとかFだとかを議論をせずに済みますね。 国際規格に従うべき理由 国際規格に従うことは色々と利点があります。まず、どうしてそういうコード体系にしたのかを説明しやすいです。また多言語対応する際も規格通りに書けば伝わるはずなので迷わずに済みます。別システムへのデータの移行や、異なるシステム間でのデータの統合もコード体系が同じならラクラクです。もしかしたら別のプロジェクトで書いたコードをそのまま使いまわせるかもしれません。技術者に対するトレーニングも不要です。 対して、わざわざ国際規格に反する実装をする場合は上記のメリットがそのままひっくり返ってデメリットになりはしますが、もちろん、それなりの理由があれば規格と
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
もういい加減「nullチェックをしたら安全」とかわけのわからないことを言うのはやめよう - Qiita
（僕の主観で）クソな記事をたまたま読んでしまってもにょったので愚痴。 Safe Harbor Statement 以下の事項は個人の見解であり所属する組織の公式見解ではありませんし、明日になったら違うことを思っているかもしれませんがそういう類のものです。 某所で危険と言われていたコード public void hogeMethod(Hoge hoge) { //hogeを使った処理 hoge.doSomething(); return; } 安全な理由: NullPointerExceptionが発生しない 僕がいいたかったこと それ、NPEを握りつぶしているだけですから！！！！！！！ (とくにJavaの世界においては)非検査例外というのはコーディングバグを示してくれるものですから、へんなnullチェックをいれるのではなく、積極的にNPEを発生させていきましょう。 こういうわけのわからない
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
「絶対要らないハズだけど、なかなか削除できずにいるもの」を対応した小話 | メルカリエンジニアリング
はじめましてこんにちは。SREの@masartzです。 私は最近joinしたのですが、今回は本番環境に古くからあるテーブルの掃除作業をした案件をご紹介します。 tl;dr; 本番の住所情報テーブルを消したけど問題なかった話 絶対要らないハズだけど、なかなか削除できずにいるもの を対処する話 本番環境の住所情報テーブルをdropするまでの作業 今回、本番環境の住所情報テーブルをdropしました。 と言っても、事故でもうっかりでもなく、既に使われていなかったものの整理という作業でした。 何故使われていなかったかというのは、メルカリの住所情報の保持の仕方の変遷が関係しています。 初期にはuser情報と住所情報は1対1の関係でした。イメージとしては以下です。 CREATE TABLE IF NOT EXISTS users ( id INT UNSIGNED NOT NULL, name VARC
電車の座席が窮屈な理由は｢肩幅｣にあった
通勤電車のシートに座っていたら隣の乗客が下車。次にその席に座った人が大柄で窮屈な思いをした――。こんな体験をした人は少なくないだろう。 たとえば横1列に7人が並んで座れるロングシート。以前は色分けやくぼみなどによる座席区分はなかった。小さい子供が座る場合、1人分のスペースを必要としないので、浮いたスペースを有効に使えるし、車内がそれほど混んでいない場合は、乗客同士がほどよく隙間を空けて座ることもできる。しかし、誰か1人が中途半端な位置に座ると6人しか座れない。そこで、最近の通勤列車では7人が隙間なく座れるように、座る部分にくぼみを付けたり色分けしたり、あるいはロングシートが2人、3人、2人と区分できるように仕切り棒を付けたり、といった座席区分を行なっている。 JIS規定のシート幅は43センチ とはいえ、7人が整然と座ったとしても、隣の人が大柄だったり、あるいは隣の人がひざの上に大きな荷物を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
逆なのよ逆。子持ちokの男性が検索可能であるべきなのよ
https://twitter.com/sshinohe/status/1536021284261285889
