JJUG CCC 2012 fall / 札幌Javaカンファレンス2012での発表資料です。 ソースコードは https://github.com/shuji/demo-refactering-unittest から取得してください。
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます ここ数年、ソフトウェア開発の世界は比較的穏やかだった。しかし、HTML5が地歩を固め、Windows 8がWindowsの開発シーンに大きな変化を迫っている今では、ジェットコースターの日々が戻り、スピードはますます上がってきている。もし最先端に居続けたいのなら、少なくともこの記事で挙げる10のソフトウェア開発スキルを身につけることを検討すべきだ。 1.モバイル開発 モバイル開発を学ぶのに時間を割く価値などないと考えているのなら、考え直した方がいい。2011年のAndroid携帯の世界出荷台数は、ほとんどPCの販売台数と同じだ。他の有名なモバイルデバイス(iPhone、iPad、そして「瀕死状態」のRIMデバイス)を加えれば、販売台数で見
先日からContinuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automationの読書会をしているというのは、日記にも書いた。*1 本日は第3章Continuous Integration(継続的インテグレーション)だ。早瀬さんが2号館のカフェテリアでやろうというので、近所のコンビニでビールとつまみを買いこんで参加した。(うひひ) コンビニ袋にビールとポップコーンを突っ込んでカフェテリアに登場したところ、目ざとくビールを発見され、「おっビール」と言われるのだが、「えっビールじゃないんですか」と返す。早瀬さんもわたしのビールにつられてドリンクとつまみをコンビニに買出しに行った。 そんなこんなで、飲みながら第3章は始まったのであるが、その前にわたしのヨタ話を披露した。 Conti
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記:一部修正した。 ※追記:Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念~Velocity: プログラマの思索 ソフトウェア開発に特有な技術~ソフトウェア見積り: プログラマの思索 チームは加速するのか~Velocityの使い
すぺっく 仕事:ソフトウェア開発 性格:ヒッキー。 立場:特定派遣。メンバーは自社の人。人事権はない。 何の因果か、リーダーとかやるはめになったのでその経験を書いてみる。 技術的な話はない。 ■方針:プブチャラティの精神。 「任務は遂行する。部下も守る。両方やらなくちゃならないのが『幹部』のつらいところだな。覚悟はいいか? 」 プブチャラティさん!俺やるよ! …というわけで、尊敬するプブチャラティさんの姿勢をすべての行動の方針とした。 ■実際にやったこと。 ○作業日誌を送りつけた。 本日やった作業とともに顧客と自社の上層部に送りつけた。 われわれたはちゃんとやってますよという言い訳と、問題が発生した場合に上司に詰め腹を切ってもらうため。 ○朝会 毎朝、問題点と作業の状況を2,3分で確認した。 これで、問題点を抱え込まない状況を作り出すのと、一体感、連帯感的なものを演出した。 ○作業の目的を
統計や実証を通してソフトウェア工学を研究していく、それが「エンピリカルソフトウェア工学」(Empirical Software Engineering、実証的ソフトウェア工学)です。「第一回エンピリカルソフトウェア工学研究会」が、12月10日に都内で開催されました。 基調講演では、マイクロソフトリサーチで研究をしているDr. Thomas Zimmermann氏が登壇。開発組織の構造がソフトウェアにどう影響するのか、バグ報告書やバグ報告者と修正されるバグの優先順位の関係、そしてエンピリカルソフトウェア工学という「データ指向のソフトウェア工学」を、どのようにソフトウェア開発における意志決定に役立ていくのか、といった内容の講演でした。 開発組織の構造がソフトウェア品質に及ぼす影響は? マイクロソフトリサーチのDr. Thomas Zimmermann氏。 今日はいくつかのテーマについて紹介した
俺は普段こういう運用でやっているが、君はどうか。 社内の trac にドキュメントをかいたので、コピペしておく。git についてはカジュアルにつかってるだけなので、もっとこうしたほうがいいんじゃねえのというのがあればおしえてください。 ブランチ命名規則master 本番の deploy 用。誰かに deploy されてこまるものはいれない。stg ステージングの deploy 用iss(\d+) チケット$1 用の topic branch。master から分岐させるその他、キャンペーン関係など、おいやすくしたい者は別途名前つけてもよし。 stg の運用基本的に、開発はチケットにひもづく topic branch でおこなうので、以下のような作業フローとなる git co master git co -b issXXX # トピックブランチをきる ... # development gi
「ビジネス上のコミュニケーションを、メールの不便さから解放したい」という思いから2009年にサイボウズがスタートした無料コラボレーションツール「サイボウズLive」。その開発現場は、Webアプリケーション開発の流行をうまく取り入れたアジャイルなものでした。その様子を、はてなチーフエンジニアの大西康裕がインタビューしました。テーマは、プログラミング言語の選び方から、自動ビルドと自動テスト、リファクタリング、チーム内コミュニケーションなど。大西自身も「面白かった」と語る取材の様子をぜひお楽しみください。記事の最後ではプレゼントもご案内しています。ところでこの取材には、サイボウズ・ラボの竹迫良範氏が、なぜか大量のレッドブルを抱えて登場したのですが……。 http://live.cybozu.co.jp/ (※この記事はサイボウズ株式会社提供によるPR記事です。) 大西 はてなチーフエンジニアの大
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
Web 制作のことを中心に、ちょっとした Tips などを掲載しています。「自分用メモ」が基本スタンス。 btmup Blog ディレクトリ名とかファイル名って、ちゃんとしようとすると意外に時間がかかるもの。 ページタイトルを直訳すれば良いってもんでもなく、いくつかある候補から内容に一番合った単語を見付けてこないといけない。 いちいち英語を調べるのもメンドいし、かといって「gaiyo」とかじゃ気持ち悪いし、どうしたもんかねー、とずっと思っていました。 で、今回、勢いでざっくりとまとめてみたのでついでに公開します。 本当にざっくりなので抜けもあるだろうし「それくらい書かんでも分かるわボケ」なものもあるでしょうけど、まぁそれは追々。 ディレクトリ名やファイル名として使用することを前提としているので、文法とかは全く考慮してませんので悪しからず。 最近、医療・病院関係のサイトに仕事で関わることが多
OSC 2010 北海道の発表で使用したスライド資料「PHPで大規模ブラウザゲームを開発してわかったこと」 Tweet 2010/6/28 月曜日 matsui Posted in PHP, お知らせ | 7 Comments » 先日6月26日、札幌で「オープンソースカンファレンス2010 北海道」が行われ、無事終了することができました。 当日は来場者数が過去最高の約450名となり、閉会式は会場に収まりきらないくらいの大盛況でした。 ご来場者の方々、スタッフ・事務局の方々、本当にありがとうございました。 私も1コマセミナー枠を戴くことができまして、弊社で「ブラウザ三国志」というゲームのプログラム開発を行った際の苦労やノウハウなどをまとめた、「PHPで大規模ブラウザゲームを開発してわかったこと」という発表を行わせていただきました。 お越しいただけなかった方のためにも、その際に使用したスライ
数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発(内製)を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く