fluid_27’s blog

勉強した内容をアウトプットするためのブログ

Laravel + tailwindでボタンデザインのチェックボックスを実装

現在作成しているlaravelアプリにチェックボックスを組み込んだですが、デザインをボタンぽくしたかったのでtailwindで実装してみました。

 

同様のことを生のCSSで書いて解説しているブログはけっこう見つかったのですが、tailwindで実装しているのは見つからなかったので、自分自身の備忘録も兼ねて完成したソースを残しておきます。

 

 

完成画面

最終的に下図のような感じで、ボタンっぽいデザインにしました。

選択済み・マウスホバー時には色が濃くなるようになってます。

f:id:fluid_27:20220416172513p:plain

 

完成版ソース

{{-- タグ選択 --}}
@if ($tags)
 <div class="p-2">
  <p for="career" class="leading-7 text-sm text-gray-600">特徴タグ</p>
  @foreach ($tags as $tag)
   <div class="relative inline-block px-1 py-2">
     {{-- 既に登録しているタグがあれば --}}
   @if ($jobTags && $jobTags->contains($tag))
     <input checked="checked" type="checkbox" id="checkbox{{ $tag->id }}"
         name="tag[{{ $tag->id }}]" value="{{ $tag->id }}"
       class="opacity-0 absolute w-full h-full left-0 peer cursor-pointer">
     <label for="checkbox1" class="text-white rounded-full bg-teal-500
         cursor-pointer ease-in peer-hover:bg-teal-600 px-2 py-1
         peer-checked:bg-teal-600">
         {{ $tag->tag_name }}
     </label>
    {{-- タグ未登録であれば --}}
   @else
     <input type="checkbox" id="checkbox{{ $tag->id }}" name="tag[{{ $tag->id }}]"
       value="{{ $tag->id }}" class="opacity-0 absolute w-full h-full left-0 peer
         cursor-pointer">
     <label for="checkbox1" class="text-white rounded-full bg-teal-500
         cursor-pointer ease-in peer-hover:bg-teal-600 px-2 py-1
         peer-checked:bg-teal-600">
        {{ $tag->tag_name }}
     </label>
  @endif
  </div>
 @endforeach
 </div>
@endif

* アプリでは求人サイトを作成していて、登録した求人(job)がタグ(tag)を選択できる仕様です。

 

上記はタグを選択できるようにチェックボックスを実装している画面のソースコードです。

コメントにあるように、既にタグ登録済みかどうかで条件分岐してます。

 

 

checkboxをボタンデザインで表現する為のクラスをtailwindで書く

tailwind初めて使ったのでCSSをtailwindではどう書くのか調べながら実装しました。

