ハウテレビジョン開発者ブログ

『外資就活ドットコム』を日夜開発している技術陣がプログラミングネタ・業務改善ネタ・よしなしごとについて記していきます。

なぜ DI が好きなのか PHP / Laravel でやってみた

夏はとにかく苦手、夏生まれの@KJ_BACCHUSです。 外出なんてしてたまるかと自宅で何かやろうと思いたった今日この頃。 Webエンジニアとしての知識が乏しいのでスキルアップを目的にアプリを作成しようと思います。 当社にはスマホアプリエンジニア(主にAndroid)としてjoinしたのですが、Webアプリも携わるようになってきたのでWebの勉強をしようと決意したという感じです。 いろいろ手広く業務出来るのはスタートアップならではの醍醐味。非常にやりがいを感じる日々です。

言語/framework 選定

さて、なにでアプリを作ろうかなと。 だれもが悩み、また楽しい行程の1つであろう言語の選定です。 とは言え私はPHPで決定です。 当社既存サービスがPHPを使用している且つ私はPHPを使ったことがないので、勉強という名目のため1択です。 楽しい行程即終了です。。。 しかし、Frameworkは好きなものを選ぼう!と色々調査することに。

Laravelをチョイス

馴染み易そう!という印象を受けたので決定しました。 慣れないWebアプリ/PHPをやるならまずは自分のやり易いコーディングができるのが一番と考えました。 ということで、どういった所に惹かれたのかを書いていこうと思います。

惹かれたワード

  • DI ← 影響力強し
  • ディレクトリ構成が自由
  • 開発スピード重視のフレームワーク

DIが好き

ほぼこれに尽きます。 まず当社Androidアプリ開発において、DI(依存性注入)しているという背景があります。 Android開発者なら、Dagger(当社アプリでも使用)を使用しているという方が多いのではないでしょうか。 Laravelなら、ちょっとそれに似た感じでコーディングできそうという期待が膨らみました。

なぜDIが好きなのか?

DIはjavaのフレームワークではよく使われるようになってきていると思います。 テストが書き易くなると言うのが大方の意見でしょう。DIで検索すると「テスト」という言葉がよく見受けられます。

それはまさにその通りなのですが、私が好きな理由としては疎結合なコードが書けるというところです。 まぁそれが「テストし易い」ということと直結するのですから意味は一緒かもしれませんが。。。

ただしDIコンテナを使用すれば必ずしも「疎結合」「テストし易い」コードになるわけではないので勘違いしてはいけません。 DIを駆使して開発していくには、抽象化と上手につき合っていく必要があります。

そういった意味でDIコンテナを使用して開発する事は、「疎結合」なコードを書く訓練になると感じています。

つまりDIを使用して「疎結合」なコードにしようという姿勢が好きなのです。

抽象化(interface)

「疎結合」なコードにするために「抽象化」が大切と述べましたので例を挙げてみます。

before

<?php

class HolidayOfManA {
    public function wakeUp() {
        return '8時起床';
    }

    public function breakfast() {
        return '朝食は食べない';
    }

    public function mainActivation() {
        return '家でゲームをする';
    }

    public function dinner() {
        return '夕食はパスタを食べる';
    }

    public function goToBed() {
        return '23時就寝';
    }
}

?>
<?php

class HolidayOfManB {
    public function wakeUp() {
        return '6時半起床';
    }

    public function breakfast() {
        return 'トーストを食べる';
    }

    public function mainActivation() {
        return '映画館に行く';
    }

    public function dinner() {
        return '夕食は親子丼を食べる';
    }

    public function goToBed() {
        return '24時就寝';
    }
}
?>
<?php
class ScheduleController extends AppController {

    public function view() {
        $holidayManA = new HolidayOfManA();
        echo $holidayManA->wakeUp();
        echo $holidayManA->breakfast();
        echo $holidayManA->mainActivation();
        echo $holidayManA->dinner();
        echo $holidayManA->goToBed();
    }
}
?>

上記の「HolidayOfManA」「HolidayOfManB」クラスはそれぞれ、男A、男Bの1日の行動を返すクラスです。 「ScheduleController」クラスのview()メソッドでは、男Aの1日の行動パターンを表示しています。

現状のview() メソッドだと、メソッド内で「HolidayOfManA」クラスのインスタンスを生成しているため密結合なコードと言えます。

