リンクじゃなくてドメインの一部を載せるだけならgoogle広告的にも問題ないだろうと推測。ソフトアダ○トサイトだからね。
｢bwhsearch｣っていう名前のサイトを運用しているんだけど、今回のwikiのダンプデータ適用でレコード数=｢BWHサイズの紐付けできた有名人のデータ｣が8000人を超えた。
昨年末に公開した当初は7000レコード切ってた事を考えるとやっぱりwikipediaってすごい。また寄付しとこう。
wiki自体も次のダンプでは200万レコード超えると予想。って今見たら次のダンプ20151202始まってるw
色々趣味プログラミングしながら、同じPC酷使してスクレイピングbot何発も飛ばしてるんだけど、一昨日ようやくenwiki人物データ40万超のレコードが一周した。
最初のレコードが8月10日だから約4ヶ月かかったw そんで英語版｢BWHサイズの紐付けできた有名人のデータ｣数は、｢5476｣…
なんか個人情報?プロフィール?に対する考え方が日本とは根本的に違う。
スクレイピングアルゴを試行錯誤してて感じたのは、日本は(有名人について)｢本人がいやがる(と意思表示した)情報は公開しない｣って感じだけど、欧米は｢本人が公開した、あるいは公開に明確に同意した情報以外は公開しない｣って感触。訴訟問題でもあるのかな。せっかく集めたデータだけど、運用にはもうちょっと検討が必要だな。つーかこのレコード数では処理見直してもう一周しないといけないか。
さっき初めてのAndroidアプリ公開した。2ヵ月半かかった。いくら趣味とは言え、我ながらコーディング遅いよなー。次は一旦webサイトのメンテナンスか、もう一本アプリ作ってみるか。
15年12月4日(金)‡12時59分33秒 ‡
ただの自分向けメモ
今日は1時間ほどPC作業。
ようやくAndroidアプリの骨格が出来てきて、懸案のカメラ(画像)処理の部分に昨日から取り掛かる。
特徴色(DominantColor)抽出に再挑戦。前回はwebアプリで色々やってみたんだけど、結局途中であきらめて｢なんちゃってMedian cut｣でお茶を濁して終わり。
どこがなんちゃってかというと、赤系のワンポイントの色が上手いこと拾えなくて、試行錯誤の末R値だけ優遇するという悲惨な結果にw
今回はoctreeアルゴでやってみようとして色々ためしてる。何故か前回はたどり着けなかった｢Jimi｣ってライブラリを使ってJava環境ではある程度実現できたんだけど、
そのままではAndroid環境では使えない。Awt系API使いまくってるからね。
で、｢無理やりAwt」｢ImageMajikに路線変更｣｢そのためだけにunity｣などなど色々ググりまくって調べて方策を練ったんだけど、最終的にはJimiのソースコードまじめに読んで自分なりの実装を組んでみることにした。コピペプログラマーらしからぬ決断だけど、さすがsun様、コードがきれいで追いやすい。プログラミングの勉強になりそうだし、しばらく頑張ってみます。
今日、香港からトルコ語配列のThinkpad200向けキーボード届いた。たった3000円くらいで2週間で新品が届くんだからやっぱりThinkpadって良いなと思った。
換装はアメリカからヒートシンク(ファン付き)が届いてから。こちらは送料込みで1500円くらいw
15年11月20日(金)‡16時07分29秒 ‡
未分類
10月は2回dump取りあったんだなー。ボランティアの皆さんには足を向けて寝られない。僕にできるのは時々の寄付だけだ。あー。
未だにAndroid入門。遅々として進まず、アプリ公開なんてまだ先の話。
ここ2～3日はMediaPlayerとAudioTrackのどっちを使うかで試行錯誤。
結局今はAudioTrackで組んでいくことになったんだけど、
- MediaPlayer
- メリット
- UIと親和性高い。
- 組むのが簡単。ネット上の情報も豊富
- メディアタイプを選ばない。mp3はもちろん、FLACもそのまま再生できる
- デメリット
- 音データを細かく引っ張り出して処理するのが難しい。定番としては、Visualizerクラスを使う(それ以外の方法見つけられず)のだけど、各種eventListenerで拾って処理していくので、自前でThreadとか作らなくて良い分簡単なんだけど、当然データ取得タイミング(=データサイズ)を自由に設定できない。
- Visualizerで取得できるデータがいまいち。周波数もずれてるような。色々やっても400Hzが344Hzとか出る。そのズレの修正アルゴが分からない。それに最大値と最小値にも制限がある。簡単なイコライザー的な処理や、ヴィジュアライズ処理にならそれほどシビアに音の周波数拾わなくって良いんだろうけど。その結果一切GCが走らないのは大きなメリットだけどw
- AudioTrack
- メリット
- byte配列でデータをやり取りするので途中で抜きやすい。というかデータ処理部分は普通にFileInputStreamとか使うので自由度高い&Java使いには分かりやすい。
- 一応各種eventListenerも揃ってる。情報見つけるの難しいけど。
- デメリット
- Waveファイルしか再生できない。それ以外のタイプは事前に変換処理必要。またメモリが圧迫される…
- AudioTrackの情報が少ない。2011年の情報とか未だに重宝するのはAndroid開発では珍しいと思う。
- GC走りまくり。(それはお前のプログラミング能力ががが)
ということで、現状の知識を整理。後で読み返して間違ってることがあったら実装内容変えよう。
しかし、今までもwebサイト構築はTomcat+DWRで基本やってきたんで、Java使ってきたと思ってたけど、Androidみたいに全部Javaで書いてると改めて発見することが多い。継承とかオブジェクト(クラス)志向とか知識としては持ってたけど、きっちり実践してたわけではない概念?をAndroidの場合ある意味強制されるからより理解が深まる感じ。以上。
15年11月6日(金)‡16時17分43秒 ‡
ただの自分向けメモ