Vue.jsでクリップボード機能を実装する

はじめに

PCであれば、「範囲選択→ショートカットキー」で簡単に範囲コピーをする事が可能ですが、スマホの場合面倒な作業になってしまいます。
ユーザー体験向上の為、ブラウザ上でクリップボード機能を実現する目的でClipboard APIを利用したので紹介します。

記事の目的

・クリップボードボタンを押下すると対象文字列がコピーされる機能を実装する

Clipboard API

Clipboard API は Promise ベースでクリップボードのコピーやペーストが行えるAPI です。

使い方は簡単で、クリップボードにテキストを書き込む為に以下のように利用します。

navigator.clipboard.writeText("コピーしたい文字列")

Vue.jsプロジェクト内で利用してみる

<template>
    <div>
        <p>{{ text }}</p>
        <button @click=writeToClipboard(text)>コピー</button>
        <input type="text">
    </div>
</template>

<script lang="ts">
    private text = "クリップボード成功";

    private writeToClipboard(text: string): void {
        navigator.clipboard.writeText(text).catch((e) => {
            console.error(e);
        });
    }
</script>

ちなみに現在は多くのブラウザで対応されているようです。

参考

developer.mozilla.org

developer.mozilla.org

Rails consoleのsandboxモードを利用してコードを確認してみた

はじめに

Railsでアプリケーションを開発していると、コードの挙動を確認したい場面が多々あると思います。
今回はRailsコンソールのsandboxモードを利用して挙動確認を行ったので備忘録としてまとめます。

記事の目的

・Rails consoleを利用して挙動確認を行う事で効率よくアプリケーション開発を行えるようになる

Rails consoleとは

Rails consoleとは、Railsの環境を読み込んだ状態でrubyのコードを実行できるツールです。
色々なメソッドの挙動を確認したいときに利用したり、エラーの原因を探るときなどにも使える便利なものですのでRails開発には欠かせないものとなっています。
Rails consoleを起動するには以下コマンドをターミナルへ入力します。

$ rails console
※ rails c　と省略する事も可能です

起動後はexitと入力することで終了します。

sandboxモードとは

sandboxモードを起動するとコンソール内でDBの内容を変更した際、最終的にロールバックを行う事でDBを起動前の状態に戻す事が可能になります。
DB関連の操作を行う際は必ずsandboxモードを使うようにしましょう。
以下のようにオプションを指定する事でsandboxモードを起動することができます。

$  rails c -s

まとめ

Rails consoleは非常に便利なものです。
積極的に利用して効率的に開発を進めていきましょう！！

FactoryBotでテストデータ作成する方法

はじめに

本記事は以前Qiitaに掲載していた内容です。
エンジニア転職を目指してRails Tutorialで学習を行なっていた際に、デフォルトで紹介されているminitestではなく、現場で利用されている事の多いRspecを利用してみました。
テストを作成する中でFactoryBotというGemを使用したので詰まったところなどまとめておきます。

記事の目的

・Rspecを利用したテストデータ作成の基本を知る
・Rspecで複数のテストユーザーを作成できるようになる

FactoryBotを使ってみる

テストデータを定義する

テストデータの定義は、specの配下にfactories/モデル名.rb　のようなファイルを作成し、この中で定義していきます。今回はuserというテストデータを定義します。

-factories/user.rb

FactoryBot.define do
  factory :user do
    name { 'Yamada Tarou' }
    email { 'yamade@rails.com' }
    password { 'password' }
    password_confirmation { 'password' }
  end
end

テストデータを利用する

先程定義したテストデータを実際に利用していきましょう。
定義した内容をテストで利用するにはテストファイル内で以下のように記述していきます。

-rspec/controllers/users_controller_spec.rb

RSpec.describe UsersController, type: :controller do
  let(:user){ FactoryBot.create(:user) }
end

ユーザーを複数登録したい、、、

ログインユーザーが別ユーザーの情報を変更する事ができない事をテストする為、複数のユーザーをテストデータとして登録していきます。

FactoryBot.define do
  factory :user do
    name { 'Yamada Tarou' }
    email { 'yamade@rails.com' }
    password { 'password' }
    password_confirmation { 'password' }
  end
  factory :other_user, do
    name { 'Sato jirou' }
    email { 'sato@rails.com' }
    password { 'foobar' }
    password_confirmation { 'foobar' }
  end
