絵日記 グルメ ライフスタイル・暮らし ペット 旅行・海外 日記 ニュース スポーツ ビジネス・経済 趣味・創作 音楽 書籍・雑誌 漫画・アニメ ゲーム 受験・学校 ヘルス・ビューティ IT・家電 学問・科学 まとめ

そういえば昨日の飲み会で誰かが言っていて同意したのがプログラマの机の話。 机の上に紙とペンをどれだけ広げられるかで勝負が決まる。 せまい机に押し込まれて隣の人と触れ合うほど、近かったりするともうだめ。 デュアルディスプレイで得られる効率はコーディングの効率なのだけど、机に広げたノートで得られるのは考えをまとめる効率。 脳の中に展開できない何かをノートに展開ですよ。 紙とペンとか言うと、うげー古いぜとか思うかもしれないですが僕より若い優秀なエンジニアは良く紙に何か描いているなあ。(上の世代は言うまでもない)。 今使っているノートとペンを教えてくれたのは僕よりずっと若い id:kambara氏 だし。
All I Need To Know To Be A Better Programmer I Learned In Kindergartenより。 原文 http://codist.biit.com/fiche/thecodist/article/all-i-need-to-know-to-be-a-better-programmer-i-learned-in-kindergarten プログラミングは複雑なもの。だけど良いプログラマを作るのに必要なことのほとんどは、僕らが幼い頃に習ったこととほとんど変わらない。 このリストのためのインスピレーションはRobert Fulghumの"All I Really Need to Know I Learned in Kindergarten"(http://www.robertfulghum.com/) から得られた。 1.なんでも分けよう 可能
This shop will be powered by Are you the store owner? Log in here
プログラミング, 生活ちょっとワクワクしながらつらつらと書きます。 テレビ朝日のドキュメンタリで、11歳のゴールデンエイジのテニス少年たちを教える松岡修造氏*1の番組を見た。 彼はいつも「○○をできないと世界に通用しない」と臆面もなく「世界」という言葉をだす。あたりまえのものとしてその言葉を出している。「インターハイがどうのこうの」ではなく、「世界に通用するかどうか」ということを常に話している。 そして練習が終わったあとには子供に「なぜ君を選んだのか」を語る。「君には才能があるからだ」「センスがあるからだ」「センスがあるんだから、君はがんばるしかないんだ」「今日一日できみはものすごく成長した」と、教え子のやっていることが無意味ではない、ちょっとでも前に進んでいると一所懸命に語っていた。 この言葉を聞いた子供たちは、「世界」を「手の届かないもの」ではなくて、「届くかどうかは自分次第だ」と思う
古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。 特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。 よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。 ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。 一度固定した文書は次のフェーズで変更
メモ, PHP【PHP TIPS】 58. すごいリロード対策紹介されているのはシンプルなワンタイムトークン.単純なリロード対策であれば ticket の値は乱数でなくても良い.ここを乱数にすることで CSRF 対策も兼ねている.ただこの方法は,場合によってはフォームを正常に送信できなくなってしまう問題がある. 例えば,入力画面→入力確認画面と遷移してから別のウィンドウで入力画面→入力確認画面と遷移すると,前の入力確認画面のフォームは ticket が無効になり,フォームを送信できなくなる(複数画面同時編集ができない). 解決策としては,発行したトークンを全て記憶しておき,POST されたトークンと照合する方法がある. confirm.php session_start(); $token = sha1(uniqid(mt_rand(), true)); // トークンをセッションに追加す
Last Updated on: 2013年12月3日ちょっと気になったので… 記事はコラム形式だったので書いていないだけだと思いますが2つ問題があります。 1. 識別可能なフォームの数に限りがある セッション変数を利用しているため変数名でフォームを識別する必要があり、ユーザが複数のフォームを利用した場合、正しく動作しない。この制限をなくす事もできますが、その場合セッション変数が大きくなりすぎた状態に対処するようにしないとならくなります。(ガーベッジコレクションの実装が必要) 2. レースコンディションによる2重投稿の可能性がある コードを見て分かる通り if (isset($_POST['submit_button'], $_SESSION['ticket'], $_POST['ticket']) && $_SESSION['ticket'] === $_POST['ticket'])
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー!古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
http://www.martinfowler.com/bliki/FluentInterface.html 2005/12/20 数ヶ月前、Eric Evansと一緒にあるワークショップに参加した。 そこで彼がとあるインターフェースのスタイルについて語ったのだが、 我々はそれを「流れるようなインターフェース(fluent interface)」と名づけることにした。 一般的なスタイルではないが、もっと評価されるべき代物だ。 おそらく例を示したほうがいいだろうから、そうしてみることにする。 一番簡単な例は、EricのtimeAndMoneyライブラリだろう。 時間の間隔を作るには、通常は、以下のようにする。 TimePoint fiveOClock, sixOClock; ... TimeInterval meetingTime = new TimeInterval(fiveOClock,
Seasarカンファレンスで、Seasar2入門セッションを、いろんな方に喜んでいただけるようにSeasar2ロードマップと復活のStrutsのセッションに変えるよというアナウンスをしたのですが、Seasar2の入門セッションはやはり必要だということで、元に戻すことになりました。 期待していた方ごめんなさい。でも、入門セッションのほうも面白いネタをいろいろしゃべるつもりなので、是非お越しください。 今後はやるフレームワークは「流れるようなインターフェース」を持ったものになるんじゃないかなぁと思います。流れるようなインターフェースの説明は、ファウラーたんのFluentInterfaceを参照してください。 Seasar2の新O/R Mapper(以後S2JDBCと呼びます)もこの「流れるようなインターフェース」を実現しています。例えば、JdbcManagerを使った検索はこんな感じになります
Last Updated on: 2014年12月5日PRGパターンって不必要…というより有害な気がします。 追記/訂正: 普通に実装するとこの後に書いている問題は発生しないので、別の実装が「戻る」ボタンで戻れない原因の様です。普通にリダイレクトすれば302でブラウザに返すので前のページまで戻ります。態々別のリダイレクトをしているPRGパターンが有害と言う事なのかも知れません。今度戻れないページにあったら調べてブログに書きます。(あまり突くと攻撃と見なされるかもしれないので問題ですけど… 役に立つ対策ではないですがもしかすると重複ポスト対策なのかも知れません。不特定多数向けアンケートなどだと安直にリダイレクトで制限だけしてOKとしているのかも知れません。幾つかのパターンがありそうなので調べてみる価値はありそうです)私はデータのやり取りが増え、かつGETを利用することにより汎用性が劣るこの方
正直な話、Seasarはほとんど触ったことがない。 ただ、せっかくいいものを作っているのに、 日本からなかなか巣立つことがないのは もったいないと思う。 これには、明確な理由があります。日本人の特にソフトウェアにおける「舶来信仰」をぶちこわすためです。 自分たちであまり考えることなく、海外ではやっていたらそれをそのまま受け入れる傾向が、日本人には強いように思えます。それっていいことだとはあまり思えません。 例えば、Rubyも海外からのRails効果でブレイクしたわけです。ちょっと悔しくないですか。せっかく日本で作られたすばらしいソフトウェアなのに、海外で認められるまでは、日本人は、一部の人を除いては評価できなかったわけです。 後、ソフトウェアをやるならアメリカ行けとかシリコンバレーに行けとか。場所なんか関係ないんじゃないの、もちろん、海外にも優秀な人は多いと思いますが、日本にも優秀な人はい
ソースコードにコメントを記載するべきか、どの程度コメントを入れるべきか、どういった内容を書くべきかはプログラミング普遍の議題であって、永遠に解決しない問題の1つのようなところがある。よく言われるのは、短く簡潔で、他人がそのコードを読んだ時に理解を助けるように「なぜ」そのコードをそのように書いてあるのかをコメントとして入れるべきということだ。理にかなっているし、もっとも無難な方法だ。 しかし逆にコメントを書かない方がいいとする考えもある。それはコードとコメントが必ずしも一致していないことがあるからだ。また最初は一致していても、コードに変更を加えていくうちにコメントと内容が一致しなくなり、コメントとコードの不一致が作業ミスの原因になるというものだ。これも一理ある。これを突き詰めれば、コメントをまったく書かなければデベロッパは大量のコードを追って読む必要があり、初期コストは高いかもしれないが結局
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く