DEV Community: Seattle Consulting, Inc.

Alexa Skill Blueprintsを使った簡単スキル作成

KoichiMachida — Mon, 23 Sep 2019 14:10:46 +0000

Alexaを買ってみたけれど

ITの業界に来て少しした頃、業界的な影響を受けてか知らずか、
「我が家を便利にしてみたい！」という思いでAlexaを買ってみました。

ところがどっこい！

いざ導入してみても、毎日の天気予報と時々のタイマーぐらいにしか使っておらず……
せっかく買ってみたのだから、いっそスキルを自作してみて試せないかと思ったりしてもどんな感じに出来上がるのかもイマイチイメージ出来ない。

そんな「Alexaガチ初心者」の人間でもスキルを作成する【Alexa Skill Blueprints】といったものがあったのでご紹介。
「スキルを作成してみたい方」のイメージ掴みとか、「ちょっとしたスキルだけ作りたい」といった方向け。

Alexa Skill Blueprintsでできること

一言で説明すると「Web上のテンプレートを埋めていってスキルを作成」するもの。
記事作成時点で、グリーティングが4種類、試してみようが7種類。

例えば【カスタムQ&A】を使ってスキルを作成すると、質問文を追加してそれに対する回答を追加していって…といった手順になります。
ながら作業時用の自分用辞典みたいな使い方とかも出来そう。ゲームを遊んでいる時に「このブキについて教えて！」みたいな。

今回はサボりがちな自宅筋トレをすべく、【パーソナルトレーナー】のスキルを作成していきます。

スキル作成までの手順

【Alexa Skill Blueprints】の公式サイトに行くと、まずは右上に【Sign in】があるのでAlexaで使っているアカウントでログイン。

【パーソナルトレーナー】のテンプレートを開くと、サンプルや作成手順が出てくるので、そのまま【作成する】を押してみます。

すると出るわ出るわのトレーニング項目！
「腕立て伏せ」「腹筋」「サイドプランク」「ツイスト」「左右立ち」etc…

とりあえずいくつかの項目をセットして次へ行くと、さきほどセットしたトレーニングの秒数やスキルを起動する時間を聞かれるので、筋トレしたい秒数やセット数を記入していきます。

その次は【Alexaのメッセージ】記入。
始まりの挨拶や筋トレ実行中の応援メッセージを入力します。
自分が応援してもらう内容を自分で記入していく様は中々シュール。

最後にスキル名を記入して【スキルを作成】
数分待てば自分で作成したスキルで筋トレが出来るようになります！！

…いつの間にか筋トレの話になってしまいました。

意識したい点は、「発言させる内容はシンプルにする」ということ。
あまり難しい文面や、長文は発言出来なかったり聞きづらかったりするので、分かりやすい内容を心がけると良いと思います。
これはBlueprintsでの作成に限らず、コードを用いてのスキル作成等でも言えるので、常に意識しておきたいところ。

スキルが不要になった場合は、【作成したスキル】から削除出来ます。

以上、すごいお手頃にAlexaスキルは作成出来るので、「Alexaいじり」を考えている人は是非試してみてください。

GCE + VSCode + docker-composeでリモート開発環境を構築する

Kazuhiro Miyajima — Mon, 09 Sep 2019 09:24:29 +0000

これを書いているのは2019年の9月ですが、今年はあまり暑くなくて過ごしやすい夏でしたね。
とはいえ残暑の方が厳しい可能性もあるので、できればローカルのMacでDockerを立ち上げることで余計な熱源は減らしたいですよね。
そこでGCE(Goodle Compute Engine)にインスタンスを立てて、VSCodeで繋いで、ローカルMacでの開発と遜色ない環境を構築する方法を紹介します。
（Windowsも基本は同じ手順でイケると思いますが、手元にないので）

Macが熱くならない以外にも、以下のメリットがあります。

ブラウザとターミナルとエディタ、ネットワークさえあれば開発できる
強いマシンを買う必要がない=エコ
ネットワークが速い（dockerイメージのpullやnode modulesのインストールなどで体感できる）

事前準備

GCPアカウントの作成・設定は、この辺りを参考に適宜お願いします。
https://cloud.google.com/iam/docs/creating-managing-service-accounts?hl=ja

