読者です 読者をやめる 読者になる 読者になる

Shoichi Matsuda's diary

このブログは移転しました。 https://shoma2da.net/ が新しいブログです。

意味のあるCheckをしよう

PDCAなんて言葉が出てきて久しいですが、みなさんのチームはうまく回っているでしょうか。

僕個人がいくつかのチームでスクラムやかんばん方式といった開発手法のうえでPDCAを回してきた中で、特にCであるCheck(振り返り)について思うところがあったのでまとめておきます。

(今回Checkの対象としているのは主にチームの状態や運営状況についてです。数値のCheckという観点ではないですのであしからず。)

よくある問題定義


Checkの中で必ずと言って良いほど出てくるのが以下のような問題点です。

  • 残業が多い(時間が取れない)
  • 作業が特定の人に集中している
  • 意思決定者に時間がない

こういった問題定義はほとんどの場合、事の本質に迫れていません。
少し詳しく説明していきます。

なぜ良くないのか


こうした問題定義の何が問題かというと、Actionにつなげられないことです。(あるいは見当違いなActionを行ってしまうことです。)

「残業が多い」というのを例に取って説明します。

「残業が多い」に対しての安易なActionの一つとして「定時になったら必ず帰る」という方法があります。(極端ですがw)

これをActionとして実践すると、今までは残業ありきで終わらせていたので当然ですが仕事が全く終わりません。
ひどい場合は退勤後のサービス残業につながるかもしれませんね。
これでは問題点を別の場所に移動させただけです。

多くの場合、真に迫るべきは「なぜ残業が必要になっているか」という点でしょう。
これはチームによってそれこそ様々です。
不要だと考えられる仕様が多く盛り込まれている、仕事に取り掛かる前の待ち時間が多い、会議が多いなどといったことなどが上がるでしょう。

ここで注意したいのはチーム内では対処しようもないことを問題として挙げてしまわないことです。
例えば開発チームにおける「人が足りない」というものですね。
Actionとしては「人事担当者に人を⚪︎⚪︎人採用するように伝える」などでしょうか。

運良く採用されれば良いですが、そうでなかった場合は「Actionなし」となってしまい改善への道が断たれます。
(もちろんチーム外の動きとしての採用活動の活発化はアリです。)

まとめます


Checkにおいてよくある問題定義は以下のようなことです。

  • 良くない状況をあげるだけになっていて、問題の特定ができていない(例:残業が多い)
  • 外部要因を問題としていて自分たちの範囲内の問題として落とし込めていない(例:人が足りない)

以上です。
それでは、良い改善を!

Togglで時間管理しはじめたら意識がみるみる変わっていった話

はじめに

作業時間の管理・計測をこれまでやったことがなかったのですがTogglというサービスを使い始めてみたら作業時間の見える化だけでなく意識すら変わってきているように感じたのでまとめておきます。

Togglとは

非常にシンプルな作りのタイムトラッキング(時間の計測)サービスです。

Webクライアント、Andoird、iPhone、PCクライアントが用意されています。

基本的な操作は作業を始めたらスタートボタンを押して、終わったらストップボタンを押すだけです。
これ以上ないほどにカンタン。

Togglを使い始めたきっかけ

id:naoto5959さんのこちらの記事を読んだことでした。

この記事自体は情報のPush / Pullについて書いてあるので「なるほどー」と思って読んだのですが、この中で出てくるTogglについて興味を持ったのでMacアプリを入れてみました。

何が変わったのか

先に結論から言ってしまうと自分が今何をしているのかを把握し集中しやすくなりました。

Togglは実際の作業時間を残していけるところが価値のポイントだとは思いますが、それよりもこの点のインパクトのほうが自分の中では強かったです。

ものすごく単純なことだと思うんですが、僕自身もこんな簡単なことが今までできていなかったのかと我ながら驚いていますw

今まではどうしていたのか

例えばブログを書き始める時に「よし、1時間くらいで書こー」と思ってそれ以上は特に何も考えずに書き始めていました。

運良くフロー状態(深い集中)に入れば良いのですが大抵の場合はそうはいかず、数分もすると横にあるお菓子を食べ始めてしまったりはてブの人気エントリーを見てしまったりしていました。

こんな状態なので仮に予定通り1時間でブログが書き終わったとしても実際に作業をしている時間は半分の30分というのも良くあることだったと思います。(測っていたわけではないので印象ですがw)

15分あれば喫茶店に入りなさい。

