タグ

関連タグで絞り込む (2)

タグの絞り込みを解除

policyとprogrammingに関するakiyanのブックマーク (5)

  • DRYと不当な抽象化によるコストについて | POSTD

    記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、

    DRYと不当な抽象化によるコストについて | POSTD
    akiyan
    akiyan 2016/11/01
    これはとても思う。抽象化するときは呼び出し元をテストコードでガチガチにカバレッジしとかないと、抽象化部分の変更が怖すぎる。
  • プログラミング地獄への道は“ベストプラクティス”で敷き詰められている:Rails Hub情報局:エンジニアライフ

    Ruby on RailsのメジャーバージョンアップとなるRails4のリリースが近づいて来ました。先日、日人(あるいはアジア人)として初めてRailsコアチームのコミッタとして迎え入れられた松田明氏によると、Railsの生みの親であるDavid Heinemeier Hansson氏(以下、通称のDHHを使います)は、プロジェクトをリードするという意味で活動が活発になっているそうです。 そして最近のDHHは、ブログもよく書いています。彼は歯に衣着せぬ発言でも知られています。強い主張を持った(opinionated)なフレームワークの作者らしく、DHH自身もきわめてハッキリと物を言います。攻撃的とまでは言いませんが、IT業界技術動向などでは割と何かをクソミソにけなしたりということをします。 DHHが何かをけなすときは、だいたい何らかの鋭い洞察とパンチの効いた皮肉が含まれていて、Twit

    プログラミング地獄への道は“ベストプラクティス”で敷き詰められている:Rails Hub情報局:エンジニアライフ
  • PHPの次に勉強する言語は何か? - kなんとかの日記

    マジレスすると、HTTP。 Webアプリケーション作っているのに、PHPの知識はあってもHTTPプロトコルの知識がさっぱりな人が多くね? 他の言語を勉強する前に、GETとPOSTがどう違うのかぐらい勉強しようよ。 それでもあえて PHP ユーザが次の「言語」を選ぶなら、JavaScript か ActionScript ... と言いたいところだけど、どっちもサーバサイドプログラミングが苦しいから、ここでは Python を推す。 PHPユーザにPythonを薦める理由: 家サイトでちゃんとしたドキュメントを公開している 最近は日語のもたくさんある Rubyより仕組みが簡単で黒魔術が少ない グローバル関数が多いところが PHP チック なんたって Google App Engine で使える唯一の言語だもん PHP ユーザは、PHP家サイトでの充実したドキュメントに慣れているだろう

    PHPの次に勉強する言語は何か? - kなんとかの日記
    akiyan
    akiyan 2008/07/12
    同意。
  • プログラミングは「設計」である - モジログ

    「設計」を、以下のように定義してみる。 ・設計とは、設計図をつくることである。 ・設計図とは、「それに従えば、誰が作っても同じものができる」ものである。 ここで「誰が作っても同じ」というのはもちろん、作る人に一定のスキルがあるというのが前提で、また「同じ」といっても、許容しうる程度の違いはあるものとする。 建築の場合、建築家が「設計」し、工務店などの施工業者が「施工」する。 設計がきちんと作りこまれていれば、施工業者が作り出すものにはそれほど大きな開きは出ない。 しかしソフトウェアでは、「設計」と「実装」をそれほど明確に切り分けられない。 ソフトウェア開発において、「そこから先は、誰が作っても同じものができる」レベルとは、一体どのあたりだろうか。 モジュールやクラスを決めるくらいでは、「そこから先は、誰が作っても同じものができる」レベルにはほど遠い。 では、関数やメソッドのインターフェイス

  • 頭の中にプログラムを入れる

    Paul Graham / 青木靖 訳 2007年8月 いいプログラマは、自分のコードに集中しているとき、それを頭の中に保持しておくことができる。数学者が取り組んでいる問題を頭の中に入れているのといっしょだ。数学者は学校で子供たちが習っているように、紙の上で問題の解いているわけではない。彼らは多くの部分を頭の中でやっているのだ。問題の領域をよく把握しようと努めることで、普通の人が記憶にある育った家の中を歩き回れるように、数学者は頭の中で問題空間を歩き回ることができる。最高の状態で行われるプログラミングもそうだ。プログラムの全体を頭の中に入れたなら、それを思い通りに操れるようになる。 これはプロジェクトのはじめにおいては特に価値がある。それはプログラムを作り始めるときに最も重要なことが、やっていることを変えられるということだからだ。単に問題の解き方を変えるという ことではなく、解いている問題

  • 1