こんにちはこんにちは！！ プログラミング言語とかマスターしてると、なんかかっこいい感じですよね！ 就職とか転職にもバッチリ有利そうだし…！ だけど難しいよね、言語とか…。 入門書とかどれだけ買ってみても毎回 Hello world どまりだし…。 なんでなんだろう？ なんでうまく覚えることができないんだろうね。 世の中には、ちゃんとプログラミングできる人がたくさんいるのに…！ うーん。 たぶんこれかな… なにか作りたいものがある または なにかを作る必要がある なんて状況以外で、マトモにプログラミング言語を習得してる人って ぼくほとんど見たことないんだけど、みなさんはどうでしょう…！ たしかに、コンピュータを教えてくれる学校に通って、ちゃんと教えてもらえればJavaだってなんだってしっかりと、その時だけは身に付くんだけど、 でもそういうのって、ほんとに「その時だけ」なんだよね…。ほとんどの

この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく

「ＯＯ（ＯＯＰ）とは何か？」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。 リスコフのユーザー定義型（aka、抽象データ型。データと手続きのセット）そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするＯＯ（ストラウストラップ。aka、クラス指向。継承を使ったプログラミング）。もしくはそれらを一般化したＯＯ（クック。aka、手続きによる抽象化）。 メッセージングにより動的性を実現しようとするＯＯ（ケイ。aka メッセージ指向） 今回登場した、後者のメッセージングのＯＯのミニマリズムをおしすすめることによって派生的に生じたＯＯ（アンガーとスミスからの 派生 変形。aka、プロトタイプベースＯＯ。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“

「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか？」という質問を受けたので、「はて？どうしているだろうか？」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基本的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス

この記事は小飼弾氏が，2008年3月24日に発売した日経ソフトウエア2008年5月号の特集「はじめてのプログラミング」向けに著したものの再掲です。記述された内容は，執筆当時の情報に基づいています。 あなた，プログラマになりたいんですって？ 本当に？ 本当に？ もう一度尋ねます。本当に？ 3回も念を押したのには，理由があります。このあと，さらに念を押します。この手紙を読み進めれば，あなたにもその理由がおわかりいただけるかと思います。 「日経ソフトウエア」を読んでいただいているからには，あなたは「プログラマ」という職業について，ある程度のイメージをお持ちだと思います。プログラマ，プログラムを作る人。では，プログラムって何でしょうか？ その定義は，これをお読みになった人の数かそれ以上存在しますが，私にとっての定義は「コンピュータが仕事をできるようにすること」です。ご存じだとは思いますが，コンピュ

まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」に行ってきました〜。今年初めて行ったイベントなのですが、とてもいいお話を聞くことができました。美しいコードとはどのようなものか、またそのようなコードを書けるようになるためにはどうすればいいのかというお話でした。 以下、まとめになります。僕のメモを元にしたので、まつもとさんが話された内容と多少ズレがあるかもしれません。 そもそもコードとは何か 「コードの美しさとは」という前に、そもそも「コード」とは何か。 ソフトウェアの作成はものづくりではない コードは工業製品ではない。コードは、車とかと同じ工業製品だと思われることが多く、例えば次のような勘違いがある。 日本は「ものづくり」が得意だ。だからソフトウェアも「ものづくり」として取り組めばいい 車のように、ソフトウェアも部品をどんどんコピーして組み合わせばできる 違うよ！全

以前、とあるシステムのソースコードを読む機会があったのだけどあまりにひどかった。あのひどいコードでまあまあまともに動いているというのが逆に信じられない。今日昼ご飯を食べながら少し話していたのだけど意外と知られていないようなので、話せる範囲でいかにひどいのか説明してみようと思う。 まず、ソースコードが大雑把に見積もって3750万行あるのだけど、その中でまともに機能しているコードは3%しかない。10分の1程度のソースコードで同程度の機能を実現しているシステムもあるのでほんとあのシステムのコードはゴミだと言っても過言じゃない(*1) プログラマとしてはなんでそのプロジェクトはそんな状態になってしまったのか気になるところだけども、まあ多くのプロジェクト同様、真相を知る人は誰もいない。でもまあ、実際に機能しているコードのコピーみたいなものがあちこちに散らばっていることからしてコピー＆ペーストが盛んに

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

