不確実性とうまくやっていくためのプログラミング設計論 - dely Tech Blog
こんにちは。delyのTech Leadのうめもりです。 これはdely Advent Calendarの25日目の記事です。ほかの記事についてはこちら qiita.com adventar.org をご覧ください。 昨日はプロダクトマネージャー兼開発部ジェネラルマネージャーをしている奥原 (@okutaku0507)が tech.dely.jp という記事を書いてくれました。ご興味あればそちらも是非ご覧ください。 25日目の記事は、みんな大好き技術的負債の話をしたいと思います。 はじめに 「技術的負債」 我々プログラマーからすればうまく付き合っていく必要のある厄介な存在であり、「何故技術的負債を解消していかないといけないのか？」というトピックは定期的にプログラマー界隈でも話題になりやすいものです。 時にはビジネスサイドに技術的負債の存在やその厄介さについて説明する必要が生じることもあり、
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
API 設計ガイド | Cloud APIs | Google Cloud
フィードバックを送信 API 設計ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 変更履歴 はじめに これは、ネットワーク API の一般的な設計ガイドです。2014 年以来 Google 内部で使用され、Cloud API やその他の Google API を設計するときに Google が従うガイドです。この設計ガイドは、外部のデベロッパーへの情報提供と、互いの連携作業の効率化のためにここで共有されています。 Cloud Endpoints のデベロッパーには、このガイドは、gRPC API を設計するときに特に役立つことがあり、そのような場合にはこれらの設計原則を使用することを強くおすすめします。ただし、このガイドの使用は必須ではありません。Cloud Endpoints と gRPC はガイドに従わなくても使用できます。 このガイドは、gR
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
「データベース実践活用」の連載をはじめました - sifue's blog
本日発売のWEB+DB PRESS Vol.81からデータベース実践活用という記事の連載をはじめました。次回と次々回まで自分が担当する予定です。 WEB+DB PRESS Vol.81 作者: 長嶋享,藤吾郎,八木俊広,日高一明,滝口健太郎,田中慎司,泉水翔吾,海野弘成,佐藤太一,吉村総一郎,伊藤直也,川上大喜,こしばとしあき,舘野祐一,中島聡,橋本翔,渡邊恵太,はまちや2,竹原,川添貴生,沢渡真雪,WEB+DB PRESS編集部 出版社/メーカー: 技術評論社 発売日: 2014/06/24 メディア: 大型本 この商品を含むブログ (1件) を見る 第一回目は、オブジェクト指向プログラミングを利用したDAO設計パターンの紹介です。DAOってあれですね、データアクセスオブジェクトです。RDBとかKVSとかファイルとかごにょごにょするオブジェクト群のことですね。 最近は、ORMとかいろいろ
アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った - 水まんじゅう2
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
質の高いAPIを作るための7つの習慣
PHP7 で堅牢なコードを書く - 例外処理、表明プログラミング、契約による設計 / PHP Conference 2016
PCサイトのUIデザインにおける12のトレンド
メンテナブルでありつづけるためのCSS設計
Martin Fowler氏の語る“犠牲的アーキテクチャ"
開発効率アンチパターン
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
イマドキCSS設計