月別アーカイブ: 2014年4月

iOS アプリの社内配布メモ

前々から、iOSやAndroidで業務アプリを作った場合、どういう配布方法になるんだろうなぁ〜と疑問には思っていたんだけど、機会あって調べてみたのでメモ的に残しておく。
ちなみに調べたのはiOSだけで、Androidに関してはまだ調べてないのでそれはまた別の機会にでも。

Enterprise Program

AppStoreに公開するために加入するプログラムとして 「Developer Program」 があるのは知っていたけど、社内アプリケーション開発用に別途、「Developer Enterprise Program」が用意されていた。

プログラム比較一覧表
https://developer.apple.com/jp/programs/start/ios/

それぞれで出来る事に関しては、上記の公式を見ていただくと分かると思うが、ざっくりというと

  • AppStoreに公開するならDeveloper Programでいいけど、社内用アプリケーションはDeveloper Enterprise Programに入る必要がある
  • Developer Enterprise Program は、社内配布は制限無く出来るが、逆にApp Store への公開の権限を有していない
  • Developer Program で実機にセコセコと一台ずつインストールしていくという手もなくはないが、登録が面倒だし1年の有効期限がある

と言うところか。

ここで、結構気になるのは「社内への公開」と言うところだ。
たぶんだが、Enterprise 契約時に DUNS 番号を必要としている事から考えると、DUNS で定義された範囲内でのみの利用と言う位置づけなんだろうな。

普段業務アプリケーションを開発している私としては、お客様先へお客様のニーズにあったアプリケーションを開発して提供というシナリオが真っ先に思いついてしまう。
ところが、当然の事ながらその場合は「社内」という枠を超えてしまう。

こういうケースの場合、お客様が Developer Enterprise Program へ加入して、そのコード署名を使ってビルドしたアプリケーションを使ってもらう必要がありそうだ。

つまり、実際に開発した会社に対して、開発作業をアウトソーシングするような位置づけなのかな。

そういう立場ならばそういう立場でもいいのかもしれないけど、そうなるとお客様にMacを購入してもらって、そこでビルドとかになりかねないのではないかなぁ。
でも、そのためだけにMac購入してもらうとか、どんだけ無駄なんだ・・・。

この辺り、実は私の理解が謝っている恐れは十分あり得るんだけど、もし理解が正しかったとすればとても非効率な話に感じる。

うーん、なんか間違っているかもしれないな

Elasticsearch JDBC river での取りこぼし

先日の Elasticsearch 勉強会では、これまで知らなかった事を色々と勉強出来た。
勉強会が終わってから、勉強会中に話されていたが自分で理解出来ていなかった事をあれこれと消化しようとしています。

当初はログをぶち込んで Kibana で見る事によって何かしらの解析を行う事が出来ないか?という事を考えていたんだけど、
Elasticsearch を生かそうとした時には全文検索もちゃんと生かした方がいいと考えを改めた。
特に、基本語化等の自然言語処理系のお話はこれまで携わっていなかった分野なので素直に面白いと思ったのです。

と言う訳で、これまでは RDB に入れて Like 検索を行っていたような情報を Elasticsearch に入れて、フロントを適当に作ってしまえば誰かしら(not 自分)が幸せにならないかなぁと考えた。

Kibana を使うにあたって、既に RDB からのインポートと言う意味では JDBC river を試した事があったのでそれを利用して早速データを入れてみたんだけど・・・・

件数があわない

たかだか2万件ちょっとのデータなのだが、取込んでみると1万8千件位になってしまう。
これではちょっと困る。

先日の勉強会で、Couchbase からのデータ移行時に処理が追いつかずに Elasticsearch が取りこぼすような話があったんだけど、、、うーん。
当然の事ながら、Elasticsearch のログには特にエラーのようなものは出ていない。

元となっているRDB側のデータは少し変なデータが混ざっているかもしれなくて、それが悪さをしているのかもしれないけど、それにしてもエラーも何もでないのは困る。
(別なところにエラーが出ていてそれに気づいていない??)

JDBC river のソースはあるので、そちらを少しいじってみようかなと考えています。
river プラグイン側の問題なのか、それとも Elasticsearch 本体側ではじかれているのか。
せめてそれくらいはどこかしらにメッセージ出してくれてもいいじゃないか

まぁ、それはそれとして、あれこれと使ってみる上でやはり調べる事が多すぎて追いついていない状態です。
と言う訳で、AmazonでKindle版をポチりました。
お世話になりまする

