はてなブックマーク

前回、思い出話として nagise.hatenablog.jp を書いたのだが、その中でネットスラングの「マウンティング」について、初出が nagise.hatenablog.jp であるということを書いた。この記事は 2008年9月20日で、以下の用例が見られる。 そんなテクニックはいかに相手のニホンザルを押さえ込んでマウンティングを成功させるかというテクニックでしかない。そんなことをやったところで疑問はなんら解決しないし、誤った意見をこうした手法で押し通しでもした日には、後で大きな惨劇が起こりかねない。勝った負けたなどと言っていても議論は進展しないのである。 これは明確なエビデンスで、この時点でこのような用例があった、というのはひとつの道標となる。 ここで、「筆者が発案したというのは本当か？」「より古い用例はないか？」という疑問が生じることだろう。では、そうした疑問が生じたときにどのよ

思い出話。今回はポエムと思って気楽に読んで欲しい。 インターネットの世界には情報が溢れかえっていて、やれ、なんやらが炎上しただのそんなニュースもありふれていて特に興味もわかない。ふーん、ゲームの歴史について書いた本が噓八百で炎上してんのか、まあ適当なことを書きならべる人がトンデモ本を書きましたなんてのは昔から枚挙に暇がない話だ。 その程度に思っていたのだけども、先日ようやくそのゲームの歴史なる本を書いた人が岩崎夏海氏であったことを認識した。 僕の古い古い記憶が、この人物を知っているぞ、と呼び掛けてきた。そう、あれは2008年のことだった。今から15年も前のことになるのか。 岩崎氏ははてなダイアリー（はてなブログの前身となるブログサービス）ではちょっとした有名人だった。彼はそのblogのタイトルから、ハックルさんと呼ばれていた。よく炎上していた人だったと記憶している。というのも、ハックル氏の

リファクタリングには価値がある、とプログラマは確信していることだろう。しかし、その価値が何であるか？を上手く説明できるかというと難しいのではないだろうか。本稿ではリファクタリングの価値をテーマに筆者の説を提示していく。 品質特性の側面から 補足 品質特性の相互作用 リファクタリングの価値 障害対応 機能追加 システムの製品寿命 まとめ 品質特性の側面から ソフトウェアの品質特性としてISO/IEC 9126が一般的に用いられている。大きく6つの特性と細分化された副特性からなり、ISO/IEC 9126 - Wikipedia から引用すると 機能性（functionality） - 機能とその特性に影響する特性群 信頼性（reliability） - ある状況がある時間続いたときにソフトウェアがどの程度機能するかに影響する特性群 使用性（usability） - 利用するのにかかる手間、個

開発室の雑談。営業側のマネージャが言うには 「今のプロジェクトで自動テストの導入を試みている話をしたら、XXXさんのところでも過去にいくつか導入を試みたけどもみんな上手くいかなかったって話になって」 なるほど？ まあ確かに自動テストはシステム開発にとって魅惑の技法ではあるものの、では導入がうまくいっているか？　というと普及率は低いと言わざるを得ない。私がお手伝いしたプロジェクトでは、元請け側から自動テストをやるお達しが来たわけだが、紆余曲折あって掛け声倒れのような状態になってしまった。 ビジネス書の煽りタイトルのような本件だが、古式ゆかしき受注生産の業務システム開発プロジェクトに自動テストを導入しようとして失敗する事例を聞いたので、僕なりに分析して見出した要素を挙げておこうと思う。 V字モデル ソフトウェア開発の手法としてV字モデルというものがある。 オーダーメイドでシステムを作るにあたっ

閏年（うるうどし）の話題。 Twitterで見かけた話題で「西暦1年は閏年かどうかぱっとわからん人おる？」という些か煽り気味のツイートを見かけたのだけども、反射的に「閏年じゃないに決まってるじゃん」とぱっと答えてしまわないだろうか。本当にそうだろうか？　そう単純な話なのだろうか？ プログラミングを学んでカレンダーを扱うことを学ぶ際に置閏法についても簡単に触れられることがある。置閏法というのは閏年や閏月（太陰暦では1年が13ヵ月になるケースがあり追加の月を閏月と呼ぶ）をどのようなルールで挿入するかという話で、まさにアルゴリズムであるからプログラミングの話題と相性がいい。 置閏法 現代の西暦の置閏法（ちじゅんほう）は 西暦を 400 で割り切れる年は閏年 上記以外で西暦を 100 で割り切れる年は平年 上記以外で西暦を 4 で割り切れる年は閏年 上記以外は平年 といった手続きで閏年（つまり2月

