桃缶食べたい。

Hadoop を Pseudo-Distributed Mode で試してみた

chocolablog ver 0.8 にアップデートしました

sqlite3 で SELECT 結果の行番号を取得する

Ionic 2 を試してみた

Maven Resources Plugin の Filtering 機能を使ってみる

Eclipse プロジェクトの再読み込みなしでリソースを更新する

chocolablog ver 0.7 にアップデートしました

Bitbucket プロジェクト用アイコン作ったよー

Python nose でユニットテストを書いてみた

Dynabook KIRA V634 を買ったので Fedora 20 をインストールしてみた

Eclipse Project Loader

画面解像度が高い

薄い、軽い

メモリ 8 GB

ストレージは SSD のみ

Haswell 搭載

液晶パネルはノングレアではない

大量データの分析で威力を発揮するものの、癖が強すぎて適応分野の選定が難しいと一部で話題になっているらしい Hadoop ですが、これまでなかなか触る機会がなかったため、少し触ってみることにしました。実際にうまく使いこなせている人達は企業でさえも 10 〜 20 社あるかないかとか言われてるらしいですが、個人的に何も知見がないため、何を言われていても「へ〜そうなんだ〜」と返すしかありません。エンジニアとしてそんな状況もどうなんだと思ったので、ちょっと遊んでみることにしました。

ちなみに、Hadoop には大きく分けて Standalone Mode、Pseudo-Distributed Mode、Fully-Distributed Mode の 3 つの構築方法があるそうで、公式ドキュメントにちょっと遊んでみるなら単一ノード構成がいいよと書かれていたので Pseudo-Distributed Mode で遊んでみることにしました。ざっとドキュメントを読んだ感じ、Standalone Mode　は分析用のロジックを動かしてみるだけで、Hadoop の特徴らしい HDFS なんかにまったく触らず終わりそうだったので、やめておきます。分析ロジックが jar なので、自分で書いた jar を試しに動かしてみるには Standalone Mode　が良さそうです。

なお、今回はらしいらしいという記述が多くなっていますが、分散処理は奥が深そうで、現時点では断言できることが少ないためです。ブログにはなるべくしっかりとした情報を書きたいのですが、これに関しては仕方ないかなと思います。ご了承ください。
続きを読む WEB 技術, Hadoop コメント (0) 2017/03/29 18:42:18

Python 製自作ブログの chocolablog を ver 0.8 にアップデートしました。

前回のバージョンアップは 2014 年 11 月 3 日でした。2 年と 3 ヶ月ぶりくらいですね。
その間特にリリースを迫られるような理由もなかったのですが、最近になって大きめの追加機能を実装することになりました。

……こうやって趣味で書いてるコードを日の当たる場所に出すというのも随分ひさしぶりな感じがしますね。
以前よりも家でコードを書くことが減っているのこともありますが、まああまり後先考えずに書きたいコードを書いていこうかなと思っています。

そして恒例の謎スクショ。
この手の記事は毎回何の画像を貼ろうかすごく悩みます。

続きを読む chocolablog 開発コメント (0) 2017/02/13 19:59:53

SQL を使っていると、SELECT した結果セットの各行について、結果セット中での行番号を知りたい、という場面にたまに遭遇します。こういうやつです。

SELECT * FROM books ORDER BY price;
id          title           price     
----------  --------------  ----------
3           Art with Basis  600    #行番号: 1
4           Book List       990    #行番号: 2
1           Civilizations   1000   #行番号: 3
2           Dream Post      1200   #行番号: 4
5           El sant magina  1500   #行番号: 5

一般的な一覧系の処理では先頭から N 件とりだすことが多いので、OFFSET で取り出した件数を指定すれば行番号を意識せずに続きをとることができます。

ただ、ID からその行の結果セット中での位置を知ろうとすると、やはり行番号が欲しくなってくるのです。結果セットがソートされていたり、ソートされているカラムがユニークでなかったりするとかなり面倒なことになります。特定の ID の行の前後 3 行ずつを取りたい、というような時に困ってしまうわけです。

結果セット中での行番号を取得するために、Oracle では ROWNUM 擬似列や ROW_NUMBER() 関数が用意されているそうです。
また、MySQL ではユーザ定義変数を使うことで、SELECT 時に行番号を計算し、出力することができます。