15分あれば喫茶店に入りなさい。

Togglを使ったところ...

Togglでは作業開始時に「今から何をするのか」を書いてスタートボタンを押します。

このたった一つの行動が意識には大きな影響を与えます。

何が言いたいかというと、ただ意識していた「今から何をやるのか」がTogglによってテキストに起こすという具体的な行動に変えるキッカケになるというところです。

自らやることを宣言しているので作業中はこれに逆らうことがなかなかできません。
これによって半ば強制的に今やっていることに集中することになります。

休憩したいときも「休憩する」と書いてスタートするので存分にお菓子や人気エントリーを楽しめますw

どちらにしろ自制は必要ですがTogglを使うことによってみなさんも集中しやすくなるかもしれません!
是非お試しください!

リモートワークをするときに意識している言葉使い

2015年一発目

あけましておめでとうございます。

今年は"発信"に重きを置いた一年にしたいと思ってます。
完璧より爆速を!
よろしくお願いします。

普通の働き方とリモートワーク

メンバーと顔を合わせて同じ場所で仕事をする場合は基本的にはコミュニケーションが非常に取りやすいです。
改めて言うまでもないですが、メンバーは物理的に近くにいますし、同じ時間にほぼ必ず働いている、という点が良いのでしょう。

一方で社外でのプライベートなプロジェクトなどではメンバーの作業する場所、作業する時間はバラバラな場合が多いと思います。

そういったリモートワークをするときに僕個人が意識している言葉使いを書き残しておきます。

こんな言い方はせずに、こう言います

相談編
  • NG これ、どうしよう?
  • OK これ、どうしよう?個人的には○○と思うから、△△しておきます。
お願い編
  • NG ○○の作業をしたので確認お願いします。
  • OK ○○の作業を完了しました。確認お願いします。何かあったら連絡ください。

結局どんなことを考えているのか

例はそんなに出できませんでしたがw、意識しているのはとにかく作業を止めずに、個人あるいは今作業中のメンバーだけで進めるところまで進んでしまうことです。

もう少し掘り下げて考えてみると時間をどこに使うかを工夫して考えていると言って良いと思っています。
具体的には

  • 相手からの返信が来るまでの待ち時間を取るか(待ち時間)
  • 後から入るかもしれない修正の時間を取るか(修正時間)

という2つから後者の「修正時間」を意識的に選択しています。

「待ち時間」を選んでしまうと相手がその瞬間に作業をしていない限りはいつまで待てば良いのかがわかりません。
また、待ちの状態なので自分の作業がこれ以上は進まなくなってしまう場合もあるでしょう。

これに対して「修正時間」は分かる範囲でどんどん進んでいけるため待ち時間はほぼありません。
修正が必要になった場合は修正時間はもちろんかかってしまいますが、一方で修正が必要なかった場合は無駄になる時間は一切なくなります。

他メンバーとの信頼感や作業スピードの違いによって進め方は限りなくあるとは思いますが、一つの考え方として参考になればと思います。

形から入るリーンスタートアップ

無駄を徹底的になくす、と言われているリーンスタートアップ。

2012年ごろから話題でしたがようやく最近勉強を始めました。

新しい手法を取り入れるときはその導入コストに悩まされるものですが2014年の今、
リーンスタートアップをとにもかくにも始めるためのツールが充実してきていると感じたのでまとめておきます。

リーンスタートアップとは

リーンスタートアップとは何でしょうか?
以下のように参考になる資料はネット上にたくさんあります。

ざっくり言うと「検証を重ねて無駄を最小限に抑えながらサービスを構築していく手法」と言ってしまって良いかと思います。

検証の対象は多岐に渡ります。

  • 課題は解決すべきものか
  • 解決方法は顧客が求める形か
  • 顧客はお金を支払ってくれるか


詳細を知りたい方はぜひとも資料をお読みください。

リーン・スタートアップ

リーン・スタートアップ

  • 作者: エリック・リース,伊藤穣一(MITメディアラボ所長),井口耕二
  • 出版社/メーカー: 日経BP社
  • 発売日: 2012/04/12
  • メディア: 単行本
  • 購入: 24人 クリック: 360回
  • この商品を含むブログ (92件) を見る
Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

  • 作者: アッシュ・マウリャ,渡辺千賀,エリック・リース,角征典
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2012/12/21
  • メディア: 単行本(ソフトカバー)
  • 購入: 3人 クリック: 14回
  • この商品を含むブログ (18件) を見る

