2014年10月25日

【お前だよ!お前!!】Node.js express!!

びじゅチューン!」の「ムンクの叫びラーメン」がお気に入りの息子。
いいのか!?本当にそれでいいのか!?息子よ!!!
嫁のやってしまった感が半端ないジャンボです。


mongoDB を勉強していく中で、やっぱりアプリとの連携が気になるジャンボさん。
mongoDB は Node.js との相性が良いとの事。

開発メーカーが同じとかそんな訳でもない中、
相性が良いってどういう事だろうね?

多分、mongoDB は BSON でデータのやり取りをしているので、
変換が少ない JavaScript で処理される Node.js が
パフォーマンスを一番生かせるって事なのかしらん?

だれか、分かっている人がいたら教えてください。


まあ、とりあえず、参考スクリプトも Node.js が殆どな訳で、
とりあえず、自分も触ってみようと思った訳です。

特に起動ユーザの制限とかは無いはずなのだけど、
特に理由が無ければ root で実行した方が良いですね・・・。

最初は nodejs という専用のユーザで動かそうとしたのですが、
色々と挫折しました・・・(汗

HTTP通信は通常は 80ポート を使用するのですが、
80ポートは特別なポートで、rootユーザじゃなきゃ起動できない。
この時点で詰みなのですが、他にも・・・

npm でインストールしたモジュールを読み込もうとしたら、
権限エラーで開けないエラーが多々。
(一通り権限を与えてみたのですが、その先の呼び出しモジュールが失敗したとかで、
何に権限を与えれば良いのか把握しづらい)

うーん・・・いらん所で色々と躓きました。


何よりも express お前だよ!お前!

Node.js にもフレームワークがあり、
その現行のデファクトスタンダードっぽいのが express というフレームワークです。
とりあえず、色々な書籍では、コイツを入れるのが前提のが多いです。

ただね・・・書籍で紹介されているのは epress 3.X 以下が多いのよ。
現行の最新版は 4.9.0 なのね。
メージャーバージョンが変わっている事からわかる通り、もはや別物。

書籍や色々なサイトの情報が役に立ちません。



express をインストールし、
当該のフレームワークを使ったプロジェクトは express コマンドで生成・・・
なのですが、express コマンドなんか、どこにもできない。

4.X からは、
express コマンドは「express-generator」に独立しました。

そんな訳で、上記も必要になるんですね。

で、できた express プロジェクトを起動しても、
エラーの連続。

色々と別途ライブラリを使用しており、
少なくとも自分は下記ライブラリをインストールする必要がありました。
 ・serve-favicon
 ・morgan
 ・cookie-parser
 ・body-parser
 ・debug

そして何よりもね・・・
"起動後「http://localhost:3000/」で確認できます。" が
全くできないのに一番躓いた。

起動コマンドも 4.X から変わっていて、
"node app.js" → "npm start" になってた。

えぇぇぇぇぇ・・・。


もう、4.9 って9回も最低マイナーバージョンアップしてるのに、
殆ど情報が無いのは何故〜?



posted by ジャンボ at 01:14| Comment(0) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年10月16日

【最近、多すぎやしないか?】SSL 3.0 脆弱性 POODLE!! (CVE-2014-3566)

ウチの嫁さんは大事なもの程、よく無くす。
今日は、プレゼントしたトートバックを無くされた・・・。
もう、誕生日プレゼントはチョコ棒100本とかにしてくれようか・・・ジャンボです。


またもや、重大な脆弱性が発表されましたね・・・。
SSLv3.0 脆弱性 POODLE (CVE-2014-3566)」!!

内容としては、
SSL通信の規格の一つである、SSL 3.0 について、
暗号化通信を行っているにもかかわらず、解読可能になるとのこと。

HTTPSサイトだから安心〜なんて思っていたら、
IDやパスワードが通信から丸見えだった。
なんて事がありえる訳です。

SSL 3.0 自体はかなり古いバージョンなので、
実際の通信で採用されるケースはあまりないとのことですが、
サーバ側で SSL 3.0 の通信もサポートしていた場合、
TLS(=SSL3.0の上位バージョンの様なもの)での通信になんらかの理由で失敗した場合、
SSL 3.0 での通信をリトライする仕様があるみたいで、この時に問題が表面化しそうです。
(上記仕様を悪用したツールもあるとかないとか・・・)

上記のリトライは普通にあり得るケースみたいで、
Microsoftの情報」を読み替える限りでは、数百に1回の頻度ではありえるかも。



この脆弱性、特定のミドルウェアの脆弱性ではなくて、
SSL の規格そのものの脆弱性なので、
SSL 3.0 のサポートを切る以外には対応策が無いという
悪魔の脆弱性です。



上記で "実際の通信で採用されるケースはあまりない" とありますが、
これはPCサイトに限られた話で、携帯サイトになると話が変わります。

携帯サイトといいますか、ガラケー向けサイトなんですけど、
SSL 3.0 までまでしかサポートしていない機種は最近の物でも色々あるんです。
(詳しくは各キャリアのサイトを参照ください)

キャリア側の対応は期待できないので、
お客様に買い替えてもらう以外に方法がない・・・。

うえぇぇぇ・・・・。



ちなみに、肝心の SSL3.0 のサポートを切る方法は、
Apacheの場合は下記の様に設定ファイルで明示的に指定すればOK。
(デフォルトは SSLProtocol all -SSLv2)

 SSLProtocol all -SSLv2 -SSLv3


じゃあ、IISは・・・

・・・
・・・・・・
・・・・・・・・レジストリの書き換えが必要です。


まぢか!?


posted by ジャンボ at 23:59| Comment(1) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年10月14日

【早いけどさ・・・】Google Chromeの背景の問題

最近、「3年後には、PCが全く使えない新人が入ってくるよ。」というつぶやきがあった。
確かに、今時ならスマホかタブレットでPC未経験もありえるか・・・。
ちょっとした衝撃。ジャンボです。



JavaScriptでペソペソ開発しているジャンボさん。
最近はクライアントサイドでも十分に動的な挙動が出来るから良いですね。

ただ、担当案件の都合上、IEは8なんですね・・・。
IE8ってHTML5周りはてんでダメなんですよ・・・。
CANVAS関連なんて使おうとしたら、目も当てられなくなります。

で、動作確認に Google Chrome とかを使用しているのですが、
スクロールした時の挙動がおかしい・・・。

インラインフレームの様にスクロールでオーバーフロー処理している所があって、
ウィンドウサイズに合わせて、当該の要素を拡大縮小する様にした所、
要素内のスクロールをすると、当該要素の背景画像がズレズレに・・・。

15パズルの様にスクロール付近の背景画像のみ動いて、
他はそのまんま・・・。

再度、ウィンドウサイズを修正すると元に戻ったり、
IE10とかで見た所、特にそんな問題は発生せず・・・。

おそらく、Google Chrome の
挙動を早くさせるための処理付近に問題がありそう。

そんな訳で、対応した方式が以下の通り。


$(document).ready(function() {
$([問題発生要素]).scroll(function() {
if($([問題発生要素]).find('.dummy').length > 0) {
$([問題発生要素]).find('.dummy').romove();
} else {
var dummy = $('<span class="dummy"></span>');
$([問題発生要素]).append(dummy);
}
});
}


簡単に言えば、問題要素をスクロールした際、
ダミーの要素を挿入し、再度スクロールしたらダミー要素を削除。
これを繰り返すことで、GoogleChromeにスクロール内の要素を再描画させてみた。

最初は挿入後に即削除をしてみたのだけど、全然ダメ。
Timeoutとか設定して、数秒後に削除としても状況は変わらず。
上記の方式に収まった。


同じ現象に悩む方がいたら、参考にどうぞ。


posted by ジャンボ at 23:00| Comment(0) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年10月09日

【[sysWOW64]のWOWってなんだ?】OCI.DLL が読み込めません。

BMIを17.0からいったりきたり・・・。
痩せすぎですね。ジャンボです。


今日も今日とて、ポチポチと開発をしていたのですが、
ある日を境に社内向けの一部アプリが
「DB 接続エラー:Oracle ライブラリ OCI.DLL が読み込めません。」
と言い、動かなくなった。

数日ぶりに起動したので、何が原因か全く読めない。
PATHを見たけど、その直下に OCI.DLL があるしな〜。
あれれ〜???

実はそのソフト、
案件の見積やら月次処理やら何かと重宝するので、
正直、動かないとまずいんですよ。はい。

上記に書いた文面とは裏腹、結構、焦ったジャンボさん。

原因はね・・・

そのアプリは32bit向けソフトだったんだけど、
いつの間にか、64bit向けのOracleクライアントを入れていた。

Windows7から64bitが標準になって、
「system32」直下に置くんじゃなくて、「sysWOW64」とかが表れて、
正直、いらない所で混乱しまくってます。

せめて、oci64.dll とかファイル名を分けてくれれば、
ピンときたのに・・・。


「OCI.DLL が読み込めません。」のエラーがあって、
PATHも通っているのなら、上記を疑うのも一つです。


自分用にメモ。


posted by ジャンボ at 00:00| Comment(0) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年09月27日

【まぢか・・・】CVE-2014-6271 ShellShock !!

息子と一緒にキョウリュウジャーのおもちゃを見ていた所、
息子のお勧めはザクトル。

なにゆえ、これなんだ?ジャンボです。


話題になっていますね・・・ShellShock (CVE-2014-6271)

Heartbleed」に引き続き、
影響範囲が広く、危険性も高くて、
正直、勘弁してくれ〜な脆弱性ですね。

少なくとも、RHELやCentOSでは、パッチ対応済みのバージョンが公開されているので、
それを充てれば大丈夫でしょうか。

組み込み式Linuxとか、
銀行系とかまぢでどうするんだろ・・・。

とりあえず、身近なPCで対応をしてみたのですが、
色々なサイトで、既存バージョンの確認方法で

 # /bin/bash --version

のコマンドが挙げられているのですが、
RHELやCentOSは個別に作られたパッケージのせいなのか、
パッチを充てた後も上記ではバージョン表記が変わりませんでした。

 # rpm -qa bash

で確認した方が良さそうです。

あと、パッチを充てた後の動作確認で

 $ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
 bash: warning: x: ignoring function definition attempt
 bash: error importing function definition for `x'
 hello

が良く挙げられているのですが、
9/26にリリースされたバージョンを充てると、

 $ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
 hello

と出て、warning 表記は少なくともウチのマシンでは出ませんでした。
(9/24 リリース分を充てた時は warning 表記が出た)

あくまで、確認ポイントは「echo vulnerable」が実行されない事。
なので、上記を注意しないと、動作検証時に更にパニックになりそうです。


(´Д`;)うえぇぇぇぇ・・・・。


posted by ジャンボ at 00:00| Comment(0) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年09月26日

【すっごい簡単・・・だけど・・・】mongoDB

嫁さんの入浴中の見張り番をさせられました。
眠い。だるい・・・。
一体、何に対して戦っているのだろう・・・ジャンボです。


今、流行り(ちょっと古いか?)のNoSQLの勉強で、
mongoDB」をいじくってみた。

正直、「Apache Solr」くらいの面倒臭さと頭の切り替えは覚悟していたのだけど、
めちゃくちゃ手軽。

各環境毎にコンパイル済のインストーラがあるので、
コンパイル作業等はいりません。

今回は Linux版 を使ってみたのだけど、

 1) Downloadした mongoDBファイル を解凍 (自分は /etc/mongodb 配下)
 2) データ用ディレクトリ(デフォルトは /data/db) を用意
 3) 解凍ディレクトリ配下の ./bin/mongod を実行

