CodeRepos::Share – Trac
モバイルのウェブ開発の際に PC のブラウザで見れるように HTML をレンダリングしてくれる Web アプリケーションです。 つかいかた とりあえずつかうだけなら svn co http://svn.coderepos.org/share/lang/ruby/ssb/trunk/ ssb cd ssb/ rake setup ruby ssb-webrick.rb でいけます。 末永く使いたい場合は mod_ruby を使うのもよいかもしれません。 scrapi, lha, ghostscript, imagemagick がないと絵文字の scraping に失敗して絵文字が表示できません。 携帯端末情報 機種変更時に利用される携帯端末情報は、ke-tai.orgの携帯電話スペック一覧を利用しています。 端末情報を最新のものに更新するときはシェル上で以下のコマンドを入力してください。
パズル提供能力ドリブンな人材流動化 - アンカテ(Uncategorizable Blog)
少し前にアップされた、itproの梅田ーまつもと対談の第二弾の中に、非常に印象に残るやりとりがありました。少し長くなりますが、引用します。 梅田 それをやってやろう，と思うときのモチベーションというのは何なんでしょう。そこに山があるから登るという感じ？ まつもと 新聞を開けたらそこにクロスワードパズルがあったというのと同じですね。 梅田 パズルなんだ！ まつもと 新聞に載ってるクロスワードパズルですから，やってもやらなくてもいいわけですよ。でもやれば，ある一定時間，知的な満足感が得られるわけじゃないですか。 それと同じことがオープンソース・プログラマにもあって，メーリングリストを読んでると問題が書いてあるわけですよね。で，「お，これ，きっと直せる」と思って，ソースコードを読んで10分か15分やってみると直せる。 梅田 そうすると使命感ではないわけですね。 まつもと 使命感ではないですね。楽
大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索
ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
プログラマーは、もう時代遅れなのか：代替案のある生活：オルタナティブ・ブログ
1990年代半ば、私は DB2 を中心とする IBM のリレーショナル・データベース製品の開発部門と緊密に連絡し合いながら仕事をしていた。アジア太平洋地区のプロダクトマネージャとして、シリコンバレー南部のサンタテレサ研究所には頻繁に出かけていた。 ヤニタ・マーさんという中国系女性で、DB2 の開発のキーパーソンのひとりがいた。サンタ・テレサ研究所勤務だった。IBM のメインフレーム MVS 上で稼働するRDBMS の DB2 は、何百人もの開発エンジニアではなく、数の限られた、たいへんに能力のある人たちによって開発されていた。ヤニタは、特にRDBの心臓部にあたる部分の 責任を持っていた。セカンド・レベル・マネージャといい、複数のファースト・ライン・マネージャを束ねていた。日本なら、部長レベルといっていい、と思 う。 大学は、UC バークレー校を卒業。MBAはサンタ・クララ大学で取っている。
コードを憎んで人を憎まず, あるいは. - steps to phantasien t(2008-04-02)
社会人になって最初に配属されたチームのコードはひどいもので, 私は同期の新入社員仲間 Y に "ひどいコードなんだ. あの先輩はろくでもない." と愚痴た. すると Y はぽつりとこう答えた. "<コードを憎んで人を憎まず> だよ." Y の言葉は私の座右の銘となった. コードと人格を切り離す. あたりまえの事に思えるけれど, いまより輪をかけて狭量だった私はひどいコードの書き手を見下していた. もちろん自分は棚にあげて. たかがコードで友情や信頼を失うのは愚かなことだ. Y はそう言うのだった. 件の先輩社員は寛大だった. 私は勢いと趣味に任せて彼のコードを書き換えていたが, 彼は文句もいわず, 雑用を押し付けてくることもなく, 他所からのメールやバグを黙々と片付けていた. 私が同じ立場なら, 間違いなく戦いの火蓋を切っていただろう. (実際, 翌年の私は毎日のように後輩と口論していた.
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> �LN�U �u�M�U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
満足せる豚。眠たげなポチ。:業務システム開発の世界だってコードの力で変えられる
これ、必読。 業界の重鎮とやらに惑わされるヒマがあったら、一歩でも前に進むために何をするかを考えたい。 山ほどあるサブセットから, どうやって適切な妥協点を選べばいいのだろう. 絡まりあったプラクティスをときほぐして本質に迫る根気と,サブセットの善し悪しを判断するクライテリアを K は持っていた. http://www.dodgson.org/omo/t/?date=20071103 誤解を恐れずに言えば、業務システムの開発において一番面白いのは実はここだ。 プログラミングとは、忠実に正確にまじめにシステムを動かすためのコードを書く作業ではない。 本当のプログラミングとは、コードの力を駆使して問題自体を解消してしまうような仕組みを創造するプロセスだ。その対象が身内なこともあれば、顧客なこともあるだろう。その意味で、「業務システム開発はクリエイティビティを発揮できない」なんていうのは、「私は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
