Tech Hotoke Blog

IT観音とは私のことです。

【IntelliJ】コマンドラインからプロジェクトを立ち上げる

f:id:TechHotoke:20220317002200p:plain

経緯

いちいちfinderからプロジェクトのフォルダを選択するのが面倒臭く、VSCodeのようにコマンドラインからプロジェクトを立ち上げることが可能か調べてみた。

環境

  • Mac OS
  • InteliJ 2021.3.1(Ultimate Edition)

操作

f:id:TechHotoke:20220317001529p:plain

f:id:TechHotoke:20220317001555p:plain

idea <立ち上げたいプロジェクト名>を入力して新規ウィンドウが起動すれば完了です!

【Git】プルリクエストに含まれる不要なコミットを削除する

f:id:TechHotoke:20220315115551p:plain

目的

Gitをなんとなく使わないようにするために、操作で詰まったこと、やりたいことの対処方法をまとめて、それらを深堀して理解を深めること

前提

  • Gitがインストールされていること
  • GitHubのアカウントが存在すること
  • GitHubリポジトリが存在すること
  • ITパスポートレベルのネットワークの用語などが分かること

やりたいこと

  • Pull Requestを出した後に、不要なコミットコミットログから削除したい

対応

  1. ローカルで該当のブランチに移動
  2. git rebase -i HEAD~(~はさかのぼりたいコミットの数分入力するまたは、~<さかのぼりたいコミットの数字>の書式でも可)
  3. 参考1のようにログが出てきます(5個のログをさかのぼる場合)
  4. 消したいcommitを行ごと消して保存(他のブランチで必要なコミットである場合は、必ずそちらのブランチにコミットログが存在することを確認してから実行してください)
  5. git push -f を実行して完了
参考1
pick eafa87e Remove hogehoge
pick e4ff1a5 Kick out hogehoge
pick 1e5f766 Remove fuga
pick e90e305 Fix design for hogehoge
pick fc1c368 Work in progress

【 20220318 追記】

ご指摘頂いたため追記しました。

  • PR内で「変なコミットが入っていますが、間違いなので無視してください」と自分でコメントしておくのが一番いい

コミットログは一種の「歴史」です。「不要なコミットを取り除きたい」ということは、「歴史を改竄したい」ということに等しいです。

PRに混入している「不要なコミットコミットログ」の程度にもよりますが、「ごめんね」で許されそうな軽微なものであればコメントを書いておわり、で十分だと思います。僕自身も業務でたまにそういう運用をしています。

  • レビュアーが困惑するぐらいひどい状況であれば、もう一度新しいブランチを作って、そこでコードを書き直してPRを再作成する方がいい

rebaseについて

基本構文

git rebase BaseBranch

に、現在いるブランチでおこなった全てのコミットを適用します。

挙動

  1. 現在のブランチ(D,E,Jコミット)でおこなわれた変更を一時的に保存
  2. 移行先のブランチ(master)にリセットする(git reset --hard master)
  3. 1で一時的に保存したコミットを順番に適用していく(親が違うので、コミットIDも変わる)

  4. 参考: 初心者でもわかる!リベースの使い方を解説します | 株式会社LIG

-iオプションについて

  • rebase --interactiveと同義
  • リベースのinteractiveモード
  • 今回は下記の接頭辞は修正していないが、これらを書き換えることでコミットメッセージの変更(一つ前のコミットメッセージの変更ならば、git commit --amendでいけます)などを行う事が可能
pick:コミットを採用
reword:コミットを採用するがコミットメッセージを変更
edit:コミットを採用するがファイルを修正する
squash:一個前のコミットと合体させる
fixup:コミットメッセージを変更しない点以外squashと同じ
exec:shellでコマンドを実行する

rebaseを使う時の注意点

  • 他人のコミットを決してリベースしてはいけない
    • 複数人での作業の場合、リモートにあるレポジトリを無理矢理リベースしたら、全く同じコミットが重複する可能性大
    • 新規コミットを作っているので、当然コミットIDも変わります。したがって、他の開発者のローカルにあるコミットをリベースしちゃうと、コミットIDが変わり、すでに存在している同じコミットと区別がつかなくなり、重複してしまうからNGです