(CSS記法 → tailwind記法 //解説)

opacity: 0;    → opacity-0 //要素を透明にする

position: absolute;   → absolute  //絶対配置

left: 0; → left-0  //絶対配置で左づけ

cursor: pointer; → cursor-pointer  //マウスカーソルの種類

border-radius: 9999px; → rounded-full  //角を丸く

 

マウスホバー時・チェック時に色を変える

peerを使って兄弟要素のスタイリングを制御できます。

・兄要素に peer

・弟要素に peer-* 接頭辞クラスを使用する

ことで可能になります。

 

なので、上記の例でいうと

・兄要素のinputタグに peer

・弟要素のlabel に peer-checked:bg-teal-600 を記述して、

兄要素のinputがcheckedかどうかで弟要素のlabelの色が変わるようになってます。

この辺りは下記記事や公式サイトを参考にしました。

Tailwind CSSで親要素や兄弟要素の状態変化を簡単にスタイリングする ++ Gaji-Laboブログ

Handling Hover, Focus, and Other States - Tailwind CSS

 

他にも書き方あると思うので、もっといい書き方知っている方は教えてください。

BOMってなに?

BOMってなに?

 

先日、業務でhtmlファイルを編集する際「BOMつけないようにお願いします」と言われ「BOMってなに?」ってなったので調べてみました。

 

BOMとは、、

バイト順マーク (バイトじゅんマーク、byte order mark) あるいはバイトオーダーマークとは、通称BOM(ボム)といわれるUnicode符号化形式で符号化したテキストの先頭につける数バイトのデータのことである。このデータを元にUnicodeで符号化されていることおよび符号化の種類の判別に使用する。

-wikipediaより引用

バイト順マーク - Wikipedia

 

との事。えーっと、、、結局なに?

 

どのように利用されるのかを調べてみると、

Excelなどでファイルを開く際に

BOM付きでなければ符号化方式がUTF-8なのかUTF-16なのか、またはUTF-32なのか、あるいはまったく別の文字コードなのか判断できないことがあります。

https://uxmilk.jp/48923

とあり、更に

 

一方、Webページとして使用されるHTMLファイルの場合はBOM無しで保存・上書きする方が良いとされています。これはWebページを動的に処理するPHPなどのプログラムがBOM付きのテキストファイルを正常に処理することができないことがあるからです。

https://uxmilk.jp/48923

との事。

 

まとめると

BOMとは、「そのデータの符号化方式の種類が何なのか(UTF-8UTF-16など)を明示的に示すサインのようなもの」というところでしょうか。

 

そんでもって、BOM有り・無しの使い分けとしては

BOMつける場合

 →Excelなどで開くことを想定しているファイルなど

BOMつけない場合

 →htmlファイルなど

という事になりそうです。

 

また、既存ファイルがBOMの付きなのかBOM無しなのかを調べるのは下記サイトで図入りで説明されてますので、参照ください。

https://aprico-media.com/posts/5636

 

HerokuにアップしたLaravel + tailwindアプリの画面崩れを修正

Laravelで新規アプリを作成しており、いったんherokuでデプロイし、画面を確認したところcssが崩れていました。

原因はtailwind.cssのバージョンが上がった事。

ローカルで作成している段階では

$ npm run dev もしくは

$ npm run watch

すれば解決するのですが、herokuでも同様に解決しようと

$ heroku run npm run dev

とすると、npmコマンドがそもそも使えない。という事態だったので、npmを使えるようにするところから、$ npm run devをするまでの流れをまとめました。

 

 

そもそも、npmとは

npmとNode Packaged Modules(ノードパッケージドモジュールズ)の略で、Node.jsのライブラリやパッケージを管理することができるツール。

管理ファイルであるpackage.jsonにインストールしたいパッケージを記述しておくことで「npm install」が実行されるときに指定のものをインストールしてくれる。

 

 

npm runコマンド

npm scriptsと呼ばれるタスク実行機能を呼び出すコマンド。
機能は、package.json内に書かれたシェルスクリプトを実行すること。

{
"private": true,
"scripts": {
"dev": "npm run development",
"development": "mix",
"watch": "mix watch",
"watch-poll": "mix watch -- --watch-options-poll=1000",
"hot": "mix watch --hot",
"prod": "npm run production",
"production": "mix --production"
},
"devDependencies": {
"@tailwindcss/forms": "^0.4.0",
"alpinejs": "^3.4.2",
"autoprefixer": "^10.1.0",
"axios": "^0.21",
"laravel-mix": "^6.0.6",
"lodash": "^4.17.19",
"postcss": "^8.2.1",
"postcss-import": "^14.0.1",
"tailwindcss": "^3.0.0"
}
}

上記のようなpackage.jsonがあった場合、

$ npm run dev とすると

 npm run develeopment が実行され、

$ npm run build とすると

 npm run production が実行される。

という事ですね。

 

Herokuでnpmを使えるようにする

HerokuのビルドパックにNode.jsを追加する必要があり、今回はコンソールで追加しました。(HerokuのページからGUIで追加する事もできます)

$ heroku buildpacks:add heroku/nodejs

 

そして、package.jsonが作成されてないのであれば

$ npm init

$ npm install

をする必要があるのですが(詳細は、下記の参考サイト参照)、今回はローカルで開発したアプリをHerokuにpushするので流れなので、これらは実行せずに改めて

$ git push heroku main

でherokuにプッシュし、

$ heroku run npm run dev

実行してみました。

 

が、

$ heroku run npm run dev                  

 

Running npm run dev on ⬢ limitless-fjord-21567... up, run.6630 (Free)

> dev

> npm run development

 

> development

> mix

 

sh: 1: mix: not found

というエラーが。

色々とググっていると、下記サイトに解決方法が書いてありました。

https://jun-app.com/articles/laravel-mixx-heroku-fail

HerokuではNODE_ENVがproductionとして定義されていると、インストールおよび​ビルドステップ​を実行した後、アプリケーションをデプロイする前に、​devDependencies​ に宣言されているパッケージを取り除いてしまうそうです。

 

解決法

これも上記ページに書いてありましたが、

package.jsonの内容を編集し、

devDependencies => dependencies

と書き換えました。

 

また、自分の場合必要なかったかもしれませんが、上記サイトに載っていた通り

npm run prod => npm run build

に変更し、デプロイした時にLaravel Mixを叩いて、ビルドするようにしました。

 

これで、エラーが出ずに

$ heroku run npm run dev

を実行し、tailwindのcssがちゃんと反映されているのを確認できました。

 

余談

初学者として、用語の整理をしておきます。

 

Laravel Mixとは

フロントエンドのアセットをコンパイル、バンドルしてくれるツール

webpackのAPIラッパー。

 

webpackとは

webpackにはいろんな機能があるが、一番基本的な機能はjsの結合処理。いわゆるモジュールバンドラ。

 

package.jsonとwebpack.mix.js

Laravelをインストールすると、

package.jsonとwebpack.mix.jsが用意されている。

package.jsonには

Laravel Mix自体やその他必要なパッケージが記述済み。

また、package.jsonのscriptsにはwebpackを実行するためのスクリプトも記述されている。

webpack.mix.jsは、

webpack設定ファイル(webpack.config.js)のラッパー。

ここにコンパイル対象ファイルやバンドル対象ファイルなど設定を記述していく。

 

npm install

npm install コマンドを実行すると、package.jsonに記述されているパッケージが一括でインストールされる。

 

参考:

https://tofusystem.work/programming-lesson/howto-heroku-npm-install/

フロントエンド開発の3ステップ(npmことはじめ) - Qiita

Laravel mixのアセットがherokuで動かない時の対処法

webpackをかんたんに使う(Zero Configulation) - Qiita

npm入門 - Qiita

BAPIとは?SAPとは?

未経験からエンジニアに転職して2ヶ月が経ち、現在は既存サイトの保守運用を行ってます。

業務では今まで全く勉強してなかった、ややレガシーなツール?を扱うことが多く、戸惑うことも多いので、扱ってみて分かったことを少しずつ記事にしていこうと思います。

 

 

用語の意味が理解できない

業務ではAsteriaというノーコードでデータ連携システムを構築できるミドルウェアを使っているのですが、そこで度々登場していたのが「BAPI」、「SAP」という言葉。

Asteriaとは…アイコンのドラッグ&ドロップとプロパティの設定で作成するフローによって既存のデータベース、ファイルシステム、各種業務システム、各種クラウドサービスと簡単に接続、連携することのできるデータ連携ミドルウェアです。

https://www.asteria.com/jp/warp/feature/

 

BAPIとは?SAPとは?と全然用語の意味が理解できなかったので、ザックリ調べてまとめます。

 

まず、BAPIとは?

BAPI はBusiness Application Programming Interfaceの略で、SAPのデータを取得したり更新したりするためのインタフェース(API)です。

実体はABAP言語で作成されている汎用モジュール(プログラム)です。通常の汎用モジュールとの違いは、BAPIは外部システムからリモート呼び出し可能な汎用モジュールになっている事です。

 

https://logist.bz/sap/577/

https://z00001.blog.fc2.com/blog-entry-132.html

 

 

では、SAPとは?

「SAP社」が製造する「ERP」製品のこと。

 

ERPとは?

ERP(Enterprise Resource Planning)の略。

企業全体を経営資源の有効活用の観点から統合的に管理し、経営の効率化を図るための手法・概念のこと。

 

ERPは、次の5つに分類されたシステムを統合し、ユーザーへ提供します。

  • 会計管理システム
  • 販売管理システム
  • 在庫購買管理システム
  • 生産管理システム
  • 人事給与管理システム

 

つまり、「会計」「人事」「生産」「物流」「販売」といった業務を一括で管理する為のシステム。という事みたいです。

https://www.grandit.jp/erp/

https://ja.wikipedia.org/wiki/企業資源計画

 

まとめ

BAPIとは…

SAPのデータを取得したり、更新したりする事ができるAPI

 

SAPとは…

SAP社のERP

 

ERPとは…

「会計」「人事」「生産」「物流」「販売」といった業務を一括で管理する為のシステム。

git rebase・git stash・その他 Gitコマンドまとめ

エンジニアとして働くことが決まったので、初学者として最もやらかしそうなGitについて復習しました。

 

 

今回、自分が復習して「そうなんだ」と改めて知った部分や、使いそうなコマンドだけ備忘録としてまとめておこうと思います。

間違い、指摘等あれば教えて頂けると助かります。

 

教材 

今回、復習するにあたってUdemyで山浦さんの「Git:もう怖くないGIT! チーム開発で必要なGitを完全マスター」を使用しました。

山浦さんはYoutube動画で、Dockerについて勉強しており丁寧で分かりやすかったので、「Gitに関しても丁寧にまとめてくれているかなぁ」と思い、購入しました。

https://www.udemy.com/share/1021OE3@OIbGYYkkqZHQvJrdSzlcouKyVua8yXftd6YSdtPsjmafERM_3LS6De3YgU4i0-3xcw==/

 

 

git add・git commit での詳細な処理内容

git add

ワークツリー(手元の作業場)のファイルを

ローカルリポジトリに「圧縮ファイル(blobオブジェクト)」にして作成

ステージに元のファイル名と圧縮ファイルを「ツリーファイル」として保存

 

git commit

ステージにあるツリーファイルをローカルリポジトリにツリーとして保存し、コミットファイルを作成。

コミットファイルの中身は

・ツリー

・親コミット(直前のコミット)

・作成者

・日付

・コミットメッセージ

 

 

*正直、git addで圧縮ファイルが生成されていることやツリーファイルが作られていることは知らなかったです(汗)

 

 

git rebase

ざっくり言うと、コミットの履歴をきれいにする(履歴を修正する)コマンド。

 

git rebaseの注意点

リモートにpushしてあるコミットはリベースしない。

 

git rebaseのデメリット

コンフリクトが生じた場合、各コミットでの修正が必要。

 

 

git rebaseで複数のコミットをやり直す

$ git rebase -i <コミットID>

やり直したいコミットを「edit」にする

やり直したら実行する

$ git commit --amend

次のコミットへ進む

$ git rebase --continue

 

例)

