LoginSignup
12
1

More than 5 years have passed since last update.

自宅開発トラブル紹介

Posted at

ラクスアドベントカレンダー2日目!

アドベントカレンダーの参加者として手を挙げたのはいいですが、特に何を書くか考えていませんでしたので、とりあえず、最近触っているLaravelのアプリケーションについて、詰まったところをいくつか挙げていきます。

作成しているアプリについて

特に変わったアプリでもないのですが、ある団体のWebサイトの作成を行っています。
一般の方が閲覧するページと、そのページを編集する用のログイン機能付き管理画面に分かれています。

サーバサイドに PHP を使い、フレームワークとして、Laravel を採用しており、
また、一般の方が閲覧するページは、Vue.js を用いた SPA として実装し、
SPA の JSファイルを分割するために、webpackageを導入しています。
さらに、 Docker を利用して開発環境を用意しています。

技術系トラブル

composer 実行時に警告?

Laravel を導入する際、composer で以下のような警告が出力されました。

root@a244e7e7f2df:/usr/local# composer global require "laravel/installer=~1.1"
Changed current directory to /root/.composer
Do not run Composer as root/super user! See https://getcomposer.org/root for details
./composer.json has been created

出力されても、その先の処理は実行されるので、詰まったわけではなかったのですが、気になったので調べました。

公式ドキュメントによると、composer では、composer 実行ユーザの権限で、composer で入れようとしているパッケージに関係したスクリプトを実行します。

そのため、実行されるスクリプトの中に危険なスクリプトが含まれていたときのために、root 権限による実行は控えるよう勧めているようです。

Vue.js での登録フォーム入力内容確認画面

なんだかんだこれが一番時間がかかったように思います。

特に、Vue.js の経験がなかったので、いろいろな勝手がわからず遠回りした印象です。

簡単な登録フォームを実装するとき、入力内容の確認ページを作ろうと思いました。

しかし、Vue.js + webpackage にて、他ページ(:他コンポーネント)に入力値を引き継ぐ方法がわからず、苦労しました。

結果、Vue.js アプリケーションで状態管理を行うためのライブラリである Vuex を導入することで解決しました。
Vuex のストアオブジェクトをに、フォームの入力値を保存することで、どのコンポーネントからでも呼び出すことが可能になりました。

ただ、ここは現状やりたいことを実現できただけで、リファクタリングが必要かと考えています。
というのも、Vuex のストアオブジェクトをすべて大本のコンポーネントに定義しているため、あちらこちらで使用するストアオブジェクトがあふれ気味になっています。
少し整理するか、他の用方法を探そうかと考えています。

Docker 環境での npm install

開発環境は Windows 上で、Docker を用いて作成しています。
Laravel プロジェクトの設置ディレクトリを、ボリュームとし、Windows のフォルダと共有させています。

この開発環境が原因で、以下のエラーが出力され、npm パッケージがインストールできないという問題が生じました。

npm ERR! path /usr/local/hoge/node_modules/abbrev/package.json.920591357
npm ERR! code ETXTBSY
npm ERR! errno -26
npm ERR! syscall rename
npm ERR! ETXTBSY: text file is busy, rename '/usr/local/hoge/node_modules/abbrev/package.json.920591357' -> '/usr/local/hoge/node_modules/abbrev/package.json'

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2018-08-04T08_11_53_004Z-debug.log

こちら、Windows からコンテナにマウントされているディレクトリで、 npm install を行うとこのようなエラーになるそうです。
また、Windows との共有ディレクトリではシンボリックリンクの作成が禁止されているため、以下のような手順とコマンドでこのエラーを回避しました。

  • package.json を ボリュームとしてマウントしていない Docker コンテナ内のディレクトリに移動する
  • コマンド npm install --no-bin-links を実行
  • 作成される node_modules ディレクトリをプロジェクトの直下に移動する

相変わらずいい方法ではない気がするのですが、今のところこの方法で問題は生じていません。

非技術系トラブル

開発時間が確保できない問題

