2019-07-03

obniz ファン meetup vol.2 に登壇しました

勉強会・イベント

obniz-fan.connpass.com

にて、登壇してきました。

経緯

chibi929.hatenablog.com

この記事です。
先日、obniz にプルリクを出したのがキッカケです。

そして T シャツをいただきましたので、これは着て行くしかない。
ただ着て一般参加で座っていても格好悪いだろうと、登壇側で立つことにしました。

登壇を決意するまで

プルリクを出した頃、丁度 obniz ファンというグループを見つけました。そこで、なんと meetup vol.2 が開催されるという情報が、しかもまだ登壇者募集中、あと2名残ってる！！

しかし、私は人前で喋るのが苦手です。足は震えるし声は震えるし、とても怖い。ただ、LT 等に登壇する際には とりあえず手を挙げろ！(参加表明しろ) と良く聞きます。さて、悩む。。。 T シャツを着て立ちたいが、果たして話せるのだろうか？しかもいつもの LT よりも長い 10 分の LT。登壇したいけど怖いどうしよう。。。他の登壇者は戦車作るとか言ってるし怖ぇ。。。そんな感じで登壇が決定してもないのに緊張して寝れない。

とりあえずポチる なんて勇気は出ず、試しにマインドマップを使って、自分の話したいことはなんだろうか？というのを挙げまくってみた。うーーん。内容が薄い。スライド作りも苦手だし、こんなんで10分持つのだろうか？そんなこんなで2〜3日過ぎてしまい「一般枠満員＋登壇枠はまだ1名ある」という情報が流れてくる。

あ、これはやばい、せっかくのチャンスが無くなるかもしれない。グループのコメント欄に登壇表明の文字列を打ち始めた。そして、送信ボタンで再び止まり、1回閉じる。再び とりあえず手を挙げろ という話を思い出し、開く。

そして、もう目を瞑って勢いよくポチる！

そんなこんなで登壇

登壇資料はこちら

speakerdeck.com

動画はこちら

www.youtube.com

登壇した感想

メッチャ楽しい！
言いたいこと言えた！
皆さん優しい！

聞いてくださった優しい皆さまありがとうございました。

準備はとても大変だったけど最初のマインドマップからアウトラインを作って「一番言いたいこと」の為の「前振り」や「流れ」を作ることができました。

まとめ

一番緊張したのはポチる前
- とりあえずポチる の気持ちがわかったかもしれない
リハで時間オーバーして内容削るの大変
- 社内 LT の準備でもそうだったけど黙読だと早口だし。。。
やったらやったで楽しい！とても良い経験になった！

2019-06-06

obniz にプルリクを出した話

f:id:chibi929:20190605182221p:plain

先日、obniz にプルリクを出しました。
https://github.com/obniz/obniz/pull/172

そしてマージされ、リリースされました！
https://github.com/obniz/obniz/releases/tag/v2.1.0

本人のスペック

IoT は全然できません。
obniz だからこそLチカやモーターが動かせているようなものです。。。
アノードやカソードも obniz で初めて知りました。
(正確にいうとデジモンのゲームで単語だけは聞いたことありました。)

ずっと C++ や Java(Android) を触っていて、
ここ最近 Web アプリケーション開発に携わるようになり、
Frontend, Backend 等の知識がなんとなく身について来た感じです。

※ちなみにスマホアプリ開発時代は API や Cloud も全くイメージ沸かなかった。。。

何故、プルリクを出そうと思ったか

簡潔にいうと、今までの経歴が C/C++, Java(Android) と来て、
型の無い JavaScript を気持ち悪いと思いつつ、
Web アプリケーション開発で TypeScript を触って JavaScript と少し仲良しになった。

でも、TypeScript で書いていると any な型がどうしても辛い。
型を作りたくなる病になるわけです。

そんなこんなでやっぱり型が欲しい！

ハンズオンに参加する際は HTML に直接 JS を書くようなコードを書きますが、
自分でコードを整理する際は、やっぱりファイルを分けたりします。
そして TypeScript 化したり Webpack を導入したり・・・。

