友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
昨日 Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き - というエントリを書きましたが，その際 apple や microsoft が出すような Release note と，いわゆるオープンソースなプロジェクトが出す release note や changelog とでは英文の書き方が異なることに気が付きました．蛇足気味ですが，興味深かったので別エントリとしてまとめます． ポイント 不具合を，不具合と言わない bug，problem，fix といった単語は，他の言葉で言い換えます 旧製品も完璧だったが，新製品はもっと良い製品だよという言い回しが基本です．会社的に不具合を認めると面倒ですからね． 免責事項を強調 良く使う単語 issue (problem, bug の言い換え) update, improve, address
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
Invalid Text■<%=sn number %> <%=flickr_left '3274768929' %>デブサミ2009で発表しました:「時を超えたプログラミングの道への道」 つかれたのであとで書く。とりあえずスライド。最後までスライドめくれてよかった。 写真はtakaiのを借りてます。練習不足(というかスライド完成したのが10分前)でリモコンを見すぎてしまいました。情けないです。 The way to the timeless way of programmingView more presentations from Shintaro Kakutani. (tags: devsumi2009 xp) slideshare.net kakutani.com よくある質問と答え Q:動画はいつ公開されますか？ A:録画してません。 Q:予稿とかないの？ A:ありません。ひとえ
「Introduction to Abject-Oriented Programming」という記事がありました。 オブジェクト指向プログラミングで発生しがちな事柄を皮肉っています。 かなり笑えました。 最初は気がつきませんでしたが、原文のタイトルはObject-Orientedではなく、Abject-Orientedになっています。 面白かったので訳してみました。 一部良くわからなかったので省略してしまっているのと、間違っているかもしれないので、原文もご覧下さい。 また、原文のコメントも面白かったので、もしよろしければご覧下さい。 なお、原文のコメントにはネタであることを理解していないと思われる人の書き込みがありました。 念のためここにも書いておきますが「オブジェクト指向」じゃなくて「アブジェクト指向」ですよ！！！ 仮に、 Abject: 絶望的な、悲惨な、惨めな、屈辱的な、ひどい だそ
Microsoftは9日、IE用プラグイン「Internet Explorer Developer Toolbar」正式版をリリースした。以前からWeb開発者向けにリリースされていたプラグインだが、今回よりバージョン1.00の正式版となった（リリースされたのは、バージョン1.00.2188.0）。 Internet Explorer Developer ToolbarはMicrosoftのWebサイトより無償でダウンロードできる。IE7の場合、インストールするとブラウザの右上に小さなアイコンが現れ、これをクリックするとメニューが表示されるようになる。 Webサイトにおける画面デザインでは、HTMLのDOM構造やCSS適用内容、要素のサイズなど、実際にブラウザを通した表示を見ながら検証していく必要がある。Internet Explorer Developer Toolbarを使うと検証した
Firefox拡張機能(extension)の作り方 Firefox拡張機能(extension)の作り方を説明します。 Firefox 拡張機能とは Firefox add-onの一種です。 add-onは次のように分類できます。 plugin ...実体はexeやdll。C++で作成。素人にはお勧めしません 検索バー ...実体はXMLの設定ファイルのみ。見れば分かるので説明はしません スペルチェッカ ...日本語には無縁なので未調査(たぶんファイルを作るだけ) 拡張機能 ...実体はXML、JavaScriptとCSS。必要なら、C++で書くXPCOM。これから説明します テーマ ...拡張機能のサブセット。CSSのみの場合をテーマと呼びます
ここはプログラミングの原則を集める Wiki です。巨人の肩に乗って、ふつうの人がよいプログラムを書くための指針を集めたいなと思ってます。 目次 よいデザインのための Concepts + Principles DRY (Don'tRepeatYourself) 名前重要 直交性 トラッシュではなくクラッシュ DuckTyping よいルーチンを書く 凝集性 結合性 契約による設計 (DesignByContract) ルーチンを作る正当な理由 よいモジュールを書く 適切なモジュール性を確保するために守らなければならない5つの原則 開放/閉鎖原則 (OpenClosedPrinciple) よいアプローチのための Concepts + Principles 曳光弾 可逆性
■ Development Environment Conference 行ってキタ 今日(もう昨日だけど)は Development Environment Conference へ行ってきました。参加申し込みの前哨戦があったみたいですが、事前に名前とメールアドレスとコメントをコピペ用に用意してたオレの勝ち。 秋葉原ってパソコン買う時しか行かないから大分久しぶり何だな。相変わらずメイドさんとか普通にチラシ配ってるけど、あれ効果あんのかね。そういえば、バスケットコートとかどうなっちゃったんだろうか。 ダイビルの様子 20分くらい前に会場入りしました。チケットとかないしどうやって入るのかと思ったら、何かもうスルーでした。せめて名前くらいは確認した方が…。 とりあえず、スクリーンの近くに陣どった。 発表前の風景 そんで感想とか適当に抜粋して書きなぐり。上段が発表内容で下段がオレの感想と読みにく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
