CodeCommit 〜クライアント側設定編〜
前回の記事では、AWS CodeCommitのサーバー側の設定を行いました。
CodeCommit 〜サーバー側設定編〜 - Tatsuyashi's Blog
今回はクライアント側の設定と実際にコミット、プッシュまで行ってみたいと思います。
が!
実はサーバー側の設定、まだ残っていました(笑)
ということで今回はまず残っているサーバー側の設定から行っていきます。
IAMユーザの作成
AWSといえば、IAMによるユーザ・権限の管理ですね!
例に漏れず、CodeCommitも権限が必要です。
専用のユーザを作ってみたいと思います。
まずIAMコンソールを開き、左のサイドバーから「ユーザー」→「ユーザーを追加」とクリックしていきます。
ユーザ情報を入力していきます。サンプルのユーザーなので名前は適当です。
アクセス許可の設定は「既存のポリシーを直接アタッチ」から「AWSCodeCommitFullAccess」をアタッチします。
ユーザーの追加が完了すると、アクセスキーID・シークレットアクセスキーが表示されるので、コピーしておきます。
これで、CodeCommitの権限を持ったユーザが作成できました。
HTTPS接続
HTTPSで接続する手順に入ります。
Git認証情報の生成
IAMコンソールを開き、左のサイドバーから「ユーザー」→対象ユーザをクリックし、「認証情報」タブを開きます。
「AWS CodeCommit の HTTPS Git 認証情報」の「生成」ボタンをクリックします。
認証情報が生成されるので、証明書をダウンロードしてユーザに配布します。
パスワードを確認できる唯一の機会ですので忘れずダウンロードやメモをしましょう。
クライアントからの接続
※管理者ではなく、開発者自身がコンソールにログインして操作します。
CodeCommitコンソールを開き、対象のリポジトリを選択し、「クローンURL」から「HTTPS」を選択します。
クリップボードにURLがコピーされるので、早速接続してみたいと思います。
クローン
①クローンします。
git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/test
②認証が求められるので、先ほど生成したユーザ名とパスワードを入力します。
Cloning into 'test'... remote: Counting objects: 3, done. Unpacking objects: 100% (3/3), done. Checking connectivity... done.
クローンが成功します。
コミット&プッシュ
とりあえず何かしらソースに変更を加えて・・・
①ステージ
git add README.md
②コミット
git commit -m "test commit"
コミットが成功します。
③プッシュ
git push origin master
プッシュが成功します。
クローンしてからの流れは通常のGitの操作と同じですね。
確認
プッシュされた内容を確認します。
CodeCommitコンソールから対象のリポジトリを開きます。
変更が反映されていますね!
HTTPSでの接続はこれで終わりです。
SSH接続
次にSSHで接続する手順に入ります。
SSH鍵ペアの生成
※開発者作業
ssh-keygen
鍵名はcodecommit_rsaにしておきます。
Enter file in which to save the key (/c/Users/xxxxx/.ssh/id_rsa): /c/Users/xxxxx/.ssh/codecommit_rsa
以上で、codecommit_rsaとcodecommit_rsa.pubが作成されます。
SSH公開鍵のアップロード
IAMコンソールを開き、左のサイドバーから「ユーザー」→対象ユーザをクリックし、「認証情報」タブを開きます。
「SSH 公開鍵のアップロード」をクリックします。
公開鍵の入力欄が表示されるので、codecommit_rsa.pubの内容を貼り付けます。
公開鍵がアップロードできたら、SSHキーIDをコピーしておきます。
SSH秘密鍵の設定
./.ssh/configを以下のように編集します。ファイルがなければ作成します。
Host git-codecommit.*.amazonaws.com User APKAEIBAERJR2EXAMPLE IdentityFile ~/.ssh/codecommit_rsa
UserにはコピーしておいたSSHキーIDを設定します。
SSHの接続テストをします。
ssh git-codecommit.us-east-2.amazonaws.com
実行するとAWS CodeCommitサーバーのフィンガープリントが表示されます。
接続続行の確認には「yes」、その後パスフレーズの入力を求められるので入力します。
You have successfully authenticated〜〜〜
と表示されれば接続テストOKです。
クライアントからの接続
CodeCommitコンソールを開き、対象のリポジトリを選択し、「クローンURL」から「SSH」を選択します。
クリップボードにURLがコピーされるので、接続してみたいと思います。
クローン
①クローンします。
git clone ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/test
サーバーのフィンガープリントが表示されます。
接続続行の確認には「yes」、その後パスフレーズの入力を求められるので入力します。
Unpacking objects: 100% (3/3), done. Checking connectivity... done.
クローンが成功します。
コミット&プッシュ
ソースに変更を加えて・・・
①ステージ
git add README.md
②コミット
git commit -m "ssh test commit"
コミットが成功します。
③プッシュ
git push origin master
パスフレーズを聞かれるので、入力するとプッシュが完了します。
確認
プッシュされた内容を確認します。
CodeCommitコンソールから対象のリポジトリを開きます。
変更が反映されていますね!
SSHでの接続はこれで終わりです。
まとめ
今回はCodeCommitに実際に接続してソースの編集、コミット、プッシュまで行いました。
HTTPSとSSH両方試しましたが、手間がかからなくてなおかつ公式ドキュメントで推奨されているHTTPSを使用していこうと思います。
CodeCommit 〜サーバー側設定編〜
あらゆるサービスで利用されていますね。
私自身も仕事で扱うことが増えてきました。
ただ、アプリ寄りのエンジニアということもありAWSで基盤を作ったりという経験はありませんでした。
今回、業務外ですが仲間内でアプリを作ることになり、担当割を行った結果、今まで経験が少ないAWS構築の担当となりました。
( 立候補の上、やらせてもらうことにしました )
色々詰まるところは出てくるとは思いますが、知ってる人に聞いたりググったりして進めていこうと思います。
まず今の時点でできているのは、
- AWSの無料枠登録
- 管理者と自分のIAMユーザ作成
までです。
具体的にどんなサービスを使って構築するかはこれから検討するので、まずは開発環境の提供を進めます。
今回構築するのは AWS CodeCommit です。
AWS CodeCommitとは
ふむふむ。
AWSが提供するGitのホスティングサービスということですね。
GitHubで良いやん!
と言いたいところですが、
- GitHubはこれまでに何度も利用している
- 今回の主旨は、できるだけ新しいor使ったことのない技術を利用する
という理由があるため、GitHubではなくCodeCommitを使ってみます。
5人までは無料枠で使用できるので、メンバー的にはギリギリ足りています。
では早速、AWS CodeCommitの設定に入っていきましょう!
基本的には以下のチュートリアル通りに進めてみます。
AWS CodeCommit の開始方法のチュートリアル - AWS CodeCommit
CodeCommitにリポジトリを作成する
① AWSコンソールにログイン
② AWS CodeCommitコンソールを開く
AWSコンソールトップのテキストボックスに「codecommit」を入力し、「CodeCommit」を選択します。
コンソールが開いたら「今すぐ始める」をクリックします。
↓
③ リポジトリ情報を入力
とりあえずお試しなので「test」
④ リポジトリ作成完了
リポジトリの作成が完了して、Eメール通知の設定画面が表示されます。
ここは一旦「スキップ」します。
↓
ファイルをコミットしてみる
クライアントからコミット→プッシュするのは次回行うとして、今回はCodeCommitコンソールからファイルをコミットしてみます。
リポジトリ画面で「ファイルの追加」→「ファイルのアップロード」をクリックします。(「ファイルの作成」でも可)
あらかじめ用意していたファイルを選択します。今回はREADME.mdをアップロードします。
コミット画面が表示されるので、
- 作成者
- Eメールアドレス
- コミットコメント
を入力して「ファイルをコミット」をクリックします。
↓
できましたね!READMEも表示されています。
まとめ
今回は、CodeCommitによるリポジトリの作成を行いましたが、非常に簡単で1分もあれば作成できます。
GitHubや似たようなGitのホスティングサービスを利用したことがある方にとっては全く苦にならないという印象でした。
次回はリポジトリをクライアントからクローンして、コミット、プッシュ等の操作を学んでいこうと思います。
筋トレログ その3
今日のメニューです。
背中をメインにトレーニングを行いました。
今日のメニュー
レッグプレス (太もも、臀部)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 120 | 15 |
2 | 120 | 15 |
3 | 120 | 15 |
レッグエクステンション (太もも前、臀部)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 45 | 15 |
2 | 45 | 15 |
3 | 45 | 15 |
懸垂マシン (背中)
体重 - 重量が実際のウェイトになります。
セット | 重量(kg) | 回数 |
---|---|---|
1 | 18 | 10 |
2 | 18 | 10 |
3 | 18 | 10 |
ラットプルダウン (背中)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 45 | 10 |
2 | 45 | 10 |
3 | 45 | 10 |
プルダウン (背中)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 30 | 15 |
2 | 30 | 15 |
3 | 30 | 15 |
チェストプレス (胸)
背中の日ですが、筋力キープのために胸のトレーニングも軽く入れておきます。
セット | 重量(kg) | 回数 |
---|---|---|
1 | 40 | 15 |
2 | 40 | 15 |
3 | 40 | 15 |
バタフライマシン(のようなもの) (胸-内側)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 35 | 15 |
2 | 35 | 15 |
3 | 35 | 15 |
ダンベルカール (上腕二頭)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 12 | 10 |
2 | 9 | 10 |
3 | 9 | 10 |
やはり12kgはまだ早いですね。。
コンセントレーションカール (腕-主に上腕二頭)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 3 | 15 |
2 | 3 | 15 |
3 | 3 | 15 |
シーテッドロー (背中)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 15 | 15 |
2 | 15 | 15 |
3 | 15 | 15 |
腹筋マシン(左右に捻るタイプのマシンですが名前わかりません)
左回り、右回りそれぞれ
セット | 重量(kg) | 回数 |
---|---|---|
1 | 60 | 15 |
2 | 60 | 15 |
3 | 60 | 15 |
有酸素運動 (リカンベントバイク)
約30分
振り返り
全体的に左右差を感じています。左の方が疲労が早いです。
右利きだからというのはあるかもしれませんが、左右差を埋めていきたいので、右より回数を増やしたり片側を鍛えられるトレーニングを取り入れていければなと思っています。
筋トレログ その2
今日のメニューです。
前回の筋肉痛が一部残っていたので、影響の少ない足と肩を中心に行いました。
今日のメニュー
レッグプレス (太もも、臀部)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 105 | 15 |
2 | 105 | 15 |
3 | 145 | 10 |
レッグエクステンション (太もも前、臀部)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 35 | 15 |
2 | 35 | 15 |
3 | 35 | 15 |
レッグカール (太もも後ろ、臀部)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 45 | 15 |
2 | 45 | 15 |
3 | 45 | 15 |
足のメニューは体全体に疲労がきます。。
ショルダープレス (三角筋前)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 30 | 12 |
2 | 30 | 12 |
3 | 30 | 12 |
名称不明 (三角筋後ろ)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 35 | 12 |
2 | 35 | 12 |
3 | 35 | 12 |
ショルダープレス (三角筋前)
2回目。軽めで回数増やします。
セット | 重量(kg) | 回数 |
---|---|---|
1 | 10 | 20 |
2 | 10 | 20 |
3 | 10 | 20 |
ハンマーカール (前腕、上腕二頭)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 8 | 15 |
2 | 8 | 15 |
3 | 8 | 15 |
4 | 4 | 15 |
5 | 4 | 15 |
6 | 4 | 15 |
トライセプス・プレスダウン (上腕三頭)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 16.75 | 15 |
2 | 16.75 | 15 |
3 | 16.75 | 15 |
有酸素運動 (リカンベントバイク)
約30分
振り返り
ジムの宿命ですが、他のトレーニーが多かったため思ったようなトレーニングできませんでした。
足りない分は自宅で補うように考えます。
それにしても足のトレーニングは本当に疲れます。。
Angularを2年ほど使ってみた感想
ここのところ、仕事で約2年ほどAngularを使ってSPAの開発をしています。
バージョンとしては1, 2, 4, 6と割と幅広く使っています。
今回はそんな私がAngularを2年使ってみて感じた良かった点・悪かった点を書いていこうと思います。
(ただし、AngularJS (バージョン1) は対象外)
良かった点
公式ドキュメントが充実
最近はドキュメントが充実しているプロダクトが増えてきている印象ですが、AngularもさすがGoogle社のエンジニアが開発しているだけあってわかりやすいドキュメントを用意してくれています。
ただし英語がベースなので多少の英語力は必須です。
( 最近はコントリビューターによる日本語翻訳もかなり進んできています! )
デザインとロジックが明確に分離できる
AngularのComponentはビュー(HTML, CSS)とロジック(TypeScript)のファイルを分けて開発するので、デザインに力を入れる時・ロジックに力を入れる時の頭の切り替えが楽にできます。
担当の分担も比較的容易にできると思います。
他に大きなライブラリを組み合わせる必要がない
Angularはフルスタックであることを売りにしていることもあり、Angularさえあれば他のライブラリはほとんど必要ありません。
私もいくつかAngularの開発をしてきましたが、UIライブラリを除いてはAngularのQuickStartで使うライブラリ以外にほとんど追加せずに済んでいます。
Angular CLIが優秀
Angularを開発する上で必須となるのが、Angular CLIです。
- Angularプロジェクトの作成
- 各種ファイル (Component, Directive等) の自動生成
- Webpackを含んでいることにより、開発サーバの設定やビルドが楽
等の特徴があり、プロジェクト作成から開発、ステージング・本番環境へのビルド、デプロイまで一連の流れをコマンド1つでできます。
また、CLIなので、CI (JenkinsやCircle CI等) への組み込みも容易なのは良いですね。
個人的に一番嬉しかったのはWebpackを含んでくれていることです。
Angular CLIを使用せずに開発をしていた頃は、Webpackを自分で組み合わせていたのですが、
依存関係や設定の問題やらで相当苦しめられたので、その苦しみから開放されたのは非常に大きいです。
楽しい!
単純に楽しいです(笑) それだけでモチベーションが違いますね!
特にこれまでjQuery等でガリガリ開発してきた方からすると、開発手法や考え方が大きく変わるので良い刺激になります。
悪かった点
悪かったというより苦労した点になります。
バージョンアップについていくのが大変
Angularは6.0.0のようにmajor.minor.patchというバージョニングが行われていて下記のようなスケジュールでの運用が行われています。
- major → 半年に1回バージョンアップ
- minor → majorのバージョンアップまでに2、3回のバージョンアップ
- patch → 毎週バージョンアップ
Angularに限らず昨今のフロントエンドの開発スピードは尋常ではないので、どこでバージョンFixするかというのも開発において重要になってきます。
またmarjorが半年に1回のため、新しくアプリの開発をする度にmajorバージョンのアップを検討する必要が出て来ますし、新機能を理解していくのも時間がかかります。
Webで情報収集する際にも、度々起こる破壊的変更によって、せっかくの良記事が参考にならないということもよくあります。
日本語の情報が少ない
今は検索しても日本語の情報がよく見られるようになりましたが、私がAngularを開発し始めた当初はほぼ英語の情報しかありませんでした。
おかげで英語を読むことへの抵抗が少なくなったので、それは良かったとは思っています。
開発者の教育が必要 (教育コスト)
例えばJavaの開発であれば、Javaができるエンジニアは星の数ほどいるので、1から教育することはあまりありませんが、 Angularはとにかく経験者が少ないので、手に馴染んでもらうまでそこそこ時間を要します。
QuickStart〜Tutorial (Tour Of Heros) を一通りやってもらったり、Webpackなどの説明をしたり、、
Anguar自体は難解なフレームワークではないのが救いです。
これからもっとAngularが広がっていくことを願うばかりです。
最後に
以上、私が約2年Angularの開発をしてきた上で感じた感想を記載しました。
苦労することもありますが、開発していて楽しいと思えるフレームワークですので、SPAを検討する場合は是非Angularを試してもらえたらなと思います。
※ReactやVue.jsと比較しているわけではありません。この記事ではAngularにのみフォーカスしています。
筋トレログ その1
単なる趣味の域ですが、1年ほど筋トレしています。
ある程度効果はでていると思っていますが、ちょうどブログを始めたのでメモとして自分がやった内容を残していきます。
今日は筋トレログの1回目なので、何故トレーニングするのか、どういうトレーニングをしているのかなどを簡単に書いてから、今日のメニューを書こうと思います。
筋トレを始めたきっかけ
30歳を超えて自分がおっさんに向かっていくと考えたとき、ふと、
おっさんになっても体絞れてる人ってかっこいい!
と思ったのがきっかけです。
サラリーマンをやっていると、体を動かす機会がなくなり、飲み会や外食で太る一方です。
自分の周りを見ても恰幅の良い人ばかり。。
私もちょうど太りかけていた時期でもあったので、
- 諦めてこのまま太る
- トレーニングをして体をつくる
という分岐点に立った結果、2を選択しました。
どうやって筋トレしているか
ジムに通っています。
エニタイムフィットネスという最近都市部で増えてきている24時間365日営業しているジムです。
自宅の近所にちょうどエニタイムフィットネスがあったので入会しました。
ペース
週2回ジムに行っています。火-土、水-日という組み合わせが多いです。
仕事が忙しい時期や体調が悪い時は週1回になることもありますが、
その場合でもできるだけ自宅でトレーニングするようにしています。
目標
体重○kg!という目標を立てる方が多いですが、私は体重は気にしません。
(ちょっとは気にしますが)
それよりは外見を重視していて、
- お腹が出ていない
- 良い感じに筋肉が付いている
という風にあいまいではありますが、見た目に対して自分が満足できるかどうかという点でみています。
数字での目標をあげるとするなら、体脂肪率ですね。だいたい10%ぐらい。
この位の数字になると余分な脂肪が落ちて腹筋がキレイに見えてきます。
今日のメニュー
とりあえず前段はこのぐらいにしておきます。今日書ききれなかった分は別の日に書きますね。
ここからは今日行ったメニューをつらつらと書いていきます。
本当はトレーニングの画像とかあれば良いですが、ちょっと時間がかかりそうでしたのでどこかで載せるようにします。
重量がしょぼいのは気にしない(笑)
レッグプレス (太もも、臀部)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 105 | 15 |
2 | 105 | 15 |
3 | 145 | 10 |
チェストプレス (胸)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 45 | 15 |
2 | 45 | 12 |
3 | 45 | 12 |
ダンベルプレス (胸)
ダンベルプレスは久しぶりだったので今日は軽めです。
セット | 重量(kg) | 回数 |
---|---|---|
1 | 10 | 15 |
2 | 10 | 15 |
3 | 10 | 15 |
4 | 5 | 20 |
5 | 5 | 20 |
バタフライマシン(のようなもの) (胸-内側)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 35 | 12 |
2 | 35 | 12 |
3 | 35 | 12 |
4 | 20 | 20 |
5 | 20 | 20 |
ラットプルダウン (背中)
今日は胸メインの日なので、背中は程よい重量でしっかり効かせることを重視しました。
セット | 重量(kg) | 回数 |
---|---|---|
1 | 40 | 12 |
2 | 40 | 12 |
3 | 40 | 12 |
4 | 25 | 20 |
5 | 25 | 20 |
ダンベルカール (腕-主に上腕二頭)
ドロップダウンセットで行いました。
インターバル5秒ぐらいで行うので、最後の2kgでも相当辛いです。
セット | 重量(kg) | 回数 |
---|---|---|
1 | 10 | 10 |
2 | 8 | 10 |
3 | 6 | 10 |
4 | 4 | 10 |
5 | 3 | 10 |
6 | 2 | 10 |
コンセントレーションカール (腕-主に上腕二頭)
セット | 重量(kg) | 回数 |
---|---|---|
1 | 5 | 15 |
2 | 5 | 15 |
3 | 5 | 15 |
腹筋マシン(左右に捻るタイプのマシンですが名前わかりません)
右回り
セット | 重量(kg) | 回数 |
---|---|---|
1 | 60 | 15 |
2 | 60 | 15 |
3 | 60 | 15 |
左回り
セット | 重量(kg) | 回数 |
---|---|---|
1 | 60 | 15 |
2 | 60 | 15 |
3 | 60 | 15 |
有酸素運動 (リカンベントバイク)
スマホで本読みながらできるのでよく使っていましたが、この記事によると有酸素マシンとしての効果は最低ランクですね(笑)
振り返り
今日はチェストデイ (胸がメインの日) としていました。
マシンの空き事情もあってメニュー変えた部分はありますが、それなりに効いたと思います。
あ、肩やるの忘れてました(笑)
アウトプットすることの大切さ
前回のブログで1日1記事を目標に掲げながら、早速3日も空けてしまいました。。
書きたいネタはいくつかあるので、後はそれをひたすら書く、ということで頑張っていきます。
で、今回はアウトプットするということについて軽く語ろうと思います。
アウトプットとは
アウトプットはoutput (出力) のことですね。ここでは情報のアウトプットのことを指します。
- 人に口頭で説明する
- 資料にまとめる
- ブログに書く
などがあります。
アウトプットできていますか?
アウトプットの逆はインプット (input (入力)) です。
- 人に口頭で説明してもらう
- 本を読む
- Webで検索する
などがあり、現代ではインプットの手段、情報量が豊富に存在します。
それ自体は非常に良いことなのですが、
私が最近つくづく思うのは、
インプットばかりし過ぎて、アウトプットできている人が少ない
ということです。
「○○の勉強で△△の本を買いました!」
「□□の勉強会に行きました!」
という話はよく聞きます。
素晴らしい!
まずは行動に移せている時点で素晴らしいとは思います。
ただ、
そのインプットした情報をどうしていますか?
インプットしっぱなしになっていませんか?
なぜアウトプットが大事なの?
ずばり言うと、
自分にとって最適なかたちで情報を整理できる
ということにあると思います。
書籍やWebから得られる情報って非常によくまとまっていてわかりやすいものが多いですよね。
そういった情報も結局のところ、
筆者の考えを筆者なりに整理したものを提供してくれているわけです。(筆者ナイズされている)
人間は誰ひとりとして同じ人はいません。
人が何を考えているかを完全に把握することは不可能です。
つまり、
インプットされる情報は提供する側にとっては100%の情報だが、
それを受ける側にはかっちりはまるものではない。
受け手にとっては10%なのか20%なのかわかりませんが、必ずズレが生じています。
その穴埋めを行うためにアウトプットが必要なのです。
じゃあ何をすれば良いの?
最初の方に書きましたが、
- 人に口頭で説明する
- 資料にまとめる
- ブログに書く
などがあり、基本的にはどういう手段でも良いのかなとは思います。
ただ大事なポイントは3つあって、
- 自分の言葉で表現する
- 具体例を挙げられるようにする
- 他者に見てもらう(聞いてもらう)状況を作る
この3つは是非意識して実践してもらえたらなと思います。
これらを行おうとすると、相当自分の中で情報が整理されていないと上手くいかないので、失敗しても良いのでまずは実践をして、
自分の中でカチッとはまる感覚
を覚えることができれば十分定着したと言えると思います。
インプットしたママ伝えるようなことはしないということが大事です。
最後に
長々と書きましたが、
要はアウトプットすることでインプットされた情報を自分ナイズしましょうということです。
中にはそんなことしなくても大丈夫な脳みそスポンジ人間な人もいますが、
私のような凡人はアウトプットしないと上手く吸収できません。
一緒に仕事をしている人にもできるだけアウトプットを勧めようとはしていて、
最近は「Javaについて詳しく教えてください」「Angular教えて」というような依頼はほとんど断っています(笑)
間違ってても良いからあなたが説明する機会を作ってくれ、と頼んでいます。
別に勉強会のような形式ではなくもっと軽い感じで良いのでと。
もちろん完全に丸投げしても大変だと思うので、ヒントや参考資料は教えたりしていますし、
アウトプットされる際のフォローは全力で行っています。
感覚値でしかないですが、こちらから一方的に教えるよりは効果があるのかなとは思っています。
とはいえ、元々私は全くアウトプットしない人間で、割りと最近になってその重要性に気付きました。
自分が凄いなーと思っていた人たちはみんなアウトプットしていたなーということも併せて気付きました。
そして今回ブログ、Twitter、GitHubのアカウントを作成してアウトプットする環境を用意したわけで。
今は1つ書くのに凄く時間がかかっていますが、自分のためにこれからどんどんアウトプットしていこうと思います。