とにかく形から入ろう

ここからが本記事のメインの内容です。

リーンスタートアップを始めるにあたっての手順は本来様々だとは思いますが、
いくつかのツールを使えば本で紹介されるような内容を押さえた形でかなり素早くリーンスタートアップの導入をすることができます。

ここでいう「形から」という部分の具体的な内容は以下のとおりです。

  1. サービス全体をまとめる
  2. 課題が適切かどうかを問う
  3. 顧客がサービスに興味を持ってくれるか問う

それぞれを少し詳しく説明していきます。

サービス全体をまとめる

リーンスタートアップでは「リーンキャンバス」というものを書きます。
課題やその解決方法、顧客層、マネタイズなど様々な内容を書くことでサービスを俯瞰して捉えることができるとされています。

このリーンキャンバスを書く、というときにに使えるのがTinyCanvasです。
非常にシンプルなツールで起動したらログインなどは何もなくすぐさま書くのみで、URLさえ取っておければいつでも途中の状態を維持できます。
もちろん無料です。

こちらのツールで書いてみたのがこちら、OnlineIdです。

f:id:shoma2da:20140924203141p:plain

リーンキャンバスを書くにあたっての参考になればと思います。

課題が適切かどうかを問う

次に進みましょう。

特に技術者は、サービスを考えた時点ですぐに製品を作ろうとしてしまいがちですがリーンスタートアップの考えではこの時点で製品開発を始めるのは時期尚早です。

まずは課題設定が適切かどうかを確かめましょう。
課題を設定した時点ではほぼ全ての場合、「hogehogeは解決すべき問題だと思われる」といった未確認(サービス提供側の思い込み)の状態のはずです。

基本的にはこのときのおすすめの検証方法は顧客に直接話を聞くことです。
先ほどのリーンキャンバスで書いた顧客を見つけて話を聞きましょう。
ここでのコツは解決方法についてはまだ触れないことです。課題のみを話して共感してくれるかどうかで「解決くべき課題である」ということを検証します。

直接話を聞くのが難しかったり、とにかく早く回答数が欲しいといった場合はQuestantを使ってみるのも一つの手でしょう。

PC、スマホの両方に対応しておりかなり簡単にアンケートを作成することができます。
アンケートの作成や回答の収集が無料でできます。

ソリューションに問題がないか問う

課題が解決すべきものだと確認できた場合は解決方法が妥当かどうかの検証に入ります。

この段階でのやることも多岐に渡って考えられますが、個人的なおすすめはサービスのランディングページを作ってしまうことです。
サービスの概要をいち早く世に出すことで「解決すべき課題を適切な方法で解決しようとしているか」を検証することができます。

このときのおすすめサービスはStrikinglyです。
サクッとWebページを作ることができます。

Strikinglyを使えばWebサーバは愚か、HTMLやCSSの知識がゼロでもキレイなUIのページを簡単に作成できます。
用意するのは表示する文言と(載せたければ)数枚の画像だけです。
アクセス解析情報の閲覧やメールアドレスの登録フォームも用意できてかなり便利です。

このサービスを使って作成してみたのがMyBooks ~あなたにおすすめの本を月に1冊お届けします~ on Strikinglyです。
この程度のサイトであれば20分程度で作ることができました。参考になればと思います。

以上で今回の記事は終了です。
みなさまのリーンスタートアップの入り口になれば嬉しいです。

初めてのGo言語(golang)

突然新言語を書きたくなってGoを調べてみました。

Goってどんな言語?

Googleが開発した言語で2009年に登場しました。
公式サイトはThe Go Programming Languageです。
チュートリアルには日本語も用意されているので英語が苦手な方でもすぐに着手できます。

コンパイル型の言語だそうです。パラダイムはよくわからず...。

Goを書き始める

インストール

Macの方はHomebrewで一発です。

$ brew install go
$ go version
go version go1.3 darwin/amd64

そのほかのOSやMacだけどHomebrewを使わない、といった方はこちらを参照してください。

Hello World

Test.goファイルを以下の内容で作成してgoコマンドで実行します。

package main

import "fmt"

func main() {
    fmt.Printf("hello, world\n")
}
$ go run Test.go 
hello, world

できました。

チュートリアルをひと通りやってみる

チュートリアルはこちらです。
目に止まった特徴的だと感じたものを書き残しておきます。

Multiple results