Spring boot では Webシステムをmain起動のスタンドアロンのJavaプログラムのように起動して試せる点が便利である。ところでこうしたサーバーサイドのWeb APIを作るようなケースで、Reactのようなコンパイルを伴うWebクライアントと連携して動作するようなものを開発するとき、どのようなプロジェクトのディレクトリ構成でどのようなビルド、どのような実行をすると便利にやれるのだろうか？ IDEの有償プラグインがこうした開発を統合してくれるのかもしれないが（試用して回ったわけではないのでよくわからない）ここではギョームで普通に用いられているEclpise IDE と Visual Studio Codeの組み合わせで考えてみたい。(本稿ではIDEは主題ではないので、任意のIDEで検討してもらいたい) Spring の フォルダ SpringのQuick Start に従い、デモ

セミコロンレスJava (Semicolonless Java)というのは Java でセミコロンを使わずにコードを書くというチャレンジである。ネタであり言語の構文を駆使して行うプログラミングパズルの類の遊びである。（ときどき本気にしてその有用性について聞いてくる人がいるので、この冗談がどういう冗談でどう面白いのかの解説のような無粋なことを書いている） ところで、セミコロンを使わずともJavaはチューリング完全なのであろうか？ 証明方法 チューリング完全であるという証明は、すでにチューリング完全であることが知られている体系を該当環境で実装することで行うのが簡単な方法論である。 Brainf*ck といったチューリング完全な簡易プログラミング言語を実装するとか、チューリング完全であることが知られているライフゲームを実装するとかが考えられる。 今回は、ライフゲームの1次元版とも言える、1次元セ

