TDD Boot Camp 札幌に登壇させていただきました - t-wada の日記（旧）
TDD Boot Camp もとうとう北海道に上陸です。1/22, 1/23 の2日間開催された「TDD Boot Camp 札幌」に登壇させていただきました。参加くださった皆様、そして企画を立ち上げ主催した id:shuji_w6e さん、ありがとうございました。 TDDBC 札幌も素晴らしいスタッフワークにより、素敵なイベントになったと考えています。 イベントの構成は TDDBC 2日間二部構成のコースで、結果的には次のような構成で行いました。 一日目午前その1 導入講演。『プログラマが知るべき97のこと』からテストに関するエッセイを中心に紹介。 一日目午前その2 TDD についての講演 一日目午後その1 TDD & ペアプロについてのデモ (with id:shuji_w6e さん) 一日目午後その2 (ペアプロ+コードレビュー)×2 一日目夜 懇親会 二日目午前その1 応用トピック
TopCoderから学ぶ美しいマクロや型宣言 C++ - peroon's diary
TopCoderというプログラミングコンテストで 他人のコードから発見した、美しいマクロや 型宣言を紹介します。 これを導入することで、C++のコードが短くなり、 早くコーディングすることができます。 ※すべてのTopCoder参加者がマクロなどをテンプレートと して用意しているわけではありません。 マクロなどを定義している人は半分より少ないようです。 TopCoderの他人のコードを参考に、 マクロやtypedefによる型宣言をまとめました。 コードの全体はこのようになっています。 （あとで個別にコメントします） //include //------------------------------------------ #include <vector> #include <list> #include <map> #include <set> #include <deque> #in
いろいろな言語のコーディング規約，スタイルガイドのリスト — TRIVIAL TECHNOLOGIES 2.0
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー プログラミング言語(C#，VB，PHP，C/C++，Python，Java，Ruby，JavaScript，Objective-C)やHTMLのコーディングスタンダードを集めたリストを発見しました。日本語訳があるものはできるかぎり探し出して，括弧のなかに併記して補ってあります。微妙に古いのが混じってるかな。Rubyは日本発のコーディング規約がある気がする(まつもとさんの日記を見つけた)。 元記事にPerlのスタイルガイドがなかったんだけど，モダンなPerlスタイルガイドがあったら教えて欲しいです:-)。 PythonにはPEP8というコーディングスタイルガイドがあってよく読まれることは
無償のコーディングサポートツール「CodeRush Xpress」がすごい
越後在住子持ちプログラマー奮闘記 - Author：まさる（高野 将、TAKANO Sho） 目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 338 記事 - 0 コメント - 13776 トラックバック - 105 ニュース ネタ元→ナオキにASP.NET（仮） : VS ユーザーの開発生産性を大幅アップ無償のアドイン CodeRush Xpress と Refactor! 例えば、CodeRush ・ブロックの見える化（スコープ範囲を薄く線引きし可視化しています） ・Throw とか Exit とかの処理から処理へのジャンプが発生する場合のジャンプ先へのアニメーション表示（どこに飛ぶかが一目でわかる） ・宣言、参照間のジャンプ（わんくま同盟のまさるさんお勧め） さっとあげるだけで3つ。実際に使ってみると細かな点で恩恵を受けることになります。 というわけで、
Zen-Codingの応用でもっと超速に - 原稿ありきの変換について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに こんにちは。R＆D統括本部 制作本部 ウェブデベロップメント部に所属しております。岡部和昌（@kzms2）と申します。 前回の記事（マークアップ効率化 - zen-codingでコーディングを倍速に）ではZen-Codingの基本について説明しました。 また、その内容をCSS Nite実行委員会（公式ページ）が主催した、Dreamweaver Town Meeting in TokyoというDreamweaverにフォーカスをあてたイベントで公演させていただきました。 ［撮影：飯田昌之］ その公演では、Zen-Codingを知らない方向けに、Zen-Codingとは何か・どんなことが出来るのかなど、基本に関して実演を行い
プログラマーには、コーディングの生産性で10倍、コードレビューの速度では6倍もの能力差があるという
プログラマーの生産性をテーマにした有名な著書「ピープルウェア」には、最も優秀なプログラマと最低の成績のプログラマのあいだには約10倍にあたる生産性の違いがある、というデータが出てきます。 これは、1984年から1986年にかけて92社、延べ600人が参加したプログラミングコンテストのデータを分析した結果から導き出された結果で、課題として与えられたプログラミング作業の開始からコンパイル時のエラーを消すところ（第1チェックポイント）へ到達するまでにかかった時間を比べています。 グラフを見ても分かるように、最優秀者と最低者のあいだには作業時間にして約10倍のひらきがあります。また最優秀者は平均の約2.5倍の生産性だそうです。そして、COBOLやFortranのような旧世代のプログラミング言語と、PascalやCのような現代的なプログラミング言語でのコーディングでの生産性はほとんど同じであったそう
テスト駆動開発の効果はどのくらいある？
ソフトウェアの開発を行うときに、まずテストケースを先に作ってから機能を作り込む「テスト駆動開発」（Test-Driven Development：TDD）。これにより、ソフトウェアの開発工数や品質にはどの程度の変化があるのでしょうか。 TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ この疑問について調査した論文を、奈良先端科学技術大学院大学 助教の森崎修司氏が3月10日のブログ「国立大学法人奈良先端科学技術大学院大学 助教」のエントリ「TDD(テスト駆動開発)の適用評価を紹介した研究論文 - エリクソンはじめ3社」で紹介しています。 開発時間はやや増えたがコードの品質は上がった 論文全文は有料なので読めないものの、森崎氏のブログによると次の知見が得られたとのことです。まず、ソフトウェ
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
堅牢なコーディングルールを策定する方法(1) - 都元ダイスケ IT-PRESS
「ある処理をするコードを書く」というのは「ある出来事を文章に表現する」のと似ていると思っている。 まず表現に使う言語は様々であり、使用人口の大小はあれど、基本的に優劣はない。言語が同じだったとしても、十人十色の表現をし、全く同じ出来事を表現したものであっても、複数人が全く同じ文章を作る可能性は限りなく小さい。同じ人が表現するんであっても、今と昔で「全く同じ文章」を書くとは限らない。むしろ微妙に差異があるのが普通だ。 そんな「コーディング」に一貫性を持たせるのがコーディングルールだ。インデントはスペース4つだとか、braceの位置はどうだとか。複数人で小説を執筆する*1場合は、「ですます調に統一しよう」とか色々な取り決めをすると思う。このあたりの一貫性がないと、非常に読みにくい小説が出来上がるだろう。 とまぁ、ルールってのは、複数人間の意識合わせのために*2存在する。例えば法律もそうだ。そし
あなたの制作人生を「速記コーディング」で豊かにする、Texterを使ったアウトプット術
何万回も同じ操作で同じ文字を打つ必要はありますか？ よく使う日本語や同じようなコードを、毎回同じように打つのは面倒くさいな… 思考した事がそのままの感覚でアウトプットできれば生産性はもっと高まるはず。 コードを書いている時、いつもそう感じていました。 Texterというソフトに出会ってから、そんな日常が少し変わりました。 キーを打った事を忘れて、 頭の中で浮かんだ事がそのまま目の前に現れるような感覚、 まるで、「速記」を自動展開しているような心地良さを味わえました。 今回はSACSSコーディング勉強会 vol.5のライトニングトークでお話した「Texter」を紹介します。 このTexterを使うようになってから、打つ事が革命的に早く・楽しくなりました。 効率化を追求している人にはお勧めのツールです。 目次 Texterって何ができるの？ Texterのダウンロード(日本語化済み) Text
すべてのプログラマが知っておくべき97のこと
原文(投稿日：2009/09/16)へのリンク すべてのアーキテクトが知っておくべき97のこと (InfoQの記事)に続いて、「97のこと」シリーズの続編はすべてのプログラマが知っておくべき97のこと、だ。これらはwikiに集められて、誰でも貢献できるしコメントも受け付けている。 このwikiには既に(この記事を書いた時点で) 88 のエントリが集まっていて読まれている。例えば、 コードだけが真実を知っている by Peter Sommerlad氏 スピードは命取り by Uncle Bob氏 API設計の黄金律 by Michael Feathers氏 自分のIDEを知る by Heinz Kabutz 人々のためにテストを書くWrite Tests for People by Gerard Meszaros氏 InfoQは「すべてのプログラマが知っているべき97のこと」の編集者であるK
続・バグを生まないコーディング法 | EE Times Japan
フォーラムでの議論は次のような発言から始まった。 「中括弧を使って複合文を記述し、文の切れ目にセミコロン「;」を使う言語では、オールマン・スタイルを使うべきではない」 私はどちらのスタイルでもよいと思っているが、「1TBSでは図2のような間違いを人間のコード・レビュワーが発見しにくい」という1TBSに対する批判は受け入れがたい。 人間のコード・レビュワーが、このような間違いを見落とす可能性があることは認める。しかし、まさにこの例は、ここで紹介するようなコーディング規則の重要性を物語っている。つまり、「バグを効果的に排除するためには、コーディング規則に強制力がなければならない。2個以上の競合する規則がそれぞれバグを防げても、それらの中の1つの規則だけが自動的に強制できる場合は、より強制力がある規則の適用が推奨される」ということだ。 われわれのコーディング規則では、上記のような例はまさに自動
あなたのソースを汚くして生産性も下げている、たったひとつの間違い - よくわかりません
この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザパタ140文字