Java EE環境では基本的にスレッドの生成は許されていません。この制限はEJB仕様書に記述されており、ブループリントなど他のドキュメントにも記載されています。これらの制限はかなり古い時代に考えうる最大の制限を記述したものであり、「ファイルにアクセスしてはならない」など今となってはあまり現実的ではない記述も多くなっています。しかしながら、「スレッドを生成してはならない」というのは依然多くのコンテナに適用される現在も有効な制限であり、実際にスレッドの生成などを行うと誤動作するケースがあります。今回は、なぜこのスレッドの制限があるのか、現実的にどうすれば良いのか解説します。 コンテナは様々なものをスレッドに結びつけて管理しています。様々なものというのは例えばセキュリティ、トランザクション、データソースなどのコンテナリソースです。コードのほうがイメージしやすいでしょうから、以下に擬似コードを挙げ

コードクローンと品質について話題になっている。元ネタはこちら。 ソースコードの品質についても、みずほ証券は問題を指摘している。今回のバグがあったプログラム全体について、「ソースコードの著しい重複が見られるなど、エラーの潜在する率が極めて高い作り方をされており、品質が極めて低い」と主張。これに対して東証は「コードクローン（記述の重複）を含むプログラムは、含まないプログラムと比較して信頼性が高いことが定量的な研究で裏付けられている」と反論した。 ［論点3］どんな開発手法を適用すべきか | 日経 xTECH（クロステック） この「コードクローンを含むプログラムのほうが信頼性が高い」というのはどこからきた話題なのかという話。 僕が昔読んだ論文で似たような話があったなと思って探してみた。 コードクローンに基づくレガシーソフトウェアの品質の分析(PDF) 本論文では，20年以上前に開発され，拡張COB

自分の思考を整理する意味でも、件のアレについて考えたことを書いてみる。 変数に型がないということの利点について考える - サンプルコードによる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

AWK、Ada、Bash、Boo、C、C#、C++、Clojure、D、Erlang、Forth、Fortran、Go、Groovy、Haskell、Io、Java、JavaScript、Lisp、Lua、OCaml、Objective-C、PHP、Pascal、Perl、Pike、Prolog、Python、R、Ruby、Scala、Scheme、Smalltalk、Tcl でフィボナッチ数を求める処理時間を計測してみました。 フィボナッチ数は漸化式で求められます。 F0 = 0 F1 = 1 Fn+2 = Fn+1 + Fn フィボナッチ数を求めるアルゴリズムはいろいろありますが、今回は以下の再帰で求めるアルゴリズムで統一しました。 #include <stdio.h> int fib(int n) { if (n < 2) return n; return fib(n - 2) +

http://www.zusaar.com/event/438105 アプリケーションを作る英語 の著者の西野さんを交えて、クラス名とかメソッド名とか変数名とか命名で困っている課題を1つ以上持ち寄りみんなで一緒に検討する勉強会をしました。 「アプリケーションを作る英語」 電子書籍 http://tatsu-zine.com/books/english4app 紙 http://www.amazon.co.jp/gp/product/4844332848/ はじめに：西野さんからちょっとお話 The Art of Readable Code から第2章と第3章 第2章：名前に情報を詰め込むようにする どういう情報をつめこむか。 明確な言葉を選ぶ get は不明確らしい getPage(url) -> FetchPage(url) や DownloadPage(url) 特色のある（color

重要な事 これは僕の経験に基づくものであり、世の一般的な皆々様にはあてはまるかどうかは存じ上げません。 僕がマイノリティかマジョリティかどうかはよくって、こういう状況もあるというだけです。ツッコミは大歓迎ですが「それはコーナーケース過ぎる」というご意見には「そうかもしれませんね。」としか答えようがありません。 あと、基本的に@otfに向けた記事なので、言葉足りていない部分が多いと思いますが、彼とは職場が一緒でいろいろ共有できるので気にしていません。皆さんには言葉足りていなくってすいません。という謝りはすれども、反省はしない程度の感じ。 追記>> 言いたい事書いてなかった。 ただし、 設計書否定するなら、ここにある事くらい論破するくらいの人じゃないと一緒に仕事したくない。逆に、ここに同意するくらいなら設計書否定すんなよ。自分の仕事を呪え。 と思ってる。 <<追記 ではちょいちょいカテゴリ分け

この内容には私も全面的に賛成で、クラスやフィールド、メソッド、名前空間など、とにかく文字として表れる名前には、必ず、例外なく、正しく誤解のない命名を徹底することが非常に重要だ。 http://blog.livedoor.jp/lalha/archives/50261226.html 先のエントリは、danさん*1やlalhaさんにまで言及いただき大変光栄で、なにより多くの人に読んでもらえた。多謝。 一方で、自分で読み直すと「先のエントリ」は、いくぶん観念的でいまいちよく分からないところもあるかなと思った。というわけで、より実践に結びつきやすいように、「何に気をつければいいのか」「どういう考え方でコードを書けばいいのか」を書いてみる。 lalhaさんがエントリで強調したかったという (1) 適当に書いたコードは後でとても大きな被害をもたらす可能性が高い への包括的な対策であり、 (2) たく

