タグ

ブックマーク / mixiengineer.hatenablog.com (17)

  • 「すごいGit楽しく学ぼう」を公開しました - mixi engineer blog

    こんにちは、toma です。 つい先日、新卒エンジニア向けに Git 研修を行いました。 その時の研修資料「すごいGit楽しく学ぼう」を Speaker Deck にて公開しました! 「すごいGit楽しく学ぼう」は、Git に触ったことがないという方でも、Git を使ったチーム開発に参加できることを目指して作成しています。 実際にミクシィでは、ほとんどの部署で GitHub や GHE を利用しており、Pull-Request を活用してチーム開発を進めています。 Git の習得は、ミクシィで開発を行っていく上で必須のスキルであるため、新卒研修として毎年実施されています。 資料の目次 とりあえず使ってみよう! コミットとブランチについて正しく理解しよう 歴史を取り込む 落穂拾い Git のコマンドをひと通り使ってみた後、Gitの仕組みについてひとつずつ学んでいくという構成になっています!

    「すごいGit楽しく学ぼう」を公開しました - mixi engineer blog
  • 社内研修「JavaScript基礎」の資料を公開します! - mixi engineer blog

    どうも、新卒2年目エンジニアJavaScript委員会の重田です。 帰省がてら鳥取砂丘や小豆島に行ったらだいぶ日に焼けてしまいました。 さて、もう4ヶ月ほど前になってしまったのですが、新卒研修でJavaScript基礎の講師を担当したので、そのときの資料を公開します。加えて、JSを学ぶ上で押さえておくとよいポイントを解説します。 研修資料 https://github.com/mixi-inc/JavaScriptTraining JavaScript初心者向けの資料になります。 JavaScriptに触れるのがはじめての人でも、配属後すぐに活躍できるようになることを目指して研修を実施しました。 デベロッパーツールで素早くトライ&エラーを繰り返し、JSを学ぶ 去年ぼくはこの研修を受ける立場でした。今年の講師を担当するにあたって、研修の進め方で最も変えたのはデベロッパーツールを積極的に使う

    社内研修「JavaScript基礎」の資料を公開します! - mixi engineer blog
  • スマホアプリの品質ガイドラインを公開しました - mixi engineer blog

    UP by Jawbone を衝動買いした挙句、眠りが異常に浅いことが判明し、 金銭サイクルも睡眠サイクルも崩壊しつつある柿崎です。 現在、ミクシィではスマホアプリの開発に力を入れています。 もちろんQA部門でもスマホアプリの品質ってなんだろな?と、考える機会が増えたわけですが、その機会の中で、スタッフが普遍的なチェックリストを作成してくれたので、GitHub Pagesにて公開してもらいました。 スマホアプリ品質ガイドライン リンク先の概要にも記載していますが、スマホアプリ自体の動作よりも、ハードウェアやOS設定を中心とした非機能要件を中心に項目をまとめています。 項目はスマートフォンの進化にあわせて、随時更新していく予定です。 そして、このチェックリストの使い道ですが、全ての項目のクリアを必須にするとデスマ確定になるので、あくまでもスマホアプリの品質を高めるための一助と捉えていただけれ

    スマホアプリの品質ガイドラインを公開しました - mixi engineer blog
  • スマートフォン開発研修教材の公開について - mixi engineer blog

    クラフトワークの来日公演3-D CONCERTS 1 2 3 4 5 6 7 8を観にいったら、顔が大きいのか、3Dメガネがきつくて切なかったもりもとです。 株式会社ミクシィでは、新卒入社スタッフをはじめ、これからスマートフォンアプリ開発を行っていく全スタッフを対象に、社内で「スマートフォン開発研修」を始めています。その研修資料をこのたびgithubで公開させていただきました。 mixi-inc/iOSTraining · GitHub https://github.com/mixi-inc/iOSTraining mixi-inc/AndroidTraining · GitHub https://github.com/mixi-inc/AndroidTraining これら文書は、それぞれCC BY-SA 3.0およびApache License 2.0とCC 2.5 Attributi

    スマートフォン開発研修教材の公開について - mixi engineer blog
  • 続・技術的負債の把握と改善を促すために - mixi engineer blog

    こんにちは, 先日Kansai.pmで発表させて頂いたgoccyこと五嶋@たんぽぽグループです. 今回は, 前回紹介した技術的負債の把握と改善を促すためにの続編として, 僕が作ったPerl5コードのコピペ検出器について紹介させて頂きます. はじめに 今やPerl, Ruby等さまざまな言語で, 便利なライブラリ群やフレームワークを利用できる時代になりました. これらを使うことでソフトウェアの開発コストは格段に下がり, より素早く開発することができるようになっています. しかし, 当初予定されていた機能を実装して, 「よしできたから終わり!」というわけにもいきません. 何か物を生み出せば, 必ずそれを保守・運用するコストが発生します. 開発することが便利になった今, 開発物を保守・運用することを支援するツールも求められています. ですが, 保守や運用, とりわけ保守に関して支援するツールはそ

    続・技術的負債の把握と改善を促すために - 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
  • 技術的負債を減らす - mixi engineer blog

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

    技術的負債を減らす - mixi engineer blog
  • ステージングサーバ予約アプリを自作したよって話 - mixi engineer blog

    こんにちは。よういちろうです。今日はOpenSocialなどmixi Platformの話ではなく、最近開発した「あるWebアプリ」についての話をしてみようと思います。 いつの時代も予約って大変!? このエントリを読んでいる方々の多くは、何らかのシステム開発に関わっている人が多いのではないかと思います。その規模には大小があり、エンタープライズ向け or コンシューマ向けがあり、最近ではWebアプリ or スマートフォンアプリといった区分けもあるでしょう。こういったシステム開発において、よく使われるテスト手法として「ステージングサーバの利用」があげられます。「番サーバじゃないんだけど、開発機でもない中途半端なもので最終確認する」ためのサーバ、というものですが、一般的には限りなく番環境に近い環境を準備して、環境の違いからくる不具合などを事前に解消、確認した上で番環境にリリースする、という

    ステージングサーバ予約アプリを自作したよって話 - mixi engineer blog
  • プランニング・ポーカーで始める楽しい見積り - mixi engineer blog

    こんにちは、UX統括部の横幕です。すっかり春になって、桜を眺めるのが気持ち良いですね。 最近、社内で活発に「デイリースクラム」が行われるようになりました。 日々、チームメンバーの持っているタスクの進捗を確認し合うことで、スケジュール感の共有・調整、あるいは、チームメンバー同士でタスクの振り分けを見なおしたりなどができ、チームの有機的な動きを作ることが出来るようになってきています。 さて、そんななかで、今回は、プロジェクトを進める上で、また日々のデイリースクラムをする上で重要な「タスクの見積り」についてお話しようと思います。 これが実際のPlanning Pokerです。アメリカのMountain Goat社が企画発売し、ライセンスしています。 1. 見積る前に 1-1. 計画を立てよう タスクの見積りをする前に、何をするのか、その計画を立てていきます。 ・フィーチャーを考える フィーチャー

    プランニング・ポーカーで始める楽しい見積り - mixi engineer blog
  • GHUnitで単体テストをしてみよう - mixi engineer blog

    初めまして。プログラマのショウといいます。 現在、mixiの公式iPhoneアプリを担当しています。 今回は、iPhoneアプリ開発におけるGHUnitを用いた単体テストについて紹介したいと思います。 ★ テストとは 題に入る前に少しだけ、テストという概念について整理してみましょう。 ソフトウェアを開発する上での「テスト」という言葉は、「コンピュータのプログラムを実行し、正しく動作するかを確認する作業のこと」を指します。 そしてこの「正しく動作するかを確認する方法」として主に以下の2通りがあります。 ・ ホワイトボックステスト ・ ブラックボックステスト ホワイトボックステストとは、「命令網羅」「分岐網羅」「条件網羅」などの方式を用いて、プログラム内部の動作がプログラマの意図通りとなっているかを確認するものとなります。 これに対してブラックボックステストとは、プログラム内部に関係なく、外

    GHUnitで単体テストをしてみよう - mixi engineer blog
  • 新社会人のためのバグレポートの基本 - mixi engineer blog

    はじめまして、品質管理部門の柿崎です。 最近、Skyrim にハマってしまい、人生一回休みになりかけています。 季節は春ということで、新社会人になられる方も多いと存じます。 新社会人が会社勤めをするようになって、初めて書くビジネス文書といえば...... そうですね!「バグレポート」ですね。 今回はバグレポートの基について書きたいと思います。 近年、開発現場ではバグトラッキングシステムが定着し、ドッグフーディングのような社内テストを行う現場も増え、テスト担当者以外の方でもバグレポートを提出する機会が増えています。そして前衛的なバグレポートによって、プログラマ達が理不尽かつ不可解なバグ地獄に叩き込まれる機会も増えています。 バグレポートは諸刃の剣です。 良いバグレポートはアプリケーションの問題を速やかに解決まで導きますが、反対にダメなレポートは現場に混乱をもたらします。 良いバグレポートを

    新社会人のためのバグレポートの基本 - 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
  • 詳細 ECMA-262-3 第8章 評価戦略 - mixi engineer blog

    全国20人の ECMA セオリストのみなさま、おつかれさまです。大形尚弘です。 ついに Dmitry 先生の ES3 シリーズも最終章となりました。この後に ES5 シリーズが5章続きますが、それらは基的に今シリーズの補足として書かれたものですので、ここまでお読みいただいたみなさまは、ほぼ ECMAScript の理論的側面を理解したと言えます。 もしそうでない部分があったとしても、実際に ECMAScript の仕様書をご覧いただければ、これまでとは全く理解度が違っていて、あっという間に足りない知識を補足できると思います。端的に、「仕様が読める」ようになっているはずです。 ES5 であれば、PDF である仕様書を、有志の方が es5.github.com にて「注釈付きの」 HTML 形式で公開し、頻繁に更新されています。注釈の一つはもちろん我らが Dmitry 先生の ES シ

    詳細 ECMA-262-3 第8章 評価戦略 - mixi engineer blog
  • ミクシィのアプリケーションセキュリティの代表的な取り組みについて - mixi engineer blog

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

    ミクシィのアプリケーションセキュリティの代表的な取り組みについて - mixi engineer blog
  • mixi Engineers’ Blog » Linux Programming、epollの話

    お久しぶりです、初めての日の夏に圧倒されているトールマエサカです。 今日はLinuxにおけるネットワークプログラミング関連のネタです。分散データベースサーバの開発過程で最近よくLinuxのepollというイベントハンドリング機能を使っています。これがまた優秀な機能なので紹介します。 このContextでいうイベントハンドラーはサーバがクライエントのリクエストを処理するためのメカニズムです。イベントの感知と通知は大雑把にいうと以下の三つの処理で構成されています: 一つもしくは複数のディスクリプタを監視 ディスクリプタの準備が整うまでハチ公のごとくひたすら待ち続ける 準備が整ったディスクリプタの通知 アプリケーションでの実装は一昔までselect(2)、もしくはpoll(2)というシステムコールで行われていました。二つとも役目は同じですがselect(2)の場合、kernelをいじらない限り

    mixi Engineers’ Blog » Linux Programming、epollの話
  • 詳細 ECMA-262-3 第3章 this - mixi engineer blog

    どうもおつかれさまでございます。たんぽぽグループの大形尚弘でございます。好きな言語は Dylan です。好きな声優は五十嵐裕美さんです。 さて、週刊のはずが月刊になってしまった、 Dmitry 先生の ECMA-262-3 シリーズの第3章をお送りします。文中、未だ訳出の終わっていないスコープチェーンや関数の章への参照がありますが、特にスコープチェーンにおいてこの時点である程度理解しておきたいとお感じになる方もいらっしゃるかと思います。その辺りは、以前私個人のブログで翻訳・公開させいただいたコア・JavaScript ( JavaScript. The Core. )でも簡単に触れられておりますので、適宜ご参照ください。 また、章とは全然関係ないのですが、先日 JavaScript Advent Calendar 2011 (オレ標準コース)に参加させていただき、 ECMAScript

    詳細 ECMA-262-3 第3章 this - mixi engineer blog
  • Sinon.JS を使った JavaScript のテスト - mixi engineer blog

    初めましてこんにちは。ソーシャルクライアント開発の tanabe と申します。 今回は?Sinon.JS を使った JavaScript のテスト方法を紹介したいと思います。 Sinon.JS って何? Sinon.JS はノルウェーのエンジニア Christian Johansen さんが書かれた、JavaScript 用のライブラリです。スタブやモック、フェイクオブジェクトの提供に特化していて、QUnit などのテスト用のフレームワークや実行環境に依存しない所が特徴です。Christian Johansen さんは?Test-Driven JavaScript Development の著者でもあり、こちらは近々翻訳版 が登場するようです。 では早速、Sinon.JS を使ったテスト手法をご紹介していきたいと思います。稿ではテストフレームワークは QUnit を採用しています。 時間

    Sinon.JS を使った JavaScript のテスト - mixi engineer blog
  • 1