タグ

資料と設計に関するindicationのブックマーク (21)

  • CTO から見た,なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck

    Speaker Deck This deck requires a password Password

  • ボタン電池が素手でどうあがいても開かなかった→そのPanasonicの理由に「開かなくて正解!」となった - Togetter

    清水 潔 @NOSUKE0607 出先で電池が無くなり買った。ハサミで切れと書いてあるが無いから素手で格闘したが約10分で諦めた。これ全然開かない。もちろん子供のボタン電池誤飲防止のためだ。どれほど「開かない実験」を繰り返したのだろうか。思わず拍手した。Panasonicスゴイ。使えなかったがこれで良いと思います。 pic.twitter.com/GNKZbf6ZGl 2022-09-24 11:19:47 清水 潔 @NOSUKE0607 ニュースや情報を分析し辛口解説中。 経歴 /新聞社、出版社、テレビ報道記者、特別解説委員、早稲田ジャーナリズム大学院講師、他。「文庫X」などの著書が数冊、受賞歴多数。 ▪️メディアでの解説、講演やジャーナリズム研修、番組制作支援や危機管理を行っています。お問い合わせは「株式会社Jpエンジン」まで。 jp-engine.jp/cultural/index

    ボタン電池が素手でどうあがいても開かなかった→そのPanasonicの理由に「開かなくて正解!」となった - Togetter
    indication
    indication 2022/09/25
    switchって味も苦いのか。スゴい
  • ドメインイベントの観点から再考するソフトウェア設計

    ドメインイベントは過去に起きたドメイン上の出来事を意味します。「過去に起きた」なので後から変更できません。つまり不変(イミュータブル)なモデルです。 昨今、このドメインイベントはCQRS/Event Sourcingやマイクロサービスなどの書籍で取り上げられ、実際に実装上でドメインイベントが利用される事例も増えています。このように有益性は認識されつつありますが「うちはEvent Sourcingじゃないのでイベントは関係ありません」と視野が狭くなっている方もいます。 たとえ実装で使えなくても、ドメイン分析に基盤的な視点を与えてくれるのがドメインイベントです。 ともあれ、この資料は「そもそもドメインイベントはソフトウェア設計にどのような影響を与えるのか」を解説します。

    ドメインイベントの観点から再考するソフトウェア設計
  • イミュータブルデータモデルの極意

    2021/11/24 「イミュータブルでゆこう」イベントの資料です。 データをリソースとイベントに場合分けして考えようという至極単純な話を1時間ほどしました。Read less

    イミュータブルデータモデルの極意
  • 「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - How elegant the tech world is...!

    はじめに 前回の投稿から少し日が空いてしまいましたが、AWS x コンテナに関する商業誌を執筆したので、ブログにて少し内容を紹介できればと思います🚀 日、無事校了しました(発売日が10/21なので、結構ギリギリです)。 Amazon.co.jp: AWSコンテナ設計・構築格入門 : 佐々木拓郎 新井雅也 馬勝淳史: Japanese Books 執筆の経緯と書籍のテーマ 2020年春先、APN Ambassadorであり多数のAWS書籍を執筆されている佐々木さん@dkfj、APN AWS Top Engineersの一人である馬勝さん@HorseVictoryと一緒に技術書典#8に出展したことが事の始まりです。 執筆したクラウドネイティブファーストストーリーが多くの読者の手にとっていただけたという背景もあり、佐々木さんのご厚意により、出版社(SBクリエイティブさん)に繋いでもらいま

    「AWSコンテナ設計・構築 [本格] 入門」を執筆しました - How elegant the tech world is...!
  • モダンなソフトウェア設計の書籍 - kawasima

    型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。

    モダンなソフトウェア設計の書籍 - kawasima
  • 「ビジネスロジック」とは何か、どう実装するのか - Qiita

    アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い

    「ビジネスロジック」とは何か、どう実装するのか - Qiita
  • 歴史から学ぼう!! 設計失敗学-ハイアットリージェンシー空中通路落下事故- | しぶちょー技術研究所

    失敗から学べることは多くあります。例えそれが自分の失敗でなくても、失敗を考察することで教訓を得ることができます。そこで今回は有名な設計失敗事例を紹介し、その失敗を考察していきたいと思います。 ドイツ政治家オットー・ビスマルク氏は「愚者は経験に学び、賢者は歴史に学ぶ」というの言葉を残しています。それほどの過去の失敗というものは財産なんです。記事で、過去の歴史的な失敗事例から教訓を学び、あなたの設計ノウハウとして活かしましょう!! 今回紹介する失敗事例は ハイアットリージェンシーホテルで起きた空中通路落下事故です。 設計変更に潜むリスクを考えてみよう 事例説明の前に、まずは問題です。考えてみましょう。 上図の通路は、柱とワッシャ、ナットで支えられています。当初は”設計A案”で進めていましたが、柱が長すぎることや施工もやりづらいことから、柱を分割した”設計B案”に変更しました。これで、材料の

    歴史から学ぼう!! 設計失敗学-ハイアットリージェンシー空中通路落下事故- | しぶちょー技術研究所
    indication
    indication 2020/04/19
    なお、IT業界では
  • 要件定義~システム設計ができる人材になれる記事 - Qiita

    はじめに 株式会社デジサク がお送りするプログラミング記事、 今回は要件定義・システム設計について扱っていこうと思います。 プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。 「勉強してもプロダクトが作れない」 「そもそも開発ってどうやるの?」 「要件定義ってなに?」 その悩みを解決するために、まずは開発の全体感を理解しましょう。 下図『ソフトウェア開発プロセス』をご覧ください いつも勉強しているプログラミングは 『実装』 の部分に該当します。 つまり、プログラミングの実力を発揮する前に4つも壁が存在するのです。 そのため、記事では実装(プログラミング)を開始する前に必要となる、 『企画~設計』 について順を追って説明して行きます。 特に、エンジニアが理解しておくべき 『要件定義』『設計』 にフォーカスします。 なお、開発全体において実装(プログラミング)に使用する時間

    要件定義~システム設計ができる人材になれる記事 - Qiita
  • 現場で役立つシステム設計の原則メモ - 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章 小さくまとめてわかりやすくする 変更が大変なプログラムの特徴 メソッドが長い クラスが大きい 引数が多い 関心事を詰め込みすぎ

    現場で役立つシステム設計の原則メモ - Qiita
  • Wordな職場にSwaggerを定着させようとして失敗したけど結局定着した話 - Qiita

    はじめに 私の職場では、WebAPIの仕様書をWordで書く習慣があったのですが、2018年頃にSwaggerで書くように切り替わったので、そのように変化した経緯を書きます。 何かの参考になれば幸いです。 ちなみに、こちらの記事と同じ職場です。 Wordな職場にMarkdownを定着させるためにやった4つのこと Swaggerとは? Swaggerとは、REST APIの仕様を定義するためのフォーマットです。その周辺技術も含めて、Swaggerと呼ばれます。以下の記事が非常に参考になりますので、詳細を知りたい方はご参照ください。 Swaggerの概要をまとめてみた。 Swagger 導入失敗 2016年頃のある日、上司から「世の中にはSwaggerというものがあるらしい。調べてもらえる?」と指示されました。 調べてみたところ、Swaggerがあれば、WebAPIのドキュメントサイトも作れる

    Wordな職場にSwaggerを定着させようとして失敗したけど結局定着した話 - Qiita
    indication
    indication 2019/10/30
    相手に合わせて提案、改善できてるのすごい
  • 東京・大阪・石狩を結ぶ100Gbpsネットワーク 〜さくらのバックボーンネットワークの設計と運用(1)〜 | さくらのナレッジ

    さくらのナレッジをご覧の皆様、こんにちは。 当社でバックボーンネットワークの設計や運用、対外接続の交渉などを担当しております山口と申します。 バックボーンネットワークの設計や品質向上の取り組みについて連載にてご紹介していきたいと思います。初回は 石狩・東京・大阪 の3エリア間の新ネットワークの導入についてお伝えします。 はじめに 2019年1月中旬に、当社バックボーンネットワークの東京~大阪間を200Gbps(100Gbps x2)に増速、今まで直接の接続が無かった大阪~石狩間の100Gbpsネットワークの新規構築を行いました。また、これにあわせて単純に回線の増強を行うだけでなく、東京・大阪・石狩の3エリア間の接続をMPLSを利用した新バックボーンネットワークへ切り替えました。 今までのエリア間ネットワークの問題点 当社では、石狩、東京、大阪の3エリアにあるデータセンターで様々なサービスを

    東京・大阪・石狩を結ぶ100Gbpsネットワーク 〜さくらのバックボーンネットワークの設計と運用(1)〜 | さくらのナレッジ
    indication
    indication 2019/02/14
    経路変更を伴わないって凄い。メッシュにしなかったのは費用の問題なのかな?、何か意図がありそうなのだが、読み取れない
  • POSシステム特有のユーザー体験の障壁

    Dennisは過去10年にわたりエビデンスベースのアプローチでUXデザインUIデザインを専門とする15人の代理店Creative Navyを経営してきました。実践的なビジョンとリサーチへの深い造詣を兼ね備えています。 POSシステム(Point of sale system)は、店舗のレジにて使用され、注文を処理し、顧客を確認するために使われます。動きが遅い店員のレジに並んで待つときのイライラは、誰もが経験したことがあることでしょう。しかし、その不満も行列ができたときに店員が経験する不安と比較すれば大したことではありません。 通常のアプリとは異なるPOSシステム POSシステムのデザインは、典型的なアプリケーションと大きく異なる点が少なくとも1つあることにエンジニアは注意しなければなりません。標準的なWebやモバイルアプリのユーザー目標はアプリ内で達成されるのに対し、POSシステムでは、

    POSシステム特有のユーザー体験の障壁
    indication
    indication 2018/07/16
    POSシステムにUIが出てくると途端に、難しくなる。このUI以外に担当者なども絡むし、ポイントカードとかもややこしそう
  • オスプレイの設計は見事、そして鳥人間の罠 (3ページ目):日経ビジネスオンライン

    オスプレイの設計は見事、そして鳥人間の罠 (3ページ目):日経ビジネスオンライン
    indication
    indication 2018/05/10
    設計の話は面白い。長距離輸送かつ垂直離着陸を満たし、効率を考えて、あんな形なのか。今年の春のエンベデット試験でドローンが出てて非常に面白かった(受からない)
  • コンセプトの重要性についてうんぬん

    UXデザイナーになりたい僕らのサバイバル生存戦略 〜UXデザインUXリサーチはどうやって学べばいいの?〜 | UX BOOST!! Vol.1 Yoshiki Hayama

    コンセプトの重要性についてうんぬん
  • 結婚の話について改善の提案

    2340分の1で見つける「普通の恋」 http://d.hatena.ne.jp/hase0831/20130908 の記事を見ていて、普段感じてきた違和感を言語化できた。あわせて提案がひとつある。 自分の周囲には、かなりの数の既婚家庭がある。親族もあるけれど、多くは友人達だ。つまりは、そういう年齢になったと言うことで、自分と友人達は結婚をする年代なのである。もちろんこのご時世なので結婚していない人もいる。 そんなわけで自然と「結婚」が話題になる事が多い。そのなかでもやもやと感じてきたことが今回の記事になる。 先に結論からのべると、既婚のみんなは、そんなに配偶者のことを好きじゃない。 このことは、みんなネットには書かない。世間ではあんまり歓迎されない言説だとも理解している。提案は、それをやめようというものだ。 がっかりしないで欲しいし絶望しないで欲しい。「配偶者をそんなに大好きなわけではな

    結婚の話について改善の提案
    indication
    indication 2013/09/09
    過度の期待は破綻のもと。設計方針に使えそうだけど、なかなか、準拠が難しそう
  • Efficient data transfer through zero copy

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    Efficient data transfer through zero copy
    indication
    indication 2012/09/07
    部品粒度のお話
  • 仕様変更に強い開発をするための、ヒアリングモデル

    仕様変更に強い開発をするための、ヒアリングモデル:仕事を楽しめ! エンジニアの不死身力(21)(1/2 ページ) 今回のテーマ:仕様変更が起きる理由、そしてそれを防ぐには ある程度の経験を積んだエンジニアなら誰しも、顧客から仕様変更を依頼されて困った経験があるかと思います。 仕様変更が起こると手戻りが発生し、開発工数の増大や予算の圧迫、納期遅れなどを引き起こします。さらに。「仕様だ/仕様ではない」「言った/言わない」といったコミュニケーションのトラブルは感情論になる場合が多く、顧客との信頼関係も悪化します。エンジニアは無理な仕様変更で士気を落とし、顧客は社内調整などでいら立ちを覚えます。 せっかく開発するなら、リソース的にも感情的にも気持ち良く仕事をしたいものです。そこで今回は、「なぜ仕様変更は起こるのか?」をテーマに、仕様変更が起きる原因を探り、それを防ぐヒアリング方法を紹介します。 ヒ

    仕様変更に強い開発をするための、ヒアリングモデル
  • GitHub - MSDN Blogs

    In Visual Studio 2022 17.10 Preview 2, we’ve introduced some UX updates and usability improvements to the Connection Manager. With these updates we provide a more seamless experience when connecting to remote systems and/or debugging failed connections. Please install the latest Preview to try it out. Read on to learn what the Connection ...

    GitHub - MSDN Blogs
    indication
    indication 2011/05/30
    x32,x64及びエミュレーションについての注意点
  • Active Directory™ 障害復旧ガイド

    このホワイトペーパーは、シングルドメインを対象とした Active Directory のバックアップとリストアをご説明いたします。バックアップでは、Windows® 2000 バックアップユーティリティである Windows バックアップの概要をご紹介します。またリストアでは、1 台のみのドメインコントローラの場合や、その他のドメインコントローラに複製された場合などいくつかのパターンに分けて、詳しい手順をご紹介します。 ホワイトペーパーでは以前に公開したホワイトペーパーに対するお客様からのフィードバックに基づき、誤記を修正しています。修正内容は、ホワイトペーパー末の 更新履歴 v1.0 をご参照ください。 概要 このホワイトペーパーは、「Active Directory のバックアップ」と「Active Directory のリストア」の 2 つの項目から構成されています。 「Act

    Active Directory™ 障害復旧ガイド