職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
GrowthForecast-Aggregator-Declare - tokuhirom's blog
https://metacpan.org/release/GrowthForecast-Aggregator-Declare use GrowthForecast::Aggregator::Declare; my @queries = gf { section member => sub { # post to member/count db( name => 'count', description => 'The number of members', query => 'SELECT COUNT(*) FROM member', ); }; section entry => sub { # post to entry/count, entry/count_unique db_multi( names => ['count', 'count_unique'], descriptions
Jenkinsでビルド・パイプラインを構築する - プログラマでありたい
前回、Jenkinsのインストールについて書きました。今回は、Jenkinsでビルド・パイプラインを構築する話です。 ビルド・パイプラインとは？ ビルド・パイプラインとは、ビルドのプロセスを分割して順番に実行していくことです。例えばビルドの流れとして、コミット→静的解析→コンパイル→ロジック層のユニットテスト→UI層のユニットテスト等があったとします。これを1つのジョブとして登録するのではなく、1つ1つのジョブとして実行し、成功した場合のみ次のステップに進めるようにします。これがビルドパイプラインです。 メリットとしては、どの工程で失敗しているのか解りやすいことが第一にあります。またJenkinsの特性を活かして、特定のジョブを並列で動かしたり出来るので効率化も出来ます。また、更に検証済みマージなど、高度な活用にもつながります。 Jenkinsでビルド・パイプラインの構築 元々Jenkin
動的型とか静的型の話の前に「作者の気持ち」を考えろ - mizchi log
自分の思考を整理する意味でも、件のアレについて考えたことを書いてみる。 変数に型がないということの利点について考える - サンプルコードによるPerl入門 http://d.hatena.ne.jp/perlcodesample/20130227/1361928810 この件に触れることはプログラマとしての中二病である。恥ずかしい。マジレス乙だ。 でも気づいたら5000文字も書いてしまったし、公開して酒のんで寝る。 型のフローは機械のためだけでなく、人間に対するものでもある 最近TypeScriptを書いている。こいつを使って、二次元座標上で二点間を求める関数、getDistanceを定義してみよう。 interface IPoint { x: Number; y: Number; } var getDistance = (a:IPoint, b:IPoint): Number => Ma
Hasegawa方式の CSRF対策を試してみた - tokuhirom's blog
Amon2 での実装例です。 使用感としては、 実装はそれほどむずかしくないトークンの保存をサーバー側でやらなくていいので楽といったかんじ。 管理画面とかでつかってみたらよいかもしれぬ。 use strict; use warnings; use utf8; use File::Spec; use File::Basename; use lib File::Spec->catdir(dirname(__FILE__), 'extlib', 'lib', 'perl5'); use lib File::Spec->catdir(dirname(__FILE__), 'lib'); use Amon2::Lite; { package Amon2::Plugin::Web::Hsegawa; use constant { REDIRECT => 10001, VALIDATION_ERROR
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
修正時に一箇所リファクタリングする - $shibayu36->blog;
最近仕事でバグ修正をするときには、必ずその周辺のリファクタリングを一箇所行うという事をしている。今日はそのことについて書いてみる。 時間が経つとコードはレガシーになる これは自分の感覚でしかないのだが、コードというのはどんなに素晴らしい人が書いたとしても、時間が経つと必ずレガシーコードになると思っている。これには例えば以下の理由などがある。 技術が進む 昔は無理やりやらないといけなかったものが、ミドルウェアを入れると簡単に出来るようになったとか コーディング規約が変わる 人が増えるなど、外部要因によってコーディング規約が変わるけど、昔のコードは思想が違うとか そのため、少しずつリファクタリングの時間を設けないとどんどんレガシーなコードが作られていく。 修正時、一箇所修正する それでリファクタリングをしたいのだけど、ずっとリファクタリングをするのもモチベーションを維持できないし、リファクタリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
めしおのアフィリエイト教材レビューブログ
MessagePackが文字列とバイナリをわけないのは問題？
cpanfile
http://shishithefool.blogspot.com/2012/04/el-get-emacs.html