obniz は、当初 TypeScript を導入しても any 型のまま扱っていました。
ですが、ソースコードを共有したり、時間が経ってから再び触ったりすると型が欲しくなっちゃうんですよね。

どう対応していたかというと、自分のプロジェクト内に interface を作るだとか hoge.d.ts とか作って、必要最低限のみで any 型を無理矢理キャストして使う感じです。

import * as Obniz from 'obniz';

interface Obniz {
  wired(name: string, options: any): any
}

interface LED {
  on(): void;
  off(): void;
}

const obniz: Obniz = new Obniz('1234-5678');
obniz.onconnect = () => {
  const led: LED = obniz.wired('LED', {anode: 0, cathode: 1});
  led.on();
}

必要分定義して、こんな感じだったりです。
時には index.d.ts とか作ってみたり。

徐々に使用するパーツが増えてくる・・・

IoT には疎いので、ハンズオンで学んだことくらいしか出来ませんが、
百均で「電飾」や「ミニプラレール」を買ってきたりして遊んでいます。
でも HTML で操作するにも API 経由で操作するにもやっぱり TypeScript で書きたい！！

キノコなどの仲間内でも obniz を購入する人が増えたり、
TypeScript を使うようになった人が増え、型定義が無いことが辛みになってくる。

じゃあ、途中まで型定義あるから、
少し定義不足があってもみんなが小さいプルリクをたくさん出せるように
土台だけでも作るか！そんなノリで始めた型定義生活。

型定義と過ごした日々...

一つ目の難関 (new)

トランスパイル後の以下のような形になる定義の仕方...

var Obniz = require('obniz');
var obniz = new Obniz('1234-5678');

試行錯誤を繰り返す。。。

定義1 (NG)

export class Obniz {}

定義が、上記の場合

import * as Obniz from ('obniz');
const obniz = new Obniz.Obniz('1234-5678');

----- トランスパイル後 -----

var Obniz = require("obniz");
var obniz = new Obniz.Obniz('1234-5678');

となってしまうので違う。
もしくは、

import { Obniz } from 'obniz';
const obniz = new Obniz('1234-5678');

----- トランスパイル後 -----

var obniz_1 = require("obniz");
var obniz = new obniz_1.Obniz('1234-5678');

となってしまって、違う。。。

定義2 (NG)

export interface ObnizStatic {
  hello(): void;
}

declare const Obniz: ObnizStatic;

export default Obniz;

axios を真似てこんな感じの定義だと、

import Obniz from 'obniz';
const obniz = new Obniz('1234-5678');  // new できないよエラー

定義3 (OK)

そういえば、Node で Error を作る時に、
new Error() するし、変わった型定義だったなーと思い、Error の定義を見てみることに。

interface Error {
    name: string;
    message: string;
    stack?: string;
}

interface ErrorConstructor {
    new(message?: string): Error;
    (message?: string): Error;
    readonly prototype: Error;
}

declare var Error: ErrorConstructor;

declare しているのが var の Error で型は ErrorConstructor という interface
new の戻り値で Error interface を返している。。。

new はこうやって定義するんだな！

そして、Express は以下のように使うなー。。。
と思って定義を見てみることに。

import * as express from 'express';
const app = express();

定義はこんな感じ。
export = e ...! これか...!!

declare function e(): core.Express;
export = e;

そして出来上がったのがこれ。

interface Obniz {}

interface ObnizConstructor {
  new (id: string, options?: ObnizOptions): Obniz;
}
declare const Obniz: ObnizConstructor;

export = Obniz;

二つ目の難関 (wired)

obniz.wired() は、第一引数のパーツ名に合わせて、戻り値の型が変わります。これは document.createElement() を参考にしました。

createElement<K extends keyof HTMLElementTagNameMap>(tagName: K, options?: ElementCreationOptions): HTMLElementTagNameMap[K];

こちらはそれほど迷わずにクリア！

三つ目の難関 (パーツライブラリ)