これだけで OK。

後は ./bin/mongo でクライアントを動かして、
対応するコマンドを入力すればよい。
コマンドもそこまで特殊じゃないので、理解は簡単そう。

ただ、mongoDB の得意分野や不得意分野が明確にあって、
基本、メモリ上にデータを保管して動かすタイプなので、
本当のビッグデータにはあまり向かないっぽい。

データ構成の制限がかなり緩いので、
柔軟性が高いとか、そっちの方がウリみたいですね。

事例をちょこちょこ調べた限りでも、

 ・互いに主導権を譲らなかったシステムの統合 とか
 ・必要なデータがぼんやりのまま進めたゲーム開発 とか

そういうのに向いているみたい。

・・・
・・・・・・
・・・・・・・・・

手段の一つとして、知識の引出にあるのは良いけど、
これメインでの仕事は胃が痛くなりそう・・・。


posted by ジャンボ at 00:00| Comment(2) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年09月19日

【需要は無いのかな?】CANVASの背景ごとデータ化したい時

昔やっていた「音楽ファンタジーゆめ」の動画を見た所、
「天国と地獄」に大ハマリの息子。
「バーイ、オッフェンバック!!!」と最後の部分まで叫びます。ジャンボです。



HTML5にちょっと色々と手を出しています。
HTML5といえば、やはり、CANVAS機能ですね。

