Swiftのエラーハンドリングはなぜ最先端なのか - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Java Tips: かしこいロック
単純なロックの問題点 Java にはマルチスレッドプログラミングにおける一般的な排他制御を記述するのに適した synchronized ブロック、synchronized メソッドという構文があり、保護したいデータにアクセスする全てのコードをこれらの構文を使って同期化すれば、排他制御は簡単に実現できる。しかし、この方法には問題もある。例えば電子掲示板システムのログデータにこの方法を適用することを考えてみよう。 電子掲示板に対するアクセスを全て同期化するということは、一度に一人のユーザしかログにアクセスできないということである。なんらかの理由(サーバ・クライアント間の回線速度やクライアントの処理速度の低下など)でログの読み込みに時間がかかっているユーザが一人れば、サーバ側の計算機資源にいくら余裕があっても、その間は他の大勢のユーザは掲示板にアクセスできない。すなわち計算機資源の利用効率が著し
JVMはそんなに重くない | POSTD
Clojureに反対する大きな理由がJVMです。この役立たずは重いですからね。 これは、数週間前に ZA Tech のSlackで見た投稿です。休暇中にClojureの話題を何件か見たのですが、投稿者はJVMについても繰り返し言及していました。 私はこの投稿について Slack上で少しつぶやいていました が、もっと広く理解され議論されるように、本稿を書くことを決めました。 背景 以前は、私もJVMは重いと思っていました。2000年代の初めにJVMとPHPと比べていた頃の話です。当時は、.NETやColdFusionなど、別の重い製品が他にもありました。また、PerlやPythonという軽めの製品もありましたが、私はWindowsを使っていたのでActivePerlやActivePythonはやはり少し重めでした。 私が初めてJVMに対する“恐れ”を克服したのは、小規模な製品アプリを、JRu
LL から Java に移行した人がはまりがちなこと - tokuhirom's blog
LL から Java に移行した人がはまりがちなこと こんにちは｡Java 初心者です｡ Java 初心者､得に LL から Java に来た人にありがちな問題について社内向けに書いたものをオープンアンドシェアさせていただきます｡ 前提として､我々は Java 8 でガンガン攻めているということをご承知おきください｡ また､自分がこの数ヶ月で｢うわー｡こうしとくべきだったのかー｣と気づいたやつをドヤ顔で語っているということにもご注意ください｡ 【追記】 対象は中規模 B2C の場合です(中規模というのは facebook より小さいという程度の意味です) 例外を握りつぶさないようにしよう Eclipse が生成する以下のようなコードをそのまま残しているケース｡ これは言うまでもなく良くないですね｡デバッグが困難になります｡ try { } catch (IOException e) { e
リッチなドメインモデル 名前探し
ドメイン駆動設計で、モデリングをどうやっているか、それをどう実装に結びつけているかの事例紹介。 RDRA+ICONXをベースに、より機敏なやり方への挑戦。実践的なオブジェクト指向設計。
ブール値を返すメンバー関数の命名規則
関数の名前の付け方は人それぞれですが、使う単語が同じなら、関数の名前はほぼ同じものになると思います。例えば、サイズをセットする関数の名前を、「set」と「size」という単語を使って考えると、ほぼ全員が「SetSize」と答えるでしょう。「SizeSet」「SizeToSet」「SizeSetted」「SettingSize」といった名前を考える人は、ほとんどいないと思います。 ところが、真か偽かのブール値を返す関数の名前は、混乱することが多いようです。 ここでは、Java言語で採用されている命名規則と、その解釈の仕方を紹介します。 関数名が混乱する例 ブール値を返す関数では、「Is○○」という名前を良く見かけます。例えば、中身が空っぽかどうか、の判定をする関数には、IsEmptyという名前が良く使われます。MFCのCStringクラスや、JavaのListインターフェースなどにも、IsE
BDDの導入 - Dan North - Digital Romanticism
この記事はDan North氏の記事「Introducing BDD」を氏の許可を得て翻訳した公式版（"the official translation"）です。（原文公開日：2006年9月20日） 私は１つ問題を抱えていました。様々な環境にあるプロジェクトでテスト駆動開発（TDD）のようなアジャイルのプラクティスを用いたり、あるいは教えていると、いつも同じような混乱や誤解に行き当たったのです。プログラマが知りたいと望むのは、どこから始めれば良いのか、何をテストすれば良いのか、何をテストする必要がないのか、１つのものに対してどの程度テストすれば良いのか、テストをなんと呼べば良いのか、テストが失敗した理由をどう理解すれば良いのか、ということでした。 TDDに深く入り込むほどに、自分の道程が、言われたことをコツコツやれば徐々に上達するようなものではなく、むしろ行き詰まりの連続であると感じました
Javaプログラマが知るべき9のこと - @katzchang.contexts
はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下： 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ
Javaの未来、RubyとJavaScriptの台頭
オープンソースによるJavaのフレームワークである「Seasar2」の作者にして、著名なJavaプログラマのひとりとして知られるひがやすを氏が「Javaに未来はないかなと。（略）個人的には少しずつJavaから離れていっています。」という発言をパネルディスカッションでしました。昨日の記事で紹介したので、お読みになった方も多いと思います。 Javaはエンタープライズ分野に限られるようになるか Javaの将来像について、米調査会社ForresterのアナリストJohn Rymer氏とJeffrey Hammond氏が、同社のブログに「The Future Of Java」というエントリを先週末ポストしています。 彼らは、オラクルの戦略が次のようにJavaのエコシステムを変化させるだろうとしています。 Oracle’s strategy for Java will change the Java
RubyのMVM APIの共同研究が始まる
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
5年後に後悔しないJavaプログラムの書き方 - L'eclat des jours(2009-07-02)
_ 5年後に後悔しないJavaプログラムの書き方 ここ数日、死ぬほど後悔しまくっているので、あらためて（というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが）後悔しないための書き方をいくつか紹介する。 とにかく、ファクトリメソッドパターンを使うこと。 これは本当に重要。しかも簡単でありながら効果は絶大。 だめな例。 public class FooBar { private Connection conn; ... protected void setup() { ... conn = DriverManager.getConnection(url); ... } urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても（というか、Connectionならそういう方法もあり得るが、そうはいかな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
「作者の気持ち」以前に、揚げ足とる相手の最新状況くらい調べろ
Let'sプログラミング
Java コーディング規約(2004)
Android入門