近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Web 開発者の責任 (翻訳): Days on the Moon
John Resig 氏による A Web Developer's Responsibility という記事が素晴しかったので、著者の許可を得てここに日本語訳を掲載します。 Web 開発者の最大の負担は、ブラウザのバグと非互換性への対応に膨大な時間を費やすことであるといって間違いないでしょう。それゆえに、それらへの対応に不満をいうのは、Web 開発者全員の常となっていました。ブラウザのバグは迷惑でいらだたしく、仕事を大幅に難しくします。 ブラウザのバグはとてもいらだたしく、通常の開発における最大の負担です。ですから、開発対象のブラウザが、自身のバグを見つけ修正できるようにしてやるのは、すべての Web 開発者にとっての責任です。自分が見つけたバグに対して責任を持ち、「ほかの誰かがこれを見つけるだろう」とは思わないことで、ブラウザの進歩の速度は加速していくでしょう。 ブラウザを支援する解決策
内部WebAPIの呼び出しコスト - MVCモデルの”次” - Tous Les Jours 攻防記
デブサミ２００９でid:secondlife氏が発表されたという資料を見てみました。 http://www.slideshare.net/hotchpotch/deb2009-1023281 はてぶをフルスクラッチでリニューアルした際に、従来のMVCモデルからさらに一歩進んで抽象化を進めたとのことで。 資料中、MVCの発展系として、MVACなる概念が提唱されているのですが、Aは「Applicaiont」？？「アプリケーションレイヤの作成」という記述もあるし、たぶんApplicationのtypoですねきっと。 資料からは「データソース層」「サービス層」「アプリケーション層」の３層が「Model」「View」「Application」「Controller」にどう対応するのかよくわからなかったけど、おそらく「サービス層」を担当するのが「Application」なのでありましょう。 そして、「
ソフトウェア品質の12の属性
システム開発において「品質の向上」という標語がしばしば掲げられますが、 「品質の属性」については無頓着なケースが多いのではないでしょうか。 ひとくちに品質といっても多様な属性があります。 顧客と品質の話で揉めたことはありませんか？ 品質には多様な属性があり、単一の軸で良しあしを決められないという側面があります。 そのため、単に「品質」と言ってしまうと認識に齟齬が生じるのです。 Karl E. Wiegers氏が著書 「ソフトウェア要求」 で挙げた、すべてのプロジェクトが検討すべき12の属性は以下のとおりです。 可用性availability 動作可能時間の指標。システム故障までの平均時間MTTF(Mean Time To Failure)を 平均修復時間MTTR(Mean Time To Repair)とMTTFの合計で割った値。稼働率とも呼ばれる。 効率性efficiency 同じ処理性
Linus「C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが 簡単に生産されるようになってる」
/15 [4] (21:54) 原文: http://lwn.net/Articles/249460/ From: xxx To: xxx Subject: Re: [RFC] builin-mailinfo.c をマシな文字列ライブラリを使うようにすること Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST) Message-ID: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org> On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Git のソースコードを最初に見たとき、ヘンだと思ったこと: > 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性がどうとか言わないで、 > そんなのウソに決まってるから。 *あんた* のほうこそ
Tracに足りない4つの機能 - プログラマーの脳みそ
ITの地殻変動はどこで起きているのか？: プログラマの思索を読んで思い出したことをまとめておこう。 TracなどのBTS(バグ管理システム)を用いたチケット駆動の開発というスタイルで、アジャイル開発を実践されている方も多いことだろう。 私がTracを使っていて感じた不足をここに挙げておく。 インシデント管理 顧客からの要望などのインシデント票と呼ばれるものと、開発の為のタスク（チケット）は別のものだ。私も当初はこれらを混在してつかっていたのだけど、顧客からの問い合わせや要望といったものと、実際の開発作業の間には大きな溝がある。 例えば「Tracにインシデント管理機能をつけてよ」と言われた段階で「インシデント管理機能を作成」というチケットをあげてはいけない。 XPで言うところの計画ゲームをする際のタスクカードと、TODOであるところのTrac上のチケットは分けた方がいい。アイデアとしては出た
開発者とデザイナの協働 | スパムとか
「開発者は最初の段階からデザイナーと共同で作業する必要がある」 グーグル、「App Engine」でデザイナーと開発者の連携狙う デザイナとプログラマの協調作業については、Djangoのコア開発者（含むデザイナ）たちが提唱してきたことです。Djangoが標準ライブラリとして含まれるApp Engineが「デザイナーと開発者の連携」をうたうのもおかしいことではありません。 じつは今回のDjango本には、実際の開発例という章があります。その章ではプログラマとデザイナが例えばどのように共同作業を行えるのかというシミュレーション的な作業フローについて書いています。App Engineと同じく、デザイナの作業環境に実行環境を整えることを重要視しています。 シミュレーション的とはいっても、2007年冬のデブキャンでnyusukeさんというデザイナと共同作業した際に検討し、実施した経験を
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
はてなブックマークの作り直しについて - naoyaのはてなダイアリー
id:naoya:20080320:1206009912 でも少し触れましたが、京都に来てからはてなブックマークの作り直しをしています。どういう意図を持って作り直そうとしているかを述べておきます。 まず大前提として、今のはてなブックマークに追加したい機能、変更したい仕様、本来追加するはずが途中で頓挫したものが結構な数で山積みになっています。それを実現するための基礎作りです。 追加したい機能、変更したい箇所 おそらく新システムの最初のリリース時には、それほど大きく変わった、という印象にはならないかと思います。長く続いているサービスですし、インタフェースや使い方もリリース当初からそれほど大きくは変わっていません。既存システムからの極端な変更は歓迎されないだろうと思っており、まずはオリジナルが持っていた機能をしっかり再現することが重要です。 ただし、既存システムでも問題と思っている箇所は改善して
ソフトウェア開発におけるウォーターフォールモデルの長所と短所を理解する - builder by ZDNet Japan
RPA見直される”業務”と”人”の関係 人的リソースを単純作業から解放！ 高付加価値業務への転換のために エッジ市場の活性化へ 高まるIoTを中心としたエッジ分野への期待 OSS活用が新しい時代のビジネスを拓く クラウド導入が進まない本当の課題 ITベンダーだからこそ知っている クラウドに二の足を踏む企業のボトルネック 勝つためのクラウド活用術 New Value on Azure ビジネスを次のステージへ！ サービスを止めない！ サイバーエージェントに聞く高可用性の実現 そこにピュア・ストレージが選ばれた理由 iPhoneデバイスも統合的に管理 激しく変化する業務環境とリスクに合わせ 深化するM365セキュリティ Anywhere Workspace！ ハイブリッドワーク時代の働き方 分散業務環境3つの課題と解決策 Summit 講演レポート公開！ イノベーション志向経営からDX推進の覚
携帯向けXHTMLを出力する場合に便利なPHPのパッチ
PHPでiモード用XHTMLを出力する際のトラブルと、トラブル対策としてPHPにパッチを当てる方法を紹介します。 ディノの過去の案件で実際にあったことなのですが、携帯向けにXHTMLのコンテンツを表示する際に、PHPで意外なトラブルが発生することがあります。具体的には、下記の状況でmb_output_handlerによる文字エンコーディング変換が効きません。 ドコモ携帯向けにXHTMLを出力する Content-Typeを「application/xhtml+xml」とする必要がある(※1) mbstringで外部エンコーディングをSJIS-winに変換したい mb_output_handlerでの文字エンコーディング変換が「text/*」のときにしか有効にならない(※2) 実際、このような状況は十分考えられます。携帯向けのコンテンツをXHTML+CSSで作成することは今後どんどん増えてく
memokami :: 第2回モバイル勉強会で「キャリア判別と絵文字の扱い」を発表してきました
第2回モバイル勉強会を開催しました。 今回はモバイルに情熱を持ったスピーカー12名の方々にご賛同いただき、 密度の濃いモバイルの勉強会を開催することが出来ました。 本当に皆様のおかげで、このような素晴らしい会を開催することが出来ました。 ありがとうございました。 また祝日の上、大人数にも関わらず、快く会場を貸してくださった上に 朝早くから会場設置までしてくださったECナビさん、本当にありがとうございました。 私も1スピーカーとして発表してまいりましたので、 その資料をあげておきます。 「キャリア判別と絵文字の扱い」 さてそんな第2回モバイル勉強会のご報告です。 ■スピーカーセッション ★モバイル前世紀 小飼 弾 さん 資料:モバイル前世紀 動画:モバイル前世紀 プレゼンテーションは携帯のみ！ 参加者各自で携帯を触りながらのプレゼンは斬新でした。 某ライブ○アの頃の携帯サイトを作ったときに話
あるＳＥのつぶやき: 携帯サイト構築メモ
携帯サイトを作る情報を公開しているサイトを、何かの時のためにメモしておきます。 ■情報サイト Mobile-users.jp - 日本のモバイルサイト開発者のためのハブサイト ke-tai.org > Blog Archive > モバイルサイト開発者のためのハブサイト「Mobile-users.jp」 PCサイトを携帯に対応させるまとめ(AffilicatePortal.net) 携帯からアクセスがあった場合に、携帯用ページにリダイレクトする方法や、エミュレーター、変換プログラムなどが紹介されてます。 携帯サイトの作り方 携帯サイトを構築する方法が詳しく解説されてます。 携帯電話向けコンテンツの書き方(ウェブの作り方)。 かなり詳しい解説です。 携帯便利ツールEZ-INFO 携帯サイト構築に役立つ情報、ツール、リンクがあります。 携帯サイト開発にあたっての下調べメモ(集積蔵) エミュレー
ここギコ！: Viewは完全にロジックから切り離してApacheモジュールとかで面倒見たらどうだろうか
うちの部署が公開するサービスの構築に、社内の技術資産流用の一環として、隣の部署が開発したフレームワークを導入*1する担当になっているのだけど。 そのフレームワーク、テンプレートシステムとしてXSLTを使っているんだけど、この構築が中々面倒くさい。 おまけに、部署間で要求するデザイン精度が異なる（うちの方が厳しい）ものだから、フレームワークの出力するデータ等がうちの要件に十分対応していないところを、むりやりXSLTのアクロバティックなやり方で回避してたりして、でもそれでもうちの部署のデザイン担当の眼鏡には適わずあちこち修正要求が。 XSLTは確かにやろうと思えばなんでもできるんだけど、変数の再代入はできない、複雑なループは再帰させなきゃいけない、正規表現なんかも使えないというわけで、「ここをこう変えて」と言われたら「確かに変える方法はある」んだけど「そのためにTemplateの切り方か
ケータイシミュレータなんて使ってないで Moxy 使えばいいのに - tokuhirom's blog.
http://codezine.jp/a/article/aid/1352.aspx この記事よんでマトモにうけとる人がいるといけないので一言いっておくと、ぶっちゃけケータイシミュレータは出来がよくありません。シミュレータ使うぐらいなら実装時から実機使った方がマシです。そもそもキャリヤ側にしてみればシミュレータを作りこんでも儲からないのでやる気がないんじゃないかと邪推しています。実際には Firefox+UserAgentSwitcher+ModifyHeaders+i絵文字 という組み合わせがよく使われてるんじゃないかと思いますね。まー i絵文字 は docomo の絵文字のみの対応な上に、ソフトによっては相性が悪かったりする気もしてあんまり好きじゃないんですけどねwそして、今時 HDML はほとんどのケースでサポートする必要がありません。HDML な端末は 2002 年ぐらいまでなの
おさかなラボ / API駆動型開発ってアリかもしんない。
近年、様々なWebAPIが公開され、利用されるようになったが、MVCからWebAPIを呼び出すWebアプリケーションってコードがとてもスッキリする。 逆に、WebAPIの開発もWebアプリケーションに比べると肩の荷が軽い。API開発者は渡されたデータのハンドリングに専念でき、エラーハンドリングも楽（エラーコードを返せば良いだけ）だからだ。Viewに至ってはデータ構造をシリアライズ（JSONとかXMLとか）するだけですむ。 これって何も外部APIに限らなくても良いのではないか。Webアプリケーションから、ビジネスロジック部を内部専用の（つまりlocalhostからしかアクセスできない）WebAPIとして切り離し、それをWebアプリケーションから呼んでやれば、今よりももっと開発が楽になるのではないだろうか、というのが今日のお話。 WebAPIの開発も当然MVCフレームワークが使われるので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
セキュリティガイドライン
http://d.hatena.ne.jp/tokuhirom/20070918/1190081969