Javaのクラス名の表現方法で 「全部同じじゃないですか」 「ちがいますよーーっ」 「これだからしろうとはダメだ！もっとよく見ろ！」 をやっている🤔— なぎせ ゆうき (@nagise) April 14, 2020 Java言語を扱っていると何通りかのクラス名の表記法を見ることがある nagise.sample.Hoge.Piyo nagise.sample.Hoge$Piyo nagise/sample/Hoge$Piyo [Lnagise.sample.Hoge.Piyo これらの違いは何なのか。 Javaのクラス名関連の専門用語を調べ直してみた。 用語 日本語 概要 Identifier 識別子 識別に用いるもの全般を指した抽象度の高い表現 Class Name クラス名 一般に言うクラス名。比較的曖昧な表現。文脈によってはInterfaceも含む。ネストしたクラス、内部クラスの

Twitterで @RayStark77 氏に教えてもらった方法 var v = new java.util.Vector<String>(); java.util.Enumeration<String> e = v.elements(); for (String s : (Iterable<String>)e::asIterator) { // ... } Enumeration#asIterator() がJava9からのメソッドなので Java9 以降で利用可能。 なるほどなー、これ実際にはそのままダイレクトには書けないですけど、明示的にキャストしてあげれば書けますね for (String name : (Iterable<String>) request.getHeaderNames()::asIterator) { ... }https://t.co/NTL5iUFzL9— が

Java10以降、Java SEのリリースサイクルを6カ月単位とすることが発表されてしばらく経ち、また、予告通りJava11からいよいよJavaのサポート体制も変更となった。 本稿ではJavaを使い続けるリスク、あるいはほかの言語ランタイムを使い続けるリスクについて検討してみたい。プログラム言語は用途に応じて様々なものが使い分けられている。特に本稿では選択肢が多く、またJavaのシェアも高いサーバーサイドのWebシステムという戦場で検討してみたい。 「Javaリスク」という単語、語呂が良い— なぎせ ゆうき (@nagise) 2018年10月11日 pic.twitter.com/tBGvupxtJ4— rf (@rf0444) 2018年10月11日 ランタイムの有償化リスク 無償で提供されていたプログラム言語のランタイムが、突如有償化するリスクをまず考えてみよう。この点で、Javaは

Javaのジェネリクスは一般に配列と混ぜてはいけないとされるが、混ぜて用いた場合に何が問題となるのか。 歴史的な問題 Javaが1995年に登場した当時、Javaに配列はあったがジェネリクスはなかった。 ジェネリクスを含む型システムの理論的な整備は、1990年代から2000年代にかけてのJavaのバージョンアップの時期に並行して行われていた。これは1995年当初のJavaになぜより良いジェネリクスを搭載した形でリリースされなかったのか？ということにひとつの答えを示すだろう。つまり、1995年当時にはジェネリクス（Java5に搭載されたような変性を含むもの）は未来の技術であって、まだ理論的に固まっていないものであった、というわけだ。 Java言語仕様にも記述されているが Historically, wildcards are a direct descendant of the work b

Java Generics Hell アドベントカレンダー 6日目。 前回(5日目) パラメタライズドタイプ 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 ここまで話の簡単のためにいろいろ端折って書いてきているのだが、徐々に詳細を書かねばなるまい。同時に取り漏らしも回収して行かなければならない。 スコープ Javaのジェネリクスの型変数には2種類のスコープがある。 メソッドの範囲で有効な型変数 クラスのインスタンスの範囲で有効な型変数 List<String>といった例でバインドされているのは後者のクラスのインスタンスを範囲としたもの。よく目にするのがこちらだろう。 前者のメソッドの範囲の型変数は入門書ではあまり取り上げられていないかもしれない。しかし、話としてはメソッドスコープの方が単純なのできっちりやるならメソッドスコープから導入したほうがわかりやすいのではない

Java Generics Hell アドベントカレンダー 3日目。 1日目 Java Generics Hell 序章 2日目 オブジェクト指向 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 前回はオブジェクト指向の中核が（継承に限定せず幅広い意味での）ポリモーフィズムではないか、という話であった。 今回はそれらをコンパイル、つまり静的型チェックによって安全を目指す「型システム」について。その中でも「リスコフの置換原則」について取り上げる。 ヒューマンエラー ボイラープレートと呼ばれるプログラミングの定型句ぐらいであれば機械による自動生成もありうるが、プログラミングというのは現代では基本的に人力の作業である。 人間は簡単な問題であってもときおり誤りをおかす。一桁の足し算のようなドリルでも、延々とやらせると時折ミスが混ざる。「簡単だからミスするはずがない」「ミスをす

Java Generics Hell アドベントカレンダー 2日目。 1日目 Java Generics Hell 序章 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 前回は与太話だった。ジェネリクスの話をする前にOOP（オブジェクト指向プログラミング）について整理しておかねばならない。 オブジェクト指向とは オブジェクト指向が何かという点についてはなかなか難しい。 Smalltalkを作ったアラン・ケイが「オブジェクト指向」という言葉を初めて用いたといわれるが、この「オブジェクト指向」はJava言語の教育の過程で一般に教えられる「オブジェクト指向」とはかなりイメージが違う。 アラン・ケイが「オブジェクト指向」という言葉を創った当初は、Smalltalk システムが体現した「パーソナルコンピューティングに関わる全てを『オブジェクト』とそれらの間で交わされる『メッセー

気合が続くか分からない Java Generics Hell アドベントカレンダー 1日目。 読者の推奨スキルとしてはOCJP Silverぐらいを想定している。 導入 JavaのジェネリクスはJavaが設計された当初(Javaは1995年に発表されている)から検討はされてはいたものの、実装が追いつかず、導入はJava5(2004年)を待つこととなった。後方互換の都合からいろいろと不便な部分もある。Javaに限らず、ある程度、歴史の長いプログラミング言語は、改定の都合からいろいろと不都合な部分が生じるものである。後方互換性を犠牲にして一新すれば言語仕様もさっぱりするが、非互換の壁でバージョンアップできないという闇を抱えたりとそれはそれで大変だ。 後方互換、つまり、より新しいバージョンは、昔作ったモノも動かせる、ということを前提にした場合、プログラミング言語の仕様というのはどんどん肥大してい

聞くところJava本格入門（通称アクロ本）の評判がすこぶる良いようだ。1995年にJavaが発表されてから随分と経つ。Javaのメジャーバージョンも8を数え、9がリリースされようとしている。1990年代にはこの新しい言語についてたくさんの技術書が発行されたが、これほどバージョンに差異があると現代では役に立たない。現代のバージョンに即した質の良い入門書が発行されることは喜ばしいことだと思う。 しかしながら、このJava本格入門も3-4-2 ジェネリクス(総称型)にていささか不適切な用語の使用方法がされているようだ。本項では改善提案を行い、また関連する用語の解説を行いたい。 発端 Java本格入門の101p、何となく違和感… 『GenericStack<E>のように、パラメータ化された型として定義』 ここパラメータ化された型ではなく総称型ではなかろうか？— なめりかん(仮) (@heignam

Javaのジェネリクスでしばしば話題に上がる「イレイジャ」について整理しておきたい。 イレイジャについては僕もいろいろと誤解しており、過去に誤った発言をしている。本エントリはその贖罪として書かれたものである。 「イレイジャ」という方式についてはネガティブな誤解が広まっていると思う。「イレイジャ方式」が問題の根ではない事象について、それを「イレイジャのせい」であると誤って理解することはエンジニアとしてはマイナスである。 しばしばイレイジャのせいとされる事象にnew T()できないという論点があるが、これはJavaのジェネリクスがC#でいうnew制約(型変数の制約としてデフォルトコンストラクタを持つことを要求する機能)を持たないことに起因する問題である。 そのため、この点についてJavaの言語仕様に改善を求めるのであれば、new制約を導入せよという現実的な要求とするべきである。 イレイジャ方式

入門書ではあまりとりあげられない部分を解説するコンセプトの「入門書が教えてくれないJava」シリーズの第二弾。前回は変数についてだった。今回はそのスコープについて取り上げたい。 スコープとは スコープとは大雑把に言えば変数やメソッドなどが見える範囲のことを指す。 Javaの変数のスコープで一番簡単なのはローカル変数で、これは{から}まで（これをブロックという）の中で、宣言した位置より後ろで参照することができる。 public void main(String[] args) { int i1 = 0; // i1はここからmainの}までの間で参照できる if (true) { int i2 = 0; // i2はこのifの}までの間で参照できる } // i2はifの}を過ぎると参照できなくなる i2 = 1; // ← コンパイルエラー } なお、Javaの言語仕様では{}のブロックは

春なのでJava入門的なことを書こうと思い立ったので、入門書ではあまりとりあげられない部分を解説するコンセプトの入門記事を書いてみようと思う。(←ひねくれ者) 対象読者としては、Java言語の基礎を学んだがもう一歩踏み込んだ話が知りたいぐらいの初学者〜中級者を想定してる。上級者の方は記述に誤りがないかチェックしていただければ幸いだが、説明を簡単にするためにいろいろ端折っている点はご理解いただきたい。 今回は変数・フィールド編とした。筆者のやる気次第だがこのシリーズでいくつか書こうと考えている。 入門書が教えてくれないJava 変数編 (本稿) 入門書が教えてくれないJava スコープ編 - プログラマーの脳みそ 初期値を指定しない変数宣言 変数宣言に際して初期値を設定しないことができる。 int i; この場合、このint i;がフィールドであるか、ローカル変数であるかで扱いが変わってくる

すいません。完成まで漕ぎ着けれませんでした。 本稿はセミコロンレスJava Advent Calendar 2015の25日目です。 セミコロンレスJavaについて簡単に説明すると、Javaの構文上のセミコロンを用いないで標準APIの範囲でプログラミングをするにはどうしたら良いかを考える衒学的な娯楽です。 アプローチ Oracle版のJDK (Java Development Kit)に標準で入っているcom.sun.tools.javac.main.JavaCompilerを使います。JDKをインストールするとtools.jarというのがJavaのインストールフォルダ以下に展開されていると思います。Windowsだと C:\Program Files\Java\jdk1.8.0\lib あたりですね。 このtools.jarに含まれているJavaCompilerを使うとJavaのソースコ

java.util.concurrent.FutureTaskのコンストラクタの定義が public FutureTask(Callable callable) http://docs.oracle.com/javase/jp/8/docs/api/java/util/concurrent/FutureTask.html#FutureTask-java.util.concurrent.Callable- とCallable<V>となっていてCallable<? extends V>じゃないのが不便だという話題。 これにより Thread Safe な汎用オブジェクトCache - がくぞーのメモ のキャッシュ機構のコンストラクタをCallable<? extends V>に出来ないのだとがくぞさん(@gakuzzzz)が嘆いていたので、小手先のテクニックで対応したのが以下のコード。 imp

メソッド内部で任意の型のインスタンスを生成してオブジェクトを返す場合 public static <T> T hoge(Class<T> clazz) { try { return clazz.newInstance(); } catch (ReflectiveOperationException e) { throw new RuntimeException(e); } } といったようにjava.lang.Classを引数にとり、リフレクションでインスタンス生成するというのが常道だった。 対象となるClassにはデフォルトコンストラクタ（引数なしのコンストラクタ）が存在することが前提となる。 呼び出し側は以下のように 型名.class を渡す。 String string = hoge(String.class); これがstataicメソッドではなく、thisオブジェクトが継承による

ある型のインスタンスを受け取り、Listにして返すメソッドを考えよう。 public static <T> List<T> wrap(T value) { List<T> list = new ArrayList<T>(); list.add(value); return list; } このとき、型変数はメソッドのIn / Outで型の関連を表現できさえすればよいので、型変数のスコープはメソッドスコープでよい。 例示のために継承階層をもったクラスA,B,Cを用意しておく。 public class A {} public class B extends A {} public class C extends B {} ではこのwrapメソッドの呼び出し側のコードがどうなるかを見てみよう。 public class Sample { public static void main(Stri

Javaのジェネリクスについて考察するのに丁度良いテーマを見つけたので忘れないうちに書いておく。 Map を Mapに変換するメソッドを作るという話題。 public static <K,V> Map<V,K> swap1(Map<K,V> origin) { // 略 } 単にMapからMapに変換するなら上記のようなメソッドシグネチャでよい。 ここで、Mapの具象型を帰すようにしたいとする。 public static <K,V, R extends Map<V,K>, P extends Map<K,V>> R swap2(P origin, Supplier<R> supplier) { // 略 } まず単純に引数のMapと戻り値のMapを型変数PとRにとるようにしてみよう。 JavaのジェネリクスはC#のようなnew制約をつけれないのでメソッド内部でインスタンス生成する場合はj

Javaのgetter/setterのお話。 僕は当時を語るには若すぎるのだけど、過去を振り返って書いてみる。当時を知る人は誤りがあれば指摘してほしいし、情報があればコメントなりトラックバックなりして欲しい。前世紀の話というのは今となっては探すことがなかなか難しくなりつつある。 「privateな変数にpublicなアクセサを定義する」？ - ネットの海の片隅で getter/setterとは何か Javaのオブジェクトにフィールドがあったとして、そのフィールドに値を設定するメソッドがsetter(せったー)、そのフィールドの値を取得するメソッドがgetter(げったー)と呼ばれる。慣習としてsetterはsetXXX(int value)といった様にsetから始まる名前をつけ、引数はひとつ。戻り値はvoid型。getterはgetXXX()といった様にgetから始まる名前をつけ、引数はな

今回はJavaの型システムのコンストラクタについて考えてみたい。 Javaの型システム、あるいはJavaのオブジェクト指向において、コンストラクタという存在は特殊な存在だ。 コンストラクタ内からはそのクラスのインスタンスフィールドにアクセスできる。これは通常のインスタンスメソッドと同等のスコープであってstaticメソッドのそれとは異なる。しかし、コンストラクタを呼び出すにあたってはインスタンスのメソッドという体ではなく、staticメソッドのように（インスタンスではなく）クラスに属するものとして呼び出すことになる。（もっともnewという専用のキーワードを用いるのでそうは見えないかもしれないが） クラスやinterface、つまりJavaの「型」によるポリモフィズムの世界を考えるとき、コンストラクタはのけものである。継承関係を持つクラスであってもコンストラクタは継承されないし、オーバーライ

http://aoking.hatenablog.jp/entry/20100427/1272326219での主張は public class Sample { public static void main(String[] args) { List<Integer> list = getList(); System.out.println(list); } public static <T> List<T> getList() { List<T> list = new ArrayList<T>(); list.add((T)"string"); list.add((T)Integer.valueOf(1)); list.add((T)new Object()); return list; } } といったように型変数Tにキャストを行った場合に「このコードはコンパイルエラーは発生しない。