SET @rownum := 0; SELECT *, (@rownum := @rownum + 1) FROM books;

しかし sqlite3 では ROW_NUMBER() 的な機能もユーザー定義変数的な機能も実装されていないので、これらの方針をとることはできません。ネットを見てみると以下のようなクエリで計算している例がありますが、境界値として WHERE 句で使っているカラム（ここでは id カラム）がユニークでない場合、境界値として機能しないため、厳密な行番号はとれません。

SELECT id, title, price, (SELECT COUNT(*) FROM books b2 WHERE b1.id >= b2.id) AS rownum FROM books b1 ORDER BY rownum;
id          title           price       rownum    
----------  --------------  ----------  ----------
3           Art with Basis  600         1         
4           Book List       990         2         
1           Civilizations   1000        3         
2           Dream Post      1200        4         
5           El sant magina  1500        5

※ ORDER BY rownum は見やすさ重視のためにつけたもので、必須ではありません。

もう 1 点、この方法では 1 行毎にサブクエリで行番号をカウントするため、参照性能に問題があります。MySQL では悪名高き DEPENDENT SUBQUERY にあたるためです。
続きを読む WEB 技術コメント (0) 2017/02/01 19:45:13

あけましておめでとうございます。
年の瀬に Maven Resources Plugin の記事を書き、お正月だからとだらだらしていたら 3 年経ってしまいました。

それはともかく、少し時間ができたのでスマホアプリの技術でも触ってみようかと思い、Ionic 2で遊んでみました。今回は Ionic 2 のインストールから空のプロジェクトを作ってブラウザから動作確認をし、独自の新ページを追加するところまでです。

スマホアプリというと Android や iPhone の実機をつないで都度ビルドしながらデバッグする、というイメージが強いですが、Ionic 2 などの最近のフレームワークは WEB ベースの技術が組み合わさっているため、実機がなくてもブラウザから動かすことができます。簡単なページは JavaScript や CSS を使って WEB アプリ的に実装し、それで実現できない部分は端末固有の実装として Java や Swift で書いたプラグインに任せよう、という設計思想だそうです。確かに、ゲーム系でないスマホアプリは、突き詰めてしまえばボタンを押しながら画面遷移していくだけの事が多いので、WEB アプリに似せた開発ができるというのは効率的なのだと思います。

Ionic 2 は Cordova というマルチプラットフォーム向けのフレームワークに覆いかぶさる形で作られています。なので Cordova 同様、Ionic 2 で書いたアプリも Android や iOS 用にビルドすることができます。また Ionic 2 の特徴として、AngularJS と切っても切れないほと密接に連携していて、その特徴を色濃く受け継いでいます。データとデータを取り扱うロジック部分をビューから切り離し、そのデータをビューに対して自動的に埋め込ませることができます。このあたりの考え方は、WEB アプリを作ったことのある人には、馴染みの深い MVC モデルの応用のように聞こえますが、MVC モデル自体がデスクトップアプリケーションに端を発しているものなので実際は逆輸入なのかもしれません。

さて、今回の目標としては、似非商品検索アプリを作ってみようと思います。トップ画面から検索画面に遷移し、そこで入力したキーワードから、キーワードを商品名に含む商品の一覧を表示する、という感じの動きです。ただし、今回は実際に DB や WEB サービスから検索するわけではなく、キーワードを商品名っぽく加工して表示するだけとします。
こんな感じの仕上がりを目指していこうと思います。
続きを読む WEB 技術, Ionic 2 コメント (0) 2017/01/24 19:19:22

Maven Resources Plugin は必要なタイミングで、リソースファイルを特定のディレクトリにコピーする機能です。
Maven プロジェクトではコンパイルされたクラスは target/classes に配置され、実行時には target/classes に classpath を通せばよいように設計されています。（jar や war にパッケージされるのも targaet/classes 配下のファイルになります。）つまりコンパイルが走るタイミングで src/main/resources ディレクトリ下のリソースも classpath の通る target/classes に配置してやる必要があり、その役割を担うのが Maven Resources Plugin なのです。