アカウント作成後、適当なGCPプロジェクトを作成または選択してください。

GCEでインスタンス作成＆起動

この後の手順は、基本的にはこのチュートリアルの通り。
https://cloud.google.com/community/tutorials/docker-compose-on-container-optimized-os

作成したプロジェクトでVMインスタンスを作成します。
ブートディスクはDebian9のまま、
リージョン、インスタンスサイズはお好みで。最初のビルド時はn1-standardくらいが良いと思います。
あと、複数プロジェクトを同インスタンス内で使いたい場合は、storageが10GBだと足りなくなる可能性が高いので増やした方がよいやも。

GCEインスタンス上で、個別プロジェクトのdocker-compose実行

git, docker. docker-composeインストール

VMインスタンス一覧でSSHボタンクリックでブラウザターミナル起動 git
sudo apt install git

docker, docker-composeのインストールはこの辺を参考に。
https://www.digitalocean.com/community/tutorials/how-to-install-docker-compose-on-debian-9

docker

sudo apt update
sudo apt install apt-transport-https ca-certificates curl gnupg2 software-properties-common
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
sudo apt update
apt-cache policy docker-ce
sudo apt install docker-ce
sudo systemctl status docker
docker --version
sudo usermod -aG docker ${USER} # sudo なしでdockerコマンド実行できるようにgroupに追加
SSHログインし直す

docker-compose

sudo curl -L https://github.com/docker/compose/releases/download/1.22.0/docker-compose-uname -s-uname -m-o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
docker-compose --version

個別プロジェクトのソースコードをGitHubからcloneした後、docker-compose upを実行

前準備として、このVMインスタンスからGitHubに接続できるように設定します。

ブラウザターミナルで ssh-keygen 実行。ファイル名はデフォルトのid_rsaでOK。パスフレーズを入れて忘れないようにする
GitHubのSettings > SSH and PGP Keysページに上記で作った公開鍵（~/.ssh/id_rsa.pubの中身）を登録

これでVMインスタンス上でcloneできるはずです。

mkdir /home/<username>/projects （ディレクトリ名は何でも良いです）
cd projects
git clone <githubなどのclone先URL>
cd <cloneしたプロジェクト>
docker-compose up -d

ポートを開ける（Optional）

ここまでで、ポート80でリクエストを受けられるようなdocker-compose環境であれば、
VMインスタンス一覧画面の外部IPリンクをクリックすればブラウザで実行結果を確認できます。
80以外のポートを開けたい場合は、以下を追加で実施してください。
SPAの開発環境であれば、2つくらいは開けたくなると思います。

GCPのVPCネットワーク > ファイヤーウォールルールをクリック
ファイヤーウォールを作成をクリック
名前とターゲットタグに http-8080 、プロトコルとポートに許可したいポートを指定（例：tcp:8080,3000,3100）
VMインスタンスの編集画面で、ネットワークタグに http-8080 を追加

これで http://<外部IP>:<ポート>/ にブラウザで接続できると思います。
SPAなどの場合、通信先IPの指定も忘れずに。

Visual Studio Code Insiders & Extensionsで開発

Visual Studio Code Insidersをインストールします。
2019年8月現在、Visual Studio Code（以下VSCode）正式版ではRemote SSHなどが動作しないのでInsiders版をローカルPCにインストールします。
https://code.visualstudio.com/docs/?dv=osx&build=insiders

Remote Developmentをインストール

以下のExtension全部入りのExtensionであるRemote Developmentをインストールします。
VSCode Insiders版のExtensionタブで「Remote Development」で検索してください。

Remote Containers
Remote SSH
Remote WSL

VMインスタンス側の接続設定

VMインスタンス編集画面で、SSH認証鍵欄にローカルMacの公開鍵を追加して保存（またはVMインスタンス内のauthorized_keys に公開鍵を追加）

ローカル側の接続設定

ローカルMacの~/.ssh/config を編集

Host <ホスト名>
  Hostname <立ち上げたVMインスタンスの外部IP>
  User <GCPユーザー名>

VSCode のRemote SSHタブ上に、上記で追加した<ホスト名>が出てくるのでダブルクリック
接続完了