end

=>NameError:
 uninitialized constact OtherUser

上記のように複数のユーザーを定義して実行するとエラーが出てしまいます。
FactoryBotデータを作成する際には、factory :モデル名 do ~ endとする必要があり、今回のように複数のユーザーを作る時には明示的クラスを指定しなければならないようです。

/省略/
factory :other_user, class: User do
    name { 'Sato jirou' }
    email { 'sato@rails.com' }
    password { 'foobar' }
    password_confirmation { 'foobar' }
    admin { 'false' }
  end
end

上記のように変更する事で無事にテストユーザーを作成する事ができます。

Laravel × Vue CLIを利用した環境構築案を考えてみた

はじめに

最近、LaravelとVueを触る機会が多くなりました。
Laravelはフロントエンドの開発が行やすいようLaravel Mixの仕組みが用意されています。
今まではこちらを利用してVue、ReactなどをLaravelに組み込んでいました。
今回Vue CLIの雛形をそのまま使いたいと思いその環境を構築してみたのでまとめておきます。

今回の方法ではVue CLIの雛形を利用できる以外にも以下のようなメリットがあげられます。

・フロントエンドエンジニアがLaravelを意識せず開発できる
・Laravel Mixが対応していない為、Vue CLIの新機能が使えないという事がなくなる
・バックエンドにLaravelを利用しなくなった場合でも対応できる
今後の変化に備えてフロントエンドがLaravelに依存しないよう環境を作りたい！！ただの興味本位でやってみたというのもある、、、

目指す構成

docker-laravel/
├─ docker-compose.yml 
├─ backend/ .......... Laravelコード
│  ├─ app/
│  ├─ bootstrap/
│  ├─ config/
│  ├─ database/
│  ├─ public/
│  │  ├─ docker-laravel/
│  ├─ resources/
│  │  └─ views/ .......... spa/app.blade.phpが作成される
│  ├─ routes/
│  ├─ storage/
│  ├─ tests/
│  └─ vendor/
├─ frontend/
│  ├─ // Vue.jsのコードを格納    
└─ infra/
   └─ docker/

frontendディレクトリがVue CLIのプロジェクトです。
frontendディレクトリ内でnpm run buildを実行した結果、resources/views/spa/app.blade.phpが作成され画面が描写されます。

Laravelの準備

今回はLaravel環境の準備は本題ではない為、こちらを利用させていただきます。

https://github.com/ucan-lab/docker-laravel

この通りに進めると、backendディレクトリ以下にLaravelアプリが作成されます。
バックエンド側の準備は以上で完了です。
念の為、この段階でLaravelのwelcome画面が表示される事を確認しておきましょう。

フロント側の準備

Vue CLIのインストール

Vue.js を使う環境を準備するためのコマンドラインインタフェースをインストールします。

$ npm install -g @vue/cli

// 完了後バージョンが表示されればOK
$ vue --version
@vue/cli 4.5.13

Vue CLIでフロントエンドアプリの雛形を作成

ルートディレクトリ内でvue-cliコマンドを利用していvue3のインストールを行います。今回はVue3、TypeScriptの組み合わせで利用します。
こちらも本題ではないのでリンクを参考に準備してください。

https://reffect.co.jp/vue/vue3-typescript#class-style_component

Laravel Mixのファイルを削除

今回の環境ではLaravel Mixを利用しないの為、不要なファイルは削除しておきます。

$ cd backend
$ rm -rf package.json webpack.mix.js

VueアプリをLaravelで配信する

現在の構成だとfrontendディレクトリのVueアプリとbackendディレクトリのLaravelアプリが2つ存在する状態です。
npm run buildを実行するとbladeの出力とアセットがLaravel以下に出力されるように設定していきます。

Vue.config.jsの作成

$ cd frontend
$ touch vue.config.js

module.exports = {
    // アセットはLaravelのpublic/appディレクトリ配下に作成される
    outputDir: '../backend/public/app',

    // app配下にjs, cssなどが置かれるので、publicPathを調整
    publicPath: '/app',

    pages: {
        // appのエントリポイント、テンプレート、出力先を調整
        app: {
            entry: 'src/main.ts',
            template: 'templates/base.html',
            filename: `../../resources/views/spa/app.blade.php`,
        },
    },
}

