2010/11/22(月)twitterの流入測定について修正
2010/11/22 09:41
あらためて調査したところ、短縮URLとノーリファラーは関係ないようです。申し訳ありません。
下記記事に追記しましたのでご覧ください。
Google AnalysticでのTwitterとfacebookからの流入測定(リダイレクトと参照元について)
2010/11/15(月)Google AnalysticでのTwitterとfacebookからの流入測定(リダイレクトと参照元について)
2010/11/15 21:38
この記事のTwitterからの流入についてですが、実際に自分で調査したところ、短縮URLがノーリファラーになることはないようでした。
ネット上にそのような記述がちらほらあり、かつ自分のサイトでRTされたときなどはtwitter.comからではなくノーリファラーのアクセスが上昇することからそのように考えていたのですが、思い込みだったようです。
改めてtwitterから実際に短縮URLを経由して自分のサイトにアクセスし、Analysticで計測してみたところちゃんとtwitter.comが参照元になっていました。
一方、twitterからの流入がノーリファラーとして計上されることが非常に多いというのも事実です。この記事自体、わりとツイッター上でRTされたのですが、Analysticのレポートではノーリファラーが急上昇しておりアクセス全体の54%、twitter.comからのアクセスはあまり他の日と変化無く、8%でした。なので、twitter経由の流入を正確に測定するためにURLにutm_sourceなどを付与するというのは有効であると言えます。
で、前述の通りノーリファラーは短縮URLのせいではないわけですが、おそらくtwitterクライアントの利用が多いためと思われます。twitterクライアントはブラウザではないのでノーリファラー扱いになります。まあクライアント利用が多いから、というのも推測の域を出てませんのでもうちょっとちゃんと調べないとわかりません。
以上です。ちゃんと調べずに誤解を与えてしまい申し訳ありませんでした。
=========================
いろいろ調べたのでざっくりメモ。
Google AnalysticだとTwitterからの流入が少なく見積もられます。
この原因はTwitterで頻繁に使われる短縮URL。短縮URLでリダイレクトされるとAnalysticが参照元を取得できず、ノーリファラ扱いになる。
ちゃんと測定したい場合はURLの末尾に
?utm_source=<ソース>&utm_media=<メディア>
みたいに直接参照元を指定してやるとAnalysticで測定できるようになる。詳しくは下記で。
http://blog.livedoor.jp/ld_directors/archives/51075018.html
URLにゴミがついたみたいでちょっと嫌だけど、これくらいしか方法はないっぽい。ちなみにこのURLをそのままどこかに貼られてしまったりすると結局どこからの流入なのかわからなくなるのであんまり解決してない気もする。
まあ短縮URLはおそらくHTTPヘッダのLocationかなんかでリダイレクトさせてるんだろうけど、そのリダイレクト手法だとAnalysticでは参照元を取れないわけです。
一方Facebook。Facebook内からリンクをクリックするとこれもリダイレクトされてジャンプする。しかしこちらはちゃんとAnalysticでも「参照元:facebook」として測定できる。
facebookのリダイレクトページを覗いたんだけどmetaタグのrefreshを使っていた。このやり方はブラウザの履歴にリダイレクトページが挟まって戻るボタンで戻ると再リダイレクトされてしまう上に、Googleなどのクローラーがリダイレクトとして判断してくれなかったりとで、「悪いリダイレクト」とされていたような気がしますが(確かGoogleは推奨してない。)、この手法だとAnalysticで測定できるんですね。こちらの方が何もしなくていいのでありがたい。短縮URLもrefreshにすれば測定できるのに!と思うけど、そうするとGoogleとかにうまくクロールしてもらえないというジレンマ。
refreshによるリダイレクトはGoogleのクローラーに気を遣わなくていいFacebookならではのやり方でしょうかね。mixiもそうなのかな?ちなみにリンク先から戻るボタンで戻った場合も再リダイレクトされることなくうまく処理しているようです。
まとめ:
Twitter(短縮URL)からの流入測定は一手間必要。
facebookは特に考えなくていい。
2010/07/05(月)個人で事業を始める人に役立つ書籍と会計ソフト
2010/07/05 14:06
意外と手間取りませんでした。大変そうだったけどやってみればなんとかなるもんです。
で、いい区切りなので、今回は自分が
会社退職→フリーランス→法人化
と進めてきた中で役に立った本とかをまとめて紹介してみます。
クリエイター独立ガイド―起業と経営
一番最初に買った本です。
税金や保険、複式簿記、商工会議所の活用、法人化(株式会社、LLC等)、トラブル対応まで、扱ってるネタが幅広く、独立したらどんなことが必要になるのか?という全体像をつかむにはもってこいの一冊です。
クリエイターでなくても、要は飲食店みたいに店舗や在庫を持つわけではない職種の人なら役立つと思います。
【2008-2009年度版】図解 フリーランスのための超簡単!初めての青色申告
個人事業主の青色申告向け。
Excelにアドインする形の会計ソフトがくっついてるんですが、これがかなりいい出来。「フリーランス」に機能を特化しているので(在庫とか無い)、操作自体が大変わかりやすく、フリーランスの時はこれ1本で日頃の会計処理から確定申告まで十分対応できました。変に本格的な会計ソフトを買って混乱するよりいいです。インターフェースがExcelなところもなじみがあって使いやすいし、オススメです。本の内容自体もとてもわかりやすいです。
毎年新しいのが出てるので、ご購入の際は最新版をどうぞ。
で、上記2冊でフリーランス時代は十分でした。
この後、法人化へ。
0円で株式会社を起こす完全設立マニュアル
株式会社を設立するためのマニュアル本。内容はまさに「チュートリアル」。
この本に沿って進めていくと「会社が出来ます」って感じの本で、本当にそのとおりに進めるだけなのですごく助かりました。「0円」を変に強調しているのがちょっと嘘くさい気もしましたが内容的にはそんなことなかったですw
ただ、チュートリアルなので会社ができた後はほとんど読むことがありません。
起業から1年目までの 会社設立の手続きと法律・税金
amazonでの評判が良かったので一個上の本と併せて購入。
取締役会とか監査役とかの話もしっかり書いてあって、本格的な会社立ち上げの指南書という印象。僕のようなフリーランスからの法人成りにはちょっと重すぎる感じもしますが、税金とか給与とか知っておくべきこともいろいろわかりやすく載ってるので、何か法人についてわからないときにちょくちょく参照してます。
設立の手続きについては一個上の本と違って時系列ではないこともあり、あんまり使いませんでした。
http://ichibou.net/asin/4534043333
今回の決算前に買った本。法人税は難しそうなので何か本が必要かと思い買ってみました。法人税は書類が多くて何から手をつけていいのかわかりずらいですが、この本を読むと全体像と処理すべき順番がよくわかります。ただ零細故にそんなに複雑な処理ではない上に、下記のソフトが結構助けになってサウサクできたので残念ながら意外と活躍してません。わかりやすくていい本ですが、わざわざ法人税に一冊買う必要はないかもしれません。
会計ソフト 税理士いらず
今回の法人の確定申告で使った会計ソフトがこれ。
小規模法人の確定申告に特化していて、法人用会計ソフトとしては安い¥12,600。
さすがに何か法人用の会計ソフト買わないとだめかなと思い、弥生とかいろいろ比較してたら偶然見つけたソフト。
聞いたことないし、ぐぐってもあんまりレビューとか出てこないので不安だったんですが、使ってみたらかなりよかったです。仕訳を入力するだけで(csvによる一括インポートも可)確定申告に必要な書類一式が全部作れます。地方税もOK。特化しているが故に操作に迷うところがありません。Good!
他の会計ソフトと比べるとおそらくいろんなところが劣っているのでしょうが、零細法人でたいした複雑な経理もなく、「確定申告の手間だけなんとかしたい~!」という向きには必要十分なありがたいソフトではないでしょうか。体験版もあります。
以上です。他にも何冊か買いましたが、あんまり役立たないのはブックオフに行っってしまったので、上記はすべて本棚に残っている良本です。
どうぞご参考まで!
2010/06/24(木)Android搭載のブラウザでjavascriptのスクロールイベントの処理が異様に遅い
2010/06/24 20:42
最初、Android端末の性能上、DOMの処理が追いついてないのかと思ったが、いろいろテストしてみたらどうやらスクロールのイベントを拾うのが異様にヘタらしい。
つまり、onclickイベントなどはすぐに拾ってくれるがonscrollイベントをうまく拾ってくれない。jqueryでの$(window).scrollも同様。
しばらく待っても処理されないときは処理されないので、遅いと言うより拾えてないのか??。何度もスクロールしてると拾ってくれるが、インタフェースとしてはかなりストレスが高くなってしまう。PCのスクロールと違ってタッチしてヌルヌル動かせるということが何かしら処理しづらい原因になっているのか?
いづれにせよ残念ながら解決策はみつからず。
原寸画像検索とかもAndroid対応しようと思ってたんだけど、ここが解決しないと快適性が得られないなあ..。ぐぐってもあんまり情報ないし。フローズンヨーグルトがこの辺を解決してくれてるとありがたいけど..。
なんかわかったらまたブログで書きます。
誰かこの辺について知ってる方いたら教えてください。
<2010/7/11追記>
結局スクロールイベントはあきらめてインターバルタイマーで処理することにしました。数秒ごとに残りスクロール量をチェックし、少なくなったら次を読み込むという形式です。
setInterval("次読み込み関数", チェック間隔(秒));
これでOK。
2010/03/03(水)AmazonEC2でc1.middleを使うときデフォルトカーネルを選ばない方がいい
2010/03/04 20:10
一部サービスにAmazonEC2を使っているのですが、先日インスタンスタイプをm1.smallからc1.mediumに乗り換えたところ、1日1回くらいのペースでサーバが落ちるという状況に。なぜかAmazonの管理画面では「running」になっているのだけど、WebもSSHもまったくアクセスできなくなる。しかも一度落ちると2回再起動しないと復活しないというよくわからない状況(なぜ2回?)。
/var/log/messageには下記のようなエラーが。
kernel BUG at arch/i386/mm/pgtable-xen.c:306!カーネルのバグ??
検索しても日本語のページでは原因が見つからず。海外サイトをまわってやっと見つけました。
以下、参考情報(英語)
http://www.vincestross.com/2009/04/upgrade-an-ec2-instance/
結論としては、インスタンスの起動時にデフォルトのカーネルを選択しない方がいいらしい。
c1.mediumのデフォルトのカーネルバージョンが2.6.16なんですが、これが問題の元とのこと。
インスタンス起動時に、たぶんどれでもいいのですがデフォルト以外のなるべくリストの下の方のKernel ID(下の方がカーネルが新しい)を選んでおきましょう。
2.6.16でなければなんでもいい。
ちなみに利用中のカーネルのバージョンはuname -aで確認できます。
2.6.31になって今のところ安定してます。しかしデフォルト設定にそんな罠があったとは…。
2010/02/20(土)正規表現の遅さ
2010/02/20 09:53
perlで正規表現が負担になるケース。
use UTF8環境下でのuc、lc、//i
http://d.hatena.ne.jp/gfx/20091001/1254375323
パイプは重い
http://qootas.org/blog/archives/2006/06/perl_regex_perf.html
http://d.hatena.ne.jp/fbis/20060615/1150333992
これも?
http://d.hatena.ne.jp/head/20071203/perl
//i なんて、片っ端から使いまくってた。
気をつけよう…
2010/01/20(水)SpeedyCGI(PersistentPerl)がいい感じ
2010/01/20 18:51
一部CGIに導入してみたところ、動作がかなり軽快に。
厳密には名前は知ってたんだけど、mod_perl、FastCGIとよく並べてられているから、まあ似たようなもんなんだろうと思って無視してました。まさか導入がこんなに楽なものだったとは。
詳しくは↓この辺をどうぞ。
■SpeedyCGI - CGIスクリプトを常駐させて実行することによりスピードアップさせます
■PersistentPerl(SpeedyCGI)のメモ
■Perl CGIのキャッシュ環境 - adiary開発日誌
速度的にはmod_perlのが上だけど大差ない模様。十分スピードアップできますし、楽なのでおすすめ。まあ、昨日使い始めたばかりなので、もしかするといろいろ問題点が出てくるかもしれませんが、いまのところは快適です。
mod_perl化しなきゃな~とか思いながらなんかいろいろ面倒なので先延ばししていたんですが、もうmod_perlのことは忘れます(笑。
ちなみに「-gオプションでグループ化すればメモリ節約できる」とのことなので、よくわからないまま片っ端からグループ化していたのですが、CGIじゃなくてcronから実行するplプログラムに対して-gオプションを使ったらプロセス数が無限に増えていってサーバダウンという有様に。.cgiと.plを同じグループにしちゃいけないのかな?詳しく調べていないのでなんとも言えませんが、とりあえず.plはグループ化しないようにしたら大丈夫でした。
ご参考に。