画像の加工や合成をはじめ、
JavaScriptと組み合わせたお絵かき機能など、
詰め込めるとクライアントサイドだけで色々と出来そうです。

CANVAS機能には画像を取り込める機能もあるのですが、
それを背景に利用しようとして取り込んだ場合、
クリア時に背景も一緒にクリアされてしまう問題があります。

そこで、CSSのbackground-imageを使って、
CANVASの要素とは独立して背景を設定する事により、
その問題は解決できる訳です。


・・・で、それで問題なしかと思うのですが・・・
toDataURL()メソッドを使って、データ化しようとすると、
背景は真っ白で出力されてしまうんですね・・・。

まあ、canvasの要素にしていないので、当たり前といえば当たり前なのですが。

Webサイトで見る限りでは問題ないのですが、実画像とするには困ります。
調べても見つからず、何とか自己解決をしたので、以下に記載します。



【HTML5 CANVAS の描画内容を背景も含めて画像化する方法】

1) とりあえず、CANVAS領域を確保

2) 背景画像のURLを別途 hidden などで退避
  css の値を取る様にするのもアリなんですが、
  url("〜") の表記を取り除くのが結構、めんどいので、
  それくらいならと別途用意しておきました。

3) CANVAS領域に適当に作図

4) 画像出力直前に「globalCompositeOperation プロパティ」を「destination-over」に変更
 これで、作図していない領域のみ、画像を適用させることができます。

