タグ

mixiに関するsbg3のブックマーク (57)

  • mixiの新人研修トレーニングが非常にわかりやすくて実践的すぎる - Android Javascript iOS

    mixiは新人研修用のトレーニングをgithubに公開しています。 公開していることは知っていたけれど、いざみてみると… とってもわかりやすく実践的!!! 普通に参考書で勉強するよりも企業が公開しているものだから、より実践的という感じもします。 自分はこのAndroidTrainingをやっているのですが、最後に課題もあり、到達度や理解度もすごく把握できていい感じです。 READMEもかなり充実しており、一通りを学べるように工夫されています。 mixiに入社した方がこれを一通りやったと思うと、大変な印象ですが…だからこそやったときに達成感がありそうです。 開発環境の構築から書かれているので、ほとんどつまづくことはありません。 かなり詳しくわかりやすく書かれている印象を受けました。 ちょっと初めて学習するには、難しい箇所もありますが適宜ぐぐって補えばよいでしょう。 ・AndroidTrain

    mixiの新人研修トレーニングが非常にわかりやすくて実践的すぎる - Android Javascript iOS
  • mixiのサーバOS移行のお話 - ビルド&Kernel編 - mixi engineer blog

    こんにちは。年末と年度末になるとブログを書きたくなる運用部アプリ運用グループの清水です。 気づけば前回の記事から3ヶ月が経過してしまいました… 今回は、ビルド&Kernel編と題して、Fedora 17向けにおこなったパッケージのビルドや、KernelのConfig、TCP周りの変更点について紹介したいと思います。 パッケージのビルド OSが大幅にバージョンアップすると、依存しているライブラリに大きな変更が入ったり、RPMの仕様変更もあるため、Fedora 8時代のパッケージのリビルドなど、多くのRPMパッケージを作りなおさなければなりません。 mixiでは、Fedora標準パッケージとは別に150個以上のパッケージを、 configureなどビルドオプションを変える Fedoraで提供されないパッケージを作る ディストリビューションに依存しない構成のパッケージを作る(あとで紹介するPer

    mixiのサーバOS移行のお話 - ビルド&Kernel編 - mixi engineer blog
    sbg3
    sbg3 2013/04/04
  • ユーザーファーストを実現するmixiの開発プロセス - mixi engineer blog

    デザインユニットUXデザイン担当の酒井です。 mixiでは昨年来、最重要キーワードとして「ユーザーファースト」を掲げ、ユーザー様のご意見やご利用状況に基づいたサービス施策の実現を素早く行えるようになるために、開発プロセスの改善を継続的に行なっています。今回は、この「ユーザーファースト」なmixiを実現するための取り組みについて、具体的にご紹介していきたいと思います。 なぜ今、ユーザーファーストなのか? 昨年11月に開催した『ユーザーファーストウィーク』で笠原社長からもご説明させていただきましたとおり、mixiというサービスが大きく成長したこれまでの数年の間に、いつのまにかユーザー様と私達との間に「ギャップ」が生まれてしまったという強い反省があります。mixiを取り巻く外部環境の変化に対応していく中で、これまでもユーザー様にとっての「心地よいつながり」とは何なのかを真摯に検討し、時流に合わせ

    ユーザーファーストを実現するmixiの開発プロセス - mixi engineer blog
    sbg3
    sbg3 2013/04/03
  • JaSST'13 Tokyo に参加して、考えたこと - mixi engineer blog

    こんにちは。 「アサシンクリード3」というタイトルから、てっきり3部作だと思って、シリーズをプレイし始めたところ、実は5部作だったという事実を知って、軽く戦慄している品質管理部門の柿崎です。ちなみに2までクリアしました。 先日、国内最大級のソフトウェアテストシンポジウムである「JaSST'13 Tokyo」に参加して来たので、レポートします。 と、思ったのですが、既に素敵なレポートがあちらこちらに存在するので、シンポジウムを通して見えてきた、ミクシィの品質保証、QAチームを取り巻く状況を書いてみたいと思います。 テストの自動化 ここ数年、「テストの自動化」はホットなキーワードであり続けています。今年のシンポジウムでも、幾つかテスト自動化に関するセッションが開かれていました。 自分の参加したセッションでは、テスト自動化の難しさや、自動化を担えるエンジニア像について議論が交わされていました。世

    JaSST'13 Tokyo に参加して、考えたこと - mixi engineer blog
  • mixiの年末年始対策2012-2013 - mixi engineer blog

    はじめまして、運用部アプリ運用グループのainoyaと申します。 今年4月に新卒で入社して以来、はじめてエンジニアブログを書きます。 この記事は、デスクトップ版も大変使いやすいFedoraから書いています。 はじめに ~ mixi vs 正月 ~ mixiを支えるバックエンドには、mixiを影で支えるエンジニアによって 大量のアクセスをさばききる頑丈なシステムが構築されていました。 ですが、年末年始にはその頑丈なシステムを打ち破るほど想定外な負荷が押し寄せてきます。 それは、月間利用者1,400万人以上のユーザの方々が、mixi上で交わす年末年始の挨拶です。 mixi vs 正月 ~ 戦いの歴史 ~ これまで、mixiのエンジニアによって行われてきた正月の負荷急増対策は、毎年毎年必ず乗り越えなければならない 戦いとして、脈々と受け継がれてきた歴史です。 それでは簡単になってしまいますが、今

    mixiの年末年始対策2012-2013 - mixi engineer blog
  • 「インタレストターゲティング」リニューアルの裏側 - mixi engineer blog

    こんにちは。下田@研究開発グループです。 前回は、かなりライトな「行って来ました」記事でしたので、今回はデータマイニング技術の活用事例の一つとして「インタレストターゲティング」という広告商品と、そのリニューアル案件についてご紹介します。 あらまし mixiには「インタレストターゲティング」という広告商品があります。まだ僕が入社する前の2009年に研究開発グループが広告の部署と協力して作成したプロダクトになります。 リリース当初は効果が高く、人気の広告商品の一つだったそうですが、メンテナンス性やオペレーション部分に問題等を抱えており、つい最近、再度広告関係の部署と協力して、バックエンドを作り直し、新しい仕組みをリリースするに至りました。 2012年12月現在、販売している広告商品としては、2009年作のプロダクトが動いていますが、間もなく切り替わる予定となっています。 以下、2009年製の今

    「インタレストターゲティング」リニューアルの裏側 - mixi engineer blog
  • 技術的負債を減らす - mixi engineer blog

    こんにちは、システム部長の松岡です。 はじめに 今回はミクシィの物作りの中で、技術的な負債を返済する取り組みの一つについてご紹介します。 ミクシィは2012年8月にユニット制に移行しました。これはユーザーファーストな開発を促進するための挑戦です。 裁量権が各ユニット長に落ちることで早い判断と実施が可能になります。 反面、ソースコードがユニットごとに完全に疎結合しているわけではありませんので、早い判断と実施の結果、他のユニットに迷惑がかかるかもしれません。 いつまでも、どの開発者も困らないような開発を進めていければ、問題ないことですが、これまでの開発で負債として溜まってきた事、今後の進め方次第でいずれ行き詰まる事があるとも考えています。 そこで、負債を解消するため or 未来に積まないための対応が必要となります。 ミクシィはとても技術に理解のある会社です。 私含め経営陣から積極的に負債を返

    技術的負債を減らす - mixi engineer blog
  • 技術的負債の把握と改善を促すために - mixi engineer blog

    こんにちは. 先日水道を止められて水のありがたみを再確認したgoccyこと五嶋@たんぽぽグループです. 今回は, 先日q_zouさんから紹介のあった技術的負債を減らす取り組みの一環で, 僕が開発したビジュアライザについてご紹介させて頂きます. はじめに 弊社では主な開発言語としてPerlを採用しており, そのソースコード量は数十万行単位に上ります. 自社で開発したライブラリ群はプロジェクトルート下のlib/Mixi/配下に設置されており, 更にその下でサービスや用途毎にNamespaceが分かれています(lib/Mixi/APIやlib/Mixi/Photo, lib/Mixi/Voiceなど). ※以降, 文章中のNamespaceという表現は, これら(lib/Mixi/APIなど)を指すものとします. 来であればNamespace単位で疎結合化されているべきですが, なかなかうまく

    技術的負債の把握と改善を促すために - mixi engineer blog
  • データ解析用ワークフローフレームワーク Honey の紹介 - mixi engineer blog

    最近,もっぱら上原ひろみさんの曲をエンドレスに聴いて癒しを得ています.もちろんピクルス作りも最高です.みなさんは何で癒しを得ていますでしょうか.こんにちは,技術部の石川有です. 以前,「mixi の解析基盤とApache Hive での JSON パーサの活用の紹介」で mixi における Hadoop/ Hive の活用の仕方について記事を書かせていただきました.今回の記事では,ちらっと触れていた Hive などで定期実行する必要のある処理をワークフローとして定義するフレームワークについて書きます. 文章の構成 まず最初に,今回ご紹介するデータ解析用ワークフローフレームワーク Honey とは何か,なぜ作ったのかを説明します.つぎに,どのような構成や機能があるのかを簡単に説明します.それから具体的なデータ解析処理を記述する方法について説明します.その中で,定型的な処理を YAML とし

    データ解析用ワークフローフレームワーク Honey の紹介 - mixi engineer blog
  • Perl Oceanとmixiのチャット機能トライアルの紹介 - mixi engineer blog

    大槻唯が好きすぎて辛いlapis25です.エンジニアブログをはじめて書きます. この記事では,リアルタイムコミュニケーションフレームワークスイート Perl Oceanの紹介と,Perl Oceanを用いて開発した,mixiのチャット機能のトライアルについて紹介したいと思います. XMPP まずは,Perl Oceanのコア技術である,XMPPの概要を軽く説明します. 1990年代後半からYahoo! Messenger,Microsoft LiveやAOL AIMなどさまざまなメッセンジャアプリが開発されていましたが,それらのアプリは独自の仕様によって作られていました.メッセンジャに要求される仕様を標準化するためにJabberが生まれました.Jabberは名前をXMPP(Extensible Messaging And Presence Protocol:拡張可能なメッセージとプレゼンス

    Perl Oceanとmixiのチャット機能トライアルの紹介 - mixi engineer blog
  • mixi の解析基盤とApache Hive での JSON パーサの活用の紹介 - mixi engineer blog

    こんにちは.最近ピクルス作りで精神統一をしている,たんぽぽグループ解析チームの石川有です. このブログではお馴染みのたんぽぽグループですが,"No More 「刺身の上にタンポポをのせる仕事」 - 単純作業の繰り返しで開発者の時間を浪費しないために。"というミッションを持っています.その中で解析チームは,データ解析基盤の構築,データマイニング,データ解析の社内コンサルティングを行ない技術からの改善を担当しています. 今回の記事では,mixi における解析基盤について簡単に触れたあと,その基盤における「刺身の上にタンポポをのせる仕事」をどう減らすかの2点について書きます. mixi の解析基盤 まずは解析環境について,簡単にお話します.2012-08 現在 mixi では,主な解析用のツールとしては,Apache Hadoop, Hive を利用しています.またあわせて,自分など一部の人は,

    mixi の解析基盤とApache Hive での JSON パーサの活用の紹介 - mixi engineer blog
  • mixiのコードレビューについてご紹介 - mixi engineer blog

    こんにちは技術部たんぽぽグループのmasartzです。でも今日はコードレビューアのmasartzとしてお送りします。 mixiの開発フローにはコードレビューという工程が含まれています。 今回はこの工程を行うコードレビューアな人々と、その業務内容、今後(の予定)などをお話しようと思います。 コードレビュー業務 mixiのサービスがスタートしたのは2004年2月の事ですが、コードレビュー業務が始まった正確な日時は残念ながらわかりません。 レビューツールもemailのやりとり->Tracのチケット->JIRAチケットと変遷があるため、最古のものをトラッキングできないのですが、おそらく5年以上前から様々な変遷を経て、今に至ります。 開発者が増えると、開発されるコード量も増えます。つまりレビューする量が増えるため、コードレビューアも増加します。 そんなこんなで現在ではアプリ開発者に対して、コードレビ

    mixiのコードレビューについてご紹介 - mixi engineer blog
  • Jenkins 勉強会で発表しました - mixi engineer blog

    システム技術部たんぽぽグループの加藤和良です。すこし前の話になりますが Software Design 2012年2月号 にテストのはなしを書きました。gihyo.jp から全文が読めますので、ぜひご覧いただければと思います。なお、現在発売中の2012年3月号にも弊社の佐藤が寄稿しています。 この記事がきっかけになり、先日おこなわれた 第五回 Jenkins 勉強会 でも発表の機会をいただきましたので、その スライド を公開します。 会場の識字率の高さを考慮し (話すことを一字一句書くと先に読まれてしまうので) スライドは文字少なめで作りました。これだけ見ても何を話したかよくわからないと思うので、いくつか補足します。 Jenkins で Perlプロジェクトを管理する はじめに、Jenkins で Perlプロジェクトを管理するための、一般・基的な部分について説明しました。J

    Jenkins 勉強会で発表しました - mixi engineer blog
  • 第1回 バーストトラフィックの発見と対処 | gihyo.jp

    はじめに 初めまして、(⁠株)ミクシィの中野和貴です。私はシステム部運用部インフラグループネットワークチームという部署で働いており、ほかのメンバーと共にmixiのネットワーク部分全般に関して設計・保守・運用を行っています。ここでは『WEB+DB Press』Vol.50~55にて連載されていた「大規模Webサービスの裏側」で紹介しきれなかったエピソードや、その後のインフラ事情を紹介していきます。 日々大量のトラフィックが流れるmixiのネットワークですが、大きくなってくるとやはりいろいろな問題も出てきます。今回はそれらの問題の中で普段運用しているとなかなか気付きにくいバーストトラフィックに起因する問題事例を紹介します。 ミクシィのネットワーク構成と問題の発覚 mixiでは主要なネットワーク機材にはお金をかけていますが、サービス規模からどうしてもラック数が多くなってしまうため、エッジスイッ

    第1回 バーストトラフィックの発見と対処 | gihyo.jp
  • mixiエンジニアがおくるソーシャルアプリ開発実践講座:第3回 自動テストと継続的インテグレーションを既存プロジェクトへ導入しよう|gihyo.jp … 技術評論社

    はじめに はじめまして。(⁠株)ミクシィの加藤和良です。2008年度に入社し、2011年1月からはシステム技術部に所属しています。技術部は、日記やコミュニティといった特定のサービスに紐づかない、mixi全体を裏から支える部署です。「⁠支える」ための方法は、実際のサービスの一部として動作する共通基盤から、開発効率を上げるために社内で動作しているものまで、多岐にわたります。 mixiでは、ここ数年で自動テストの導入が急速に進みました。図1は、mixiのソースツリーにおけるコードと、そのテストコードの毎月1日のバイト数をグラフにしたものです。2008年の頭には少なかったテストが急速に増え、今年の5月にはコード量をも追い越しているのがわかります。 携帯電話向けmixiである「mixiモバイル」の開始が2004年、mixiニュースが2006年ですから、2008年当時のmixiも、それなりに大き

    mixiエンジニアがおくるソーシャルアプリ開発実践講座:第3回 自動テストと継続的インテグレーションを既存プロジェクトへ導入しよう|gihyo.jp … 技術評論社
  • ミクシィのアプリケーションセキュリティの代表的な取り組みについて - mixi engineer blog

    こんにちは、opera 大好き 松岡 剛志 です。今日は部長職ではなくて、セキュリティチームリーダー立場でブログを書いています。 今回は弊社の様々なアプリケーションセキュリティの取り組みのうち、以下の4つのコンテンツについて書きます。この内容はほとんどが弊社のセキュリティイベントである Scrap Challenge で使われたスライドの焼き直しです。 トレーニング セキュリティレビュー コードレビュー セキュリティチェック トレーニング 現在ミクシィでは新卒エンジニアに対して1カ月程度の缶詰の教育を行っています。そのコンセプトは以下です。 関係各所、チーム、チーム横断でのタスクに関して 迷惑をかけずに自分で判断できる/あるいは正しく判断を仰げる状態までの成長。 現状の技術的問題点や課題を把握し、改善策や改善のためのプランニングができる。 各項目への知識体系の羅針盤を提供して、自学自習によ

    ミクシィのアプリケーションセキュリティの代表的な取り組みについて - mixi engineer blog
  • 【更新】ソーシャルメディアに共有するボタンの設置方法(Twitter, facebook, mixi, GREE, Evernote, Google+, Tumblr, Pinterest, はてブ) [C!]

    MovableType 小技集 【更新】ソーシャルメディアに共有するボタンの設置方法(Twitter, facebook, mixi, GREE, Evernote, Google+, Tumblr, Pinterest, はてブ) ソーシャルメディアの各サービスがこぞって「いいね!」などの共有ボタンをリリースしています。ブログやニュースメディアでも頻繁に目にする昨今ですが、色々なソーシャルボタンの設置方法をまとめて紹介したいと思います。 目次(兼ショートカット) TwitterTwitterボタン」 Facebook「Share」「Like(いいね!)」 mixi「mixiチェック」 GREE「Social Feedback(いいね!)」 Evernote「Site Memory(Clip)」 Google+「+1」 Tumblr「Share on Tumblr」 Pinterest

    【更新】ソーシャルメディアに共有するボタンの設置方法(Twitter, facebook, mixi, GREE, Evernote, Google+, Tumblr, Pinterest, はてブ) [C!]
  • Facebook・Twitterなどソーシャルボタン設置方法まとめ │ Design Spice

    twitter、facebook、google+1、evernote、tumblr、はてブ、mixiなど、各ソーシャルメディアやブックマークに共有するボタン設置方法をまとめてみました。 このブログはwordpressで構築しているのでプラグインを使用すれば簡単なのですが、他サイトなどにも使うことを想定した設置方法です。 備忘録エントリー。 twitter ツイートボタン facebook いいねボタン google+1ボタン evernote サイトメモリーボタン tumblr 共有ボタン はてなブックマーク mixiチェックボタン twitter ツイートボタン 1.コード取得 下記リンク先でツイートボタンのソースコードが取得できます。 Twitter / ツイートボタン ボタン ボタンの種類を選びます。 ツイート内テキスト ツイートに含まれるテキストを選択します。 ボタンが表示されるペ

    Facebook・Twitterなどソーシャルボタン設置方法まとめ │ Design Spice
  • 第8回 Perlによる大規模システム開発・設計のツボ(2) | gihyo.jp

    mixiのアーキテクチャパターン 2011年4月現在、mixiは2004年2月のサービス開始から7年以上をかけて、最適化、バグ修正、新機能リリースなどを続けています。(⁠2)では、こういった状況の中で、安定したサービスをみなさんにお届けするために取り入れているアーキテクチャ設計上の工夫や、失敗を修正していくための品質評価手法を紹介します。 システムの境界と階層化 mixiでは個々の機能について、次のようなパッケージレイアウトを採用しています。 Mixi::Voice::* つぶやき機能に関するモジュール群 Mixi::Video::* ビデオ機能に関するモジュール群 Mixi::Diary::* 日記機能に関するモジュール群 Mixi::Home::* ホーム表示機能に関するモジュール群 以降では、これらのモジュールの集まりを「コンポーネント」と呼びます。これらのコンポーネントは、相互に連

    第8回 Perlによる大規模システム開発・設計のツボ(2) | gihyo.jp
    sbg3
    sbg3 2011/08/04
  • 第8回 Perlによる大規模システム開発・設計のツボ(3) | gihyo.jp

    技術的負債の「見える化」 どのようなソフトウェアにも設計上のミスはあります。設計時点ではサービスの発展性や日々変わりゆく要件を完全に予測することはできないからです。ある時点で正しい設計も、その次のサービスリリースでは設計上の修正を必要とするかもしれません。これらの変更への粘着性や複雑性のある状態を、「⁠技術的負債」と言います。 mixiでは技術的負債は長らく、コードレビュー技術力の高いエンジニアによる新機能リリース時の修正などで対応を行ってきました。しかし、これまでに紹介した「わかりやすいコードの指針」や「アーキテクチャパターン」をレビューや教育だけで維持することは、ソフトウェアが巨大になり、開発者数が増加するにつれて難しくなります。そのため現在では、ソフトウェアの設計品質評価を自動化するツール群を開発し、それらを用いて技術的負債を見える化し、計画的に解消していく試みを行っています。 コ

    第8回 Perlによる大規模システム開発・設計のツボ(3) | gihyo.jp
    sbg3
    sbg3 2011/08/04