安定寄りの零細IT会社を作って1年ちょいで得た知見

凡例は多い方がいいのかなと思ったのと幾つか思うことがあったので。

今月で設立からまる4年の零細IT企業を経営しています。
多少の違いはあれど思うことは同じかなと思い凡例として自分の経験をメモしておきたいと思います。
そこそこ似ているところもあるので。

設立以前から現在までのざっくりの状況 経歴
  • 小規模外注でサラリーマンエンジニア3年
  • 独立系金融系SIerで運用エンジニア1年
  • Web系コンテンツ会社のDBA4年
  • ベンチャー2年
  • 独立

コミュニティ活動は積極的に。
Cassandra Summit JPNを主催しています。
まずは1人だけの株式会社を設立。
設立から1年ちょいの間に社員を2人採用。
以後、出入りはありつつ常時3名程度は在籍中。
インターンを含めて最大4名(自分入れて5名)
現時点では受託開発中心で、安定に寄せた経営方針(これも一緒)
業績はボチボチ、倒産の危機とかはない程度には良い(これも一緒)
一応、2ヶ月程度全く仕事無くても倒産はしない位のキャッシュはあります。

とりあえず受託で食っていくために必要なもの

ほぼほぼ同意。
ただ、うちは
「月末締め、支払いサイト60日」
の仕事が多い為、そこそこ体力がいります。
※こういうお客さんは結構多い。

尚、自分の場合起業直後に東日本大震災を喰らったので
それなりに生き抜く為のお金は必要でした。
厚生年金・健康保険は維持したので収入無いのにぶっ飛んでいくお金は大きかったです。

(震災のおかげと言っては何ですが割と精神的にタフになりました。
状況的にはあの時にくらべたら格段に良いですし。)

コネ

「コネがなければコネを作る」
自分としてはこれが全てかなあ。
結局の所、縁で仕事が繋がっていくのは事実として、
しかしながら前の所から仕事を貰っているだけだといざという時に
つぶしが利かないので。

正直失敗も色々ありますし。
(失敗は誠心誠意努力して返していくしか無いのですけれども)

相場・市況感

同意。
後、自分の値付けをしっかりできること、値段の根拠をしっかりと
顧客に説明できることは大事だと思います。
(付加価値は何処にあるのかとか相場にくらべての値段差の説明とか)

ちゃんと仕事を回してちゃんと納品する能力

これは非常に大事なんだけれども、こと社長など経営側に居る場合は
最終的には無理してでも頑張らないとどうしようも無いことがあるのは事実です。
(自分及びメンバーの見積もりミスをどうにかするのは結局の所社長なので)
もちろん見積もりミスが無いに越したことはないのですが失敗の無い人間も居ないのも事実なので。
この4年で2回ほど見積もりミスがあります。
サブ的や仕掛かり的な仕事ほど本命に手を取られてディレクションを回すのが
難しくなるのでそこが課題。

その他雑多な事項
雑務

顧問の社労士が居たり、顧問の税理士が居たり細かいところでは事務所に
清掃業者入れたりとかかなり雑務的には解放されるように仕向けているのですが
なかなか減っていません。一つ減ると新しく一つ増える感じです。
テンポラリの雑務も多いですしね。
最近は社長業の宿命かなとあきらめています。
(一つ一つが小さすぎて事務員を雇うほどでは無いのです。)
(高校の同級に税理士が居たのが暁光。すごい頼りにしています。)

社員を雇うか否か

雑務のほとんどがここに集約するのでいい面と悪い面と。
おそらく気ままにやりたいだけなら本当に雇わない方がいいと思います。

一応、雇用保険・厚生年金・健康保険(但し規模的に協会けんぽだけど)は維持していますし
スポーツクラブの補助(週一回程度であればただで使えます)やClubCCI(福利厚生代行サービス)も加入しています。

メンバーに対しては残業禁止とも言えていますし、
アメリカに連れて行ったりはしているのでそこそこの環境は維持できているのかなと。
ちなみに倒産防止共済は入っていますが退職金共済は入っていません。
(メンバーに「手取り減るけど入る?」と聞いたら入らないと言われたので)
(減る分を上乗せは体力的にまだ。)

就業規則

