30分以内の配達を実現するAmazonの配達ドローンが劇的進化、着陸方法など最新版ムービー公開

http://gigazine.net/news/20151130-amazon-prime-air-in-30-min/

Amazon Prime Airは5ポンド(約2.3kg)までの商品を30分以内に届けるサービスで、アメリカ、イギリス、イスラエルに開発拠点を構えてサービススタートに向けて試験フライトが繰り返されているとのこと。法整備が追いつかないほどの開発スピードですが、安全性と合法性をたずさえて、30分以内の驚異的な配達サービスのスタートに向けて、Amazonは着々と準備を進めているようです。
日本でも一部とないで1時間以内のハイタッチサービスが開始。
高齢者が多い内は量販店が残っているだろうけど、
10年後、20年後はどうなるか…
時代に合わせて生き残って行くには情報収集だけではなく
そこから先を推察する思考が必要な。

超優秀なプレイヤーは出世させてはいけない

http://www.masafumiotsuka.com/2015/11/the_peter_principle.html

例えば営業で大きな実績を上げた人が、営業部長に出世する。すると今度は営業力ではなく部下の管理する力が求められる。しかし、このスキルを見込まれて出世したわけではない。自分では数字をあげられるが、自分のやり方を押し付けても、人が違う以上、うまくいかないケースが多い。しかし、一度得た地位を下げ、元の一営業員に戻るのは敗北宣言。どんなことをしてえも現在の地位にしがみつこうとする。そして辞めさせられる（日本の企業の場合、周りを不幸にする）。

当たり前というか…
能力、ポテンシャルを見抜いてポジションを与えるべきだし、
優秀なプレイヤーは将来性を見据えた生産性に合う対価を与える。

見合わなければとどちらかが思えば、
切り捨てるor去る…というのを日本でもやりやすい環境にして
危機感と人材の流動性がある社会の方が最近は良いと感じるようになってきた。その方が

• 労働者も色々な世界を知れる。
• 優秀ではない人はがんばる。
• 優秀な人を確保する為に労働環境も整備される・・・？

堀江貴文/ホリエモンについて

賛否が色々あるようですが、私は堀江貴文がけっこう好きで、

有料メルマガや書籍、Youtubeの動画など良く観ます。

誕生日が同じで少し親近感があるってところもあるかな？

考え方や頭の回転などはとても参考になる。

メルマガとかは引用できないけど、Youtubeの動画を一部紹介。

宇宙事業の話。
内容も興味深いしわかりやすく・笑いのあるプレゼンでとても好感。
プレゼンの参考になる。こういうプレゼンが私の理想だったりします。

少年時代から企業・球団/ニッポン放送買収、衆議院選証券取引法違反などなど。
関口宏の進行も良いのでテンポが良くて観やすい。

お金・・・というより、世の中の【信用】と、
情報社会、グローバル化などの話。

君がオヤジになる前に

最近読んでいる書籍！

Qiitaへ移行

長いこと放置していたこのブログですが、

定期的なINPUT(情報収集)とOUTPUT(情報共有)をしないと

思考停止してしまう・・・

ということでこれからはこのブログはITやビジネス関連を中心として

時事ネタやニュース記事に対する所感を中心とした記事を投稿することにして、

プログラム関連のアウトプットはQiitaにしようと思います。

今後はhttp://qiita.com/petticoat-lanerも宜しくです。

そもそも、はてぶのコメントでいいじゃん！って気もしますが、

あっちは自分用の「ブックマーク」なのでとりあえずここでテスト運用！

JBOSSとSeasarとTeeda その４

だいぶ時間が空いてしまいましたが、JBOSS移行シリーズ最終回。
もはや少し忘れかけてます。。。

サーブレットコンテナによる細かい仕様の違いなんだけど、
まずはFilterです。

