2016年3月23日水曜日

Functional Interface を意識した URLCon のライブラリを作成した

そのうち maven とかに登録した

眠い・・・

投稿者 Unknown 時刻: 2:08 0 コメント
ラベル: , ,

2015年3月24日火曜日

メンタリング

メンタリング本を中古でアマゾンで購入

 読んでいてずーと違和感があった

原因は何なのか？という事だが

 前提条件として、 

『企業は存続すべき事業内容を実施かつ組織である』
 『メンターとメンティーはそれぞれのロール実行能力を要する』 

を満たしていなければいけない 上の条件って、む、無理・・・結局、

 『問題の無いように事を進める』 または『事なかれ主義』

 に落ち着くのが現実なのだと思う 

これは、発祥は欧米なので一般的に日本(東洋)とは合わないと感じるのであった

 
投稿者 Unknown 時刻: 1:02 0 コメント

2015年3月8日日曜日

HHKB 見せてもらおう、アフィリエイトとやら力を

キーボードを『HHKB Pro 黒 刻印あり』から『HHKB pro Type-S 白 刻印なし』にした、 このタイピングは！！後戻りはできない・・・・、家用が『HHKB Pro 黒』となったが、う、うるさい・・・ 今度は、FILCOとかを試したいと検討中ですね

投稿者 YooWaan 時刻: 1:19 0 コメント
ラベル: , ,

JIRAの車窓から

JIRAは使いづいらい トレンドは上がっているが・・・・

＜使いづらい点＞

  • BackLogが増えると、カオスで把握しきれない
      　　
    • Epic,Component で分けれるが、分けたら分けたで余計全体が把握できない
      • 　　
    • WBSは有料plugin ＼（^o^）／
  • Agileのバックログ/スプリン画面の右に簡易の課題表示の編集がかゆいところに手が届かないようになってる
  • Agile,Kanban をちょっとでも知ってないと、石像になる人がでる（これで合点が多い場合は、日本は多分終わってる）

などなどですが、争点はこれではないので置いておいて、

[管理者]層のリテラシー、体質が追いつてない限り、[現場]の作業フローとか組織構成はなんの意味も持たないため、管理体制と作業フローの間での乖離が発生し、結果的に作業フローで使用している。JIRAなどのツールが使いづらいのでなないだろうか？ という仮説があります。（イメージは下図）これを読んだ方どうでしょうか？ 


[元ネタ] 反復開発/アジャイル/スクラムの作業フロー
 ↓
[管理者] 経営者？冗長？日本の文化と合わない or 理解（リテラシー）がない
 ↓　　　　　　　　　　　　　　　↓
[現場] JIRA使いづらい　　　　自己組織化されない

[現場]レベルで導入しても、[管理者]が理解レベルが合わないと、かみ合わない歯車がグルグルとなるので、 早急に対応が必要となるが、[現場]から[管理者]に知識や勝手をインストールすることまで、余裕が取れる状況はどれくらいあるのだろうか？ また、[管理者]がインストールに対して前向きである必要もあるので、文化の改変まで日本レベルでN十年かかるのだろうか・・・orz

海外での職場は普通に作業フローを実行できているのだろうか？ ご存知の方いましたら、コメントをお願いします。 また、そういったフォーラムの掲示板をご存知の方も情報いただけると助かります。 英語ならギリ話せると思うので、海外サイトでも大丈夫です。

そもそも、日本ベースのしょうゆ味作業フローを考えないといけないかもしれませんね。（^^)

投稿者 Unknown 時刻: 0:17 0 コメント
ラベル: ,

2014年6月13日金曜日

Docker01 Initialize 

mac $ boot2docker init --disksize=50000 --memory=2048
mac $ boot2docker start

確認結果

mac $ boot2docker ssh
docker@boot2docker:~$ df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                    1.8G    204.8M      1.6G  11% /
tmpfs                     1.8G    204.8M      1.6G  11% /
tmpfs                  1004.6M         0   1004.6M   0% /dev/shm
/dev/sda1                47.0G     68.9M     44.5G   0% /mnt/sda1
cgroup                 1004.6M         0   1004.6M   0% /sys/fs/cgroup
/dev/sda1                47.0G     68.9M     44.5G   0% /mnt/sda1/var/lib/docker/aufs
docker@boot2docker:~$ free
             total         used         free       shared      buffers