5) CANVAS領域一杯に背景画像を描画

6) 描画した内容をtoDataURL()メソッドで画像変換


・・・で、実際に作ったのがコチラ

HTML5 + Canvas非対応です





※ 実際に描画された画像です (右クリックでダウンロードしてみてください)。
右クリックでダウンロードできます


ソースはこちら



意外にとんでもなく、時間がかかりました。


posted by ジャンボ at 00:38| Comment(1) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年09月12日

【余白ってそういう意味?】ActiveReports でPDF出力時にページサイズが合わない時

iPhone, iPod touch, iPad mini の3台を持ってる訳ですね。
そんな訳でやった、
「白猫プロジェクト」の奇跡の1人で3人同時協力プレイ
右手でメインキャラを操作しつつ、
左手の人差し指で1台、中指で1台を連打連打連打!!!!
バカすぎです。ジャンボです。


ActiveReports のPDF出力で思いっきり詰まりました。
レポート設定はA4になってて、出力されたPDFもA4っぽいのだけど、
ページサイズを見たら、「230mm×297mm」・・・。

A4じゃねーよコレ。
(A4サイズは 210mm×297mm です)

Google先生を頼りに、色々調べたのだけど、全然ダメ。
「rpt.PageSettings.PaperWidth」やら色々指定しても、
何も変わんない。

で、ちょっとページマージンとかをちょこちょこいじくっていたら、
「223mm×297mm」ってなんか変わった。

どうやら、ActiveReports で言うページ幅って、
「レポート幅 + マージン幅」の事らしい。

