ここの流れで、ウォーターフォール開発/スパイラル開発/アジャイル開発に関する話を書きました。 https://www.facebook.com/masahiko/posts/442480179150002 ご意見、御要望、御質問、ご発注は、Twitterからどうぞw @masahikosatoh
TDD及びペアプロを通じてプログラミングスキルを上げるべく、ネットで公開されている『お題』について色々情報収集してみました。 お題やテーマについては、見つけ次第随時追加していきます。 Stackユーティリティ from 『車窓からのTDD』 - 車窓からのTDD こちらについては自分でも試しに写経してみました。以下エントリ。 『車窓からのTDD』を写経してみた ( JDK7 / Eclipse4.2 / Quick JUnit / Mercurial / Bitbucket ) - Shinya’s Daily Report FizzBuzz問題 from TDDBC TDDBC お題 うるう年問題 from TDDBC TDDBC お題 LRU Cache from TDDBC TDDBC お題 ワードフィルタ from TDDBC TDDBC お題 以上、ここまでの4つのお題は和田卓人
あらすじ あなたはとある業務用 Web アプリケーションの開発・保守を任されています。 このアプリケーションは ASP.NET を用いて作成されており、 クライアントサイドは一部 jQuery を利用してナウなヤングにバカウケの UI を実装しています。 さて、今回は 商品情報の変更履歴を一覧表示する。一覧から2つのバージョンを選んで差分を表示できるようにする。 という機能を実装することになりました。 これ自体はちゃちゃっと実装し、以下のようなHTMLが生成されるようにしました: ... <table> <tr> <th>A</th> <th>B</th> <th>変更日時</th> <th>変更者</th> </tr> <tr> <td><input type="radio" name="new_version" value="9"/></td> <td></td> <td>2012-0
2012/6/30 Symfony勉強会 #6 一歩先ゆくエンジニアから見たSymfonyのセッションで使用したスライド。先人たちの知見、ドメインモデル等について。
例外の勉強会をやるので、是非にというお話を頂いて、 LOG.debug(“nice catch!”) というイベントで発表させていただきました。 当日の資料はこちらでご覧になれます。 エラー処理の抽象化 昨年末頃に社内セミナーで発表した エラー処理を書いてはいけない をもうちょっと抽象的に、あるいは具体的な話を入れて焼き直したような内容です。 今回は java-ja さんの勉強会という事で、 なにやらモヒカンとかマサカリとかが飛んでくるらしい、 とんでもないところに来てしまったとビクビクしていましたが、 この難局も何とか乗り切りました。はい。 皆さんとても真面目にソフトウェアエンジニアリングについて議論していて、楽しかったです。 僕は普段Javaでコードは書かないのですが、 Javaだと普通こうする的なのが垣間見えて、 いろいろJavaのバッドノウハウ(あるいはグッドプラクティス)が学べま
エラー処理の抽象化田中英行 <tanaka.hideyuki@gmail.com> 2012/06/26 @LOG.debug("nice catch!") 自己紹介田中英行 http://tanakh.jpTwitter: @tanakhGithub: https://github.com/tanakh Preferred Infrastracture 勤務のプログラマHaskellと、プログラミングについてあれこれ考えるのが好きHaskell入門書 すごいHaskellたのしく学ぼう! Learn You a Haskell for Great Good! の和訳 java-ja …!?とんでもないところに来てしまったぞ (((´・_・`))) ブルブル 本日のお話なぜ、エラー処理は重要なのか?なぜ、エラー処理の抽象化は重要なのか?なぜ、エラー処理の抽象化は行われて来なかったのか?
About Project Euler What is Project Euler? Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems. The motivation for starting Project Euler, and
この記事の対象: ユーザーインターフェイスやグラフィックスを扱うデザイナとプログラマ 昔話から始まって恐縮ですが、私が3DCGプログラミングに触れたのは今から20年近く前、当時学生だった清水亮氏がプログラミング雑誌に投稿していた記事やプログラムを見掛けたのがきっかけだったと思います。私は残念ながら「神童」ではなかったのでベクトルや行列については「チンプンカンプン」でしたが、いずれ3DCGを扱ってみようという気になった事は確かです。 その当時と今では、ハードウェアの性能、ソフトウェアの規模、そこから生まれるCGの表現力、何れを取っても桁違いになってしまいました。が、ベクトルを伸ばして、回して、移動させて、という操作がコンピュータグラフィクスの基本である事は何一つ変わっていません。 20年前の昔、家庭のコンピュータでベクトルや行列の計算をして画面にポリゴンを描くなどという事に興じていたのは、一
is a totally awesome idea still being worked on. Check back later.
(見やすいコードのために出来るたった一つのこと - 日々常々 の続きみたいなもの) 「フォーマッターを使わないなんてありえないよねー」とか思ってたけど、意外と使っていないプロジェクトは多いのかもしれない。思い返せば、私の経験上も多くのプロジェクトで使ってなかった。なので導入する時にあったあれこれを思い出しつつ書いてみる。 必ず同じ定義を使用する 必ず全員同じ定義でフォーマットしましょう。 個々人の好みはあるとは思いますが、それ以上に共通したものを使うことのメリットの方が大きいはずです。 これから導入する場合、まずはその言語で一般的っぽい定義を手に入れ、既存のコードをフォーマットしながら微調整するのがいいです。 なるべく早いうちに導入する 可能な限り早く導入しましょう。途中からの導入も可能ではあります(後述)が、それでもなるべく早期に導入しているほうが、余計なコストもかかりません。 何よりチ
FrontPage / 言語処理100本ノック 3 秒後に NLP 100 Drill Exercises に移動します。 (移動しない場合は、上のリンクをクリックしてください。) © Inui Laboratory 2010-2018 All rights reserved. 研究室紹介/About Us 過去に在籍したメンバー Members 研究室環境 Lab Facilities ↑研究会/Research Meetings 概要 Overview 総合研究会 Research Seminar 意味研究会 SIG Semantics 談話研究会 SIG Discourse 知識獲得研究会 SIG Knowledge Acquisition Embedding研究会 SIG Embedding KIAI Knowledge-Intensive Artificial Intellige
負数が含まれる剰余を計算した場合、言語に跨がって一意な結果が得られない。 -5 % 3 5 % -3 C -2 2 C++ -2 2 Java -2 2 Ruby 1 -1 Python 1 -1 Common Lisp 1 -1 さて、なぜこんなことが起きるのかというと、剰余には複数の定義が存在するからである。 m ÷ n = q … rこの r を剰余と言うが、 r の範囲が 0 ≤ r < n 最小非負剰余 -n/2 ≤ r < n/2 絶対値最小剰余 の二つの定義があり、一般的には前者の「最小非負剰余」を用いるようである。 m が負数、 n が正数の場合は、先程の表にあるプログラミング言語は以下のように分類される。 絶対値最小剰余 C C++ Java 最小非負剰余 Ruby Python Common Lisp しかし、最小非負剰余では r が正数になる必要があり、剰余の結果が
なんとなく最近少し理論的な方面もやってみようかなと思い立って、今回はラムダ計算の基礎を勉強してみることにしました。 関数型言語の基盤らしいです。たしかにちょっと雰囲気はあります。 参考にしたページとしては Wikipedia ラムダ計算 - http://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97 Wikipedia 型付きラムダ計算 - http://ja.wikipedia.org/wiki/%E5%9E%8B%E4%BB%98%E3%81%8D%E3%83%A9%E3%83%A0%E3%83%80%E8%A8%88%E7%AE%97 カリー・ハワード同型対応入門 - http://ocw.kyoto-u.ac.jp/ocw-archives-jp/002-006/pdf/curryhoward
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
久しぶりにシステムエンジニアっぽい話題。 良いコードというのはケース・バイ・ケースであり案件によって異なるものですので、あくまで『私が思う良いコード』についてです。 私がコードに対して持ってる座右の銘は、これです。 動く汚いコードより、動かない綺麗なコード 動く汚いコードはトラブルが発生して動かなくなったときに「なぜ動かないか」が解らず修正が困難ですが、動かない綺麗なコードは誰かが動くように直せば動き、修正が簡単です。故に、トラブルが発生したときのメンテナンス工数に差が出ます。トラブルは必ず発生するものですからね。動く汚いコードを綺麗にするには多大なるコストが掛かりますが、動かない綺麗なコードを動くようにするのはそれほど難しいことではないでしょう。一切トラブルも追加開発も発生しないと仮定するならば動く汚いコードでも問題ありませんが、果たしてそんなことがありうるでしょうか? むしろ、トラブル
第21回オープンラボ岡山の発表スライド http://openlab.okaya.ma/wiki.cgi?page=%CA%D9%B6%AF%B2%F1%2F%C2%E8021%B2%F3Read less
2012年02月10日13:00 カテゴリアルゴリズム百選アマグラマーのすすめ 博士の異常なアルゴリズム、または私は如何にして心配するのを止めて線形探索を愛するようになったか これはちょっとプログラマーといふ生物を買いかぶりすぎてると思います。 プログラマへの誤解 | pineapple blog プログラムを書かない人がプログラムを読んだときにする良くある間違いは,ああこんなプログラムなら自分にも書けそうだと思うことだ.プログラムは何百万とある可能性からたったひとつ(は言い過ぎにしてもわずかながら)の正しい方法を残したものであり,この捨てる能力こそがプログラマの実力だから. 少なくとも、プロ2グラマーの場合は。 その反証としてあげたいのが、線型探索(linear search)。漢字で書いたり英語で書いたりするとさぞ凝ったことをやってるように見えるけど、実は「見つかるまで頭から(あるいは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く