タグ

開発に関するThailandMethodのブックマーク (12)

  • PdM/EMが気づくべき「技術負債」の異変

    技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 とはいえ、つばり一番わかり易いのは工数の予測精度の幅がある。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていることが多い。(特に、1.と3.) 一般的な視点と現場システムへの理解度のズレ詳細から開発手前での予測のズレ予測工数と実績工数のズレここでいう工数予測がズレるのはエンジニアリングスキルの問題ではなく、システムに関する理解度の認知問題によってズレるケースが該当する 1.一般

    PdM/EMが気づくべき「技術負債」の異変
  • DDDでの要件定義〜実装までの流れについて解説します

    記事では、ソフトウェア開発手法の一つであるDDD(domain-driven design)を使って要件定義〜実装を行う際のプロセスやポイントについてまとめていきます。 (書籍「ドメイン駆動設計モデリング/実装ガイド」の内容を大いに参考にさせていただいていますが、独自の内容・考察も記載しているつもりです。) DDD とは? DDD(domain-driven design)は日語に訳すとドメイン駆動設計で、ソフトウェア開発手法の一つです。 ドメイン駆動という言葉から、ドメインというものが重要そうだということは伝わってくると思いますが、そもそもドメインという言葉が抽象的でわかりにくいですよね。 ドメインは直訳すると「領域」ですが、DDD で指している「領域」とは「ソフトウェアで問題解決しようとする対象領域」です。 そして、① ドメインについての理解を深めてモデルを作成し(DDD では、後

    DDDでの要件定義〜実装までの流れについて解説します
  • たのしいドメイン駆動設計: 序 / Enjoy domain driven design : ZYO

    自分の開発に対する姿勢を根的に変えたドメイン駆動設計(DDD)。ぜひみんなにもその面白さを知ってもらいたい!と思い社内向け資料を作成、さらにSpeakerDeckにて公開としました。 たのしんでご覧ください! 関連note記事はこちら:https://note.com/jgc_parallel/n/n17db4b63affe

    たのしいドメイン駆動設計: 序 / Enjoy domain driven design : ZYO
  • 実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

    先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と

    実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
  • 開発者としての「テスト自動化」の基礎

    はじめに 連載は、開発を加速・効率化させるソフトウェアテストをテーマに解説を進めています。前回の解説で、読者の方々はソフトウェアテストの新たな分類やそのアプローチを知ることができたのではないでしょうか。 今回は、「開発者としての」という視点で「テスト自動化」の実践に向けた基を解説します。なお、ここではテスト自動化を下記のように定義することとします。 「ソフトウェアを使って、テストマネジメント、テスト設計、テスト実行、結果チェックなどのテスト活動の実行や支援をすること(ソフトウェアテスト標準用語集(日語版)Version 2.3.J02)」 その上で、皆さんが開発者にとってのテスト自動化を知り、テスト自動化をどのように実施するかチームで議論・決められるようになることを期待しています。 開発者にとってのテスト自動化のメリット テスト自動化とは人手で行うことをソフトウェアで実施することにな

    開発者としての「テスト自動化」の基礎
  • ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか?

    スクウェア・エニックスの人気RPG「ドラゴンクエスト」シリーズの最新作「ドラゴンクエストX(ドラクエ10)」はシリーズ初のオンライン作品となりましたが、その舞台裏は一体どうなっていたのか。ゲームの世界観を支えるサーバシステムがどのように構成されているのかということや、ドラゴンクエストⅩならではの仕組みや機能から開発の苦労話まで、株式会社スクウェア・エニックス開発部プログラマ森山朋輝さんが語っています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/NW/C12_P0040.html 森山朋輝: 皆様、日はお集まり頂きどうもありがとうございます。このセッションを担当させて頂きます、株式会社スクウェア・エニックス開発部所属の森山朋輝と

    ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか?
  • 【Unity】CullingGroupについて - テラシュールブログ

    CullingGroupとは オブジェクトが実際に見えている場合のみ処理を行う Renderer.isVisible オブジェクトとの相対距離で処理を切り替える サンプル CullingGroupとは CullingGroupは、見えないオブジェクトや遠いキャラクターのギミックに対して制御を行うためのAPI群です。 大きな機能は二つ、「オブジェクトが実際に見えている場合、もしくは見えない場合にのみ処理を行う」と「オブジェクトとの相対距離で処理を切り替える」といった物です。 docs.unity3d.com オブジェクトが実際に見えている場合のみ処理を行う 3Dゲームにおいて「見えている判定」というのは非常に難しい問題です。実際に目に見えていなくとも、ピクセルが塗られていなくとも、3D空間内には描画されているケースが多々あります。これはOcclusionCullingによって不要な部分を表示

    【Unity】CullingGroupについて - テラシュールブログ
  • エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita

    システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40kg痩せた!ダイエットでわかるリーンなプロジェクトマネジメント手法 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) 障害の種類と障害報告について 障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生

    エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
  • 【デブサミ2013】14-A-4レポート 「グリーにおけるスマホアプリ開発~ネイティブ編」

    サーバサイドからみたネイティブアプリ開発のポイント 両氏が所属するチームが開発しているのは、女性向けの箱庭系ゲームだ。ゲームで中心となるフローは、『ショップで植物のタネを購入』『場所を選んでタネをまく』『発育を待つ』、というものになる。では、同様の機能を従来のモバイルアプリと、ネイティブアプリに盛り込む場合ではどのような違いがあるのか。 まず、通信のタイミングが違う。Webアプリでは、ユーザの操作によりページをリプレースするごとに、1回通信が入る遷移になっている。対してネイティブでは、必ずしも1タップ=1通信ではない。フローベースで、UI、画面遷移に応じて、必要に応じたタイミングで通信が行われる。 もう一つの違いは、表示データの管理場所だ。Webアプリでは通信のたびにすべてのデータをサーバから配信するが、ネイティブアプリでは、更新頻度の低いデータなどをローカルに置くことができる。以上の違い

  • これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE

    和田卓人さんによるテスト駆動開発問題解説の寄稿です! バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中! by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上

    これであなたもテスト駆動開発マスター!?和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します~現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd|CodeIQ MAGAZINE
  • 日経ITProの記事にケチつけておく - masayang's diary

    日経ITPro: アジャイルはウォーターフォールよりも難しい 何を持って簡単・困難を定義するのかがわからないけど、「アジャイルはウォーターフォールよりもごまかすのが難しい」というのであれば、その通りだろう。 そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。 そもそも大規模プロジェクトを想定して生まれた手法は存在しないわけで。 ウォーターフォールは他に選択肢がなかったために大規模に適用されてきたけど、それが適切だったかはなんとも言えない。失敗しても他に選択肢がないんだから「ウォータフォールが悪い」って言えなかったしね。 ただ、最近は大規模でのAgile事例は増えてきている。日ではまだ少ない、というところでしょ。 「要求の増加に歯止めが利きにくいアジャイル」というのも変だよね。 当初の一欄に

    日経ITProの記事にケチつけておく - masayang's diary
  • さらに分かっておきたいトランジスタの種類 − @IT MONOist

    組み込みソフトウェア/ハードウェア開発における技術力の向上、改善・最適化などを幅広く支援する“組み込み開発エキスパート”のための情報フォーラム

  • 1