$ git rebase -i HEAD~3

(2つ前のコミットからやり直すことができる)

pick gh21f6d ヘッダー修正

pick 193054e ファイル追加

pick 84gha0d README修正

(先頭のpickをeditに変更すると、そのコミットをやり直すことができる)

edit gh21f6d ヘッダー修正

pick 193054e ファイル追加

pick 84gha0d README修正

$ git commit --amend

$ git rebase --continue

 

git rebaseでコミットの順番を入れ替える・削除する

$ git rebase -i <コミットID>

コミットの順番を入れ替えるor削除する

$ git commit --amend

 

例)

$ git rebase -i HEAD~3

pick gh21f6d ヘッダー修正

pick 193054e ファイル追加

pick 84gha0d README修正

(順番の入れ替えor削除)

pick 193054e ファイル追加

pick gh21f6d ヘッダー修正

 

git rebaseでコミットをまとめる

$ git rebase -i <コミットID>

コミットをまとめる

pickを「squash」にするとその前のコミットとまとめることができる

 

例)

$ git rebase -i HEAD~3

pick gh21f6d ヘッダー修正

pick 193054e ファイル追加

pick 84gha0d README修正

(コミットをまとめる)

pick gh21f6d ヘッダー修正

squash 193054e ファイル追加

squash 84gha0d README修正

 