rebaseを取り消したい時は、、、

git reflogで操作歴を見て、戻したいポイントを見つけたらgit reset --hard


今回はここまでです!

お付き合いいただきありがとうございます!!

【Linux】さくらVPSにインストールしたサーバーにクライアント側からSSH接続でログインする

f:id:TechHotoke:20220309222010p:plain

目的

表題の作業の手順や注意すべきポイント、 自分のエラーの記録などを残すこと。

環境

ローカル:Mac BigSir 11.4 M1 シェル:zsh リモート:Debian11 64amd シェル:bash

前提

  • リモートサーバーにsshがインストールされていること
  • 一般ユーザーが作成されていること

作業

管理用ユーザーの作成

usermod -G wheel <既存の一般ユーザー>

usermodコマンドはユーザーのホームディレクトリやグループ、パスワードなどを変更するためのコマンドです。

f:id:TechHotoke:20220309225724p:plain

どうやらwheelグループが存在しないようで、代わりにsudoが存在しています。Debianにはwheelがデフォルトで存在しないため作成する必要があるそうです。

f:id:TechHotoke:20220309225633p:plain

  • 参考:

https://atmarkit.itmedia.co.jp/ait/articles/1612/14/news022.html

http://hnakamur.blogspot.com/2008/12/debianwheel.html

  • とりあえずまずは一般ユーザーがsudoを使えれば良いので、usermod -G sudo <ユーザー名>でいきます

  • 一般ユーザーにログインし直して、適当なファイルを作成し、sudo chmod 777 hogehoge的なコマンドを叩いてsudoが使えることを確認します

SSHの設定を書き換え~接続試行

  • /etc/ssh/sshd_configファイルを開きます

  • PermitRootLogin no:rootユーザーでのログインを禁止

  • Port <任意のポート番号>:ポートをデフォルトから変更(ウェルノウンポートと被らないように注意)

  • PubkeyAuthentication yesSSHプロトコル ver.2 で公開鍵認証を許可する

  • ファイルを保存した後、sudo systemctl restart sshで設定の変更を反映