人数的にまだです。(従業員5名以下は必須で無い。)
ここも課題です。(terurouさんの所のはその内利用させて貰うつもりです。)

役員報酬額

役員報酬は決算後の2ヶ月以内に年総額を決めなければいけなくて
それを一年間変更することができないのでいつも迷います。

キャッシュフロー

支払いサイトと売り上げのタイミングが異なるので複式必須の帳簿が
読めなければ話になりません。その上で取っ払いのお金が発生したりするので
キャッシュフローは大事です。(結構見えにくい。)
社員の給与数ヶ月分をバッファーとして積んでおくつもりで口座に残しておくと
経常利益となりそこから税金をすっこぬかれます。
これが地味に痛い。
うちは初年度こそ赤字でしたが一応2年目以降は黒字にしています。
従業員に給与払えなくなると困りますしね。
(その月の売り上げをダイレクトに給与に回したくないので)

東商リサーチや帝国データバンク辺りには正確に報告しているので興味ある方はそちらから覗いてみてください。
(立ち上げ直後に2社とも直接足を運んでくれたのには驚きました。)

まとめ
この4年間での総括としては以下の通りかなと。
  • 人材大事。
  • 人材難しい。
  • 早く関東IT健康保険組合に入りたい。
  • 受託以外の種まきは必須でずっと撒き続けているけれどもなかなか芽は出ない
こんな感じですかね。 今年もCassandra Conference JPNは開催する予定で準備を進めているので参加頂けると幸いです。

何かとドタバタしていて大変遅くなりました。
二日目のレポートになります。
すでにスライドもビデオも公開されているのでそちらも参考にしてみてください。

■Hindsight is 20/20. MySQL to Cassandra

Spam検知を行うシステムをMySQLからCassandraに移行した経験とポイントを話してくれました。(多分)すみません。英語が早すぎてあまり聞き取れていないです。ただ、いくつか印象に残っているのがMySQLからCassandraに移行した後のパフォーマンスの変化の表と「C* is the best option for persistence tier」の言葉

■Cassandra on Cloud Foundry

Cloud FoundryでCassandraを使うには。CaaS (Cassandra as a Service)をCloud Foundryで構築する方法をその場で実演してくれました。Cloud Foundryに詳しくないのですが環境構築方法としては面白いかもと思っています。そのうち環境構築をしてみようかなと考えています。参加者が少なかったのが印象的でした。(5人くらいしか居なかった。)

■Adaptive Data Convergence for Life Sciences

行動履歴とビジネスの直交のお話でした。
グラフ理論を使って「見えるか」をどのように行うかを図付きで丁寧に説明してくれました。
Cassandraを使ってのソーシャルグラフの作り方を丁寧に教えてくれたので結構有用です。
(でもここも人数少なかったんですよね。一つ前よりは多くて10人くらい)

■Data Driven Retail
太陽電池パネル、冷蔵庫、ガス・水道メーター、電灯のセンサーデータをかき集めて解析しコスト削減につなげましょうというお話。全米からセンサーデータをかき集めているのでデータが爆発しますがそれをうまく制御して有効活用すると色々とできますよと。これは自分が考えているデータのあり方の一つの道筋になるかなと思っています。。

■Data as Competitive Advantage in Manufacturing

これ時間取り違えていたらしく30分では全く収まらず押しに押しました。途中からひたすら早口になるし最後はちょくちょく催促入るし。ただ無いように関してはとても興味深いです。製造業におけるデータの重要性を説きつつアーキテクチャーの説明をしてくれました。工場の生産機器のログやエラーなどを統計解析することによってデータを活用することを行っているとのことです。

■Time is Money

民間投資会社が時系列のリアルタイムマーケットデータをどのように格納するかそしてどのように格納するかの発表でした。前半が業務パート、後半が技術パートという感じで。自分は前が押してしまったので後半しか聞けませんでした。

■Stepping Through the Lifecycle of a Service Offering with Cassandra

システムのライフサイクルのお話。ちょっと観念論ぽくて自分の英語力では難しすぎました。

■Cassandra at Instagram

InstagramでのCassandraの活用方法の解説です。RedisからCassandraへ置き換えた理由やRedis、Cassandraそれぞれのデータ構造のお話でした。Instagramのデータ構造が見えて面白いですね。