Maven Resources Plugin には Filtering と呼ばれる機能があります。これにより、リソースファイルをコピーする際に、リソースファイル内の文字列を動的に書き換えた上でコピーすることができます。
続きを読む Maven コメント (0) 2014/12/31 11:37:58

Eclipse 外で HTML ファイルや prpperties ファイルなどを修正した場合、Eclipse プロジェクトを都度再読み込み（更新）し、修正したリソースファイルを Eclipse に認識させてやる必要があります。WEB アプリ開発などでは頻繁に HTML ファイルやテンプレートファイルを修正するため、その都度 Tomcat を止めて Eclipse プロジェクトを更新する、というのは非常に非効率です。Java クラスについては、メソッドやクラスの定義が変わらない限り Servlet コンテナを止める必要はないのですが、リソースファイルの修正にはまだまだ弱いのが現状です。

リソースファイル変更時に Eclipse プロジェクトの更新が必要になるのは、Eclipse プロジェクトのレイアウトとして、リソースファイルが配置されるディレクトリと実行/デバック時に Eclipse がクラスパスを通すディレクトリが異なるためです。例えば Maven プロジェクトでは、リソースが配置されるのは src/main/resources ですが、Eclipse がクラスパスを通してくれるのは target/classes になります。Eclipse は Eclipse プロジェクトの更新時などにリソースファイルを src/main/resources 下から target/classes 下にコピーし直すのですが、逆にいうと、いくら src/main/resources 下のリソースファイルを書き換えても、target/classes 下にコピーされない限り（クラスパスの通ったリソースファイルは古いままなので）プログラムはリソースとして読み込むことができません。
target/classes 下のリソースファイルを修正すれば一応クラスパス上のリソースを変更することはできますが、次にリソースディレクトリからリソースファイルがコピーされた時に上書きされて巻き戻ってしまいます。

これを解決するため、読み込むリソースファイルの場所を任意のディレクトリに切り替える仕組みを作ってみました。

https://github.com/momokan/eclipse-project-loader (github)

Eclipse Project Loader　を使うことで、クラスパス内のリソースファイルをクラスパスの通っていない別のディレクトリから読み込むことができるようになります。そのため、プログラムがリソースファイルを読みにいくたびに、最新のリソースファイルにアクセスすることができるようになります。

続きを読む Eclipse Class Loader コメント (0) 2014/11/29 19:41:00

Python 製自作ブログの chocolablog を ver 0.7 にアップデートしました。

前回アップデートが 2013 年 5 月 2 日ということで、今回も 1 年以上の間を置いてのバージョンアップとなります。ver 0.6 ではシステム管理側でいろいろ機能を追加していきましたが、ver 0.7 では新機能の追加はほとんどなく、細かな機能拡張と不具合修正のみになります。

ver 0.6 で実装したスパムコメントのフィルタリング機能は、1 年半くらい運用してみてまずまずの成果をあげているようです。フィルタリング機能は 2 段構えなのですが、第 1 障壁を超えてきたコメントスパムが 2 件だけでした。その 2 件も察するに、スパマーさんが試しに普通にコメントしたんじゃないかという感じの内容だったので、第 1 障壁の役目としては問題ない範囲になります。

スパムコメント対策に限らず、システムとしてはだいぶ成熟してきた感が強くなってきているので、今後もこんなペースでの開発が進んでいくことになるんじゃないかと思っています。当面は大きめの機能追加の予定はありません。（単にネタ切れとも言う）

続きを読む chocolablog 開発コメント (0) 2014/11/03 15:24:13

あのバケツ見てるといつもこれを思い浮かべます。

続きを読むコメント (0) 2014/06/22 18:58:28

chocolablog は Python で書かれていますが、これまであまりユニットテストの整備に時間を割いてこれませんでした。しかし初期バージョンの開発から 2 年以上が経ち、その間に何度か sqlite3 をとりまく DB アクセス部分を中心に、処理を書き換えています。他のロジックはともかく、コアとなるコードはしっかり動作を担保しておくべきだなと感じ、ユニットテストの整備に着手することにしました。

