きまぐれ日記: MeCabがiPhone,OSXに載っていると言うのは止めようと思う
iPhoneのSDKの条項に変更が加わり、Flashのクロスコンパイルを含む 純正開発ツール以外で作成されたバイナリの配布が禁止となるようです。 世間でも散々言われていますが、この変更は正直とても残念です。 Apple的には「製品のクオリティーが保てないから」という理由だそうですが、 Windows版iTunesが意味もなくQuickTime入れたり、Windows非標準のUIを 使いまくっていて、お世辞にもクオリティーが高いとは言えないのを棚にあげて、 クオリティー云々と言い訳できるのでしょうか。アプリなんて所詮 玉石混淆。決めるのはユーザです。 MeCabは以前GPL/LGPLでした。Appleを含む複数の方からこのライセンスでは 使いにくいと言う指摘をうけ、前職の同僚と協議をしながらBSD/LGPL/GPL のトリプルライセンスにしたという経緯があります。結果としてこの変更は うまく
きまぐれ日記: ファンに支えられるプロダクトとユーザにdisられるプロダクト
世の中には熱狂的なファンに支えられるサービスやプロダクトがあります。 Appleファン、Googleファン、日産ファンといえばピンときますが、 Microsoftファン、Yahooファン、トヨタファンと言うとあまり聞きません。 ファンに支えられることは素晴らしいことですが、ファンが多いからといって プロダクトの完成度やクオリティが高いとは限りません。私がファンになるのは アイドルぐらいで、ソフトウェアに関してこれとってファンはないのですが (いやむしろありとあらゆるプロダクトを触ってみては〇〇はウンコと言っていますが...) 某製品の改善点をそのファンに伝えると「愛が足りない」とか 「そんな所誰が気にするのか」とかわされます。 あるプロダクトのファンになるかどうかは、中の人がどれだけカリスマ性があるかとか、 彼らの長期的なビジョンや理念がどれだけ魅力的かと言ったハイレベルなところで 決まり
きまぐれ日記: 「ハードウェア」プログラマと「ソフトウェア」プログラマ
プログラマ・ソフトウェアエンジニアと呼ばれる人間には、 2つのタイプがあるような気がしています。 ひとつは、もともと機械いじりやハードウェアが好きな 「ハードウェア」プログラマ、もう一つはその反対の「ソフトウェア」プログラマ。 それぞれどういう特徴があるか、独断と偏見でまとめてみました。 (私自身ハード出身なのでそちらに偏重していますw ) 「ハードウェア」プログラマ 「最適化」という言葉が好き 外的な制約(メモリ/速度/ディスク)がある方が燃えるし、真の能力を発揮できる 逆に制約がないと何していいのかわからず、平凡なアイデアしか思いつけない 開発言語は、制約から決定する O(n) の計算量でも、その定数項を気にする 専用ハード好き (地球シミュレータ, メーンフレーム) 定量評価ができないような仕事は興味ない 固定長データ バイナリデータ 再帰なんてもってのほか スピード狂 CPUがどれ
きまぐれ日記: pubic static はコンピュータに伝える約束事ではない
http://www.atmarkit.co.jp/news/200904/10/matz.html PerlやRuby、Pythonといったスクリプト言語では、 記述が非常にストレートで端的になる。JavaやC++といった言語では、 「public static void mainなど、コンピュータに伝える約束事が多くて、 やりたいことが頭の中から逃げてしまう。簡潔さは力なのです」（まつもと氏）。 これは書くときだけでなく、読むときにも同様だ。 まつもと氏の記事を読んで、仕事として大規模な共同開発の経験に基づいているのかなと思いました。 publicとかstaticとかconstというのは書く側からすると約束事で めんどいということには同意しますが、毎日のようにコードレビューを している経験からいうと、コードレビューをする側にとってこいうキーワードがあるかないかで全く意味が異なります。メ
きまぐれ日記: 肥大化して破綻するオープンソースプロジェクト
一時期オープンソースがはやった時期がありましたが、今はどうなんでしょう? 当時はオープンソースでバラ色の人生みたく過大評価されていたような記憶があります。 過大評価は言い過ぎですが、いまこうやってブログをかけるのもオープンソースの おかげであることは間違いありません。 しかし、すべてのオープンソースプロジェクトが成功したかというと、簡単に YES といえないような気がします。こういう話を某エンジニアとしたら、彼も 同じような視点(というかその方の場合は実経験かもしれませんが)を持ってて、 なんか話が盛り上がってしまいました。 その問題点とは肥大化です。オープンソースは誰でもプロジェクトに参加できるのですが、 ディベロッパーの技術もピンキリなため、時にはどーでもいい拡張がコミットされてしまう ことがあります。その最たるものが周辺技術との統合。ホニャララメタデータをMySQLに保存, ○○バッ
きまぐれ日記: Yahoo!の形態素解析をMeCabで無理やり再現してみる
MeCabで形態素解析器を作りたい場合は以下の二つの言語リソースが必要です。 1. 辞書 (単語と品詞のペアの集合) 2. 入力文と、それに対応する正解出力ペア(正解データ) 現在公開している mecab-ipadic は、ipadicとRWCPコーパスという正解データを使っています。 ここから分かるとおり、少なくともMeCabを使う場合は、コスト値を丹念にチューニング するといった職人芸は要りません。形態素解析への入力文とそれに対応する(理想)出力 があればコスト値を機械学習的なアプローチで構築することができます。 さらに、正解データを人手で作る必要は必ずしもありません。 すなわち、Yahoo!の形態素解析器の出力結果を「擬似正解」とみなして MeCabの学習プログラムを走らせれば、Yahoo!の出力を高い精度で再現できる MeCab用辞書を作成することが原理的に可能です。 ふだんはあま
きまぐれ日記: 動的配列への追加コストはなぜ O(1)?
動的配列への追加コストは O(1) ってのは覚えていればそれだけの話ですが，どうしてかと言われると意外と難しいものです． というのも, このO(1)ってのは動的配列の実装方法に強く依存しているからです．実装を知っていないと答えられません． 一般論として，1つ要素を追加するとき，配列に空きがなかったら新しく配列を作り直して全要素をコピーする必要があります．コピーのコストは O(n) だから，追加コストも O(n) になるという議論が混乱の元になっています． こういうときは，要素追加を n 回繰り返したときの計算量を n で割った平均をとるという解析方法が使われるそうです．一般に, ある operation C の計算量を C を n 回行ったときの計算量 O(n) を n で割った値 O(n)/n で評価する手法をならし解析 (amortized analysis)と言うそうです． さて，s
きまぐれ日記: ソートの平均要素移動距離
配列をソートする際に各要素の平均移動距離はどれくらいになるか問題が同僚の間で話題になった. 結論から言ってしまえば，サイズ n の配列の場合平均移動距離は n/3 になるらしい． サイズ n の場合, 最右の要素は [0 .. n-1] に等確率で移動するので，直感的に考えると n/2 のような気がする．しかし，真ん中の要素は両側に移動するので，その距離は小さくなる．平均移動距離は n/2 より小さい値になるはずだ. 頭で考えるより手を動かしたほうが楽なので，モンテカルロサンプリングしてみた. 配列をランダムにシャッフルし，ソート済みの配列と比較して各要素の平均移動距離を求める．これを 1000 回繰り返し平均値を計算する. #include <iostream> #include <vector> #include <cmath> #include <algorithm> static
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
