タグ

developmentとprogrammingに関するyuu013のブックマーク (11)

  • marsのメモ - 開発環境に関わるメモ

    今月で今やってる仕事の契約が切れるので,ここで培ったノウハウなどをメモしておこうと思う。 しかし,今後この手の開発系の仕事ができるとは限らないってのが悲しいところ。 プロジェクトポータルまわり とりあえず,Subversion(SCM), Trac(ITS/Wiki), Hudson(CI)は必須。この3セットがないプロジェクトなんてうんこ。 とにかくTrac-Subversionの連携が強力なので,Subversion以外のSCMは無視していい。HudsonはCIつうよりプロジェクトダッシュボードとして使うのが吉(数あるプラグインを有効利用しよう)。 marsのメモ - Trac marsのメモ - MacroBazaar - The Trac Project marsのメモ - 角谷HTML化計画(2006-04-25) marsのメモ - trac-post-commit-hookが

    marsのメモ - 開発環境に関わるメモ
  • HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方

    HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,

  • 川o・-・)<2nd life - Developer Enviroments Conference の発表資料

    9/8 に開かれた DEcon で windows enviroments and vim という内容で発表してきました。主に自分が使ってる windows の開発に便利なツールと、vim についてプレゼンしてきました。時間大幅に押してしまいましてスイマセン…。 また、スピーカと参加者のみなさん、お疲れ様でした。他の方の開発環境やポリシーが聴けて大変参考になりました。あとカンジマン(id:tnx)には毎度の事ながら様々な準備お疲れ様でした。 自分のプレゼンには自作のはてな記法つかったプレゼンツールを使ったのですが、よくよく考えるとそれをエントリーに貼り付ければいいじゃん!ということに気づいたので、以下に発表資料を貼り付けておきます。 windows environments and vim secondlife 発表内容 windows での環境 どんなツールがあると便利か vim vim

    川o・-・)<2nd life - Developer Enviroments Conference の発表資料
  • JUnit 実践講座 - プログラミングスタイルガイド

    [ホームへもどる] [JUnit 実践講座 へもどる] JUnit 実践講座 - プログラミングスタイルガイド 2002/01/02 作成 石井 勝 目次 はじめに 実装コードとテストコードの書き方は違う テストコードで一般解を扱わないこと コメントについて リファクタリングについて メソッド名と体について テストコードの構成 Footnotes 更新履歴 はじめに XP による開発全体にいえることですが,JUnit を使った開発では,プログラマは次の 2種類のコードを書かなくてはなりません. 実装コード 実際にソフトウェアとして実装されるコード テストコード JUnit を使って書かれるコード 僕の経験では,一般に実装コードよりもテストコードの方がコード量が多く,コードを書くのに費やされる時間もテストコードの方が長くなります.したがって,何も考えず

  • 『ダルいプログラマのためのプログラミング入門』 - babie, you're my home

    が欲しい。「カーソル移動のたびにホームポジションから手を動かすのがダルいので Vim を使いましょう」とかから始まるやつ。 「コマンドを全部打つのはダルいので zsh をつかいましょう」 「変数宣言のたびに型を明示するのはダルイので Ruby を使いましょう」 「〜クロージャを〜」 「あとで影響範囲を特定するのがだるいのでテストを書きましょう」 「全体像を描くのがダルイので TDD を行いましょう」 「考えるのがダルイので仮実装してとりあえずグリーンにましょう」 「テストメソッド名を考えるのがダルイので、RSpec を使いましょう」 終始「ダルイ」ベース。

    『ダルいプログラマのためのプログラミング入門』 - babie, you're my home
    yuu013
    yuu013 2006/11/15
    確かに、ツールの存在理由を全面的に押し出した解説書があるといいかもしれない。ツールを使う動機付けにもなるはずだし。
  • A. WEBプログラマコース

  • いいアジャイルと悪いアジャイル

    スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見

  • 最上の日々 - 数学を表現するのに最適な媒体はコンピュータである

    数学の表現の媒体としてのコンピュータつづき あのあとyoriyukiさんから有用な示唆をもらいました。 (これだけ書くのも大変だろうなあ。いつもお世話になってます。) 証明チェッカのあちら側とこちら側 私的にみたハイライトはこの辺りかな: 論理に関する部分はうまくいかなそうな気が(直観的には)します。言語や論理について一般の人が抱いている直観は誤っているか、すくなくとも混乱していることが多く、そのまま形式化しようとするとうまくいかないからです。例えば、名詞は何か対象を名指している、といった考えがその例になるでしょう。この場合、何の対象も指さない時や、複数の対象に当てはまるときにどうするか、といった問題が考えられてないのですが、にもかかわらず強固な直観としてなかなかここから自由になれないようにに思います。 言い方を変えると、自然言語に近いもの純粋に形式的に取り扱おうとすると

    yuu013
    yuu013 2006/06/22
    最後が見えてないから。
  • [鏡] しっぽのさきっちょ 2006年06月 -- Spiegel's Trunk: ☆ 知らぬは国許ばかりなり?

    del.icio.us の便利な使い方 ありゃ, 私のところもチェックされているのか。 確かに私のブックマークは(見る人によっては)かなりノイズが多いからな。 私のところで比較的マメにブックマークしているのは spiegel/Astronomy spiegel/Security くらいか。 暗号関係に興味のある方は spiegel/Cryptography あたりがいいかもしれない。 (spiegel/Security とダブルことが多いんだけどね) 知財関係もブックマークしてるけど, それほどマメではない。 タグでいうなら spiegel/Intellectual_Property あたりかな。 「そんなくそ真面目な記事はいらんねん。 もっと面白おかしいのはないんか」 という方は spiegel/Fun あたりをどうぞ。 ついでに私の場合だが, 方針としてはノイズを多めにしてでもなるべく

    yuu013
    yuu013 2006/06/18
    問題を簡単にしてソフトウェアに解かせるもの。複雑にしてるのは人間。
  • [結] 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日 ■

  • OBB vs AABB - Radium Software Development

    iPhoneの一般修理店は予約なしでも来店できる? 基的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、

  • 1