2015年8月31日月曜日

WebSocketのサンプルコード(サーバサイド)

GlassFish 4.1 + Java 1.7で記述。
(サポート切れててゴメン。たぶん1.8でも動くよ(祈り)。)

なんか画面の表示下のコード表示が微妙にバグ踏んでるけど、まあいいや。
(勝手に<Session>を</session>で閉じなくていいんだよ......</session>消せないし...)
※102行目の</session></session>は無視おねがいします。

package websocketchatter;

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
import java.text.SimpleDateFormat;
import java.util.Collections;
import java.util.Date;
import java.util.HashSet;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.websocket.OnClose;
import javax.websocket.OnMessage;
import javax.websocket.OnOpen;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;

/**
 * WebSocketのURIを指定。
 * @author USER
 */
@ServerEndpoint("/MessageReceiptor")
public class MessageReceiptor {

    private static Set peers = Collections.synchronizedSet(new HashSet());
    private static File file;
    private static BufferedWriter writer;

  /* いずれかのセッションからメッセージが送信された場合のメソッド */
    @OnMessage
    public String onMessage(String message) {
       for(Session s : peers) {
      /*
             非同期に各セッションにメッセージを送る。
           */
           s.getAsyncRemote().sendText(message);
           try {
               System.out.println(message);
               writer.write(message, 0, message.length());
               writer.newLine();
               writer.flush();
           } catch (IOException ex) {
               Logger.getLogger(MessageReceiptor.class.getName()).log(Level.SEVERE, null, ex);
           }
           System.out.println(message);
       }
        return null;
    }
  /* セッションがクローズされた際に呼び出されるメソッド */
    @OnClose
    public void onClose(Session peer) {
        peers.remove(peer);
    }

    /* セッションがオープンされた際に呼び出されるメソッド */
    @OnOpen
    public void onOpen(Session peer) {
    /*
         この処理は非常に雑なので参考にしないで。
     永続化に際してはJPAとかを使ってRDBに書き込んだりしたほうがいいと思います。
     滅茶苦茶雑な処理です。(こんな書き方はしてはいけません。)
         修正したら正式版を別記事で挙げます。
        */
        if(file == null) {
            Date date = new Date();
            SimpleDateFormat format = new SimpleDateFormat("YYYYMMdd");
            String str = format.format(date);
            file = new File(str+".log");
            try {
                System.out.println("File Path:" + file.getCanonicalPath());
            } catch (IOException ex) {
                Logger.getLogger(MessageReceiptor.class.getName()).log(Level.SEVERE, null, ex);
            }
        }
        
        if(writer == null) {
            try {
                writer = new BufferedWriter(new FileWriter(file));
            } catch (IOException ex) {
                Logger.getLogger(MessageReceiptor.class.getName()).log(Level.SEVERE, null, ex);
            }
        }
        
        try {
            BufferedReader reader = new BufferedReader(new FileReader(file));
            for(String str = reader.readLine(); str != null; str = reader.readLine()) {
                peer.getAsyncRemote().sendText(str);
            }
        } catch (FileNotFoundException ex) {
            Logger.getLogger(MessageReceiptor.class.getName()).log(Level.SEVERE, null, ex);
        } catch (IOException ex) {
            Logger.getLogger(MessageReceiptor.class.getName()).log(Level.SEVERE, null, ex);
        }       
        peers.add(peer);
    }    
}


そのうち、クライアント側処理(jQuery + Bootstrapを組み合わせた場合かな~...)
と組み合わせた時の画像か動画でも載せます。

ちな、jQueryとBootstrapの使い方として正しいのかは保証しません。