私は IoT には疎いので、使うパーツは2~3種類です。
Light 系や Motor 系

その辺はまぁ良かったのですが。。。
パーツライブラリの数が多いこと多いこと。
こんなに充実していたとは。。。

公式パーツライブラリには 63 種類のパーツが載っています。
開発中なのかパーツライブラリに載っていないパーツも少なからずありました。
とりあえず、公式パーツライブラリに載ってないので wired 的にはコメントアウトしておきましたが。。。

途中で挫折しそうになりながらもなんとか。。。

テスト

とりあえず初めの段階で、手元でフォークしたリポジトリを npm install して動作確認。
ts ファイルで LED や DC Motor を動かしてみる。
そして、最後にも同じことをやる。

自分の持っているパーツではこの程度しかテストできないので、
この時点でプルリクを出そうとも考えたが、最低限全体的に型エラーにならないことを確認したい。

実コードには手を入れていなく、型定義だけなのでユニットテストは違う。
どうしようか考えた結果、パーツライブラリに載っている全てのサンプルコードを ts ファイルで記述して型エラーにならなければ良いだろう。と考えた。

とりあえず test ディレクトリ以下に ts ファイルを作って、
パーツライブラリに載っているサンプルコード全ての ts ファイルに記述した。型エラーになる項目を検出することをテストとしました。

そして型定義を直す。
ざっと15ファイル程度に定義ミスを発見できました。

そしてプルリクに至る。

最後に

思った以上のパーツが対応していて、そして全てサンプルコードがある。
そして、ほぼ全ての I/F を知った。
IoT が疎い私でもパーツライブラリに載っている配線を真似すればなんでもできそうな気がする！
そんな気持ちになりました。

2019-06-03

Unity - ブロック崩しチュートリアルで学んだこと

Unity

はじめに

本記事は自分の理解のために雑にまとめたもの。

参考 URL

http://tutorial.unity3d.jp/archive/my-first-unity/
http://baba-s.hatenablog.com/entry/2018/01/16/212800
http://baba-s.hatenablog.com/entry/2018/01/16/212900
http://baba-s.hatenablog.com/entry/2018/01/16/213000

第一回

まずは、各オブジェクトの大きさや配置などの設定。
パドルの操作とボールの制御を行う。

壁

Cube を使って豆腐を「直方体」にして壁を作る
- GameObject > 3D Object > Cube
インスペクタビューの Transform を使って位置や大きさの調整
- Position, Rotation, Scales

カメラ

シーンビューのカメラの向きを変更する
- シーンビューのカメラだけだとゲームビューは変わらない
- Cube と同じように Transform する

自機

壁と同じく Cube を使って自機となる「直方体」を作成＆配置

パドルを操作できるようにする

C# Script を追加する
- Assets > Create > C# Script

public class PaddleController : MonoBehaviour
{
    public float accel = 1000;

    private void Update()
    {
        var force = transform.right * Input.GetAxisRaw("Horizontal") * accel;
        GetComponent<Rigidbody>().AddForce(force, ForceMode.Impulse);
    }
}

// Input.GetAxisRaw("Horizontal") により、
// 水平方向 (Horizontal) のユーザー入力を -1 ~ 1 の正規化された範囲で取得している
// ユーザー入力はキーボードでもジョイスティックでも OK

// ForceMode.Impulse は質量を考慮して動作に反映される

C# Script をドラッグ＆ドロップで Paddle に設定する
- Add Component した状態と同じになる。

パドルに物理特性を追加する

インスペクタビューから Add Component を押下して Rigidbody を追加する
- ボール(Sphere) に Regidbody という機能を追加した感じ
Regidbody のパラメータを設定する

ボール

ボールも同じノリで Sphere を選択して作成＆配置
- GameObject > 3D Object > Sphere

ボールに物理特性を追加する

インスペクタビューから Add Component を押下して Rigidbody を追加する
- ボール(Sphere) に Regidbody という機能を追加した感じ
Regidbody のパラメータを設定する

ボールに初速度を与える

