初心者プログラマにたいして「これは読むべき」だと思うコードを教えてください。 プログラムの勉強の際に良質なコードを読むをおすすめされたのですが、どのコードを読めばいいのかわかりません。参考になるコードやライブラリがありましたら教えていただけるとうれしいです。とりあえず、PHP中心でお願いしたいです。
初心者プログラマにたいして「これは読むべき」だと思うコードを教えてください。 プログラムの勉強の際に良質なコードを読むをおすすめされたのですが、どのコードを読めばいいのかわかりません。参考になるコードやライブラリがありましたら教えていただけるとうれしいです。とりあえず、PHP中心でお願いしたいです。
2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマーク数が多いものを選びました。 知らないツールもあるので、分類がいいかげんなところもあると思います。何か気づいたらコメントください。 解説が不十分なツールについても、補足(コピペで本文に取り込める体裁だとありがたい)を頂けると助かります! 元ネタの投稿は現在進
0.1を10回足してみた。 PHPの場合 PHPでの結果、1 //——————————————————————————– JavaScriptの場合 JavaScriptでの結果、 0.9999999999999999 //——————————————————————————– Python(Ver2.7)の場合 Pythonでの結果、0.9999999999999999 //——————————————————————————– Rubyの場合 Rubyでの結果、1.0 //——————————————————————————– Haskellの場合 Haskellでの結果0.9999999999999999 //——————————————————————————– 結論、PHPは神、その次、Ruby
この記事はartima developerに掲載されている、Trygve Reenskaug氏とJames O. Coplien氏による記事「The DCI Architecture: A New Vision of Object-Oriented Programming」を、著作権者であるBill Bennrs氏の許可を得て翻訳したものです。本文内の図の著作権はArtima, Inc.に帰属します。(原文公開日:2009年3月20日) 要約 オブジェクト指向プログラミングはプログラマとエンドユーザの視点をコンピュータコードにおいて統一するものと考えられていた。この恩恵はユーザビリティとプログラムの分かりやすさの両面にわたる。しかし、オブジェクトは構造をとらえるのに長けている一方で、システムの動作をとらえることができていない。DCIはエンドユーザのロールに関する認識モデルとロール間の関係を
An experienced project manager I used to work with claimed that he took the programmers’ time estimates, multiplied by pi and converted to the next time magnitude to get the true number. 1 day converts to 3.14 weeks. He had learned the hard way that programmers are bad at estimating times. To get a more precise conversion, I’ve created a translation table for programmers’ time estimations, trying
アジャイル開発でプロジェクトを進めている現場では、やるべき作業を表す付箋や、進行状況を示すチャートをプロジェクトルームの壁に貼って状況を見える化し、共有している光景をよく見かける。 本稿では、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていく。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案する。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装 “TRICHORD” を紹介する。 アジャイル開発プロジェクトにおける見える化 XP(eXtreme Programming)の中に、“情報発信する作業場所”というプラクティスが紹介されている。これはプロジェクトの進行状況を、一目で把握できる
最近新人のコードレビューをする機会が増えまして、自分の中の経験則を言語化する機会に恵まれています。なんとなーくわかっていた事柄を人に伝えようとするのは、いつの時代にも最良の学びの機会ですね。 さて新人各位に個別に伝えた「JUnit4利用に関する注意」を整理してみました。JUnitは自由度の高いフレームワークであり使い方は十人十色かと思いますので、もっと良い使い道をご存知のかたは是非はてブコメントなどで教えていただければと思います。ちなみにここで言う「テスト」とは実装の前に書く単体テストだけではなく、実装後に書かれるものや自動化された統合テストも含めています。 1.JUnitを使うために押さえるべき前提知識 テストメソッドの実行される順番は不定 EclipseのJUnit実行機能に親しんでいると意外と気付けないのですが、JUnitはテストクラス内のテストメソッド実行順を保証していません。それ
でもそんなのどうでもいいから最終的には皆自分のTDDを持てばいいのではと思っている 2012-08-30 12:27:33 via web あなたがTDDだとおもうものがTDDです。 ただしたにんのどういをえられるとはかぎりません。 2012-08-30 12:30:20 via Twitter for iPhone ということで、TDDを定義します。 はじめに TDDを定義し、それの基礎を明らかにし、リファレンスモデルを明にする。 そして、他の例も紹介してみます。 TDDとは何であるか TDDとはソフトウェア開発者向けフレームワークです。 RED -> GREEN -> REFACTOR のスパイラルモデルが根幹にあります。 RED, GREEN, REFACTOR は開発者のアクティビティになります。 僕の理解ではプロセスの部分集合がフレームワークであるから、プロセスと呼ぶ事もできるけ
書籍「ThoughtWorksアンソロジー」の「第5章 オブジェクト指向エクササイズ」より。概要優れたオブジェクト指向設計の原理を自分のもにし、実際に使えるようになるためのエクササイズ。ほぼ必然的にオブジェクト指向になるコードを書くように強制する9つのルールを、1000行程度のプロジェクトで適用してエクササイズ。要するに、オブジェクト指向の「理解」を「実践力」にするための『練習』メニューの紹介。注意あくまで「練習」で、普遍的なルールとは限らない。ただし、筆者(Jeff Bay)は実際のプロジェクトで適用して上手く運用出来ているらしい。エクササイズ・ルール一覧ルール1:インデント1段階 1つのメソッドにつきインデントは1段階までにすることルール2:else句禁止 else句を使用しないことルール3:プリミティブ禁止 すべてのプリミティブ型と文字列型をラップすることルール4:ドット1つ 1行に
Rob Pike, now a Distinguished Engineer at Google, worked at Bell Labs as a member of the Unix Team and co-created Plan 9 and Inferno. He was central to the creation of the Go and Limbo programming languages. Rob shares an experience at Bell Labs that changed his approach to debugging. Save 35% off the list price* of the related book or multi-format eBook (EPUB + MOBI + PDF) with discount code ARTI
以前、図らずも注目を集めてしまった人材獲得の件からおよそ1年経ちました。 そこで、再び募集をかけてみようと思います。今回は転職サイトは使わずにここで告知します。 【募集要項】 ●これは1次試験です。合格者には次のステップの案内を送ります。(2次試験以降は非公開で行います) ●待遇はその人の実力次第ですが、年俸で500~1000万円の間になるでしょう。基本在宅勤務です。居住地不問。 ●仕事は相場に関わりのあるソフトウェアを作ること全般です。クライアントサイドはWindows(C#)/iOS/android, サーバサイドではJava/Rubyがターゲットになります。その中から、得意なもの・興味のあるものを担当してもらいます。 ●上記の言語/プラットフォームを知らないのは問題にしない(勉強すればいいだけなので)ですが、ソフトウェア作りに適度なプライドと熱意を持っていることは問題にします。(過剰
先日「ブログ書きが不調」と書いたが、言語のアウトプットが不調なときは、それ以外のことをするに限る...たとえば黙々とプログラムを書く、音楽に浸る、身体を酷使する、などだ。というわけで月曜日、天気は晴れなかったものの、研究のデータ処理に使うRubyスクリプトを書きまくって鬱憤を晴らしていた。 ところがそのプログラム脳のまま夜にはVimM#4に行こうとした時、そういえば内定者3人によるSkype会議が予定されていた(つまりダブルブッキング)ことを思い出し、自分の阿呆さに呆れ、本当にすみません、でもって結局気分は晴れず。 前置き(ただの日記)終わり。 本題。 Rubyの配列でいろいろいじる時に、for i in ...と array.each でだいたいできるんだけど、もちっとスマートにやりたいなぁと思って調べていたらこれ使えるんじゃね?と気がついたことがいくつかある。zipとinjectとev
文部科学省「プログラミン」は1024x768ピクセル以上のモニタ解像度でご覧ください。 ご覧いただくためには、最新版のFlashPlayerをインストールのうえ、 JavaScriptを有効にしてください。 「Adobe Flash Player」の最新版はアドビシステムズ社のWebサイトより無料でダウンロードできます。 インストール方法については、配布元の説明をお読みください。
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい!どの口がアジャイル出来るって言ってるねん!」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを10年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか?」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
-- 追記@2012-08-08 09:20JST -- この速さなら言える。この前職場(派遣先)でプログラミングテストがあったのだけど、弊社社員の1/3がFizzBuzz解けなかったんだ… — papamitraさん (@papamitra) 8月 6, 2012 これ読んで工エエェェ(´д`)ェェエエ工となり、書いた。 -- 追記ここまで@2012-08-08 09:20JST -- あるいは、「FizzBuzz書けない奴m9(^Д^)プギャー」のもにょもにょ感。 結論だけ、書く。 要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。要らないから。そして知らないから。 さて、まずはこの問題解こうか。制限時間5分。 タイトル: Ants 問題
食事を抜く、おざなりにする 朝食、昼食、夕食を熱中しすぎて抜いてしまう。ブドウ糖は蓄えておくことができません。定期的に栄養を取らないと脳がエネルギー不足となって、生産性の低下を招きます。凡ミスが多くなってくる。 きりの良いところで必ず食事をとること。食事の間隔があきすぎることがないように注意する。 生産性のないことに2〜3時間熱くなる 落ちついてコードを読み、設定を直せばすぐに解決するバグを、憶測で○○が悪いのかな?とあれもこれもと手を出すうちに2,3時間を費やしてしまい疲弊してしまう。 感情を抑え、物事を論理的に考える落ち着きを取り戻そう。 何を完了したら仕事が終わりなのかを理解していない コードを書けば仕事は終わりですか?QAやテストやドキュメントなどはいりませんか?誰に承認をえるのですか?これら、仕事として必要なことに注意を向けずに仕事を終わったと思ってしまう。本当に足りないことはあ
美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ。(本書「はじめに」より) コードは理解しやすくなければならない。本書はこの原則を日々のコーディングの様々な場面に当てはめる方法を紹介します。名前の付け方、コメントの書き方など表面上の改善について。コードを動かすための制御フロー、論理式、変数などループとロジックについて。またコードを再構成するための方法。さらにテストの書き方などについて、楽しいイラストと共に説明しています。日本語版ではRubyやgroongaのコミッタとしても著名な須藤功平氏による解説を収録。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載しています。以下のリストに記載の年月は、正誤表を作
Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く