技術系の境界線 | La Verda Luno
これは 設計ナイト2020 の感想記事です。 CQRS と GraphQL の話が主な話題でしたが、ディスカッションなどで示唆に富む話を聞けたので、（レポートというよりも）考えたことを書き残しておきます。 発表内容についてはあまり書きませんが、すでに 設計ナイト2020感想 - Qiita と 設計ナイト2020に参加してきました。 | achanBlog という記事があります。 Q&A やディスカッションについても #sekkeinight 付きのツイートを見ると、何が交わされたか把握できると思います。 コンテキスト DDD・CQRS・GraphQL・アーキテクチャの進化戦略などについて深い話（触ってみたレベルでなく実運用等を経たもの）についても興味深かったのですが、サーバー再度にとっての理想的なモデルとフロントエンドの要求が衝突する境界線について考えるきっかけになりました。もしかしてサ
エンジニアの職人芸を継承すべし | 外道父の匠
『職人芸』。それは、その人にしかできない、または他より圧倒的な品質・精度・速度で仕事を遂行する技術力、というものが確かにあります。 そのような崇高な技術は、どこから来て、どこへ行くのか。そんな圧倒的ポエム回。 職人芸とは 言い方はなんでも良いのですが、組織には上級的なエンジニアが一定割合いて、おそらくその人にしかできない仕事や、手慣れていて効率的に済ませられる仕事を任せられていることでしょう。 そういうエンジニアはたいてい『職人芸』と呼べそうな技術を修得しています。例えば、高精度な設計・高難度な機能実装・的確なコードレビュー・精密な試験・堅牢な運用などなど。 システム提供を大雑把に工程で分類すると、企画・設計・構築・試験・運用 といったところでしょうか。ちょっと外すと研究などもアリですね。それぞれの工程において、集中的に従事して得る職人芸もあれば、多岐にわたる経験によって生まれる職人芸もあ
この設計は何がダメなの?ー新人君の設計事例ー | しぶちょー技術研究所
以前、Twitterで呟いたもので反響が大きかった内容がありました。今回はその呟きに対すると皆様の回答について整理・考察していきたいと思います。 新人くんの設計事例 下記が私がTwitterで呟いた内容です。 【新人君の設計事例】 新人君が出してきた設計案。これは"やってはいけない締結"だよと色々説明したが、あまり納得してもらえず。上司も"部品強そうだし、問題ないでしょ"と一言。 個人的な感覚では、"絶対にダメな奴"なんだけど上手く納得させる説明ができなかった。皆さんならどう説明しますか？ pic.twitter.com/FYMZOu9dqx — しぶちょー (@sibucho_labo) September 5, 2020 ある日、新人君がこのような設計を提案してきました。ボルトの下は隙間になっていて、普段あまり見ない形です。詳細な意図は省きますが、他部品との干渉の関係もあり、こういう形
設計書には何を書くべきなのか - terurouメモ
設計とは、 要求（やりたいこと）をヒアリングする 要求を要件（何を満たさないといけないのか）に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する（一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する） 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案（いわゆる比較表で書いていくのが楽） 検証結果 選定・合意結果（合意した代替策や妥協ラインについても記載する） 詳細設計（どういう実装にするとか、パラメーターにするとか、細
2020年からのカンファレンス設計について考えること
ここ数年、技術カンファレンスと名のつくものが急速に増えてきたと感じていました。人と人が出会う場所が増えるのは大変素晴らしいことですが、これは同時に参加者の方の期待値や需要と供給のバランスがシフトするということであり、長期的にイベント運営を考える人間は向き合わないといけない命題であると思います。 歴史的に技術カンファレンスとは情報発信と交流の場でした。今も本質的な変化はないとは思いますが、そこに人を集めるための考え方が変わってきているのではないかと私は考えています（ここでは特に数百人〜数千人規模のカンファレンスをイメージしています）。 なおこれは DevRelcon で話そうと思っている内容の下書き的な内容であり、コミュニティ•カンファレンス運営 Advent Calendar 2019のエントリでもあります。Devrelconについてはちょっとネタバレでもありますが、当日までにはもっとまと
技術的負債が紛らわしいので改善対象となる設計不備に名前をつけたい - Tbpgr Blog
システム開発に関するお仕事をしていれば、よく耳にするであろう「技術的負債」という言葉。 色々と認識が揃いにくいことや、可燃性があることで有名です。 そこで、認識の揃いにくさの理由、話題が可燃性であることの理由を踏まえた上で、よりよい名前はないだろうかという話につなげたいと思います。 なぜ「技術的負債」の認識はずれやすいか？ 技術的負債は Ward Cunningham が作ったメタファです。 何らかの業務上の利益を得るために一時的に好ましくない設計を 意図的に 選び、それを負債として考えます。 負債には利子があり、それはどんどん膨らんでいくのでいつか返済する必要があります。 こういった内容を開発者ではない経営者などのステークホルダーに伝えるための表現として存在する言葉です。 その上で、さらに議論は進み 意図的ではない 設計上の不備かそうではないかの区別には意味がないのではないか、という説が
ヘルプサイトの作り方
2019年2月16日紙版発売 2019年2月16日電子版発売 仲田尚央，山本絵理 著 A5判／208ページ 定価2,838円（本体2,580円＋税10%） ISBN 978-4-297-10404-7 Gihyo Direct Amazon 楽天ブックス honto ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 単機能なプロダクトではヘルプサイトは必要ないかもしれませんが，機能が増えると，チュートリアルやヘルプなどによるフォローなしにはユーザーがプロダクトを使いこなすことが難しくなっていきます。また，ユーザーに長くプロダクトを利用してもらうためには，機能追加などに伴いヘルプサイトを継続的に改善していくことが必要です。本書では，ユ
金属加工業界のお話
むーちゃ＠めんどくさいｵｯｻﾝ @mucha610610 ただ「働く時間が長い割には業績にならない」については思うところが多々あるので、あくまで自分の業界の範疇でつらつらツイってみる。 2014-05-31 20:55:37 むーちゃ＠めんどくさいｵｯｻﾝ @mucha610610 私は東大阪の中小企業の、金属関係の職人なんだが。 およそこの業界で頑張る割には売り上げが伸びないのって、その理由の一番は「加工・製作に失敗して作り直し」です。 2014-05-31 20:59:06
レイヤー越えが出来ない人たち - Nothing ventured, nothing gained.
物にはそれぞれの役割というものがある。 もちろん、本来の役割を超えて利用されることもある。可能性は無限大だ。 だが、ある物に固執し、本来ならば他の物で対応されるべきものまでをも無理に対応しようとすることは褒められたものではない。コンピューターシステムでは、そのような行為はコストを増大させることになったり、設計に無理を生じさせる。 spモードはなぜIPアドレスに頼らざるを得なかったか : 高木浩光＠自宅の日記 NTT DoCoMoのspモードでの障害は当初の予想よりも深刻な根本設計レベルの問題が原因であることが指摘されている。Web技術者にとって、IPアドレスとユーザーを結びつけるなどということはあり得ない。だが、NTT DoCoMoにとってはそうでもなかったらしい。 高木さんのブログでその背景などが推測されているが、今回の件だけではなく、NTT DoCoMoなどのキャリア系の人たちに共通す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
三菱電機が設計不正、自動車業界を震撼させる「偽の宣言書」
進捗率を何で測るか？ −−情報処理技術者試験の問題より | タイム・コンサルタントの日誌から
最高のITエンジニアリングを支える守りと攻めの「設計技術」と「SRE」 - Speaker Deck
設計の「なぜ」を考える | タイム・コンサルタントの日誌から