コードのインデントはタブ?スペース? クォートはシングル?ダブル? 人気のあるコーディングルールの統計 -Popular Coding Convention
コードのインデントはタブ?スペース? クォートはシングル?ダブル? 人気のあるコーディングルールの統計 -Popular Coding Convention
※ Sun Microsystems の規約は Java 草創期から一応の標準という位置づけだったが、オブジェクト指向、及び、その開発環境の普及・発展によって、設計やコーディングにおいて、直接的に有用な知識や豊富な指針を含むような優れた規約や、ツールなどによる機械的な準拠チェックと連携する規約が普及してきている。 # 規約の重要性 標準としての規約を定義し、遵守することの重要性を以下に示す。 ソフトウェアメンテナンスにおける、可読性・保守性・拡張性の向上 問題を起こしやすい実装を未然に回避することによる、品質・生産性の向上 標準規約を通して得られる一般的な実装知識やノウハウ(=学習効果) # コーディングの心得 長いプログラムを記述すること(ステップ数)によって生産性が評価されたのは、過去の時代の出来事である。現在は、クラスやメソッドの役割が明確で、ロジックが読みやすく、保守性に優れたプロ
元記事: Awesome Java Awesome List in Qiita Awesome Ruby Awesome JavaScript Awesome Node.js Awesome Python Awesome Go Awesome Selenium Awesome Appium Bean マッピング Bean マッピングを容易にするフレームワーク dOOv - 型安全なドメインモデルの検証とマッピングのための API を提供します. アノテーション, コード生成, および型安全 DSL を使用して, Bean の検証とマッピングを迅速かつ簡単にします. Dozer - アノテーション, API または XML 設定を使用して, あるオブジェクトから別のオブジェクトへデータをコピーするマッパー. JMapper - 高速コードマッピングのためにバイトコード操作を使用. アノテーシ
Javaは決して悪い言語ではない。 C++からポインターの「*」やアロー演算子の「->」とかスコープ演算子の「::」とか気持ち悪いものを廃止・整理して、比較的読み易いシンタックスになったと思う。1995年当時から見れば、十分に出来の良い言語だったと思われる。 でも後発のC#でコーディングする機会が増えてきたら、如何にJavaが駄目(というか保守的な)言語かってのもまた同時に痛感してしまう。2005年リリースの2.0の時点で既にJavaをほぼ完全に上回っていると思うのに、その後ラムダ式・LINQ・拡張メソッドなど数多くの新機能が加わった現行C#とは最早比べるまでもないと思う。 以下は根拠。 ■注(2014年2月18日) このエントリーは殴り書きに等しい状態で放置してましたが、最近は思わぬところで読まれ始めたりしたので、ちょっと加筆修正しました。 ①そもそも純粋なオブジェクト指向言語ではない。
Spring MVCのコントローラのメソッドで使える戻り値にどんなものがあるか、どういう使い方ができるかをざっくりまとめてみた。 @Controllerと@RestControllerの違い 先に@Controllerと@RestControllerの違いを説明しておく。 Spring MVC ではコントローラクラスにアノテーションで@Controllerまたは@RestControllerを付ける。 @Controllerは主にWebページ用のコントローラで使用する。 Webページ用コントローラはJSPやテンプレートエンジンのViewに遷移してレスポンスのHTMLを生成するので、基本的にメソッドの戻り値はViewの遷移先を指定するのに使用する。 @RestControllerはJsonやXML等を返すWebAPI用のコントローラで使用する。 こちらはViewに遷移しないのでメソッドの戻り
PHPでアプリケーションを作ってゆく。大きくなると、classが増えてゆく。classが増えてゆき、constructorの引数が増えてゆく。classをnewする順番が決まってゆき、それに従はねばならない。同じインスタンスがあちこちで必要になる。DI (Dependency Injection, IoC) の出番だ。 はじめはPimpleを使うてゐたが面倒になり、既存のDIライブラリは複雑な手続きが必要で、面倒だったので自分で作った。Ranyuen/Diだ。 cf. Ranyuen/Di https://github.com/Ranyuen/Di cf. PHPで簡単に華麗にDIとAOPをキメる http://c4se.hatenablog.com/entry/2014/12/11/013136 こんなに苦労して作ったDIコンテナだが、Rubyでは20行で書けるとMatzも言ってゐる。
あけましておめでとうございます。 大晦日は実家でプログレ聞きながらコード書いてました。 今さらながら Heldon の Stand by とか聞いてたんですが、Tangerine Dream を思わせるミニマルなシンセサイザーの反復と、リシャール・ピナスによるロバート・フリップばりの暴力的なギターソロが絡みあっており、大変良いですね。 作ったもの また説明長くなりそうなので、はじめに作ったものの紹介です。 dee dee-rails この Dee というのが DI コンテナの本体です。 名前は Ozzy Osbourne ソロ 1st Blizzard of Ozz におけるランディ・ローズのギター曲からです。 50 秒と短く、メタルアルバムの中にあってクラシック風の静かなギター曲ですが、同時にアルバムから欠かせない存在感を放つ名曲です。 何が言いたいかというと、Dee はコンパクトな実装
import java.util.Set; import java.util.HashSet; public class ConcreteSubject implements Subject { private Set<Observer> observers; public enum Status { NORMAL, ERROR } private Status status; public void setStatus(Status status) { this.status = status; notifyObservers(); // status フィールドを更新したら Observer に通知するようにしておきます } public String getStatus() { return status.toString(); } public ConcreteSubject()
はじめに Java API を巡って Oracle と Google の訴訟が続いています。世間の論調を見ていると、「Oracle 対 Google」の構図を「プロプライエタリ対オープンソース」と位置付け、あたかも Google が正義の味方であるかのように扱っていますが、この件に関しては、私は逆の立場です。むしろ、「Google けしからん」と思っています。私がそう思う理由をここに書きます。 Java の互換性 Android が登場するずっと前から、業界の皆は、JCP (Java Community Process) に則り、協議の上 Java API の仕様を決めてきました。仕様を策定する際には、RI (Reference Implementation) (リファレンス実装) と TCK (Technology Compatibility Kit) (テスト群) も同時に用意します。
OutOfMemoryError (以下 OOME)が起こったときにお手上げ状態にならないためにも、 Java のメモリ管理の仕組みとか、 OOME が起こったときの調査方法とかを調べる。 環境 OS Windows 7 > java -version java version "1.8.0_74" Java(TM) SE Runtime Environment (build 1.8.0_74-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode) Java 8 で、 Oracle の JVM を前提とした話です。 Java のメモリ管理 これを知っておかないと、 OOME が起こっても、メモリ内で何が起こっていて、どこを調査すべきで、どのように対処したらいいのかが判断できない。 なので、まずは、そもそも J
ちょーっと古い記事なのだけれど(実際今どきだったらOAuthとかだよね)、Spring Source社のブログ記事に“Spring Security in Google App Engine”というのがあって、気になってはいたけれどブックマークでとっておいてそのままになっていた。 今回はその記事を訳出してみた。Google社やSpring Source社のドキュメントは、他のプロジェクトとくらべて、使用する単語や時制、構文に気をつけていて、非常に読みやすい。それでもまぁ訳しておいた方がのちのち参照しやすいのもたしか。その程度の意図で。 原典は、“Spring Security in Google App Engine”(SpringSource Blog)。ルーク・テイラー氏の投稿です。 * * * Google App EngineでSpring Securityを使う Spring S
変数の展開 {{name}}のように2つのブレースで囲ったタグは、nameという名前のキーの値でおきかえられます。 対応するキーが見つからなかった場合はデフォルトでは空文字になります。 Mustache.render("Hello, {{world}}!", world: "mustache") # => "Hello, mustache!" Mustache.render("{{no_such_key}}") # => ""
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に(アーキテクトではなく)プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
色んなシステムに携わっていると、様々なJavaのクラス名に遭遇する。 ○○Beanとか ○○DTOとか ○○Entityとか ○○VOとか ○○Form。 ここらへんって 「MVCのModelのデータ部分にあたるって意味で同じだし」 とか 「ゲッター/セッターがあるクラスで意味的に一緒じゃない?なんで色々名前つけてんの?」 って思いませんか? ってことで、今回はそれぞれの定義を改めて考えてみようと思う。 とりあえずはそれぞれの意味から ・Bean 総称はBean。あえて言うならJavaBeansの略。 Javaの初心者でも知っている。 あまりに有名すぎるが、Oracleのサイトのガイドを見ながらパクってまとめてみた。 ・Sun Microsystems社のJavaBeans仕様に準拠した再使用可能なソフトウェア・コンポーネント。 ・最低限、クラスにはプロパティが必要。 ・プロパティはメソッ
java-for-android-app.markdown Android アプリ開発のための Java 入門 MEMO declaration は 「宣言」 と訳しているが、「定義」 の方が適しているような気がしなくもない。 「インスタンス」 と 「オブジェクト」 という言葉を使うことがあるが、本文書中ではどちらも同じ意味で使用している。 「String オブジェクト」 という表現は、「String クラスのインスタンス」 を意味している。 (Java に限らず一般的な表現だと思う。) はじめに この文書は Android アプリ開発をしようと思うプログラマのための Java の入門文書である。 まともに Android アプリを書くために最低限必要だと思われる知識をひととおり記述している。 また、C の流れをくむ文法であるため、C やその類似言語を知っている場合には既知であろうと考えら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く