3. 自己紹介 1992年～1997年 某ゲーム会社 プログラマ SFC,GB,PS1,N64のゲーム開発経験 1998年～現在 日本工学院八王子専門学校 @mozmoz1972 専任講師 プログラミング教育を中心に担当 twitterもfacebookも実名です。よかったらフォローしてください。

id:t-wada と話してた時に出てきた「プログラマの麻疹」 プログラマはみんなどうせかかるんだから早めにかかっておいた方が良い そしてかかっておくと治った後にはさらに良いコードが書けるようになるので 恐れずにかかりましょう 名前 症状 僕の状態 OO 厨 多分、現在一番キャリアが多い。一時期 AOP 厨になってしまった人も含むことがある。Smalltalk を神格化し始める かかり中 function 厨 最近増えてきた。マルチコア時代に最適というわかりやすい感染源ができたことも要因の一つ。LISP が世界を作っていると信じる 挫折中 三項演算子厨 どんどんネストした三項演算子を書いてしまう。気がつくと自分でもよくわからなくなってることもある 治療済み テスト厨 テストのためだけにコードを書いてしまう。プロダクトコードのきれいさよりもテストのしやすさを求めてしまう 治療中 lambda

Tython とはhttps://github.com/gongo/Tython/tree/development 肉体言語 Tython は、Kinect センサーを用いて、体の動きを利用してプログラムを入力する言語、というかインターフェースというかフレームワークというか。 図にするとこんな感じです。 Kinect を介して動きを検知 (Detector) 検知した動きによって、入力するソースコードを決定 (InputMethod) ソースコードを入力し終わったら、コンパイル (Compile) コンパイルしてできた命令列を実行 (VM) デモ 「Hello, World!」Tython を使って Hello, World! を出力してみました。 Hello, World! 出力まで 4分強 一回で成功しなかった 最終的に成功するまでの時間は 90分 一度でも文字入力失敗すると最初から

本のまとめに続いてプログラミングの勉強を始めて１年間のまとめとして感想とかどう勉強したのかとかそんな感じのまとめを書きたいと思います。 思いつくままにつらづらと書いて行くのでまとまりは全然ないと思いますがご了承をｗつまり殴り書き注意！ ちなみに買った本のまとめの記事はこちら↓ http://d.hatena.ne.jp/Akineko/20100220/1266682148 えーと、まず簡単にプログラミングの勉強を始めた理由ですが、今の職場ではデザインよりの仕事をしているわけなんですが基本は既にデザインしてあるものの加工が多くあまりデザインの仕事はしてない感じなんですね。それでもいろいろと勉強したりはするものも自分センスないなーと思ったり、たまに回ってくるデザインの仕事も理不尽な理由で締切明日だとかやっつけでやる仕事しかなかったりするので、段々と今の職場ではデザインの勉強しても意味がないな

1．一般的なコーディング規約に目を通し、エレガントなコードを知る エレガントなコードを書くためには、エレガントなコードを知らなければならい。その土台を築いているコーディング規約について、オープンソースではどのようなものが使われているのか理解しておこう。入社する予定の会社が採用している言語については必ず目を通しておこう。 PHP PEAR 標準コーディング規約 symfony CodingStandards Perl perlstyle Ruby クックパッド株式会社のRubyコーディング規準 Matzスタイル NaClで採用している規約 Python PEP 8 そして、あなたの身近にあるオープンソースのコードを実際に読んでみよう。この時点でコードの仕組みや設計が理解できなくても良い。コードがエレガントかどうか？を感じ取って欲しい。こう書いた方が、良いのではないか？など、考えてみよう。

Developers Summit 2011 セッション【17-B-1】に関するつぶやきをまとめました。 セッション資料 http://www.slideshare.net/t_wada/the-only-one-big-thing-every-programmer-should-know t-wadaさん関連のリンクは[続きを読む]からどうぞ。動画もたくさんあります。 セッションを紹介したタイムテーブル 続きを読む

最近、DDDの"意図の明白なインタフェース"というパターンの章を読みなおしています。このパターンが一環して主張していることは"名前が重要"ということです。その名前の重要性について、いろいろな文献からの引用を用いて考えてみたいと思います。 名前重要 "名前が重要"といえば、「プログラマが知るべき97のこと」で、まつもと ゆきひろ氏が 「名前重要」というタイトルで名前の重要性について語っています。 適切な名前をつけられると言うことは、その機能が正しく理解されて、設計されているということで、逆にふさわしい名前がつけられないということは、その機能が果たすべき役割を設計者自身も十分に理解できていないということではないでしょうか。 名前が設計と強く結び付いていることがわかる、深イイ言葉です。 名前の決定が難航すると「えぃ、面倒だから適当に名前を付けてしまえ」となりがちです。油断すると結構適当になるもん

このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 技術的負債の返済に役立つ 9 つの戦術 David Laribee MSDN Magazine の 2009 年 12 月号では、技術的負債に取り組むために、問題を特定して主張を展開するためのアドバイスを書きました。簡単に言えば、近い将来に問題になりそうな負債を特定することが重要だと信じています。コードベースのほとんど触れられない部分で、価値ある技術を確立しても、明日の生産性向上の実現には役立ちません。 また、負債返済の重要性について経営陣からお墨付きを得ることの重要性を理解し、同じ理由から手堅い主張を展開するための基本ツールを用意してください。 では、利息の高い技術的負債を返済するうえで役立つ可能性がある戦