C# Script を追加する
- Assets > Create > C# Script
GameObject 起動時に速度を与える

public class BallController : MonoBehaviour
{
    public float speed = 10;
    
    private void Start()
    {
        var force = (transform.forward + transform.right) * speed;
        GetComponent<Rigidbody>().AddForce(force, ForceMode.VelocityChange);
    }
}

// transform.forward はボールの正面 (Z方向) を示す単位ベクトル
// transform.right はボールの右方向 (X方向) を示す単位ベクトル
// これらを足して Speed を掛け合わせることで右斜めのベクトルを得ている

C# Script をドラッグ＆ドロップで Sphere に設定する
- Add Component した状態と同じになる

ボールをバウンドさせる

今のままだとボールが跳ね返らない

Physic Material をボールに設定する
- Assets > Create > Physic Material
- Physic Material は物理パラメータを管理するもの

第二回

ターゲットとなるブロックを作成する

ブロックの作成と配置

壁と同じノリで Cube を追加して Block という名前にする
C# Script を Block に追加する

public class BlockController : MonoBehaviour
{
    private void OnCollisionEnter(Collision collision)
    {
        Destroy(gameObject);
    }
}

// OnCollisionEnter は、Rigidbody で動作しているオブジェクトが接触したときに呼ばれる処理
// 引数の collision には接触対象オブジェクトが入っている

// Destroy メソッドで gameObject、
// つまりコンポーネントを実行したオブジェクトつまり接触したブロックを削除している

Block を複製する

Empty なゲームオブジェクトを作成して Blocks という名前にする
- GameObject > Create Empty
- 今回は、ディレクトリ的(グループ化)な扱いに利用する
Blocks に Block をドラッグ＆ドロップする
Block を選択して Ctrl + D で複製
複製した Block それぞれにX座標を設定する
Blocks には Z座標を設定して全ての Block を制御する

Blocks を複製する

更に Blocks を複製して5行6列なブロック群を作る
- 複製した Blocks にはそれぞれZ座標を設定する

ゲームオーバーの実装

下側の壁に C# Script を追加する

public class BottomWallController : MonoBehaviour
{
    private void OnCollisionEnter(Collision collision)
    {
        Destroy(collision.gameObject);
    }
}

// ブロックの時とは異なり、接触対象の gameObject をデストロイしている
// つまり、ボールをデストロイしている

第三回

サウンドを付ける

チュートリアル用の *.unitypackage をインポートする

ダウンロードした sound.unitypackage には、BGM や SE が格納されているので、 Custom Package としてインポートする。

SE の実装

C# Script を追加する

public class HitPlaySound : MonoBehaviour
{
    public AudioClip sound;

    private void OnCollisionEnter( Collision collision )
    {
        AudioSource.PlayClipAtPoint( sound, transform.position );
    }
}

// AudioClip は音を登録する変数
// AudioSource.PlayClipAtPoint にて音を再生
// 音の発生源は第二引数で指定

SE を設定する

壁

壁の GameObject を選択して、上記で追加したスクリプトをインスペクタビューの Add Component へドラッグ＆ドロップ
先ほどインポートした壁の音となる SE ファイルを C# Script の Audio Clip へドラッグ＆ドロップ

ブロック

ブロック全ての GameObject を選択して、同様にスクリプトをインスペクタビューの Add Component へドラッグ＆ドロップ
先ほどインポートした壁の音となる SE ファイルを C# Script の Audio Clip へドラッグ＆ドロップ

パドル

上記に同じ

下側の壁

4つの壁のうち下側の壁にはゲームオーバー用の SE を設定する

BGM の設定

Main Camera に BGM を設定する
- 選択状態にして Add Component で Audio Source を追加する
- Audio Clip に BGM もドラッグ＆ドロップ
- 音がデカイ場合は Volume で調整

ブロックの色を変更

Material を作成する
- Assets > Create > Material
Mterial のカラーを設定する
全てのブロックを選択して上記で作成した Material をインスペクタビューへドラッグ＆ドロップ

完

2019-05-12

