自分の学習スタイルに関する考察
皆さんおはこんばんにちは。ぐーどらです。突然ですがDockerとDocker ComposeでPHPの開発環境を作ってみました。構成は下記です。
近いうちにGitHubリポジトリを公開しようと思います。公開した時はまた別の記事で躓いたところなどを書きたいと思います。
（追記）書きました。
今回の記事は制作物を作った経験を抽象化して、自分の学習方法の最適化と効率化を狙ったオレオレ記事になります。
今回のことを記事に残す理由
独自ドメインとVPSを契約しているので、折角なら自作のアプリケーションをコンテナ化して運用したい思いがありました。
しかし開発職へ転職し初年度であることや職場でDockerを使った開発をしていないなどの要素が合わさり、Docker自体の学習速度が出ていませんでした。
しかし興味本位でData VolumeやVolumeコンテナなどの記事を読み、Docker Composeでの開発環境を自作したことで、Volumeへの理解が急激に進みました。そこで速度が上がった要因を分析しようと思います。
考えられる要因
- 学習のスコープを絞り、Data VolumeとVolumeコンテナのみの理解に努めた
- 概念の理解を深めるために適した良い記事を見つけることができた
- 理解したものを使用して実装する記事も見つけ、実装してみた
今後の学習への活かし方
- 学習する際に網羅的にやろうとしがちなため、学習する対象を絞る（Dockerという漠然としたテーマではなくVolumeに絞ったように）
- 概念的な部分を理解するための記事、書籍などを読む
- 実際に小さいものを実装すると決め、理解を必要とするものから学習を進める
だいぶオレオレ記事でしたが、以上のことを今後活かして学習を進めていきたいと思います。
ストレングスファインダー
みなさん、おはこんばんにちは。お盆は中4日がまるごと会社が休みだったため、嬉々として引きこもっていました。ぐーどらです。
さて、本日少しTwitterでつぶやきましたが、ストレングスファインダーやりました。結果とその注意点を自分用に纏めて今後の指標にします。
ストレングスファインダーとは
tbさんがわかりやすく纏めてくださっているので、説明は割愛します。
ぐーどらの強み5つ
割と納得したものばかり。
目標志向
「目標志向」の資質が高い人は、目標を定め、その目標に向かってまい進し、目標達成に必要な修正を行うことができます。優先順位をつけてから、そのとおりに行動します。
目標が明確に定まっているときはとても調子がよく、逆にブレると行動できない部分もあり、納得感が高いです。書籍に書かれていた部分で、無駄と思った行動をしないと書かれており、正に現状そうした生活を送っていました。
共感性
「共感性」の資質が高い人は、自分を相手の状況に置き換えて考えることにより、相手の感情を察することができます。
🤔🤔🤔
未来志向
「未来志向」の資質が高い人は、未来と未来にできることを心に描くことで、ひらめきを得ます。未来についてのビジョンを語ることで、人々にエネルギーを与えます。
現状に対し、〜であったらいいなと思えることを割とすぐに思いつきます。現状より良い状況や未来を夢想し、それを目指すところがあると思います。
内省
「内省」の資質が高い人は、知的な活動に多くの時間を費やします。内省的で、知的な議論が好きです。
これも納得したのですが、割と頭を使って何かを考えている時間が好きです。内省の資質を持つ人は方向性は問わず頭を使うことが好きという文で言い当てられている感が強くなりました。
達成欲
「達成欲」の資質が高い人は、並外れたスタミナがあり、旺盛に仕事に取り組みます。自分が多忙で生産的であることに、大きな満足感を得ます。
これも当たっているなと思ったのですが自分自身が生産的であることや何かを成し遂げていることを追い求めています。また、自分がチーム内や組織内で生産性の低い状態でいることを心底許せません。
行動アイデアから見える指針
- 私生活でも目標を設定する（目標志向、達成欲、未来指向）
- 量と質を考慮した目標、基準の設定（目標志向、達成欲）
- 言葉以外のことも使って人を安心させる（共感性）
- 未来志向の考え方を論理的に裏付けるようにする（未来志向）
- 知識を得るために学習をする（未来志向、達成欲）
- 考える時間をスケジュールに入れる（未来志向）
雑感
物凄く成長欲に傾倒していそうな結果だと思います。昔からたまに向上心があると言われる理由が少し知れた気がしました。
結果が出てから思うところとしては、成長した先で何をするかが大切と一般的に言われますが、あまりピンと来ることがなく成長欲だけ先行していました。かと言ってなにかを成し遂げたいと思っていたことは転職前まではありませんでした。
笑ったのは、目標志向の資質を持つ人との接するときの注意点で上がっていたのが「この資質を持つ人は自分の目標を優先する際、他人の気持ちに対しての配慮に欠ける」というようなことが書かれていました。共感性も持ち合わせているため、他人の感情を理解しつつも踏みにじっていく冷徹さが出る場合があります。少し自覚があり、ゲームなどで勝敗がかかる場面ではプレイスタイルに遺憾なく現れます。
全体的に「あ〜」と思うところがあり、仲の良い友人からも「らしい」とお墨付きをもらいました。各資質の解説には行動のアイデアが書かれており、資質を伸ばすためのアイデア集のようなものが載っています。資質の解説だけではなくアイデアも十分今後に活かせそうなことが書かれているため、とても満足感が高い書籍でした。今後は先に載せた指針を私生活に活かしていこうと思います。
Vagrant上にaglioをインストールしようとしてどハマリした話
皆さんおはこんばんにちは。ぐーどらです。
転職エントリー書こう書こうと思っていながら、なかなか指が動きません。明日から本気出す( ˘ω˘)
本日てっぺんを回った電車に乗っている理由
aglioのインストールにどハマリしました。
最近はAPIの開発を任されています。「取り敢えず実装しました。あとはぐーどらさん任せた」な感じで振られてやってますが、既に9割書き換えました。
仕様書も無いので、手っ取り早く作りたいと思い、ググったところ、Markdownで書けるAPI Blueprintなんてものがあるじゃないですか…素敵…ということでaglioをインストールしようという流れでした。
環境
はい、散々こき下ろしているWin10 Homeなので、今回のaglioはVagrant上にインストールしようとしてやろうと思いやっていました。
使っているOSイメージはbento/ubuntu-18.04です。だってUbuntu使いたかったんですもの
踏んだエラーその1
node.jsのインストールを済ませ、おや？n packageなんてあるぞ？ということでglobalインストールしたくなるじゃないですか…
そうしたら出てくるわけですよ…
ふむ。どうやら共有フォルダを作ってる影響でエラーが出てるのだな…ということは、Vagrantfileの共有フォルダ設定を一度コメントアウトしてvagrant reloadすれば良いのでは…？
ということでyarn global add aglioするわけですよ。ここで終わりではなかった…
踏んだエラーその2
は〜Vagrantにシンボリックリンクが作成できない罠があるなんて知らんよ…な気持ちでコマンド叩くじゃないですか。そうしたらまたなんか出るわけですよ。
ほう…依存関係の解決が出来ていない…ほう…
というわけでググります。しかしこれはいくらググっても出てこず。そもそもyarn whyしても怪しい依存ライブラリなんか出てこないんです。
そうしてようやく辿り着いたどこかの記事に「node.jsを8系まで落としたらライブラリ入れられました！」なんて記述があったのでした。内心（まさかね…）なんて思いつつ、node.jsを8系まで落とし、yarn add したら、遂にインストール出来たんですよ。
まとめ
時間も時間なんでちょっと文章がポエミーになってますが許してください。node.jsとyarnとnとaglioのインストールだけで3時間取られたんです。泣きたい。
因みにnode.jsが最新版な理由はnをインストールしてから最新版にしていたからです。泣きたい。
最後に、インストールが全て終わってからaglioのリポジトリを見たらDockerイメージの文字がありましたとさ( ˘ω˘)
軽率に1on1を受けたらとても凄かった話
みなさんおはこんばんにちは。ぐーどらです。先日ひょんなことから腕立て伏せをやることになり、膝つきで10回やったら胸筋と背筋がバキバキになりました。どう見ても運動不足です。本当にありがとうございました。
軽率に1on1を頼んでみた。
さて、本日は軽率に1on1をお願いしたらとても悩みがスッキリしたので、備忘録とお礼を兼ねて記事を書こうと思い立ちました。
今回マネージャー役として来ていただいたのは株式会社ゆめみのエンジニアリングマネージャー、果物リンさんです。
僕が軽率に1on1して頂きたいとつぶやいた直後くらいに、リンさん自身が「1on1してもらいたい人いるかなあ」とつぶやかれていたので、軽率に依頼させて頂きました。
結論から言うと最高オブ最高で、自分の中で全く出口が見えなかった悩みが綺麗にリファクタリングされてしまいました。リンさん本当にマネージャー歴半年ですか？
解消したこと
今回の1on1で相談した題材は2つあり
- 市場価値の高いエンジニアになるためのアプローチについて
- 転職活動を開始する時期について
です。終わってから考察してみると一人で考えていた時には要因を正しく分解分析できていなかったことと、自分が持っている視点が足りていなかったために深みにハマっていたようです。
市場価値の高いエンジニアになるためのアプローチについて
今現在の僕はある程度のキャリアプランを持っているのですが、そのプランは僕のロールモデルとなる方々を参考にしています。そしてその人達の共通項として、「自分で仕事を選べる、もしくは作れる」という状態が共通していることから、10年後には自身がその状態になっていることが現在の目標です。その目標から逆算し、2021年以内にはフルスタックな経験を積んだエンジニアになっていることを今までマイルストーンとしていました。
逆算の仕方としては非常に大雑把なのですが、仕事を選べる状態=市場価値の高い状態=フルスタックエンジニアという考え方を以前しており、今日までその考えを疑うことをしていませんでした。
しかし今回の1on1によりまず一つ目のパラダイムシフトが発生し、そもそも市場価値の高い状態=フルスタックエンジニアではない、という視点の変化が発生しました。フルスタックな経験そのものは市場価値の高い状態の1要素でしかなく、市場価値の高い状態には考えの至っていない要素が他にあるという気付きを得ることができたのです。
1on1により明らかになった当時僕が考えていた市場価値の高い状態は「バイネームで仕事を紹介してもらえるようになっていること」であり、フルスタックなエンジニアという中間目標では、最終目標に対しての最適なアプローチではないということを気づかせてもらえました。今回の1on1により目標に対するズレと考えが足りていない要素を認識させてもらったことで、僕の考える市場価値の高い状態へのアプローチをより視野が広いものへと再設定することができました。
また、1on1をしてもらってから気がついたのですが、市場価値の高い状態に「有名であること」という視点が抜け落ちており、それを認識＆可視化してもらえたこともとても凄いと感じました。
現職を転職する時期について
こちらのテーマは最近特に悩み化していた状態で、一人で時間を使ったり友人に相談したりしつつも納得の行く答えにたどり着けていなかった状態が1on1前でした。
葛藤していたポイントを纏めると、最近の業務を通して感じる成長感があまり無いため、成長感を感じることのできる環境へ転職をしたいという欲求に対し、現職も不満ばかりではなく自分に合っている部分もあると感じていることもや、転職をしてから半年という短い期間での再転職を行うことへのリスクもあることから今後どのように行動をしていくのか決めかねる状況でした。
こちらの悩みについてのパラダイムシフトはそもそも現職に対する合う合わないの価値基準は入社前に良く調べ上げることでほとんど解消出来る条件ばかりであるという視点を得られたことです。転職活動を行う際のリスクについても自身の行動次第でリスクヘッジが可能という気づきを得ることが出来たため、後はリスクを取り行動をするのかしないのかという選択まで落とし込むことが出来ました。
また今回の1on1では勉強会に参加することは書類に書ける具体的なアクションである気づきを得ました。「勉強会に行くエンジニアの数を社内のエンジニアの人数で割ってみなよ。10%くらいじゃない？」と言われ実際に数えたところ、確かに現職では10%を切っていました。（自分以外に勉強会に行く人を聞いたことがなかったため、厳密には参加している人もいるかも知れませんが）僕個人が勉強会に参加する大きな理由の一つは自分より歳下で経験豊富な人材は数多くいる事実を強く認識しているからで、要は「現状自分の市場価値は最底辺クラス」と思っているためです。自分で設定するキャリアプランの達成のためには効率よく学習を行う必要があり、その一つの手段が勉強会に参加することと考えていたため、他人と比較して珍しいことをやっている自覚は全くありませんでした。
リンさんの1on1ここが凄かった
御本人には1on1して頂いた後のアンケートを既に提出したのですが、改めて考えてみるとさらに良いところを幾つか思いついたので、改めて掲載させていただきます。
- リンさんの傾聴スキルが高く、発言に対し「否定されているかも？」と感じることが全く無かった。
- あらかじめある程度の関係性を築けていた前提と的確な質問を投げかけられたことにより、ポイントとなる僕個人が大切に感じている価値観であったり、考え方を1on1の場ですんなりと言語化することが出来た。
- 要所要所で「大切なポイントですね」「わかるぅー」などの承認的な態度を取って頂けたため、発言に対しての心理的ハードルがどんどん下がっていった。
- こちらの反応を見て発言してもらえるタイミングがありながら、発言を遮られたと感じる場面はなく対話のテンポがとても良かった。
- 転職に関する知見が凄く、発言のタイミングが良いことも重なりとてもスムーズに内容が腹落ちした。
受けてみた雑感
…本当にマネージャー半年です？（2回め）良く考えていることではあったのですが、感じていることを何かに書き出す、具体的な要素に分解していくというプロセスを実行することはとても思考の整理に繋がると再認識も出来ました。今後思考のアウトプットに詰まったらフリーハンドでもノートに書き出すという具体的な行動として日常に取り込んでみようと思いました。
リンさんの1on1すごいぞ
具体的なアクション
- 7/21期限でスキルシートと職務経歴書の用意。
- T字型人材（専門を持ちつつ責任範囲以外のことを知っている状態）を目指すことと有名になるという視点を忘れない
というわけで転職やっていき勢化しました。転職エントリーに関しては別記事で記載することにします。それではまた～。
オライリーのDockerがDocker入門書に最適だと思いこんでいたら思い切りはしごを外された話。
みなさんおはこんばんにちは。ぐーどらです。
先日こんなやり取りをしました。
知り合いの方「みんな転職したほうがいいと思ってる」
— ぐーどらくらんち (@gulDra_cranch) 2019年6月26日
僕「」 #phpstudy
その時はゲラゲラ笑っていただけなのですが、最近ツイートで見かける他社環境や参加する勉強会での話を聞いているうちにどんどんと他社さんの環境やプロダクトに使われている技術スタックが羨ましくなってきました。そこで転職活動するだけならタダだし動いてみるのもありじゃない？という助言に乗っかり、先日エージェントに登録しました。来週からエージェントさんとちょこちょこやり取りを行い、自分の市場価値を測りに行こうと思います。
因みに前々から続いている社内改善シリーズを楽しみにして頂いていた方は申し訳ございません。今週はGitLabが手付かずになってしまい、進捗出ませんでした。なので、今週の記事は個人で学習している内容になります。
ところでDockerにもう一度入門した
Dockerなんもわからん勢なので、改めてDockerを使い物にすべく学習し始めました。なんもわからん。
僕はネット記事を漁った結果、なんもわからんになりました。そこで次に行き着くのはやはり本ということで、今回購入したのはオライリーのDockerでした。
ちなみに実はもう一冊Dockerの書籍は購入していて、こちらの書籍は持っている状態でした。
「Docker/Kubernetes 実践コンテナ開発入門」を読んでみて、さらに別の書籍が欲しくなった理由としては
- 内容が実践的すぎ、ネット上にあるDockerを使った開発環境のリポジトリを見てもなぜそのような構成にしているのかわからない場合が多々あった
- どちらかというと実践的なハンズオン形式の書籍であったため、もう少し基礎的な部分から理解を深めたいと思った
などを感じており、一言に纏めると「Dockerを使うにあたり、Dockerに関する正しい知識が欲しかった」ということです。Dockerなんもわからん。個人的な技術書に限った好みはある程度傾向が見えてきており、
- 扱っているものの情報がある程度網羅されている
- 項目で羅列可能なものが羅列されている。（Dockerの場合はDockerfileに記載する命令などは一覧で見たくなる）
こういう教科書的な使い方ができる書籍だと相性が良いようです。ジュンク堂書店 渋谷店で購入したのですが、置かれていた書籍でこれを満たしていた書籍はオライリーのDockerだけでした。
オライリー本にはジョークもあった
はい、オライリーと言うと身構える方が多数いらっしゃると思います。僕も身構えていました。この本の3章を読むまでは。1章はDockerの歴史的背景、2章はインストール方法についてなので、実際に手を動かすのは3章からです。
OK、それでは新たに、実際に取っておく有益なコンテナを構築しましょう。生成するのは、Docker 化された cowsay アプリケーションです。もしも cowsay が何かを知らばければ、覚悟を決めることをお勧めします。
という仰々しい前振りから始りますが、実際に構築させられるアプリケーションはこれ。
おい。オライリー。おい。
しかもご丁寧に注釈で
ええと、有益と書いてはみましたが、厳密には正しくないですね
と書かれていました。オライリーとは思えないフレンドリーさがあり、少し手を動かすのが楽しくなりました。
オライリー本の罠
オライリー本でも意外にジョークが入ってたりするんだと思いながら手を動かし、5章に入ります。
しかし最初のコンテナのビルドに失敗します。なぜだ。Docker logsコマンドを使った結果、Pythonのコードで、インデントが間違っている模様…
幸いにも書籍内にGitHubにリポジトリを用意している旨が記載されていたので、コードを見比べた結果、解消できました。
from flask import Flask （インデント）app = Flask(__name__)
どうやらこの箇所のインデントが間違っていたようです。
しかし問題はそれだけではなかったのです。さらに進めるとまたビルドが通らなくなります。色々調べてもよくわからなかったのですが、Pythonのベースイメージのバージョンを一つ落とすとビルドが通るように。しかしその状態でもアプリケーションを動かしてもHTTP 500ステータスが返ってくるという散々な目に。おい。オライリー。おい。
散々なことを書きましたが、一応フォローすると、Dockerについて手を動かすという目的は達成できているので、まあ良しとします。動かすアプリケーションもHello World を出力させるだけなので、特に気にしてもしょうがないという気持ちにもなりました。
雑な感想
- オライリーでもコードが間違っている場合はある＝書籍だからといって鵜呑みにしてはいけない。最後は地に足の着いた知識が役に立つ。
- Dockerについての知識は着実についているため、コードの質はともかく、内容については満足している。エラーを気にしなければ手を動かして覚えるにはやはり最適解。
今回は短い記事ですがこんなところで！ではまたよろしくどうぞ～。
自社のVCSがGitLabで確定した話
みなさんおはこんばんにちは。ぐーどらです。
今週は飲み会や勉強会に伺った際に「辛いブログの方…」でしたり「早く転職したほうがいい人！」と認知して頂いているのだなぁと実感することが劇的に増え、ありがたみを噛み締めました。認知頂けることは現状とても嬉しいです。
今週木曜日（6/21）にはLravel.shibuyaにお邪魔していました。
今週やってたこと
GitLabインストール
先週金曜日、めでたくGitHubEE導入が確定したかのように思われましたが、今週月曜日に出社したところ「GitHubEEを導入すると言ったな。あれは嘘だ」を体験しました。やはりコストがネックになったようです。一人$21/月はキツいですね。
しかし偶然にも先週金曜日の業務後に伺ったYYPHP（ありがとうございました！）でGitHubを無料で使えるようにしたGitLabというソフトウェアがあると聞いていました。月曜日に移行作業のイの字も始まらなかったため、火曜日にはGitLabを提案、水曜日には社内のサーバーが用意されており、構築から導入作業を一任されました。
突然のYYPHPさん宣伝。
GitLabのインストールについては公式を参照していましたが、その途中で公式はCE版でなくEE版のインストール手順が書いてあるので注意というQiita記事を見つけ、慌ててCE版に手順を切り換えるという漫画みたいなことをしていました。
社内向け資料作り
特に言われたわけではないのですが、案外Gitの使い方に慣れている人が少なさそうな気配だったので、察して作り始めました。自社内での導入後の運用に沿ってこういう手順でやりますという尖らせなた内容にしました。
久々の開発タスク
回ってきました！（とても嬉しい）しかも権限系なので重要な部分。きっちり綺麗に実装したいです。
その他雑多なこと
GitLabのこと
OSS版GitHubとも言われるVCSで、機能が充実していていいですね。GitHubのプルリクエストには標準でCIが実施されテストの実施が推奨されていますし、権限設定も非常に細やかに設定できます。なによりUIがとてもわかりやすく、自社製品でも参考にできるような部分が多くありそうです。この辺もいつかちゃんと記事にしたいです。
今後のこと
めでたくGitLab導入がほぼ確定したので、今後はよりCIやCDの実装もやっていけそうです。目指せモダンな開発現場。少しググった程度ですが、最近書かれた記事が多くあり情報不足に陥ることも無さそうで安心しました。というわけで恒例の今後のタスク。
- 自社のプロジェクトのGitLab移行作業の手伝い。Slack連携はしておきたい。
- 自社プロダクトの開発。
- RPAに関連する技術に触れる。少なくとも言語はRuby。
- 個人では買ったオライリーのDockerを進める。
自社からは結構骨太なタスクが回ってくるようになりました。特に今までやったことない言語での仕事ができそうなのは嬉しいです。早く機能実装して、Rubyの言語仕様も一通り目を通したいところです。
個人的なスキルではDockerを使い物になるようにして、早くなんかアプリケーションの土台として使いたいところ。
自社のVCSをSVNからGitHubへの入れ替えを提案した話
みなさん、おはこんばんにちは。ぐーどらです。
既にTwitterで呟いたのでご存知の方も多いと思いますが、GitHub使用許可が社長から出ました。OK出たときは入社後イチでテンション上がりました。
今回はどうやって経営層を説得したのか、そして導入後のタスクの整理を書いていきたいと思います。
ぐーどらのつらたみシリーズはこちら↓
説得するにあたり
デプロイ時に大変時間がかかっている問題があり、その要素は主に3点ありました。
どう考えても辛い（2回目）
上記のような状態だったので、GitHubを入れるだけで大分デプロイ前に作業が集中することが無くなるのでは？という予想が立っていました。
- プルリクエストの通知をSlackに出すことにより、差分確認を通常業務中に分散可能
- ソースコードの反映はアップロードではなく、git pullのみのため、人為作業の取り間違えポイントはブランチの選択程度になる
- ブランチのマージ履歴を追えば、管理している機能が本番環境とステージング環境のどちらに反映されているいないが視覚的にわかる
- CIツールが使え、テストコード自動実行と自動デプロイが出来るため開発スピードが上がる
データベーススキーマの課題は残りますが、導入するだけでも上記のようなメリットがあり、正直これだけでも説得出来るのでは？と思っていました。
現実は甘くなかった
GitHubを提案したところ、下記のような課題もあがってきました。
- Gitを自社で運用して来なかったため、ブランチの運用方法がわからない
- ブランチ毎へのマージやコミットの権限設定は出来るのか
提案当初に用意していたブランチ運用モデルはGit flowだったのですが「機能毎の部分的なリリースが難しい」という問題が浮上し、Git-flowは諦めることに。
そこで次に提案したのがGit feature flowです。
ブランチモデルはgit feature flow、gitクライアントにSourceTreeを使うことでどの機能がどのブランチにマージされているのか、漏れていないのかが視覚的に確認できるようになります。
運用モデルとSourceTreeを引っさげて社内でミーティングを組みました。布陣はCTOを説得する布陣。
- CTO(GitHub否定派)
- 自分(多分社内でGitHub一番入れたい人)
- PM(頭が良く、チケットの切り方が抜群な人。以前からGitHubにしたかった)
- 元SIerさん(ぐーどらより1ヶ月後に入社。CTOの手動デプロイを手伝っている被害者)
禄に使えもしないPowerPointで図説しながら、git feature flowなら現状より相当便利&管理ができるようになる旨を訴えました。
結果ミーティングが終わり、CTOから社長へ打診いただいたようです。
「社長がコードをホスティングするのは駄目だと言っていたので、ローカルのGitになります」
(´；ω；｀)ﾌﾞﾜｯ
「なのでGitHub Enterpriseになりそうです。高いけど」
…
……
…………………
( Д ) ﾟ ﾟ
というわけで前向きに検討いただけるようになりました。良かった。（まあ今日仕事に行ったら、移行作業のイの字も出てこなかったので不安は残りますが…）
次の課題点
環境の更新作業で人の手が残っている部分として、次に着手すべきはデータベース更新かと思っています。本番環境に手作業でupdateなんて誰も叩きたくないですもん…
ということで、先週金曜日に参加してきたYYPHPで欲張って聞いてきたマイグレーションツールの導入を目指します。（今日ジャブを打ったらとことん打ち返されました…泣きたい）
あとは前々から考えていたCIツールですね。GitHubEnterpriseなので、ローカルにインストールしないとだめと言われそうなので、GitLab CIでほぼ確定な気がしています。
というわけで自分が見やすいように自分のタスクを纏めます。
- 引き続きcodeceptionのテストコードを書く
- 新しくアサインされたRPAプロジェクトの技術取得
- GitHubもしくはGitLabへの移行誘導（運用が面倒くさいという部分は強調する）
- 移行後CIツールを入れ、テスト自動実行化&Slack通知出来るようにする
- マイグレーションツール導入のための布石を打つ（不可ならmigrationテーブル作成案を提案）
それにしても手作業が多すぎる。今日もデプロイ作業が手作業故に、本番環境で権限関係のエラーが顧客から連絡入ってしまったんだけどなあ…IaC化して構築も人の手をなるべく介さないようにしていけたらと切に思います。少しずつ体制を変えていけたら転職のネタにもできるようになると思うので、引き続き頑張りたいですね。
本日のオチ
元SIerさんは前職でCOBOLを書いていたそうなのですが、その人からデプロイに関して一言。
「デプロイは前職より酷い」