■How Not to Use Cassandra

Cassandraユーザーにとってのどから手が出るほど欲しい運用情報(苦笑)。様々なかゆいところに手が届く系の情報が詰まっています。セッションでは笑いが起きたり和やかな感じで面白かったですね。

駆け足になりましたが、アメリカでのCassandraの使われ方が垣間見れるようでしたらうれしいです。自分としてもアメリカと日本とのCassandraの勢いの差はどうにかして埋めたいと思いますので。もちろん今年もCassandraConference in Tokyoを行う予定です。アメリカで多少小細工を打ってきました。楽しみにまっていてください。

ほぼ一年ぶりの更新になってしまいました。もう少し更新しないとですね。

さて、先日からCassandraSummit2013及びHBaseConに参加するためにサンフランシスコに来ています。
アメリカのイベントは活気があっていいですね。取り急ぎの初日の速報としてCassandraSummit2013の報告をしたいと思います。内容に関しては自分の英語にそれなりに難有りと思っていますので、認識違いがあると思います。ですので、後日公開されるビデオなどを参考にしてください。ビデオが公開されたら改めて確認して詳細を書きたいと思います。なお今年は2日間5トラック参加登録数1200人以上と有料カンファレンスにもかかわらず去年の800名を大幅に超え巨大なカンファレンスになっていました。全体的なトラックもビジネス寄りのものが増え参加者も年齢層が高めになった印象です。来年はどうなることやら。

  • 基調講演

  • CEOは今年は案内に徹していて余りぶっ放さなかったなという印象 CTOの基調講演は1.2の新機能と7月に出る予定の2.0の新機能のお話。 基本的にはすでに表沙汰になっている機能ばかりなので驚きは余りありませんでした。 TwitterにそのままメモしていたJonathanが語った内容に関しては以下の通り。

    各nosqlのパフォーマンス比較:HBaseやRedisなどとのパフォーマンス比較。
    CQL3の解説: Account Authorization:今までも簡易的には存在していましたが、アカウント認証がCreate User文で出来るようになりました。
    Native drivers : CQL3用のNativeDriverが続々作成されています。
    Cassandraのメモリの使い方:JVMヒープ以外のメモリにbloomfilterを展開してメモリの効率的に使用しています。
    Compaction throttling:Compaction時のIOの使用方法を調整して効率的な。
    Dse3:
    Casの話:Paxosプロトコルが実装されました。CQL3上でWhere句にif文を追加することにより条件分岐でUPDateが可能になりました。
    Triggerの話:

  • What were they thinking?

  • アクセンチュアの話 EnterpriseITを使うのかCassandraを使うのか?

    得ることを判断としますか?
    失うことを判断としますか?

    Cassandraを使うのはいつ?
    今でしょ?

    のお話。

    最初何が言いたいか解らずなんでこのセッションがここにあるのかなと思っていましたが 要約すると上記のとおりでした。内容に関しては近いうちに公開されるビデオを参照してみてください。 これはこれで面白いですよ。

  • Big Architectures for Big Data

  • DaaS(Data as a Service)のお話 SimpleReachのデータプラットフォームの設計方法、 ITアーキテクチャの概要など。 Cassandraのスキーマ設計が聞けるのかなと思っていたらちょっと違いました。 去年のDisneyもそうだったのですがやっぱりMongoと併用させてますよね。

  • Ground Traffic Control - Logistics with Cassandra

  • 壮絶に期待していたいのですが、前の自分の参加したセッションが押してしまい 5分遅れで行った処、15分しかプレゼンをしてくれなかったので10分程度しか聞けませんでした。 内容もCassandraの特徴とAWSの特徴を話していただけの印象が。 こちらはビデオ公開がされたら改めて内容を確認したいですね。

  • Real-time Analytics using Cassandra, Spark and Shark

  • CassandraでAnalyticsを行うためのプラットフォームの解説。 HiveQL互換の記述方法でCassandra上でアグリゲーションを行うのに有効ですとのこと。 SparkがMRフレームワークでSharkがその上で動くHive互換フレームワーク。 特徴としては中間ファイルをマテリアルビューとしてメモリ上に保持しているので バク速ですよとの事。ClouderaのImparaをどう考えるかがこのツールの肝のような気がしています。

  • Suicide Risk Prediction Using Social Media and Cassandra

  • 題名が題名だったので方法論などに期待していたのですがシステムアーキテクチャのお話でした。 これはこれで非常に重要なんですけどね。 一番大事な所はブラックボックスの中でゴニョゴニョと。そこが聞きたいのに。

  • Hardware Agnostic: Cassandra on Raspberry Pi

  • 今回もっともGeekよりの内容。結構動かすまでに苦労しますねという印象。 64ノードクラスターで$2,000とか32ノード作ったとか楽しいですね。 OracleJDKとOpenJDKでかなりの差がでたとのこと。 こういう話は楽しくてイイですね。 思わず日経さんからでたRaspberry Pi付きムックをそのまま注文してしまいました。再現実験は後日。

  • When Bad Things Happen to Good Data: A Deep Dive Into How Cassandra Resolves Inconsistent Data

  • リペアのお話。どのようにデータを復帰させているかや、ノード障害時のデータ整合性の担保の仕方を内部アーキテクチャを詳細に説明しながら解説してくれました。内部アーキテクチャに関して自分の勘違いしていた部分もあったりしたのでこのセッションはビデオが出次第改めて確認したいと思います。