「キッズコーチ検定3級」を受けてきた

ティーチング と コーチング は違うよ
傾聴 , 承認 , 質問 を心掛けましょう
子どもとのコミュニケーションについて
- 姿勢
- 表情
- リアクション
- 話し方
- 言葉遣い
- 自己紹介(初対面のとき)
- 話題
- 聞く姿勢
コミュニケーションツール
- クイズ、ゲーム
- 興味の対象になる
- 好きなものを探る

2019-05-08

「PlayCanvas 3D チュートリアル」で学んだこと

勉強会・イベント Unity

はじめに

playcanvasjp.connpass.com

これに参加して、Unity 同様メモしたやつ。
Unity も全然使えないからむずかしい。。。

参考サイト

https://support.playcanvas.jp/hc/ja/articles/224172247

PlayCanvas のビューについて

Unity と一緒。すんなりイメージできた。

シーンビュー

カメラやスプライトを配置する画面

ヒエラルキービュー

カメラやスプライトの階層画面

プロジェクトビュー

プロジェクト画面各種 IDE でもよく見るやつ

インスペクタービュー

カメラやスプライトの属性を設定する画面 Xcode でよく使うやつ

スクリプトについて

initialize , update , swap というライフサイクル関数重要

initialize: 初回に呼ばれるやつ
update: 毎フレーム呼ばれるやつ
swap: ホッとリローディング時に呼ばれるやつ

モデルについて

オブジェクトと同義なのかな？物体のこと？エンティティとも言えるのかな？（エンティティはモデルの属性かな？）モデルを作成してマテリアルで色を付ける。

Attribute について

スクリプトに属性を付与することができる

var Shot = pc.createScript('shot');
Shot.attributes.add("bulletTemplate",{type:"entity"});

こんな感じ

テンプレートについて

Unity でいうところのプレハブ Template として定義しておくことでクローンを作成できる。

上記のように Entity タイプの Attribute を宣言したら、該当ソースコードをアタッチしている物体を選択して Entity にモデルを設定する。これで、モデルをたくさんクローンすることができる。

Number タイプの Attribute を宣言した場合は、大きさ等のデータを入れられるようになるということ。

Collision

当たり判定のこと。タイプによって当たり判定枠が変わる。

this.entity.collision.on("collisionstart", this.death, this);

で当たり判定定義をスタートする。 this.death はコールバック関数。

Rigid Body

物体に対して物理演算を付けることができる。 https://developer.playcanvas.com/ja/tutorials/collision-and-triggers/

Static: エンティティを固定し、動かなくします。
Dynamic: エンティティは重力と外部から与えられた力に影響されて動くようになります。
Kinematic: エンティティは力に反応しなくなりますが、位置と速度を直接指定して動かすことができるようになります。

ということらしい。

Enemy.prototype.death = function(result) {
  if(result && result.other.rigidbody && result.other.name === "clone") {
    //衝突したコリジョンを持った相手の名前が"clone"だったら
    this.entity.destroy();//自分自身をdestroy
    result.other.destroy();//衝突した相手をdestroy
  }
};

衝突したときに、衝突対象の名前を見て破壊する。 clone は、Template のクローンに付けた名前である。

マテリアルについて

モデルに対する素材になるものである。

テクスチャを貼ることができる
色を設定することができる
マテリアルはモデルにアタッチすることで反映する

2019-05-01

「Unityで2Dミニゲームを作るチュートリアル」で学んだこと

Unity

はじめに

Unity を今更使う初心者が、とりあえず Qiita の記事通りにゲームを作った際のメモ。
Unity 用語が全然わからないので、その辺もメモしている。

参考URL

Unity のビューについて

主に5つのビューから成り立っている

シーンビュー

カメラやスプライトを配置する画面

ゲームビュー

プレビュー画面

ヒエラルキービュー

カメラやスプライトの階層画面

プロジェクトビュー

プロジェクト画面各種 IDE でもよく見るやつ

インスペクタービュー

カメラやスプライトの属性を設定する画面 Xcode でよく使うやつ

