収納がうまくいかないのは家事をしない男性が設計した家に住んでいるから
煽りじゃなくてマジでこれ 賃貸から要望出しまくった注文住宅に引っ越したら何も困らなくなった 男性設計士も考えてないわけじゃないんだが 片付ける側の発想ではなく、片付けてもらう側の発想で設計しているんだよね システム開発に例えるとユーザーを誘導する設計ではなく、ユーザーが勝手にうまく使ってくれると想定して設計している感じ 賃貸や建売では不可能な収納術 ものの定位置を決める 出したら出しっぱなしの人でも定位置があると片付ける確率が上がる必要なものは必要な場所の近くに収納する でかい収納だと必然的に必要な場所から遠ざかる。小さい収納を複数用意する収納との距離が近づくほど出したら出しっぱなしの人でも片付ける確率が上がる収納ボックスのサイズに合わせる ホムセンでもニトリでもいいけどサイズをきっちり合わせる見た目が整うほど出したら出しっぱなしの人でも片付ける確率が上がるできるかぎり玄関で済ませる 上着
ほんと日本の男って家電開発のセンスがないわ
現代社会を見れば共働き夫婦が多いことなんて当たり前にわかるよな なのに冷蔵庫の設計なんなんだよ 冷蔵のスペース1番でかい設計をいつまで続ける気だよ 共働きで平日にちまちま買い物行けるわけねーだろ 冷凍庫や野菜室をでっかくしろ 製氷皿のメンテナンスができる機種が三菱のみってアホなの？ 日本の男は冷蔵庫の掃除をしたことが無いからわかんないのかなー 冷蔵庫の棚もいい加減可動式にしろよ 何が「鍋も置けるように1番下の棚高さを上げました」だよ あんなもん1cmピッチで簡単に可動式にできるだろうがw ちなみに東芝はドアポケットだけ可動式になったんだが何故か片側だけwww なにその出し惜しみw 続き次はコンロとトースター。それに炊飯器 もうほとんど同じだが、洗濯機、扇風機に食洗機もだ
もっと早くデザイナーに声をかけろ
SIerのインハウスデザイナーとして働いてるんだけど、うちの会社の業務フローがクソすぎてストレスが溜まっている。 あの、PMのみなさん、ていうか我が社の開発標準つくってるみなさん。 外部設計とか機能設計とか、「設計」ってついてる工程にデザイナーをアサインしてください。 デザインって「設計」っていう意味なので。 別に、知識マウントとか偉ぶってるとかでもなんでもないです。 外部設計も機能設計も社内のエンジニアがエクセルで作っているけど、なんでデザイナーを呼んでくれないんですか？ あなたたちがやってるそれ、デザインですよね？ そのくせエンジニアは、自分が設計書を作っていても「デザイン」をしているという自覚は全くない。 それどころか「自分にはセンスが無いから〜！」と変にデザイナーを持ち上げてくるんだけど、あなたたちのやってることもデザインですよ。 なのに、自分たちだけですっかり外部設計とか機能設計
面倒くさい作りにしたせいで誤った使用法が広がったならそれは設計に問題がある
この機械ボタン押し続けな動かんな。せや！こうやったら押しっぱなしにできるで。生活の知恵や→こうして重大事故が起きる - Togetter フォロー・ブクマ外からクソリプ失礼します。 フールプルーフ機構を回避した結果、重大な事故が起き、更にはその回避方法によってそれが悪化するというシチュエーションについて話す場であるという前提のもとに、フールプルーフ機構の設計自体に問題がないかを設計者は考えるべきではないかという問題定義をさせて頂きます。 まず前提として、フールプルーフ・フェイルセーフを搭載しようとする判断自体は極めて正しいと思っております。 使用者に対して「完全に説明書を読み込み常に無限大の集中力を発揮すること」を求める設計は双方完全合意の極めて特別な場合以外は推奨されない設計であり、もし作る側が使用者に対してこのようなことを何の相談もなしに安易に求めるのならばそれはモノづくりとしては不誠
RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料
はじめに タイトルのとおり、RDBのデータモデリング・テーブル設計を行う際に参考にしている考え方と関連資料をまとめました。 P.S. なんと本記事内でいくつか参考として挙げさせてもらっている増田さん・かとじゅんさん・奥野さん・そーだいさんからコメントいただくことができました。 本当にありがとうございます。 前提 RDBを採用するのは事実を無駄なく正しく記録するため 正規化、トランザクション、制約とデータ整合性 基本的には始めに理想として集合論・リレーショナルモデルに基づいて正規化を考え(論理設計)、パフォーマンスなどの現実問題に対して折り合いをつけていく(物理設計) 制約を最大限利用する cf: ↑P91〜 ↑P.29,41 ↑P56〜 ↑5章 ↑P347～ 情報とデータ データ：単なる事実の値→これを永続化して蓄えるものがRDB 情報：データから生み出される意味や目的のあるもの→RDBか
何故 Fastly を使うのか
数ある CDN のなかでも Fastly は圧倒的に優れた特性を持つものだと思うので、障害にかこつけてその優れた点を紹介していく。 キャッシュが消えるのがはやいCDN とは世界各地にあるキャッシュサーバーにコンテンツをキャッシュして配信してもらうことで、オリジンサーバーの負荷を軽減したりユーザーへの配信速度を上げたりするリバースプロキシのホスティングサービスだが、 Fastly の最大の特徴としてはそのキャッシュが消えるのが速い。普通の CDN が数十秒〜数分とかかるのにたいして 0.2 秒で全部消えることが保証されているし、キャッシュにたいしてキーをつけておけば(HTTP ヘッダーに Surrogate-Key って入れるだけ)特定のキーがついているキャッシュだけ 0.2 秒以内に消したりということができる。 これにより、 CDN による配信高速化の恩恵を受けながら、コンテンツをリアルタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
