酒と開発の日々

飲酒大好き駆け出しエンジニアのブログ

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インストールしたくなるじゃないですか…

そうしたら出てくるわけですよ…

qiita.com

ふむ。どうやら共有フォルダを作ってる影響でエラーが出てるのだな…ということは、Vagrantfileの共有フォルダ設定を一度コメントアウトしてvagrant reloadすれば良いのでは…?

ということでyarn global add aglioするわけですよ。ここで終わりではなかった…

踏んだエラーその2

は〜Vagrantシンボリックリンクが作成できない罠があるなんて知らんよ…な気持ちでコマンド叩くじゃないですか。そうしたらまたなんか出るわけですよ。

qiita.com

ほう…依存関係の解決が出来ていない…ほう…

というわけでググります。しかしこれはいくらググっても出てこず。そもそもyarn whyしても怪しい依存ライブラリなんか出てこないんです。

そうしてようやく辿り着いたどこかの記事に「node.jsを8系まで落としたらライブラリ入れられました!」なんて記述があったのでした。内心(まさかね…)なんて思いつつ、node.jsを8系まで落とし、yarn add したら、遂にインストール出来たんですよ。

これでようやくAPI仕様書をMarkdownで書ける…

まとめ

時間も時間なんでちょっと文章がポエミーになってますが許してください。node.jsとyarnとnとaglioのインストールだけで3時間取られたんです。泣きたい。

因みにnode.jsが最新版な理由はnをインストールしてから最新版にしていたからです。泣きたい。

最後に、インストールが全て終わってからaglioのリポジトリを見たらDockerイメージの文字がありましたとさ( ˘ω˘)

軽率に1on1を受けたらとても凄かった話

みなさんおはこんばんにちは。ぐーどらです。先日ひょんなことから腕立て伏せをやることになり、膝つきで10回やったら胸筋と背筋がバキバキになりました。どう見ても運動不足です。本当にありがとうございました。

軽率に1on1を頼んでみた。

さて、本日は軽率に1on1をお願いしたらとても悩みがスッキリしたので、備忘録とお礼を兼ねて記事を書こうと思い立ちました。

今回マネージャー役として来ていただいたのは株式会社ゆめみのエンジニアリングマネージャー、果物リンさんです。

twitter.com

僕が軽率に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入門書に最適だと思いこんでいたら思い切りはしごを外された話。

みなさんおはこんばんにちは。ぐーどらです。

先日こんなやり取りをしました。

その時はゲラゲラ笑っていただけなのですが、最近ツイートで見かける他社環境や参加する勉強会での話を聞いているうちにどんどんと他社さんの環境やプロダクトに使われている技術スタックが羨ましくなってきました。そこで転職活動するだけならタダだし動いてみるのもありじゃない?という助言に乗っかり、先日エージェントに登録しました。来週からエージェントさんとちょこちょこやり取りを行い、自分の市場価値を測りに行こうと思います。

因みに前々から続いている社内改善シリーズを楽しみにして頂いていた方は申し訳ございません。今週はGitLabが手付かずになってしまい、進捗出ませんでした。なので、今週の記事は個人で学習している内容になります。

ところでDockerにもう一度入門した

Dockerなんもわからん勢なので、改めてDockerを使い物にすべく学習し始めました。なんもわからん。

僕はネット記事を漁った結果、なんもわからんになりました。そこで次に行き着くのはやはり本ということで、今回購入したのはオライリーのDockerでした。

www.oreilly.co.jp

ちなみに実はもう一冊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にお邪魔していました。

laravel-shibuya.connpass.com

今週やってたこと

GitLabインストール

先週金曜日、めでたくGitHubEE導入が確定したかのように思われましたが、今週月曜日に出社したところ「GitHubEEを導入すると言ったな。あれは嘘だ」を体験しました。やはりコストがネックになったようです。一人$21/月はキツいですね。

しかし偶然にも先週金曜日の業務後に伺ったYYPHP(ありがとうございました!)でGitHubを無料で使えるようにしたGitLabというソフトウェアがあると聞いていました。月曜日に移行作業のイの字も始まらなかったため、火曜日にはGitLabを提案、水曜日には社内のサーバーが用意されており、構築から導入作業を一任されました。

突然のYYPHPさん宣伝。

yyphp.connpass.com

GitLabのインストールについては公式を参照していましたが、その途中で公式はCE版でなくEE版のインストール手順が書いてあるので注意というQiita記事を見つけ、慌ててCE版に手順を切り換えるという漫画みたいなことをしていました。

qiita.com

社内向け資料作り

特に言われたわけではないのですが、案外Gitの使い方に慣れている人が少なさそうな気配だったので、察して作り始めました。自社内での導入後の運用に沿ってこういう手順でやりますという尖らせなた内容にしました。

久々の開発タスク

回ってきました!(とても嬉しい)しかも権限系なので重要な部分。きっちり綺麗に実装したいです。