取り急ぎの初日のレポートは以上になります。二日目もすぐに上げたいと思いますが明日帰国なので飛行機上でかけたらと思いますので今暫くお待ちください。

尚、次回のCassandra勉強会にてCassandra Summit 2013の報告会を行いたいと思いますのでもし良かったらご参加ください。申込は以下となります。

第26回Cassandra勉強会

参加お待ちしています。

昨日に引き続きCassandra Summitのレポートです。


Buy It Now, Cassandra at eBay
eBayにおけるCassandraの使用方法のレポートです。
ソーシャルシグナル(いいねボタンなど)のデータを直接投入しているしているとのことです。
このデータを使用してリアルタイムレコメンデーションを実現しているとのこと。
データモデルの提示もありかなり有効なセッションでした。


End-to-end Analytic Workflows with Cassandra
HadoopファミリーととCassandraを用いたアナリティクスの入門でした。
Cassandra + Oozie の話が興味深かったです。

Hastur: Open-Source Scalable Metrics with Cassandra (Noah Gibbs)
Cassandraを用いたモニタリングシステムの解説でした。
データ設計方法が詳細に語られていますでこれも参考になると思います。

Big Data at Disney

ディズニーにおけるデータ運用方法の全体像の報告です。
ディズニーのもつ全てのデータ、(ムービーやテレビ番組、ディズニーランドの情報など)を一元管理するための仕組みとのことです。「Data as a Sservice」という言葉がこの設計の壮大さを表しているなと。正直、激しく壮大な話なので直接的にこのセッションが参考になる所も少ないとは思いますがデータ活用方法の一つの局地としてみると非常に興味深かったです。

Changing the Game, Cassandra + Solr

普通にDataStaxEnterpriseにおけるSolrの使用方法でした。
(正直、Cassandraあまり関係ないやんというツッコミがなくも無いですが)
最近、業務絡みでDataStaxEnterpriseを調査しているのですがAll in one パッケージとして非常に優れていますのでとても有効なプロダクションであると思っています。


Technical Deep Dive: Data Modeling
かなり濃ゆいCassandraにおけるデータ設計方法の解説でした。
非常に役に立ちますのでCassandraを使用してみようとしている方はスライド及びビデオ必見です。自分も改めてもう一度見直す予定です。

セッション全体を通して実用例、モデリング方法、運用方法など色々な情報が詰め込まれており非常に楽しく且つ役に立つセッションが多かった印象です。ビデオも公開されているので、聞き逃したセッションもみておこうかなと考えています。

Summit終了後のAfter-party at Computer History Museumの様子はまた、明日書きます。

ほぼ一ヶ月たってしまいましたが先月参加したCassandraSummitの報告をしたいと思います。

因みに自分の英語はズタボロなので内容の正確性は保証できかねますのでそのあたりは差っ引いてください。

因みにCassandraSummit2012の様子はここから一部見ることが可能です。Cassandra Summit 2012 Presentations

