GenerambaとSourceryでファイルとボイラープレートコードを自動生成する

やりたいこと

Viewを作るためのコードを作っていた際に、 下記のようなコードを繰り返し書くことがありました。

このようなボイラープレートコードを何度も書くのは面倒です。

自動でコードを生成する仕組みを使えないかと思い、自動生成するための処理を書いてみました。

public class SampleView: UIView {
    @IBOutlet private var nameLabel: UILabel!

    public var name: String? {
        get {
            nameLabel.text
        }
        set {
            nameLabel.text = newValue
            nameLabel.isHidden = newValue == nil 
        }
    }
}

完成物

GitHub - 46kuro/AtomicDesignSample

$ sh CreateTemplate.sh -n Sample -p name=String,name2=String

上記のようなCommand1つで、SampleViewというPublicなClassと、name, name2の2つのPropertyとIBOutletのProperty、空のXibファイルを生成することができました。

処理の流れ

  • Templateのファイルを生成する
  • Templateファイル内にPropertyに紐づくコードを生成する

全てを自前で実装することはとても難しいと思ったので、ライブラリに頼りつつ、上記処理を実装していきました。

Templateのファイルを生成する

ファイル生成ではxctemplateを使用する方法などもありますが、コマンドライン上からファイルをXcodeのReferenceに追加したかったので、Generambaを使用しました。

Generambaを使用し、下記のようなSwiftコードを生成していきます。

import UIKit

public class {{ module_info.name }}View: UIView {

    // sourcery:inline:{{ module_info.name }}View.TemplateName
    // sourcery:end

    override public func awakeFromNib() {
        super.awakeFromNib()
    }
}

Generambaを使用することで、Command上から法則性に沿ったSwiftファイルを作成することができました。

sourcery: のコメントは、次に説明するSourceryで生成されるコードを入れる範囲になります。

Templateファイル内にPropertyに紐づくコードを生成する

先ほど作成されたSwiftファイルに対し、Propertyに紐づくコードを生成していこうと思います。

コード生成のためにSouceryを使用しました。

Sourcery is a code generator for Swift language, built on top of Apple's own SourceKit. It extends the language abstractions to allow you to generate boilerplate code automatically.

メタプログラミングツールとして使われる、ボイラープレートコードを自動生成するためのツールです。

今回くらいの規模感であれば、Shellで書こうと思えば書けるような気もしますが、Sourceryの勉強のために使ってみました。

Sourceryを使ったコード生成の処理について1つずつ説明すると長くなりそうなので、別で記事を書こうと思います。

こちらのようなコードを生成することができました。

import UIKit

public class SampleView: UIView {

    // sourcery:inline:{{ module_info.name }}View.TemplateName    
    @IBOutlet private var nameLabel: UILabel!

    public var name: String? {
        get {
            nameLabel.text
        }
        set {
            nameLabel.text = newValue
            nameLabel.isHidden = newValue == nil 
        }
    }
    // sourcery:end

    override public func awakeFromNib() {
        super.awakeFromNib()
    }
}

最後に sed -i '' -e '/sourcery:/d' でsourcery関連のコメントを削除すれば、ボイラープレートコードをコマンド上で自動生成することができました。

参考

感想

GenerambaとSourceryを使用することで、コマンド1つでTemplateを作るところまでできました。

できたことはとりあえず良かったですが、依存しているツールも多くなってしまったので、もう少しシンプルな形にして実際にプロジェクトで使えると良いなと思います。

Souceryはいつか触ってみたいと思いつつ手が出せていなかったので、Stencilの文法やドキュメントの見方などを勉強する良い機会になりました。

メタプログラミングはとても面白いと思うので、Souceryを支えているSouceKitなどのFrameworkも勉強していきたいと思いました。

Generambaは、コマンドからSwiftファイルを生成するいい方法が他に分からなかったので、取り急ぎ使用しています。他に使いやすいツールがあれば、そういうものを使用したいです。

もしかしたら、Sourcery(SourceKitなどのツール)のみでSwiftファイルを生成する方がシンプルかもしれません。

【PyCon JP 2019 Tutorial】Lambda(Python)を使用したサーバレスのハンズオン

PyCon JP 2019 Tutorialに参加したので、学んだことをざっくり書き残しておきます。

資料

speakerdeck.com

進め方

  • Lambdaについての説明
  • Lambdaを始める(ハンズオン)
  • サーバーレスアーキテクチャとLambdaの位置付け
  • Lambdaと周辺サービスでAPIサーバーを作ってみる

