あぼぼノート

頭の中空っぽ

坂道グループの中からもうすぐ誕生日を迎えるメンバーを教えてくれるLINE Clovaスキルをつくった

『さかたん』というLINE Clovaスキルをだいぶ前に公開しました。

clova.line.me

さかたんは、乃木坂46欅坂46、日向坂46のメンバーの中で、次に誕生日を迎えるメンバーを教えてくれます。

※noteに書いた記事の移植 坂道グループの中からもうすぐ誕生日を迎えるメンバーを教えてくれるLINE Clovaスキルをつくった|あぼぼ|note

使い方

😲「ねぇClova、さかたんを起動して」
🤖「グループ名か、坂道と言ってください」
😲「乃木坂」
🤖「8月20日に、乃木坂の秋元真夏さんが26歳、乃木坂の白石麻衣さんが27歳を迎えます。」

グループ名は「坂」を省略することが可能です。グループを絞らない場合は「全部」とか「坂道」と言ってください。該当するメンバーが複数いる場合は↑のように全員喋ります。

あとは、当日なら

🤖「本日8月10日に、乃木坂の齋藤飛鳥さんが21歳になりました。」

と喋ります。

つくった理由

・特定のメンバーの誕生日ならググればすぐ知れるけど、つぎ誰が何歳になるかはすぐにはわからないなーと思ったから ・Clovaスキル(と乃木坂46が昔コラボしてたので)つくりたかった

技術について

言語はSwiftを使いました。LINEがSwift用のSDKを用意してくれてるのと、ぼくが一番書き慣れている言語なので。Swift以外にNode.jsとかPythonとかKotlinとかgoもありますよ👶

github.com

あとは動かすためにDockerとHerokuを使いました。SDKに組み込まれてるので、楽チン!Herokuのssl対応は別途必要です。

Swiftは型名や変数名に日本語が使えます。

enum 坂道: String {
    case 乃木坂 = "のぎざか"
    case 欅坂 = "けやきざか"
    case 日向坂 = "ひなたざか"
}

struct Member {
    let name: String
    let kana: String
    let birthday: Date
    let group: 坂道
}

今回一番時間がかかったところは、メンバーのデータを作るところですかね。欅坂46のサイトはコピペできないようになってて大変でした🙄

// MARK: - 乃木坂46
let nogizakaMembers: [Member] = [
    // MARK: 1期生
    Member("秋元 真夏", "あきもと まなつ", "1993年8月20日", .乃木坂),
    Member("生田 絵梨花", "いくた えりか", "1997年1月22日", .乃木坂),
    Member("井上 小百合", "いのうえ さゆり", "1994年12月14日", .乃木坂),
    Member("齋藤 飛鳥", "さいとう あすか", "1998年8月10日", .乃木坂),
    ...
]

ほかには、ローカルとheroku上とでタイムゾーンが違うことによるDateFormatterの扱いとかは少し悩みました。

そしてClovaの発話のための処理と、汎用的な坂道グループのデータを分離したので、今後何かしらに応用できるかもしれないし、できないかもしれません。

Clovaスキルの審査について

LINE Clovaスキルストアに自作スキルを公開するには、LINEによる審査に合格する必要があります。さかたんは1回落ちました。

指摘箇所は6箇所で、パッと見結構多いな・・・と思ったんですが、指摘理由が明確で、且つ修正例も載せてくれたりと、どう直せば良いか分かりやすくて助かりました。

審査のスピード感ですが、さかたんの場合、初回の審査結果は申請してから38時間後、2回目は40時間後に返ってきました。つまりそれぞれ2営業日内で審査していただきました。

Clova Developer Centerでスキルごとに統計も見れます。今回の審査員はClova DeskとClova Friends miniの2台でテストしてた、というのがログ見ると分かったりします。

今後の懸念

メンバーが卒業するたびに泣きながらメンテする必要があり、メンタルがもつか心配です。

メンバーの更新だけならLINEの再審査なしで行えるので

『10歳でもわかる問題解決の授業』を読んで

解決策に急がない、というのは大事だな〜。

問題解決の意識を変えること

  • 問題解決を一発ですますことは不可能であるということを理解する
  • 問題解決はサイクルである。一度意思決定してそれで終わりではない
  • テストは複数の選択肢があれば、その中に必ず「正解」がある。実際の問題には、いくら案があろうがその中に"最高の"効果をあげるものがあるという確信は誰も持てない。「この選択肢はこういう効果があった」という実験結果に価値がある

現象ではなく論点を考える

  • 現象は表立って目に見えている問題、論点は問題解決に繋がる打ち手を導くもの
  • 「算数の成績が良くない」は現象、「計算ミスが多い」「割合の理解不足による間違いが多い」「一度解いたことのある問題が定着していない」は論点
  • 「解決策」に急ぐのではなく、「問題設定」を疑ってみること。正しい問題=論点が設定されていないと効果的な打ち手に繋がらない