参加して一番感じたのはアメリカでのCassandraの勢いです。

有料のカンファレンスに登録800名との事。大きなホテルのカンファレンスフロア全てを借りきって4トラックのセッションを一日埋める。すごいですね。

全体的な印象としては前日のプレカンファレンスに参加しても感じたのですがCassandraをアナリティクスに用いている場合が多いかなと。DataStaxEnterpriseを用いるだけでなく独自でもトラッキング情報をCassandraに放り込んで後で解析するなどです。また、DataStaxEnterpriseとCassandraの話がシームレスに交じるのでDataStaxEnterpriseをある程度知ってないと混乱するかもと思いました。
(SolrandraはCassandraの機能ではありません。)

アナリティクスは自分もそちらのほうが親和性高いかなとも感じますのでCassandra自身そちらの方に進むかもしれないなと感じています。

さて、自分が参加した参加したセッションに関してコメントしていきたいと思います。


KeyNote
オープニングが和太鼓から始まって多少面食らいましたがなかなか楽しかったですね。
異国で見る和の雰囲気はなんか嬉しいです。

Billy Bosworth(DataStax CEO)

盛大にHBaseをディスっていて楽しかったです。(笑)
先日行われたHBaseConは600人しか集められなかったけどCassandraSummitは800人集めたぜハッハーとか、ビジネスにおけるパイの大きさが全然違うぞとかなどなど。
HBaseConを見ていないので本当の所はわかりませんがこの辺にも勢いを感じました。



Jonathan Ellis(DataStax CTO)

JonathanのKeyノートは普通にDataStaxEnterpriseの宣伝でしたね。Cassandraの内容が半分とDataStaxEnterpriseの内容が半分でその境目がシームレス。これは誤解を生むようなと感じました。内容としては1.2で導入予定のバーチャルノードやJBODが気になりましたね。Cassandraは高性能のハードで運用するとリソースを使い切れないのが現状なので擬似的に複数ノードに分けることによりハードウェア性能を使いきろうという考えです。JBODに関しては現行のCassandraが複数台のハードディスク搭載していてもその一本が飛ぶことによりノードダウンと同じ状態になるので全てのディスクを束ねてRAID0にする方が良いという本末転倒な状況だったのでその対応が入ったというのは大きいと思います。


We Messed Up, So You Don't Have to (Jason Brown, Ed Capriolo, Matt Dennis, Matt Pfeil)

使用者による運用に関するトークセッションです。
先日Cassandra勉強会でもお話ししていただいたJason Brownさんが参加されるので半分会いに行くという目的もあったのですが内容としては、正直自分の英語力では少し厳しかったです。このセッションの為に公開ビデオを待っていたくらいです。結構細かいCassandraの運用Tipsが盛り込まれているのでビデオは割と必見かもしれません。自分も改めて見なおしています。

 

続きはまた明日書きます。

現在、Cassandra Summit 2012に参加するためにサンタクララに来ています。 明日が本番当日なのですが今日は無謀にもpre-conferenceに突入してきました。

ここまで英語が拙いにも関わらずお話に
お付き合いいただいたエンジニアには感謝感激です。
(しかも帰りのタクシーの呼び方が解らなかったから呼んででもらってしまいました。)

嬉しいことにアメリカのCassandra熱は日本と違ってかなり高いですね。
明日のCassandra Summit 2012には800人もエントリーしているとのことです。

話を色々聞いてみて結構アナリティクスに利用している人が多い感じがしました。
やっぱりそういった方向に走っているのかなぁ。

恥も外聞も捨てて突入してみるとやはり収穫は大きいですね。
嬉しい限りです。でももう少し英語を勉強しないと。
(半年間この為に英会話学校に通っていたりしたのですが。
くそ度胸がついたのだけは収穫かもです。)

明日は再度詳細をリポートします。

 

 

O'reilly Japan 「Cassandra」を訳者の一人である小林さんより献本頂きました。
御礼申し上げます。

日本語唯一と行っていいほどのCassandraの底本です。


そもそもCassandraはドキュメントそのものが少なく、更に日本語情報となると
更に 輪をかけて減ってしまうため、まとまった日本語資料に当たることは
難しいのですが、とりあえずこれからCassandraを使おうと思う、もしくは
Cassandraの運用を行う必要があり情報に当たりたいと思う方は必携の書と思います。