git rebaseでコミットを分割する

$ git rebase -i <コミットID>

pickを「edit」にしてコミットをやり直す

コミットを取り消し

$ git reset HEAD^

分割したい内容でadd & commit を行いコミットをやり直す

$ git rebase --continue

 

コミットの指定方法

HEAD     現在の作業場所

HEAD~     親コミットを指定できる

HEAD~1    HEADの1つ上の親コミット

HEAD~2 HEADの2つ上の親コミット

HEAD^   マージ後の複数ある親の中から指定できる

 

*HEAD^に関してはこちらの記事が分かりやすかったです。

https://qiita.com/chihiro/items/d551c14cb9764454e0b9

 

 

タグ付け

タグの表示

$ git tag

 

指定したタグの表示

$ git tag -l "指定する文字列"

例)

$ git tag -l "release"

 

release_20210824

release_20210721

release_20210515

と表示される

 

タグの作成(注釈付き)

$ git tag -a <タグ名> -m "メッセージ"

例) $ git tag -a 20170501_01 -m "20170501のバージョン01"

 

タグの作成(軽量版)

$ git tag <タグ名>

例) $ git tag 20170501_01

 

後からコミットにタグ付けする

$ git tag <タグ名> <コミット名>

例) $ git tag 20170501_01 8a6cbc4

 

