プログラミングキャンプの講義資料を公開します - IT戦記
はじめに もうすぐ講義が開始されるので、同じタイミングでここで講義資料を公開したいと思います。 JavaScript の難しいところとか、マニアックなことは一切使わずに「プログラミングの楽しさ」みたいなものを伝えられたら嬉しいです。 この資料のターゲットは、プログラミング初心者です。 リンク http://svn.coderepos.org/share/docs/amachang/20080813-procamp2008/index.html 注意 今日の学生の出来によって、会期中ちょこちょこ資料の内容が変わると思います。
OOコード養成ギブス - rants
Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた
どうしてプログラマに・・・プログラムが書けないのか?
Jeff Atwood / 青木靖 訳 2007年2月26日 レジナルド・ブレイスウェイトが書いていることを読んだとき、私はそんなわけないだろうと思っていた。 私と同様、この著者は、プログラミングの仕事への応募者200人中199人はコードがまったく書けないということで苦労している。繰り返すが、彼らはどんなコードも書けないのだ。 彼が引用している著者というのはイムランのことで、彼は単純なプログラムも書けないプログラマをたくさん追い払っているということだ。 かなりの試行錯誤の末に、コードを書こうともがいている人たちというのは、単に大きな問題に対して苦労しているのではないことがわかった。やや小さな問題(連結リストを実装するというような)に対して苦労するということでさえない。彼らはまったくちっぽけな問題に苦労しているのだ。 それで、そういった類の開発者を見分けるための質問を作り始め、私が｢Fizz
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
プログラミングファースト開発のアキレス腱 : 404 Blog Not Found
2008年07月21日15:00 カテゴリArt プログラミングファースト開発のアキレス腱 ktkt. プログラミングファースト開発の必要性 - ひがやすを blog これをふまえて考えたのが、以前提案したプログラミングファースト開発だ。 プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法。ドキュメントは仕様が固まった後に書く。 実は私自身、この言葉が生まれる前から実践してきたのだけど、一つけったいな問題点があるので、それを指摘しておく。 それが何かというと、 客がそれを安易だと勘違いして、安価だと思いやすい こと。 プログラミングファーストの場合、最早だと打ち合わせのその場で動くものを見せたりする場合がある。客が分かっている人だと、その事にボーナスを出
404 Blog Not Found:フローチャートがダメな3つの理由
2008年07月19日16:00 カテゴリLightweight Languages フローチャートがダメな3つの理由 というわけで、前世紀の遺物、フローチャートを供養する試み。 フローチャートとFizzBuzz問題 - novtan別館 さて、研修の話だけど、低水準言語ってだけではなく、きちんとフローチャートを書かせて処理の流れを整理し、あるいは効率が悪くないかを考えさせる、ということも重要だと思っています。フローチャートがそんなにいいなら、なんでビジュアルプログラミング言語が現場で使われないの? まずは経験則による終了宣言。ちなみにここで言うビジュアルプログラミング言語の定義は、Wikipediaのそれと同じ。 ビジュアルプログラミング言語 - Wikipedia ビジュアルプログラミング言語（英: Visual programming language、VPL）とは、プログラム要素を
よいサブルーチンを作成するための心がけ。★★★ - サンプルコードによる Perl 入門
Perl › サブルーチン › here サブルーチン作成に関するわたしの考えを殴り書きしました。 見出し 引数と戻り値について理解する。 小さなサブルーチンを作成する。 サブルーチンに柔軟性を持たせる。 呼び出しの階層を浅く保つ。 機能を実現するサブルーチンを作成する。 ユーザーを意識する。 将来を楽にすることを考える。 完全な抽象化は求めない。 1. 引数と戻り値について理解する サブルーチンを理解するためには、引数の受け取り方と、戻り値の返却のし方を覚えれば十分です。なぜなら、引数を受け取ってから、戻り値を返却をするまでは、今まで学習したプログラミングとなんら変わることがないからです。引数と戻り値の扱いを、覚えたら、すぐに実践に移りましょう。 サブルーチン作成で、難しいのは、以下の4点です。 何をサブルーチンにするか どのような名前をつけるか 引数を何にするか 戻り値を何にするか 正
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