用語

スプライト

2D では、画像をスプライトと呼ぶ

コンポーネント

スプライトにアタッチするもの

Physics 2D/Rigidbody 2D

スプライトを物理エンジンで制御できるようにするコンポーネント

Physics 2D/Circle Collider 2D

円形コリジョンコリジョンを設定するとクリック判定が可能になるコリジョンを設定しない場合は衝突しないたこ焼きになるのかな？

スクリプト

スプライトの制御ロジックドラッグ＆ドロップでもアタッチできる

プレハブ

同じ性質を持つスプライトを複製する仕組みスプライトをプロジェクトビューに置けばプレハブ化できるプレハブ元は削除してヒエラルキービューから良いらしい

マテリアル

スプライトにはマテリアルを適用できる

Shader を Particles/Additive
- 加算合成

空のゲームオブジェクト

メニュー -> GameObject -> Create Empty で作成が可能スプライトではないただのオブジェクト(見えないスプライトみたいなもの)

Assets ディレクトリ

ソースコードを含めた利用するファイルを入れておく場所

Assets
├── Materials: マテリアルを入れておく場所
├── Resources: 今回はプレハブを入れておく場所として利用
├── Scenes: シーンを入れておく場所
├── Scripts: スクリプトを入れておく場所
└── Sprites: 2D関連のスプライトを入れておく場所

スクリプト

Start と Update というライフサイクル関数重要

Start: 初回に呼ばれるやつ？
Update: 毎フレーム呼ばれるやつ？

UnityEngine.SceneManagement

SceneManager.LoadScene("シーン名")
- 他のシーンを起動することができる

2018-10-31

「エンジニアとして食っていく方法」に参加しました

勉強会・イベント

techplay.jp

本日はこちらに参加しました。
「エンジニアとして食っていく方法」！！
とても刺激になるイベントでした

内容はこんな感じです。

活躍するエンジニアの条件 (及川卓也さん)
美容師からエンジニアへの転身 (許直人さん)
TECH PLAY Academyのご紹介 (片岡秀夫さん)
パネルディスカッション
- パネリスト；及川卓也さん
- パネリスト：許直人さん
- モデレーター：片岡秀夫さん

f:id:chibi929:20181101004922j:plain

活躍するエンジニアの条件 (及川卓也さん)

【小学校プログラミング教育必修化に向けて】

プログラミングの授業があるわけではないらしい。
scratch とか普通にやるんだと思ってたー。

各授業の中でプログラミング的思考を学ぶとのこと。

【code.org】　　

米国ではこんなことをやっている組織がある。
code.org は小中学生向けプログラミングを支援している。

プログラミングを学ぶことにより格差社会に負けなくなる。
貧困の連鎖を止めることができる。
それは、明らかにリターンがあり収入があるためである。

米国だとソフトウェアエンジニアが各種業種の中でトップクラス。
バリューを生み出すことができ、価値のある仕事をしているため。

【事業について】

人間がやっていたことをコンピューターにやらせることで「省力化・コスト削減・効率化を行なっていた事業」から、「技術がないと生み出せない事業」へ。

Amazon も技術を駆使して強くなった。

【DevOps】

これは、もう結構前からだが、
開発と運用を別々にやるのは効率が悪い。
だから DevOps

開発者は運用も行うことでユーザーから直接フィードバックを得て開発に生かすことができる。
作り上げたら終わりではない。リリースしてからが本番だ。

【エンジニアとしての成長】

知識を身に付け、技能に発展させる。
「知っている」から「使える」へ。
「使える」から「使いこなせる」へ。

学習→知識→経験　のループを行う。
経験して、より深く学習し、より深い知識を身に付ける。
それをまた経験として活かす。

大事なのは、経験そのものではなく知識とそこから昇華された技能！

美容師からエンジニアへの転身 (許直人さん)

プログラミングで貧困を脱出したトップスタイリストの方。稼ぐためにプログラマに転身。

