【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
Teach Yourself Computer Science
Note: this guide was extensively updated in May 2020. For the prior version, see here. If you’re a self-taught engineer or bootcamp grad, you owe it to yourself to learn computer science. Thankfully, you can give yourself a world-class CS education without investing years and a small fortune in a degree program 💸. There are plenty of resources out there, but some are better than others. You don’t
初心者プログラマが犯しがちな過ち25選 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 以下はThe Mistakes I Made As a Beginner Programmerの日本語訳です。 The Mistakes I Made As a Beginner Programmer 初心者プログラマが犯しがちな間違いと、それらを特定し、避けるための習慣を学ぶ方法。 まず最初に言っておくことがあります。 この記事は、誤りを犯すことを悪いと糾弾するために作成されたものではありません。 むしろ貴方が誤りに自ら気付き、あるいはその兆候を見いだし、それらを避けられるようにするために書かれたものです。 私は過去これらの誤りを犯し
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きっぽい悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになっ
本だけではわからなかったユーザビリティテストのリアル - CrowdWorks Designer Blog | クラウドワークス デザイナーブログ
こんにちは、UXデザイナーの八尾です。 京都に旅行して久しぶりに自転車に乗ると筋肉痛になりました。運動不足です。 UXデザイナーとしてデザイン組織に入り、主に定性調査を任されています。 （ユーザーインタビューやユーザビリティテストを通じてユーザーの真のニーズの把握や仮説の検証を行なっています。） 今回は、社内で初の試みであった、自社サービスの本格的なユーザビリティテスト（ユーザーテスト、ユーザビリティ評価って呼ばれたりもしますよね）について書かせていただきます。 まだ体制の整っていない中で行った手探り感と自社で定性調査を実施する上での気づきがお伝えできればと思っています。（暖かく見守ってやってください） 本を読んでみる。でも、本のようにはいかない まず、どういう流れで進めればいいのかすらわからないのでとりあえず本を読みながら考えました。 主に参考にしたのはこちらの本です ユーザビリティエン
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
グローバルゲームジャムでクラス設計をやった話2017 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #お知らせ 2017/11/26開催の「プログラマのためのUnity勉強会」において、 Unity開発で使える設計の話＋Zenjectの紹介 というタイトルで講演しました。こちらのスライドを先に見てから本記事を参照されることをおすすめします。 #はじめに 去年に引き続き、今年もGGJに参加してきました。今回もそのことを書きたいと思います。 今回の内容は以前に投稿したUnity開発で便利だったアセット・サービス紹介 & Unityでのプログラミングテクニックとつながりがあるので、こちらを先に読んでからのほうがわかりやすいかもしれません。
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
AbemaTV Developer Conference 2016のアウトラインメモ
AbemaTV Developer Conference 2016に参加してきたメモ。 途中でメモが吹っ飛んだので最初のほうがありません。 イマドキの Web サービス運営で突き当たるフロントエンド課題とつらみ 開発上の様々な依存のつらみと FRESH! by AbemaTV の話 // Speaker Deck ahomuさんすごい！！！ リニア放送型動画サービスの Web フロントエンド リニア放送型動画サービスの Web フロントエンド 動画のストリーミング配信について Flux with RxSwift FluxをRxSwiftで実装する話 dekatotoro/FluxWithRxSwiftSample デザイナーとエンジニアの境界線 デザイン 人の話 AbemaTC 社長からの要望 すぐ再生 ザッピング再生 受身的な再生 最初のモック 縦画面 pixate サービス終了..
責任(関心)を意識したアプリケーション設計 - Qiita
プログラムが上手く組めるようになりたい プログラミングが上手くなりたいと考えたときに、個人的には『名付けを意識』するのと、『アプリケーション設計のときに責任を意識する』考え方を取り入れることをおすすめしております。 今回は『アプリケーション設計のときに責任を意識する』ことについて書いてみたいと思います。 基本的には単一責任原則と、関心の分離のお話になります。 ※ タイトルに『関心』というワードがありますが、アスペクト指向プログラミングの話ではありません 単一責任原則とは まずは単一責任原則とは何かについてです。 よく単一責任原則の説明では「クラスを変更する理由は複数存在してはいけない」というニュアンスの言葉がよく使われます。 例えば、社員管理システムの実装を行いたい場合、一つのクラスに「社員登録」「出勤管理」「給与管理」などの機能を詰め込むと、『社員登録』の変更をする際にそのクラスが変更さ
契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
Design as strategy ～なぜ「戦略としてのデザイン」が重要なのか？ | Biz/Zine
デザインとは、長らく視覚的に美しいものを作ることであると考えられてきたが、戦略として捉えることで、企業にイノベーションや変革をもたらし、時代のニーズに沿った存在であり続ける助けとなる。本連載では、戦略的デザインとはどういうもので、どのように使うことができるのか、デザイン中心の企業になるためにはどうしたら良いのか、そしてデザインによって産業が発展し、世界への影響を拡大させた事例に関しても言及する。 デザインとビジネスが出会う場所では、何が生まれようとしているのか イノベーションを起こすためのツールとしてデザインを取り入れてきた企業は、業界内外における確固たる地位を築き、長年にわたり輝かしい業績を残している。昨年発表されたDMIデザインバリュー・インデックス(※1)によると、 デザインを重要視している企業はS＆P500（※2）の指数を過去10年間で219%も伸ばしている。 DMIデザインバリュ
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
データ指向設計
こんにちは、Cygames Research の多胡です。これまで10年以上コンソールゲーム開発を行ってきていて、最近ではハイエンドゲームエンジンを制作しておりました。Cygames でもハイエンドゲームエンジンの開発に携わることになりました。 ゲームエンジン開発を行う上で重要な考え方にデータ指向設計 (Data Oriented Design) というものがあります。今回はこのデータ指向設計を例を交えながら紹介させていただきます。 背景 データ指向設計の考え方は 2009年頃から有名になりました。 この 30年で CPU の性能は1万倍以上になりましたが、メモリの転送速度は10倍にもなっていません。そのため、プログラムのボトルネックはメモリ帯域となることが多くなりました。ゲームにおいても CPU はほとんどの時間がメモリからのデータの転送待ちになっています。CPU の性能を引き出すために
デザインとプロダクト開発における「割れ窓理論」
by Tobias van Schneider first appeared on my private email list. 私が「割れ窓理論」に出会ったのは、数年前、当時働いていたSpotifyの同僚が勧めてくれたのがきっかけでした。 「割れ窓理論」とは、地下鉄の落書きを消したりすることで都市の環境をきちんと整備すると、破壊行為や路上飲酒といった小さな犯罪の発生率が下がり、街に秩序を好む雰囲気が生まれるというものです。そして、それがより深刻な犯罪の発生を減少させるというのが最大のポイントです。 比較的最近のニューヨークの例を紹介しましょう。1990年代にニューヨークの犯罪発生率は劇的に下がりました。重大犯罪がこの期間アメリカ全土で28%減少したのに対し、ニューヨークは56%以上も減少しました。どうして短い間にニューヨークの犯罪発生率はこれ程大きく落ち込んだのでしょう？ 一般的に、こう
参照系と更新系の非対称性について、追補 - たなかこういちの開発ノート
以前の記事を補足、あるいは主張を一部修正するものです。 〜・〜 サブジェクト指向とは？ ある要求仕様のセットがあったとき、そこに仕様変更のライフサイクルに違いのあるサブセットが認められるならば、それらは、同一のデータ資源（＝オブジェクト）に関わることであっても、別々の“モデル”として捉えよう、というのがサブジェクト指向の一つの意図です。例えば、「受注」という同じデータ（≒管理対象）に関わることでも、「注文受付オペレーター」観点の“モデル”と「販売管理担当」観点の“モデル”とでは、要求仕様のセットが異なるし、その後の仕様変更の発生タイミングや頻度も異なるでしょう。そういった状況においては、「受注」サブドメインに関わる全ての要求を一つの集約やエンティティに全て載せてしまうと、いわゆるファット・モデルとなり、当初段階はなんとかやり遂げたとしても、その後の仕様変更の度に、当初開発段階に近い苦労を都
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GoogleによるAPIデザインガイドの公開
コードを書く際の指針として見返すサイトまとめ - Qiita