タプル、と呼ばれたりするものですね。今どきの言語っぽいです。

package main

import "fmt"

func swap(x, y string) (string, string) {
    return y, x
}

func main() {
    a, b := swap("hello", "world")
    fmt.Println(a, b)
}
Named results

戻り値に変数名をつけて関数内ではreturnを書くだけで良いようです。
関数が長くなるとわかりづらくなりそうな気が...。

package main

import "fmt"

func split(sum int) (x, y int) {
    x = sum * 4 / 9
    y = sum - x
    return
}

func main() {
    fmt.Println(split(17))
}
Short variable declarations

関数内で使える暗黙的な型宣言らしいです。
型推論が充実すればこの書き方をする必要がないような...。今のところメリットはよくわかってません。

package main

import "fmt"

func main() {
    k := 3

    fmt.Println(k)
}
Slicing slices

配列の中の値をスライスして取得できます。これはなかなか便利そう。

package main

import "fmt"

func main() {
    p := []int{2, 3, 5, 7, 11, 13}
    fmt.Println("p ==", p)
    fmt.Println("p[1:4] ==", p[1:4])

    // missing low index implies 0
    fmt.Println("p[:3] ==", p[:3])

    // missing high index implies len(s)
    fmt.Println("p[4:] ==", p[4:])
}
Function values

今どきの言語っぽく関数はファーストクラスのようです。

package main

import (
    "fmt"
    "math"
)

func main() {
    hypot := func(x, y float64) float64 {
        return math.Sqrt(x*x + y*y)
    }

    fmt.Println(hypot(3, 4))
}
Goroutines

goキーワードを使って軽量スレッド上で実行できるそうです。
簡単でなかなか良さそうですね。

package main

import (
    "fmt"
    "time"
)

func say(s string) {
    for i := 0; i < 5; i++ {
        time.Sleep(100 * time.Millisecond)
        fmt.Println(s)
    }
}

func main() {
    go say("world")
    say("hello")
}
Channels

チャネル、という仕組みでスレッドの待ち合わせが簡単にできるみたいです。

package main

import "fmt"

func sum(a []int, c chan int) {
    sum := 0
    for _, v := range a {
        sum += v
    }
    c <- sum // send sum to c
}

func main() {
    a := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(a[:len(a)/2], c)
    go sum(a[len(a)/2:], c)
    x, y := <-c, <-c // receive from c

    fmt.Println(x, y, x+y)
}

所感

ささっとチュートリアルを見たぐらいなので、かなり浅い考察しかできていませんが今の思いを正直に書いていきます。

  • 型推論がいまいちすぎる??
  • ポインタ出てきた!?後発言語で見るのは逆に新鮮!
  • Map、配列の宣言があんまりきれいじゃないような...
  • 関数がファーストクラスだけど、それ以外に関数型らしさ(定数とか遅延評価的なもの)はほとんどない?
  • クラスの仕組みがないのにびっくり!(structにメソッドを定義する)
  • スレッドの扱いはかなり楽そう
  • 売りはどこなんだろう??スレッド?

こんな感じで第一印象はいまいちです...。
(パラダイムなど下調べをほとんどせずに書いているのも良くないですね...)

ただ、もう少し深く見ていけばオブジェクト指向や関数型の考え方からは少し離れた設計技法があるなど実はかなり奥が深い言語だったりするのかな?といった期待もあります。
今後も少しずつ調べていこうと思います!

Swiftことはじめ:String?のクエスチョンマークって何?

Swift出ましたね!

WWDCで突然の言語発表で驚きです。

f:id:shoma2da:20140603232720p:plain

 

無料のドキュメントが提供されており、ざっと読んでみた限り最近の言語のエッセンスを色々と取り込んだ良い意味で特徴のない(かなり書きやすそうな!)言語という印象を受けました。

 

今回はそんなSwiftの中のoptional valueなどと呼ばれている言語仕様について取り上げていきます。

 

どれのこと?

ドキュメント中に出てくる以下の様な記述です。

var optionalString: String? = "hello"
optionalString = nil
println(optionalString)

 

このString?、なんのことだかわかりますか?

 

このクエスチョンマーク、どうやって使うの?

使い方を見ていきましょう。

 

まず普通の変数宣言で以下の様に書いてみましょう。

var normalString = "aaa"
normalString = "bbb" //普通に代入できる
normalString = nil //コンパイルエラー!

なんとnilの代入ができません!

 

これは次のように書いたのと全く同じ意味になります。 

