AWSアドバンスドコンサルティングパートナーの一員として活動する株式会社スタイルズが、AWS導入、移行、開発、セキュリティ、運用保守など、すべてのご相談に乗らせていただきます。 AWSを導入したいが何から始めたらいいかわからない 既存のベンダーが新技術に弱く、良い提案がもらえない クラウドの導入にセキュリティの不安がある AWSをとりあえず導入したが、さらに活用していきたい 社内にAWSの知見を持っている人がいない AWSならではのシステム開発を詳しく知りたい

数日繰り返してきましたがようやくsennaのインストールが成功しました。 MySQLの設定等はまだですが、いちおエラーもなく終了。 インストールまでの軌跡を自分メモします。 [環境］ OS：FedoraCore6 Mecab0.95 senna1.0.3 MySQL5.0.37 まず、MySQLのユーザーを登録。これを忘れるとちょっとひどい目にあうかも？！ #groupadd mysql #useradd -g mysql mysql groupaddコマンドでエラー。not foundとかって怒られる。 調べて見ると、どうやら su だけでrootになるとエラーになるらしい。 su　-　　　もしくは　su root できちんとrootになるとうまくいった。 ［mecab0.95　インストール］ wget http://downloads.sourceforge.net/mecab/mec

symfony1.0.XでPropel1.3のDBレプリケーションが使いたい！という理由だけでsfPropel13Pluginを導入してみたので簡単に手順をまとめておきます。 インストール SVNリポジトリからプラグイン本体をゲットすれば終了です。チェックアウトでもいいと思いますが、1.2ではデフォルトでPropel1.3が導入されていることから、もう更新はおそらく無いので自分のリポジトリに入れるようにexportしてます。 $ svn export http://svn.symfony-project.com/plugins/sfPropel13Plugin/ plugins/ 導入(基本編) まずdatabase.ymlをPropel1.3仕様に書き換えます。dsnの仕様はPHP: PDO_MYSQL DSN - Manualを参照してください。 all: propel: class:

ざっと試した感じ以下の3点が気になったので、とりあえず動くようにしてみました。 databases.ymlのencoding指定が無視される。 デバッグツールバーにSQLが表示されない。 Propel1.3で正式対応しているReplication設定ができない。 <?php class myPropel13Database extends sfPropel13Database { public function initialize($parameters = null, $name = 'propel') { parent::initialize($parameters, $name); if (sfConfig::get('sf_debug') && sfConfig::get('sf_logging_enabled')) { Propel::setLogger(myPropel13L

# mkdir /usr/local/symfony # cd /usr/local/symfony # wget http://www.symfony-project.org/get/symfony-1.0.19.tgz # wget http://www.symfony-project.org/get/symfony-1.1.6.tgz # wget http://www.symfony-project.org/get/symfony-1.2.0.tgz # tar zxf symfony-1.0.19.tgz # tar zxf symfony-1.1.6.tgz # tar zxf symfony-1.2.0.tgz # ln -s symfony-1.0.19 1.0 # ln -s symfony-1.1.6 1.1 # ln -s symfony-1.2.0 1.2 $ al

Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ

WEB製作者の為のSEOチートシート SEOmozで配布されているSEOチートシートが素敵ですので日本語にしてみました。 重要なHTML要素 title要素にキーワードを含みましょう。 h1,h2,h3要素にキーワードを含みましょう。 b要素、strong要素でキーワードを包みましょう。 img要素のalt属性、ファイル名にキーワードを含みましょう。 a要素のtitle属性、アンカーテキストにはキーワードを含ませましょう。 a要素のnofollowを上手に使いましょう。 インデクシングに関する限界 ページのファイルサイズは150KB以下にしましょう。 ページ内のリンクは100個以内にしましょう。 title要素は70文字(半角)以内にしましょう。 meta要素のdescriptionは155文字（半角）以内にしましょう。 URLの含まれるパラメーターは2個以内にしましょう。 ディレクトリの

このレポートは、サイトが獲得しているキーワードベースの検索トラフィックについて、その健全さと分布を視覚化する検索マーケティング用のツールだ。上で示したのはSEOmozの過去40～50日のデータだ。マウスをグラフに沿って動かしていくと、参照数上位25％は、それぞれ50人以上の訪問者を獲得している検索キーワードからだということがわかる。それに対して、下位25％（実際にはもっと）では、各検索フレーズが示す検索ビジター数はそれぞれたった1人だ。これは、ロングテールの力と重要性を明らかにしているだけでなく、データが不足して困っている多くのマーケティング部門を、説得力のある材料で支援するものでもある。 僕らは最近、いくつかの大きなウェブ資産を任されるようになった。そして、かなり大きなサイトを持っている人ならだれでも知っているとおり、その規模を担う訪問者はすべて、テールの中にいる。そこで、ロングテールの

ページの重要度を推し量るために、ウェブ上に広がる個々のリンクをどのように評価するのが最も望ましいか（検索利用者に快適な検索体験を提供できるか？）。一連のPaid Links（有料リンク。キーワード型のテキストリンク広告。具体例を知りたい方は、Matt Cutts氏によるプレゼンテーション資料を参照（.ppt、パワーポイントのファイル））に対するGoogleの対応を追っていくと、彼らの説明は時期によって根拠や理由が異なっているし（＝Googleとしても明確なポリシーが決められていなかった）、少なくともサイト運営者にとって目安となる程度のガイドラインを引いていなかった。何より、Googleを含む検索会社はこれまで、サイト運営者に対するリンクスパムの考え方として「クローラの利益にしかならないリンクはスパム」（＝ユーザの利益を考えなさい）というのを提示してきたため、少なくともSEO業界の側からは「