タグ

2011年6月20日のブックマーク (9件)

  • IBMの企業Twitterアカウントは30以上、全社員が自由に活動するためのガイドライン/日本IBM | 企業担当者に聞くFacebook&Twitter運用の現場

    「一般消費者の方との接点としてTwitterのようなソーシャルメディアが使えるのではないかと考えたのがきっかけです。企業ホームページのトップから情報を探すスタイルから、検索エンジンやSNSから情報にたどり着くユーザーが増えてきていると思います。B2Cビジネスの会社ではないのですが、それでも会社としてどのような取り組みをしているかを、一般ユーザーのみなさんに知ってもらいたいと思いTwitterアカウントを開設しました」 Twitterアカウントの運営部門は企業によってさまざまだが、社内広報部門が担当するのは珍しいケースだ。栗原氏がTwitterを運営するのはどういった理由があるのだろうか。 「TwitterのIDは早い者勝ちなので@IBM_JAPANというIDを2年ぐらい前に取得していました。私は社内広報を担当しているので、社外広報チームのメンバーに『@IBM_JAPANのアカウントを取った

    IBMの企業Twitterアカウントは30以上、全社員が自由に活動するためのガイドライン/日本IBM | 企業担当者に聞くFacebook&Twitter運用の現場
    naney
    naney 2011/06/20
  • MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店

    MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という

    naney
    naney 2011/06/20
  • GitHub時代のオープンソース・プロジェクトとの付き合い方

    GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS

    naney
    naney 2011/06/20
  • かぜの科学―もっとも身近な病の生態 - 情報考学 Passion For The Future

    ・かぜの科学―もっとも身近な病の生態 これは素晴らしい。全人類に強くおすすめ。 統計によると私たちは一生に200回風邪をひくそうだ。成人は少なくとも年に2回、小児は10回以上かかる。 「もちろん、一回一回の罹患そのものは大したことではない。けれども、一人の人が平均寿命のうちにこの取り立てて悪性でもない病原体に苦しむ期間を合計すれば、およそ五年間にわたって鼻づまり、咳、頭痛、喉の痛みに襲われ、おおまかに言って一年間床につく計算になる。」 全人類が長い間悩まされてきた風邪には俗説の療法も多い。どうするとうつるのか、どうすると予防できるのか、どうすると治るのか。このは科学的観点からいえることを整理してくれる。 一般常識を打ち破る事実も多く、目からうろこなである。 たとえば、 ・咳やくしゃみによって発生する飛沫が風邪を広めるという証拠はないに等しい ・鼻をかんでも鼻が詰まった感じはとれない(鼻

    naney
    naney 2011/06/20
    「なによりも風邪を予防するには、手を洗って、顔を触らないこと。」
  • Google

    世界中のあらゆる情報を検索するためのツールを提供しています。さまざまな検索機能を活用して、お探しの情報を見つけてください。

    naney
    naney 2011/06/20
    みんなソックリですね?
  • mixi, Twitter, Facebook 2011年5月最新ニールセン調査、Facebook利用者820万人へ:In the looop:オルタナティブ・ブログ

    mixi, Twitter, Facebook 2011年5月最新ニールセン調査、Facebook利用者820万人へ 6月18日に、2011年5月度のニールセン・インターネット視聴率が発表された。震災の反動で3サービスとも利用者が減少した4月と比較すると、5月度はサービス間の明暗がはっきりと出た一ヶ月となった。 データ元は、ネットレイティングス社提供によるインターネット利用動向調査「Neilsen/NetRatings NetView」サービス。対象は「一般家庭および職場のPCユーザー」としている。 利用者数でいくと、mixiは1287万人(前月比103%)と微増、Twitterは1466万人(同95%)と減少、Facebookは820万人(前月比118%)と大幅増加となった。ただし、ペーシビューや利用時間では、引き続きmixiが他を圧倒している。 Twitter訪問者数には専用クライアン

    mixi, Twitter, Facebook 2011年5月最新ニールセン調査、Facebook利用者820万人へ:In the looop:オルタナティブ・ブログ
    naney
    naney 2011/06/20
  • Perlのメモリリークを見つける方法 - Islands in the byte stream (legacy)

    Perlではメモリリーク検出ツールがいくつか開発されているので、top(1)の結果を眺めるよりそういうツールを使うほうが楽である。 さて、メモリリークが発生しているとき、その可能性としてはだいたい以下の4つが挙げられる。 Perlレベルでの循環参照 グローバル変数に値をどんどん足しているとき*1 XSレベルでリファレンスカウントの管理ミス XSレベルでmalloc()したメモリの管理ミス この1-3についてはすべてPerlインタプリタ内の出来事であり、Test::LeakTraceを使って検出できる。4を検出するのは難しいが、Test::Valgrindが役に立つ。 Test::LeakTraceのSYNOPSISは歴史的経緯によりごちゃごちゃしているが、テストで使うべき関数はno_leaks_ok()とleaks_cmp_ok()だけである。 たとえば、以下のようにして使う*2。 #!p

    Perlのメモリリークを見つける方法 - Islands in the byte stream (legacy)
  • mixiでユーザー評価(観察法)ワークショップ

    mixiさんでのワークショップも3回目。 今回はユーザー評価をやります。 終わってからデビッドに「ペルソナから入らないでユーザー評価から入るのは上手い!」と褒められた。 結果が目に見えずらい調査やユーザーモデリングよりも、はっきり成果が見えるユーザー評価を先にやってもらってセミナー参加者の心を鷲づかみにするのが今回の作戦。ww まずはタスクを考えてもらう。 ここが一番最初の関門で、特にmixiのサービスは作業ステップが多い。。 コツはインタフェース用語を使わないで、ユーザーのアクティビティを書き表すこと。 これ以外に、答えとしてインタラクションシナリオを書いて持っていると良い。 慣れないと、ついついインタフェース用語の入った答えのようなタスクを作ってしまうので要注意! タスクが決まったら、まずは自分達でゆっくりパイロットテストしてみる。 この時点でもうかなりの問題が見つかるはず。 そうする

    naney
    naney 2011/06/20
  • 第1回 2011年「あけおめアクセス」の対策と結果 | gihyo.jp

    はじめに はじめまして。(⁠株)ミクシィのシステム部 運用部でアプリ運用を担当している小池知裕です。mixiのシステムの運用/管理業務に従事しています。連載では、3回にわたってmixi.jpでのシステム運用業務の裏側を紹介します。 ミクシィの運用部のシゴト 最初に、(⁠株)ミクシィの運用部という組織について簡単に説明します。運用部には「アプリ運用」「⁠インフラ」「⁠バックオフィス」の3つのグループがあり、それぞれ「ソフトウェア面での運用/管理/改善」「⁠ハードウェア面での運用/管理/改善」「⁠購買/資産管理」の業務を担当しています。 そのほか、同じシステム部には技術部があり、さまざまな研究開発を行う研究開発グループやmixiの大規模障害で有名になった、たんぽぽグループなどがあります。 連載では、筆者が所属するアプリ運用グループで、mixiサービスのソフトウェアをどのように運用/管理

    第1回 2011年「あけおめアクセス」の対策と結果 | gihyo.jp