接続できない場合は、以下を疑ってみてください。

~/.ssh/config のユーザー名がGCPユーザー名ではない、または外部IPが違う
ssh初回接続をVSCodeで実施してしまうと、ローカルMacのknown_hostsに追加するところで止まってしまうので、ターミナルなどで一度ssh接続してみる

余談

本当は、GCEのContainer-Optimized OS(COS)を使ってリモート環境を構築し始めたんですが、VSCodeのRemote Serverインストールでコケたのでやめました。
Container-Optimized OS の機能と利点はこちら。
https://cloud.google.com/container-optimized-os/docs/concepts/features-and-benefits?hl=ja

また、Cloud Shellのコードエディタで開発できるようにしようかと思いましたが、VMインスタンスからCloud Shell上にソースコードを同期する必要があるため、面倒なのでやめました。
素直にVSCodeでソースを書きましょう。

では、良いリモート開発ライフを。

もっと早く出会いたかった git command 達

yanskun — Thu, 05 Sep 2019 15:29:13 +0000

はじめに

いわゆるｎ番煎じ
業務で使うコマンドの中でも特に気に入ってるものを並べました。

初心者から、中級者向け？だと思います。

コマンドを覚えると開発がより楽しくなると思います。
あんなこともできるこんなこともできる、できるが増えるって素晴らしいですね。

便利コマンド

差分をステージングエリアに追加する

git add -p

役立ち度：★★★★★
基本的に、このオプションでしか add はしない。

差分を取り消す

git checkout {FILE_NAME}
git checkout # 全部なかったことに。
git checkout -p # もある

役立ち度：★☆☆☆☆
時々使うけど、結構危険だと思う。

ステージングエリアから戻す(add する前に戻す)

git reset {FILE_NAME}
git reset # 全部戻す
git reset -p # もある

役立ち度:★★★☆☆
コミットしようとした時に、「あれなんでこいついるの？」ってなった時に使う
コミット前には必ず git status しましょう。

指定したユーザーのコミットログを見る

git log --committer={USER_NAME}

重要度:★★☆☆☆
怪しい人を見つけた時に。

コミットIDを指定して、中身を確認する

git show {COMMIT_ID}

重要度：★★★★☆
怪しいコミットがあった時に。
pull したらコミットをたくさん取り込んだ時によく使う。

別のブランチからファイル/コミットを持ってくる

git checkout {BRANCH_NAME} {FILE_NAME}

git cherry-pick {COMMIT_ID}

役立ち度：★★★☆☆
別のブランチの作業者が作った共通部品を盗みたい時に。

直前のコミットを修正する

git commit --amend # コミットメッセージも変えられる
git commit --amend --no-edit # vim をスキップ

役立ち度:★★★★☆
「この差分もこのコミットに乗せたい」という時に。

ファイル名の変更

git mv {OLD_NAME} {NEW_NNAME}

役立ち度：★★★★★
普通にエクスプローラーから名前をすると delete と create になってしまう。
これでファイル名を変更するとログに変更が残るから嬉しい。
（これもオプションがあるわけじゃないけど、意外と使ってる人が少ない...。のでランクイン)

特定のファイルの歴史を確認

git log -- {FILE_NAME}
git blame {FILE_NAME}

役立ち度:★★★☆☆

blame の方が有名だけど、 log で見るのも便利な時がある。

マージ済みのブランチの確認

git branch --merged
git branch --no-merged # その逆

役立ち度：★★★★☆
削除して良いローカルブランチを見つける。

直前のブランチを指定して〇〇

git checkout - # ブランチ切り替え
git merge - #  マージ

役立ち度：★★★★★
ひょっとしたら一番便利かもしれない。
ブランチ名が長くて打ってらんない時に。
ブランチ名を忘れちゃった時に。

マージしたらコンフリクトしたのでなかったことに

git merge --abort

役立ち度：★★★☆☆
他の人に聞かないと解消できない時に。

ざっくりした差分をみる

git diff --stat

役立ち度：★★★☆☆
ファイル名と、そのファイルが何行変わったかだけを表示

ステージングエリアの差分を見る

git diff --cached