public/index.htmlをLaravel側で生成する為、Vue側のindex.htmlをbaseのテンプレートとして指定するよう変更します。

// テンプレートディレクトリの作成
$ mkdir templates
$ mv public/index.html templates/base.html

Laravel側でルートを用意する

先程のvue.config.jsの設定で、frontend側でnpm run buildを実行するとLaravelの resources/views/spa 配下にapp.blade.phpが作成されます。
そちらのbladeを呼び出すspa用のルーティングを用意していきます。

Route::get('/{any}', function () {
    return view('spa.app');
})->where('any', '.*');

これでどのURLでアクセスしてもspa/app.blade.phpが表示される事になります。 ついでに以下をgitignoreに追加しておきます。

.gitignore
/public/app
/resources/views/spa

動作を確認する

frontendディレクトリに移動して、ビルドを実行します。

$npm run build

localhostにアクセスし、Vue.jsのwelcome画面が描写されていれば完成です。

まとめ

今回は、Vue CLIとLaravelを利用した環境構築を進めていきました。
Laravelのappディレクトリ以下にfrontendディレクトリを切っている記事が多かったのですが、Laravelのディレクトリ内にVue CLIのコードが紛れている事が個人的に気持ち悪かったので今回のような構成を試してみました。

参考記事

https://qiita.com/bokuranokyo/items/1b14852c09395bf99941

ソースコードのコメントについて再考してみる

はじめに

「クソコード」と呼ばれるコードが生まれる理由は様々ですが、本来コードを読みやすくするはずのコメントが原因でソースコードの可読性が下がる事もあります。
何となく直感でコメント内容を決めていくと可読性を下げるコメントを残してしまっているかもしれません。

実務で携わった案件でも、コメントのせいで処理が追いづらかったり、コメントと動作内容に齟齬があり、騙されそうになる事もありました。味方に後ろから切られる気分でした、、、（汗）
そこで本記事では、「可読性を上げる為のコメント」について考えてみたいと思います。

記事の目的

・コメントの目的、残すべきコメントを知ることでコードの可読性を高める。

優れたコードの定義

事前に今回目指す「優れたコード」の定義を明確にします。
「優れたコード」とは、他人が最短時間で理解できるコードと定義します。この他人には何ヶ月後かの自分も含まれています。
コードを書いている最中は実装の周辺知識などが豊富にある状態ですが、何ヶ月後かにその箇所のコードを読む時はそのような前提条件がない可能性が高いです。

開発で最も多くの時間を占めるタスクは既存コードを読み、理解することです。
その為、他人がが理解しやすいコードを目指す必要があります。
理解しやすいコードの要素は様々ありますが、本記事ではソースコードのコメントという視点から考えてみたいと思います。

コメントの目的

コメントがあってもなくてもソースコードは同じ動きをします。
むしろ闇雲にコメントを残すと、コードの視認性が下がり悪影響を与える事すらあります。
このような不要なコメントを残さないように、コメントを書く目的を常に意識しておく必要があります。
コメントの目的は、ソースコードの書き手の意図を読み手に知らせる事です。
背景知識のない読み手になぜそのようなコードなっているのか、前提知識がないと理解できないものをコメントとして残す事で、読み手側にコードの意図を伝える役割があります。

不要なコメント

実例を挙げながら、視認性を下げるコメントを見ていきたいと思います。
これらは私が新人研修のレビューや、案件内で実際に出会い不要と感じたコメントです。

変数名・メソッド名を説明するコメント

名前から意味を読み取れない変数、メソッドに対しコメントで説明を加えているコードがあります。
この場合は、コメントで補足するのではなく名前を意味あるものに変更しましょう。

// 姓
$a = '田中';　← 変数名を意味のあるものに変更する

$last_name = '田中'; 　← コメントがなくとも変数名から意味を汲み取れる

コードの再翻訳

ソースコードから読み取れる内容をコメントに残すべきではありません。
コードの視認性が下がる上に、該当箇所に変更が加えられた時にコメントを修正する手間も発生するなどの弊害があります。

例)
// a と bが等しい場合
if ($a === $b) {

}

コードの変更履歴

過去に携わった案件でコードの修正履歴、変更者などをコメントとして残しているプロジェクトがありました。
コミット情報で確認できるので必要ではないかと、、、