余白を左右それぞれ 0.5inch, レポート幅を 7.27inch にした所、ちょうどピッタリになった。
(210mm = 約8.27inch)

レポート設定のA4って何なのよ?
っていうか、むしろ、余白ってそういう意味?

余白を広げれば広げるほど内容部分の幅が縮まるんじゃなくて、
横幅をどんどん広げるって何よ?


じゃあ、それが仕様かと思おうとしても、
縦は余白をどんなに変更しても変化せず。



腑に落ち無すぎ。
ActiveReports の PDF出力に悩まされた方は、上記をチェックです。


posted by ジャンボ at 21:56| Comment(1) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年09月10日

【IE・・・】Ajaxのクロスドメイン対策

自分が何か成長し続けるために、
何でも良いので、毎日続ける事が大事とのことです。
そんな訳で・・・
 ・WiiFit で「からだ測定」
 ・ブログの記事を書く
 ・息子との交換日記を書く
 ・「白猫プロジェクト」にログインする
をやっている訳ですね。
・・・絶対何か間違っている気がする。ジャンボです。


Ajaxで通信をするプログラムをペソペソ作っていたのですが、
異なるドメイン間でのAjax通信には色々と制限が入ってしまいます。
いわゆる、「クロスドメイン」という奴です。

Cross-Origin Resource Sharing (CORS)」という奴で、
W3Cで規定された、ドメイン間の通信の制限に引っかかる訳です。

クロスドメイン間の通信を許可する場合、
サーバ側のHTTPヘッダーに「Access-Control-Allow-Origin」を追加し、
値を「*」とすれば、OK です。

・・・
・・・・・・
・・・・・・・・・Google Chrome ならな。

でもね、IEじゃだめなの。
「Type Error : アクセスが拒否されました。」なんて言われる。

許可するゆーとるやんけぇぇぇ!!!!!
と思わず叫びたくもなりますが、まあ、毎度おなじみのIE独自仕様です。

検索してみても、異様に小難しいものが多く、少し四苦八苦しましたが、
Cross-Domain AJAX for IE8
という便利なツールがあったので、以下に記します。

 1) jquery.xdomainrequest.min.js をダウンロード
  「Cross-Domain AJAX for IE8」のサイトからダウンロードします。

 2) ページ内HTMLのHEAD部にダウンロードしたJSを読み込む様に記載
  下記は、ページHTMLと同ディレクトリにダウンロードしたJSファイルを設置した場合です。
  <script type="text/javascript" src="./jquery.xdomainrequest.min.js"></script>

 3) ajax通信に "crossDomain: true" のパラメータを追加
  例えば、下記のような感じです。

        $.ajax({
type: 'GET',
url: 'http://xxx.xxx.xxx/xxx',
cache : false,
crossDomain: true,
dataType: 'json',
success: function(json) {
・・・
},
error: function(request, status, thrown) {
・・・
}
});


これでOK。とりあえず、IE8での動作確認はしましたが、IE9等でも問題ないらしいとのこと。


やれやれ。


posted by ジャンボ at 21:53| Comment(0) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2014年08月29日

【陰謀?】富士通の開発コスト4割削減のアレ

近日、嫁が30歳の誕生日を迎えました。
夫婦そろって30代です。早いね〜。
ちなみに、嫁の20代最後に向けてやった事は
寝床に寄り添っての絵本の読み聞かせ

嫁の死んだ目が凄まじい。ジャンボです。

