[etc] : DMP vs DSP : CookieとDataのSync Syncの流れ
How does cookie sync work between DMP and DSP? - Quora
上のQuoraにデータ分析した結果を売ってお金にしたいDMPと分析された結果を広告配信のターゲティング精度に還元してお金にしたいDSPとの間でCookieの同期とデータ分析結果の受け渡しについて良いまとめがあったので要約したいと思います。上の内容に書いてない事で僕が知識として持っていることも加えておきます。
Cookie Sync 特定のWebサイトはサイト分析やより精度の高い広告配信のためにDMPのJavaScriptタグを設置する。 設置されたDMPのJavaScriptタグはDMP側での分析サーバに送られるリクエスト以外にDSPドメインのpixelタグが含まれている。 DMP/DSPの両方にRequest処理が走り、そのResponseを受け取るのでCookieがDMP/DSPそれぞれで発行される。通常のCookieの場合はブラウザを識別できる一意のIDが付与されている。(※以下の説明ではCookie = ブラウザ識別のための一意のIDと置き換えて考えて良い。) DMPおよびDSPでCookieがそれぞれ異なるが同一のブラウザだと認識する必要があるので、Cookie対応表を作成し少なくともDMP/DSPのどちらか一方で保持する必要がある。 CookieはRFCの規格により特定ドメイン内でのみ有効なので、HttpHeaderのリクエストでCookieを別ドメインに直接渡すことはできない。 DSPのpixelが呼ばれるときにDMPのCookieをRequestパラメータとして渡せば、DSPはDSPのCookieとパラメータからDMPのCookieの両方が取得できるので、DSP側ではそれの対応表が作成することができる。もし対応表をDMP側で対応表を持つ場合はDSPのCookieをパラメータとしてDMP側のサーバにRedirectする。 もし対応表を作成するタイミングでDSPのCookieがまだ無ければ新規発行し、HttpResponseとして返す。 処理の流れのイメージは上図参照。 Data Sync CookieのSyncはOnlineで行うのが一般的。DMPの分析データはOnlineのリアルタイムで行うと処理コストが大きいので、Offlineのバッチ処理で行う。 DMPはDMPのCookieに紐づく各種Webサイトから収集した行動履歴によりAudienceの分析を行い、結果をDSP側にバッチ処理で転送する。 DSP側は対応表からDSPのCookieに紐づくデータに変換してAudienceの分析データを利用する。
[機械学習] : 機械学習のOverfitting対策 Overfitting対策 How can I avoid overfitting? - Quora
機械学習で偏った学習データに適合したモデルを評価データに対して利用した場合、精度が悪い結果が得られることがあります。単純にモデルにInputする訓練データが少なかったり、局所領域に存在するデータ扱っていたり、モデルの自由度が高く複雑である事など幾つか原因が考えられ、上のQuoraで解決策について意見が書かれています。ここでは結論として書かれた内容について簡単に紹介します。
K-Fold Cross Validation 単純な解決方法としては学習時に偏ったデータに適合しすぎないように学習データをK個のまとまりに分割して、K-1個のデータを用いて学習、残りの1個を用いて評価する作業を組みわせパターン全てで行うというK-Fold Cross Validationという手法が用いられます。こうすることによってデータの偏りは防ぐことができますし、モデルの汎化性能(評価データへの適用能力)を正しく評価することも可能であり、複数のモデルからより秀でたモデルを選択する手段としても有効かと思います。
Regularization Regularizationは過学習を抑止するためのペナルティ項で、モデルのパラメータがより複雑になればなるほど値を大きくする仕組みです。 代表的な例としてL1,L2,L1L2正則化といったものがあり、それぞれ精度やメモリの消費、スパース具合が異なります。よく目にする報告としてはL1がL2よりも計算量が少なく済む(精度が低く、スパースになりがちであるため)があります。Support Vector Machineの一つのツールであるliblinearを例にとると、学習コマンドであるtrainで学習データを指定すると同時に正則化パラメータを設定することが可能です。
Support Vector Machineは特徴ベクトルの「マージン最大化」により分類を行う手法ですが、綺麗にデータを分類できない場合にマージンの具合を決めるための定数Cというものを指定したりします。Cを大きくすると誤りを許さないハードマージン、Cを小さくするとソフトマージンで多少の誤差は許容とするという働きになります。正確にはRegularizationとは異なりますが、役割は似ているところがあります。
[etc] : Recsys2014の発表から現在のRecommend Systemの問題点を読み取る 集合知プログラミング
作者: Toby Segaran,當山仁健,鴨澤眞夫出版社/メーカー: オライリージャパン発売日: 2008/07/25メディア: 大型本購入: 91人 クリック: 2,220回この商品を含むブログ (277件) を見る
Recsys 2014 Tutorial - The Recommender Problem Revisited Recsys 2014 Tutorial - The Recommender Problem Revisited
仕事でRecommenderに関わっているのでRecsys2014の最初の発表を読んで現在の問題点を再確認したいという気持ちで、内容を起こしてみます。途中に出てくる数式の理解および書き写しが大変なので、概要だけ書きます。また意味を理解するためには「機械学習の手法」と「Recommend」に対する知識をそれなりに必要とされます。
The Recommender Problem Recommendは古くから"過去の行動履歴"、"他のUserとの関係性"、"アイテムの類似度"、"Context"に基づいてどのようにUserがアイテムを好むかを自動的に予測する便利な関数を作る事である。 RecommendationはDataを基に前処理、モデルの学習、テストおよびValidation評価をする一般的なデータマイニング問題としてみなすことが可能。 機械学習以外の側面として、UserInterface、Systemの要件定義、セレンディピティ、多様性、気づき、説明などの要素がある。 セレンディピティは直接求められていないものを探す。Userが既に知っているアイテムを紹介してはいけず、Userを興味に近しい領域に拡張させる 様々なカテゴリジャンルのアイテムを表示する事が多様性と気づきである(意訳) Collaborative Filterling (CF) Traditional Methods 協調フィルタリングには似ているUserベースでの予測をするものと(Personalized)、全てのUserの平均でのやり方がある(Not Personalized)。 手頃な手法でRecommendを作ることは簡単だが精度を改善することは難しい。手頃な手法と精度の間にはビジネス価値に大きな差がある。 User-Baseの協調フィルタリングはターゲットしたいアクティブUserを見つけて、近似関数によりUserを識別し、似ているUserが好むアイテムを見つけて、予測をして、TopNのアイテムをRecommendする。 Item-Baseの協調フィルタリングはターゲットしたいUserが持っているアイテムを探し、他のUserが過去に持っているアイテムのみを使ってどれほど似ているかを計算し、最も似ているk個を選択しRecommendする。 ほとんどの場合良い結果が期待される。次のことにできれば挑戦したい。user/itemの相互作用は1%以下なのでDataがsparseになる。NNはUserとアイテムの両面での数を多く必要とする。 Model-Based Collaborative Filterling Memory-Basedの手法は予測のために全てのUser-Itemののデータベースを利用する。またNNのような統計学技術を必要とする。 Model-Basedの手法は最初にUserのModelを作成する。例えばBayesian Network、Clustering、Rule-base approace、Classification、Regression、LDA等。 Netfilix PrizeでのModel-Basedから学んだことはとても高い精度であり、改善の精度が10%あったこと。 2007年のPrizeではTop2のアルゴリズムがSVD(RMSE:0.
[etc] : Criteoが発表したCross Device Advertisingのreportを読む アドテクノロジー プロフェッショナル養成読本 ~デジタルマーケティング時代の広告効果を最適化! (Software Design plus)
作者: 簗島亮次,佐藤裕介,松田佑樹,時吉啓司,石黒武士,小川卓出版社/メーカー: 技術評論社発売日: 2014/04/16メディア: 大型本この商品を含むブログ (4件) を見る
Cross Device Advertising Cross-device advertising: How to navigate mobile marketing's next big opportunity | Criteo
リターゲティング広告の分野で最強と言われているCriteoが2014年の9月に書いているCross Device Advertisingのreportについてまとめを書いておきます。そもそもCross Deviceって何よっ思った方の為にも簡単に説明を書いておきますが、個人が複数のデバイスを利用してインターネットをしているとタッチポイントが分散してしまうので、個人の興味を解析してAdを配信したいサービスにとっては断片的な行動ログをそれぞれの端末から得るより、複数のデバイスを利用している人を1個人として特定できたらいいよねって話です。現状の識別情報については1ブラウザの特定はCookie、1端末の特定はIDFA、1ユーザーの特定はUserIDで行われているのが一般的で、これらは纏めた管理ではなく基本的に独立して扱っています。UserIDを使うと特定サービス内において複数デバイスを紐付ける事も可能なんですが、UserID自体が各メディアサービス(FacebookIDやTwitterID等)の識別子であるため、メディ側での利用に限定される事とAd配信サービス側は直接知る事ができないので扱いづらいとされています。
複数デバイスの解決をテクノロジーを使って推し進める上での気をつけなければいけない点は"インターネットユーザーの不快"と"個人情報保護"とされています。個人情報についてはどこまでなら許容可能という線引きを国が握ってしまっているのでそこは法律に従うしか無い状況です。数年前から個人情報を一切利用せずにCookieの代替IDを生成する41st Parameter社のADTruthやtactadsというSolutionにも注目が集まって来ていますが、今のところ精度はまだまだという感じのようです。
AdTruthとは? | AdTruth
Cross-device advertising solutions
Criteo Report / Technology and Tracking : Volume vs. Accuracy 結局最後まで読んでみて目新しい話はあまりありませんでしたが、User識別の精度が低いと広告費用や機会損失をしているというメッセージが良く伝わってきました。 簡単にまとめるとCross Deviceによる広告配信はまだまだこれからということだと思います。 一部ですが重要だと思った事を意訳メモします。
スマートフォン、タブレット、ラップトップのようなモバイルデイバスを40億人が利用する時代である。 Cross Deviceの広告配信による収益は素晴らしい物になるはずだが、市場関係者はCross Device識別は技術的に難しいものになると考えている。なぜならばプラットフォームをまたいで分析する事が現状はできないから。 60%の人が複数のプラットフォームを利用している。それはdesktopを使っているアカウントに比べ凄く多くなっている。またTVを見ながらタブレットを使うようなケースも珍しい事ではない。 インターネットユーザーは流動的にデバイスを使い分けるのでますます難しい問題になるが、ちゃんと識別して広告を配信しないと無駄な費用を使ってしまう。間違って識別してしまうと複数人のように扱ってしまう。 インターネットユーザーは昼にPCで探して、更にスマートフォンでも探して、最終的には翌日にお家のPCで買うようなケースがあるから、市場関係者はこういった問題を解決するために複数のデバイス分析をちゃんと行い、いつどこでどれだけ商品が購入されるかを予測しないといけない。 モバイル広告をうまく展開できない3つの障壁として、ユーザー属性が取得できない、デバイスを跨ぐ消費者をうまく識別できない、サービスの最適化やパフォーマンスが低いのでコンバージョンが低いことが挙げられる。 2016年には年には消費者がモバイルを使う率が44.
[etc] : 検索Crawlerを作る Solr in Action
作者: Trey Grainger,Timothy Potter出版社/メーカー: Manning Pubns Co発売日: 2014/04/05メディア: ペーパーバックこの商品を含むブログを見る
Nutch + Solr + Hbase + Zookeeper Nutchで特定のWebPageをCrawlingしてSolrのIndexを作ろうとした時にかなり嵌ってしまったので作業のメモを記録しておきます。(※タイトルに語弊があるようですが、検索Crawler自体を作るという話ではありません。)特にNuth/Hbase間のVersion依存があるので、installしてみたけど動かなかったという人の参考になればと思います。Webを色々と探してみるとNutch2.2.1とHbase0.90.Xを組み合わせると良いようです。僕が試してみた環境は以下のものです。因にZookeeperは個別にinstallする必要は無いようです、Hbaseを起動するとZookeeperも実行されます。
OS : CentOS 6.4 Java : 1.7.0_51 Nutch : 2.2.1 Solr : 4.7.0 Hbase : 0.90.6 Zookeeper : 3.4.6 またNutchのTutorialに関しても注意が必要です。Webで紹介されているものは1.X系のものが多く、Crawlingのコマンドも掲載されているものをそのまま実行するとdeprecatedされていて動かなかったりします。NutchのVersionを確認して必要なTutorialを参照するようにしましょう。 特に一番したのリンクのCommandLineOptionsに記載されているVersion毎の×印を参考にすると良いでしょう。
NutchTutorial - Nutch Wiki Nutch2Tutorial - Nutch Wiki CommandLineOptions - Nutch Wiki Setup 基本的にはどれもWebから圧縮ファイルをdownloadして解凍し、設定ファイルの変更と起動コマンドの実行により動きます。ここではJavaは既に設定されているものとして話を進めます。
[Android] : Android Studioを入れてFacebookSDKのLogin機能を使うまでの作業記録 Android StudioではじめるAndroidプログラミング入門
作者: 掌田津耶乃出版社/メーカー: 秀和システム発売日: 2014/04メディア: 単行本この商品を含むブログ (2件) を見る
Android Studioの導入以降 柄にも無くAndroid Appliの開発に手を染め始めた@yutakikucです。
Android Appliの開発をする為にはEclipseかAndroid Studioを導入すると良いようです。ぐぐってみると断然Eclipseのドキュメントが多いようですが、EclipseはGradleというAndroid Appliをビルドするツールが導入しづらいとの事で、僕はAndroid Studioを選びました。Android Studioの導入はdotinstallに詳しく載っているので、僕と同じ初学者の方は一度参考にする事をお勧めします。Androidアプリ開発入門 (全12回) - プログラミングならドットインストール またschooでも同じような講義が公開されていますがGradleに対する説明がある冒頭だけ見れば良いと思います。その他はdotinstallでOK。Android StudioではじめるAndroidアプリケーション実践入門 - 無料動画学習｜schoo（スクー）
dotinstallで無料会員で視聴できるのはMyActivity.Java、activity_my.xmlを編集してボタンを押下した時に画面に表示する文言を変更するという所までです。アプリの細かい開発の動画もあるようなんですが有料会員でないと利用できません... Oh...。Javaにビジネスロジック書いて取得したデータをViewに反映したいという欲求を満たす為に今日は自分で試してみた事を記録しておきます。
尚、僕が試している環境は以下の通り。
PC : OSX 10.9.4 Android Studio : Beta 0.8 FacebookSDK : 3.17.1 FacebookSDKの設定 Facebook SDKのImport Android用Facebook SDKスタートガイド
Getting Started with the Facebook SDK for Android (Android Studio)
[調査] : 類似度計算と転置Indexとb-Bit Minwise Hashing Recommend Engineでの類似度計算 RecommendEngineを作る時の話。アイテム間の相関を計算する為にユーザーの購買データからJaccard係数やCos類似度を求める手法が一般的です(アイテム×ユーザーTableと、アイテム×アイテム相関Tableが必要)。しかしアイテムの個数(N)×ユーザー数(M)の行列を作り、Nの中から2つのアイテムを取り出してそれぞれの係数や類似度を求め、それを個数分繰り返していたら行列が大きくなる程計算が大変になります。特にアイテムの購買という行為がほとんど発生しないので、購買のベクトルがほとんど0となる疎ベクトルが作られて効率が悪く感じられます。一時期はこれを回避する為にベクトル数を減らす(購買データが多いユーザーに超超限定する)事で回避していたんですが、ユーザーが偏るしデータも少なくなってしまう事を問題として認識していました。そこでデータ数を減らすよりもっと色んな方法あるっしょって事で調べてみました。
レコメンドにおける類似度計算その傾向と対策 #DSIRNLP 第4回 2013.9.1 // Speaker Deck
転置Indexを使う手法。特定のアイテムAを買ったUser一覧をIndexから引き、User一覧が買った商品一覧を引いて来てアイテムA以外の共起回数を計算する。この方法では共起回数の計算はそこまで大変ではなく、アイテム数とユーザー数の両方が増えても処理時間への影響が小さい(らしい)です。
b-Bit Minwise Hashing
b-bit miniwise Hashingという手法。ハッシュ関数(MurmurHash3等)を使って2つのアイテムの全ベクトル要素に対して適用し、それぞれの最小の値が一致する確率はJaccard係数と等しいという理論から導きだされます。ハッシュ関数だけ共有すれば分散処理も行ける優れもの。b-bitというのは保存するbit数の事でMurmurHash3の下位1bitで良いようです。ただしハッシュ値の衝突が生じるので衝突確率を補正した値をJaccard係数とするようです。
自分が詳しく把握していなかったのは上の2つなんですが、他に調べていて手法が見つかったらここに纏めて行こうと思います。
[Apache] : ブラウザ識別用Cookieを生成する「mod_oreore(仮)」を作ったった Apacheクックブック 第2版 ―Webサーバ管理者のためのレシピ集
作者: Ken Coar,Rich Bowen,笹井崇司出版社/メーカー: オライリージャパン発売日: 2008/09/26メディア: 大型本購入: 6人 クリック: 144回この商品を含むブログ (32件) を見る
mod_oreore(仮) ネーミングセンスが糞すぎる@yutakikucです。
アクセス履歴をLogに落として行動履歴を追いたい時はCookieに識別子を設定するのが一般的かと思います。一般的にあるCookie識別子の設定のタイミングはFWやアプリケーションのでやるというように様々パターンを見かけますが、今回はApacheのレイヤーで自動的に付与してくれるModuleを作ってみました。因に同じようなApacheModuleは幾つか存在しますが、完全なる一意性が保証されていないことやApacheのVersionで使えなかったり等、ちょっとイケテナイ感じがしたので自作してみました。※mod_oreoreとはユーザー視点で「俺だよ！俺！」っというLogに自ら足跡を残す意味で、決してオレオレ詐欺とは関係ありません。
mod_usertrack ※ 一意性に問題あり
mod_session_cookie ※ apache2.3以降で利用可能
github : mod_oreore(仮)
識別子の値にはRequestを受け付けたサーバーのIPアドレス、リクエスト時刻(タイムスタンプ:マイクロ秒)、ApacheのプロセスID、コネクションIDを重ね合わせ、最終的な出力はbase64のURLSafeな形でencodeしています。base64する前に生成した識別子を暗号化しようと思ったのですが、処理が冗長的な気がして辞めました(ソースには暗号化をそのまま残しております)。またDOS攻撃を防ぐ処理は入れていません。
設定と確認 $ sudo yum install httpd httpd-devel openssl openssl-devel $ git clone https://github.com/yutakikuchi/apache_module.git $ cd apache_module/mod_oreore $ sudo apxs -i -a -c -I/usr/include/openssl -L/usr/lib64 -lcrypto mod_oreore.c $ sudo cp conf/oreore.conf /etc/httpd/conf.d/ $ sudo vim /etc/httpd/conf.
[起業] : 常駐型受託開発の経験から 受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ)
作者: 岡島幸男,四六出版社/メーカー: 技術評論社発売日: 2008/04/08メディア: 単行本（ソフトカバー）購入: 25人 クリック: 1,381回この商品を含むブログ (91件) を見る
常駐型受託開発 久しぶりにブログを更新します。「常駐型受託開発」という言葉が正確かどうかも分からないけど、とりあえず取引先のシステムを作ってました@yutakikucです。とある会社様(クライント)の新規事業立ち上げが目的で、そのクライアント様のOfficeにお邪魔しながら約1年程携わらせて頂きました。結論から言うとこの経験が凄く身になってとても良かったと感じました。(※優秀なスタッフさんが沢山いらっしゃる環境で、とても親切にして頂いた事は厚くお礼を申し上げます。)
受託やらないほうが良いぜ！論を当然否定することはしませんし、逆に強く薦めもしませんが、新規事業立ち上げに必要な事を凄く近いところで経験できたのは今後自分が事業を立ち上げる事にもプラスの材料になったと思います。今日はこの開発現場で感じた受託開発とマネジメントについて記録するだけなので、内容的には糞つまらないことかもしれませんが、どなたかのお役に立てればと思います。因に僕の会社には社員がいないので、一人で出向いていました。
常駐型受託で良かった点、残念だった点 良かった点 自分と同じような受託社長さん達と知り合う事が出来た(ここ凄く大事)。また受託開発現場というのを肌で感じれた。 自分の技術力の立ち位置を把握できた。また技術力よりも人間力/信頼力が仕事を得る材料である事も理解できた。 常駐する事で社員さんとのコミュニケーションが密にできたし、認識の大きな間違いも少なかった。 事業立ち上げフェーズから入れてもらえた事で社員さんと同等のStartUPの進め方のノウハウを身につける事ができた。 0からのスタートなので、幅広く必要なシステムの根幹を作り込んだ。またその仕組みをいち早く作れるように考える頭も身につけた。 注文請書、請求書等のやり取り作業を全部自分で経験できた。契約面で質問したい内容があれば直ぐに現場でも解消する事が出来た。 残念だった点 常駐型+時間契約だったので労働時間の対価を得るような内容になってしまった事。またそれによって時間的な拘束が多く発生してしまった事。これにより他社からの開発を受けられなくなってしまった。 受託に重きを置きすぎて自社開発に手がつけられなくなってしまった事。(僕はここの比率を途中で変更してしまったのだが、最初に決めた信念を貫く必要があると感じた。) 決められた方針に反論しづらい、また自分が思った改善策や良いアイディアを率先して現場に浸透させづらい。どうしても所詮受託の意見という考えが浮かんでしまう。 イベントや勉強会で直接的な成果を発表しづらい。発表する場合はコアな話は出来なく、概要レベルもしくは一般論に置き換えて話す必要がある。 頑張った事に対する評価についてあれこれ考えてしまう。 受託エンジニアの種別 受託エンジニアと言っても様々な背景を持った人と知り合う事ができたのでそれもプラスの材料になりました。今回の現場では受託エンジニアご本人が別の会社に所属しているか否(独立している)か、採用に紹介会社がいるのか否かという2×2の4パターンありました。凄く失礼な話かもしれませんが、この区分けによりなんとなーくのエンジニア特性が見れて取れたように思います。ここでも書けるような内容としては個人を見た場合、会社所属の人たちは要件の抽出とそれを具体化する力、独立している人達は何かやったるぜー！という野心と個性が強く見れた気がします。マネジメントをする人はご自身で特性を見つけ出して知っておくと良いかもしれません。ここはもっと詳しく書きたいんですがこの辺まで(笑)
受託の人数 現場で社員を雇えない状況で今直ぐ対応する人が欲しい場合は受託の人数を増やすのが手っ取り早いですが、その人数が増えすぎるとマネジメントが確実に行き届かなくなります。これはどんなに優秀な社員マネージャーがいたとしても受託に対する指示を一人ずつに細かく伝えるのは不可能であり、結局のところ一番コミュニケーションが発生するのは社員マネージャと受託では無く、機能担当の社員エンジニアと受託の直接になります。この社員さんのコミュニケーションコストが半端無い。仕様の伝達、ソースコードレビュー、改修依頼等、ただでさえ忙しい社員エンジニアさんもその辺のサポートに相当な工数が掛かってしまいます。今回の経験での一つの指標として、どんなに苦しい状況でも社員エンジニアの数より受託の数を増やすことはNGであり、更に言うと理想的には受託人数が社員数の半分より小さくなるように採用すべきかと思いました。もしそれでも人数対工数の折り合いが付かないのであれば、常駐型だけではなくマネジメントを含めて外部委託会社に依頼する、そもそものリリーススケジュールを見直すか機能の削ぎ落としや簡略化を図るのが得策と思います。大事なので2度言いますが、単純に常駐型受託の人数を増やすのはマネジメントのリスクが大きくなります。あと、受託に重要な機能を任せると後々いなくなってしまった時に大変な事になるので、機能の重要度で委託するかどうかを考える事が必要だと思います。
紹介業者の戦略 僕も最初は受託を1人採用するのは紹介会社1社を経由するケースしか無いのかと思ったのですが、実際には間に紹介会社を2,3社挟むケースもあってその分受託サラリーのマージンが引かれているようです。このケースで美味しい思いをしているのは間にいる紹介業者だけであり、発注元は金額が高くなるし現場で頑張っているエンジニアの労は報われません。人材だけでなく仲介業全般での当然の話なんでしょうけど、このシステムってなんとかならないんでしょうか。受託の士気を上げる為にも常識的なマージンであって欲しいと強く希望します。
紹介会社は既に送り出している受託の人から都度現場状況をヒアリングして、更に人数を増やせるか、そしてどれぐらいのレベルのエンジニアなら長期採用されるのかというのを把握しています。紹介会社としても当然長く現場にいて欲しいという希望があるので、今求められているスキルと新たに送り出せる人のマッチング具合が気になるのだと思います。ある程度の採用単価が保証される事も当然前提の一つですが、ちゃんとした技術基盤があり高い目標を常に持ち続けられるいい環境という情報がうまく紹介会社側に伝われば優秀なエンジニアが来てくれる可能性は高まります。逆に炎上状態やスキル面での低レベル感が伝わると当然紹介会社もハイエンドな人材を送り出したいとは思わなくなってしまう。後者に嵌ってしまうと現場としては完全なる悪循環ですよね。
[C] : 男なら潔くC言語書けよと言われた話。〜mod_db,mod_dbdの実装〜 C実践プログラミング 第3版
作者: Steve Oualline,望月康司(監訳),谷口功出版社/メーカー: オライリー・ジャパン発売日: 1998/06/15メディア: 大型本購入: 7人 クリック: 158回この商品を含むブログ (45件) を見る
恩師に言われた言葉 Geek女優の池澤あやかさんに会いたいと思っている@yutakikucです。
池澤さんはRubyが出来てSFCで女優さんなんて羨ましいですね〜。僕なんてRubyは得意じゃないし東京とは言えないような都心から離れた場所の地味な国立大だし、何よりお金も無いパンピーだしね〜。
僕の学生時代にもRubyはあったんですけどRailsはまだ出始めでそんなに流行っている雰囲気は無かったし、Webを書くには面倒くさいJSP/ServletかPerlかって感じでした。ApacheのModuleでWebを書ける事も学生ながら知っていたんですが、ポインタ、メモリの動的確保/解放の間違いが頻発して開発効率が落ちるから極力Javaで、どうしてもCを書かなければ行けない時はC++で逃げてました。
でも学生時代に恩師に言われたんですよね、JavaやPerlを書く奴はチャラいやつと。男なら潔くC言語書けよと。 (因に恩師はJavaとJavascriptの違いも良く理解していなかったと思いますけどww) おそらく恩師が言いたいのは学生の時から高級言語に頼る事無く、まずはプログラミングの仕組みを理解するためにC言語で苦労してエキスパートを目指せっていう意図だったと解釈しています。
C言語をやると他の言語と違って問題の発生率が高い。 要は言語側であまり頑張ってくれないから自分で工夫する必要があります。特に他のコンポーネントに接続する時には接続数の制御/ポートの使い切り、ConnectionPoolの実装、使用メモリのオーバー、良く分からないSegmentation Fault等必ず経験します。こういった問題解決の経験値をつける事でエンジニアの実力が養われるのだと思います。
恩師の言葉を信じてCの勉強を重ねた結果、会社の開発チームに配属された時は凄く重宝されましたし、極力PHP以外を書く案件を回して貰えました。だからCを勉強して来て良かったと思ってます。しかし今後C言語はどうなるんでしょうか... 身の回りではゲーム系、広告配信エンジニア以外は触って無さそうです。その他の言語が強力で簡単WebアプリぐらいだとCで頑張って書くとか全く無いんですよね。学生の勉強の仕組み理解と違って会社は効率化や作業時間短縮を掲げてくるのでC推しも難しいですね。
前置きが長くなりましたが、それでも僕はCを触る事が多いのでこのエントリーではC言語からのDB接続について書きたいと思います。
DB接続 mysqlclientを使った自作ApacheModule mod_db.c mysqlclient,prepared stmtを使ったApache Moduleのmod_dbは以下になります。完全なる自作なのであまり自信が無いですが、並列テストをしてもSegmentation Faultは発生しませんでした。下のソースではbindしたいparameterとresultをmemsetで設定するところが分かりづらいのと、Pointerの設定を間違えてmemory errorを起こし易いので注意が必要です。このプログラムの駄目な点はmysql_real_connectで都度Connectionしているので、接続のOverHeadが大きいところです。実際にabでbenchmarkを取ってみるとCommand Connectが多く発生していますし、netstatでも大量のTIME_WAITが出てます。都度接続の方式で頑張る場合は、TIME_WAITが残り続けると実行Port不足に陥って処理が進まなくなる可能性があるので、/etc/sysctlのnet.ipv4.tcp_tw_recycle=1に設定してリサイクルを速く回す設定を入れるか、net.ipv4.ip_local_port_range = 1024 65535のように使用可能なPortを増やすかのどちらかが有効になりそうです。ただしsysctlの設定をチューニングする場合は十分にテストすると良いと思います。
$ sudo yum install mysql-devel -y $ sudo vim /etc/httpd/conf/httpd.conf IfModule mod_db.c DBHost localhost DBPort 3306 DBUser root DBPass root DBName helloworld DBTableName hello /IfModule $ sudo apxs -i -a -c -I /usr/include/mysql -L /usr/lib64/mysql -lmysqlclient mod_db.