public function taxAmount($item_price)
{
    return $item_price + ($item_price * 0.1);  // 2020年1月bugfix　◯◯
}

必要なコメント

なぜそうなっているかの説明

本来はこうあるべきだと考えられる処理だが、（〜の理由で）あえてこのようなコードになっているなどの背景はコメントに明記しましょう。
なぜそのような選択をしたのかわ本人しかわかりません。

なにもしない事の宣言

何もしないのコメントとして残す以外方法がありません。
コメントを残す事で意図して処理を書いていない旨を知らせる効果があります。

try {
   ...処理...
} catch (\Exception $e) {
   // do nothing
}

コードの欠陥をメモして置く

欠陥を認識しているがどうしても手が回らない場合など、せめて改善が必要な事をメモしておく事で将来的な修正に備えてコメントを残す事もありかと思います。
その際にはメモルールをチームで統一して決めておくと重宝します。

例）メモルールの一例
TODO：あとで手を付ける
FIXME：既存の不具合があるコード
XXX：危険！大きな問題がある

参考

本記事はリーダブルコードを参考にしています。
本書には、ソースコードを「いいコード」にする為のノウハウが詰まっています。経験が浅い方でもすぐに使える内容も含まれるのでぜひ一度読んでいただきたいです！

PHPカンファレンスに初参加してみた件

はじめに

5/29(土) に行われた以下イベントに参加しました。

connpass.com

・Twitter HashTag : #phpcon_okinawa

初のPHPカンファレンスへの参加でしたが、有意義な時間となりました。
個人的に関心事であった技術的負債について登壇されたLTが印象に残っています。

LT内容

@akki_megane さん
技術的負債を返し続ける取り組み ~ あなたのPHPのバージョンいくつですか？

技術的負債を返し続ける取り組み - Speaker Deck

感想

技術的負債は新しいものに取り組む中で必ず生まれてしまうもの。その負債に対してのアプローチをチームとしてシステム化する事の重要性を感じた。
特に以下二点。

・課題を起票する際、起票者が必ず対応するのではなくチーム全体で課題の共有
→ 課題発見のハードルを下げる事

・新規開発と別軸で技術負債の優先順位を決め、負債返済の為の時間を新規開発と別に設ける
→ 新規開発と同軸で有線順位を決定すると負債返済へのアプローチが後回しになり続ける

経営側からすると負債返済への取り組みを新規開発と別軸で設ける事への抵抗はありそう。
負債解決する事でバグの混入を防ぎ、拡張性が高まるメリットをいかに周囲に納得させるかが鍵ですね、、、

まとめ

SESとして働いている時は、システムを要件通りに組み上げる事のみに注力し仕事をしていました。
自社にリスク・責任がこないような立ち振る舞いに重きをおいてましたが、自社開発のサービスに関わる中で、ビジネスとしてシステムを捉えるようになり、市場動向に合わせ、スピード感をもってシステムを拡張する事の必要性を感じていたので今回のLT内容が印象に残りました。
負債に対してのアプローチをチームとしてシステム化し、早い段階でかつ、継続的に行なっていこうと決意しました。
自社内での信頼を得てからの話ですが(笑)　

SES企業って実際どうなの？ ~未経験からSES企業に入社した私が感じた事~

はじめに

未経験エンジニアの転職活動での関心事の一つが、
「自社開発・受託開発・SESどのようなビジネス形態の企業を選択するか。」　

実務未経験者が影響されそうなテック系インフルエンサーはこぞって「自社開発に就職しろ」、「SESは経験なんてつめない」等の発言をしています。
これに対して未経験からSES企業で1年半就業した経験のある私の立場から考察していきたいと思います。

対象

・エンジニア転職を目指して企業選びをしている方
・SES企業の就業イメージをつけたい方

SESとは...

SESとは、システム・エンジニア・サービスの略称です。
要は客先常駐の事のことで、自社ではなく客先の会社で働く形態の事を指します。募集要項に勤務地が自社だけでなく様々な場所を書いている会社などはSES事業を行なっている場合が多いです。

実務未経験者向けのテック系インフルエンサーは、

・ SESでは雑務ばかりやらされて技術レベルが身に付かない

・未経験はSESは避けて自社開発を目指すべき

という意見がほとんどかと思います。
実務未経験の方は、このような発言を聞いて 「SES = やばい」と判断しているのではないでしょうか。