これを「疎結合」にするために「HolidayOfManA」「HolidayOfManB」クラスから共通処理を抽出し、「抽象化」します。 そして、ここからLaravelのDIの機能を使用して記述していこうと思います。

after

<?php namespace MyProject\Humans;

interface HumanLifecycleInterface {
    public function wakeUp();

    public function eat($timezone);

    public function mainActivation();

    public function goToBed();
}
<?php namespace MyProject\Humans\Eloquent;

use MyProject\Humans\HumanLifecycleInterface;

class HolidayOfManA implements HumanLifecycleInterface {
    public function wakeUp() {
        return '8時起床';
    }

    public function eat($timezone) {
        if ($timezone == 'morning') {
            return '朝食は食べない';
        }
        else if ($timezone == 'night'){
            return '夕食はパスタを食べる';
        }
        return '';
    }

    public function mainActivation() {
        return '家でゲームをする';
    }

    public function goToBed() {
        return '23時就寝';
    }
}

?>
<?php namespace MyProject\Humans\Eloquent;

use MyProject\Humans\HumanLifecycleInterface;

class HolidayOfManB implements HumanLifecycleInterface {
    public function wakeUp() {
        return '6時半起床';
    }

    public function eat($timezone) {
        if ($timezone == 'morning') {
            return 'トーストを食べる';
        }
        else if ($timezone == 'night'){
            return '夕食は親子丼を食べる';
        }
        return '';
    }

    public function mainActivation() {
        return '映画館に行く';
    }

    public function goToBed() {
        return '24時就寝';
    }
}
<?php namespace MyProject\Controllers

use MyProject\Humans\HumanLifecycleInterface;

class ScheduleController extends AppController {

    protected $lifecycle;

    public function __construct(
        HumanLifecycleInterface $lifecycle) {

        $this->lifecycle = $lifecycle;
    }

    public function view() {
        echo $this->lifecycle->wakeUp();
        echo $this->lifecycle->eat('morning');
        echo $this->lifecycle->mainActivation();
        echo $this->lifecycle->eat('night');
        echo $this->lifecycle->goToBed();
    }
}

HumanLifecycleInterfaceが「抽象化」したinterfaceです。 共通の振る舞いを抽出したファイルになります。

「ScheduleController」のview()メソッドでインスタンスを生成することはせずに、コンストラクタでクラスを注入しています。 これがDI(依存性注入)です。

ある人の1日のスケジュールを表示する「ScheduleController」クラスは、誰のスケジュールかを知る必要がないという考え方です。 コンストラクタで注入するクラスが変更されることで、表示されるものが切り替わります。

変更しなければならないクラスが独立されるので、「疎結合」なコードとなりました。

では一体どのように実体を注入するのかというと...

app配下のconfigにあるapp.phpのprovidersに以下を記述します

<?php

return [
    'providers' => [

        'MyProject\Providers\HumansServiceProvider',

    ]
];

そして下記のHumansServiceProviderクラスにてHumanLifecycleInterfaceに注入する実体を記載します。 そのため、ここで実体を切り替えることができます。

この場合だとHolidayOfManAが使用されることになります。

<?php namespace MyProject\Providers;

use Illuminate\Support\ServiceProvider;

class HumansServiceProvider extends ServiceProvider {
    public function boot(){}

    public function register() {
        \App::bind('MyProject\Humans\HumanLifecycleInterface', 'MyProject\Humans\Eloquent\HolidayOfManA');
    }
}

※この例ではコンストラクタインジェクションですが、Laravel5にはメソッドインジェクションというものもあります。

いかがでしょうか。Android開発でDIを使用している方は、そっくり!!と感じたのではないでしょうか。 私はまさに、この方法にかなり惹き付けられました。

コード設計の概念

「抽象化」ができるようになると、プログラムの構成についても色々と思うところがでてきます。

各役割を明確化し、処理間の依存度を低くする。 そのためにインターフェースが存在する。

こう考える事で、本来のオブジェクト思考な開発が思い出されるのではないでしょうか。

図で表記すると以下のようなイメージです。

※APIアクセスする時の構成をイメージしています。

f:id:KJ_BACCHUS:20150807092238p:plain

フレームワークを使用していたことで、MVCで作成しなければいけないと囚われがちになっている考えが変わると思います。

もしも、「MVCで分割する」って結局どうすればいいの?とカオスになっているのであれば、「抽象化」を通して晴れやかになるかもしれません。