その他雑多なこと

  • 新規顧客に向けたリリースが8月に控えているので、テストの要因としてもアサインされテストの実施
  • 相変わらず一人テストコード
  • 新規にRPAのプロジェクトにアサイン&ミーティング参加

GitLabのこと

OSSGitHubとも言われるVCSで、機能が充実していていいですね。GitHubのプルリクエストには標準でCIが実施されテストの実施が推奨されていますし、権限設定も非常に細やかに設定できます。なによりUIがとてもわかりやすく、自社製品でも参考にできるような部分が多くありそうです。この辺もいつかちゃんと記事にしたいです。

今後のこと

めでたくGitLab導入がほぼ確定したので、今後はよりCIやCDの実装もやっていけそうです。目指せモダンな開発現場。少しググった程度ですが、最近書かれた記事が多くあり情報不足に陥ることも無さそうで安心しました。というわけで恒例の今後のタスク。

  • 自社のプロジェクトのGitLab移行作業の手伝い。Slack連携はしておきたい。
  • 自社プロダクトの開発。
  • RPAに関連する技術に触れる。少なくとも言語はRuby
  • 個人では買ったオライリーのDockerを進める。

自社からは結構骨太なタスクが回ってくるようになりました。特に今までやったことない言語での仕事ができそうなのは嬉しいです。早く機能実装して、Rubyの言語仕様も一通り目を通したいところです。

個人的なスキルではDockerを使い物になるようにして、早くなんかアプリケーションの土台として使いたいところ。

自社のVCSをSVNからGitHubへの入れ替えを提案した話

みなさん、おはこんばんにちは。ぐーどらです。

既にTwitterで呟いたのでご存知の方も多いと思いますが、GitHub使用許可が社長から出ました。OK出たときは入社後イチでテンション上がりました。

今回はどうやって経営層を説得したのか、そして導入後のタスクの整理を書いていきたいと思います。

ぐーどらのつらたみシリーズはこちら↓

説得するにあたり

デプロイ時に大変時間がかかっている問題があり、その要素は主に3点ありました。

  • ソースコードの全差分確認をデプロイ直前に行う
  • SCPソフトによる手動アップロード
  • データベーススキーマ変更も手作業