焦ってる時、疲れてるとき if ($val == true) { 等と比較する時に、 if ($val = true) { 切羽詰まったあげくこんなコードを書いてて、デバッグに苦しむ事があると思います。いつかある気がします。 回避するチョッとしたテク そこで、 if (true == $val) { こんなふうに変数名を右辺に書くクセをつけとくと、 if (true = $val) { 間違ってこんな書いてても、パースエラーで怒られるから変数汚染されなくて助かりますね！

「変数のスコープは狭いほど良い」と妄信する 変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある*1。 実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。 たとえば、プログラムのいろいろな箇所から比較的頻繁にアクセスする必要があるようなオブジェクトや機能がバインド(格納)された変数やメソッドのスコープをクラスやメソッド内のローカルにして、それを使うときは、いちいち各クラスやメソッドにパラメータ渡しのチェ

とりあえず思いついたもののまとめ。 まずは、ベーシックなものから。 変数のスコープをなるべく狭くしろ 他はグローバル変数を使うなとか、モジュール化と界面を意識せよなど。とにかくスコープは重要かつ意外と奥が深い。スコープに関係する機能は、モジュール(パッケージ)、クロージャ、ローカル関数、ローカルクラス、変数の種類、アクセス制御など。 同じロジックのコードを2度以上書くな 他はDRY原則、コピペをするななど。自分の場合、2度書く方がシンプルになる場合、2度書くこともある。特に、ifやswitchなどのロジックの中で同じコードが2度現れる場合、ちょっとしたコードでわざわざ別のところで関数やブロックにまとめて、それを参照するのは面倒。但し3度以上現れる場合は関数などにまとめるケースが多いかも。 汎用コード内で条件分岐コードを減らせ 他はifをポリモーフィズムによりなくせなど。条件分岐は汎用性を損

Binstock on Software: Perfecting OO's Small Classes and Short Methods The Pragmatic Programmersシリーズの新しい本、The ThoughtWorks Anthologyの中に 興味をそそるエッセイがある。Jeff Bayの"Object Calisthenics"だ。 これは良いオブジェクト指向の性質を実証する小さなルーチンを書く方法をマスターするための 詳細にわたるエクササイズだ。オブジェクト指向なルーチンを書く能力を向上させたい開発者がいるなら このエッセイに目を通すことを勧める。ここにBayのアプローチを要約してみよう。 彼は次にあげられる制約のもとに1000行のプログラムを書くことを勧めている。 これらの制約は意図的に過剰な制限となっているが、これは開発者を手続き的なやり方から脱却させるた

Perlとは何か Perlはテキスト処理に特に優れた非常に強力なプログラミング言語です。でも，うまく使えばシステムをきれいに掃除させることもできますし，さらにあなたの心もいやしてくれるに違いありません。また，多くのディストリビューションで標準的にインストールされていますし，自分でインストールすることも難しくはありません。 「PerlってCGIじゃないの？」と思う方がいるかも知れません。確かに，CGIで利用するためにPerlに出会った人は多いでしょう。主な利用方法といえば，Webアプリケーションの作成かもしれません。しかし，「プログラミングPerl」＊1によれば，Perlは最初，システム管理のためのツールとして作られたものだったのです。 FedoraなどのLinuxディストリビューションでは導入時に開発環境を選ぶとPerlがインストールされます。同時にPerlのドキュメントもインストールされ

第1回 そろそろ本気で学びませんか？ | Think IT これ、今この記事書いてる時点で650以上ものブクマがされているんだけれども、あまり内容がよろしくない。 というのも、解説はとても丁寧ですごくよい内容なのだけど、サンプルコードの書き方がどうも古くさい。 onclick属性とか、今時のフロントエンドエンジニアはそんな書き方はしない（と思う）。 なぜonclickをあまり推奨しないのか やっぱり、エンジニアとデザイナーorマークアッパーとの分業の点でHTMLの属性にスクリプトを書いちゃうのはあんまりよろしくない。 たとえばの話だけど関数の名前を変えたかったり、だとか、HTMLを変更したり、っていうときにミスが起こりやすくなってしまう。 これは分業していなくてもどちらにしろ発生してしまうことだと思う。 他にも前に書いたのだけど、aタグとかでonclickしちゃうとhrefにreturn

上を行くかどうかは知りませんが :-p Ajaxはクライアントの都合でサーバーに通信を仕掛けるpull型の通信ができ、Cometはサーバーが好きなタイミングでクライアントへデータを送りつけるpush型の通信ができるわけですが、新たに双方向の通信ができる技術を開発しました。 具体的には、JavaScriptとサーバーの間で双方向のRPCができます。すなわち、サーバーからクライアント側のJavaScriptのメソッドが呼べるし、逆にクライアント側からサーバー側のメソッドを呼ぶこともできます。 サーバー側で call("addMessage", "Hello!") とやると、JavaScript側の function addMessage(msg) { ... } という関数が呼ばれたりします。 この技術を使って、試しにチャットシステムを作ってみました ＞ デモ （ソースコード）*1 リアルタイ

ドットインストール代表のライフハックブログ