「抽象化」により依存度を低くした結果が「MVC」であって「MVC」で作成するのかどうかは開発者次第になるのではないかと。 つまり必ずしも「MVC」にしようと意識するのではなくて、「疎結合」なコードにしようと心がけるようになるのではないでしょうか。

おわりに

結局本記事ではLaravelのに機能ついてはあまり触れれませんでした。。。 ほとんどDIについてで終わってしまいましたので、今後Laravelの機能についてもっと書いていければと思います。

スマホエンジニアがWebアプリの設計を考えたらこうなったと捉えていただければ幸いです。

Slack WebAPIでナイスなフォーマットのメッセージを送る

こんにちは。xyz_iです。

弊社ではチャットツールとしてSlackを使用しています。 メンバー同士のやりとりはもちろん、いろいろなイベントの通知先としてもとても重宝しています。 例えば、WebAPIを使い、Capistranoによるデプロイの実行時にSlack通知する方法のように使ったりもしています。

この記事は、Slack WebAPIでメッセージを投稿するとき、Message Attachmentsを使うといいことがありますよというお話です。

WebAPIにおけるメッセージ

Slackにメッセージを投稿する際、メッセージのフォーマットとして以下のような選択肢があります。

  1. プレーンテキスト
  2. Markdownテキスト
  3. Message Attachments

おそらく人間がSlackを使う場合は、1または2の書き方をすると思いますが、 githubなどの通知BOT(下の画像参照)を見てみると、より進んだ感じのメッセージになっていることがわかります。 このようなフォーマットで表示させるには、3のMessage Attachmentsを使います。

f:id:xyz_i:20150409095744p:plain

Message Attachments

Message Attachmentsは、メインのテキスト以外にもいろいろなメタ情報を含むことができます。 例えば、以下のようなものです。

  • pretext(概要などを入れたりする)
  • 著者(例えば、「ブログに記事が投稿されました」という通知の場合、ブログの作者)
  • タイトル
  • 画像

これらを決められた形のJSONフォーマットでWebAPIに送信することで、Slackがいい感じに処理してくれます。

やってみる

百聞は一見にしかずということで、とりあえずやってみます。

Incoming WebHooksを設定

https://○○○.slack.com/services/new(○○○は適宜変更してください。)にアクセスして、Incoming WebHooks欄のAddボタンを押します。

f:id:xyz_i:20150409102456p:plain

次の画面でチャンネルを選択すると、Webhook URLができていると思います。 それがAPIのエンドポイントになりますので、大事にメモしておいてください

メッセージの投稿

同じ画面にいろいろな説明と下のようなExampleがあると思います。

一度それを実行してみましょう。 (読みやすいように少し整形してあります。)

curl -X POST --data-urlencode\
  'payload={
    "channel": "#testroom",
    "username": "webhookbot",
    "text": "This is posted to #testroom and comes from a bot named webhookbot.",
    "icon_emoji": ":ghost:"
  }' \
  <Webhook URL>

okと返って来れば成功です。 以下のようなメッセージが投稿されていると思います。

f:id:xyz_i:20150409110532p:plain

Message Attachmentsで投稿

先ほどのcurlコマンドをベースに、メッセージの本文をMessage Attachmentsを使って書きなおしてみます。

curl -X POST --data-urlencode \
  'payload={
    "channel": "#testroom", 
    "username": "webhookbot", 
    "attachments": [
      {
        "fallback": "ブログに記事が投稿されました。(http://blog.howtelevision.co.jp/entry/2015/04/09/xxxxxx)",
        "color": "#36a64f",
        "pretext": "ブログに記事が投稿されました。",
        "author_name": "xyz_i",
        "author_link": "http://howtelevision.jp/",
        "title": "Slack WebAPIでナイスなフォーマットのメッセージを送る",
        "title_link": "http://blog.howtelevision.co.jp/entry/2015/04/09/xxxxxx",
        "text": "(ブログの冒頭や本文を全部入れても良いかもしれません。)"
      }
    ],
    "icon_emoji": ":ghost:"
  }' \
  <Webhook URL>

f:id:xyz_i:20150409110541p:plain

誰が何をしたかが明確に表せていると思います。 (画像ではわからないですが「xyz_i」という部分にもリンクがついています。)

今回はメッセージの本文がどう変わるかというところを強調したかったため、webhookbotという名前や:ghost:アイコンは変更していませんが、通知する内容によって適宜変更すると、より適切なメッセージにできます

まとめ