高速スケーラブル検索エンジン ElasticSearch Server
Rafal Kuc Marek Rogozinski
KADOKAWA/アスキー・メディアワークス
売り上げランキング: 3,439

Elasticsearch 勉強会 #4

少し妻に頼み込んで、最近気になっている Elasticsearch 勉強会に行ってきた。
いやぁ、頼もしい妻で助かります。(大事なところ)

今回、初めてこの勉強会に参加した訳ですが、ここで使われている技術のほとんどは、
現在の私の業務上ではそれほど使う事がない技術ばかり。
そういう事もあって、とても新鮮な印象を受けました。

恐らく、全体の概要と言う形では他の参加者が記事にされると思うし、私に取っては整理が追いついていない事柄も多々あるのでここでは割愛。
ただ、今後調べてみたりした事に関しては随時記事にしていきたいと思っている。

特にこれまで Kibana に目が行き過ぎていたけど、今日の発表中にあった文字の「基本語化」という処理などは、あったらいいなと思う場面は幾つかありそう。
それらのソリューションに対して、今回の Couchbase や Hadoop , Hive などの技術を組み合わせて対応するというのは、素直に面白そうだなと思える。

なかなかこういった勉強会への参加は、子供が小さかったり家が遠かったりすると
参加が難しい現実があります。
いや、その辺りはうまい事家族内で折り合いが付けられればいいんですけどね。

とはいえ、勉強してなんぼの業界ではあるので学ぶ機会と言うのは増やしていきたいですね。

logに関して考える日曜日

最近、先日も記事に書いた Elasticsearch、Kibana 周辺を見ています。
Kibana を知ったきっかけはただの偶然で、

Hacker News でElasticsearch 1.0 Release ! → Kibana ってかっこいいー!

という、目的とかそういうの何も考えない世界からのスタートでした。

所謂 Big Data ブームに関しては、私の業務的にはそれほど密接に繋がっている訳ではないんだけど、
もう少しデータを有効活用する事で随分と自分の周りは変化するのではないかとよく考えていました。

よくある話と言えばよくある話なのかもしれませんが、IT に携わっている割にデータや数値ではなく経験に頼って物事が進んでしまう事が多々あります。
ソフトウェアを提供する側が、もう少しソフトウェアに頼って行きたいところ。
ソフトウェアに使われるような形にはなりたくありませんが、利用出来るものは有効活用していきたいですね。

時間の長さからこれまで見ていなかったけど、Kibana に関しては公式のビデオが結構分かりやすかった。

kibana: data visualization made simple and beautiful
http://www.elasticsearch.org/webinars/kibana-made-simple/?watch=1

ただ、どちらかというと logstash 経由の Web アクセスログが対象で、公開 Web サーバーを取り扱っている訳ではない私にはどう使っていくかが完全には見えていない。
特に Kibana で面倒だと思うのは、可視化する事は出来るが、データの操作を行う事は出来ない点だ。
あらかじめ、Elasticsearch に対して分析が容易になるような形でデータを取込む必要があるので、独自のデータを対象とした場合にはその形式を決めるのに少し知恵を絞る必要がありそう。

確かにグラフへ変換が容易だったり、フィルタリングなどの仕組みは秀逸。
文字列の検索に関しても言う事は無い。
ただ、実際にそれらを分析するシーンにはいいけどよく話としてはありがちなレポートとして利用するとなると、どうしていいのかがよくわからない。

あくまで、分析や問題発見のシーンに利用する感じなのかな?
そもそも Web の世界のカックイイ人たちはレポートとかURLで示す事が出来ればOKなのかな。

それはそれで一つの形だとは思うし、そういう使い方でも十分だとは思う。
結局のところ、何を持って「可視化出来た」というかなんだろうな。

さてはて、データを有効活用したいという考え自体は間違っていないとは思うが、問題は何をどう活用すれば有効なのか?という基本的なところの考えが足りていない。

ホテルルワンダ

先週末に久々にDVDを借りていたのだが、なかなか見る時間を作れずにいた。
ようやく、夜更かしをしてみる事が出来た。

ホテル・ルワンダ [Blu-ray]
Happinet(SB)(D) (2012-11-02)
売り上げランキング: 15,068

話には聞いた事があって、見たいと思っていたのだがこれまで手が出てなかった。
涙が出るような感動ものではないんだけど、でも考えさせる映画だと思う。

基本的に日本のニュースと言うのは国内の話が多すぎると最近はよく感じる。
それは、結局のところ日本人に対してニュースを提供しているだけだからなんだろう。