Mem:       2057440       271940      1785500            0         1348
-/+ buffers:             270592      1786848
Swap:       447972            0       447972
docker@boot2docker:~$ cat /proc/meminfo 
MemTotal:        2057440 kB

次は、web server, db をセットアップしよう

mac $ boot2docker stop
投稿者 YooWaan 時刻: 2:47 0 コメント
ラベル:

2012年8月10日金曜日

Google APIs Calnedar & OAuth2.0 (v3/v2)

はじめに

Google APIs を使うコマンドラインを書いてみました。自分のイベントとか見たい方は適当に改良してください。:-)

** かぶりネタですが興味のある方は読んでください。**


Usage

USAGE
      gapicalendarlist.sh  v2|v3

RESET SETTINGS
      remove 'v2.gapi.token' or 'v3.gapi.token'

DEPENDENCIES
      lynx, curl


解説のようなメモのような

簡単に認証と処理内容を書いてみました

認証の種類

Version 2 : using ClientLogin
  • OAuth
  • AuthSub
  • ClientLogin
Version 3 : using OAuth -> Devices

知識の足りなさ等の諸事情で Devices の方法を選択してます。

Installed Applicatoins の方式で、https://accounts.google.com/o/oauth2/auth にリクエストするとHTMLコンテンツがかえって来ます。これはシェルであれこれするのが面倒だったのでやめました。
Devices方式で、https://accounts.google.com/o/oauth2/device/code にリクエストをすると、JSONがかえってpiar毎に改行されているのでシェルで扱いやすいのでこちらを選択しました

  • OAuth
    • Login
    • Web Server Applications
    • Client-size Applications
    • Installled Applications (Winwdows, iOS, Android, Blackberry)
    • Devices
    • Service Accounts

処理内容

*** Google のサイトを見た方がいいと思ったので割愛します。 ***

 [ shell ]                  [ google ]
    |                            |
    |                            |
    +----- get user token -----> +  URL 1 
    |                            |
    | <------ user token --------+
    |     and other params       |
    |          JSON              |
    |                            |
    +----+                       |
    |    | save token            |
    |<---+                       |
    |         [ lynx ]           |
    |            |               |
    +-- verify ->|               |
    |    URL     +-- Sign in --> |
    |            |               |
    |            |<- user code --+
    |            |     form      |
    |            |               |
    |            +- user code -->|
    |            |               |
    |            |<- allow acces-+
    |            |  confirm page |
    |            |               |
    |            +-allow submit->|
    |            |               |
    |            |<- result page-+
    |            |               |
    |                            |
    |                            |
    |                            |
    |                            |
    +------ get access token --->+ URL 2 
    |                            |
    | <------ access token ------+
    |       and other params     |
    |           JSON             |
    |                            |
    +----+                       |
    |    | save token            |
    |<---+                       |
    |                            |
    |                            |
    +----- get calendar list --->+  URL 3
    |                            |
    | <----- calendar list ------+
    |         JSON               |
    |                            |
    |                            |


URL 1 https://accounts.google.com/o/oauth2/device/code
URL 2 https://accounts.google.com/o/oauth2/token
URL 3 https://www.googleapis.com/calendar/v3/users/me/calendarList

Reference Link

Google OAuth 2.0

Google APIs Calendar



Source & Screen cast


ttyplay


投稿者 Unknown 時刻: 20:17 0 コメント
ラベル: , ,

2012年4月25日水曜日

web server benchmark : apache lighttpd nodejs warp yesod tomcat jetty

結論

QCon 2012 で Warp+Yesod がいいと言っていたので、ベンチをとってみました。いいっぽいです

サーバーサイドのチューニングはデフォなので、スレッド数位は合わせてベンチマークをとりたいと思って下ります。 なんかサーセン