SlackのMessage Attachementsを使うことにより、メッセージをリッチにすることができます。 メタ情報が加わることでメッセージの情報量を整然と増やすことができ、色情報が加わることでひと目で何についての通知か(もしくは通知内容のステータスなど)認識できるようになります。

より良いSlackライフを!

データドリブンな組織を作るときにまず行うこと 〜我が社よデータ分析色に染まれ〜

はじめに

データ解析本部のn_maoです。

前回は高速集計ツールmコマンドのご紹介をしました。

前回のmコマンドの紹介の投稿

今回は趣向を変えて、社内に分析部隊をゼロから作り、データドリブンなサービス改善を実現するためにまず行うべきこと、意識することをまとめてみました。

これは実際にゼロから初めた私の経験に基づくものです。

1つのケーススタディとして読んでいただければと思います。

主張を大まかな流れに分類すると、

1. 分析環境を整える

2. 社員のデータに対する意識を高める

3. データ分析とサービス開発を結ぶ仕組みを作る

4. 小さな効果を体感してもらう

5. 現状を把握し、指標を作る

という感じです。

以下で各トピックの詳細について触れていきます。

1. 分析環境を整える

分析のためのサーバーを用意する

当然のことですが、念のため。

データ分析や集計を行っていると、どうしてもメモリやCPUに高負荷のかかる処理が発生します。

ここはケチらずに、分析を行うためだけに存在するサーバーを用意しましょう

分析用のデータベースを作る

そして、分析や集計業務を行いやすいように、分析用のデータベースを作りましょう。

サービスを行ううえで適したデータ構造と、分析を行ううえで適したデータ構造は異なります。

コツは、同じキーのデータセットはなるべくまとめることです。

ただし、毎回分割して処理をかけるようなことがあれば、同じキーでもあえて分割させて保存しておきましょう。

この辺は好みや実際に運用してみて、柔軟に変更してみてください。

図に表すとこんな感じです。適当ですみません。

f:id:n_mao:20150406142131p:plain

2. 社員のデータに対する意識を高める

最終的には、皆が自分で分析できるようになることが理想ですが、そうは言っても最初は何をすれば良いか分からないと思います。

まずは、日々のユーザーの動きであったり、売上げなどの成果がどのようになっているのかになるべく興味を持ってもらうところから始めましょう。

そのために、皆がデータを気軽に確認できる場所を作りましょう。

いわゆるダッシュボードというやつです。

最近よく開発されているBIツールを導入しても良いし、自社で1から作っても良いです。

個人的には、ダッシュボードとしては予測モデルや多変量解析などの機能が充実している高価なBIツールは必要ないと思っています。

3. データ分析とサービス開発を結ぶ仕組みを作る

さて、分析環境が整い、ダッシュボードも出来上がったら、そこからが分析者の本領発揮です!

分析者はここぞとばかりに良い分析をしようと張り切ります。

実際に客観的事実に基づいた有意義な分析結果が出て、それを現場に持って行ったとします。

分析者「こんな面白い結果が出たんですよ!」

   「ここ、改善しましょう!」

現場 「なるほどねぇ」

   「うん、そうだよね。ありがとう」

・・・・・・終わり!?

結局いつ改善されるんだ??

これ、意味あったのか??

このようなケースに陥ったことのある組織は多いのではないでしょうか。

以下ではそうならないように「意識すること」と「データドリブンな仕組み作り」について議論します。

意識すること

まずは一個人としての信頼を得ることです。これも当然ですが一応。

データ分析者は、実際に分析を行って、

「このサイトのここが良いんです!」

というだけでは意味がなくて(勿論それも重要ですが)、

「ここが問題だから、こんな改善をしてみてはいかがでしょうか」

と提案しなければなりません。

そして、その提案が通って初めて分析に意味ができます。

しかし、データ分析者というのは微妙な立ち位置です。

実際にサービスを作るエンジニアでもなければ、ディレクションもしていない。

営業もしていないし、ましてや社長でもありません。

そんな分析者の言うことに耳を傾けてもらうためには、

確かな分析スキルに加え、サービスのことを

  • どれだけ愛しているか

  • どれだけ考えているか

を日々伝えることが意外と重要になってきます。

そのためには、開発現場や営業の人と日々コミュニケーションをとることを心がけ、日々競合のチェックをすることを心がけましょう

もちろん、ちゃんとサービスを愛し、日々思いを巡らせましょう

仕組みについて