var normalString:String = "aaa"
normalString = "bbb" //普通に代入できる
normalString = nil //コンパイルエラー!

normalStringの型はStringです。

 

ではnilを代入したい場合はどうするのでしょうか?

そんな時に出てくるのがこのクエスチョンマークです。

var optionalString:String? = "aaa"
optionalString = "bbb" //普通に代入できる
optionalString = nil //代入できるようになった!

optionalStringの型はString?です。

 

このようにSwiftではデフォルトでは変数にnilが入らないようになっており、

nilを代入したい場合は型に?を付けた型で宣言します。

 

こうしたクエスチョンマーク付きの型は変数だけでなく関数の引数や返却値としても使用できます。

func optionalReceiveMethod(string:String?) {
    println("received value is [\(string)]")
}

optionalReceiveMethod("hello")
optionalReceiveMethod(nil) //関数の引数がStringだとエラーになります
func optionalReturnMethod() -> String? {
    return nil //返却値の型がStringだとエラーになります
}

 

次に変数の使い方を見て行きましょう。

使うときには?!が重要になります。

var noarmalString:String = "aaa"
println(noarmalString.uppercaseString)

var optionalStringFirst:String? = nil
//println(optionalStringFirst.uppercaseString) コンパイルエラー!
println(optionalStringFirst?.uppercaseString)
//?が付いたところを評価してnilならそこでメソッド呼び出しをやめて結果をnilとする

var optionalStringSecond:String? = nil
println(optionalStringSecond!.uppercaseString)
//!の場所はnilだろうがなんだろうが無理やり実行する→ここだとクラッシュします…

!を使ってしまうとoptional valueを使う意味がほとんどなくなってしまうので基本的には使わない方が無難でしょう。(詳細は後述します)

 

また以下のようにifで囲めばnilでないことがわかるので?!を使う必要はなくなります。

var optionalString:String? = "aaa"
if optionalString {
    println(optionalString)
}

 

使い方はここまでを把握できていれば十分かと思います。

 

なんでこんな言語仕様があるの?

結論から言ってしまうと「コンパイル時点でnilをチェックするため」です。

 

今までnilに起因したクラッシュが発生したことはありませんでしょうか?

おそらくみなさん経験していることでしょう。

 

Objective-Cでは値がないことをチェックするにはいわゆるnullチェックをしていたかと思います。

※厳密にはNSNullnilnullなどでそれぞれ対応は異なったりしますが話を簡単にしています。

 

しかし通常のnullチェックの場合、以下の様な欠点がありました。

  • nullになり得るかどうかをプログラマが考える必要がある→対応忘れが頻繁に起きる
  • ほんとにnullになるかどうかは実行時にわかる→ストア配布後などにテスト漏れによるnilに起因したクラッシュが発生する

 

こうした状況に対処できるのが今回説明しているoptional valueです。

上記の欠点についてoptional valueなら次のことが言えます。

  • nullになり得るかどうかは型で把握しているのでコンパイラが判断できる
  • ほんとにnullになるかどうかはコンパイル時点でわかる

 

つまり今まではプログラマが考えたり実行してテストしていたものをコンパイラという機械にまかせてしまうことができます。

 

さきほど!は使わない、と言いましたが!を使うとコンパイラによって得られる恩恵を全て無視してしまっていることがわかるかと思います。

良くないですね。

 

まとめ

optional valueは「値がない場合」の対応をほぼコンパイラに任せたような言語仕様でした。

 

nullについてはnull参照の考案は10億ドル単位の過ち?などと言われることもあるように旧来の言語ではなかなか苦戦していた部分でした。

今回はSwiftで説明しましたが他の言語を見てみると、KotlinやCoffeeScriptではSwiftと似たような機能が既に取り入れられています。

またScalaなど関数型の色が濃い言語ではMaybeモナドによる解決策なども図られています。

 

最近は自動テストやCIなどこれまでプログラマが行ってきたことはどんどんと機械に任せられていっています。

様々な言語の仕様でもその流れに沿っていて、メモリ管理・暗黙の値・遅延評価・今回のようなnull対応など、コンパイラや実行マシンに任せる比重もどんどんと増えているように感じます。

 

人にしかできないことがより強く重視されていくんでしょうね!楽しみ!!

Androidの自動ビルドと配布は今やこんなに簡単!

GitHub・Android Studio・Travis CI・DeployGateを組み合わせてAndroidアプリを自動ビルド→配布していきます。

 