環境

Server

Ubuntu 11.10

Intel(R) Xeon(R) CPU 5160 @ 3.00GHz x 2

Memory 2 GiB

|

Switching Hub

corega Fast SW-8D

|

Client

Mac OS X 10.7.3

2.53 GHz Intel Core i5

Memory 8 GB 1067 MHz DDR3

計測の仕方

$ ab -n request_count -c 128 -r -g gnuplot_file_name   http://ubuntu.server:port/path   >& result.txt

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

計測したもの

Apache Lighttpd 

Server Software:        Apache/2.2.20
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            80

Document Path:          /index.html
Document Length:        85 bytes


Server Software:        lighttpd/1.4.30
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8123

Document Path:          /index.html
Document Length:        85 bytes
Node.js Warp + Yesod

version: 0.6.15


Server Software:        
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8124

Document Path:          /
Document Length:        80 bytes

ghc: 7.0.3

warp: 1.2.0.1

yesod: 1.0.0.2


Server Software:        Warp/1.2.0.1
Server Hostname:        xxx.xxx.x.160
Server Port:            8123

Document Path:          /index
Document Length:        99 bytes
Tomcat Jetty 

Server Software:        Apache-Coyote/1.1
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8080

Document Path:          /sample/index.html
Document Length:        85 bytes



Server Software:        Jetty(8.1.2.v20120308)
Server Hostname:        xxx.xxx.xxx.xxx
Server Port:            8080

Document Path:          /sample/index.html
Document Length:        85 bytes

計測結果

wait time 分布図

30000 request

10000 request

wait time について => Between writing request and reading response

Source らしい(何となく怪しい) から一部抜粋

struct data {
#ifdef USE_SSL
    /* XXX insert timings for ssl */
#endif
    int read;                   /* number of bytes read */
    long starttime;             /* start time of connection in seconds since
                                 * Jan. 1, 1970 */
    long waittime;              /* Between writing request and reading response */
    long ctime;                 /* time in ms to connect */
    long time;                  /* time in ms for connection */
};

テスト時間 (sec)

apache, lighttpd はリクエスト数が多いとテストに時間がかかります。


result/apache-time.dat
request  1       2       3       4
  200    0.028   0.035   0.030   0.031
  500    0.081   0.087   0.078   0.069
 1500    0.187   0.172   0.187   0.185
10000   90.143 109.438 107.131 104.303
30000   18.995   3.584  32.986 327.660

result/lighttpd-time.dat
request  1       2       3       4
  200    0.025   0.025   0.027   0.026
  500    0.063   0.069   0.055   0.053
 1500    2.139   0.561   0.168   0.169
10000  50.097   52.646   2.285  34.739
30000 142.147    5.152 165.114 162.209

result/nodejs-time.dat
request  1      2        3       4
  200    0.034  0.039    0.034   0.032
  500    0.097  0.074    0.073   0.072
 1500    0.238  0.235    0.245   0.211
10000    1.560  1.610    5.101   1.505
30000    8.593 24.368   16.838  31.659

result/warp-time.dat
request  1      2        3       4
  200    0.071  0.093    0.074   0.070
  500    0.160  0.309    0.229   0.176
 1500    1.264  1.057    1.326   1.048
10000    3.115 10.991   11.347   5.078
30000   33.264 34.866   33.098  34.690

result/tomcat-time.dat
request  1      2        3       4
  200    0.021  0.024    0.025   0.080
  500    0.052  0.050    0.049   0.043
 1500    0.151  0.167    0.166   0.153
10000    9.062 10.112    6.957   0.965
30000   21.004 12.324   21.602  18.784

result/jetty-time.dat
request  1      2        3       4
  200    0.025  0.025    0.026   0.028
  500    0.087  0.104   14.926   0.059
 1500    1.127 22.815    1.244  14.990
10000   11.779 11.658   11.648  11.617
30000   36.141 36.806   36.773  36.225
投稿者 YooWaan 時刻: 16:02 0 コメント
ラベル: , , , , , , ,
登録: 投稿 (Atom)