そんなに難しくないことですが、備忘録として。
datetime型を整形する
というだけであれば
date('フォーマット', 'タイムスタンプ')
で整形できる。
date('Y/m/d', strtotime($updated_at));
とすると
2022/05/26
のように表示される。
Laravel + tailwindでボタンデザインのチェックボックスを実装
現在作成しているlaravelアプリにチェックボックスを組み込んだですが、デザインをボタンぽくしたかったのでtailwindで実装してみました。
同様のことを生のCSSで書いて解説しているブログはけっこう見つかったのですが、tailwindで実装しているのは見つからなかったので、自分自身の備忘録も兼ねて完成したソースを残しておきます。
完成画面
最終的に下図のような感じで、ボタンっぽいデザインにしました。
選択済み・マウスホバー時には色が濃くなるようになってます。
完成版ソース
{{-- タグ選択 --}}
@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 }}"
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 }}]"
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より引用
との事。えーっと、、、結局なに？
どのように利用されるのかを調べてみると、
Excelなどでファイルを開く際に
BOM付きでなければ符号化方式がUTF-8なのかUTF-16なのか、またはUTF-32なのか、あるいはまったく別の文字コードなのか判断できないことがあります。
とあり、更に
一方、Webページとして使用されるHTMLファイルの場合はBOM無しで保存・上書きする方が良いとされています。これはWebページを動的に処理するPHPなどのプログラムがBOM付きのテキストファイルを正常に処理することができないことがあるからです。
との事。
まとめると
BOMとは、「そのデータの符号化方式の種類が何なのか（UTF-8、UTF-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 runコマンド
- Herokuでnpmを使えるようにする
- 解決法
- 余談
- Laravel Mixとは
- webpackとは
- package.jsonとwebpack.mix.js
- npm install
そもそも、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","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/
フロントエンド開発の３ステップ（npmことはじめ） - Qiita
Laravel mixのアセットがherokuで動かない時の対処法
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://z00001.blog.fc2.com/blog-entry-132.html
では、SAPとは？
「SAP社」が製造する「ERP」製品のこと。
ERPとは？
ERP（Enterprise Resource Planning）の略。
企業全体を経営資源の有効活用の観点から統合的に管理し、経営の効率化を図るための手法・概念のこと。
ERPは、次の5つに分類されたシステムを統合し、ユーザーへ提供します。
- 会計管理システム
- 販売管理システム
- 在庫購買管理システム
- 生産管理システム
- 人事給与管理システム
つまり、「会計」「人事」「生産」「物流」「販売」といった業務を一括で管理する為のシステム。という事みたいです。
https://ja.wikipedia.org/wiki/企業資源計画
まとめ
BAPIとは…
SAPのデータを取得したり、更新したりする事ができるAPI。
SAPとは…
SAP社のERP。
ERPとは…
「会計」「人事」「生産」「物流」「販売」といった業務を一括で管理する為のシステム。
Gitあれこれ① git rebase・git stash・その他 Gitコマンドまとめ
エンジニアとして働くことが決まったので、初学者として最もやらかしそうなGitについて復習しました。
今回、自分が復習して「そうなんだ」と改めて知った部分や、使いそうなコマンドだけ備忘録としてまとめておこうと思います。
間違い、指摘等あれば教えて頂けると助かります。
教材
今回、復習するにあたってUdemyで山浦さんの「Git：もう怖くないGIT! チーム開発で必要なGitを完全マスター」を使用しました。
山浦さんはYoutube動画で、Dockerについて勉強しており丁寧で分かりやすかったので、「Gitに関しても丁寧にまとめてくれているかなぁ」と思い、購入しました。
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 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モデルとは、システム開発プロジェクトにおける開発工程とテスト工程の対応関係を表した１つのモデルだそうです。
下記の図は、Vモデルを一般的なイメージで表したものです。
ザックリまとめ
「要件定義」は開発するシステムに組み込む機能をまとめたもの。
「基本設計」はシステムを外から見た時の振る舞いを決定するもの。
「詳細設計」は要件定義や基本設計で決まった要件をプログラマー向けに詳細にしたもの。
調べた感想
今回まとめた内容は超基本的な事だと思いますし、以前にさらっと勉強したことあったのですが、「ぼんやり分かったつもりでいる」状態が一番危ないような気がして、改めて調べてみました。
また、スキルシートの作成に伴って、「自分が学習してきたこと、やったことを全然言語化できてない」と実感しました。
これからエンジニアの方々とコミュニケーションをとる際には言語化の能力は必須だと思うので意識してやっていこうと思います。
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