タグデータの表示

$ git show <タグ名>

・タグ付した人の情報

・タグ付したにちじ

・注釈メッセージ

・コミット

が表示される。

 

タグをリモートリポジトリにpushする

$ git push <リモート名> <タグ名>

例) $ git push origin 20170520_01

 

全てのタグをpushする

$ git push origin --tags

 

 

一時避難(stash)

 

ワークツリーとステージの変更を避難させる。

$ git stash

 

避難した分を確認

$ git stash list

 

最新の避難した分を復元する

$ git stash apply

 

ステージの状況も復元する

$ git stash apply --index

 

特定の作業を復元する

$ git stash apply <スタッシュ名>

例) $ git stash apply stash@{1}

 

最新の避難した分を削除

$ git stash drop

 

特定の作業を削除

$ git stash drop <スタッシュ名>

例) $ git stash drop stash@{1}

 

全ての避難した分を削除

$ git stash clear

 

 

その他コマンドまとめ

$ git commit

ステージされたスナップショットをコミット。エディタ上でコミットメッセージを入力する

 

$ git commit -m

インラインでメッセージを記述し、コミット

 

$ git commit -v

エディタ上で変更を確認し、コミット

 

$ git commit --amend

直前のコミットを修正

 

$ git status

変更したファイルの一覧を確認

 

$ git diff

ステージに追加する前の変更分をソースコードとして確認

 

$ git diff --staged

ステージに追加した後の変更分をソースコードとして確認

 

$ git rm <ファイル名>

git、ワークツリー両方からファイルを削除

 

$ git rm -r <ディレクトリ名>

git、ワークツリー両方からディレクトリを削除

 

$ git rm --cached <ファイル名>

ワークツリーにはファイルを残すがgit上からは削除

 

$ git mv <旧ファイル> <新ファイル>

ファイル名の変更

 

$ git checkout -- <ファイル名>

ファイルの変更を取り消す(ステージの情報をワークツリーに上書き)

 

$ git checkout -- <ディレクトリ名>

ディレクトリの変更を取り消す

 

$ git checkout --.

全取消し

 

$ git reset HEAD <ファイル名>

ステージしたファイルの変更を取り消す(ローカルリポジトリからステージに上書き)

 