ちょっと前の話題になりましたが、
出ましたね・・・「Interdevelop Designer」
(企業URL: http://pr.fujitsu.com/jp/news/2014/08/28-1.html)

設計書からプログラムやテスト項目書を自動作成!!!
プログラマが不要になり、開発コストを約4割削減!!!

2番目以降の内容とか見たけどね・・・
これはアカンやつや

設計書といってもプログラム設計書だし、
こんなもん書ける人材はプログラマーしかおらんやん。
いらなくなるのはコーダーぐらいか・・・。

もうね・・・漢字Talk時代のAppleScriptとか色々思いだした・・・。
コードの中に "おのおのにして" とか書いてね・・・。

お偉いさんが日経の記事を見て湧き上がって、
SE, PGが地獄を見る姿が目に浮かぶ・・・。


まあ、どんどんCOBOL職人がいなくなってしまう中、
それでも基幹システムとしてはCOBOLが必要で、
COBOLを今更覚えてもらうよりは良いとか・・・

最終的にはJavaに移行したいのだけど、現行システムの連携上、COBOLである必要があって、
その時に直ぐに変換出来る様にしたいとか・・・

好意的に見れば、そんな案件には最適のツールかもしれないですね。


むしろ・・・
「Interdevelop Designer」使いという
新たな雇用を増やして、
富士通社員の空き要員対策にしたいんじゃ・・・
そんな陰謀を感じてしまう。


posted by ジャンボ at 23:31| Comment(1) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2011年07月23日

【Java】どうしてもIEがページをキャッシュする時・・・

もうすぐアナログ放送が終了しますね。
我が家は地デジ化していないため、
もうすぐテレビは見えなくなります。ジャンボです。



Struts と Ajax を組み合わせた画面をペソペソ作っていたのですが、
IEだとどうしてもページをキャッシュしてしまい、
ヒストリーバック時が上手く動かない事態に・・・。

HTMLのヘッダーとかに下記を記載したのですが

<head>
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
・・・(省略)・・・
</head>

全然ダメ。

意地でもキャッシュしやがる・・・。
Temporary Internet Filesに嫌味かのように作成される・・・。

ムキー!! (ノ ゚皿゚)ノ ==== ┻━━┻



そんな訳で、HTTPレスポンスを直接いじるようにしたら、
IEでもキャッシュされなくなった。
忘れない様に自分用にメモ。


<%@ page import="java.util.Calendar" %>
<%
response.setHeader("pragma","no-cache"); // (1)
response.setHeader("Cache-Control","no-cache"); // (1)
response.setDateHeader("Last-Modified", Calendar.getInstance().getTime().getTime()); // (2)
response.setDateHeader("Expires", 0); // (3)
%>


(1): HTTP1.0/1.1 の仕様にあるキャッシュ無効のヘッダーを付与
(2): 最終更新日を現在の日時に設定
(3): 有効期限を 1970/01/01 00:00:00 に設定



ローカル上では (1) のみで大丈夫でしたが、
間にキャッシュサーバが入った時で対応が変わる可能性があるので、
(2), (3) も念のため付与。

あと、HTMLのHEADタグ内にもキャッシュ無効の記載を入れた。



ふう・・・。
posted by ジャンボ at 22:21| Comment(0) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする

2011年07月02日

【Java】三項演算子

昨日、他の人が作ったプログラムをペソペソ修正していたら、
見慣れない記載があって、はて・・・?と一瞬悩んだ。


return hoge.equals(hoge2) ? RETURN1 : RETURN2;


こんなやつ。

これは、三項演算子ってやつで、
下記の場合、${条件式} が真の場合は ${式1} が評価され、
${条件式} が偽の場合は ${式2} が評価されるものらしい。

${条件式} ? ${式1} : ${式2}



たとえば、二つの変数 a, b があって、
大きい値の方を変数 c に入れたい場合はこんな感じ。


int a = 1;
int b = 2;
int c = (a>=b) ? a : b;


上記の場合は、下記で書いた事と同じ処理になる。


int a = 1;
int b = 2;
int c;
if(a>=b) {
c = a;
} else {
c = b;
}




三項演算子を使った方が、記載は短くなるし、
知っていれば、そこまで煩雑にならないから良いのだろう。

ただ、コードのレビューをした際には、
そこが条件分岐になっている事を見逃しやすくなったり、
そこまで一般的でもないから、あまり使わない方が良いかな〜って
思ったのだけれど、どうなんだろう・・・。
posted by ジャンボ at 14:56| Comment(0) | TrackBack(0) | 雑記:PC | このブログの読者になる | 更新情報をチェックする