システムの技術的負債にどう挑むか?~『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策~
システムの技術的負債にどう挑むか?~『レガシーコード改善ガイド』著者マイケル・フェザーズが語る課題と解決策~
ソフトウェア開発のタスクはどのように管理するのが効率的なのか。ソフトウェアという目に見えないものを作るためにはタスクの見える化は進捗状況を図る重要な指標になります。ソフトウェア開発で発生するタスクを、バグ管理システム(BTS)や課題管理システム(ITS)を活用することで、タスクの状態とワークフローを管理しようというのがチケット駆動開発です。 チケット駆動開発については、以前に記事を書いたので、そちらを参考にしてください。 チケット駆動開発のススメ〜No ticket! No commit チケット駆動開発をうまく実践するためにはツールが不可欠です。不具合管理や障害管理で使うツールを応用して活用することも出来ますが、最近は専用のツールも出て来ています。ソニックガーデンでは、Pivotal Trackerというツールを使っています。Pivotal Trackerでは「ストーリー」と表記していま
スマートフォンの「スマート」は、さまざまなセンサやハードウェアを使うところにある。本連載で、さまざまなセンサやハードウェアを使うiOS(iPhone、iPad、iPod touch)のスマートなアプリを作ってみよう 今回は、Bluetoothを利用した通信を行うためのフレームワークである「Core Bluetooth」と、Bluetoothなどでの端末間通信のゲーム機能を含めたゲーム開発用フレームワーク「Game Kit」について、サンプルアプリを例に利用方法を紹介します。 意外と知らない? 「Bluetooth」は3種類ある Bluetoothはデバイス間における近距離無線通信を行うための規格で、「Bluetooth SIG」という団体が仕様の策定や機器の認証を行っています。本稿執筆時の最新バージョンは4.0です。 Bluetooth 4.0では、低消費電力モードに対応する規格である「B
みなさんこんにちは。@ryuzeeです。 Alan Shalloway氏のWastes of Software Developmentが良い記事でしたので、抜粋・意訳にてご紹介します。 僕のトレーニングではいつもトヨタ生産方式の話やStandishのレポートの話をしています。 7つのムダのうち特に作り過ぎのムダをなくすことはとても重要で(もちろんほかも重要)、これがないと頻繁に継続的に顧客に価値あるフィーチャーを届けることはできなくなるからです。 さらに開発のプロセスの中で、常にどこにムダがあるのかを考えて改善していくことはチームに課された責任でもあります。 例えば思いつく限り以下のようなものはムダです。 使わない機能たくさんのオプション設定読まない仕様書読まない報告書やたらと体裁にこだわった文書更新されない文書目的のない会議決定事項が守られない会議遅いPC小さいディスプレイ行動の監視目的
海外ではなぜアジャイル型開発が普及しているのか、IPA(独立行政法人情報処理推進機構)が継続的に行っている非ウォーターフォール型開発についての調査や提言活動の一環として、海外でのアジャイル開発の背景などについての報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書 (非ウォーターフォール型開発の海外における普及要因編)」が公開されました。 調査対象国は、アメリカ、イギリス、中国、ブラジル、デンマークです。アメリカはアジャイル宣言が行われたアジャイル開発先進国として、イギリスもアジャイル開発の先進国として選ばれ、中国は日本のオフショア先であり新しいソフトウェア開発市場が起こりつつある国として、ブラジルはアジャイルコミュニティが活発化しており、デンマークは政府がアジャイル開発を推進している国として選択されました。 報告書のハイライトを紹介します。 海外でなぜアジャイル
プロジェクト管理は決して精密な科学ではないが、これにソフトウェア開発が持つ予測が難しいという性質と組み合わせられると、大きな悲劇のレシピが生まれる。わたしは、ソフトウェア開発プロジェクトに取り組んでいるプロジェクトマネージャーがよく犯す過ちを数多く見てきた。それらの過ちの一部はソフトウェア開発に限ったことではないが、この文脈では特に頻繁に起こり、ダメージも大きい。 1.「人数を増やせばよい」という誤解 Fred Brooks氏は同氏の有名な言葉の中で、よくあるプロジェクト管理の間違いについて「ある女性が9カ月に1人子どもを産めるからといって、9人の女性がいれば1カ月に1人の子どもを産めるわけではない」と表現している。そして、この間違いは今でも頻繁に見られる。ある問題に多くの人間を割り当てれば、その問題は早く解決するという考え方だ。残念ながら、これは正しくない。 プロジェクトに人を1人投入す
はてなでスマートフォンアプリの開発を担当している、id:ninjinkunこと浅野慧です。近年、スマホアプリは「ユーザー体験(UX)」が非常に重要と言われており、筆者もUXの勉強に勤しむ毎日です。そんな中、エンジニア&クリエイターを支援するコミュニティ「Web CAT Studio(運営:リクルートエージェント)」が「スマートフォンUXの最前線」という勉強会を開催すると聞いて、お邪魔してきました。勉強会当日のレポートと、Web CAT Studioが積極的に勉強会を開催している理由を伺ったインタビューをお送りします。記事の終わりには、関連書籍のプレゼントのお知らせも! (※この記事はWeb CAT Studio/株式会社リクルートエージェントの提供によるPR記事です) ▽ スマートフォンUXの最前線 : ATND 「UX」とは「ユーザー・エクスペリエンス」「ユーザー体験」の略で、簡単に言う
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
Captcha security check coolcoding.com is for sale Please prove you're not a robot View Price Processing
どこにでもあるWEBの受託開発会社で働いていますが、今回やっとの思いで受託開発と並行しつつ自分が本当に使ってもらいたいと思える自社WEBサービスをオープンさせるところまで持ってこれました。自社サービスを作りたいとおもってウン年ですが、なぜ今回は作ることができたか記録しておきます。 #リリースに向けて開発しているサイト Make::Booth http://makebooth.com/press WEBサービス作りたい!けれど作れなかった… 今は受託開発の会社にいますがもともと媒体側であったので「インターネットで少しでも世界を変えるんだ!」と大志を持っていたのですが、他の受託開発会社のみなさんと同じく下記の理由で、少なくとも自分が関わったガチ自社WEBサービスは作れずにいました。 ・確実にお金になる既存受託案件が忙しく、自社サービス開発のリソースなんてない ・うちの場合はお客様と直接取引なの
Android案件を何件か担当して見積り前に確認しておいた方がいいと思うことや決めておくこと、 事前に説明しておくべきことがいくつかあったのでまとめます。 ①ハードウェアの選定 ・どの端末をサポートしますか? 動作確認を行う端末を決めてもらいます。 複数の端末をサポートする場合、テストも複数の端末で行うため工数もそれに応じて増やす必要があります。 ・サポートするAndroidのバージョンは? 端末を決めた時点でほぼ決まってしまいますが"Android 2.2以上"のようにサポートする最小のバージョンを決めます。 特にお客様にご要望がない場合はアプリのリリース時期と端末、OSのシェアなどを考慮して提案しています。 ・タブレットでの使用は想定していますか? これはスマートフォン用に開発している案件で後からタブレットでも使用したい、 というご要望を受けることがあるためです。 ・マルチデバイス対応
Android案件の見積り | クラスメソッド開発ブログ を読んで、業界人らしき人のブコメが、「この程度でホッテントリか」という感じで、僕もややそっちよりの意見だったので、ざっくり補足できそうな点について書いて見ました。もう転職して受託の立場ではなくなったので。やや発注側の視点も含まれています。 責任のないリスクについてコスト負担範囲を決める すべてにおいて最重要項目です。変化の激しいスマホ業界においては、互いのリスクテイクについての認識をあわせておく必要があります。例としてはこんなものがあります。 開発期間中に突如OSのメジャーバージョンアップがあった。 顧客「あ、新しいのでましたね。対応できますよね^^」 世論に応じて機能の根幹部分が突然リジェクト対象になる。 りんご「今日から電話番号認証禁止ね^^直さないと削除しちゃうよ^^」 過去を顧みない方針転換がなされる ぐぐる「メニューボタン
Test, 雑感, iPad, iPhone, Objective-Cテストを書く事でおこるいい事は、いろんなところで解説されているので、iOS開発に限ったもので、わりと僕の中でキたViewControllerについて。ViewContollerがデータを所持しているケーステストをしていく上で課題になるアプリケーションテスト。iOSアプリケーションなので必ずビューが存在するわけですが、こいつを操作するViewControllerが非常に厄介な存在になってくる。少なくともApple公式のドキュメントのような書き方をすると、すぐに破綻する。例えば、こういうコードをよく書くと思いますが、この時に描画されるデータが正しいかをテストする為だけに複雑で手間のかかるアプリケーションテストをする必要があるでしょうか。 - (UITableViewCell *)tableView:(UITableView
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
This document introduces Aiming, a startup founded in 2011 by Toshiaki Katayama. It previously worked on Community Engine from 2001-2003 and Play Online China from 2003-2007. Aiming focuses on building online and mobile games using technologies like HTML5, Unity, Ruby on Rails and Flash. It aims to create fun and social games and uses agile practices like Git and continuous integration. The compan
こんにちは。お仕事でiPhoneアプリを開発しているid:ninjinkunです。このエントリはiOS Advent Calendar 2011 23日目の記事です。今回はあまり注目されることがなさそうなiPhoneアプリのエラー処理を取り上げてみようと思います。 エラー処理と言うとプログラマが粛々とやるものというイメージで、主に内部のエラーハンドリングのことが中心になりがちです。しかしエラー処理はそれをユーザーに通知するところまで考えて初めて完結します。この記事ではユーザー体験の面と内部処理と両方に言及してみようと思います。自分の今までのアプリでもあまり実践できていなかったので、自戒の念も込めて…。 エラーは様々な状況で発生しますが、ここでは主にHTTP通信のエラーを想定します。HTTP通信はiPhoneのようなモバイル端末では高い確率で失敗します。移動中、地下鉄、山の中の中など通信が不
2011年12月20日に品川の日本マイクロソフト本社をお借りして、ワンクリックデプロイ勉強会を開催しました。 当初内輪でやろうと思っていたのですが多くの方にご参加いただきありがとうございました。 また、もろもろセッティング頂いた@katzchangと日本マイクロソフトの長沢さんありがとうございました。 以下にセッション資料を公開します。 例によって短文での感想を。 セッション開始前にちゃんとRed Bullを飲んでおいたので元気だった最初の会場へのヒアリングで既にワンクリックデプロイをしている人がいるか調査したところいなかった。まぁWebサービス系でやっているところは増えては来ているもののまだ定着フェーズではなさそうな感じユニットテストやJenkinsはかなりの現場で使われている個人的な今日の名言は、「障害発生時に1日でリリースできるなら、普段のリリースも1日にできるはずだ」というやつ。物
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く