1社目
- 独学で色々出来たけど、美容師という肩書きで落とされる
- 実際に動くものを見せ、コードを見せるようになった
2社目
- 1社目での実績があるので転職しやすくなったとのこと
- 先輩プログラマから学ぶ
- オープンソースを読みまくった
  - 人のコードを読むのが好きになった
3社目
- 1人ではプロダクトとして成立しないことがわかった
- 空いてる時間はとにかく勉強しまくった
その他多々
- 上流工程への興味
- とにかく勉強
- エンジニアを土台としてビジネスを
ポイント
- スキルと収入は相関する
  - 稼ぐ仕事: 70%
  - 学ぶ仕事: 20%
- 仕事の一部を技術への投資にする -自分の市場価値を定期的にチェック
  - エージェントに話を聞く
  - 自らを競争に晒す
    - 勉強会に出るなどでも外部の人たちと比べることができる
- 自分の置かれた環境を憂うよりも自分が変わった方が早い
  - 環境が良くないなら行動を起こせ
    - 提案、転職など
  - 学びたい技術、欲しい技術は取りに行く
- 好きこそものの上手なれ
  - 目先の年収はわからないけどスキルと一緒についてくる

TECH PLAY Academyのご紹介 (片岡秀夫さん)

エンジニアは圧倒的人材不足
2030年にはもっと人材不足
TECH PLAY Academy
- プログラミングブートキャンプを提供
- 完全オンラインでリモートで参加
- 仕事をしながら学ぶ
- 毎週20時間×16週
- シニアエンジニアメンターがサポート
- エンジニア転職支援の豊富な実績から年収100万アップを目指す
- コミュニティ・仲間づくりとして活用可能
  - あの人は頑張っているという刺激が大事
- アウトプットを出していく
学習スケジュール
- 1ヶ月目：基礎学習・課題挑戦
- 2ヶ月目：1週間に1本ずつミニアプリ作成
- 3,4ヶ月目：アプリ作成

パネルディスカッション

ウェブエンジニアの魅力について

知らないといけない分野がたくさん散らばっているのが良い
- ドメイン、サーバー、クラウド、セキュリティ・・・
  - 知識の幅が広がる
  - イヤでも幅が広くなる
導入コストがかからない
- レンタルサーバー安い！
- クラウドで簡単
- 意欲と技術があればお金がなくてもできる
スマホアプリ
- スマホだけで完結しちゃうので世界が閉じてしまう可能性がある
- 個人的にもスマホアプリからウェブアプリの世界を経験したのは大きいと思っている
  - 何より Front・Back・Cloud・API 色々触ることができた
IoT はハードルが高い
- ハードウェアも用意しないといけないし。。。
- それに比べてウェブアプリはハードルが低いのにビジネスにもなる
ウェブの技術がスマホに展開できる
JavaScript の進化がヤバイ
世界的に新しいものを作るときは Go か JavaScript

学習の動機付け

内的要因
- 自ら進んでやること
外的要因
- 収入を得るため
- 自ら宣言して外的要因を作る
成長を止めたら死ぬ
- 暇な環境が続いたら死ぬ
- 無駄な時間をなくす
- 危機感を感じろ
- とにかくやらなきゃっていう気持ち
- 行動を起こせ
自分を追い込む
- 苦労する状況じゃないと勉強しないから飛び込んだ
- やらざるおえない状況を作る
- 常に課題だと思っているところをやる
  - 課題なら解決すればストレスもなくなる
- わからないことをやるから成長する
コミットメントをする (宣言することで追い込む)
- これやります
- 勉強会にいきます
- LT やります
- とにかく先に宣言する
- 受け身になって聞いているのはダメ
  - 質問をする気になって聞け

三日坊主にならないために

やるぞ！と思ったときがピーク
とにかく決意したらすぐに行動を起こす・すぐに自分の環境を変える
周りの状況によって諦めない
- 「○○だから出来ない」とかは甘え
  - 個人的にも「時間がないから出来ない」とかは甘えだと思っている

まとめ

とにかくすぐに行動を起こして書けたかな・・・。
もっと楽しくやるぞー。