感想

決定することが苦手だけど、繰り返すことを前提に意思決定を怖がらないようにしていきたい。それから筋のいい仮説をたてたり、検証結果を正しく読み解くために、「解決」を急がないようにしたい。

『ライト、ついてますか』を読んだ

f:id:aboy_perry:20190807000134p:plain

人生や仕事は「問題」の連続です。この本には、問題をどう発見するのか、どう定義するのか、どう解決するのかについてのヒントがたくさん詰まっているなーと思いました。

この本にはこれらの「標語」のようなものがいくつも出てきます。

問題によっては、それを認識するところが一番むずかしいということもある(p55)


結論に飛びつくな、だが第一印象を無視するな(p62)


他人が自分の問題を自分で完全に解けるときに、それを解いてやろうとするな(p89)


もし人々の頭の中のライトがついているなら、ちょっと思い出させてやる方がごちゃごちゃいうより有効なのだ(p104)

この標語だけを見ていくのでも楽しめるのですが、この本では各章、各部がそれぞれケーススタディのようになっていて、その中身こそが重要です。


  • 「誰の問題か?」
  • 「問題は何か?」
  • 「この問題はどこからきたのか?」

という問いが、本全体で何度も繰り返されます。それゆえ重要な問いで、問題を正確に見極めるには不可欠な問いだと思います。

翻訳は少し読みづらいところもあったんですが、内容はよかったです。会社のCTOに教えてもらった本なので、CTOにお礼を言っとこうと思います。

2019年01月に読んだ本

もう2月になってしまったけど1月に読んだ本!1冊だけ!

ITエンジニア的論理思考テクニック! 仕事ができる人になるための13の極意。

チームリーダーにオススメされ読んだ。文章は読みやすかったし、値段相応の量でサックリ読める。

自分がとくにキーワードしてあげるなら以下の2つ!

  • 定量的に説明する
  • ロジックツリーで伝える

「作業を終えるにはもう少しかかりそう」 => 「作業を終えるには1人日かかりそう」 => 「もう1人日かかりそう。今日は障害対応で作業ができなかったため。」

日々の仕事の報連相でクセづけていきたい、と思うと同時に、やりすぎだろと思う部分もあったので、うまいこと調整してやっていきたい気持ち。

2019年の目標

来年2019年に自分が何に注力するのか、どういう状態になっていたいのか、というのをざっくり書いておくことで、定期的に自分で振り返る材料にしたい。

ここに書いたことは確定ではないし、1年間ずっと固執するわけでもない。多分変わる。

お金を稼ぐ

2019年はお金をもっと稼ぐ。その選択肢はここに書けるものもあれば書けないものもある。

書けるものでいうと、これとは別のブログを作ったり、あとはアプリを作ったりする予定。

なぜお金を稼ぎたいかというと、来年は今年以上にお金を使う年になりそうだから。

お金を使う

しかるべきものにお金を使う。これはプログラミングのことだけじゃなく生活まわりや、自分の健康面などもそうだ。

多分大量にお金を使うことになるのだが、今の収入では確実に足りないので、最初のうちは金額や時期的な面で優先順位を考えながらお金を使っていくことになるだろう。

本を読む習慣をつける

技術書だけじゃないけど、本を読む。

とりあえず外部サービスの読書メーターを使い始めたので、これで管理してこうと思う。

bookmeter.com

そのほか、読んだ技術書に関しては1ヶ月毎くらいでまとめて記事にしたりしてみる。とりあえず今月はこれ

aboy-perry.hatenablog.com


ということで3つ書いたけど結局のところ2019年で1番大事な目標は、お金を稼ぐこと。そのための環境の変化は受け入れる。

みなさま良いお年を。

2018年12月に読んだ技術書

思いつきで書いてみる。と言っても2冊しか読んでない。

アジャイルサムライ――達人開発者への道

昔から読みたかった気持ちはあったけど、仕事で読む必要に迫られたので読んだ。実際は10月くらいに買ってざっと流し読みしたあと、仕事で必要なときに読み返して使った。

読みやすいし面白かった。また1つのフレームワークが知識として残った。

比較して学ぶRxSwift入門 (技術書典シリーズ(NextPublishing))

これは自分のためにではなく、チームに入ってくるiOS開発未経験のメンバーにオススメできるかどうか、毒味的に読んでみた。

毒味といっても、RxSwiftに関する書籍は現状これぐらいしかないはずなので、結構期待して買った。題名のとおり、iOS開発の入門をサックリ終えたあとにRxSwiftを学び始めたいと思っている人が読むような本だった。内容は基礎的で、そこまで深く説明はされないものの、入門としてはいいんじゃないかと思う。

そこまで高くないし眠くなるようなボリュームではないので、サックリ読める本。Cold/Hotの違いとかも最低限の説明がされてあるので良い。