章立てとしては各章が独立しており後から字引替わりの参考資料としても使えます。
これからCassandraを始める人であれば1章、3章、7章、8章、13章、付録Aは必読、
現在Cassandraを使用していて困っている人であれば、7章、9章、(10章※1)、11章が
必読になると思います。
※110章に関しては基本的にツールの実態が事実上JMXを叩いているだけなので
9章を理解していればそれほど必要にはなりません。


ただ、本書における注意点があります。
Cassandraのバージョン更新が早いのと翻訳元の底本がでた時期がかなり前であることも
影響しているのですが、各章に於いてそれぞれどのバージョンベースのものかが記載されていません。
底本の関係により0.6系をベースに記述されている部分も多くあります。
さすがに現状0.6系を選択することも無いと思いますので、実際に操作する際には内部実装が
かなり変わっている部分も多いので注意する必要があります。
(例えば、運用を開始して必ず立ちはだかるStream関連は、各バージョンごとに
かなり実装が異なるため運用の手順も異なります。)


ちなみに0.7系、0.8系、1.0系は外部インターフェースはそれほど変更されていないので
アプリケーションの移行はそれほど大変ではないのですが、内部実装が激変しているので
DBA系の運用者は特に注意が必要です。
残念ながら内部実装のまとまったドキュメントは現状無いため自力で対応していくより
他無いのですが、それ以外の部分は綺麗にまとまった本書が非常に大切になると思います。


軽くCassandraに触れてみたい人も、がっつりCassandraに触れてみたい人も
ぜひ手にとって読んでみてください。

尚、内部実装とがっつり取っ組みあってみたい人はCassandra勉強会に
来てみてください。 割と内部実装のお話していたりします。
次回は1.0系のCompactionに取り組む予定です。

Twitterの方では流しましたがfluent-plugin-cassandraをリリースしました。

FluentとはTreasureDataの古橋さんが作成されたプラガブルなイベントログ収集ツールです。

自分も、ログ収集ツールを探していて、flumeにするかscribeにするかなど悩んでいたのですが

flumeは重いし面倒だし、scribeは敷居高いし面倒だしなどピンとこない状態が続いていました。

Cassandraにデータを入れたかったのもあって接続が大変というのもありました。

そこに丁度という感じで先日Fluentが発表されてこれは良いなと感じたわけです。

発表の場にいたので、Cassandraのプラグインは?と聞いてみたのですが書いてーとの返事だったのでこれはやるしか無いかなと。

Python使いとしてはrubyは結構遠くて手こずりましたがどうにか公開にこぎつけました。

書き方が悪いとかそういうツッコミは直接いくらでもください。rubyのお作法解らないし。

github からかもしくは

gem install fluent-plugin-cassandra

でどうぞ。

尚、構造としては受け取ったJSON毎にそのままCassandraのColumnFamilyに流し込んでいます。

ですのでJSONの構造は単純なKey-Valueのペアか、SuperColumnFamilyを作成して

二元ハッシュにしてください。キーはイベントタグにイベント取得時間を単純にくっつけていkeyにしています。

想定としてはイベントをCassandraに放り込んだ後に上にbriskを乗せるですかねぇ。(要するに後からマップ・レデュースで解析)

非常に色々と応用が利きそうで面白かったので自分用のメモ。
昔の専攻がらみで焼けぼっくいに火が付きそう。

HadoopのMapReduceとPythonとmecabを組み合わせてテキストマイニングの取っ掛かりのお話。
条件としては

  • 分散のHadoop環境が構築できていること
  • データノードでpythonが正常に動くこと
  • データノードにmecabがインストールされていること。
です。

Hadoop構築はHadoopのドキュメントを参照しました。
Hadoopで動くPythonのMapReduce環境はこのblogを参照しました。
mecabはmecabの公式ドキュメントを参照しました。
環境構築の話を書くと長くなるので端折ります。

実行したmapperが以下のスクリプト
mapper.py

#!/usr/local/bin/python
# -*- coding: utf-8 -*-
 
import sys
import MeCab
 
# input comes from STDIN (standard input)
m = MeCab.Tagger("-Ogoso")