多種多様な人がいる国ではこうはいかないんだろうな。

ホテルルワンダが題材としている大量虐殺は1990年ごろと最近だが、
そういう話題はあまり当時、記憶に無い。

もちろん、当時と言えばまだ私も中学とか小学生だったわけだから純粋にそういう話に
耳を傾けていなかったといえばそれまでかもしれないが。

アフリカに限った話ではないが、アフリカの事を余りにもよく知らない。
たまたまかもしれないが、今見たいと思っている「マンデラの名も無き看守」も
アフリカ題材だ。

マンデラの名もなき看守 [DVD]
ポニーキャニオン (2009-04-24)
売り上げランキング: 45,812

ElasticsearchにCSVでデータ登録

最近、こそこそとElasticsearchを触っています。

とりあえず、手始めに簡単なところからと思い、気象庁のHPから千葉の気温に関するCSVを取得。
どんな風に見えるかをやってみようかと。

過去の気象データ・ダウンロード
http://www.data.jma.go.jp/gmd/risk/obsdl/index.php

注意しなければいけないのは、CSVファイルがダウンロードされる割にそのまま使える形になっていません。
微妙に整形しないといけないし、最初の行をタイトルとすると列名が重複する事になります。
この辺りは手操作で修正する形ですね。

Elasticsearchにデータを流し込むのはcsv_riverというプラグインを使いました。

CSV River
https://github.com/xxBedy/elasticsearch-river-csv

流し込む事自体はそれほど苦労せずに出来たのですが、Kibanaにてヒストグラムを表示しようとするとエラーになりました。

実は、以前にOracleデータをJDBC Riverを使って入れた時はこんなエラーにならなかったので一瞬何が起きたのか分かりませんでした。

ただ、Kibana上からデータをJSON形式で見てみると

これ、データが文字列として登録されているように見える。
つまり、自動判別されてしまうもしくは、CSV Riverがすべて文字列として登録してしまっているので、フィールドの定義をきちんとしてあげればOKになるはず。
ただ、CSV Riverのプロパティを見てもそれっぽいところが見つからなかった

そこで、困った時の神頼みと言うことでおもむろにTwitterへ投稿したら

 

反応してくれる人がやはりいた。ありがたい。

私はJDBC Riverの時にうまい事判定してくれたので、データの登録側で何かするのではないかと考えていたのだが、
あらかじめElasticsearch側に定義を作っておく形を取るようだ。
もしかすると、JDBC RiverではRDBからそういう情報を抜いて、あらかじめマッピング定義をしているのかもしれない。
違うかもしれないけど。

さて、何となくの仕組みは理解したが、リファレンスをじっくりと読む事が苦手な私はとりあえず見よう見まねでやってみた。

curl -XPUT localhost:9200/temperature/chiba/_mapping -d ‘{
“chiba”:{
“properties”:{
“average”:{“type”:”double”},
“high”:{“type”:”double”},
“low”:{“type”:”double”},
“date”:{“type”:”date”, “format”:”yyyy/MM/dd”}
}
}
}’

こんな感じかな〜?と思ってやってみたが、エラー。

{“error”:”MergeMappingException[Merge failed with failures {[mapper [average] of different type, current_type [string], merged_type [double], mapper [low] of different type, current_type [string], merged_type [double]]}]”,”status”:400}

マージに失敗?
確かにリファレンスには、マッピング情報が定義されてから登録されるデータに適用されると言う話だったので、一度全部データを削除してから定義してみようとしたけど

{“error”:”IndexMissingException[[temperature] missing]”,”status”:404}

INDEXそのものを削除してしまってはいかんか。
面倒だったけど、もう一度INDEXを作り、その後INDEXを残してTYPEを削除。
再度、マッピング情報を登録してあげると・・・

ヒャッハー

なんて見た目がつまんないデータなんだー!

今日はここまで。
なんか凄い疲れた

高速スケーラブル検索エンジン ElasticSearch Server
Rafal Kuc Marek Rogozinski
KADOKAWA/アスキー・メディアワークス
売り上げランキング: 24,547

お絵描き

庭の花壇に植えたチューリップがだいぶ咲いてきたので、今日は少しお庭でお絵描きを。

 

酷いもので二人とも最初は被写体に背を向けて絵を描き始めた。
最初はよくあるデフォルメされたようなチューリップを書いていた長男も、何度か

「うまく書けなくてもいいから、見たまま書いてごらん」