立ち度：★★★★☆
直前のコミットと、ステージングエリアとの差分を見る。
add + commit を連結して考えてると不要。（結構危険な考えです、やめましょう）
あれ？これコミットしたら何がリモートに上がっちゃうんだろう、と気になって見てください。

リモート削除されたローカルブランチを削除する

git remote prune origin

立ち度：★★★☆☆
branch 名の予測変換が有効になっている場合、
削除されたブランチ名に勝手に変換されてしまって
嫌な気持ちになったことないでしょうか？僕はあります、たくさん
時々綺麗にすると家と同じで気持ちがいいです。

ネタ系

コミット数のランキング

git shortlog --summary -n

楽しさ:★★★★☆
努力を誰となく認められたい時に。
Git はあなたのコミット数を見てくれてます。

最後に

どうでしょうか。
git command でもっと楽しもうって気になれましたでしょうか。
CLI での git 操作ができるようになるともっと楽しく開発ができるかもしれません。
僕は楽しいです。

結構便利コマンド多いなって思います。
shell環境整えたら git command を愛する人になったので、たくさん知りたいです。
「これも使いなよ」っていう、とっておきのコマンドがあったら教えてください。

おまけ

僕の git の alias を晒します

＄ git config --list | grep alias
alias.b=branch
alias.s=status
alias.co=checkout

あんまりたくさん作ってもしょうがないかな派です。

ありがとうございました。

未経験中途入社エンジニアが初現場で学んだこと

ryohei.nagaoka — Tue, 03 Sep 2019 02:26:47 +0000

はじめに

不動産賃貸管理会社の営業という割とローカルな仕事に３年間務めた後、IT業界へ飛び込みました。入社後３か月の研修を経て、初の現場に参画することになりましたが、参画初日の正直な感想は本当にこのプロジェクトやっていけるのか・・・というとても大きな不安でした。

そんな不安からスタートした初現場でしたが、なんとか走りきることができたので、そこで学んだことをこちらに残していこうと思います。

私のように、研修や自己学習と実際のプロジェクトの"規模"の違いから大きな不安に駆られる人は少なくないと思います。そんな人達の助けになれば嬉しいです！！

"分からない"を知ってもらう

私がプロジェクトに参画して最初の業務は要件定義書を読み、既存の設計書を元に今回のプロジェクト用の設計書を書き起こすというものでした。

しかし、既存の設計書があるにしろ、設計書を書いたことも無ければ、何が書いてあるのかも良く分からない。"分からない"が多すぎて本当に困った。というのがその時の感想です。

こんな時に重要なのが、"分からない"ということをメンバーや先輩に知ってもらうことです。

基本的に先輩方は、新人エンジニアに対して"仕事ができる"とは思っていません。
"分からないこと"をキャッチアップして成長することを期待しています。

逆に一番やってはいけないのが、分かっているかのように振舞うことです。

私は前職でお客様との話の中で分からないことが出てきた際に、正直に分からないと伝えてしまうと「そんなことも分からないのか！！無能め！！お前の会社とは契約しない！！」なんてことになりかねないので、虚勢を張ってその場を凌げと先輩に教えられて来ました。
その為、そんな窮地に立たされた際に虚勢を張って上手いこと窮地を回避する悪い癖がついていてしまっており、本当に苦労した点です。
未だに癖が出てきてしまうことがあるので、常に意識して業務にあたっています。

"分からない"に直面した時は

"分からない"を知ってもらうことはできましたが、それで解決ではありません。
"分からない"を"分かる"状態にして初めて解決です。
その方法ですが、即上司やメンバーに聞くのはNGです。
自分で解決する気は無いのか？？と疑念や不安を与えてしまいます。
それに、自分で解決する能力も成長しません。
なのでこんな時は、
「自分で調べる→解決できなければ上司やメンバーに聞く」このステップでやってみましょう。
自分で調べることによって、自己解決力が上がります。
そして、そこで解決できれば上司やメンバーに聞く時間も取ることはありません。
しかし、"調べすぎる"のは良くありません。
1時間調べて分からないこともあります。というより、15分調べて分からないことは大体1時間調べても分かりません(※個人差があります)
なので私は、15分調べて分からなければ聞くという風に実行しています。
調べることに熱中しすぎて15分過ぎていることもあるので、タイマーを設定しておくのも良さそうです。
そうして分かった事、解決したことはメンバーに展開したり、コミュニケーションツール等でアウトプットすると、ほかの社員の知識にもなりますし、自分の知識の定着にも繋がります。
ここまでできれば120点ですね！！