なので、今後のToDoとしては以下の通り

  1. クライアント側(ブラウザ側実装の提示)
  2. PowerPointスライド(画像)によるサーバサイド処理の内容の表示
  3. @OnOpen処理の屑さ加減の改善(JPAを使ったRDBによる永続化

JFreeChartで横軸の値を縦書きにする

JFreeChartでグラフを作るときに悩ましいのが、
横軸のラベル(って言えばいいのでしょうか?)の管理。
横軸ラベルの文字列が長くなると本来の値が
...に置換されてしまい残念な結果になってしまいます。
一応の対応策としては、ラベルを縦書きにすることで
問題を解消できます。
こんな感じで、修正可能です。
JFreeChart chart = ChartFactory.createBarChart("サンプルグラフ", "横軸", "縦軸", dataset);
chart.setAntiAlias(true);
CategoryPlot plot = chart.getCategoryPlot();
CategoryAxis axis = plot.getDomainAxis();
axis.setCategoryLabelPositions(CategoryLabelPositions.UP_90);

JFreeChartから上記処理に基づいて
CategoryAxisを取得しsetCategoryLabelPositionsメソッドで
向きを変更することができます。

2015年8月28日金曜日

なんだこれ

以下の記事だけやたらと閲覧数が多い。なんでだ?
対した記事ではないと思うんだけど。
所詮はjQueryのことを良く知らない人間が勉強し始めて即日書いたものなのに......


http://ryoma0923.blogspot.jp/2015/01/jquerycss.html


律儀に動画を作成したのがよかったのかな?

ユーザ主導の技術革新(まだ案レベル)

とくにパブリッククラウドに限った話になりますが、
技術革新はユーザ手動で起こるという印象を受けます。

詳細は改めて説明しますね。

ハイプサイクルに踊らされる危険性

所謂Gartnerの発表しているハイプサイクル

https://ja.wikipedia.org/wiki/%E3%83%8F%E3%82%A4%E3%83%97%E3%83%BB%E3%82%B5%E3%82%A4%E3%82%AF%E3%83%AB

  • 黎明期
  • 流行期
  • 幻滅期
  • 回復期
  • 安定期
の5つのフェーズで新しい技術が広がっていったり、途中で消えたりするアレです。
個人的には、発表する意義は大いにあるけれども如何わしいと思うものですね。

これには少なくとも一つだけ技術的にいえることがあります。

流行期から幻滅期に落ち込んだ時にどこまで頑張れるかという問題です。
最近の技術はOSS主導がほとんどです。
安定期にたどり着くまでの技術っていうのは幻滅期にどれだけのビッグベンダーが撤退せずに
踏みとどまったかである程度の趨勢が決まるという印象を受けます。
(根拠は見つけ次第追記しようかと。なければこの記事は撤回。) 

正直なところはビッグベンダー以外はは審美眼とかそういうレベルの話になってしまい、
山師が鉱脈を見つける以上の根拠はなかなか説明しづらいと思います。
(ビッグベンダーにガンガン売り込んでファンを増やすという手はあるかもしれません。)
これまでも技術的に優れていても消えていった技術は山ほどある訳で。
結局のところ安定期にたどり着ける技術というのを確実に見分ける方法は永遠の課題になり続けると思います。

注意したいのは、仮に安定期までたどりついたテクノロジーがあったとしてもそれが流行期に大量に広まったものと同じものであるかという問題です。

最近の例だとハイプサイクルに直接載っているかは知りませんが、
Hadoopがいい例かと思います。

Hadoopのアーリーアダプター?の悩みがHadoopのバージョン間での断絶です。
Hadoopの2.2以降で導入されたYARNについては様々なHadoopのバリエーションを生み出してしまいました。(とはいっても使いたい処理内容別にいろいろな選択肢が用意されたという観点では悪いこととは一刀両断できないわけですが)

Hadoopに限った話でよいのでそこに対するアプローチって何かあるのでしょうかね?

一部のSIerのようにコミッタを輩出してコミュニティをコントロールしようとするなんて力技もあったりするわけですが。

ただ一つ言えることはテクノロジー企業である限りは安定期に入ってからのんびり参入なんてのは基本的には勝ち目は薄いと思います。(先進企業を買収するなんて力技除く)

適材適所の"所"って?(スコープの問題)

たまにはらしくない全体像のお話し。
適度にアルコールも入ったところで。


ものの配置などの選択をする際の基本原則があります。

”適材適所"

小学生でも知っている言葉ですね。

ですがこの言葉の厄介なところは、
適材適"所"の"所"のスコープです。

それを表すためによく使われる言葉が、

"局所最適化"と"全体最適化"。

適材適所の"所"の部分を考えてできるだけ
広い範囲での適材適所を考えられるように
なりたいというのが今のところの目標。

これをどこまで広く考えられるかが、
ここでの問題。

例えば孫正義さんみたいなレベルになると
常人には考えられないスコープで考えてしまうので、
一般人からすると完全に突飛な考えが出てきてしまう
傾向が強いのかなと思ったり。

少なくともPepperなんかは広告塔以上の役割は
すぐには出てこないけれども将来的には
絶対に有用性の出てくる技術かと思います。

そもそも局所最適化を突き詰めることが
できる人もなかなか少ないのもアレなわけですが。
局所最適化はブラックボックスを生み出しやすい
といった問題をはらんでいます。

(エンジニアの方には理解いただけるかもしれませんが、
パフォーマンスチューニングしまくったソースコードは
可読性が下がるってアレです。)

全体最適といってもどこまでを全体とみなすかという
問題はどうしても生じてしまうんですけどね。

企業の一担当者であれば、自身の担当範囲。
(もう少し広く考えてほしいというのはあるかもしれませんが)

企業の管理者であれば、自身の管理範囲内での
全体最適を目指さなければなりません。

政治家だったら自分の国全体における全体最適を
目指す必要があります。

人によって全体最適の全体の定義が変わってしまうのは
仕方ないと思います。おそらく他人からそういった観点で
尊敬される人というのは自身の担うべき範囲を少し超えた範囲まで
カバーして全体最適(に近いもの)を出せる人なのかなと......

なかなか私自身は自身の範囲内での局所最適化に
はまりやすいですしそこまでいたらないことも多いですが、
なるべく広い範囲での全体最適を目指して動きたいですね。


あ~、酒で正気を保っていないだけに取り留めのない文章に
なってしまいましたが、ひとまずこの記事はここまで。