for line in sys.stdin:
# 行頭と行末の空白を取り除く
line = line.strip()
# 行を単語に分割する
line = m.parse(line)
words = line.split()
# カウンターを上げる
for word in words:
print '%s\t%s' % (word, 1)
# STDOUT (標準出力)に結果を書き込む;
# ここで出力したものはReduce(つまりrecuder.py)での
# 入力になる
#
# タブ文字での分割; 単語の出現回数は 1


 


単純に日本語TEXTを分かち書きしてCountして標準出力に。

実行したreducerは以下のスクリプト
reducer.py



#!/usr/bin/env python
# -*- coding: utf-8 -*-

from operator import itemgetter
import sys

# 単語の出現回数のマップ
word2count = {}

# 入力はSTDIN
for line in sys.stdin:
# 行頭と行末の空白文字を除去
line = line.strip()

# mapper.pyの出力をパースする
word, count = line.split('\t', 1)
# 回数を文字列から数字に変換
try:
count = int(count)
word2count[word] = word2count.get(word, 0) + count
except ValueError:
# 回数が数字でなければ
# こっそり、この行はなかったことにして捨て去る
pass

# 単語をアスキーソートする
#
# この処理は必要ないが、オフィシャルHadoopの単語の
# カウントサンプルコードの最終出力に似せるために行う。
sorted_word2count = sorted(word2count.items(), key=itemgetter(1))

# STDOUT (標準出力)に結果を書き込む
for word, count in sorted_word2count:
print '%s\t%s'% (word, count)

 


単純にCount数を積算してソートして標準出力に。

単語出力回数順にソートをしています。


これをhadoopコマンドで実行します。


/usr/local/hadoop/bin/hadoop \
jar /usr/local/hadoop/mapred/contrib/streaming/hadoop-0.21.0-streaming.jar \
-mapper /home/hadoop/mapper.py \
-reducer /home/hadoop/reduce.py \
-input /user/hadoop/matome \
-output /user/hadoop/output

約2分強で60MB程の日本語テキストの解析が終了。

昔(10年前)は数ヶ月かけていたのに......。



結果の抜粋はこんな感じ。頻出単語上位です。


を 371190
て 393814
は 426790
に 433759
た 473274
。 477822
の 633713
、 775162

やっぱり「て」、「に」、「を」、「は」が多いんですよね。

これはこれで面白かったのですが、動詞系は活用があるので別カウントされてしまいます。これもつまらないなと思ったのでmecabの設定に手を入れてみました。



/usr/local/lib/mecab/dic/naist-jdic/dicrc

に以下の設定を追記しました。語素の部分のみ出力する設定です。


; goso
node-format-goso = %pS%f[6]\n
unk-format-goso = %M
eos-format-goso = \n

これで活用を無視できるようになります。

てにをはの強さは変わらないので途中の抜粋としては

思う 16754

とか

言う 18065

とかの強さですかねぇ。

てにをはの出現頻度は桁違いですが。


結構簡単にできたのでこれを応用していけば結構面白いことできるかなと思います。応用方法を少し考えてみようかなと。


前回のエントリーの通り株式会社を設立しました。
以前に比べ格段に株式会社を作りやすくなっているのでおすすめも含めて
株式会社の作り方をつらつら書いていこうかなと思います。

まず、なぜ株式会社を選択したのかです
会社を設立するにあたっていくつかの選択肢があります。

  • 株式会社
  • 合同会社(LLC)
  • 有限責任事業組合(LLP)

等です。(LLPは組合なので法人(会社)では無いですが)
もちろん自分のような一人会社であればわざわざ法人を設立する必要性は薄く、
個人事業主でも十分仕事はできます。

