このコースの通りやれば、LINEbotを作れる。個人的に嬉しかったのが以下の3点。Laravelでアプリを作成〜公開までのやり方が分かった。Laravelでアプリを開発するのに有用なツールやライブラリ、コマンドを知ることができた。外部APIを使う際の流れが理解できた。どれもLaravelの入門書だと調達できなかった知識なので、よかった。LINEbotが目的でなくても、Laravelの開発をするつもりであれば、知っておきたい内容だと思った。Laravelの入門書と並行して私の教材に取り組んでいただき、入門書では触れていない知識をうまく私の教材が補完するかたちとなったようです。嬉しかった3点、として挙げていただいた点が、まさに私の教材で意識して盛り込んだ内容なので、大変嬉しいです。Laravelでアプリを作成〜公開までのやり方が分かった。教材ではHerokuへのデプロイ方法を解説しています。Herokuなどにデプロイができるようになると、自作のアプリをネット上で広く使ってもらえるようになり、プログラミング学習のモチベーションがぐっと上がるかと思います。そのため、教材にはデプロイ方法の解説を盛り込みました。Laravelでアプリを開発するのに有用なツールやライブラリ、コマンドを知ることができた。Botと直接は関係無い知識も積極的に盛り込んでいます。外部APIを使う際の流れが理解できた。教材では、ぐるなびAPIの使用方法を解説しています。何かひとつAPIの使い方を学べば応用して他のAPIも使いやすくなり、作ることのできるアプリの幅も広がることになるので、API利用を題材としました。次に2人目の方の感想。満足のいく講座でした。簡易版などを作成し公開することで段階的に理解することができました!Laravel入門書(青本)を一読した後にお勧めだと感じます。Botを作るのではなく、シンプルな内容から徐々にBotの機能を発展させていく構成としましたが、その点を評価いただけたようです。こちらの方も通称青本と呼ばれる以下のLaravel入門書と併用して、私の教材に取り組んでいただいたようです。Kindle版この商品を含むブログを見る続いて3人目の方の感想。Botを作ることができました。活用方法を知れる良い教材でした!Laravel初学者でも十分に理解できるとのことですが、丁寧な解説を心掛けたので大変嬉しいです。Bot作りを通じてAPIの活用方法を学んでいただけたようです。制作意欲も湧き、内容もわかりやすい非常に良い教材でした。次回作も期待しています。Botは制作意欲が湧きやすい題材のひとつでは?」という話になり、今回選択しました。それが良い結果に繋がったようで嬉しいです。最後に5人目の方の感想。LineBotなどのAPIなどを使ってみたい、Laravelに触れてみたいという方にオススメです。実用的にアプリが作れるので楽しかったですし、解説や質問への回答も丁寧ですごく良かったです。この教材の前後でLaravel本を読むとより理解が深まると思います。Botを完成させることができました。その質問対応も含めて評価をしていただけました。Twitter上での感想Twitter上でも感想を書いて下さる方がいたので、それらの一部を紹介します。同じ方なのですが、異なる観点で2つ感想を書いていただけているので、その両方を紹介します。2019初級レベルで基本的なことから記述してくれていたから、Laravel勉強始めたばかりの自分は取り組みやすかった!基礎的なところから解説をしている点を評価いただけました。if文、foreach文、関数・引数の概念の理解)があればLaravel未経験でも教材を進められるよう解説しているつもりなので、Laravel初学者の方であればすんなりと入っていけるのでは、と思います。2019Lineでキーワードを入力すると飲食店検索ができるようになって、デプロイ方法まで解説されてるからこのチュートリアル完成させれば普通にアプリケーションとしても便利だ😄ある程度の実用性を持たせたアプリを作ることのできる点を評価いただきました。Bot)完成後はご自身で使ったり、知り合いにLINE上で友だち登録して使ってもらうなどして、楽しんでもらえたらと思います。教材を使った勉強会での感想また、既に開催済みですが、私の教材を使った勉強会をTechpitさんに先日開催いただきました。10/19(土)の開催に対し、その4日前の10/15(火)からの告知だったので募集期間は短めでしたが、大変嬉しいことにすぐに募集枠はいっぱいとなりました。参加いただいた方からは以下のような感想をいただきました。外部apiとlaravelの連携だったりインターフェース,tinker,guzzleだったりと知りたかった技術が実際にアプリとしてどのように機能するのか。最初から調べながらやるよりもはるかに理解がしやすかった。いきずまってる人におすすめです。2019外部apiとlaravelの連携だったりインターフェース,tinker,guzzleだったりと知りたかった技術が実際にアプリとしてどのように機能するのか。最初から調べながらやるよりもはるかに理解がしやすかった。様々な知識を短期間で効率的に学べる点を評価いただきました。この教材を足がかりに、更にアプリケーション開発の知識を広げていっていただけたらと思います。Botを作ろう!」のレビュー・感想まとめでした。多くの方から好意的な評価をいただけて、教材執筆者としては嬉しい限りです。こちらの教材に興味を持った方は以下のTechpitのサイトからご覧ください。IAMのマニアックな話」のダウンロード版をBOOTHにて購入しました。takuros.booth.pm本の概要タイトルに「マニアックな・・・」とありますが、実は表紙を見ると「初心者からマニアまで必読」とあるこの本。AWSアカウントとIAMユーザーの違いなど、基礎的な内容から始まって段階的にIAMについて理解できる本となっています。全10章構成の1章・2章で基礎を押さえた後は、3章のチュートリアルで実際にIAMポリシー等を作成。4章以降はIAMの設計・運用に役立つ実践的なノウハウがまとめられています。IAMのマニアックな話」は「IAM初心者」にこそちょうどいいが詳しいので、私からは個人的に嬉しかった第8章の「IAMとCloudFormation」について。この章では、CloudFormationを使ってIAMを管理することの利点のほか、別途コラムというかたちで、IAMに限らずAWSリソース全般に関してCloudFormationを継続的に利用するための考え方について触れられています。CloudFormationの使い始めは、それ全部で完結するような長大なテンプレートファイルを作成してしまいがちなようで、これに対してどのようなAWSリソースがCloudFormationのテンプレートファイル化に適しているか、その考え方ひとつのテンプレートファイル内で管理するAWSリソースの粒度について解説されており、これが私には非常に勉強になりました。このIAM本で取り扱われていることからもわかる通り、IAM(IAMユーザーは除く)はCloudFormationで作成・管理するのに適しており、その具体的手法が学べます。IAMを作成するためのCloudFormationテンプレートファイルは比較的シンプルなものになるようで、CloudFormation入門の題材としてもIAM作成はお勧めだそうです。続く9章ではサンプルとして、管理者グループ、開発者グループなどを想定した6タイプのIAMグループの構成が掲載されています(CloudFormation用テンプレートファイルも本掲載のURLからダウンロードできます)。これらも活用して、IAMに加えてCloudFormationの理解も深めていきたいと思います。副業はじめにプログラミング初学者向けの教材(チュートリアル)を執筆し、Techpitというプログラミング学習サービスで公開しました。Techpitは、作りながらプログラミングが学べる「プログラミング学習教材のマーケットプレイス」です。現役のエンジニアがプログラミング学習者向けに教材を販売し、プログラミング学習者は現役エンジニアが作った教材で、文法ではなくサービスの作り方を学ぶことが出来ます。これまでQiitaなどに自らの勉強目的でチュートリアルを投稿したことは何度かありますが、有料のチュートリアルを作成したのは今回が初となります。有料なので、筆者である私にはその売上の一部が入ります。私は企業で社員として働いているので副業収入ということになります。今回は企業に属する社員エンジニアの副業という観点で何か参考になればと思い、執筆のきっかけや動機、副業としての可能性などの考えを書きます。執筆のきっかけ7月上旬にTechpit運営の方からtwitterのDMでコンタクトをいただきました。私が過去にQiitaに投稿したLaravelのチュートリアル記事が、比較的Googleの検索上位であったことが目にとまり、声をかけてくださったそうです。後日ビデオチャットでTechpitというサービスがどういったものであるかの説明を受けた後、今後充実させる必要のある教材について話し合い、Laravelの教材を作成することになりました。執筆することにしたか執筆の動機としては2点あります。何か有料のコンテンツを作成してみたかったが、なかなか書くきっかけをつかめずにいたスタートアップのサービスのこれからの成長に関わってみたかったもともと何か有料のコンテンツを作成してみたかったが、なかなか書くきっかけをつかめずにいたアウトプットの一環としてnoteや技術書典などに何か有料のコンテンツを出したい、という気持ちは前々からありました。有料のコンテンツを出すからにはそれなりの質・ボリュームのものを、という思いもあり、本業やそれに関する勉強のさなか、なかなか手をつけられずにいました。そんな中で今回声をかけてもらったわけですが、Techpitでは教材を章単位で作成し、ひとつの章の作成が完了したら運営の方がレビューをする、というプロセスを繰り返し、教材全体を完成させていきます。各章の作成について納期にあたるものはありませんが、これから作成に着手する章の完成の目処をSlackで伝え、一定の期日感を持って執筆に取り組むことになります。「一人で黙々とコンテンツを作成するよりは、運営の方のレビューを受けながらある程度の締め切り意識を持って取り組んだ方が最終的に完成させられそう」と考え、Techpit向けに執筆することにしました。実際、7月上旬から8月下旬までの2ヶ月間で約100,000字(技術書であればおそらく200〜300ページの規模)のチュートリアルを書き上げましたが、セルフコントロールだけでこの期間にこの量をこなすのは無理だったと思います。スタートアップのサービスのこれからの成長に関わってみたかった上から目線の偉そうな物言いになってしまって大変恐縮なのですが、Techpitはプログラミング学習サービスとして、Progateやドットインストール等と比較してまだ若いサービスです(ローンチしたのも昨年10月とのこと)。サービスの認知度やコンテンツ量もこれから伸びていくのだと思います。いったスタートアップのサービスに微力ながらも実際に自分も関わることで、外部からの1コンテンツ提供者という立場ではありますが、このサービスが今後どのように成長していくのか、強い関心を持つことができるのではと考えました。執筆着手後はSlackにて運営の方々と頻繁にやり取りを行ったほか、ミートアップにも一度参加させていただきましたが、プログラミング学習サービスとしてより良いものにするための今後の展望などを共有してもらえたほか、私からの記事執筆のこと以外の質問にも随時真摯に答えていただけるなど、単に教材を執筆する以上のさまざまな学びや気付きを得ることができました。執筆にあたって留意したこと今回の有料チュートリアル記事執筆では、自分のこれまでの無料記事と比較して以下の点で差別化を図るようにしました。Webサイト上でのサービス登録、インストールなどGUIを使う場面があれば1ステップごとに画面の画像を掲載Techpitで上記のような基準やガイドラインがあるというわけではありませんが、自分個人としてこういった線引きをした上で執筆に取り組みました。教材公開後の売れ行きについて執筆を終えて先日教材を公開したばかりですが、いまのところ連日購入をいただけている状況です。2019副業としての有料チュートリアルの可能性ITエンジニアの副業の一部としては以下のようなものが挙げられるかと思います。2を組み合わせたところがあると私は思っていて、サービスとしてグロース、マネタイズすることは厳しいが何らかのアプリのアイディアを持つエンジニアが、プログラミング初学者でも挑戦できるレベルにアプリをシンプル化した上で、そのアプリの作り方を、個人執筆の技術書レベルの詳細度でチュートリアル化するといったアプローチを取ることで、アプリのアイディア、作成スキルをマネタイズできるのではと思います。無いテキスト形式の教材であるため、相対的に作成着手のハードルが低く、メンテナンスも容易といった点があると思います。Udemyもそれぞれ優位な点があると思いますので、Techpitの方が良いと結論づける意図はありません)Techpitでは、教材の販売と同時に教材執筆者募集も行なっているようです。興味のあるITエンジニアの方向けに募集フォームのリンクを以下に掲載しておきます。docs.google.com最後に以上、副業として取り組んだ有料チュートリアル執筆の振り返りでした。今回の記事がITエンジニアの方々の参考になれば幸いです。最後にPRとなりますが、プログラミング初学者の方でもし興味があれば、ぜひ以下の教材をご覧ください。働き方はじめにWebエンジニアにキャリアチェンジして、3ヶ月が経過しました。今回は直近約2ヶ月間(6〜7月)の振り返りとなります。入社直後にアサインされたプロジェクトを、7月のリリース完了まで引き続き担当しました。(アサイン当初の話はこちら👇)プロジェクト内で担当する領域としては、LaravelによるバックエンドとVue.jsによるフロントエンドの開発となります。様々な機能の実装を行なったのですが、その中で特に印象に残ったこととして以下の3点があります。今回のプロジェクトで作る各画面では、社内外のユーザーの権限やデータの状態に応じて、各データへの参照可否や更新可否を制御する必要がありました。それらをどう実現するか・・・と、Laravelの公式ドキュメントを調べているとGateやPolicyといった認可の機能が見つかったので、これらの使い方を公式ドキュメントで調べながら順次実装していきました。この認可に関しては自らフレームワークの適切な機能を選択して実装することができましたが、他の認可以外の機能に関してはレビュアーから「Laravelではこれこれという標準的な機能があるのでそれを使った方が良い」と指摘を受けることもあったので、フレームワークの様々な機能を幅広く把握しておくことは重要だと感じました。そのフレームワークを選択しているからには、フレームワークの思想や設計に準じて実装していくことが求められる・・・と考えるからです。日頃から公式ドキュメント等でインプットしておく一方で、そのフレームワークでの開発経験が長い周囲のエンジニアに早めに相談して手戻りの発生を抑えるといったことをバランス良く行うことが大切かな、と思います。前述の認可では、ユーザーの権限やデータの状態、操作内容といった可否の組み合わせが多岐に渡りました。そのため、実装漏れが無いよう、いったん対応が必要な箇所をドキュメントに洗い出した上で、順次実装していくことにしました。前職でIT関連の利用部署にいた時は膨大なドキュメントと付き合っており、それに対して現職ではドキュメント作成は必要最低限とする文化にあると思っていますが、この認可の仕様に関しては抜け漏れ防止の面であらかじめドキュメントを整備しておいて良かったと思います。テストコード今回のプロジェクトで、最も重要な機能のひとつが、バッチ処理や画面での入力に応じて金額の計算を行う、というものでした。これに関しては、テスト駆動開発、とまでは行きませんでしたが、金額計算の実装がある程度終わってから、それを追いかけるようにテストコードを書きました。職場の環境では、開発したコードは必ず自動でテストが実行される仕組みになっています。完成した金額計算のコードに新たに追加・修正を行う必要が生じた際も、作成済みのテストがあれば非常に安心感がありました。適切なテストを書いていれば、追加・修正したコードを起因としてこれまでうまくいっていた金額計算に不備が生じる、ということを避けられるからです。「こんな便利なものはもっと早くから書き始めれば良かった・・・」という思いがあり、テストコードを書き始める前の自分を読者として想定して、チュートリアル風の記事をQiitaに投稿しました。こちらがありがたいことに好評で、一時期デイリートレンド1位まで獲得し、200以上のいいねをもらうことができました。社内のSlackでも、トレンド入りを採り上げてもらい、とても励みになりました。2019今後についてそんなこんなで3ヶ月目も経過したのですが、このたび職場で新チーム体制の発表があり、私はSREチームへの配属が決まりました。2019実際には9月からの配属なので、まだSREとしての実務には入っていないのですが、AWS全般AnsibleCI/CDGoなどがキーワードになりそうです。SREには関心があって、いずれはやってみたいとは思ってたのですが、予想外に早くそのタイミングがやってきましたwキャッチアップは非常に大変だと思いますが、SREという考え方や自社のインフラを細部まで把握できる(しなければならない)良い機会となるので、何とか頑張っていきたいと思います。最後に以上、Webエンジニア3ヶ月目の振り返りでした。今後SREや、その他エンジニアとして学びや気づきがあった際にはまた報告したいと思います。働き方はじめに今年5月からWebエンジニアとして働き始めたことを以前にブログでお伝えしました。6月に入り、この1ヶ月でWebエンジニアとしてどんな働き方をしてきたかを簡単に振り返りたいと思います。私は6名ほどのチームに配属になりました。3日程度の間はチームに以前から積み残っていた、比較的優先度の低い改修タスクが割り振られ、それらをこなしていました。その後は、このチームが抱える7月リリース予定のプロジェクトにアサインされ、その開発を行っています。仕事の進め方プロジェクトにおいて開発が必要となる各機能は、GitHub上で一定の粒度でIssue化(課題として登録)されています。(なお、プロジェクトによってはRedmineで管理されています)配属当初はリーダーから各Issueを順次アサインしてもらっていましたが、現在は自分でIssueを選んだり、あるいは把握した要件をもとに自らissueを立てて自分自身にアサインしたりしています。この辺り、ただ与えられたタスクを受け身でこなすのではなく、自ら考えて仕事を組み立ていくことになりますので、一定の裁量があって自分としてはとてもやりやすく感じています。1日の仕事の流れ現在はプロジェクトで「何を作るか?」がほぼ明確になっていることもあり、日々の大半はコードを書いています。だいたい1日に3本程度のIssueに並行して取り組んでいる感じでしょうか。ひとつのIssueに対するコードを書き終え、GitHub上でレビュー依頼をしたら、別のIssueに取り掛かり、依頼したレビューで指摘コメントが入ったら、今度はその対応に着手して・・・といった具合です。コードに充分に触れたくてWebエンジニアという職種を選んだので、この環境にはとても満足しています。2019なお、7月のリリースを終えて次のプロジェクトが始まったら打ち合わせの比重が高まるかもしれませんが、サービス作りの初期から参画できるので、それはそれで楽しみでもあります。書いたコードは、必ず別のエンジニアにレビューをしてもらうルールになっています。今後の保守のしやすさ、読みやすさなど様々な観点から適切なコードが書けているかが厳しくチェックされます。厳しく、とは書きましたが、こうしたコードレビューから私が感じるのは「ダメ出し」のようなネガティブなものではなくて、より品質の高いものを皆で築き上げていこうという前向きなものです。レビューが指摘無く一発で通れば、それはそれで嬉しいものなのですが、経験豊富なエンジニアからの指摘、コメントからは(その後ググって色々調べて得る知識も含めて)多くの学びがあります。(色々と指摘をさせてしまっているレビュアーには申し訳ない気持ちを持ちつつも)指摘、コメントがあれば「ラッキー!」と捉えて、指摘対応に取り組むようにしています。2019なお、レビューでのコメント内容についても辛辣なものにはこれまで出会ったことは無くて、レビュアー側も充分に配慮してコメントしてくれているんだろうと思います。今後について1ヶ月を振り返ると、とにかくLaravel(PHP)のコードを書いていました。Laravelに対する理解は以前よりぐっと深まり、それはそれでとても良かったのですが、裏を返すとLaravelの開発が必要となるIssueにばかり手を出していた、ということでもありました。チームにはフロントエンド(Vue.js)のタスクもごろごろ転がっており、LaravelとVue.jsのどちらも書ける人が多数いますので、自分としても苦手意識のあるフロントエンドに手を出していかなければ・・・と思っています。冒頭に現在は自分でIssueを選んだり、あるいは把握した要件をもとに自らissueを立てて自分自身にアサインしたりしています。この辺り、ただ与えられたタスクを受け身でこなすのではなく、自ら考えて仕事を組み立ていくことになりますので、一定の裁量があって自分としてはとてもやりやすく感じています。書きましたが、だからと言って、易きに流れてはいけませんね。その他生活面Webエンジニアの仕事内容そのものではなく環境面の変化で良かったことになりますが、出社時刻が柔軟なおかげで、こどもの保育園への送りを毎朝担当できています。2019Webエンジニアは、他の職種と比べて勤務形態が柔軟なケースが多いと思いますが、こうした点も転職して良かったと感じています。最後に以上、Webエンジニアとなって最初の1ヶ月の振り返りでした。Webエンジニアを目指している方の参考になれば幸いです。Webエンジニアとなって3ヶ月目にも振り返りレポートを書きました。こちらからご覧ください。02:01Webエンジニアになって1ヶ月が経ちました2019-05-29Webエンジニアになって初めて使うようになったGitコマンド5選Gitはじめに独学でプログラミングを勉強していた頃には全く知らなかったけれど、Webエンジニアに転職してから実務でよく使う便利なGitコマンド/オプションを状況別に5個紹介します。(ブランチ名)を行っても、エラーが出てブランチを切り替えることはできません。こんな時、そのエラーメッセージにも表示されているstashが使えます。stashは、こっそりしまう/隠すといった意味で、自分の作業内容を退避できます。以下コマンドで、作業内容が退避され、別のブランチに切り替えが可能となります。applyを使います。listとすることで、退避した内容を一覧表示できます。次に、ここから取り出したい退避内容を以下コマンドで取り出します。stash@{0}より詳しい使い方は、以下記事が参考になります。直前のcommitを無かったことにしたい以下コマンドで直前のcommitを取り消せます。commitされていた更新ファイルは、addした状態に戻ります。直前のcommitメッセージを修正したい以下コマンドで、commitメッセージが表示されます。--amend表示されたcommitメッセージに対して、以下の手順で修正が行えます。ブランチ名を後から修正したい以下コマンドで現在自分がいるブランチのブランチ名を変更できます。新ブランチ名ブランチ名を英語で付けることが開発チームのルールで定められているけれど、いい感じの名前が思いつかない・・・といったような時に、私は適当な名前でとりあえずブランチを作って作業を開始して、リモートリポジトリにpushするまでには正式なブランチ名に変更する、といった使い方をしています。addを無かったことにしたい以下コマンドでaddしたファイルをaddする前の状態に戻せます。最後にやはりWebエンジニアとして実務に就くと、独学の頃と比較して覚えることの幅は格段に広がります。今回採り上げたGitもそのひとつでした。今回の記事が最近Webエンジニアになった方のお役に立てば幸いです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。