タグ

ブックマーク / nowokay.hatenablog.com (25)

  • 空の配列に対するmaxは何を返すか - きしだのHatena

    ちょっと前に「配列中のすべての要素が条件を満たすかどうか判別する関数で、空の配列はTrueを返すべきかFalseを返すべきか」のような話が話題になってました。 まあこれは「Trueを返す」が答えなわけですが、では「配列中の最大値を返す関数で空の配列の場合は何を返すか」が気になりました。 「配列中のすべての要素が条件を満たすかどうか判別する関数」について言えば、簡単に言えばこんな感じ。 まず、配列のすべての要素が偶数であるかどうか判別する関数を考えます。 void main() { int[] data = { 23, 44, 12, 98, 5 }; System.out.println(allEven(data)); } boolean allEven(int[] data) { for (int n : data) { if (n % 2 != 0) return false; } r

    空の配列に対するmaxは何を返すか - きしだのHatena
    UDONCHAN
    UDONCHAN 2023/06/07
  • さよなら「あなたとJAVA」 - きしだのHatena

    みんなから愛された「あなたとJAVA」の役割が終わったようです。 「Java」で検索するとjava.comのサイトがひっかかるのですが、このサイトは古いまま放置されていて、Javaの学習を始める人にとっての罠になっていました。 https://www.java.com/ja/ 「あなたとJAVA」というキャッチコピーの脱力感と、「ダウンロー」で改行され「ド」だけが目立ってしまう間のヌケかたから大人気のサイトでしたが、かっこいいものではない・・・ もともとはJAVA+YOUで、2008年JavaOneのキャッチコピーでした。これは大文字だけのデザインだからよかったのだけど、日語訳するときJAVAだけ大文字で残ってしまい「JAVAではなくJava」の説得力をなくさせてくれていました。 それに、ほとんどの人がJavaのプログラミングの勉強をしようとして「Java」を検索するのにJREの配布サイ

    さよなら「あなたとJAVA」 - きしだのHatena
    UDONCHAN
    UDONCHAN 2022/05/25
    いい話
  • Java9、10でStringの+=に副作用があるバグ - きしだのHatena

    Java 9、10でStringの+=にバグがあるということがStack OverFlowで報告されていました。 Why does array[idx++]+="a" increase idx once in Java 8 but twice in Java 9 and 10? - Stack Overflow どういうバグかというと「s[i++] += i + ""」のようなコードが正しく動かないというものです。 次のコードを実行してみます。 public class PlusEqual { public static void main(String[] args) { System.out.print(System.getProperty("java.version")); String[] s = {"aa", "bb"}; int i = 0; s[i++] += i + "";

    Java9、10でStringの+=に副作用があるバグ - きしだのHatena
    UDONCHAN
    UDONCHAN 2018/06/15
    おもしろいけれど致命的すぎる…
  • Java10のvarをどう使うか - きしだのHatena

    Java 10でvarが追加されました。が、いろいろ使い方は悩ましい気がします。 いろいろ議論をしたので、そこで考えたことをまとめておきます。 JShellでは読むことを考えなくていいのでガンガン使いましょう。 あと、OpenJDKのStyle Guidelinesも見ておくとよさげ。 Style Guidelines for Local Variable Type Inference in Java ローカルメソッドの定義にvarを使う 通常の変数定義でのvarの使い分けは長くなりそうなので、最初にこれだけ書いておきます。 いままで、メソッド内で使えるローカルメソッドを使おうと思うと、Functional Interfaceを使うくらいしかありませんでした。 Function<Integer, Integer> twice = x -> x * 2; println(twice.appl

    Java10のvarをどう使うか - きしだのHatena
    UDONCHAN
    UDONCHAN 2018/03/27
    参考になる
  • 囚人のジレンマ的には、うなぎはSNSにアップしないのが得 - きしだのHatena

    うなぎ、あまりSNSに画像アップしないほうがいいと思うんですよね。 「あの人、絶滅危惧種たべてる〜」とか思われるという話ではなくて。そういうのは普通に踏まえてると思うし。 うなぎ、レッドリストにも載って絶滅危惧種指定されているし、今年のワシントン条約は回避したけど次回はどうなるかわからないし、べれなくなるのも時間の問題ですね。 そして、うなぎをべるかどうかは、囚人のジレンマのような状態になっています。まとめるとこう。 自分 ほかの人 結果 べない べない 絶滅回避。いちばんいい。 べない べる 絶滅してべれない。損 べる べる 絶滅早まる。痛み分け べる べない 絶滅遅れる。得 そんなウナギをいまべる場合は、絶滅する前にべておこうという戦略、ほかの人がべれなくなっても自分だけはべる、という戦略だと思うので、SNSにアップしてほかの人がべたくなって絶滅や禁輸が

    囚人のジレンマ的には、うなぎはSNSにアップしないのが得 - きしだのHatena
    UDONCHAN
    UDONCHAN 2016/07/19
    ともかくとしてうなぎはうまい
  • JAWS-UG三都物語で「そろそろJavaみなおしてもええんやで」というプレゼンしました - きしだのHatena

    夏のJAWS-UG 三都物語 2014というイベントで「そろそろJavaみなおしてもええんやで」というプレゼンしてきました。 Javaのイベントではなかったので、Javaを使ってない人を想定したプレゼンでしたが、実際会場のほとんどがJavaメインではなかったようです。 for(int num : nums){ if(num > 10) continue; sum += num * 2; } というコードが、NetBeansの「関数操作を使用」というリファクタリングで sum = nums.stream().filter((num) -> !(num > 10)).map((num) -> num * 2).reduce(sum, Integer::sum); になったところがハイライト。 ここまでできるとは思ってなかった。 そろそろJavaみなおしてもええんやで from なおき きしだ

    JAWS-UG三都物語で「そろそろJavaみなおしてもええんやで」というプレゼンしました - きしだのHatena
    UDONCHAN
    UDONCHAN 2014/07/09
    いい話
  • iteratorや拡張forよりStreamのforEachが速い? - きしだのHatena

    ちょっと気になったので、簡単にベンチマークしてみました。 最初は、ラムダ呼び出しが入る分forEachは遅いんじゃないかと思っていたら、倍の速さに。 もちろん、いろんな条件で変わるんだろうけど、ここまで差が出ることがあるのは驚き。 あと、Collectors.summingIntのような基型に対するCollectorを使うよりは、intStreamに変換してからsumなど専用メソッドを使うほうが圧倒的に速いことも確認できた。 とりあえず、0から10万件のListを用意。 array = IntStream.range(0, 100_000).boxed().collect(Collectors.toList()); それからベンチマーク用のメソッドを用意。 public static void bench(String name, Supplier<Integer> proc){ ben

    iteratorや拡張forよりStreamのforEachが速い? - きしだのHatena
    UDONCHAN
    UDONCHAN 2014/03/31
    激ヤバやないか…
  • プログラムの生産性をあげるためには - きしだのHatena

    前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛

    プログラムの生産性をあげるためには - きしだのHatena
    UDONCHAN
    UDONCHAN 2014/03/12
  • Java8には型推論があるので型指定不要で変数が使えますよ - きしだのHatena

    Javaプログラマのみなさんは、Javaは型推論がないから変数の型指定をしなくていけなくてダサい、などとイジメられた経験があると思います。 おかあさんに型推論をねだるとGroovyをわたされたり、おとうさんに型推論をねだるとScalaがやってきたり、プレステが欲しいって言ったのにWiiやXboxを買い渡される感を味わった人も多いのではないでしょうか。 そんな良い子のJavaプログラマのために、今年はサンタが素敵なプレゼントを持ってきてくれましたよ。 同じ型を書くのがダサい たとえばウィンドウを出してボタンを押したらメッセージが表示されるサンプルを書くとこんな感じになりますね。 public static void main(String... args){ JFrame f = new JFrame("テスト"); JButton b = new JButton("押して"); JText

    Java8には型推論があるので型指定不要で変数が使えますよ - きしだのHatena
    UDONCHAN
    UDONCHAN 2013/12/24
    そーなのかー
  • Java8日付時刻APIの使いづらさと凄さ - きしだのHatena

    いままでのJavaでは、日付時刻を扱おうとするとめんどくさい割に非常に低機能でした。 Java8では、新たに日付時刻APIが導入され、めんどくささが増しつつ非常に高機能になりました。 (以降、Java8で導入された日付時刻APIを単に「日付時刻API」と表します) もちろん、慣れてきて、ちょっとしたサポートメソッドを用意してやれば、結構使いやすいのですが、それは「このAPIは使いやすい」という評価にはなりません。 つまり日付時刻APIは、慣れないとぜんぜんわからないし、サポートメソッドがないと面倒なコードが必要ということです。 いろいろあってよくわからない 日付時刻では、時点を扱うInstantや期間を扱うPeriod、時間量をあらわすDurationなど多くのクラス・インタフェースが導入されています。 これらは、IDEの補完でAPIを探りながら機能を推測すれば、それなりにドキュメントなし

    Java8日付時刻APIの使いづらさと凄さ - きしだのHatena
    UDONCHAN
    UDONCHAN 2013/09/17
    うげー
  • Java8で最もインパクトのある構文拡張、デフォルトメソッド - きしだのHatena

    Java8でのラムダの使い方などを説明してきたのですが、構文拡張自体には触れていなかったので、改めてここで簡単に説明しておこうと思います。 まずは、Java8で実際に最もインパクトがある言語拡張、インタフェースのデフォルトメソッドです。 デフォルトメソッドとデフォルト実装 いままでインタフェースには実装をもつことができませんでしたが、Java 8からはインタフェースが実装をもてるようになります。 実装をもつメソッドを定義するときには、キーワードdefaultをメソッドの前につけます。 interface Foo{ void print(String s); default void twice(String s){ print(s); print(s); } } twiceメソッドが実装をもっています。この実装をデフォルト実装といいます。 デフォルトメソッドを実装するクラスで、デフォルトメ

    Java8で最もインパクトのある構文拡張、デフォルトメソッド - きしだのHatena
    UDONCHAN
    UDONCHAN 2013/06/11
    多重継承ェ
  • Java8のlambda構文がどのようにクロージャーではないか - きしだのHatena

    Java8にlambda構文が入りましたが、これはクロージャーではない、とされています。 では、どのように「クロージャーではない」のか、ちょっと見てみます。 まず、lambdaを返すメソッドを定義します。 public static Supplier<String> createMessenger(String name, String address){ return () -> { return String.format("私は%s、%sに住んでる", name, address); }; } 呼び出すと、こんな感じでSupplierを受け取ります。 Supplier<String> messenger = createMessenger("きしだ", "ふくおか"); このSupplierを実行すると、次のようになります。 System.out.println(messenger.

    Java8のlambda構文がどのようにクロージャーではないか - きしだのHatena
    UDONCHAN
    UDONCHAN 2013/05/22
    ううむ、Javaでやれることやるには困らないのだろうが、ううむ
  • Java8のStreamの目的と書きやすさや可読性、並行処理の効果について - きしだのHatena

    さて、前回Java8のStreamの使い方をざっと見てみたのですけど、はてなブックマークのコメントで「Javaが使われている領域でこんな言語拡張は必要か」「可読性が損なわれていて単なる自己満足ではないか」のようなコメントがついていました。 実際どうなのか考えてみます。 Java8のStreamの目的 では、いまJavaが使われている領域を考えてみましょう。 Javaがいまよく使われているのは、クライアントサイドではなくサーバーサイドです。とくに、直接アクセスをうけつけるサーバーではなく、分散データ処理のためのHadoopやHBase、全文検索エンジンのLuceneなど、バックエンド処理を行う製品のシェアが大きいように見えます。 TwitterGoogleでも、Javaで書かれたバックエンドが動いているようです。Facebookも分析系ではJavaを使っているようです。 大手サービスでバッ

    Java8のStreamの目的と書きやすさや可読性、並行処理の効果について - きしだのHatena
    UDONCHAN
    UDONCHAN 2013/05/10
  • 文字列でswitchするときはif-else switchイデオムを使うほうが安全 - きしだのHatena

    Java SE 7から、switch構文で文字列が使えるようになりました。 public void hoge(String s){ switch(s){ case "a": System.out.println("AA"); break; case "b": System.out.println("BB"); break; default: System.out.println("Other"); } } ところが、残念なことに、sがnullの場合はdefaultには飛ばず、ぬるぽが発生します。 そこで、null判定は事前にif文で行うことになるので、次のようなif-else switchイデオムを使うと便利です。 if(s == null){ System.out.println("Null!"); }else switch(s){ case "a": System.out.printl

    文字列でswitchするときはif-else switchイデオムを使うほうが安全 - きしだのHatena
    UDONCHAN
    UDONCHAN 2013/04/28
  • CPUはオワコン - きしだのHatena

    FPGACPUを組んでると、フェッチ部やデコーダ部で足し算や掛け算をしようとして、そんなことしたらCPUの意味ないなーと思ってしまうことがありました。 で、よく考えたら、FPGAでロジックを組むならCPUの意味はないんです。 だいたい、ひとつの処理実行するのに何クロックかかってんですか!と。 CPUでは、計算効率をよくするためにパイプラインという仕組みが使われています。 最近では、18段とかのパイプラインもあるようです。 ここで、18段のパイプラインのうち、実際に計算を行うのは2段か3段だったりします。残りの15段くらいは、命令や計算結果を読んだり書いたりしているだけです。 このパイプラインも、ほとんどはメモリの読み書き、それも命令の読み込みに多くが使われます。 であれば、CPUにしなければ、18段全部計算に使えるんじゃね?という話になりますね。 決まりきった計算を行うのに、いちいちメモ

    CPUはオワコン - きしだのHatena
    UDONCHAN
    UDONCHAN 2013/02/20
    いい話
  • 文章に向いてない構造をいかに文章に向いた構造に直列化するかが大事 - きしだのHatena

    Software Design 12月号の特集が「なぜエンジニアは文章が下手なのか?」というタイトルだったので、読んでみたら、ちょっと残念な内容だった。 「それは文章で書くべき情報なのか」という章があって、直列化した論理構造であれば文章には書きやすいけど、分岐やループがあるような構造だと書きにくいということが書いてあった。そこで文章化しにくい構造の例として地図があげてあって、暗にそういう構造は文章化をやめて図であらわせと言っているように読める。 けれども、図に書いたところで、書く側は文章化から逃げれて満足かもしれないけど、それを読み取る側は結局どこかから順番に解釈していく必要がある。図に逃げるのは、読み手に責任を押し付けているだけだと思う。 で、「ですから文章を書く前にまず論理構造を考える必要があります」と続いていて、では考えた論理構造が「文章に向かない論理構造」だったらどうするの?逃げる

    文章に向いてない構造をいかに文章に向いた構造に直列化するかが大事 - きしだのHatena
    UDONCHAN
    UDONCHAN 2012/11/25
  • Sencha Touchの本を書きました - きしだのHatena

    JavaScriptリッチクライアントフレームワークのSencha Touch解説を書きました。 Sencha Touchではじめるモバイルアプリ開発―無料で使える「HTML5」&「JavaScript」開発フレームワーク (I・O BOOKS) 作者: きしだなおき出版社/メーカー: 工学社発売日: 2012/11メディア: 単行購入: 1人 クリック: 24回この商品を含むブログ (7件) を見る 表紙になぜかコーヒーカップとJavaって書いてあるのは、ぼくの管轄外です・・・。あと、キャプチャ画面、もすこしいい感じのを使ってもらうことはできなかったのか・・・。ただ、実物の色合いはもうすこし落ち着いています。 Amazonでは15日発売だけど、公式サイトによると19日発売、らしいです。どっちが正しいかは、まだ聞いてません・・・ ともあれ、目次はこちらから。 ���Ҿ�����Senc

    Sencha Touchの本を書きました - きしだのHatena
    UDONCHAN
    UDONCHAN 2012/11/18
  • おねえさんを組み合わせ爆発から救う:完結編おねえさんは星になった - きしだのHatena

    おねえさんを組み合わせ爆発から救うために、経路をZDDとして表したら、すっきりと経路情報が扱えました。 http://d.hatena.ne.jp/nowokay/20121018#1350528607 あとは、このZDDを効率よく構築できれば、おねえさんを救えそうです。このZDDの構築には、クヌース先生の開発したSimpathアルゴリズムを使うと非常に効率よく構築できます。 前回生成したZDDを見ると、同じノードにまとまっているものがいくつかあることがわかります。特に後半になるとどんどん同じパターンになるものがまとめられていきます。 つまり、この経路問題のZDDを構築するときには、いかに同じパターンになるものをまとめるかが鍵になるということです。 Simpathでは、辺の端だけに注目して、同じパターンになっていればそれ以降のノードを使いまわすという考え方で、ノードをまとめていきます。 つ

    おねえさんを組み合わせ爆発から救う:完結編おねえさんは星になった - きしだのHatena
    UDONCHAN
    UDONCHAN 2012/10/19
  • おねえさんを組み合わせ爆発から救う:2分決定木を作る - きしだのHatena

    おねえさんを組み合わせ爆発から救うために、まず格子グラフを作成しました。 http://d.hatena.ne.jp/nowokay/20121015#1350267331 こんどは、そのグラフの辺について、それぞれ通るか通らないかの組み合わせによって、始点から終点までの単純な経路になってるかどうか判定して、それをツリーとして表してみます。 右の実線に行く場合はその辺を通る、左の点線にいく場合はその辺は通らない、ということをあらわします。そして、最終的に始点から終点までの単純な経路になっている場合を「T」なっていない場合を「F」とします。 ここでは、1x1マスのグラフをあらわしているので、「1:3」と「3:4」を通る場合、つまり右に分岐する場合と、「1:2」と「2:4」を通る場合、右に分岐する場合だけが「T」となっています。 判定方法は、ツリーの途中では、始点と終点に入る辺が2以上になる

    おねえさんを組み合わせ爆発から救う:2分決定木を作る - きしだのHatena
    UDONCHAN
    UDONCHAN 2012/10/16
  • MVCは死んだ。MOVEするときがきた - きしだのHatena

    Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ? 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか

    MVCは死んだ。MOVEするときがきた - きしだのHatena
    UDONCHAN
    UDONCHAN 2012/07/04