Python では 2.1 移行、ユニットテストフレームワークとして unittest が組み込まれています。これは個人的に大好きな JUnit をベースに作られているそうです。ただネット上で目にした Python 系のオープンソースプロジェクトでは、この uniittest モジュールではなく nose というモジュールを使ってテストコードが書かれていました。nose を使うとテスト失敗時にデバッグツールの pdb を自動で起動してステップ実行ができたり、ソースコードのカバレッジレポートを出力できたりと、テストの書き方以外の面でもいくつかメリットがあります。
今回は unittest よりさらに簡単にユニットテストを書けるらしい nose を使い、ユニットテストを書いてみました。

続きを読む python コメント (0) 2014/05/29 08:02:50

薄くて軽くて高性能なノート PC が欲しくなって、Dynabook V634/W7K を買ってみました。Intel 第四世代 CPU はまだ買ったことがなかったので、これが Haswell 初体験です。

今まで MacBook Air を使っていたので、PC 選びの基準は MacBook Air でした。MacBook Air はコストパフォーマンスを含めてすばらしいマシンだと思いますが、画面解像度の高さが 900 ピクセルしかないことと、Fedora 20 で英数・かなキーを認識してくれないのが数少ない残念ポイントでした。それでなんとなくネットを見ていたらこのマシンが目に入り、衝動買いしてしまいました。
やったね！これからはお出掛け前の気分で MacBook Air と Dynabook V634 を選べるね！

Dynabook はハードウェアデザインもかなり MacBook Air を意識して作られたようです。キーボードの感じなんかは特に MacBook Air を追いかけてる感じがしてます。

Dynabook V634 は、私が見かけた PC の中では私のマシン選びの条件を一番多くクリアしていました。

画面の物理サイズは、Dynabook V634 の高さは MacBook Air よりひとまわり小さいです。
画面解像度が 2560　x 1440 なので、UI が随分小さく細かくなったように感じます。
だがそれがいい。これだけ解像度があるとタイトルバーがやたら太い GNOME3 を使う上でとても安心です。

外出時の持ち運び用途なので重要。MacBook Air が重く感じてきたのでそれより重いのは NG。
MacBookAir が 1.35 kg、Dynabook V634 が　1.12kg　なので若干軽いらしいです。持ってみた実感として軽くなった印象は…少し軽くなってる？？

開発で DB やら eclipse やらいろいろ動かすので積めるだけ積みたい派です。
Dynabook V634　は　8GB （おそらく DDR3）なので、悪くはないレベル。次のモデルではぜひぜひ 16 GB とか検討して頂けると泣いて喜びます。

MacBook Air の高速環境に飼いならされた身としては SSD もはずせないポイント。
けれど容量にはそれほど要求はなく、120 GB あれば十分でした。Dynabook V634　の SSD は 256GB なのでかなり潤沢です。
最近のメーカー品だと HDD とのハイブリッド構成なんかもあるそうですが、ディスクは音や重さを考えると返ってないほうがいいのかなと思います。

CPU も最高クラスが欲しいわけではありませんでしたが、電源消費が改善されたと噂の Haswell であることは条件でした。Dynabook V634 は Intel Core i7-4500U です。
Dynabook V634 はバッテリーの持続時間が長いことでネット上では大きく扱われているようですが、この辺は Haswell の功績が大きいのではないでしょうか。ちなみに、私の買った V634/W7K の駆動時間は 14 時間です。同じ大きさで画面解像度がひとまわり小さい V634/W6K は 22 時間連続稼動するそうです。

<<2018, 4>>

公式サイトには SuperView LED液晶とあります。パネルの種類はあまり詳しくないのですが、ノングレアではないです。
照明が綺麗に写りこみます。人によってはすごく気になるポイントだと思います。
他のスペックが満足できるレベルだったので、この点は妥協しました。開発用途として使うつもりなので画質にはそれほどこだわらないので、気になるようならアンチグレアシートなど検討してみようと思います。

ということで、Dynabook V634 は軽い・早い・画面が広いという私の中の条件を納得できるところで達成していました。

ただしお値段は日本メーカー製だけあってだいぶ高いです。
ハードウェアスペックやマシン自体の作りを比較すると MacBook Air の品質の高さを再認識させられます。あの値段であのスペックとなれば、OS うんぬんの話は抜きにしても、人気が出ないはずはないです。この辺はもう少し日本のメーカーにも考えて欲しいところ。
続きを読む Linux, お買い物コメント (0) 2014/05/25 19:49:45