分析結果を開発に組み込み、高速なPDCAスパイラルを回すためには、ちゃんとした仕組みが必要です。

データドリブンにおいて重要なことは、データ至上主義に陥るのではなく、経験やセンス、勘も大事にしていくことです。

図で表すとこんな感じ。 f:id:n_mao:20150406153835p:plain

さらに、分析者が1人で企画まで考えるのではなく、皆で議論し解決策にたどり着くことも重要です。

以下の図は弊社で実践しようとしているPDCAサイクルの基本例です。 f:id:n_mao:20150406154117p:plain

もちろん目的はサービスが改善されることで、この流れを遵守することではないため、柔軟に調整していきます。

以下、各MTGの概要です。

①問題提起MTG

  • 目的:現状のサイトの問題点を議論、取り組む分析テーマを決める
  • 主催者:基本的にデータ分析者
  • 出席者:各部署から必須で1名の参加と、分析結果に興味のあるチームメンバー
  • 必要なもの:客観的事実に基づく問題や仮説が提起された資料
  • 補足
    • 時間を決めてメリハリをつける
    • 現状の共有だけでも定期的に開催する

②アイデア創出MTG

  • 目的:分析結果をもとに、どんな解決策があるかを議論する
  • 主催者:データ分析者
  • 出席者:各部署から必須で1名の参加と、分析結果に興味のあるチームメンバー
  • 必要なもの:
    • テーマに沿った正確な分析結果
    • サービスをより良いものにしたいというアツい想い
  • 補足
    • アイデアは思いつきレベルで構わない
    • 議論はなるべく発散させる
    • アイデアを発言する場であり、否定する場ではない
    • 時間を決めてメリハリをつける

③アイデア選別MTG

  • 目的:技術コストやインパクトの観点からアイデアを絞る
  • 主催者:データ分析者
  • 出席者:メインディレクター、メインエンジニア、メインデータ分析者
  • 必要なもの:アイデアリスト
  • 補足:
    • 選別するものがなければ開催しない
    • 多くても3つか4つに絞る
    • 選別基準は明文化する

④アイデア決定MTG

  • 目的:最高意思決定者により、アイデアを決定する
  • 出席者:意思決定者(PO)、メインディレクター、メインエンジニア、メインデータ分析者
  • 必要なもの:アイデアリスト

4. 小さな効果を体感してもらう

仕組みができたら今度こそようやく分析開始です!

しかしここでも1つ注意点があります。

いきなりホームランは狙わないでください。

分析環境がある程度整ったとはいえ、あなたの手元にあるのはまだ作り込みの甘いデータです。

データの性質もよくわかっていません。

そんななかで壮大な分析を行おうとすると、着地までにとても時間がかかることは目に見えています。

そもそも着地できるかどうか。

最初は手堅く小さな効果を出し、データ分析の効果を実感してもらいましょう

5. 現状を把握し、指標を作る

どんな分析をするにしても、目的が決まっていないと着地できません。

目的とは例えば、

  • 「当サイトにとって良いユーザーとは誰か」
  • 「当サイトの健康的な状態はどのような状態か」

などです。

これらを定量的に説明できなければ、分析は困難なものになります。

分析を本格的に開始する前に、ますは現状を調査し、指標を作りましょう。

さいごに

今回は分析の文化がない組織にデータドリブンなサービス開発を導入する際に注意したことを書きました。

サクッと書くつもりが、かなり長文になってしまいました。笑

これでようやく分析が開始できますね!

再度言いますが、これは小規模の会社の1ケースにすぎませんので、完全にこの形にあてはめようとせず、各組織で良いやり方を考えてみてください。

この投稿がきっかけとなって、データ分析者が実力を発揮できる組織が増えていってほしいなと願っています。

こんなことも気をつけたほうがいいとか、ご指摘あればコメントにてお願いします。

【Android】ScrollViewにListViewを入れる

お久しぶりです。ホサカです。

Android開発をする上で、最近では数多の便利なライブラリが存在しており、いろいろな場面でサポートしてくれるようになりました。

とはいえ、やはり自分で解決しなければいけない問題には度々遭遇するものです。

かくいう私も、先日少々カスタマイズしなければならないUIに遭遇しましたので、その際の対応を備忘録を兼ねてご紹介します。

1画面に複数のListViewを表示

これを実現する必要に迫られました。Adapterを工夫して1つのListViewで実現すればよいかなと考えていましたが、いろいろ表示するものが多かったので断念し、ScrollViewにListViewを入れる対応で実現しようとなくなく決断することに。