WebLogicではサーブレットフィルターの中で
フォワード(RequestDispatcher#Forward)をすると
フォワード先にかかっているフィルターも呼ばれます。
しかしJBOSSではフォワード先のFilterは呼ばれない。

Tomcat7もJBOSSと同様でした。JBOSSもCatalinaのAPI使ってるしね。
Servlet2.4からWeb.xmlのfilter-mappingに
dispatcher属性が追加されて
フィルターの適用をリクエスト・フォワード・インクルード・エラーの
それぞれのイベントで選択できるようになったけど
WebLogicのバージョンが古いから全部適用になってたっぽい。
2.4移行はデフォルトでリクエストのみの様子。

これのせいでJBOSS環境ではフォワード後に
SeasarのHotdeployFilterが適用されなくて
RequestオブジェクトがDIできずハマった。。。

お次はInputStreamの２度読み。
WebLogicではInputStreamをBufferedInputStreamで
包んであげればmarkメソッドとresetメソッドで
一度お尻まで読み込み終わっても
ストリームの位置を元に戻せるけどJBOSSではできない。
resetが動作しないのでBufferedReader#readLineがnullになる。

その影響だと思うけど、
フォームなどのPOSTリクエストに対して、
SeasarのRequestDumpFilterで
ログを出力した後にInputStreamを使うと読み込めない。。
これはRequestDumpFilterの中で利用している
Request#getParameterNamesのせい。
これをコメントアウトすれば大丈夫！

POSTの場合はパラメータ情報を取得する時に
InputStreamを使ってるんだと思う。
getParameterNamesやgetParameterValue自体は
内部でキャッシュするからか、何度も呼べるけど
InputStreamはダメ。どうしてもやりたい場合は
HttpServletRequestWrapperを使って、
InputStreamをキャッシュしましょう。

あとはWindowsからLinuxへの移行ということで、
SJIS⇒UTF8になり、Byte長が変わって入力チェックや
各種制御を総見直しになったり、
MSゴシックのフォントが使えなくなったり。
まぁ、それはそれは大変でした。

AS7.2~はまだ情報も少ないのがキツかった。

JBoss Enterprise Application Platform6 構築・運用パーフェクトガイド

JBOSSとSeasarとTeeda その３

ログ設定まわりのお話です。

JBOSS関連で一番ハマったのがこれです。
JBOSS AS7.xでは各アプリケーションで利用している

Log4Jなどのロガークラスは
LogManagerがハックして一元管理する仕組みになっています。

JAVA標準のログAPIやLog4Jの呼び出す時に使われるクラスローダーは
以下のようにLogManager用のクラスローダーに置き換えられてしまう。

java.util.logging.Logger = org.jboss.logmanager
org.apache.log4j.Logger = org.jboss.log4j.logmanager

{JBOSS_HOME}/modules/system/layers/base/org/apache/log4/main/module.xmlを見ると

こんな記載があり、特定のパッケージの場合に
クラスを置き換えているのがわかる。
このファイルを消したりいじるとJBOSS自体が起動できるなる。
LogManagerを無効にする方法は後述します。

LogManagerではstandalone.xmlやdomain.xmlに書かれている
ログ設定に応じて出力されるようになる。
また、このXMLを変更してJBOSSを起動すると
{JBOSS_HOME}/{standalone|domain}/configuration/logging.propertiesにその設定が反映される。

上述のように基本的にはLogManagerで一元管理されるのですが
アプリケーションのクラスパス上にlog4l.xmlがある場合は
実はLog4Jのアペンダーなどの設定が優先されます。
ただし、実はここにトラップがあります。
その１でも書きましたが、私の今回のミッションはJBOSSへの

既存プロジェクト移行です。
Seasar2で作られたプロジェクトなのでSeasar系が出力するログは基本的に
CommonsLoggingが使われています。
配備するアプリケーションのcommons-logging.propertiesファイルが
置かれていてもJBOSS環境下では無視されるんですよ。
なのでLogFactoryでロガーインスタンスを作ると

apache.commons.logging.impl.SLF4JLocationAwareLogに
なってしまう。
ややこしいことにDBFluteはCommonsLoggingではなくクラスの中で
明示的にLog4jロガーを利用しているのでDBFlute関連のログは出る。
ハマる原因のひとつでした。TraceInterceptorを
ラップしてLog4Jロガーを使うように明示的に変更してあげると出ます。

一般的なプロジェクトであればこれで解決なのかもしれませんが
まだ問題はあります。
JBOSS上ではLog4j.xmlを各モジュール分読み込んでくれません。
先勝ちなのか後勝ちなのかわかりませんが、
どれかの設定がすべてに適用されるんです。

今回の移行対象のシステムは6つくらいあり、JAVAのパッケージ構成は同一で
それぞれのLog4j.xmlないでログの出力場所を変更しているんですが、
上述した仕様の為、全部同じログファイルに出力されちゃうんですよ。
まいった(>_<)＞

で、結局どう解決したかというと・・・

各モジュールのWEB-INFの下に
jboss-deployment-structure.xmlという名前で
こんなXMLを配備すれば良い。これでLog4jはLog4jとして動きます。

JBOSSとSeasarとTeedaシリーズも次回くらいが最後になるかと思います。
次はWebLogicとJBOSS、Tomcatの
サーブレットコンテナの仕様の違いや
その他、細かいところを。

JBoss Enterprise Application Platform6 構築・運用パーフェクトガイド

JBOSS AS7.2よりGlassFish4の方がいいなぁ。

JBOSSとSeasarとTeeda その２

今回はTeedaの設定まわり。

前回のS2Containerのコンポーネント登録を直しただけではダメです。
JBOSS自体にもJSFの機能がありますのでTeedaと競合してしまいます。
そこでWeb.xmlでJBOSSのJSFは使わないよ！と宣言してあげる必要がある。
以下を追記して下さい。

org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL
true

あと、HotDeoloyの場合、JBOSSだと
Seasarの初期化処理内でセッションのClassCastExceptionが発生してしまう。
ライブラリの奥地に手を入れるのはちょっとリスクだったので
開発時はTomcatを利用するようにしました。

その為、s2container.diconで
diconファイルを無理やり環境設定に応じて切り替えています。

"jdbc.diconn"
@System@getProperties().containsKey("jboss.host.name") ? "jdbc-jndi.dicon" : "jdbc.dicon"

"jta.dicon"
@System@getProperties().containsKey("jboss.host.name") ? "jta-jboss42.dicon" : "jta.dicon"

これでとりあえずはSeasar2&Teedaが動くようになります。
次回は一番ハマったログ出力設定。

JBoss Enterprise Application Platform6 構築・運用パーフェクトガイド