自分でやってみてわかりましたが、今や簡単な設定だけでかなり高度なことができるようになっているんですね!!改めてびっくりです。

 

やりかた

プロジェクトの準備

まずはAndroidプロジェクトを準備します。

ここでの必須事項は以下2つです。基本的なところですので詳細は省きます。

 

  1. Android Studioでプロジェクトを作成
    →使ったことがない方は「今からAndroid開発を始めるなら」などをご覧ください
  2. GitHubにソースコードをpush

 

Travis CIでapkを自動ビルド 

CIサービスであるTravis CIを使って自動でapkのビルドをしていきます。

 

まずはTravis側で自動ビルドしてくれるように設定します。

TravisのAccountsメニューから対象のリポジトリのスイッチをONにするだけです。

f:id:shoma2da:20140525120014p:plain

 

次にAndroidプロジェクト内にTravisの設定ファイルである.travis.ymlを作成します。

公式ドキュメントはこちら→Travis CI: Building an Android Project (beta)です。

Androidのビルドに関してはつい最近beta版となったようです。

 

ファイル内容は以下のようにします。

language: android
android:
  components:
    - build-tools-19.0.3
    - android-19
    - sysimg-19
    - extra-android-support
  licenses:
    - android-sdk-license-bcbbd656
script:
  - ./gradlew assembleDebug

少しだけ工夫しているところはscriptの実行コマンドを変更しているところです。
このassembleDebugコマンドはAndroid Studioでデバッグ実行時のコマンドと同じものです。
(Android Studioで作ったプロジェクトはビルドは全てgradleを使っているのでこういったCIの設定もわかりやすくて良いですね)

これだけの設定でGitHubにpushする度にTravis側でapkを自動ビルドをしてくれるようになります。
簡単ですね!!

 

DeployGateで便利にアプリを配れるようにする

apkが自動ビルドされるようになったら動作確認などのために簡単にアプリをインストールできるようにしていきます。

そんなときに活躍するのがmixiのDeployGateです。(最新の情報を知りたければk_kinukawaさんをフォローしておくと良いでしょう!)

TestFlightの日本版といったところですかね。 

 

今ならベータプログラムに参加するとかなり良い条件でサービスを利用できますので是非登録だけでもしておきましょう。

f:id:shoma2da:20140525161309p:plain

 

サービス紹介はこのへんにして、Travisでビルドしたapkをアップロードしていきましょう。

DeployGateにはAPIが用意してあるのでこちらを使っていきます。

ドキュメント→https://deploygate.com/docs/api?locale=ja

 

では行きましょう。手順は以下のとおりです。

 

  1. travisコマンドをインストール
    New Command Line Clientを参照
  2. DeployGateのAPI Keyを確認
    設定ページから確認できます。
  3. API Keyを暗号化する
    travis encrypt DEPLOYGATE_TOKEN={確認したAPI Key}
    ↑この値を覚えておきましょう
  4. Travis設定を追加してapkをアップロードする
    env:
      global:
        - secure: "hogeohge" #←この行はすぐ上の暗号化手順で取得したもの
    
    # ...
    
    after_success:
      - curl -F "file=@./app/build/apk/app-debug-unaligned.apk" -F "token=${DEPLOYGATE_TOKEN}" -F "message=DeployGateに表示するメッセージ" https://deploygate.com/api/users/your_name/apps

 

これでpushする度にDeployGateにapkがアップロードされるようになります!

素晴らしい!!

 

.travis.yml全体を載せておきます。

language: android

env:
  global:
    - secure: "hogeohge" #←この行はすぐ上の暗号化手順で取得したもの

android:
  components:
    - build-tools-19.0.3
    - android-19
    - sysimg-19
    - extra-android-support
  licenses:
    - android-sdk-license-bcbbd656

script:
  - ./gradlew assembleDebug

after_success:
  - curl -F "file=@./app/build/apk/app-debug-unaligned.apk" -F "token=${DEPLOYGATE_TOKEN}" -F "message=DeployGateに表示するメッセージ" https://deploygate.com/api/users/your_name/apps 

 

さいごに

紹介は以上です。

「10年後に食える仕事、食えない仕事」なんて本がありましたが、自動化で置き換えられるような仕事は10年と待たずにどんどん無くなっていくかもしれませんね。 一体どうなることやら

10年後に食える仕事、食えない仕事

10年後に食える仕事、食えない仕事