と言ったり一緒に花びらの数を数えたりしていたらちゃんと見て描くようになった。
ぱっと見ではチューリップとは分からなくても、一生懸命描いた感じが出るいい絵が出来たと思う。

長女はというと、やはりまだ絵と言うのにはちょっと届かないような感じで描いて、
すぐに飽きてしまって庭を駆け回っていた。

日々子供達と接していると、正直長男が長女の歳だった頃。
つまりは、3歳だった頃にどうだったのかというのがはっきりと思い出せない。
うーん、もう少しお兄ちゃんはちゃんと出来た気がするんだけどなぁと思ってしまう。

妻に言わせると、「こんなもんだったでしょ」という感じなのだが・・・。
知らず知らず、長女に甘くなっていそうで注意するあまり、かえって厳しくなっていたりと
よくわかんない状態になっていたりします。

Kibana

多少、今更感はあるかもしれないけどKibanaを触っている。

会社では、所謂ビッグデータとして取り扱われるようなデータに携わっている訳ではないんだけど、
それでももう少しデータを有効活用する事が出きるんじゃないかと考えているからだ。
Kibanaを選んだのは、実を言うとただの気まぐれなので、実はもっと適したものがあるかもしれない。

でも、何となく見た目がかっこいい気がしているのでそれほど後悔はしていなかったりする

正直、Elasticsearchに対してのデータの挿入だったり、Kibana上でもう少しこういうダッシュボードが作れないものかと思うところが結構ある。
調べながら調べながらなんだけど、目的を忘れないようにしながら進めていきたい。

高速スケーラブル検索エンジン ElasticSearch Server
Rafal Kuc Marek Rogozinski
KADOKAWA/アスキー・メディアワークス
売り上げランキング: 12,804

ご褒美はなに?

私は酒もタバコもしない。

ガツガツ節約する方ではないが、どちらかというと自然と節約してしまうほうだ。
服を特段買う訳でもないし、何かしらアクセサリーなりを買う訳でもない。

趣味としては、ランニングや家庭菜園などなので、多少のお金はかかるが、
それでも趣味の中ではお金がかからない方だろう。

時々、何かを目指して。いや、目指すと言うよりはご褒美を自分で設定して頑張るというやり方を見かける。
特に酒を飲む人は、プロジェクトが終わったり一区切りした後の飲みを楽しみにしているようだ。
聞いた訳ではないけど、うちの社長もそうじゃないかと思っている。
(毎日飲んでいるらしいから、ご褒美とか無いのかもしれないけど)

別にご褒美が必ずしも万人に共感されるようなものでなくても。
それこそ、別にモノじゃなくてもいいとは思うけど、でも、そういうのがあった方が
頑張るいいわけに使えるかもしれないと思っている。

そう、結局のところはつらい事を紛らわすいいわけなんだろう。
でも、何も無いとそれはそれでやっぱりくじけてしまうかもしれない。

ところが、”必要なもの/欲しいもの”は思ったら結構買ってしまっているし、
結局買わなかったものと言うのは”必要の無いもの”である事が多い。

貧乏人根性が染み付いてしまっているせいか、こういう時にご褒美がぱっと出てこない。
出来れば、それを手にする事で、よりかっちょよくなれるものがいいな。

何となくは思い浮かんではいるが、さてはて。
妻をどうなだめすかしたものか

Github製エディタ「Atom」を触ってみた

少し前に話題になった、Github製のエディタ「Atom」がようやくbetaテストの順番がきた。

現時点では、対応環境はMacのみなので、会社では試す事が出来ない。
残念。

見た目の第一印象は、どう見てもSublimeである。
SublimeではPluginで使っていたMarkdownのPreviewが普通に選択でき、
さらにエディタ内で見る事が出来るのは結構使いやすい気がする

また、gitを使っている場合、リポジトリに対する情報も下部に表示してくれているので
何を編集しているのかを確認する事が出来る

gitに関しては、あまり手になじんで使っている訳ではないけれど、もう少し使えるようになりたい。

まぁ、gitがいくら使えたとしてもそもそもの開発が出来なければ意味が無いのでそちらの方も
もう少しなんとかしていきたいところだ。

仕事での役割として、コードを書くというシーンがドンドン排除されていってしまっており、
それはそれで仕方が無いとは思うが完全に無くなってしまう事は避けたいと思っている。

今後、どういう形での関与が一番自分に取っていい事なのか。
見極めていきたいところだ

GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)
大塚 弘記
技術評論社
売り上げランキング: 179