質問の仕方を考える

15分調べて、分からない。
次のステップは質問をすることだと思いますが、ここも注意が必要です。
私が質問をするとよく言われた言葉があります。
「何を聞きたいのかわからない」
なぜこのやり取りが発生してしまうのか。
それは質問の仕方に原因がありました。
私の場合、何をやったのか1~10まで全て話した後、聞きたいことを話すという順序で質問をしていました。
質問の仕方としては0点です。
いくら仕事のできるスーパーエンジニアといえど、1~10まで話を聞いてられません。
では、どう聞くのが正解か。
仕事のできるスーパーエンジニアな上司に聞いてみました。
上司曰く、

①やりたいことを伝える
②起きている事象を伝える
③事象を引き起こした行動となぜその行動を行ったのか伝える

この順序で質問をしてもらうのが聞きやすいようです。

質問を受ける側としては、どこまで自分で考えて何を行ったのかを知りたい。
考え方が合っていて行動が間違っているなら行動のヒントを与えるし、
考え方がそもそも間違っているのであれば、考え方から教える。

とのことです。
ここに関しては、正解は色々あると思うのですが、
"やりたいことを伝える"の手順を一番最初に持ってくるのは、変わらないと思います。
その後の説明の部分が明後日の方向に向かってしまっていても、やりたいことは分かっているからアドバイスしやすいはずです。

"分からないこと"が"分からない"

初めて設計書やソースコードを見たときに起こった現象ですが、新人エンジニアにはよく起こります。実際、新人エンジニア間では、
A「何が分からないのか分からん！！」
B「出た出たいつもの笑」
なんて会話がよく発生してました。
この現象が起きるときは大体、ドキュメントの中に"分からない"が混在しています。
"分からない"と"分からない"が手を繋いでできているドキュメントです。
そりゃ分かるはずがないのです。
なので落ち着いて一つ一つ解決していきましょう。
具体的には、ドキュメントの単語やトピック一つ一つに対して、これが何か説明できるか？という疑問を自分にぶつけてみましょう。
ここで説明できないものは全て"分からない"ものです。
この"分からない"を全て解消したころには、ドキュメントが読めるようになっています。
ただこの過程は時間がかかるので、一度上司に相談をしましょう。
先程も言った通りここで"分からない"を隠蔽してはいけません。
"分からない"ことは悪ではありませんが"分からない"を隠蔽することは確実に悪なので、意識しましょう。

認識合わせをする

新人エンジニアのタスクといえば、基本的に上司から「こういうものを作って」と任されるのがほとんどだと思います。
そんな時、自分の成果物のイメージと上司の成果物のイメージに違いがあることは本当によくあるパターンです。下手をすると、意気揚々と成果物完成しました！！なんて上司に持っていっても、「全然違うじゃねえか！！！全部やり直せ！！！」なんていう大事故に繋がりかねません。
作業していた時間が全て無駄になってしまうので、なんとしても避けなければなりません。

こんな大事故を避けるには、認識合わせが重要になってきます。

上司からこういうものを作ってと説明があった場合は、その説明を復唱するのも一つの認識合わせですし、簡単に成果物を絵に書いてみて、こんな感じのものを作ろうとしていますと一度見せてみるのも良いと思います。
お互いに認識を合わせて、無駄な時間の使い方をしないようにしましょう。

定点報告をする

「定点報告」非常に重要です。
定点報告をすることによって、認識合わせのステップでは拾いきれなかったイメージのズレを修正することができます。1時間間隔の報告であれば、1時間の間の進捗に対してイメージのズレや修正点のアドバイスを頂けるので成果物がよりクオリティの高いものとなります。
また、1時間の間に"なにをやったのか"を報告しなければならないので、無駄な時間の使い方をしなくなり、作業効率アップにも繋がります。

図を描く