iOS(Swift)エンジニアがGoでAPI作って感じたこと

普段Swiftを使ってiOSアプリを開発している私が、GoでAPIを開発した際に感じたことを紹介します。

列挙型(Enum)がない!

SwiftではEnumをめちゃめちゃ使います。ですがGoにはありません。が、Goではtypeを用いて擬似的にEnumっぽいことを実現できるようです。

Swift

enum Edge: Int {
    case top, bottom, leading, trailing
}

Go

type Edge int

const (
    Top Edge = iota
    Bottom
    Leading
    Trailing
)

interfaceを実装することでEdgeを拡張することができます。たとえばStringerインタフェースを実装すると、文字列での出力ができるようになります。

type Edge int

const (
    Top Edge = iota
    Bottom
    Leading
    Trailing
)

func (c Edge) String() string {
    switch c {
    case Top: return "上端"
    case Bottom: return "下端"
    case Leading: return "左端"
    case Trailing: return "右端"
    default: return "Unknown"
    }
}

Swiftエンジニアからするとちょっと違和感がありますね。そうです、ケースを網羅していてもdefault節は必要です。enumではないですからね。

ただinterfaceを実装することでEdgeをどんどん拡張していくことができるので、自由度は高いです。

ついにポインタを学ぶときがきたか...

Swiftにも、UnsafePointerなどのポインタを扱えるAPIがあるのですが、業務や趣味含めて一度も触ることはなかったため、業務としてはGo言語で初めて触れることになりました。正直今も100%理解できている自信はないです。

SwiftエンジニアにおけるGo言語へのハードルを低くする目的で書きますが、ポインタの使い方のひとつとして、SwiftでいうOptional型のような使い方があると思ってみるといいのではないかと思います(あまり真に受けられると困るのですが)。私は最初そう思うことで、自分なりにGo言語に対するハードルを下げていました。

SwiftのOptional型のような、というのはつまりnilを使いたいときにポインタ型を使うということです。たとえばAPIレスポンスのjson定義とか、DBのカラムの定義とかです。

type User struct {
    ID int `json:"user_id"`
    Name string `json:"user_name"`
    Age *int `json:"user_age,omitempty"`
}

これでuser_ageがnullじゃなければAgeをjsonに含めるということができるようになったりします。

そのほか、例えば構造体は値型ですので関数に渡すときなどコピーが生成されますが、ポインタを渡すことで元の構造体を参照できます。

type Position struct {
    X float64
    Y float64
}

func Exchange(p *Position) {
    x, y := p.X, p.Y
    p.X = y
    p.Y = x
}

ただポインタはやはり重要な概念だと思いますので、Goと仲良くなってきたらしっかり腰を据えて学びましょう。 Pointers — An Introduction to Programming in Go | Go Resources

これ使っとけばOKなフレームワークがない

iOS開発でいうところのCocoa Touch(UIKit)に相当するようなものがないという認識です。私は業務でAPIを作りましたが、そのときは社内で一番採用実績があること、ミニマムであること、ドキュメントドリブンなところなどに惹かれgoaを採用しました。

github.com

ほかにもたくさんあるみたいなので興味があればご覧になってみてください。7 Frameworks To Build A REST API In Go | Nordic APIs |

ただこれは躓いたというよりは当たり前のことで、「選択肢の中からメリット/デメリットなど特徴を理解したうえでそのとき最適なものを選ぶ」という、課題解決においては普通のことが必要になるということでした。

ビルドはやい

※2018/12/19思いついたので追記

SwiftでのiOSアプリ開発に比べるとビルドが早いです。

コード書いてビルドして確認(orテスト)の一連のスピード感が速まるとテンポよく開発できます。

iOSアプリではビルドを待ってる間に仮眠したりトイレに行ったりできますので、それもそれで嫌いじゃなかったんですが、やっぱテンポ良く開発できると気持ちがいいもんです。

エラーハンドリングでゲシュタルト崩壊

if err != nilif err == nilゲシュタルト崩壊を起こしました。今自分がどちらを書こうとしているのかわからなくなります。

if err != nil {
    // 異常系処理
}

if err == nil {
    // 正常系処理
}

Swiftのエラーハンドリングに慣れていると最初のうちはゲシュタルト崩壊を体験するかもしれませんが、大丈夫ですそのうち慣れます。

Gopherくんが可愛い

iOS開発には存在しない、Go言語公式のマスコットキャラです。仕事で疲れた心を癒してくれました。

https://raw.githubusercontent.com/egonelbre/gophers/master/.thumb/animation/gopher-dance-long-3x.gif

github.com

おわりに

最初のうちは、Swiftの慣れからくるGo言語への抵抗感がありましたが、今はそうでもないです。

むしろGopherくん可愛いし、やっぱり自分の中に新たな知識が流れ込んでくるのは新鮮ですね。

これからもGoと仲良くしてまいります。