それぞれメリットデメリットがあります。簡単に書くと以下の通りでしょうか?
今更無限責任の会社を作ろうという酔狂な人は少ないと思うので合名会社と合資会社は除いています。

  • 株式会社
    • メリット
      • 法人税額が一定。(個人に所得税がかかった場合は累進課税。)
      • 過去の経緯から無意味に信用度が高い。(昔は設立が大変だった。)
      • 決算期が選べる。(確定申告等に左右されない。)
      • 法的には有限責任(会社の借金を個人で背負わなくても済む。)
        ※でも実際の所、融資の際には個人補償求められること多いそうです。)
      • 出資金を出してもらえる。(融資ではなく出資が受けられる。)
      • かっこいい。(いちぶぢょーぢょーきぎょうの社長様と法的には同格です。SONYの社長なんかと同格ですよ!!)
    • デメリット
      • 設立にお金がかかる。(なんやかんやで出資金以外に20万近くかかります。)
      • 維持にお金がかかる。(決算報告などや税理士に頼んだりなど、税務絡みでまともに運用すると年間60万くらいかかります。)
      • 会社を乗っ取られる危険がある。(出資を受ける際に適当に受けると会社をあっさり持って行かれます。)
  • 合同会社(LLC)
    • メリット
      • 法人税額が一定。(個人に所得税がかかった場合は累進課税。)
      • 決算期が選べる。(確定申告等に左右されない。)
      • 出資金を出してもらえる。(融資ではなく出資が受けられる。)
      • 法的には有限責任(会社の借金を個人で背負わなくても済む。)
      • 基本的には株式会社と一緒。
        違う点は利益配分及び議決権が出資率に左右されないという所。
        つまり他人のお金が会社を作った場合に有利。(乗っ取られにくい。)
    • デメリット
      • 設立にお金がかかる。(株式会社より安いとはいえ登記に10万近くかかります。)
      • 維持にお金がかかる。(決算報告などや税理士に頼んだりなど、税務絡みでまともに運用すると年間60万くらいかかります。)
        因みに株式会社と比べて税制上のメリットは登記の時くらいしかありません。
  • 有限責任事業組合(LLP)
    • メリット
      • 出資金を出してもらえる。(融資ではなく出資が受けられる。)
      • 法的には有限責任(組合の借金を個人で背負わなくても済む。)
      • 利益配分及び議決権が出資率に左右されない(LLCと一緒)
      • パススルー課税の適用が可能(というより法人税がそもそもかからない。)
    • デメリット
      • そもそも法人じゃない。(あくまで組合なので法人格を持ちません。)
      • 設立にお金がかかる。(株式会社より安いとはいえ登記に10万近くかかります。)
      • 会計処理がめんどくさい。(ただでさえややこしい会計処理が輪をかけてめんどくさくなります。)
  • 個人事業主
    • メリット
      • 登録がいらない。(登記とかいらないです。開業届いるけど。)
      • 開業に金がかからない。
      • 法人税がかからない。
    • デメリット
      • 所得税は累進課税。(儲かると痛い。)
      • 国民年金・国民健康保険。(人によってはメリットというかもしれないけれど。)

基本的には自由選択でいいのですが、自分としてはきちっと法人格を持ちたかったこと、将来的にはある程度会社を大きくしたい事、厚生年金適用を維持したいことを理由に法人格取得を目指しました。日本版LLC・LLPは自分で全額出資した場合はメリットがあまりないのと株式会社の場合、信用度が無駄に高いので株式会社を設立しました。出資率に影響を受けない場合、最初の登記の金額が違うくらいですしね。もちろん、エンジェルがきっちりついている方はLLCやLLPを考慮するのもよいと思います。

作り方は以下のサイトを最大限参考にしました。
自分でできる会社設立
定款は電子定款で認証してもらいました。
この通り手続きを進めると登記が出来たので本当に役に立ちました。
ただ、後から気づいたことなのですが、「決算公告を電子公告にする手続き」を忘れたのがやや痛かったです。
上記のサイトには入っていないのでお気を付けください。

登記の当日は書類一式とボールペンと判子一式をすべて持って行く事をお勧めします。
書類が足りなかった場合、法務局の方が色々指摘してくださるのですが、
その場で修正したり、書いたりして捺印して提出という事が可能なので。
えぇ、いくつか書類足りなくてその場で手書きで書きました自分。

尚、会社の設立日は提出した当日になります。これ、どこにも書いて無くて自分は提出後認められた日が設立日になると思っていたので。
結果、ドメイン取得が遅くなってしまいました。

とりあえず、今回は法人登記までです。次回は口座開設と税務署への届け出と、年金事務所への届け出を書いてみたいと思います。

最近のコメント

アイテム

  • lvs.png

ウェブページ