Six Apart - Tech Talk Blog: Six Apart のチーム開発 〜 コミット・ログをメールで
2006年09月07日 Six Apart のチーム開発 ～ コミット・ログをメールで こんにちは。TypePad Engineer の重田です。 今回のTech Talk Blogはチーム開発について触れてみたいと思います。 はじめに 唐突ですがにチーム開発についていくつか列挙します。 ソフトウェア開発において最も重要な資源はソースコードです チームでの開発において最も重要なのはコミュニケーションです シックス・アパートではソースコード管理にsubversionを利用しています シックス・アパートではコミュニケーション・ツールに、メール・メッセンジャー・チャット・ビデオ会議など使用しています ということで今日はコミット・ログについて触れます。 シックス・アパートでの私 シックス・アパートではリポジトリにコミットされたログがメールで送られてきます。一日に100通近いメールが届きます。Mov
人間を冗長化するという発想 - cloned.log
システムを設計する上で、冗長化というのは多くの人が当然のように考えている。重要なポイントは、複数の内の一つがダウンしても自動的にその他に割り振られることと、サービスの提供が継続（但しパフォーマンスが落ちる可能性はある）することだ。 冗長化が必要なのは人間も同じである。人間の場合も「担当者の自動変更」と「等価な行動」が重要だ。具体的に言えば、前者は病気でも退職でも理由に問わず欠員が出たときに、その人の担当分を引き継ぐべき担当者が決まっているかどうかという点で、後者はいなくなった人と同等のパフォーマンス（技術スキルであったり知識であったりマネジメント能力であったり）を発揮できるかどうかという点だ。このような人間冗長化が行われていない場合は、欠員が出た時点でほぼサービス停止状態（具体的にはスケジュールの遅延など）が発生する。 このようなことは当たり前のことなのだけど、人間冗長化をしていないのにサ
人力検索はてな - サーバなどの機器が大量に増え、命名に困っています。 サーバやネットワークの管理者にお尋ねします。 サーバやハブ、ルータなどの名前はどのように付けていますか？
サーバなどの機器が大量に増え、命名に困っています。 サーバやネットワークの管理者にお尋ねします。 サーバやハブ、ルータなどの名前はどのように付けていますか？ 機器名や役割などをそのまま名前にしている場合もありますが、今回は惑星の名前や星座の名前など、バリエーションが豊富で今後機器が増えても安心な「シリーズもの」を教えてください。 ＜回答として欲しいもの＞ ・どんな名前のシリーズか ・その一覧が出来るだけ多く掲載されているサイトのURL（カナだけではなく英語の綴りも記載されているサイト） ※２つとも必須です ＜除外＞ 以下のものはすでに調査済みですので今回は除外します。 ・惑星 ・衛星 ・１２星座やその他の星座 （自宅でLANを組んでいる方や、何かいい案を思いついた人でも回答OKです）
CNET Japan Blog - 江島健太郎 - Kenn's Clairvoyance：レグレッション・テストに逆ギレ
どうも更新が滞りがちですが、いよいよ新サービスのリリース・カウントダウンが始まりました。寝ても覚めても開発とバグ取りにいそしむ中毒状態で、メールにさえろくに返事ができておらず、ゴメンなさい！いましばらくご辛抱下さい！ 近況としては、IRS（米国税局）から「キミはちゃんと確定申告を期日までに行わなかったからペナルティじゃ」という、折り目正しくきちんと納税した人間に対してありえない通告があったので、先方が真っ先に小切手を振り出した記録をこれでもかと全部コピーして送りつけて、お前たちはドロボーかと詰問して謝罪をとりつけたり、相棒のダニーが唐突に投票権を持つ米国民の義務であるJury Duty（陪審員義務）に駆り出されて一週間まるまる留守になったり、歯医者に行ってチェックアップしてもらったら$800/月もの医療保険に加入しているにもかかわらず$4,000という高額な治療費の見積もりをもらって開いた
上司が部下を怒る法則 - cloned.log
最近、自分の周りで上司が部下を怒っていることが多い。聴くつもりがなくても耳に入ってしまい、なんだかいつも決まったパターンだなと感じるようになってきた。大体の順序は以下のような感じだ。 起 （問題点を探す） 承 （見つけた問題点を徹底的に叩く） 転 （見つけた問題点を別の問題の原因にする） 結 （見つけた問題点を最初から言いたかったと結ぶ） 解説しよう。1.は「ここはどうなってるの？」とか「○○の進捗は？」とかいった感じで状況確認を装って問題点をサーチする。ここで問題点が見つからなければ良いのだが、現実にはほぼ確実に見つけることができる。それは時間の制約、立場の制約、個人的意見の制約などから誰も非の打ちようがない行動をとることが不可能に近いからだ。ここでの問題点は非常に些細なことでも良い。（メールのCC忘れたとか、客先に傘忘れたとか） 次に2.だが、1.で見つかった問題点を「普通はこうする」
ほとんどの人が参加する会議はしてはいけない - cloned.log
そう思った。今日、自分自身が参加しない少数派の立場だった。要件の当てはまる人だけを選んでの会議なのだろうけれど、逆にそこまで厳密に情報の壁を立てる必要があるのだろうか。参加しない人間にとってみれば、「自分たちには教えたくない内容なのだ」と勘ぐりたくもなる。 ほとんどの人が会議の対象なら思い切って全員参加にしてしまおう。内容が当人に関係あるかどうかではない。コミュニティーから除者にしたという行為が大問題だからだ。参加した者は内容を知っているから、「大した内容ではない」とか「関係ない人が聞いても仕方がない」とか言えるが、参加していない者はその判断すらできない。 結局、主催者というのは参加者のことを考えることに精一杯で、被参加者のことなど頭の片隅にもないようだ。もし、そんなことはないと否定するなら、それは被参加者には聞いて欲しくない内容だったことを暗示することになるだろう。 被参加者となった気持
負荷対策概論 - Y-110's Wiki
最新文章 2018-12-26 17:10▪ 致敬英雄，致敬不朽的精魂 2018-12-26 17:10▪ 四十年来闵行人的文化生活史一幕幕回放 2018-12-26 17:10▪ “笔尖上的童画”——欢图学员作品成果展将在东方网文化活动... 2018-12-26 17:10▪ “金色热线”12月27日将迎来年终特别节目 2018-12-26 17:10▪ 北京市发布持续低温蓝色预警信号 2018-12-26 17:10▪ 北京市网信办推进自媒体账号专项治理关闭11万个 2018-12-26 17:10▪ 有创意的崇明“橘农”让梦想和情怀扎根农场 2018-12-26 17:10▪ 突发！上海地铁3、4号线晚高峰运行延误系人员进入线路 2018-12-26 17:10▪ 中国经济总量将达90万亿关键时刻传递重要信息 2018-12-26 17:10▪ 海底捞："吃出卫生巾"系人为当事顾客
多くのユーザーは一度に1本しかジュースを買わない ― ＠IT
ユーザビリティのヒント（1） 多くのユーザーは 一度に1本しかジュースを買わない 「自動販売機での不要な動作から考える」 ソシオメディア 上野 学 2006/6/2 Webアプリケーションのユーザーインターフェイスデザインに役立つさまざまなTips集。自動販売機でジュースを買うときの不要な動作から考える。（編集部） 今回からはWebアプリケーションのユーザーインターフェイスの続編の「Tips編」として、ウェブアプリケーションのユーザーインターフェイスをデザインするうえで役立つさまざまなヒントを、少し細かな視点から具体的に見ていきます。 複雑な構成物を作り上げるには、基本となるコンセプトやアーキテクチャといった抽象度の高い部分から考えていくトップダウン式のアプローチと、構成要素の細部から考えていくボトムアップ式のアプローチの両方が必要になりますが、前回までの経験則編はどちらかといえばトップダ
ITmedia エンタープライズ：SEの道は仕様書に始まり仕様書に終わる (1/3)
最近のシステム構築では仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成することも多いようだ。否定する気はないが、駆け出しのころはしっかり自分の手で仕様書を書いた方がいい。 前回は、SEを目指している皆さんに向けて、仕事に取り組む姿勢の観点からアドバイスを書いた。今回は、SEに求められるより具体的な知識やスキルの向上に役立つ話を書いてみたい。 SEとして必要な知識やスキルは非常に広範にわたる。経験を積み、上級SEになってくればより経営的な知識が求められるが、最初のころは、システム構築に必要な知識やスキルが特に重要になる。今回は、システム構築における基礎的なスキルの開発方法を紹介しよう。 仕様書を書くこと 最近のシステム構築では、仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成したり、システムを構築したりする手法が取られることも多いようだ。こういった手法
Joel on Software - 射撃しつつ前進
Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/1/6 ときどき何もできないことがある。 確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。 このような非生産的な期間は通常1日か2日続く。しかし私の開発者としてのキャリアには何週間もの間何もできずにいたということが何度かあった。言うならば、私はフロー状態になかった。私はゾーンの中にいなかったのだ。私はどこにもいなかった。 誰でも気分のむらはある。ある人々にはそれは穏やかなものだが、他の人々には、それはもっとはっきりしていて、ときには機能不全でさえある。そして非生産的な期間は塞いだ気分と何か関係しているようだ。 それ
偽装メールを見破れ！（前編） ― ＠IT
国会という公の場を使って1通のメールの真偽が問われたのは記憶に新しい。前回のコラム「メールは信頼できても信用できない」でも取り上げたとおり、普通のメールを本物だ、偽物だと証明することは非常に難しい。ましてや国会で取り上げられたような黒塗りのメール文面だけでは技術的に真偽を問うことは困難だ。 プリントアウトされた黒塗りメールの真偽を見分けるのは難しいが、普段受信しているメールならば偽装メールを見破ることもできる。手元に届けられた普通のメールを例にして読み解いていこう。 メールは1つのテキストデータでできている あなたがOutlookなどのメールクライアントで読んでいるメールは、実際には「メールメッセージ」と呼ばれるテキストデータが整形されたうえで表示されているものである。文章以外に画像やアプリケーションなどの添付ファイルが付いていたとしても、元のメールメッセージはただのテキストで構成されてい
奇跡 - babie, you're my home
動いてるのが。ある意味すごい技術力。開発者がこの場にいたらヤバかった。 転化しよう。 名前重要！ 推測が成り立つ名前にしよう！ 保守の人を罠にかけるのは良くないぞ。 ファイル名 フロントコントローラパターンじゃなくていいから、遷移とアクションが具体的にわかる様な名前にしよう！ 関数名 関数自体あんまないけどｗｗｗ UpperCamel, lowerCamel, under_scored のどれかに統一しよう！ 君の好きなヤツでいいから。 変数名 やたら wk_ や tmp_ といったあまり意味の無い prefix を全ての変数につけるのはダサイぞ！ テーブル名 マスタじゃないテーブルもプリフィクスが m_ だと混乱しちゃうぞ！ カラム名 bunrui みたいな日本語をローマ字に直したものは勘弁してつかぁさい！ 日本的なビジネス用語はしょうがないから使ってヨシ。できるだけ英語で頑張れ。tan
かたい技術とやわらかい技術 : 小野和俊のブログ
1976年生まれ。1999年慶應義塾大学環境情報学部卒業後、同年サン・マイクロシステムズ株式会社に入社。入社後まもなく米国 Sun Microsystems, Inc での開発を経験し、2000年より株式会社アプレッソ代表取締役に就任、データ連携ミドルウェア DataSpider を開発する。2002年には DataSpider が SOFTIC ソフトウェア・プロダクト・オブ・ザ・イヤーを受賞。2004年度未踏ソフトウェア創造事業 Galapagos プロジェクト共同開発者。2007年〜2010年日経ソフトウェア巻頭連載「小野和俊のプログラマ独立独歩」執筆。2008年〜2011年九州大学大学院「高度ICTリーダーシップ特論」非常勤講師。2013年よりセゾン情報システムズ HULFT事業CTO、2014年 CTO、2015年 取締役 CTO、2016年 常務取締役 CTOを務め、2019年
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
ビジネスリサーチの心得
2．ビジネスリサーチの情報収集 デスクトップ調査 の基本〜アニュアルレポートなど公開情報から… デスクトップ調査 とは、主にインターネットなどを使用して、公開情報を調査して整理・分析を行うものです。「CIAも収集する情報の95％が公開情報」ということで、情報不足とい… 2021.01.28 2021.05.13 1915 view コラム〜リサーチャーの日常 人生を通じてマッチクオリティーを追求する 知識の幅が最強の武器になる という本で初めて知った「 マッチクオリティー 」という言葉は、経済学の用語で、ある仕事をする人とその仕事がどれくらい合っているか、その人の能力… 2021.05.04 2021.05.13 295 view 2．ビジネスリサーチの情報収集 日常的な情報収集・整理術（Feedly＋Dropbox） 【 ビジネス 情報収集 と 情報整理 の基本 】いま目の前にあるリサー
japan.linux.com | 技術者の採用面接法
技術職を募集する際の面接法を扱った解説は数多くあるが、この種の面接で最も肝心な点は、おそらくは、応募者が持つ技術の評価だろう。ここでは、より確実に評価するための一法を紹介する。 応募者の技術を評価する際、筆者らが勧めているのは、応募者に初見の問題を課して自己学習能力を見る方法である。類似のものを含めて扱ったことのない問題であればなおよい。必要な資料とコンピュータを提供し、応募者が問題にどう取り組むかを見る。着実に解に近づいていたら、採用への評価はプラスである。 自己学習能力 自己学習能力の重要性は、GNU/Linuxコミュニティではよく知られている。Eric Raymondは、「How to Become a Hacker」の中で、自己学習能力はハッカーの基本的資質だと述べている。「問題こそ我が師」がハッカー流。問題への対処の仕方を教えてくれる師はいない。我々の生業では、その性質上、高度
小野和俊のブログ:アプレッソのジョエルテスト判定結果
今週末は熱海の温泉に行ってきた。 行き帰りの新幹線で読んだJoel on Softwareは衝撃的に良かった。 この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。 中でも第三章に書かれているジョエルテストが面白かったので、 これをアプレッソに当てはめて判定してみることにした。 現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。 該当する項目が2から3の会社が圧倒的に多いということなので、 判定結果としてはかなり良い方だと思う。 しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、 「今のままで特に大きな問題があるわけでもないし、 新しい方法を導入することにはリスクも伴う。 このままでも良いのではないか。」 という理由で導入を躊躇したものも多かった。 これらはどの項目についても、マネージャーがどんなに反対したとしても
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その5）
ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。 ドキュメント＝契約書 なぜドキュメント化が嫌われるのか? SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから（結果、後から手直しが多発する）だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。 本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。 こ
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その3）
ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか? 「すでに決まったはずではないか」 「そう読み取れるではないか」 「いまさら言われても困る」 よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。 これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。 1回目：顧客との契約時、仕様の確認をするとき 2回目：ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき 3回目：火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき .…にもかかわらず、3回目がほとんどだろ。この
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その2）
ウォーターフォール・モデルとは一言で説明するなら、「プロジェクトの構造化」だ。逐次実行や先手管理、進捗の予実管理なんざ、特徴的だが本質ではない。それらはキチンと構造化された後に実現できる。プロジェクトの構造化をしないまま先手管理しようとするからおかしくなる。 プロジェクトの構造化はこうやる ウォーターフォールは逐次的な開発技法であり、ウォーターフォール全体として「分析>設計>製造>試験」とはならない。顧客受けしやすいようそんな絵を書くこともあるが、実質は異なる。 「すべきこと」単位に分解して、「すべきこと」同士の順序性を決めた後、「すべきこと」同士では逐次的な関係を守らせるようにすることが本当。 「すべきこと」の分け方は「分析」「設計」「製造」「試験」ではない。これらは分断するものではない。「なんちゃってウォーターフォール」をダメにしているのは、工程（＝フェーズ）ごとにチームを割り、それぞ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
