タグ

developmentとdesignに関するtdakakのブックマーク (11)

  • 管理画面に汎用的で便利すぎる機能追加はもしかすると危険かもしれない - ぷぎがぽぎ

    以前、PHPカンファレンスで運用しやすい気づける管理画面という発表*1しましたが、今もこの考え方を大事にしながら日々サービスの運用、開発をしています。 その中で、最近思ったことがあったのを社内kibelaにポエムってあったのですが、普通に公開できる内容だったのでここにちょっと加筆して投下しておきます。 サービスに大きく影響与えるような大事な情報ってありますよね。たとえば広告配信サービスだと広告の単価設定です。そのような項目の設定作業を画面からぽちぽち1つずつ変更するのは大変なのでCSVで一括で変更できる機能をいい感じに開発すると喜ばれるという場面は管理画面を開発している人にはよくある話だと思います。そして、「この項目も設定できるようにしたい」という声がでてきて、CSVからいろんな項目が設定できる便利機能へと発展していったりすることも。 しかし人間はミスをするものです。一括変更のため変更され

    管理画面に汎用的で便利すぎる機能追加はもしかすると危険かもしれない - ぷぎがぽぎ
    tdakak
    tdakak 2019/07/30
    "「この機能って汎用すぎてなんでもできて事故につながるんじゃないか?」や「間違えて設定したら大きな事故になりそうだけど、そのときってどういう情報を後から知りたいか?」みたいな視点も大事"
  • アプリクライアントがリソース指向なサーバAPI設計に期待すること - Qiita

    酔いどれ設計ナイト2019 - connpassの発表資料です。 イベントのテーマ 「DB設計とAP設計をつなぐナニカ」 ということでこの記事では、アプリケーションサーバの利用者であるクライアントの視点から、どういう構造が嬉しいのか語ります。 自己紹介 iOSアプリ設計パターン入門というの前半で、「設計とは何か」という主語の大きい話をしたり、GUIアーキテクチャの40年の歴史をまとめたりしました 題材をSwiftに絞っただけで、内容としては他プラットフォームにも通用する感じのやつなのでよかったらおひとつどうぞ Qiitaだと、お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiitaという記事がよく読まれてます 議論の前提 今回の議論にはいくつかの前提があります。 クライアントチームとサーバチームが充分に協調し

    アプリクライアントがリソース指向なサーバAPI設計に期待すること - Qiita
  • 設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck

    「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ)ので、2/3くらいにまとめました

    設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck
  • DCI Tokyo 1 - Lean Architecture by James Coplien - が開催されました(前編)

    1月10日に六木ヒルズにて、James Coplien氏をお招きしてLean Architectureに関する勉強会を開催しました。UUUMさんに大変素敵な会場を提供頂き、スタッフ含めて40名前後の参加者が集まりました。 このブログでは、当日の翻訳担当を務めた@remoreと@ganchikuが、当日の翻訳内容から抜け落ちた部分の捕捉を含めて、内容のアウトラインを簡単に振り返れればと思います。セッションの前半部分は@remoreが、後半は@ganchikuが解説を担当します。 なお当日のCoplien氏によるセッション内容は、許可を得た上でYouTubeにアップロードされていますので、より深くご覧になりたい方はこちらも併せてご参照下さい。 DCI Tokyo 1 - Lean Architecture by James Coplien (Part 1 of 2)DCI Tokyo 1 -

    DCI Tokyo 1 - Lean Architecture by James Coplien - が開催されました(前編)
  • 今あえてDRY原則に向き合う

    "I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)

    今あえてDRY原則に向き合う
  • チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog

    Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査(査読)を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit

    チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
  • OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ

    YAPC::Asia Tokyo 2015 前夜祭に参加して、柴田さん( hsbt さん)とモリスさん*1( tagomoris さん)の講演を聴いた。特に最後のモリスさんの講演を聴いていて、ちょっとした衝撃を受けると共に、気づきや疑問もあったので、久しぶりに blog エントリを書こうという気になった。 なお、このエントリは講演メモや浮かんだ疑問、その後の議論等を記したものであり、すっきりとした結論は無いのでご注意。 モリスさんの講演 講演資料が公開されていた How to create/improve OSS products and its community from SATOSHI TAGOMORI 講演時に取ったメモがこちら 我々にできるOSSとそのコミュニティの育てかた ======================= id:tagomoris TD のモリスさん TD はデー

    OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ
  • hidenorigotoの開発日誌(1) | QUARTETCOM TECH BLOG

    カルテットコミュニケーションズの開発部で仕事をし始めて、そろそろ2ヶ月になります。ここでの私の仕事は、バリバリ開発もしながら、チームメンバーにメンタリング(おせっかい?)したり、ソリューションの提案をしたりすることです。 このなかで、開発について私のやったことを、私の考え方を断片的にでも伝える目的で、開発日誌としてブログ記事にしておきます。 カルテットコミュニケーションズの開発部の中心的な業務は、リスティング広告運用のための総合支援ツール Lisketの開発です。一口にリスティング広告の運用といっても、Google/Yahooがそれぞれ検索連動型広告とディスプレイ広告を提供しており、最低でも4種類の広告プラットフォームを相手にすることになります。そして、それぞれのプラットフォームで必要な作業手順が微妙に異なっている上、扱う情報がかなり大量になるため、運用業務の様々な局面において、ソフトウェ

    hidenorigotoの開発日誌(1) | QUARTETCOM TECH BLOG
  • 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita

    あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし

    新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
    tdakak
    tdakak 2014/05/14
    歴史おもしろい
  • デザインパターンとともに学ぶオブジェクト指向のこころ を読んだ - takatoshiono's blog

    読んだ理由 最近、ソフトウェアの設計力が不足していると感じる。もっといい感じにクラスを設計して、オブジェクト指向ぽいプログラムを書けるようになりたい。しかもスピード感を持ってやりたい。ということで、いまさらだけど、オブジェクト指向についてもう一度学んでみようと思った。を読めばいいという訳じゃないけど、とりあえずもっと知識を増やしたい。渋谷の東急百貨店 7F の丸善&ジュンク堂書店に行って、 オブジェクトデザイン (Object Oriented SELECTION) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の3冊で悩んだ結果、これを買った。決める要因となったのは、 ついでにデザインパターンについて理解を深められたらいいなと思った これまで

    デザインパターンとともに学ぶオブジェクト指向のこころ を読んだ - takatoshiono's blog
  • FURTURE ORIENTED PROGRAMMING

    Future Oriented Programming Akihito Koriyama / @koriym About Me Akihito Koriyama @koriym 6502 to PHP The psychology of time "あなたの決断を決定するのは何か?" 授人以魚 不如授人以漁 Past Oriented Experience 実績や経験 Well known method 良く知られた手法 Conservative decision making 保守的な決定 Present Oriented Learning Cost 学習コスト Development Cost 開発コスト Rapid Application Development 早期プロトタイプ Market Share みんな使ってる? Googleで解決できる? Is it cool ? 快適?

    tdakak
    tdakak 2014/04/22
    意思決定のプロセス/視点の違い/PAST ORIENTED, PRESENT ORIENTED, FUTURE ORIENTED
  • 1