SkypeからSlackにした理由

プログラマの西川です。

今回の記事では、チャットツールのSlackについてお話します。最近各所で使いはじめたよーというお話がチラホラと出てきていますが、弊社でも大体4ヶ月ほど便利に使っています。

僕が入社した頃、弊社ではSkypeを社内チャットツールとして使っていました。僕は何年か前から、会社など管理が必要な組織でSkypeの利用は適さないと思っており、これは改善しなければと思いました。そこでSlackを利用できる状態を先に作り、社内メンバーに多少強引に使いはじめてもらい、便利さを実感してもらってそのまま社内のチャットツールとして定着させました。
とても便利なので、基本機能、連携機能等を紹介し、他社等でもより便利なコミュニケーションのためのきっかけになれば良いなと思います。

Continue reading

あなたのコード、激遅ぷんぷん丸?今すぐできる7つのチェック項目 PHP編

php_logo

みなさん、こんにちは。

GeNERACEのピンキリエンジニアこと、ひろゆきです。

ここのところPHPを書いてるんですが、同じ処理を書くとしても、どの関数を使えば良いのか分からないことがありました。

たとえば、繰り返し処理を書くにしてもfor, foreach, whileと3種類もあります。

いったいどれを使えば良いの?(´・ω・`)

分からないなら調べれば良い。

ということで、弊社環境にて処理速度の検証してみました。

(この辺ってググってみても、ソースが古かったりしてたので、あえて調べました)

Continue reading

Ruby on Rails を用いて爆速構築

初めまして、新人エンジニアまーしーです。
今回は前職でRailsを用いて開発をしていたので軽く紹介をさせていただきます。
ruby-on-rails

railsはコマンド一つでソースの骨子を作ってくれるので
ファイル、ディレクトリ追加はコマンド1つで可能です。
また、migrationを行うことでテーブル生成を行えます。

Continue reading

「カード」は2次元?3次元?

blogtitle_card

こんにちは、マークアップエンヅニアのゆーじろ(仮称)です。

今回は皆さんが今まさしく使っているWEBサイトについて書きます。
といっても全てを書くと膨大になってしまうので、テーマを「WEBサイトの奥行き」に絞ってお話します。
WEBの世界はその歴史も相まって不可思議なものです。

本題に入る前に…

WEBサイトの見栄えはHTMLというもので殆どが出来ています。
HTMLはタグと呼ばれるもので構成されていて、テキストの意味をコンピュータに伝える為の役割をしています。
これがあるおかげで、例えばニュースの更新をチェックするWEBサービスだとか、そういった情報の特定をすることやリッチなデザインを表示することが出来ています。
私の仕事であるマークアップはデザインと情報を切り分けて、WEB上に「再現」させるものです。

ここでタイトルの話をしましょう。
皆さんはカードを3次元だと思いますか?2次元だと思いますか?

Continue reading

PHP初心者向けのコードの最適化

php_code_image

こんにちは。GeNERACEのみきあらいです。
今回はPHP初心者の方に向けて、コードの最適化について書かせて頂きました。初めにコードを書くにあたって意識したことをまとめ、その後に実際にどのようなコードを書いたのか、サンプルコードをご紹介します。

Continue reading

大規模サービスでプログラマが注意すること(基礎)

blog_20130517

みなさん、こんにちは。

GeNERACEのピンキリエンジニアのひろゆきです。

いきなりですが、少しだけ自己紹介をしますと、前職やら何やらで比較的、大規模とよばれるサービスの開発、運用していました。

今回はその経験から得たノウハウ的なものをご紹介させて頂きたいと思います。

既にそういったサービスを経験されている方には当たり前のことかもしれませんが、これから参加される方、または、参加したばかりの方のお役に少しでもなれば幸いです。
Continue reading

オブジェクト指向CSS(OOCSS)とSassとUIデザインのベストな関係

こんにちは、マークアップエンヅニアのゆーじろーです。
今回は掲題の通り、オブジェクト指向CSSという概念について書きます。

ちなみに恥ずかしながら私はつい最近までこのOOCSSという概念を知りませんでした。
ただ、私が普段CSSコーディングする際に行っている行為がどうやらこれらしい。というのと、
いくつかドキュメントを探してみたら、概念を誤解しているようなものも散見されたので改めて纏めました。

Continue reading

エンジニアもロジカルに企画・デザインできる!ハイパーエンジニアデザイナーへの道」

iQONさんの画像
こんにちは。GeNERACEのエンジニアのみきあらいです。

今日はiQONさん主催のイベント「人気ファッションアプリiQON★クリエイティブワークショップ ~女子をつかむUIの作り方&デザインワークショップ~」に参加したときのお話をします。

すでにご存知の方もいるかもしれませんがiQONとはどういうアプリかというと、女性向けのファッションを取り上げたアプリで、ユーザーは自分で考えたコーディネートをアプリ上にアップできたり、他のユーザーがアップしたコーディネートで欲しいものがあったら買えるというものです。

百聞は一見に如かずということでアプリの詳細については以下をご覧ください。facebook×amazonといった感じで面白いです。

http://www.iqon.jp/

イベントに参加してどういうことをしたかというと、iQONの方々のお話を聞いたあとは参加者同士でグループワークをしました。グループワークのテーマは「アプリの登録情報入力画面とログイン画面をデザインする」です。

以下、イベントとグループワークを通して聞いた話とそれに対する気付きを紹介してきます。

  • 「面倒なこと」「つまんないこと」が斬新なデザインを生む!

イベントで聞いた話の概要(以下、イベント):「名前とか住所とか入力するのめんどくせーなあ」→「やっぱ登録するのやめるわー」

といったように登録する直前でアプリから離れてしまうユーザーは少なくないようです。そういったユーザーの動きを止めよう!という傾向があります。
例えば対話型や穴埋め式のログインフォームにするといったような工夫が必要です。アメリカですでにそんな画期的なログインフォームがあります(例:私の名前は「    」です。)

気付き:ネガティブ要素を潰すことが新しいデザインやコンテンツを生むようです。
例えばソーシャルゲームで遊んでいて「挨拶機能とか面倒だな」と思ったら、挨拶機能をなくして別の機能でユーザーに特典をあげる、などというアイディアを企画チームにも話して、その仕様で実装するということができそうです。

  • データ至上主義

イベント:「なんとなーくこれがやりたい」「なんか良さげ」で企画やデザインを決めないし決めさせない!
「LINEの新しいスタンプを売る」という企画があるとします。スタンプを売るということで例えばディズニーのスタンプを売ろうという意見があり、それを採用するとします。
もしこの「ディズニーのスタンプを売りたい」ということを実現するためには、大抵の場合「なぜディズニーのスタンプを売るのか」「売り方・宣伝の方法はどうするのか」ということを考える、つまり「1. 売りたいものを考える → 2. 売り方を考える」という流れになると思います。

まず、ターゲットをすでにスタンプを高頻度で使ってるユーザーに絞ります。これによって、スタンプを買わないユーザーではなく、スタンプを買うユーザーに絞ります。
次に、スタンプを使っているユーザーが別のスタンプを買い換えるタイミングを調査します。
調査の結果、ユーザーがスタンプを買い替えるタイミングがわかったら、「新しいスタンプができました」というメッセージをターゲットであるユーザーに一斉送信します。
そのあと、スタンプをよく使うユーザーが実際にどういうスタンプを買っているのかを調査します。
調査してどのようなスタンプがよく売れているのかがわかれば、そのスタンプと似たようなスタンプを新しいスタンプとして売ります。

このように、イベントで聞いた話によると、「1. 売り方を考える → 2. 売るものを考える」といったように、はじめに書いた「1. 売りたいものを考える → 2. 売り方を考える」という順番とは異なります。
なぜ順番が異なるのかというと、「1. 売りたいものを考える → 2. 売り方を考える」という順番では、データ分析の前に「ディズニースタンプを売る」と決めているのに対し、後者の「1. 売り方を考える → 2. 売るものを考える」という順番では、データ分析に基づいて売る方法を考えた上でそれのあとに何を売るのか決めているからです。

「やりたいことがあるならデータ分析に裏付けされていないと企画としてみなさない」ということもこの例え話と同時にイベントで聞きましたが、この考えが売れるコンテンツを生み出す秘訣なようです。

気付き:正直デザイナーの方々は感性とかを何より大事にされるだろうという認識があったので、(会場にはデザイナーとディレクターの方々がいたわけですが)どちらかというと感性がものを言うことより、論理的なデータ分析の話をたくさん聞けたのがとても新鮮でした。

—————————————————————————–

☆その他気づいたこと、聞いたこと

  • 足を使って情報を稼ぐ!

「プログラマー=超絶運動不足」と思われがちですが、とにかく足を使って色んなイベントに参加してみると、他の会社の方々と情報交換して自分たちの仕事に活かせられます。(「skypeでいいじゃん」という意見もありそうですが、直接会場に出向くのが一番だと思います。また、ただイベントやセミナーの話を聞くだけでなく、実際にイベントの会場でグループワークをしてみたり、その場にいる人と情報交換をするなど、イベントに参加するときは受け身にならないという心意気も大切だと改めて思いました。)

今まではどちらかというと、企画チームに受身的に仕様を聞いて実装していたのですが、仕様やデザイン案をただ聞くだけではなく、自分から提案していく姿勢が大切なのかなと思いました。

最後までお読みいただきましてありがとうございました。

【2週間で3万円!!】無課金から課金ユーザになるまで ~ソーシャルゲーム体験記~

kunshiro

こんにちは。ピンキリエンジニアのひろゆきです。

本日は技術的な話ではなく身近にソーシャルゲームにハマってた人@弊社プロデューサーがいたので、どうやってそういった状態になったかを聞いてきた話を書いてみます。

ユーザー心理的なもので何かのお役に立てたら幸いです。

ちなみに僕は前職でソーシャルゲーム開発をしていたため、純粋なユーザー目線というのは持てなくなってる気がしていましたが

今回の話を聞いて、忘れていた気持ちを思い出しました。

ソーシャルゲームをそれほどやりこんでいない状態から、ついつい課金までしてしまうところまでいっちゃう感じが新鮮でした。

回復する時間に合わせて、タイマーをかけてプレイしている様子はハマってるなーって感じです。

さて、以下からが聞いてきた話です

Continue reading

効率が良いペアプログラミング

こんにちは。エンジニアのみきあらいです。今回はペアプログラミングについて書きます。

「ペアプログラミング」「ペアプロ」などといった単語でgoogle検索すると様々な記事が紹介されますが、今回は初めてのペアプログラミングを行ったときのやり方と気づいたメリットをまとめていきます。

    ☆ペアプログラミングしたときの状況

  • ペアを組んでもらった人:自分よりも経験があり技術力もある(コードを書くのが速い、知識が豊富なため問題解決が速い)人
  • Gitでソースコードを管理しました。コードを書くときは各自のPCを使用しました。
    ☆メリット
    実は効率が良い:「二人で一つのコードを書くので効率が悪い」と思われがちですが、以下のメリットがあります。

  • 良い実装方法を共有しやすい:自分よりも経験があり技術力がある人に見てもらってペアプログラミングをすることにより、一人でコードを書くよりも良い実装ができます。
    さらに技術力がある人がコードを書くのを見てるとコーディングの勉強になる上に、開発を行う際にもどのように実装されたかをリアルタイムで見ているので情報共有がしやすいです。

  • 手戻りが少なくなる:一人がコードを書いてもう一人がそのコードを同時に見ているので、問題点があればその場で指摘でき、解決もその場でできます。
  • ソースコードを確認する時間が短縮できる:例えばGitでソースコードを管理しているときにもメリットがあります。GitでPull Requestを送って第三者にマージしてもらう場合、その第三者がリクエストした人とペアプログラミングをしていれば、リクエストされたコードを読むのに時間をかけなくてもどういう実装がされているのかがわかるので、すぐにマージをすることができます。
  • コーディングとコードレビューをほぼ同時に行うことができる:一人がコードを書き、もう一人がそのコードをほぼリアルタイムでレビューすることができるので、実は効率が良いです。
  • コードに責任を持てる:チーム開発ではつい自分の書いたコードに集中し、他の人が書いたコードに注意が向かなくなりかねないこともなきにしもあらずですが、それを回避するためにも「二人以上の人が書いて確認する」ことにより、そのコードに対して責任を持ちやすくなります。従って万が一障害などが起こった場合も、責任を持っているコードならより対処がしやすくなります。
    ☆今回のペアプログラミングのやり方とポイント

  • コードを書く人と書いてるのを見る人の2人で行います。30分交代でコードを書きます。
    その際は時間配分を計算して「どの処理まで書いたら交代」ということをあらかじめ決めておきます。
    具体的には、今回ペアプログラミングでやる実装の範囲を決めて、その中で行う実装をわけて作業をするとスムーズです。
  • コードを書くときはそれぞれのPCを使います。交代の段階でGitにコミットし、相手に引き継ぎます。
  • コードを書くときは「今どういう処理を書くのか」「何のためにこの条件分岐を行うのか」などを発言しながら書きます。
    実際にコードを読めばどういうことをしているのかわかるといえば確かにそうなのですが、ペアプログラミングで重要なのは「常に認識合わせを行うこと」なので、常に会話をしてコードを書くようにします。
    認識が少しでも合わなくなると二人でコードを書いている意味がなくなってしまいます。ただ会話すればいいという訳ではなく、コードを書く人も見る人も互いに認識確認をすることが大切です。
  • デバッグをこまめに行います。これはペアプログラミングに限った話ではないですが、バグを未然に防ぐためにもこまめに行います。
    ペアプログラミングならデバッグも一人ではなく事実上二人で行うため、より確実にデバッグを行うことができます。
  • コードを見る人は、書いてる人のモニターに張り付く勢いで30分間見ることに集中します。
    (当たり前のことのようですが、本当に30分間なら30分間集中しないとペアプログラミングではなく単独でコードを書くことになってしまうためです。)
  • コードを書いてる人のミスを発見したときは、「なぜそのような実装をしたのか」を見ている人が質問します。
    質問に答えることによって、コードを書いている側も「自分が本来やりたかった実装」と「今自分が書いてる実装」の違いに気付き、ミスの解決が速くなります。
    また、不要なメソッドの有無、変数名の付け方、インスタンスの生成の場所などに関しても指摘事項があればすぐにそれを共有します。
  • 書いてる人は見てる人の言う通りにコードを書くのではなく、見てる人にアドバイスをもらいつつも主体的にコードを書きます。
    これも当たり前のことのようですが、見てる人の方が書いてる人より経験がある場合、書いてる人はつい見てる人の指示通りにコードを書いてしまうようなこともありえます。が、それだと結局二人ではなく、見てる人が一人で書いているのとほぼ同じになってしまうため、ペアプログラミングの意味がなくなってしまいます。
  • コードを書くことからは少し外れますが、コードを書いてる人が自分よりも技術力がある人の場合、その人が調査してるときのやり方も見るべきポイントとなります。自分が一人でコードを書いていて調査するときの参考になります。

まとめました。

  • コードを書く人と見る人は交代制
  • 常に認識合わせをすること
  • 「一人」ではなく「二人」でコードを書くという認識を忘れずに!
  • 今回のペアプログラミングに関するメリットとポイントについては以上です。今回は具体的なコードの公開などは割愛させていただきました。
    最後まで読んでいただきまして、ありがとうございます。