画面からサーバー側へどのように情報が渡って、どのような処理が行われてデータベースから欲しい情報が得られるのか・・・
このような複雑な情報は頭の中でイメージするには、限界がある上に、頭の中のメモリを大幅に取られてしまいます。頭の中のメモリを取られて過ぎてしまうと、本来の作業に割くメモリが無くなり作業効率が落ちてしまいます。
こんな時は、図を描いてみましょう。図を描くことによってイメージで頭の中のメモリが取られることがなく、本来の作業に全てメモリを使うことができます。
そしてこの作業の中で出てきた発想は図に書き足す事によってメモリが埋まっていくことを防ぎ、さらに新たな発想に繋げることができます。
頭の中のメモリは有限ですが、図を描くための紙さえあればメモリを無限に増やすことができるので図を書きまくりましょう。

タスクの目的を常に意識する

"何の為に今のタスクに取り組んでいるか"ここを捉えているかいないかでタスクのクオリティに大きな違いが出てきます。
例えば、大半の新人エンジニアが最初に担当するのがテスト工程ですが、ここでありがちなのが"テストを消化する"ことが目的になってしまっているパターンです。
このパターンだと、テスト項目書に書いてある結果になるかどうかだけを見てしまう為、タスクの完了時の評価を5段階評価(☆☆☆☆☆)にすると星3(★★★☆☆)といったところでしょうか。
テストは作成したアプリが正常な動きをするか、異常な動きをしていないかを確認する工程です。
この点を意識できていると、テスト消化の際に「項目書通りの動きはしたけど、レイアウトが崩れているなぁ」とか「項目書通りの画面は表示されたけど、表示されるまでのローディング画面が長かったなぁ」とか項目書で拾い切れていない不具合も拾うことができます。(実際に不具合かどうかは別として)ここまでできれば星5(★★★★★)じゃないでしょうか！！
このように、タスクの目的を意識することによって視野が広がりますし、求められている成果物に限りなく近いものを作ることができます。場合によっては求められている以上の成果物を作ることも可能です。
結果自分の成長にも繋がるところだと思うので、ぜひ意識してみましょう！

手を動かす

これは実際にプログラムを組む際に大きく役立ちます。
思っている処理にする為には、
どのようなプログラムを組まなければいけないのか。
ずっと頭の中で考え、進捗が上がらないことが多々ありました。
このような状態を抜け出すには、とにかく手を動かすことが重要です。
では具体的に何をするのか。
ポイントは3点

①仮説を立てる
②仮説を実践してみる
③振り返り

このサイクルを素早く繰り返すことが、ゴールへの近道です。
頭の中で仮説がたったら実践してみる、そこで失敗したとしても
振り返りを行い、それを元に新たな仮説を立てる。
頭の中だけでは絶対に答えは出ません。
手を動かしてみましょう！！

タスク完了の時間は想定よりも多めに伝える

上司からタスクを振られると共に、どれくらいでタスクを完了できるのかも
一緒に聞かれることが多々あります。
この場合、根拠のない想定時間をそのまま伝えるのは圧倒的に間違いです。
私はよく、やったことのないタスクではあるがなんとなくこのくらいの時間で終わるだろうという想定で完了時間を報告していましたが、一度も報告通りの時間に完了したことはありません。
基本的に、報告した時間内にタスクが終わらないというのはNGです。
その為、根拠のある想定時間とイレギュラーが発生した際のことも含めて+αのタスク完了時間を報告するのがベストです。
根拠のある想定時間の算出は、経験があるタスクであればある程度割り出すことは可能ですが、新人エンジニアには経験が無い為、すぐに算出することはできません。
その為、少しタスクに着手してみて着手した上での進捗と掛かった時間から想定時間を算出するのが良いです。
想定時間を算出できたら、＋αの時間を乗っけて報告するのがベストです。
＋αの時間についてはなんとも難しいのですが、想定の3倍の時間で報告→了承を得るができればベストです。
しかし、上司ならまだしもお客様との対話の中で安易に3倍の時間を報告するのは危険です。
お客様の想定が1時間だった時に3時間で報告をしてしまうと、信用を失うことに繋がりかねません。
まぁ上司だからと言って何も考えずに3倍の時間を伝えるのもまたちょっと違う話かなとは思いますけどね・・・
ここは上司との対話の中で丁度良い頃合いを見つけていきましょう。