どう考えても辛い(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を書いていたそうなのですが、その人からデプロイに関して一言。

「デプロイは前職より酷い」

社内の環境を徐々に変えていこうと動き出した話

みなさんこんにちは。ぐーどらです。

前回自社の辛み記事を上げ、やっていき!なことを整理し、一週間取り組んできたことを報告しようと思います。

前回記事↓ guldra-cranch.hatenablog.com

一週間でさらにやったこと

  • とりあえずテストコードを更に実装
  • 先の記事で上げた手動デプロイでは具体的にどんな作業が発生しているか同僚に聞いた

テストコードを実装

相変わらず続けてます。一通りのページで動作不良を起こしていないか、機械的な正常系テストを書き上げました。

ここからさらに個別のページで使えるよう、便利な動作をしてくれるようなコードを書き上げていけば、日々の業務が楽になるかなと思っています。

先の記事で上げた手動デプロイでは具体的にどんな作業が発生しているか同僚に聞いた

自分の中ではある程度整理できているつもりでしたが、やはり実際に作業をしている人にどんな作業が発生しているかを聞いてみると、更に違った状況が見えてくるものだと思いました。

弊社手動デプロイ苦行3ステップ

  • 開発環境とデプロイ先環境の差分比較
  • バックアップ取得
  • SCPソフトによる手動アップロードや各種コマンド実行

差分比較

開発環境とデプロイ先環境の差分比較自体は必要な作業だと思います。が、ソースコードがコミットされる毎にはレビューを行っておらず、デプロイ前にまとめて差分比較&確認するという苦行が発生していました。

当然テストコードも存在していないため、SVNにコミットされているソースコードの正当性を誰も保証できていない、けれども目視しアップロードするという作業が発生しています。つらい。

バックアップ取得

社内にあるUSB3.0接続の外付HDに、デプロイ前の環境に配置されていたコードを全てコピーする作業をされていました。

SCPソフトによる手動アップロード&各種コマンド実行

デプロイ先のパスから、アップロード前のファイル、アップロード前のファイルのパスから大半の確認を経てアップロードが行われます。

どう考えても辛い

考えた解消法

どう考えてもGitHubですね。考えた理由は4つです。

  • バックアップ作業が不要になる
  • 手動アップロード作業がなくなりワンコマンド化
  • プルリクエストで差分比較とコードレビューを行うことでデプロイ前に集中した差分比較を通常業務に組み込むことが可能
  • 近況のデファクトとされるCIツールのソースコード管理はGitHubであり、CIツールを使うことで業務フローの改善に繋がる

以上の理由をもって、月曜日に同僚と共にCTOや経営層の説得にかかろうと思います。

自社の辛みが見えてきた話

みなさんこんばんは。ぐーどらです。

6月ですね。1月7日からエンジニアしてるので、まるまる5ヶ月経ったことになります。感慨深い。これくらい働いていると、あれだけいい会社だと思えていた自社にもいくつか不満点が出てくるわけでして、この前ついついTwitterで聞いてみてしまいました。

反応もいただき、やはりつらたみは様々な人と共有するといいのかもと思ったので、記事にしていこうと思います。オラワクワクしてきたぞ!

さーて、先週のぐーどらさんは!

f:id:guldra_cranch:20190601071933p:plain

  • 私だけがテスト書いてどうすんだ
  • やはりそのデプロイ先は間違っている
  • この素晴らしいAWSに祝福を!

私だけがテスト書いてどうすんだ

前回の記事に経緯を書いたとおり、1人でcodeceptionの導入を行いました。

guldra-cranch.hatenablog.com

先週も1人で受け入れテストを書いていました。

そう、1人で。おかげで僕はcodeceptionのSeleniumを使うブラウザテストに対しての知見は少しずつ溜まってきました。が、それは社内に僕1人なのです。

自動テストを運用するようになったとしても、メンテナンスする要員が自分一人になりそうな予感がプンプン…さらに自分自身がテストを書いた経験が豊富ではないことも重なり、(本当にこういうテストでいいのか?)という疑問が常に付き纏っています。

どう実装するのが正解なのかわからないため、プロジェクトにとって有益なテストコードをかけているのか、自社に対して有益なコードを書けているのかとても不安になります。

どうすべきか

とりあえず単体テストと機能テストは諦めました。単体テストはそもそも書けるコードになっていないですし、機能テストはそもそも私自身が書き方がわからないためです。

そのため設定と実行環境を整えられれば簡単に走らせることができるweb driverを使う受け入れテストを書くことにしました。

それだけでも結構バグを見つけられるようになっており、テストやってよかったと実感します。なにより回帰テストの時間=テストコードの実行時間なのもいいですね。

しかし、この状況からテストコードを全員でメンテナンスする文化にする問題は、明らかに自分だけでは解決できない問題なので、まずはコミュニティに頼ることにしました。6/14にYYPHPにお邪魔して、テストに関しての知見を伺おうと思います。

あとは月並みですが、テストに関する書籍やQiitaの記事をあたろうと思います。

あとは現状の1人で実行している状況がまず辛いので、CIツールをプロジェクトに導入してもらえるよう働きかけていきたいと思います。

やはりそのデプロイ先は間違っている

はい、弊社ではCIツールが使われていません。Jenkinsでさえも。

デプロイ方法はscpソフトによる手動です。言語がPHPであるため、静的webサイト感覚でデプロイ出来てしまうのが仇となりました。

走っているプロジェクトは複数ありますが、自社開発ゆえ使われているフレームワークは1つ。つまるところ、複数あるプロジェクトが同じディレクトリ構成で、全く違う内容で同じ名前のファイルが存在したりする環境を手動で選び、デプロイする作業が発生します。

入社当初は2ヶ月くらいはアップロード先が違う!を何回やらかしたことか、、、

あと開発環境からステージング環境、本番環境へのデプロイも手動なの結構笑えません。せめてバージョン管理をSVNからGitにして、マージしません、、、?差分比較も別のツール使わずに、GitのGUIクライアントで出来ますよ…

どうすべきか

CIツールだ。入れさせよう(血眼

CircleCIならSVN使えないから丁度いいと思っているのですが、TravisCIもかなりシェアを握っていると聞いています。CIツールの選定時、何を比較すればいいか詳しい方いらっしゃいましたら、是非教えてください。

この素晴らしいAWSに祝福を!

なんで本番環境のデータベースがEC2インスタンスに構築されたMySQLなんでしょう、、、

その他のサーバーも全てEC2インスタ上に乗せただけなので、多分今やってることを全部ASに載せ替えたら、色々管理してることをAWSが負担してくれるんじゃないかな…と思っています。悲しい。

どうすべきか

AWSに詳しくないので、どこかでどう間違っているという指摘が出来ません。悔しいのですが自分が学習する以外に打開策が思いつかない。学習して〜なメリットがあります!と明確に提示できるようになれば、初めて交渉のステージに立てるようになると思うので、現状は自分の実力不足としか言いようがない。

ですが、AWSインフラに口出し出来るようになれば、他社から見ても魅力的な人材なのでは?を胸に今後も頑張ろうと思います。

今後やっていくこと

  • 個人開発でCIツールを使い、いい感じでGitのコミットをトリガーに自動テスト、自動デプロイできるようにする。
  • AWS。スコープがでか過ぎるので、まずはデータベースから。せめてS3から学習する。ゴールはもう少し楽に運用できる状態にすること。

幸いなことは、ブラックな会社ではないことで、頭ごなしに「働けーーー!!」ではないところ。

いい感じに緩く、成果で判断される職場なので、今後も緊張感持ってエンジニアやっていきたいと思います。

実績作らなきゃ転職しようにもできませんしね。