物事を判断するときは様々な意見を集め、 自分の考えを持つ事が大切です。
以前、SES企業は絶対に嫌だという転職希望者の方に理由を聞くと
「youtuberの〇〇さんがやばいと言っていた」
という返答が返ってきた事があります。
正直これを聞いた時、あんたが一番やばいよと思った記憶があります(笑)

SES企業での経験をもとにSESを考える

労働時間と内容・収入・スキルの3項目に関してお話ししたいと思います。（あくまで私個人の経験になりますが、多くの方に共通する部分もあるかと思います）

SESの仕事の内容・労働時間

入社後、2週間の社内研修を受けHRTech企業で客先常駐を経験しました。
その会社は自社サービスとして年末調整システムを開発しており、そのチームの一員として先輩社員と一緒に参画しました。
参画1ヶ月目は、テストと軽微なバグ修正を担当とし、2ヶ月目からは実際に実装のタスクに携わらせていただきました。

この案件では、先輩とチームを組んでの参画で、各チームに対してタスクが振り分けられるような開発形式でした。
未経験入社ではありましたが2ヶ月目からは実装フェーズの仕事を振ってもらいながら開発経験を積む事ができました。

ただ実際にネットに書かれてるように、SES会社によっては延々とテストをしたり、資料印刷などスキルと無縁の仕事をさせられる事はあるようです。（私の就業していた企業では、同時期に何名か未経験入社したエンジニアがいましたが一人もそのような事はありませんでした）

就業時間に関しては、リリース前は1日1~2時間程度の残業が発生することもありましたが、それ以外はほぼ定時で退勤していました。
他現場で就業した際もそれほど残業が発生する事はありません。
SESは1ヶ月の就業時間幅が決まっており、その範囲を超えると追加の料金が発生する仕組みになっているので受け入れ側の企業も時間管理はしっかりと行われる場合が多いかと思います。

SESエンジニアの収入面

これははっきり言って安いです。
未経験エンジニアであれば300万円台が相場かと思いますので同程度はもらえるかとおもます。

SESの契約形態は月に一人が稼げる額が固定で決まっているので、給与があげられないという側面があります。
なので経験があり、そこそこの給与を望める経験のあるエンジニアからすると損をする可能性があります。

SESでスキルは身につくのか

私自身の経験から、SES企業でも開発経験を積む事は可能です。
また、自社開発の企業や、受託企業など様々な案件に携わり、それぞれのプロジェクト進行や開発スタイルを経験させていただいた事は非常に気付きも多くありました。

しかし、延々テスト・雑務などで開発経験を全く積めない現場がある事も事実のようです。
これに関しては、SES企業側に問題がある場合が多いので入社する企業を間違わない事である程度は回避できると思います。

可能であれば実際にその企業で働いてるエンジニアと話せる機会を作るなどしてブラックSESを避けるようにしましょう。

結局未経験エンジニアはどの企業形態で働くべきなのか...

私自身の経験から、SES企業でも開発経験を積む事は可能ですし、様々な技術に携われる可能性があるというメリットはあると思います。
しかし、その後のキャリアを考えるならば、実務未経験のエンジニアは自社開発のみ行なっている企業への就職を目指すべきだと思います。
SESでも経験を詰める会社はたくさんあると思いますし、自社開発でも開発経験が積めない事はあります。 しかし、自社開発の方が可能性は低いです。
SESはその時の案件状況により使う技術スタックも変っていきますが、自社開発であればある程度携われる案件が事前にわかります。

どうしても受託・SESはガチャ要素が強くなってしまうので自社開発への転職を目指すべきだと感じています。

とはいえ未経験エンジニアに必要なのは実務経験

自社開発の企業は実務経験者にも人気がある為、応募が多数あり、未経験者が入社する難易度は非常に高いものです。
未経験エンジニアに関しては、SES・受託企業も視野に入れ、実務経験を積む事が最も重要です。
IT業界は経験を積むことにより逆に仕事を選べる立場なれます。
脳死状態でSESは絶対に避けるではなく、そのメリット・デメリットを理解した上で判断してほしいなと思っています。

まとめ

長々となりましたが私の経験から未経験者がSESで働く事に関して考察してみました。あくまで私の経験をもとにした考えですので、一つの意見として捉え、自身の転職活動に望んでいただければなと思います。