LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found
2007年09月16日04:30 カテゴリArt LiveCodingに学ぶプログラミングの三原則 Mozilla24のLiveCodingの解説をやってきました。参加された方、お疲れさまでした。ほんと楽しかった。 言語もC++ありJavaありJavaScriptありActionScriptありPerlありとまちまちで、Editorもemacsありvimあり秀丸ありとまちまちでしたが、それでも全LiveCoderの共通項がはっきり見えたので、それを書き留めておきます。これらの共通項には私も含まれます。 コピペを恐れるな(don't be afraid to be a copycat) 参加者の一人として、100%フルスクラッチで書いていた人はいませんでした。たいていは関数単位でコピーし、それを適宜書き換えるというやり方をしていました。学校のテストでは反則もいいところですが、大人の世界ではこ
404 Blog Not Found:マシン語読みの言語知らず
2007年09月11日22:20 カテゴリArt マシン語読みの言語知らず もうこの話題が登場して何度目になるのかは知らないが.... shi3zの日記 - マシン語を知らない子ども達 あまりも当たり前過ぎて21世紀に入ってから言葉にだしたことはあまりないのですが、当然のことながら、プログラムというのは、マシン語を理解して初めて「書ける」と言うのです。 そんなことは、ない。 私の上の娘は、まだ日本語文法を習っていないが、日本語で彼女の母や父である私や妹や級友と話すことが出来る。まだ辞書さえ知らない下の娘も同様だ。 確かに、「下の事」を一通り習った者は、「底まで知っていて」やっと「知っている」と言って「下の事」を知らない者を下に見がちだ。しかし、知識を深さでしか測れない者は、往々にして知識を広さを測ることが出来ない。「一段下の階層を知らなければそのことを知らない」という人に限って、そのことの
100日プログラミング
100日かければなんとかプログラムが勉強できるのではないか、 という仮説から、100日間だけ がんばって勉強を続けられるようにする企画です。 基本的には5人１組でやっていき、 お互いに進捗を報告することで、モチベーションを高めていきます。 詳しくはこちらをご覧ください。 100日プログラミングが終わりました。本当はもっと早くまとめエントリーを書きたかったのですが年末で時間がなくてすいませんすいません。年明けになってしまいましたね・・・。 さて、100日プログラミングですが、いろいろな気づきがありました。まとめてみます。 よかった点 やってよかったと思う点を書いてみます。 ・毎週、順番が来るのでプレッシャーになった →これは狙い通りですね。やっていないと恥ずかしいのでなんとかやろうとしました。やり始めてしまえば意外とすらすら出来るものですが、なかなかやらないのが問題なので。やるきっかけがある
C#設計者が語る5年後のプログラミング － ＠IT
「プログラミングは命令型から宣言型に変っていく。この変化に対応するのがLINQ（Language Integrated Query）プロジェクトだ」。米マイクロソフトのDeveloper Division テクニカル フェローのアンダース ヘルスバーグ（Anders Hejlsberg）氏はプログラミング言語の将来をこう予測し、彼が主導するプロジェクトの重要性を説く。「データベースとプログラムのミスマッチを解消する」というのがLINQプロジェクトに与えられた使命だ。 ヘルスバーグ氏はC#プログラミング言語のチームデザイナー。.NET Framework開発の主要メンバーも務める。ヘルスバーグ氏は現在のプログラミング言語の課題をこう説明する。「プログラムを書いている開発者の80％はデータベースにアクセスしている。しかし、データベースのコンセプトとプログラム言語のデータセットは構造がまったく異
ユメのチカラ: ソースコードの読み方
ソフトウェア工学の標準的なカリキュラムにソースコードの読み方というのがあるのかないのか知らないが、プログラマとして最も重要な資質の一つにコードの読解力というのがある。 ついでに言えば、大学や専門学校であまり教えられているとはいえないけど、実践では常に必要とされているものとして、テストの方法論、デバッグの方法論、性能向上の方法論、メモリなど各種資源の削減方法論などなどがある。国際化、移植性なども重要な単元であるがソフトウェア工学の中で教授されていると言う話はあまり聞かない。コードのハック一般についてどこかで議論されているのだろうか。経団連あたりで議論しているのだろうか？ 閑話休題。 ソースコードの読み方ということで、最近では「コード・リーディング」というそのものずばりの教科書も出ているので状況は好転しつつある。コードの読み方はオープンソースの時代になり、間違いなく広く情報を共有できるようにな
理解することが書き直すことを意味するとき
Jeff Atwood / 青木靖 訳 2006年9月18日 開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。 しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。 ピーター・ハラムがこのことについて説明している。 どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新
blog.8-p.info : Non-Programmer's Programming Book
まえからプログラミング入門的なものが書きたいと思っていて、つまりは『ノンプログラマーズ・プログラミングブック』なのかと、ひさしぶりに『ノンデザイナーズ・デザインブック』を読んでみたら この本は、デザインを正式に学んだことがないけれど、ページをデザインする必要がある人々のために書かれました。 とあって、ちょっとちがった。「プログラミングをする必要」というのは、あるのに認識されていなくて、自分が書きたいのはそこを埋めるものだった。『ノンデザイナーズ〜』よりもっと前の段階だ。プログラミングを手段のひとつとして認識させたい。 自分がコードを書けるようになったのは、ほとんど Linux 上での出来事で、それはいま思うと良い環境だった。Linux だと、日常使うほとんどのソフトウェアにソースコードがついている。使っていて間違いや不足を感じたら、すぐ自分で書き換えてみることが出来て、生活と連続していた。
いやなブログ: 配列操作の比較表: Ruby, Python, JavaScript, Perl, C++
配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)
三項演算子の正しい書き方
C・C++・Java・Perl などのプログラミング言語では、条件演算子として三項演算子?:が用意されている。条件演算子の書き方として、以下のような説明がされることが多い。 condition ? true-expression : false-expression この説明は、以下のプログラムと同じ程度、間違っている。 #include <stdio.h> main( ){printf ("hel" "lo, world\n" );} 条件演算子は、正しくは以下のように書く。 condition ? true-expression : false-expression 使い方の例を示す。 compare = obj1 == null ? obj2 == null ? 0 : -1 : obj2 == null ? 1 : obj1.toString().compareTo(obj2.to
ブロックを組み立てるようにプログラミングを簡単に学べる『Scratch』がすごいかもしれません | POP*POP
MITのメディアラボで開発されている開発ツール「Scratch」が話題になっています。 小さなお子さんでもプログラミングに親しんでもらおう、という目的で作られたツールです。 この時代、誰でもプログラミングを学びたいものですよね。この「Scratch」、どれほど簡単なのでしょうか。 以下に詳しく見ていきましょう。 ↑ 起動直後の画面。左側からアクションを選んで組み立てていきます。 ↑ まずは猫を動かしましょう。左側から「Move 10 Steps」を選び、横のエリアにドラッグします。それをダブルクリックすると猫が横に動きます。もちろん「10」の値は好きに変えられます。 ↑ 次にさっきのブロックの下に「Say Hello for 2 seconds」をくっつけます。これでこのブロックをダブルクリックすると「横に動いてHelloと2秒間言う」というアクションがつくれました。 ↑ こうしてできたア
JS や AS で長い関数をリファクタリングする１手法 - てっく煮ブログ
200行ぐらいある関数を、分かりやすく書きなおそう、というお話。お題はこんなJavaScript。あとで、軽く ActionScript 3.0 も出てくるよ。 function fly() { // 初期化処理 var init:Boolean = false; // 50行ぐらい初期化処理 // うまくいったら init が true になる // 実行 if(init) { var succeeded = false; // 100行ぐらい実行 } // 終了処理 // 30行ぐらい終了処理 } 構造化プログラミングについて知ってる人なら、きっとこうする。 function fly() { if(startFly()) { doFly(); } endFly(); } 構造がたいそうすっきりした。問題は、startFly()・doFly()・endFly() をどこに記述するか。fl
wav ファイルフォーマット
'fmt ' チャンク構造体 #define FormatID 'fmt ' /* chunkID for Format Chunk. NOTE: There is a space at the end of this ID. */ typedef struct { ID chunkID; long chunkSize; short wFormatTag; unsigned short wChannels; unsigned long dwSamplesPerSec; unsigned long dwAvgBytesPerSec; unsigned short wBlockAlign; unsigned short wBitsPerSample; /* Note: there may be additional fields here, depending upon wFormatTa
プログラミングの光景：第1回 デバッグについて｜gihyo.jp
プログラミングに関する雑多なあれこれ 今号から、「プログラミングの光景」と題して連載することになった高林と申します。プログラミングは趣味として、仕事として、かれこれ10年ほど行ってきました。本連載ではプログラミングに関する雑多な事柄について書く予定です。 第1回は、プログラミングとは切っても切れない関係にある「デバッグ」について取り上げてみようと思います。 デバッグの時間 ソフトウェア開発において、デバッグに要する時間は相当のものです。プログラマとしては「いやいや、自分はそれほどデバッグに時間を使ってないよ」と否定したいところですが、冷静に考えてみると、現実には自分が考えているよりも（そうであってほしいと考えているよりも）デバッグに時間を要しているように思えます。それに、バグは他人が書いたコードに混入していることもあるので、たとえ自分がバグを入れなくてもデバッグするはめになります。 デバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM DAOを繰り返すな！ : Java technology : dW - Japan
codeなにがし
ma.la/mirrorman / 2004-11-08 - FAX
IBM developerWorks:わかりやすいコードを作成するための6つの方法
http://ja.doukaku.org/
IPA セキュア・プログラミング講座
音声処理をＣ言語でプログラミングしたいのですが、初心者なので困ってます。…