技術者よ、設計しよう、仕様書を書こう | 宇宙科学研究所
私は、昨年度、工業標準化事業に対する貢献により経済産業大臣から表彰を受けました。編集委員会から私に与えられたテーマは、それについて解説せよというものです。しかし、その技術的な内容については既に本ニュースの2004年6月号において「宇宙開発における標準化と情報化」という題名で執筆しています。そこで、今回は、私が標準規格などの文書の作成に力を入れている理由についてお話ししたいと思います。なぜならば、その理由をお話しすることは、「人工衛星のような複雑なシステムをいかに効率的に開発するか」という私のシステム工学的な研究の成果を解説することになるからです。 人工衛星のような複雑なシステムの開発は、必然的に大人数のチームで行うことになるのですが、効率的に開発を行うための一つの原則は、「チーム構成員の誰もが何かしら具体的な作業を担当し、その作業結果を文書などにまとめ、プロジェクトの中で機能させること」だ
設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck
「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました
ソフトウェア開発における 「設計」と「パフォーマンス」の相互作用 / Interaction Between Design and Performance on
Software Development - Speaker Deck
設計Night2018の資料です https://connpass.com/event/104821/
「この〜を導入すると、なんとこうなりました！どうです？わかりやすいと思えませんか？」 - mizchi's blog
主にUI設計やプログラミングのAPI設計について、「わかりやすい」というのは主観的で合意が取れないのでクソという話。 定量的な指標が示されてない そもそも趣味が合わない場合はそこで終わり 〜の本来意図された機能が隠れてしまっている ↑によって隠れてしまった機能を呼び出すのが、最終的にコストが掛かる 何が言いたいかと言うと、「指標の伴わない変更に意味はない」「APIの呼び方を変える程度のラッパーライブラリやヘルパーには、特に意味がない」ということです。 ここからプログラミングの話に絞りますが、特にショートハンドしたいだけの場合、ショートハンドするAPIの実装は、必ず本来の機能を呼び出す脱出ハッチも必要となります。 よく練られていない「わかりやすさ」は、次第にこの脱出ハッチを使うことを要求するようになり、結果として捨てられることになります。この破棄までの過程は、結果的に「技術的負債」と表現され
作りたいWebアプリのアイディアを迷走せずに作る方法。まず、エディターを閉じることから始めよう - Make組ブログ
何かを作りたいときは、エディターをいきなり起動してはいけません。 エディターを閉じて、まずはイメージをまとめることに集中しましょう。 なぜこの文章が必要か なぜ何かを作る前にイメージをまとめる必要があるのでしょうか？ 頭の中には完璧な作りたいもののイメージがあることでしょう。 であれば今すぐにでもプログラミングを始めるのが賢明なように思えます。 ですがそうしてはいけません。理由は「作りたいもののイメージは単なる幻想だから です」。 頭のなかにあるイメージはとても素晴らしいものですが、多くの場合は曖昧で、触れられない、価値を検証できないものです。 それを一旦書き出して、まとめていく方法を知っておきましょう。 まとめていく中で作るものがより明確になり、自分でも気づかない価値を発見できます。 作るものをまとめて検証することで、作り始めた後の手戻りを防ぎます 作るものをまとめて明確にすることで、作
Developers.IO 2018 で「API 設計」の話をしてきた #cmdevio2018 | DevelopersIO
緊張すると声がアムロ・レイになる都元です。 ここからしばらく、キャッチコピーの迷走期が始まりますのでよろしくお付き合いください。 さて、去る 10/5 (金) 秋葉原 UDX にて開催された Developers.IO 2018、その中で 「クラスメソッドにおける Web API エンジニアリリングの基本的な考え方と標準定義」 という仰々しいタイトルで1講座持たせていただきました。 スライド 話したかったことと、話したこと 本セッションで話したかったことはだいぶ多岐にわたり、当然 40 分では話しきれないので、当初は次の 2 テーマに絞ってお話しようと考えてスライドを作っていました。 アプリケーション動作ログガイドライン RESTful / リソース指向 API 設計 しかし実際にスライドを作ってみると、それぞれで 40 分の規模となってしまい…。 ログの話は断腸の思いで見送りとさせていた
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
3つのキーワードで学ぶ、ドメイン駆動設計の基礎知識 - ログミーTech
2018年8月22日、『神姫PROJECT』などソーシャルゲームの企画・開発を手がける株式会社テクロスが主催するイベント「TECH x GAME COLLEGE」が開催されました。第1回となる今回のテーマは「ドメイン駆動設計の実践」。ドメイン駆動設計（DDD）の基礎知識と、ゲームにおける活用方法について、ギルドワークス株式会社取締役の増田亨氏が解説します。前半パートとなる今回は、ドメイン駆動設計の基礎的な概念や、既存の設計との違いについて語ります。講演資料はこちら ドメイン駆動設計の基礎知識 増田亨氏（以下、増田）：こんばんは。ギルドワークスの増田です。 実は、テクロスさんとは『UNITIA』の開発初期に京都に隔週ぐらいで何度かお邪魔して、開発チームのみなさんと設計を議論したりしました。そういった縁があって、今日は講師として招かれました。ありがとうございます。 「ドメイン駆動設計の実践」と
ボトルネックは「業務系スキル」 - 設計者の発言
私は業務システムというものが好きだ。売上そのものを生み出すしくみではないので派手さはないが、経営効率を高めるための縁の下の力持ちのような奥ゆかしさがある。そして、日本企業の特質である「顧客のわがままに柔軟に応える姿勢」を貫くための鍵が、他でもない業務システムである。効果的な業務システムをいかに効率的に設計・実装するか。それを考えたり実践することが楽しくてしょうがない。 この分野にも固有の専門性がある。まず必要なスキルは、業務連係やデータベースの設計技術、そしてシステム構成と統合された会計知識だ。適性としては、論理的な思考力や人並み以上の言語能力が求められる。これらの技能を合わせて「業務系スキル」と呼んでおくが、その重要さは実装手段が変わっても揺るがない。 ところが、開発を専業とする組織における業務系スキルの空洞化が著しい。じっさい今になって営業担当者があわてている。長い不況を抜けてやっと業
初心者でもDB設計やデータモデリングについて学べる7つのサイトと本 - paiza times
Photo by Samuel Mann こんにちは。谷口です。 「SQLは何となく書けるけど、DB設計はしたことない…」「DB設計について一度ちゃんと学んでおきたい…」という人は多いですよね。 DB設計とは、DBのデータモデル（DBの構成など）を作成する作業です。 DBを一から作ったり、テーブルを追加したりする際は、当然ですが「今あるデータが何となく格納できればそれでOK」ではありません。 テーブルは正規化できていないといけませんし、データの整合性も取れないといけません。また、効率よくデータが取れる構造になっているかどうかも重要です。 一から設計に取りかかるようなケースは少ないかもしれませんが、DBを取り扱うことがあるなら、こうしたDB設計の基本は知っておいて損はありません。むしろ自分が扱うDBの構造はきちんと知っておかないと、「なんか適当にSQL投げたらデータ取れたけど、正しく取れてる
書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた
本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部 イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2
アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS! ：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー
データベーステーブル設計の基礎の基礎〜エンティティの抽出・定義から正規化まで - エンジニアHub｜若手Webエンジニアのキャリアを考える！
データベーステーブル設計の基礎の基礎～エンティティの抽出・定義から正規化まで 適切な形でデータベースのテーブルを設計し、運用するには？テーブル設計に必要な初歩を日本MySQLユーザ会副代表の坂井恵さんが丁寧に解説します。 金融系アプリ、ゲーム、人工知能などなど……。どんな種類のシステムを開発する上でも、避けて通れない領域があります。データベースです。データを適切な形式で格納し、取り出す。単純明快ながらも奥深いこの仕組みは、多くのシステムの根幹を支えています。 しかし、適切な形でデータベースのテーブルを設計し、運用するのは簡単なことではありません。「良いテーブル設計」のためには知識と経験が不可欠です。今回は日本MySQLユーザ会の副代表である坂井恵さんに、これからテーブル設計に着手する方に向け、設計に必要な技術と、良い設計を作るための考え方を教えていただきました。 坂井恵（さかい・けい） @
Node.js における設計ミス By Ryan Dahl - from scratch
Ryan Dahl は Node.js の original author ですが、彼の作ったプロダクト deno に関するトークが jsconf.eu 2018 でありました。 Node.js にずっと関わってきた僕が見て非常に興奮するような話だったので、しばらくぶりにブログに書き起こすことにしました。 背景 Ryan Dahl は2009年に Node.js の話を初めて公の場に公開しました。その時の「公の場」というのが「jsconf.eu 2009」です。 www.youtube.com Video: Node.js by Ryan Dahl - JSConf.eu - 2009 この発表から Node.js が広まり、今やサーバのみならず、IoTデバイス、デスクトップアプリなど、様々なところで動作しています。 で、今回はその発表から9年の歳月が経過し、Node.jsに対しての設計不
「現場で役立つシステム設計の原則」はプログラミング設計の普遍的な教科書 - ビープラウド社長のブログ
日本のDDD（ドメイン駆動設計）界の父ともいえる増田亨さんが著した「現場で役立つシステム設計の原則」を頂いたので、早速拝読させていただきました。 本書をおすすめしたい人 本書は、システム開発で以下のような問題を抱えている人におすすめです。 既存システムのソースコードの可読性が低く、理解に時間がかかる 機能追加・改修時の影響範囲調査に時間がかかる 機能追加・改修時の工数が予想以上にかかる テストコードが書きにくいソースコードになりがち 機能を追加・改修時の影響範囲が大きくなりがちで、テスト工数がかさんでいる デグレの確認に気を使い、多くの時間をかけている 不具合が発生したときに、調査・解決に時間がかかってしまう 新しいメンバーがプロジェクトに参画した時に、業務知識を伝えるのに多くの手間がかかる これらの問題のために、生み出す価値以上に、仕事時間が増えている このような問題を解消し、変更に強い
どのようなデータ基盤を作ったのか？ データ収集／蓄積／加工／活用、パイプライン管理の設計
どのようなデータ基盤を作ったのか？ データ収集／蓄積／加工／活用、パイプライン管理の設計：開発現場に“データ文化”を浸透させる「データ基盤」大解剖（2）（1/3 ページ） 「ゼクシィ縁結び・恋結び」の開発現場において、筆者が実際に行ったことを題材として、「データ基盤」の構築事例を紹介する連載。今回は、データ基盤システムの構成要素や採用技術の選定理由などをお伝えします。 「使われるデータ基盤」を構築するために筆者が取り組んだ試行錯誤を紹介する本連載『開発現場に“データ文化”を浸透させる「データ基盤」大解剖』。前回はデータ活用の事例やデータ基盤が必要になった理由について解説しました。第2回となる今回は基盤システムの設計、構築についてお伝えします。 なお、技術要素としてはPythonやBigQueryを扱いますが、技術選定の考え方に比重を置いて解説します。細部にとらわれずにご自身の担当する業務や
開発現場で役立たせるための設計原則とパターン - builderscon tokyo 2018
Abstract 設計原則やデザインパターンは重要なものであると言われています[要出典]が、原則やパターンを学ぶだけでは、なかなか「どのように開発現場に生かせばいいのか」が見えてこないというのもまた事実ではないでしょうか。 あるいは、原則やパターンを適用しようと頑張った結果、高まるはずの保守性が低まってしまった、というような話も、よく聞くように思います。たとえば、DRY原則を知った直後に、なんでもかんでも「共通化」を行い、あとからそこが負債化してしまった、というような体験は、多くの開発者の「苦い思い出」として残っていたりするのではないかと思います。 このセッションでは、開発要件やコードを多く例示しながら、原則やパターンと実際の開発の間の溝を埋めることを目指します。 また、原則同士の有機的なつながりや、原則とパターンの間にある関係にも光を当てることで、「カナヅチを持ったらなんでも釘に見える」
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
慣れるUIをつくる 事例編｜UXマン / プロダクトデザイナー, UXリサーチャー
前回のおさらい 「慣れを生むデザイン」は難易度が高いですが、慣れによる体験を無視することは出来ません。 ユーザーが触るものを作るデザイナーであれば、慣れるUIを作ることやそのためのデザイン方針について考えを巡らせる必要があります。 前回は、このUIに慣れてもらうためのデザイン方針の1つとして、「寛容さ」を提案しました。 目次 4. 世界で最も使われているカラシニコフの話5. カラシニコフの教訓 世界で最も使われているカラシニコフの話ここでひとつ、ユーザーの間違いやコンテクストに寛容だったことで大成功しているプロダクトの例を挙げましょう。 世界で最も利用者の多い銃のひとつに、「カラシニコフ」という銃があります。正式名称「AK-47」という、とても有名な銃です。 この銃が世界中に拡散したのには、明確な理由がありました。 それは、保守・管理性がよく、トラブルが起きづらい、多少手荒に扱っても大丈夫
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
毎日が越境だ！
