いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
リファクタリングを考える時期の記事紹介 - cakephperの日記(CakePHP, Laravel, PHP)
自分の英語力アップと、技術力アップを兼ねて、好きな開発者の書いた記事をある程度翻訳して載せていこうと思います。今までMarkとかMcurryとかの興味深い記事をざっとは読んでたけど、自分が読むだけだと流し読みになりやすくて、読んだつもりになっただけで何も残らず、いかんなぁと思ってました。 全訳ではなく、自分が記事を理解して、ざっくりと翻訳して発信していくようにすれば、まず記事の内容を理解し、それを分かりやすく短く書くようになるので、良いのではないかと思いました。一人勉強会みたいなもんです。 これを続けていき、ある程度の段階になったら自分も英語で定期的に発信していきたい。 mark-storyの記事 5 signals that can indicate its time to re-factor リファクタリングすべき時期はいつごろか？その指標となる5項目を挙げています。 1. メソッドの
各言語におけるtrue/falseまとめ - 昼メシ物語
たとえば PHP で、 if ($hoge) { ... } とか書いてあったら、 $hoge がどんな値のときに if の中身が実行されるのか即答できますか。 こういう書き方は多くの言語で可能ですが、言語によって何が真で何が偽になるのかが異なるので、それぞれまとめてみました。 C言語 C言語には bool 型が無い。 0 （int） だけが偽となり、それ以外はすべて真となる。 NULL 定数は stddef.h で以下のように ((void*)0) と定義されているため、偽値として使える。 意見が分かれそうなところですが、個人的にはNULLを偽値として使用するは好きじゃないです。 #ifndef __cplsuplus #define NULL ((void*)0) #else #define NULL __null #endif C++ C++になると bool 型が出てくる。C と同
継承とコンポジット - 都元ダイスケ IT-PRESS
id:happy_ryoに「わかんねーんだよ、説明してみろゴルァ」されたので、書いてみる。 前書き*1 とりあえず、本日のエントリのキモを最初に。「オブジェクト指向は、隠す技術である」（俺談ｗ）ということを意識して読んで見てください。隠すとは何か？ 公開しすぎない事。分かりやすく言えば、publicをprivateに変える事。これが「隠す」。 んじゃあ、隠すと何が良いのか。あるクラスから、見えるもの（＝操作できる可能性の範囲(scope)）が狭ければ狭いほど出来る事のバリエーションが減るから、プログラムは単純になる。つまり、隠すと複雑性(complexity)が下がる*2。 要件を満たした上で、いかに型（class, interface, etc.）やメンバ（field, method）の可視性を落とすか。可能な限り可視性を下げ、プログラムを単純化し、メンテナンス性を上げるにはどうしたらい
プログラミング格言集
psychopathより。 金言、格言は古今東西いろいろあるのだが、ここではプログラミングに関する格言がまとめられていたので、抜粋して翻訳してみる。翻訳に間違い等があった場合は、コメント等で指摘してください。 We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil 私たちは、時間の約97%を占めるわずかな効率に関しては忘れるべきである: 時期尚早な最適化は諸悪の根源だ。 - C. A. R. Hoare Walking on water and developing software from a specification are easy if both are frozen 水の上を歩くのと、仕様に基い
バイブルというか、良書および必読の書 - ぐるぐる～
寝ようと思っていたら、その言語で「バイブル」と呼ばれる書籍を教えてくださいなんて質問を見つけてしまい、書いてたら長くなる長くなる・・・ 言語バイブル - Strategic Choiceが元らしく、いくつかかぶってるけど気にしない方向で。 Java Java言語仕様 第3版 (The Java Series) 何かと便利 Java仮想マシン仕様 (The Java series) 同上 Effective Java 第2版 (The Java Series) Effective なのに Java やるなら必読 Java Puzzlers 罠、落とし穴、コーナーケース Java の落とし穴にはまりたくなければ読むべき Javaプログラミングの処方箋 (Programmer’s foundations) 今となっては内容がちょっと古いけど、十分通用する。Effective の次に読むような本
きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス
下限に合わせたプログラム設計はシステム開発を停滞させる - @katzchang.contexts
FxUG@北陸の懇親会で出た話題。 中規模以上のプロジェクトになれば、悲しいかな、テンプレにそったプログラムしか書けない人や、そもそもプログラムを書いたことすらない人が結構いたりします。10人もかき集めれば2〜3人、いや半分はそういう人だったり。リーダーさんは仕様検討とかで忙しいから、そういう初級者さんにプログラムの作成を頼らざるを得ないってのが現実です。 で、初心者さんにもわかりやすい設計のプログラムを量産していきましょう、となる現場はよくあります。なに、うちのところもそんなもんですよ。 でもそれで良いの？と、個人的には疑問を持っています。 初心者でも書けるように、テンプレートをコピーして使う。 コピペ駆動開発の副作用は周知の通り。 テンプレートが役立つのは限定的な場合。仕様が想定の範囲を超えればテンプレートを捨てなきゃならないけど、その判断を誰が下す？ 後々の保守しやすいよう、初心者で
あなたの履歴書を向こう5年間戦えるものにするために--今後必要な開発者スキル10選 - builder by ZDNet Japan
最近の経済の変化から、現在多くの開発者が短期的な仕事を探している。同時に、スキルを習得するために時間とエネルギーを投入するのであれば、そこから確実に最大の収入を生むことが重要だ。ここで紹介する10のスキルのリストは、あなたの履歴書を向こう5年間戦えるものにするために、今すぐ学ぶべきものだ。このリストはとても網羅的とは言えないし、カバーし切れていない業界の分野も非常に大きい（例えば、メインフレームの開発者はカバーされていない）。とはいえ、平均的な主流の開発に対しては、少なくともこれらのスキルの7つを学んでいれば間違いはないだろう。就職の面接で説得力を持って話せるというだけでなく、これらは実際に仕事でも役に立つ。 1: 「ビッグスリー」の1つを学ぶ（.NET、Java、PHP） 開発業界に（レッドモンドに隕石が落ちるというのに匹敵するような）劇的な変化が起きない限り、ほとんどの開発者は少なくと
コードレビューWebシステムが必要な理由 - プログラマの思索
最近、コードレビューWebシステムに興味を持っている。 アイデアをメモ。 【元ネタ】 プログラマの思索: ソースインスペクションを真面目にやるGoogle、MS プログラマの思索: コードレビューはペアプログラミングの代替手段 プログラマの思索: レビューはペア作業であるべき 最近思うのは、SW開発でレビュー工程が最大のボトルネックになっていること。 レビューは、設計書を作成完了した後、設計書に従って実装完了した後に行われる。 レビューの目的は二つあると思う。 一つは品質チェック。 他方は、チーム全体で仕様や設計思想を情報共有すること。 しかし、レビューがうまく機能していない。 実際は、レビューが品質強化につながっておらず、むしろ、要件定義の代替プロセスになっていたり、ソースチェックで自動化できるぐらいのレベルでしか、情報共有できてない。 僕の考えでは、XPのペアプロのように、レビューは二
スケジュールを作って、「問題対私たち」の構図に持ち込もう - レベルエンター山本大のブログ
スケジュールを作るプログラマが一番効率が良い。 - 山本大の日記のエントリに プログラマが作ったスケジュールはいつも壊される - @katzchang.contextsでトラックバックを頂いたので返答します。 すべてに返答差し上げたいところですが、長くなるので部分的に。 id:katzchangの言ってる状況は、昔僕もよく経験しましたし納得できますね。 僕の場合はそういった状況に陥らないために、自分がマネジメントをする立場になりたいと考えるようになり、現在はやばそうなプロジェクトに１SEとして入っても、そうそうトラブらなくなったので、ある程度の結果は出ていると思います。 好きなプログラミングの仕事に集中したいなら、プログラミングスキルと共にマネジメントスキルをツールとして持っておくことは大事だと思います。 とは言え「マネージャになれ」というのは解決策としては遠回り過ぎるので、もう少し現実的
スケジュールを作るプログラマが一番効率が良い。 - レベルエンター山本大のブログ
現場の周りのプログラマさんたちが残業する中、 僕が毎日定時で帰って高品質なプログラムを作れる理由は、 僕が自分でスケジュールを作ってから仕事を始めるからだ。 僕が今の現場に入って始めにリーダーさんからこういわれた。 「スケジュールがきついので、 管理工数がもったいないから、管理資料に手間をかけたくありません。 イキナリ作業に入ってもらってかまいません。」 若い頃ならうっかりその言葉に惑わされているところだが、 そうはいかない。スケジュールがきつい時ほどコントロールが必要なのだ。 何を先にやっておかないといけないか、 今週末までにどこまで進めておけば安心か。 これらがわからなければ、不安に駆られるばかりだ。 不安を取り除くという意味だけでもスケジュールを組むことは非常に役に立つ。 ドラッカー風に言えば、 「ミッションに集中するにはマネジメントを駆使しなくてはならない」 ということだ。 プログ
プログラムの書き方の本 - きしだのHatena
今回は、プログラムの書き方の本。プログラムの宣言的な側面を扱うための本とでも言うか。id:t_yanoおまたせ。 ただ、こっち側はほんとに勉強を始めたばっかりなので、ちょっと目を通しただけで読んでない本もばかりだし、自分でもちゃんとわかってない部分も多い。そういうのを割り引いて見てもらえれば。 で、まずは、論理。プログラム書かなくても読んでほしい。 論理学 作者: 野矢茂樹出版社/メーカー: 東京大学出版会発売日: 1994/02/18メディア: 単行本購入: 24人 クリック: 175回この商品を含むブログ (80件) を見る これは全部読んだ。 この本読むと、かしこさが15くらいあがる。日本語がうまくなる。考えるとき、間違った結論をださなくなる。議論するとき、議論の骨子をみつけて、議論からそれる部分を省くことができるようになる。 1章「命題論理」2章「述語論理」を読めば、あとはヤル気が
差のつく勉強法200のメモ - tanamonの稀に良く書く日記
Seaser Conference 2009 Whiteのid:nowokayさんのセッションがとても勉強になったので、セッションのメモ（というかスライドの写経）を載せておきます。 差のつく勉強法200 - 35歳定年説を乗り越えるために何をすればいいか 35歳になりました。 35歳は定年です。 35歳定年説とは ついていけなくなる プログラマじゃ稼げないので管理職になる もうひとつ 飽きる 飽きる理由 一通りやった感 プログラム言語もいくつかやった データアクセスの移り変わりも見た ユーザインターフェースも見た 同じようなプログラムばっかり 35歳定年説を乗り越えるには ついていく 価値を上げる プログラムのおもしろさを知る いろいろ作れるようになる ちゃんと勉強するということ。 何を勉強するか？ 基礎 情報系の大学でやっていることをちゃんとやる。 プログラムとは何かを知る 何が処理でき
連載：良いコ―ドへの道―普通のプログラマのためのステップアップガイド｜gihyo.jp … 技術評論社
最終回 配列／コレクションを利用した抽象化―その5 Step4：配列／コレクション化して抽象化する 縣俊貴 2009-05-18
ゲームプログラムの勉強におすすめの本とサイトまとめ - 遥か彼方の彼方から
雑記普段はPHPをメインとしてWebプログラムを楽しんでいるのですが、今年の初めくらいからゲームプログラムにも挑戦しています。言語はC++で、DirectX9プログラムをしています。昔いじったことのあるHSP*1と比べて遥かに難しくてびっくりするのですが、Webプログラムとはまた別の方向で楽しいです。ただ、特につらいなと思うのが、情報の少なさです。一応SDKのヘルプは充実しているのですが、情報が豊富なPHPと比べると色々なところで厳しさを感じます。そこで、今参考にしているサイトや書籍についてメモ代わりにまとめることにしました。もし、他にもいい本やサイトがあれば是非教えてください。 対象とするのはあくまでC++とDirectX9の組み合わせですが、ものによっては参考になると思います。反対に、C++向けじゃないけど参考になるものも載せています。C++の勉強ゲームプログラムをするためには、ある程
IT業界で楽しく仕事をするための10カ条 - ＠IT
「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部） 2009年、日本の春は多くの学生さんたちが卒業し、また社会で活躍し始める時期です。 IT業界は3K、7Kなどと、いろいろネガティブな面も取り上げられます。けれども、「ものづくり」の楽しさや、人の役に立つ仕事として＠ITで取り上げられるような業種で働こうと考えている人も多いことでしょう。 なんとなくIT業界を選択した人から、もしかしたらあまり気が進まないのに、IT業界に入ってしまった人がいるかもしれません。その一方、プログラミングやコンピュータに関する事柄がとても好きでIT業界に入ってきた人もいるでしょう。 本記事では、IT業界を目指している学生さんや入社間もない新人に向けて、より楽しく
Firebugで作るGreasemonkeyスクリプト〜入門と実践(From Kanasan.JS) | Blog.37to.net
最終更新日 Wed, 29 Apr 2009 01:29:41 +0900 最後のコメント Sun, 25 Jan 2015 19:08:17 +0900 最後のトラックバック Wed, 11 Mar 2009 15:49:00 +0900 ブックマーク 遅くなりましたが、先日に開催された、Kanasan.JS Greasemonkey チュートリアル読書会のレポートです。 せっかくなので、読書会の内容を元にGreasemonkeyスクリプト作成の「入門」「実践」「Tips」の3本立てでまとめてみたいと思います。 今回の開催はKanasan.JSの主催をkanasanから引き継いで、初めての開催ということもあり、とても緊張しました。 途中までは無難に進んでいたのですが、後半は段取り不足が出てきた感じでした。参加者の方々にはご迷惑をお掛けしました。 Greasemonkey チュートリアル読
詳細設計に吸収されるプログラミング - 設計者の発言
生産管理システムや販売管理システムといった「業務システム（基幹システム）」を開発する場合、ふつうは何らかのフレームワークを用いる。フレームワークを利用する際、オブジェクト指向等の「言語特性」を意識する必要があればあるほど、フレームワークはプリミティブである――「フレームワークはオブジェクト指向を隠蔽する」でそのように説明したが、その話題に関連して、フレームワークの「成熟度」を測るための別の観点を述べたい。そのフレームワークが「実装作業をどれだけ詳細設計作業に似せることができているか」という観点だ。 この見方は、開発スタイルの発展に関する歴史認識にもとづくものである（ってなんか大げさな言い方だ）。拙書「上流工程入門」で説明したように、「業務システム」の実装工程は以下のような「後工程の前工程への吸収合併」の過程として発展してきた。それぞれの段階でいくつかの作業が関わるが、それぞれが異なる職種と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースソフトウェアの育て方