$ git reset HEAD <ディレクトリ名>

ステージしたディレクトリの変更を取り消す(ローカルリポジトリからステージに上書き)

 

$ git reset HEAD .

ステージした全部の変更を取り消す(ローカルリポジトリからステージに上書き)

 

$ git commit --amend

直前のコミットをやり直す(今のステージの内容で直前のコミットを修正する)

pushしたコミットに関してはやり直してはいけない。

 

 

 

要件定義、基本設計、詳細設計について改めて調べてみた

ようやくエンジニアとしての就職が決まり、SESとして働くことになりました。

 

「スキルシート」なるものを記入することになったのですが「基本設計と詳細設計ってどう違うんだっけ?」となったので、曖昧だった言葉の定義を調べてみました。

 

 

要件定義

システム開発などのプロジェクトを始める前の段階で、必要な機能や要求をわかりやすくまとめていく作業のことです。 

要件定義でクライアントへのヒアリングを通じ、要求機能一覧や業務フローなどを作成していきます。

 

基本設計

基本設計は、要件定義の結果(WHAT)を「HOW」に落とし込むプロセスです。「外部設計」とも呼びます。

つまり、システムを外から見たときのふるまいを明らかにするのが基本設計のゴールです。

また、基本設計はエンドユーザにとっては「機能の説明書」のような役割を果たします。したがって、基本設計書はエンドユーザ向けの分かりやすい表現が求められます。

  

詳細設計

詳細設計では、基本設計で明確化された「HOW」をさらにプログラマー向けに詳細化します。

基本設計でざっくり考えた概要を元にして、実際のプログラムが作れるまで細かく落とし込む工程。

 

Vモデル

今回初めて知ったのですが、Vモデルとは、システム開発プロジェクトにおける開発工程とテスト工程の対応関係を表した1つのモデルだそうです。

下記の図は、Vモデルを一般的なイメージで表したものです。

f:id:fluid_27:20210819204840p:plain

 

ザックリまとめ

「要件定義」開発するシステムに組み込む機能をまとめたもの。

「基本設計」システムを外から見た時の振る舞いを決定するもの。

「詳細設計」要件定義や基本設計で決まった要件をプログラマー向けに詳細にしたもの。

 

 

調べた感想

今回まとめた内容は超基本的な事だと思いますし、以前にさらっと勉強したことあったのですが、「ぼんやり分かったつもりでいる」状態が一番危ないような気がして、改めて調べてみました。

また、スキルシートの作成に伴って、「自分が学習してきたこと、やったことを全然言語化できてない」と実感しました。

これからエンジニアの方々とコミュニケーションをとる際には言語化の能力は必須だと思うので意識してやっていこうと思います。

 

 

https://it-biz.online/it-skills/design-documents/

https://products.sint.co.jp/obdz/blog/system_design_flow

https://products.sint.co.jp/obdz/blog/basic-design-detailed-design#toc-0

https://wa3.i-3-i.info/diff236design.html

macのターミナルからVisual Studio Codeを起動させる方法

プログラミング初学者です。

tipsというか、初学者ならではの「そうなんだ!」という共有というか報告です。

 

ターミナルからでもVSCodeを起動させられる

 

プログラミングの動画を観て、勉強していたところ、macのターミナルで「code」と打って、VSCodeを起動させているのを発見しました。

 

「そんなことできるんだ!!」と思い、早速マネしてみるも、出来ない。。

なぜ?と思いググっていると、VSCodeでの設定が必要だったみたいです。

 

VSCodeでの設定

 

VSCodeを開いた状態で「Command + Shift + p」でコマンドパレットを開いて、「shell command install」と打って検索。

 

シェルコマンド: PATH内に ‘code’ コマンドをインストールします

と表示されるのを選択。

これだけでいいみたいです。

 

使い方

$ code ファイルのパス

でファイルをVSCodeで開くことができます。

 

$ code .

とすることで現在のディレクトリをVSCodeで開くことができます。

 

簡単。便利。以上です。