この設計は何がダメなの?ー新人君の設計事例ー | しぶちょー技術研究所
以前、Twitterで呟いたもので反響が大きかった内容がありました。今回はその呟きに対すると皆様の回答について整理・考察していきたいと思います。 新人くんの設計事例 下記が私がTwitterで呟いた内容です。 【新人君の設計事例】 新人君が出してきた設計案。これは"やってはいけない締結"だよと色々説明したが、あまり納得してもらえず。上司も"部品強そうだし、問題ないでしょ"と一言。 個人的な感覚では、"絶対にダメな奴"なんだけど上手く納得させる説明ができなかった。皆さんならどう説明しますか？ pic.twitter.com/FYMZOu9dqx — しぶちょー (@sibucho_labo) September 5, 2020 ある日、新人君がこのような設計を提案してきました。ボルトの下は隙間になっていて、普段あまり見ない形です。詳細な意図は省きますが、他部品との干渉の関係もあり、こういう形
歴史から学ぼう!! 設計失敗学-ハイアットリージェンシー空中通路落下事故- | しぶちょー技術研究所
失敗から学べることは多くあります。例えそれが自分の失敗でなくても、失敗を考察することで教訓を得ることができます。そこで今回は有名な設計失敗事例を紹介し、その失敗を考察していきたいと思います。 ドイツの政治家オットー・ビスマルク氏は「愚者は経験に学び、賢者は歴史に学ぶ」というの言葉を残しています。それほどの過去の失敗というものは財産なんです。本記事で、過去の歴史的な失敗事例から教訓を学び、あなたの設計ノウハウとして活かしましょう！！ 今回紹介する失敗事例は ハイアットリージェンシーホテルで起きた空中通路落下事故です。 設計変更に潜むリスクを考えてみよう 事例説明の前に、まずは問題です。考えてみましょう。 上図の通路は、柱とワッシャ、ナットで支えられています。当初は”設計A案”で進めていましたが、柱が長すぎることや施工もやりづらいことから、柱を分割した”設計B案”に変更しました。これで、材料の
10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しました - Make組ブログ
自走プログラマー表紙 「自走プログラマー」という本が出ます！ この本は僕と清水川さん、tell-kさんで、株式会社ビープラウドの仕事として書いた本です。 自走プログラマーには僕の10年来の開発ノウハウを詰め込みました。清水川さんtell-kさんに至ってはもっと長い経験があります。その3人が、入門本ではない本を本気で書きました。さらにビープラウドのつよつよメンバーが何度も何度もレビューしてくれました。 僕は自走プログラマーを多くの人にぜひ読んでほしいと思っています。ですが、「とにかく買ってほしい」とはあまり思っていません。 なぜかというと、普段、 僕（著者全員）が伝えたいこと・伝えてきたことを書いた本 だからです。 なので「多くの人に読んで欲しい」、「これで助けになってほしい」と思っています。むしろビープラウドでは自走プログラマー（とPythonプロフェッショナルプログラミング）を読んでもら
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
現場で役立つシステム設計の原則メモ - Qiita
This article is a Private article. Only a writer and users who know the URL can access it. Please change open range to public in publish setting if you want to share this article with other users. ※この記事は著者の増田さんの了解の上で限定公開させて頂いております。 https://twitter.com/masuda220/status/1215122054795522049?s=20 オブジェクト指向、設計がなぜ必要か = ソフトウェア全体の整理整頓をするため 第1章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ
プラットフォームの上でものを作るということ
プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