SSHキーの生成から転送

  • サーバー側に~/.sshディレクトリを作成し、sudo chmod 755 ~/.sshでパーミションを変更する

  • クライアント側(今回だとローカル環境)に~/.sshディレクトリを作成し、sudo chmod 700 ~/.sshでパーミションを変更する( ここのパーミッションが重要

  • クライアント側の.sshディレクトリ上でssh-keygen -t eded25519コマンドを実行

    • RSAが使われることが多いようですが、ED25519 の方が RSA よりも強度が高く、しかも速いためこちらを使用
  • パスフレーズなどは設定せずに生成し、添付画像のようになっていればOKです f:id:TechHotoke:20220310183805p:plain

  • 続いて、scp -p <設定したポート> id_ed25519.pub <root以外のユーザー名>@49.212.179.153:~/.ssh/コマンドで生成した公開鍵(.pubの方)をリモートサーバーに転送します。

  • リモートサーバーの~/.ssh/ディレクトリ配下に公開鍵がコピーされていればOKです

  • サーバに転送した公開鍵のパーミションをsudo chmod 600 <鍵名>に変更( OpenSSHでは~/.ssh/内のファイルがモード600[ユーザーのみ読み書き可能]でないと使用できないため

  • ssh -i ~/.ssh/id_ed25519 -p <設定したポート> <root以外のユーザー名>@<ホスト>で接続試行し、ログインできればOKです

パスワードなしで接続を可能にする

  • /etc/ssh/sshd_configファイルを開きます
  • PasswordAuthenticationnoにします
  • sudo systemctl restart sshを実行します
  • クライアント側でssh -i ~/.ssh/id_ed25519 -p <設定したポート> <root以外のユーザー名>@<ホスト>で接続試行すると。。。

  • Permission denied (publickey).と突然怒られました。。。Damn...

Permission denied (publickey)の解消

  • ~/.ssh直下にtouchコマンドでauthorized_keys(接続を許可する公開鍵を登録しておくサーバー側のファイル)を作成
  • sudo chmod 600 authorized_keysコマンドでパーミションの変更
  • /etc/ssh/sshd_configファイルを開きます
  • AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2コメントアウトを外します
  • sudo systemctl restart sshを実行します
  • 再度、クライアント側で接続確認し、正常に行われることを確認できればOKです

補足

  • デバッグssh -vT <ユーザー名>@<ホスト>で(-v:ログ出力、-T:疎通確認)

今回はここまでとなります!

お付き合い頂きありがとございます!

参考

【Linux】Vimとお友達になりたいドン!~Vimのカスタマイズ~

f:id:TechHotoke:20220311141025p:plain

目的

敬遠されがちなVimと是非ともお近づきになって、テキストエディタ何使ってますか?「Vim」です(ドヤァ)ってなること

前提

  • Linuxの使用経験があること
  • Linuxの基本的な知識があること
  • Vimが嫌いなこと

環境

設定ファイル

~/.vimrc

クリップボードからペーストできるようにする

set clipboard=unnamed,autoselect

unnamed:ヤンクしたテキストそのままクリップボードにコピー

autoselect:vim上でハイライトして選択したテキストがクリップボードにコピー

方法

https://ylabdesk.com/vim-copy-paste

シンタックスハイライトをつける

syntax on

行番号を表示する

setnumber

選択行の背景にハイライトをつける

set cursorline

Vimを再起動せずに設定の変更を反映する

source ~/.vimrc

補足

シェル上でvimtutorコマンドを叩いてみると主要な機能を網羅した素晴らしいチュートリアルが始まります(最初に言え)

参考

【Linux】メモーさくらVPSのVNCコンソールの沼に浸った件ー

f:id:TechHotoke:20220311134046p:plain

環境

経緯

  • さくらVPSVNCコンソール上で、rootユーザーのパスワード設定、一般ユーザーの設定などを行った後に、シリアルコンソールやクライアントからSSH接続を試みても、認証が通らずひたすら苦しんだ

結論

  • OSのキーマップがUS配列でシリアルコンソール・クライアントで使用していたコンソールのキーマップが日本語配列だったためその差異で入力値が間違っていた

具体的には

@が含まれていたのですが、US配列では日本語配列上の@は[となるため、そこが違っていた。

これから気をつけろよ自分

  • 認証エラーなんだから、まずパスワードが正しいか確認しろよ(思い込み注意)
  • 作業している環境の差異に着目しろよ
  • 困ったらちゃんと公式サポート頼れよ

これから気をつけます。。。

【Linux】Linux 再入門

f:id:TechHotoke:20220307234725p:plain

目的

Linuxの基本的な構成などを体系的にまとめること

前提

  • ローカル環境:Mac OS
  • サーバー環境:Debian11
  • 基本的なLinuxの知識があること
  • Linuxの各コマンドの説明は一部にとどめる

Linuとは?

カーネル

  • Linux = カーネル(OSの中核的存在)で単体で動作することは不可能
  • だが、一般的にLinuxと言えば、ツール・アプリケーションなど全て含んだLinux distributionを指す

シェル

  • カーネルインターフェイスとなっているソフトウェア
  • シェルとカーネルが切り離されていることで、シェルの切り替えが容易になったり、シェルがクラッシュしてもカーネルへの影響を抑えることができます
  • bash,zshなど様々な種類のシェルが存在します。LinuxのデフォルトシェルはbashですがMacではzshがデフォルトとして採用されるようになりました。
  • シェルも一つのコマンドに過ぎない→コマンドで切り替えが容易に可能

カーソルの移動

  • 後方に1文字移動:Ctrl + b
  • 前方に1文字移動:Ctrl + f
  • 行頭に移動:Ctrl + a
  • 行末に移動:Ctrl + e
  • 後方に一単語分移動:Alt → b
  • 前方に一単語分移動:Alt → f
  • カーソル位置から行末まで削除:Ctrl + k
  • カーソル位置から行頭まで削除:Ctrl + u
  • 最後に削除した内容を削除:Ctrl + y
  • 画面を消去する:Ctrl + l
  • コマンド履歴を検索する:Ctrl + r
カーネルの役割

メモリー管理:どの程度のメモリーが、何をどこに保存するために使用されたか、追跡します。
プロセス管理:どのプロセスがいつ、どれだけの期間、中央処理装置 (CPU) を使用できるかを決めます。
デバイスドライバー:ハードウェアとプロセスの間の仲介者/通訳として機能します。
システムコールとセキュリティ:プロセスからサービス要求を受け取ります。

参考: https://www.redhat.com/ja/topics/linux/what-is-the-linux-kernel#:~:text=Linux%C2%AE%20%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB%E3%81%A8%E3%81%AF,%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%92%E7%AE%A1%E7%90%86%E3%81%97%E3%81%BE%E3%81%99%E3%80%82

ファイル・ディレクト

f:id:TechHotoke:20220307165321p:plain

引用:新しいLinuxの教科書

  • Windowsとの違いはディスクが何台あってもLinux システム前提で一つのディレクトリーツリーしか持たない

  • ディレクトリ毎の役割

    • /bin:Linuxシステムの動作に最低限必要な重要度の高いコマンドが格納されているディレクト
    • /dev:デバイスファイル(ディスクやキーボードなど)を格納するディレクト
    • /etc: 設定ファイルを置くためのディレクトリ。Linux自体の設定ファイルもここに格納されているので非常に重要
    • /home:ユーザー毎に割り当てられるホームディレクトが可能されてるディレクト
    • /sbin:管理者ユーザー向けのコマンドが格納されているディレクトリ。shutdownコマンドなど
    • /tmp:一時的なファイルを格納するディレクトリ。このディレクトリ内のファイルは定期的に削除する設定がデフォルトになっているディストリビューションも あるため注意が必要
    • /usr:各種アプリケーションと、それに付随するファイルを置くためのディレクトリ。サブディレクトリにbinやsbin、etcなどを持ちルートディレクトリと似た構造を持つ
    • /var:変化するデータ(ログや電子メールなど)を格納するためのディレクトリ。容量を逼迫することが多いので、システム管理上注意が必要

ソフトウェアパッケージ

  • パッケージ管理システムでは、「 パッケージ」を単位としてインストール・アンインストールの管理を行います
    • パッケージとは、ソフトウェアの実行ファイル・ドキュメントファイル・設定ファイル・インストール 時に必要なスクリプトなどをまとめてアーカイブした1つのファイルをさします
  • パッケージファイル形式はrpmdebの二種類に大別されます。今回使用しているDebiandeb形式を採用しています

f:id:TechHotoke:20220307173209p:plain

引用:新しいLinuxの教科書

  • パッケージファイルをまとめているリポジトリからパッケージ情報・パッケージファイルを取得し、インストールします
  • CentOSなどRedHat系ではyum UbuntuなどのDebian系ではaptが使われることが多い
  • 基本的なコマンドはapt-getapt-cache
    • apt-get:install,remove,purge(設定ファイルもふくめて削除)などインストールや削除を行う
    • apt-cache:search,showsrc などパッケージ情報の参照を行う

参考:

aptコマンドチートシート - Qiita

参考

  • 新しいLinuxの教科書
  • Lpicの基本が1週間で学べる本

スクラム開発実践入門のまとめ

f:id:TechHotoke:20220305233100p:plain

目的

下記書籍のポイントをかいつまんでまとめること。 この記事を振り返り内容を復習すること。

読者のレベル感

  • ソフトウェア開発の経験がすでにある人が読むとより内容が入ってきやすい印象
  • アジャイル開発をこれからチームに導入しようと検討している方向け

ソフトウェア開発の困難にスクラムで立ち向かう

ソフトウェア開発を困難にする要因

  • 物質的な不可視性
  • 目指す機能的な不可視性
  • コミュニケーションの不可視性

これらを解決するにはまず問題を全体として捉えるのでは無く整理、分解することが重要

その方法として、 5w1h フレームワークが推奨されている

特に、

what(目指す機能的な不可視性を解決する)how (コミュニケーションの不可視性を解決する)が重要

スクラムとは?

従来の各工程を他と交わらずに進める開発スタイルをリレー競争型と表現し、

スクラムは各工程が次工程とオーバーラップするように開発を進めるスタイルを指す

スプリント

  • 開発期間の最小単位
  • 1Week〜1Month

役割

  • プロダクトオーナー
    • what
    • 課題達成のために何を作るべきか明確に定める
  • スクラムマスター
    • how
    • 人間関係のようなコミュニケーションをどのように円滑に進めるかに責任を持つ

2人のリーダーが存在することが特徴

スクラムで立ち向かう

  • 自己組織化(スクラムチームのメンバー全員がチームの理想とする姿を考え、その理想に向かって能動的に学習と成長をし続けている状態)を目指す

スクラムにおけるロール

  • スクラムマスター
  • プロダクトオーナー
  • 開発チーム

ロールと役職は別物

プロダクトオーナー

  • プロダクトオーナーは1人
  • プロダクトの価値の最大化に責任を持つ
  • 何を作るべきかの最終決定権はプロダクトオーナーにある
  • 責任の所在を明確にし、プロダクトに妥協を許さないために開発チームとは明確に独立している
  • 要件の決定権、優先順位付けの権限もある

開発チーム

  • プロダクトオーナーが定めた要件を優先順位に従って開発する専門家の集団
  • 3〜9人が望ましい
  • 機能横断的であること(プロダクトの完成に必要な能力をチームが持っている事)
  • 職種の違いによって区別されない

スクラムマスター

  • スクラムチームや組織がスクラム開発を行う上でのサポートを行う
  • 基本プロダクトには関与しない
  • チームに1人(4〜10人に1人が適切)
  • プロダクトオーナーの支援
  • 開発チームの支援
  • 組織全体への支援

スクラムイベント

検査と適応で変化に順応する

  • スプリント

    • スクラムでの開発期間の1単位
    • 1w〜1M程度
    • リリース判断可能なプロダクトを作る
  • リリーススプリント

    • スプリントの中で残ったタスクを処理する特別なイベント
  • スプリントプランニング

    • スプリント開始時に「スプリント期間内で何ができるか」「どうやって達成させるか」の2点を明らかにするミーティング
    • リファインメント(スプリントプランニングの準備→次のスプリントに写れるようにプロダクトバックログを整理する活動
    • プロダクトバックログはプロダクトで何を実現すべきかを優先順位をつけて一覧化したもの
    • それらの各項目のことをプロダクトバックログアイテムと呼ぶ
    • プロダクトバックログアイテムの内容を具体化することで完了とする
    • スプリントゴールの設定:ベロシティを参考にスプリント中に達成したい目標やバックログアイテムのこと
      • ベロシティ:1スプリントにスクラムチームが完成させることができる仕事量
    • スプリントバックログの作成
      • スプリントバックログ:スプリント期間内で行うと判断したプロダクトバックログアイテムと、それらのプロダクトバックログアイテムを実現するためのタスクを、俯瞰できるよう一覧化したもの
  • デイリースクラム

    • 1日に1回15分間のタイムボックスで、進捗や予定、問題の共有を行うミーティング
  • スプリントレビュー

    • スプリント期間中に作成したリリース判断可能なプロダクトであるインクリメントの確認を行い、フィードバックを得るためのミーティング
  • スプリントレトロスペクティブ

    • 仕事の現状を見なおし改善策を話し合う場のこと