何故なくなく決断なのか

ご存知の方は多いとは思いますが、ScrollViewは子のViewの高さが明確になっていなければなりません。

そのため、何の工夫もなくScrollViewにListViewを入れ込んでも、ListViewが極端に小さく表示されるという現象が発生してしまいます。 (ListViewの他にViewPager等も同様)

この問題に立ち向かうのは特別面白くもないし、ただただ面倒という感情が。。。しかし憂鬱になっていても時間が無駄なので、取り組むことにします。

まずはググる

ググれば解決でしょ!と思いきや、意外と記事がないw

あまり使わないのでしょうね。。。

一応回避できたという記事がちらほらありましたが、ActivityやAdapterからListViewの要素の高さを設定するというものしか出てこず。

viewの高さを設定する処理ををcontrollerで行うのは個人的には好ましくなかったので(というより、毎回実現するためにコードで記述するなんて面倒くさい)、これらの記事を参考にListViewをカスタマイズすることにします。

解決方法

カスタムListViewをScrollViewにぶち込むだけでOKというのが理想(部品化できて使い回せて便利)だと思ったので、ListViewを下記の用に拡張します。

拡張と言っても、onMesure()をいじるだけなので簡単です。

続きを読む

Lispをはじめよう! 非EmacserがMacにLisp(Scheme)の実行環境を作るまで

f:id:fuyumi3:20150312165148p:plain

こんにちは。@who_you_meです。

非常に変化が早いWebの世界ではありますが、一方で今まで長い時間をかけて積み重ねられてきた知識が大切なことに変わりはありません。

たまには古典に立ち返って名著を読みたくなりませんかなりますよね私はなります。

そんな個人の趣味趣向は別としても、プログラムを書く者としてコンピュータサイエンスの知識はやはり深めておきたいところ。

てなわけで、最近私の中ではSICP(『計算機プログラムの構造と解釈』)を読みたい欲が高まっています。というか読み始めています

計算機プログラムの構造と解釈[第2版]

計算機プログラムの構造と解釈[第2版]

  • 作者: ハロルドエイブルソン,ジュリーサスマン,ジェラルド・ジェイサスマン,Harold Abelson,Julie Sussman,Gerald Jay Sussman,和田英一
  • 出版社/メーカー: 翔泳社
  • 発売日: 2014/05/17
  • メディア: 大型本
  • この商品を含むブログ (1件) を見る

Amazonで買うとかなり高いですが、実はHTML版で無料で読めます*1

計算機プログラムの構造と解釈 第二版

この本は非常に有名なのでご存じの方も多いかとは思いますが、Lispです*2

大事なことなのでもう一度言いますLispです

実は最近のSICPの授業はPythonで教えられてたりするんですが*3、私はもとからPythonistaなので今更Pythonでやっても面白みがありません

なので折角だからこの機会にLispに触れてみよう! ということで、まずは実行環境を整えてみました。

*1:海賊版ではなく公式訳なのでご安心を。原著はCC BY-SA 4.0で公開されています。翻訳版のライセンスは謎

*2:正確には、Lispの一方言であるSchemeですが

*3:http://www-inst.eecs.berkeley.edu/~cs61a/sp14/index.html

続きを読む

UbuntuのパッケージリポジトリをChefで追加する方法

最近は昼食にマルちゃん正麺ばかり食べている artifactsauce です。

今回はUbuntuのパッケージリポジトリをChefで追加する方法を解説します。

私が最近ハマったので、皆さんは同じ轍を踏まないように。

続きを読む

初めてiOSアプリ開発するときにおさえておきたいこと

はじめまして、xyz_iです。

これまでWebアプリケーションばかり作っていた自分が、1月からiOSアプリ開発を行っています。 いろいろと覚えないとならないことが多く四苦八苦してますが、アプリ開発経験のあるチームメンバーに助けられながらなんとかやっています。 そんな感じで1ヶ月ちょっとやってきて、はじめにこれは抑えておいた方が良いなと思ったことをいくつか挙げていきます。

ただし、作るアプリによって必要になってくるスキルや知識は全く異なってくると思います。今回の記事はあくまで自分自身が携わった部分での話になります。

この記事が対象としているのは、以下のような方です。

  • iOSアプリ開発をこれから始めようとしていて、学習を始めている
  • iOSアプリ開発を始めて間もない
続きを読む