タグ

開発に関するakahigegのブックマーク (294)

  • [結] 2006年6月 - 結城浩の日記:モノクロ画像がカラーに見える錯視

    目次 2006年6月25日 - 長男と完全数談義 / 2006年6月23日 - ティナからの手紙 / 2006年6月20日 - 無神論者との対話 / 2006年6月18日 - 父の日 / 2006年6月16日 - ソフトウェアは、私たちの想像よりもずっと複雑 / 2006年6月14日 - 仕事 / 2006年6月13日 - 無限羽の鳩と無限個の巣 / 仕事 / Haskell / 読書 / 2006年6月12日 - 仕事 / 2006年6月10日 - モノクロ画像がカラーに見える錯視 / 日記ダイジェストを更新 / 2006年6月8日 - www.textfile.orgのお引っ越し / 2006年6月5日 - 仕事 / 2006年6月4日 - 今日の一日 / 2006年6月3日 - 誤植 / 2006年6月1日 - 仕事 / ぜひ、感想をお送りください 日記一覧 2006年6月25日 ■

  • テストコード、ソースコード、ドキュメントに書くこと - www.textfile.org

    http://d.hatena.ne.jp/babie/20060611/p2 テストコードにはWhat, ソースコードにはHow, そして,ドキュメントにはWhyを書くんだよ! by 角谷さん、とのこと。なるほど。 契約書にはWhenとHow muchを書くのかも。 追記:ご人、6/29に喋るつもりだった模様。 http://b.hatena.ne.jp/kakutani/20060616#bookmark-2135148 6/29とは、これのことでしょうか? http://kakutani.com/20060517.html#p01

    テストコード、ソースコード、ドキュメントに書くこと - www.textfile.org
    akahigeg
    akahigeg 2006/06/16
    わかりやすい
  • yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須

    (Last Updated On: 2016年3月3日)最近PostgreSQLMySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。 参考:セキュアなアプリケーションのアーキテクチャ – sandbox化 PostgreSQLMySQLの脆弱性は特にSJIS等、マルチバイト文字に\が含まれる文字エンコーディングが大きな影響を受けますが、同類の不正な文字エンコーディングを利用した攻撃方法が他の文字エンコーディングでも可能です。例えば、UTF-8エンコーディングは1文字を構成するバイト列の最初のバイトの何ビット目までが1であるか、を取得してUTF-8文字として1バイト~6バイト必要なのか

    yohgaki's blog - これからのプログラムの作り方 - 文字エンコーディング検証は必須
  • ユーザビリティコラム:Jakob Nielsen博士のAlertbox

    日記調査:長期間のユーザー行動と体験の理解 8月9日 読了までに約15分 参加者は日々の活動をその都度記録し、リアルタイムのユーザーの行動やニーズについてコンテキストに基づいた知見を提供する。 このコラムについてUIデザイン・ユーザビリティ・UXデザインについて、その道の第一人者・ヤコブ・ニールセン博士(略歴)ら米Nielsen Norman Groupのメンバーが実例を交えて洞察するコラム『Alertbox』。その日語訳を許可を得て公開しています。

    ユーザビリティコラム:Jakob Nielsen博士のAlertbox
    akahigeg
    akahigeg 2006/05/30
    ユーザビリティ関連のコラム
  • あさのかい - KoshigoeBLOG

    akahigeg
    akahigeg 2006/05/23
    のどかでよい
  • naoyaのはてなダイアリー - 疎結合のための Web API

    RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。 以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大DB な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな? 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもな

    naoyaのはてなダイアリー - 疎結合のための Web API
    akahigeg
    akahigeg 2006/02/28
    たくさんのサービスを作ってると疎結合にかかるコストもペイできるってことかなぁ。あとはサーバリソースたくさん。
  • 小野和俊のブログ:プログラマー風林火山

    アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニア仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ

    小野和俊のブログ:プログラマー風林火山
    akahigeg
    akahigeg 2006/02/27
    自分は火の要素が強いような気がする。燃やしっぱなし焦土作戦。
  • プログラマが騒ぐ時 - Kazzz's diary

    あるシステムの開発プロジェクトにおいて、実装を任されているプログラマがいるとしよう。そのシステムでは、他のシステムのサーバとの通信を行なうことが必要あり、プログラマは、そのサーバとの通信部分を実装しなければならない。サーバとの通信仕様は曖昧で仕様書や資料を見てもよく解らないし、周りに聞くが誰も事実を知らないようだ。仕方が無いのでサーバ側の人間にお願いして、実際にサーバにアクセスしている、他のシステムのプログラムのソースコードを送ってもらい、独自に調査を開始する。 こうして細かいサーバとのやりとりはある程度判ったので、プログラマは実装を開始した。実装はほぼ期待通りの仕様であり(調べたので当たり前だ)サーバとの通信部分は問題無く動いた。 よくいる立派なプログラマのケースだが、この進め方は駄目だ。 サーバとの通信の方法を知っているのは、プロジェクトメンバ中あなただけだ。おそらく今後も、未来永劫そ

    プログラマが騒ぐ時 - Kazzz's diary
    akahigeg
    akahigeg 2006/02/23
    騒がないで自分で処理するってことは負債を背負うってことだ
  • ハッカーの働きたい職場 - ShibaPuki

    LSE † もはや、2週間程前になるのだが、LSE(ソフトウェア技術者連盟)というのもの、設立総会に行ってきた。目玉はWinnyの作者、金田勇金子勇*2さんを生で拝めると言うこと。彼がちょろっと挨拶した。しゃべり方は木訥としているが、色々と笑いも取っていて、出来る人のオーラが出ていた。 山根さんらが来ていて、ハッカー臭のする集まりだった。この会は、「今まで情報処理学会などは、学術的な集まりだったが、LSEは技術者のProfessional Lifeをサポートすることが目的」というものらしい。 その中で大きな問題として取り上げられていたのは、「過重労働、不払い残業、偽装請負等の問題ある労働慣行」と言ったものだった。確かにそれらは大きな問題だが、それだったら、電算労とか、その下部団体のコンピュータユニオンとかが、団体交渉も得意そうだし、彼らに話した方がその手の問題は解決が早そうだと感じた。 し

    akahigeg
    akahigeg 2006/02/22
    スカンクワークいいね
  • http://blog.moongift.jp/item/2555.html

    akahigeg
    akahigeg 2006/02/22
    ひとつの方向性として
  • スクラムは現実解 (arclamp.jp アークランプ)

    アジャイル開発というとXPに代表されるようなエンジニアリング的な要素が強いように感じられる。しかし、プロジェクトマネージメントをアジャイルにすることの方が重要だと思っている。僕が気に入っているのはスクラムだ。既に書籍が出ており、かなり明確に体系化されている。スクラムのプラクティスがなにかというのはWebやで探ってもらうとして、なぜスクラムが良いのか・なにが難しいのか、というあたりを書いてみたい。 スクラムの良さ スクラムの良さはタイムボックスによるコントロールだ。ソフトウェア開発は、要件も技術要素も非常にあいまいで、ようはやってみなくては分からないことが多い。とはいえ何も基準がないのでは混乱をきたす。そこで、ある時間枠(土日を含む30日間)を基準とする。 チームは少人数(7人前後)で構成されており、自分達で期間内の作業にコミットする。作業ゴールは必ずテスト済みの動くアプリケーションで

    akahigeg
    akahigeg 2006/02/20
    本題とは外れるが「人を雇い入れるお金があるならチームの生産性をあげるために、(中略)早くて大画面のPC、空調が効いた部屋、立派な机とイス、おかしを用意したほうが良い。安いもんだ。」
  • 週40時間という見積もり

    Solution 週40時間という見積もり 「変更です」そう言って、彼は説明を始めた。「『顧客は常に正しい』というのが、私の会社のモットーです。顧客が変更を求めるなら、反対はしまんせん。喜んで協力します。実は、変更は多ければ多いほどいいんです。そこまでの段階にいけば、顧客が別の業者に乗り換えることはありませんし、お金も払ってくれます。それもたくさん」テッドは、まるでトップ・シークレットを暴露してしまったかのように、こわばった表情をしている。 概要 週40hという見積もりを利用することによって、プロジェクトを80%の確率でスケジュール通りに終わらせるマネージメント手法を論じる。 内容 部分見積もりのセーフティを使わず、50%の確率で成功する見積もりを立てる。 (現在は80%の確率を考えているので、これらの部分をプロジェクト・バッファに移す) この見積もり時に、h数(時間単位)ではなくて、w数

    akahigeg
    akahigeg 2006/02/17
    運用中のシステムがある場合はバグ修正などのためにもバッファを設けた方がよさげ
  • キーリピート間隔を短くしたらプログラミングが快適に - higepon blog

    id:secondlifeが僕がエディタで入力しているのを見て「キーリピート間隔、ストレスたまりませんか?」と聞かれた。 そのときは今のまま(デフォルト)で問題ないと思ったんですが、「コントロールパネルーキーボード」からキーリピート間隔を短くしたらとても快適になりました。 同じキーを長時間押し続けて、同じ文字を連続して入力すること。1文字入力するつもりで複数文字入力されてしまう現象を防ぐため、キーを押し始めてから0.5秒〜1秒程度経過するまではキーリピートされない。連続して入力する際、それぞれの間隔を何秒空けるかをソフトウェアで設定できるようになっていることが多い。この間隔のことをキーリピート間隔という。 追記: id:krackmaniaさんとid:secondlifeにつっこまれた http://www.jsdlab.co.jp/~kamei/ にある、kbdacc を使うのが常識のよ

    キーリピート間隔を短くしたらプログラミングが快適に - higepon blog
    akahigeg
    akahigeg 2006/02/16
    気にしたことなかった。よい。
  • http://www.arclamp.jp/blog/archives/000556.html

    akahigeg
    akahigeg 2006/02/14
    タイムボックス型開発
  • ホワイトボードブック - toyahの日記

    ホワイトボードブック 写真をみたいというリクエストがあったのでアップロード 単に、ホワイトボードシートとプラスチックをそのまま 張り合わせたぺらぺらのペアボードも数枚会社で使ってみたが こちらは、何人もの同僚からそれ便利だねと言われる。 同期のA氏などは早速10枚も購入していた。 このような、ペアボードの持ち運び版としてはよいかもしれない。 ホワイドボードシートはダイソーの100円ショップで手に入る。 裏のプラスチックは、クリップ止め式のファイルケースの クリップをはずしたものを利用している。 コピー機のサイズにジャストフィットするので、そのままコピーも可能。 (その際は、ラミネートシートなどではさんで汚さないようにする)

    ホワイトボードブック - toyahの日記
    akahigeg
    akahigeg 2006/02/14
    ホワイトボードシートを束ねて本に。持ち歩ける
  • - XFD TOP

    アイディアの箇条書き、XFD 導入奮闘日記、何でもお待ちしています! こんなネタ持ってるよ!という方、editors at ObjectClub.jp までご連絡ください。 なお、貴社名掲載の可否、掲載するお名前(ペンネーム、匿名可)を一緒にご連絡ください。 プロジェクトステータスやメトリクスは、目に見えにくい。見えないからこそ難しい。そんな悩みを解決してくれるのが、XFD(eXtreme Feedback Device)です。目に見えて、楽しい、ユニークな装置。目に付いて、絶対見落とさないような装置を指します。安上がりならなおよろし。 XFD に関する文献:Pragmatic Project Automation 元チーム角谷XFD担当 芦沢嘉典 さん ・XFDコレクション 2004年冬(PDF 284KB) <2004年オブジェクト倶楽部クリスマスイベント ライトニングトークス発表資料

    akahigeg
    akahigeg 2006/02/14
    eXtreme Feedback Device = 見える化のための道具
  • 2004-11-14

    ホワイトボードは個々人の持ち物というよりどちらかというとチームの持ち物という意識です。ホワイトボードをメンバーの人数分用意するような感覚です A3のホワイトボードは結構安いです(1000円くらい。リーダー談) ホワイトボード用のペンですが、細いペンは書き込みやすく、太いペンは気分が乗ります(元相棒談)。状況に応じて使い分けます 日酒とカニ味噌はキラーコンボ。やばいやばい。 八重洲に行ったものの、OOSC第2版は見つからず。残念です。 読書会の中でUMLモデリングツールなど開発ツール関係の話題になったとき、ホワイトボードを使うテクニックのことを少し話しました。具体的には、A3サイズのホワイトボードを大体一人一枚くらいの枚数使用し、保存したいときにはコピー機でコピーしてしまうというテクニックです。あえて、強力なテクニックだと言っておきます。 ホワイトボードを使おうとするときに、書かれている内

    2004-11-14
  • プロジェクト・オートメーション

    Generated by Rabbit version 0.3.2

    akahigeg
    akahigeg 2006/02/14
    3アウトの原則は手順化自動化するしないのバランス取るためにも大事と思った
  • プロジェクト・オートメーション

    Generated by Rabbit version 0.3.2

    akahigeg
    akahigeg 2006/02/14
    こういうの音声ファイルとかないんだろうか
  • テストで手を抜く:steps to phantasien t(2006-02-12)

    海辺のカフカ もらいもの. すばらしく面白かった. (実はもう内容をほとんど覚えていないが, それは良い娯楽作品の条件だと思う...) 村上春樹はなんというか, 日語が卓越しているね. こんなにストレスなく読めて, かつ下品でない日語を書ける作家は他に見ない. アマゾン・ドット・コムの光と影 前から気になっていたのを近所の屋で発見し読む. 資主義的に良い会社で働くのが幸せとは限らないのは実感としては 当り前ではあるが, Amazon(JP) の配送センターで働くという極端なケースの体験記. Amazon は素晴しい企業だ. 流通やアルバイトの活用といった計算機的でない部分の出来が良いと 計算機は威力を発揮するのだなあ. Expert One-on-One J2EE Development without EJB Spring Framwork の思想に基いた J2EE のアプリケー

    akahigeg
    akahigeg 2006/02/14
    参考になる