ここ一ヶ月ほど、まさにこれです。
しかし、プライベートでの開発である以上、残業やほかのタスクで時間が確保できないことは仕方ありません。

そのため、いかに実装の前行程を減らし、かつ集中して作業できるかを考えました。

まず、実装前の作業を短縮すべく、実装のアイディアや、追加機能については、通勤時間などに考え、思いついた瞬間スマホにメモします。
次に、アイディアをタスク化して、使用している Git Lab の issue として登録し、ToDoタグを付与します。

これによって、実装開始時のアイディアを考える時間や、思い出す時間などのオーバヘッドを短縮し、すぐ実装に取り掛かれるようにしました。

また、貴重な開発時間が確保できたときは、私は外出してコードを書くようにしています。
これは、入社1年目の時に、会社の先輩にアドバイスいただいたことなのですが、自宅だとどうしても寝てしまったりだらけてしまったりで、せっかくの時間を有効に活用できないことが多くなります。(私は特によく気づいたら寝ています。。。)

そのため、思い立ったら即外出して、WiFiが使える場所を探し、作業を行います。

最近は、WiFiも自由に使えて電源が確保できる自宅近くのカフェを見つけたので、暇な休日はそこへ出かけています。
さすがにカフェなどで寝ることはできないので、思った以上に作業がはかどりますね。
(ちゃんとコーヒー数杯は注文してから粘っています。)

エディタのショートカットを混同する問題

私は、業務では PhpStorm、自宅では Atom を利用しています。
それぞれのエディタはデフォルトのショートカットが異なるので、時々違う方のエディタショートカットを叩いてしまうことがあります。

先月初めまで、業務でコーディング以外のタスクをしばらくやっていたため、 Atom を触る時間のほうが多くなったときは特に困りました。久々に PhpStorm で実装を行った際に Atom のショートカットを何度も叩きました...。

PhpStorm はライセンス等の問題がややこしそうだったので、自宅では Atom を使っているのですが...本格的に業務へ支障が出る前に、エディタを統一したほうがいいのかもしれません。

コミットの粒度問題

独りで行っている自主開発なので、とくにレビューなどはありません。
そのため、開発が進むにつれ、「コミットの粒度が荒くなる問題」が生じています。

複数人での開発では、「自分はこの機能担当」といった役割分担がありますが、個人開発の場合、実装しながら気になった部分は、気づいたら直してしまっています。
そのため、途中から、一体自分はなんの実装をしていたのかがわからなくなってきてしまい、結局関係ない機能が出来上がっていたことが度々あるため、コミットするときにはたくさんの修正が含まれてしまっていることがあります。

一応、対策として、Git Lab にて、作業する issue に Doingタグを付与してから作業し、その他の機能は触らないように心がけていますが、、、気づいたら関係ないコードをいじっています。

自宅開発なので、楽しく実装はしたいですが、そのうち漏れや不要なコードができてしまって苦労しそう。。。

「これでいいや」と思ってしまう問題

ある程度実装が進むと、「ここはこだわらなくていいや」という気持ちとの戦いでした。
ファーストリリースは、できるだけ最小限の機能に抑えるつもりでしたが、完成が近づくと、だんだん妥協する心との戦いが始まりました。
しかし、今記事を書きながら考えてみると、けっこう妥協してしまっているところが多いように思います。
年末は土日の予定がほとんど詰まってしまっているので、年始から頑張ろうかな...

さいごに

振り返ってみると、自宅開発で土日はかなり潰れました(笑) が、得たものも多かったと感じます。
上記のトラブルを解決することで知識は増えましたし、言語や、MW についての見識も広がったと思います。

また、自宅開発を行うことで、コードを書く量が増え、また、自分で書いたコードに改修を加えることで、のちに保守性が悪くなるコードがどのようなものかも、わかるようになってきました。

好きこそもののなんとやらではありませんが、自分で楽しくコードを書くことで、コーディングの練習量も増え、業務では身に付きづらい感覚も得ることができたと思います。


さて、ラクスアドベントカレンダー、明日は@radiocatさんです。よろしくお願いいたします!

12
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
1