ショートカットキーを使いまくる

スーパーエンジニアの上司曰く、仕事ができない人には決まって共通点があるとのこと。
それは、ショートカットキーを使わないことです。
細かい点ではあるのですが、１日の限られた時間のなかで多くの作業を行うにあたり、一番わかりやすくタスクの時間短縮ができるのがショートカットキー。
アプリやウィンドウを切り替えるAlt+Tabキーや指定範囲をコピーするCtrl+C、ペーストするCtrl+v等はよく使った印象があります。
一番感動したのは、エクセルのセルに文字を打ち込むときに、毎回セルをダブルクリックしていたのをセルを指定してF2キーを押すこと。
こういったショートカットキーは、ショートカットキー一覧等で検索すれば紹介しているページがたくさん出てくるので調べて便利そうなものはどんどん使っていきましょう。

エラー文から逃げない

エラーが起こった際は、ログを見て原因を特定し、修正をするという流れになりますが、新人エンジニアの場合、原因を特定する場面でかなり躓く印象があります。
私を含め、周りの新人エンジニアも良くやっていたことなのですが、
エラー文から目を背けるのはやめましょう。一生解決できません。
何故か新人エンジニアがそろってやりがちなのですが、

①エラー発生
②ログを見る
③エラー文をを発見
④よくわからないから、原因と思われる部分をなんとなく修正してみる。

何故なのか。自分でやっていてよく分からないのですが、
無意識にエラー文から目を背けてしまっています。

エラー文には問題解決のヒントが書いています。
エラー文と向き合いましょう。
調べればエラー文の意味は分かるはずです。
エラー対処はエンジニアである以上避けては通れないので、
今のうちにコツを掴みましょう！！

最後に

長文にお付き合い頂きありがとうございました。

私自身、まだまだ注意されることも多いですし、
今回書いたことの中でも意識から外れてしまう点がいくつか
あったりするので戒めの意味も込めて書いてみました。

新人エンジニアというのは、できないことばかりで
自信を失ってしまうこともあると思います。

ですが、コツコツ積み重ねていけばきっと結果はついてくるはずです。
現に私は初現場で、分からないことばかりで上司からコテンパンにされましたが、
結果として多くの成果物をプロジェクトの中で残すことができました。

どんどん挑戦して、レベルアップしていきましょう！！

DEV Community: Seattle Consulting, Inc.

Alexa Skill Blueprintsを使った簡単スキル作成

Alexaを買ってみたけれど

Alexa Skill Blueprintsでできること

スキル作成までの手順

GCE + VSCode + docker-composeでリモート開発環境を構築する

目次

事前準備

GCEでインスタンス作成＆起動

GCEインスタンス上で、個別プロジェクトのdocker-compose実行

git, docker. docker-composeインストール

個別プロジェクトのソースコードをGitHubからcloneした後、docker-compose upを実行

ポートを開ける（Optional）

Visual Studio Code Insiders & Extensionsで開発

Remote Developmentをインストール

VMインスタンス側の接続設定

ローカル側の接続設定

余談

もっと早く出会いたかった git command 達

はじめに

便利コマンド

差分をステージングエリアに追加する

差分を取り消す

ステージングエリアから戻す(add する前に戻す)

指定したユーザーのコミットログを見る

コミットIDを指定して、中身を確認する

別のブランチからファイル/コミットを持ってくる

直前のコミットを修正する

ファイル名の変更

特定のファイルの歴史を確認

マージ済みのブランチの確認

直前のブランチを指定して〇〇

マージしたらコンフリクトしたのでなかったことに

ざっくりした差分をみる

ステージングエリアの差分を見る

リモート削除されたローカルブランチを削除する

ネタ系

コミット数のランキング

最後に

おまけ

僕の git の alias を晒します

未経験中途入社エンジニアが初現場で学んだこと

はじめに

"分からない"を知ってもらう

"分からない"に直面した時は

質問の仕方を考える

"分からないこと"が"分からない"

認識合わせをする

定点報告をする

図を描く

タスクの目的を常に意識する

手を動かす

タスク完了の時間は想定よりも多めに伝える

ショートカットキーを使いまくる

エラー文から逃げない

最後に