チュートリアルのゴール

  • AWS上で構築するサーバーレスアプリケーションの基本構成について知る
  • Lambdaの利用に十分な基本的な構成を知る
  • AWSの基本的なマネージドサービスを使って、サーバーレスなAPIの構成と作成手順を知る

Lambdaについての説明

AWS Lambdaとは

  • FaaS(Function as a Service)の1つ
  • AWS上のカテゴリーは「コンピューティング」(その他にはEC2など、プログラミングの実行環境)
  • マネージされたコード実行環境を提供

基本機能

  • 共有されたステートレスな実行環境
  • AWSの各種サービスとの連携
  • 柔軟なスケーリング
  • 関数のバージョニング
    • バージョンを指定することも可能
  • CloudWatchによる監視
  • StepFunctionsによる関数間オーケストレーション
    • より複雑な処理が可能に
  • Lambda Layerによる共通コンポーネントの管理
    • 割と新しい機能
    • 共有レイヤーを作ることができるようになった

AWS Lambdaで利用可能な言語について

  • Python
  • Node.js
  • Go などなど

AWS Lambdaの利点

  • コンピューティングリソースの有効活用
    • アイドルタイムに課金されない
  • アプリケーションコードのスケーラビリティ
    • 冪等性は必要(関数の設計が重要になる)
    • 事前のリソースプロビジョニングが基本的に不要になる
  • AWSの各種サービスとの親和性
    • イベントドリブンによる自動化やサーバレス化

実行ライフサイクル

  1. ENIの作成
  2. コンテナの作成
  3. デプロイパッケージのロード
  4. デプロイパッケージの展開
  5. ランタイム起動・初期化
  6. 関数/メソッドの実行(課金対象)
  7. コンテナの破棄

コールドスタートとウォームスタート

  • ライフサイクルの1から全て実施するのがコールドスタート
  • コンテナを再利用して実行されるのがウォームスタート
  • コールドスタートの場合
    • 1~7をすべて行う
  • ウォームスタートの場合
    • 3~6まで

Lambdaの利用例

  • APIサーバとして
  • AWSリソース管理の自動化
  • IoTサービスのバックエンドとして
  • ストリームデータのバックエンドとして
  • ETL処理

Lambdaの開発でよく利用されるツール群

  • 構成管理
  • AWS SDK
    • boto3
  • AWSサービスのモックツール
    • LocalStack
    • moto
  • API仕様書の記述
    • OpenAPI(Swagger)

SAM

  • AWS Serverless Application Model
  • CloudFormationの拡張として実装されていて、構成管理まで含まれる

boto3

開発環境

Cloud9

  • AWSが提供しているクラウド上でのアプリケーション開発環境
  • コードエディタと開発環境がWeb上で使える
  • 今回は環境を整えるために使用

ハンズオン

ファイルのアップローダ/ダウンローダAPIを作成しながら、Lambdaについて学びました。

デプロイ

makefileを使って、デプロイ手順をMakefileにタスクとして記載することで継続的に実行するようです。

dev.classmethod.jp

エラーの確認方法

  • CloudFormation内部のイベントに、エラーが出力される
  • CloudFormationがErrorでRollbackになっているときには、一度削除してから再実行すること

リソースタイプの調べ方

AWSの公式ドキュメントから探していくことになる

docs.aws.amazon.com

困ったら、「使いたい機能 + Cloud Formation」で検索をかけるのが手っ取り早い

SAMはCloudFormationをサーバーレスアプリケーションに拡張したものなので、CloudFormationを知っておくと早いようです。

qiita.com

感想

AWS Lambdaを使用する上で、基本的な知識を学ぶことができました。

デバッグの方法とか、調べ方について学べたことは、本を読んで学ぶ以上に価値があったと思います。

自分でやろうと思ったときに全く分からなくなりそうなので、ハンズオン形式で学べてとても良かったと思いました。

AWS Lambdaは万能ではなく、現場で使う際には、他のAWSサービスと比較・検討した上で使用する必要があると学んだので

取り急ぎは個人でAPIを作りたいときや、何かしらのAWSサービスをトリガーとして関数を実行したいときに使ってみようと思いました。

その他、作業しながら感じたこと

  • awsのコマンド、SAMのコマンド、makeのコマンドとか、CLIをたくさん学んだ
  • そもそも、CloudFormationってなんだろう?
    • デプロイを簡単に、再現性を持たせるためのツール
    • ちゃんと調べる
  • Cloud9のいいところは?現場に使う?料金体系は?
  • クラウドサービスは、余剰にお金がかかってしまうんじゃないかという不安がある
    • 中途半端な知見で始めると、痛い目を見そうという不安
  • こういうのやってみたい

スクラムガイド

PDF

https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf

スクラムをやるのであれば、チーム全員で最低限共有しておきたい前提やルールが記載されています。

学んだこと

スクラムの定義

複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ独創的に届けるためのものである。

スクラムは1990年代初頭から、複雑なプロダクト開発の管理に使用されてきた。

スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されている。それぞれに目的があり、スクラムの成功や利用に欠かせない。

スクラムのルールは、役割・イベント・作成物から、関係性や相互作用を統括する。

スクラムの理論

スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。

反復的かつ漸進的に最適化とリスク管理を行うところが、理論としてとても良いと感じた。

経験的プロセス制御の実現

以下の3本柱に支えられている。

  • 透明性
  • 検査
  • 適応

スクラムの価値基準

5つの価値基準を上手に実践する。

  • 確約(commitment)
  • 勇気(courage
  • 集中(focus)
  • 公開(openness)
  • 尊敬(respect)

スクラムチーム

スクラムチームはプロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。

スクラムチームは、プロダクトを反復的・漸進的に届けるための能力を持っている。

プロダクトオーナー

プロダクトオーナーは、開発チームの作業とプロダクトの価値に最大化に責任を持つ。その作業は、組織・スクラムチーム・個人によって大きく異なる。

プロダクトバックログの管理に責任を持つ1人の人間であり、プロダクトバックログの優先順位の変更については、プロダクトオーナーと相談する必要がある。

開発チームに作業を依頼できるのは、プロダクトオーナーだけであり、開発チームもプロダクトオーナー以外から作業依頼を受け付けてはいけない。

開発チーム

開発チームは、各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届けることのできる専門家で構成されている。インクリメントを作成できるのは、開発チームのメンバーだけである。

自己組織化されているチームのため、プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も教えてくれない。

スクラムマスター

スクラムマスターは、スクラムの理解と成立に責任を持つ。そのためにスクラムマスターは、スクラムチームにスクラムの理論・プラクティス・ルールを守ってもらうようにする。 スクラムマスターは、スクラムチームのサーバントリーダーである(訳注:メンバーが成果を上げるために支援や奉仕をするリーダーのこと)。

スクラムマスターは、プロダクトオーナー・開発チーム・組織をさまざまな形で支援する。

スクラムイベント

スクラムで固定されたイベントは規則性を作り出し、スクラムで定義されていないミーティングの必要性を最小化する

定義されているミーティングに対して、時間を取って、それ以外は極力取らないという方法はとても面白い。

スプリント

スクラムの中心はスプリントである。これは、「完成」した、利用可能な、リリース判断可能なプロダクトインクリメントを作るための、1 か月以下のタイムボックスである。

スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。

スプリントの中止

スプリントはタイムボックスの終了前に中止でき、スプリントを中止する権限があるのは、プロダクトオーナーのみ。

スプリントプランニング

スプリントの作業はスプリントプランニングで計画する。これはスクラムチームの共同作業だ。

スプリントプランニングでは、スプリントで何ができるか、選択した作業をどのように成し遂げるのかという質問に答える。

スプリントゴール

スプリントゴールはスプリントの目標セットであり、プロダクトバックログの実装によって実現するものである。

計画するときには、スプリントゴールを念頭に置き、スプリントゴールを達成するために、機能や技術を実装する。

デイリースクラム

デイリースクラムとは、開発チームが活動の速度を合わせ、次の24時間の計画を作る15分 間のタイムボックスのイベントである。前回のデイリースクラムから行った作業の検査と、次回のデイリースクラムまでに行う作業の予想を行う。

複雑にならないようにするため、毎日、同じ時間・場所で開催される。

スクラムマスターは、開発チームにデイリースクラムを開催してもらうようにするが、デイリースクラムを開催する責任は開発チームにある。

スプリントレビュー

スプリントレビューとは、スプリントの終わりにインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。

スクラムチームと関係者がスプリントの成果をレビューし、価値を最適化するために次に何ができるかを参加者全員で話し合う。

スプリントレトロスペクティブ

スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。

スプリントレビューが終わって、次のスプリントプランニングが始まる前に行う。

スクラムの作成物

スクラムの作成物は、作業や価値を表したものであり、透明性や検査・適応の機会を提供するものである。

プロダクトバックログ

プロダクトバックログは、プロダクトに必要なものがすべて並べられた一覧であり、プロダクトに対する変更要求の唯一の情報源である。プロダクトオーナーは、プロダクトバックログの内容・可用性・並び順に責任を持つ。

プロダクトバックログは決して完成せず、プロダクトや使用環境に合わせて進化する。

プロダクトが使用されて価値が増加し、市場からフィードバックを得られると、要求の変更が変化し続ける。ビジネス要求・市場の状態・技術の変化が、プロダクトバックログの変化につながる。

ビジネス要求から技術までを全て一元管理している状態は、とても理想的だと感じました。

スプリントバックログ

スプリントバックログは、スプリントで選択したプロダクトバックログアイテムと、それらのアイテムをプロダクトインクリメントにして届け、スプリントゴールを達成するための計画を合わせたものである。

スプリントバックログは詳細で、今後も変更される可能性のある計画である。

インクリメント

インクリメントとは、これまでのインクリメントの価値と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものである。

インクリメントが動作する状態であり、スクラムチームの「完成」の定義に合っていることを意味する。

作成物の透明性

スクラムは透明性に依存している。作成物の状態を把握することで、価値の最適化やリスクの制御に関する決定を行う。透明性が確保されている限り、こうした決定には信頼できる根拠が存在する。

「完成(Done)」の定義

プロダクトバックログアイテムやインクリメントの「完成」を決めるときには、全員がその「完成」の意味を理解しておかなければいけない。

【読書】ザ・マインドマップ

読んだきっかけ

情報を書き溜める場所や書き留め方に困ることがよくあります。一般的なメモであれば、ディレクトリ構造で情報をまとめていきますが、書いている途中で構造的に破綻することがあります。一方で構造化しないとディレクトリあたりの情報量が多くなり、見つけにくくなります。

情報をまとめていく上で、効率の良い方法を探して、本書を読みました。

読んだ本

新版 ザ・マインドマップ(R)

新版 ザ・マインドマップ(R)

  • 「学び方」をどうやって学ぶのか
  • 「考える」とはどういうことなのか
  • 記憶術として最強の技法は何か
  • 創造的思考法として、もっとも優れたテクニックは何か
  • 速読術の中で、速度・効率とも最高の手法は何か
  • 思考法全般の中で、何がいちばん優れているか
  • 新しい思考法や究極の思考法は開発できるのか

マインドマップについての本です。

本から学んだこと

脳の動き

  • 直線思考(一次元的)
  • 平面思考(二次元的)
  • 放射思考(多次元的)

マインドマップ

特徴

マインドマップは思考全般に使えるツールで、考えていることを視覚化して図で表す。「脳の万能ナイフ」と評されるマインドマップは、あらゆる認知機能に応用でき、記憶、創造性、学習の3分野でとくに大きな効果を発揮する。

テーマを1つ決め、そこから放射線状に書くことで、多次元的な思考ができる。

イメージ(絵)を使用する

描かれている言葉をイメージにすることで、アイディアを生み出しやすくする。

落とし穴

用途

本を読んで感じたこと

ディレクトリの整理方法

あまり深く考えずに、細かくディレクトリは設定しておいて、上位概念の存在が必要になった段階で整理していくのが良いと思いました。

例:iOSの情報をまとめるためのディレクトリを用意しておいて、Androidの情報をまとめる必要が出てきたら、Mobileを用意してiOSAndroidを入れる。さらに、Webのディレクトリも必要になったら、フロントエンドとしてまとめるなど。

ブログの位置づけ

Twitterに書くこと・ブログに書くこと など、SNSによってどのような書き分けをしようかと思ったことがあります。あまり考えずにSNSやった方が気楽ですが、ルールを設けていかないと、ブログに何でも書きそうなので、ブログの位置づけを考えました。

下のような書き分け方で、複数のツールに頼って思考を整理していくことが良さそうだと感じました。

Hack Day 準備#1

Hack Dayが今年も開催されます!

私は、昨年度もHack Dayに参加させて頂いたのですが、とても楽しかったので、今年も参加したいと思っています。

kuro-46.hatenablog.com

応募は9月2日(月)からで、先着順のようです。早めにエントリーしておきたいですね。

昨年出たメンバーとも、今年も出られるなら出たいという話を以前からしていたため、Hack Dayの準備として一度ランチをしながら、どういう方向性でつくろうか考えました。

方針

各自やりたい技術を優先する

何かしらの形で賞を取るためにアイデアを練って実現するために取り組むことも考えたのですが、休日を使って何かものづくりをする以上、新しい学びが得られると良いねという話になりました。

昨年度は、「ハッカソンを楽しむ」ために、各々ができることを行ってつくっていたのですが、今回は「#つくるってたのしいね」に沿って、普段業務ではできないような、技術的な遊びをしようという方針に決めました。

学びたい分野としては、下のような分野が挙げられました。何かしらやりたい分野から化学反応が起きたり起きなかったりするといいなと思っています。

取り急ぎ、9月2日(月)からの応募を忘れないようにしたいです。

【読書】任せるリーダーが実践している 1on1の技術

読んだ本

任せるリーダーが実践している 1on1の技術

任せるリーダーが実践している 1on1の技術

1on1について、アドラー心理学とのつながりを記載しながら書いた本です。

学んだこと

1on1とは?

シリコンバレー中心に広がった、1対1形式で週に1度、30分などコミュニケーションを行うこと。

期待される効果

  • 会社と社員のエンゲージメント(絆・愛着)向上
  • 心理的安全性(Psychological Safety) → 高業績に大きく影響を与える
  • アジリティ(機敏さ)とスピード向上
  • 意欲向上
    • アメとムチによる「外発的動機づけ」
    • 仕事自体が楽しみになる「内発的動機づけ」
  • スキルアップ
  • 理念・戦略へのアラインメント(方向の調整)
  • 問題の早期発見、対処
  • リテンション(人材の維持・離職防止)

失敗パターン

  • 時間が取れない
  • 話のネタが尽きてしまう

1on1の目的

  • 経験学習サイクルを回せるように支援
    • 経験→内省→概念化→新たな試み
  • 組織の成功循環モデルを回す
    • 結果の質→関係の質→思考の質→行動の質

1on1に必要なスキル

傾聴

3割話し、7割聞くように努力。

  • 相づち
  • オウム返し
  • 述語的会話:「それで?」「それから」
  • 沈黙:深い内省の時間
  • 非言語:表情や目線など
  • ページング:スピードや言葉遣いなどを相手に合わせる

勇気づけ

「自分には能力があり、周囲の人は仲間である」という感覚

質問

頭に空白を作り、思考を促す

  • 5W1H
  • Yes or No
  • 要約
  • 相手ペースで質問

フィードバック

事実と意見を分けて話す

以下の流れを意識する

  • 傾聴
  • 経験学習サイクル
  • 課題の分離
  • 協力と目標の一致
  • 解決志向ブリーフセラピー

マインド

  • 尊敬:行為と人格を分離
  • 信頼:根拠なく白紙委任状を出す
  • 協力:過干渉せず、放任せず
  • 目標の一致:競合的態度を排除する
  • 共同体感覚:他社を助け、喜ばせることを喜ぶ

【読書】行動科学を使ってできる人が育つ! 教える技術

読んだ本

行動科学を使ってできる人が育つ! 教える技術

行動科学を使ってできる人が育つ! 教える技術

最近、仕事で後輩の教育係を行っています。

後輩の教育を行う上で参考になるかも、と先輩から本書を借りて読みました。

育成を行う際に気をつけることについて、記載されている本です。

学んだこと

育たない原因

  • 「仕事は細かく教えるのではなく、盗んで覚えるもの」という古い考え方
  • 環境の変化
  • 環境の変化による、価値観の多様化

行うこと

心ではなく、行動に焦点を当てる

  • 対象となる人の「行動」を観察・分析
  • 望ましい行動なら、その行動をさらに実行し続けるようにする
  • 行動が間違っているなら、正しい行動に置き換えるための仕掛けを施す

信頼関係を構築

チーム内で信頼関係を築いていくために、必要な話。

  • プライベートの話をする
  • 小さい成功体験を褒めることで、見られているということを間接的に伝える
  • 失敗体験を話す

個人的には、あまり知らない人とプライベートの話をしたいと思いません。

本の中には鉄則として記載されていましたが、本が執筆されたときから時代が変わっていたり、個人差もあると思うので、全てをそのまま適用してはいけないなと感じました。

コミュニケーションの量を増やす上でプライベートの話をするよりは、「大学のとき何してた」とか、本人が今まで何をしてきたか、から入る方が良いのではないかと考えています。

動機を把握

仕事に関してどんなふうに成長していきたいと考えているのかを把握する必要がある。

そもそもの動機が弱い人もいると思うので、このあたりは無理に聞くのは良くないなと思いました。

内容の分割

  • 知識と技術に分ける
    • 知識:内容を知っている状態
    • 技術:課題を解決できる状態

細かく噛み砕く

  • タスクを理解し、実行できる粒度まで噛み砕く
  • 1つずつ実行できていたら、小さな成功体験を達成できたとして褒める

感想

教える対象の人が、作業を分割して、行動ベースで何をしたら良いかわからない人向けの本だと感じました。

行おうとしているタスクに対して、分からないことを知るための方法を教える際に、「行動」に焦点を当てることはとても重要だと感じました。

一方で、ある程度タスクを分割して一人で進められる人に関しては、このような手法は煩わしいかもしれません。

教育対象者がどのような人かを見極めて、適切なタイミングでアドバイスができれば良いと感じました。