アルゴリズムの定石?なのかもしれませんが、今まで知らずにいました。わかりやすい説明がありました。時間がかかる探索などに有効なようです。これを、実際の場面に適用するのは、また別の難しさがありそうですが。
https://dai1741.github.io/maximum-algo-2012/docs/dynamic-programming/
アルゴリズムの定石?なのかもしれませんが、今まで知らずにいました。わかりやすい説明がありました。時間がかかる探索などに有効なようです。これを、実際の場面に適用するのは、また別の難しさがありそうですが。
https://dai1741.github.io/maximum-algo-2012/docs/dynamic-programming/
P258 git init -b main fluff 開発(ノンベア)リポジトリの作成
git init --bare -b main fluff-bare ベアリポジトリの作成(権威ある参照箇所)
--bareオプションを指定してgit cloneを実行すると、ベアリポジトリが作られる
P261 リモートの作成 git remote .git/configにリモートがある git configで操作
P263 リポジトリのブランチの分類: リモート追跡ブランチ(リモートリポジトリの追跡が目的)、ローカル追跡ブランチ(開発ブランチとリモート追跡ブランチの変更の両方を集める)、トピックブランチ(開発ブランチ)、リモートブランチ(リモートリポジトリにある)
P214 git cherry-pick 指定したコミットFをカレントブランチに加える 以下の場合はF’
A-B-C-D-E-F-G-H dev A-B-C-D-E-F-G-H dev
| |
V-W-X-Y-Z rel_2.3 V-W-X-Y-Z-F' rel_2.3
git checkout rel_2.3 のあと git cherry-pick dev~2
P217 reset,revertとcheckoutの関係
ブランチを移るとき:git checkout またはgit switch
git resetはブランチ切り替えはしない:ブランチ名指定するとカレントブランチをリセットしてしまう git rest --hardは既知の状態を復元することが目的
P218 他の開発者があなたの李ぴ時取りをクローンしたり、一部のコミットをフェッチしたりしているときは、リポジトリ内のコミット履歴を書き換えるようなコマンドを使うべきではない。代わりにgit revertを使う。git resetやgit commit --amendを使ってはならない。
P219 rebaseについて:書籍にはないが、簡単な例で試してみる
①topicブランチで git rebase main ②mainブランチで git merge --no-ff topic
(--no-ffはfast-forwardなしで、そのほうがあとで管理しやすいとのこと)
③git log --graph で確認できる
もし、①で競合が発生したら、②エディタで競合の原因(main_file)を編集し、競合を解決 ③git add main_file git rebase --continue(P220) ④mainブランチで git merge --no-ff topic
P221 rebaseを途中でやめたいとなったら git rebase --abort
P225 git rebase -i コミット とすると、指定したコミット以降のコミットが編集可
エディタで先頭のpickをsquashにすると、直前のコミットの結合され、新しいコミットメッセージのテンプレートができる。先頭の#は無視される。
P134 作業ディレクトリのファイルを書き換えたり、git addやgit rmでインデックスを書き換えると、リポジトリの作業ディレクトリやインデックスはダーティ状態になる。ダーティ状態でマージは簡単にはいななくなる。クリーンな状態にしてからマージが原則。
P66 新ブランチを作成するためのコマンドの基本的形式は次のとおりである。
git branch branch-name start-point
start-pointを指定しなければ、ディフォルトで現在のアクティブブランチの先頭(HEAD)コミットが使われる。
P67 git branch ローカルのみ git branch -r リモートのみ git branch -a ローカル、リモート両方
P73 コミットしていない変更があるときのチェックアウト
Please ,commit your changes or stash them before you can switch branches.
ブランチを切り替えるためには、先に変更をコミットするか、一時退避(stash)
stashしたあと、 git stash applyを切り替え先で行うとマージが必要
P74 ファイルの状態を復元
git checkout dev~4 index.js 特定のファイルを4世代前のものに戻す
rm -rf server.js git checkout server.js 削除されたファイルを復元
git restore [options] file という新コマンドも使える
P75 別のブランチへの変更マージ
git checkout -m dev
作業ディレクトリの現在の状態と切り替えようとしているブランチの状態に矛盾がある場合、作業ディレクトリで加えた変更を活かした形で新ブランチに切り替えたい場合に、ターゲットブランチへの切り替えと同時にマージを実行。3方向(下図のA,A1,A2の3方向という意味か?)マージであることに注意。
A2 (dev)
↓
A←A1(main:コミットしてない)
P77 マージされたブランチのベースブランチ情報:枝分かれの起点をさがすコマンド
git merge-base original-branch new-branch で起点のコミットIDが表示
ブランチの起点となった最初のコミットは明示的に示されていないので、そのコミット(起点)は、新しいブランチ(new-branch)が作成されたもとのブランチ名(original-branch)からアルゴリズムによって見つけられるようになっている。
new-branch
↓
起点←original-branch
P96 git log --graph コミットグラフが枝分かれも入っていてみやすい
P101 gitkというツールをインストールしてみた。コミットグラフが表示されてわかりやすい。
https://kaityo256.github.io/github/advanced/index.html
を参考にさせていただいた。(以下抜粋)
1)detached HEADの対処
git switchとgit restoreは追加された機能。以前はgit checkoutが使われていたが、git checkoutに役目が多すぎたためにコマンドが分けられたとのこと。
「クラウド人材」とはクラウド技術やクラウドサービスを設計・実装・運用する提供側の人材を意味する。AWSや Azureを活用したり、認定資格を取得したりすることではない。」とIPAの登氏が述べている。
https://japan.zdnet.com/article/35217768/
日本は、クラウド人材を育成しようとしたけど、結果的に、クラウド人材できず、高額な使用料を外資系クラウドに払い続けることになってしまった。障害が発生してもブラックボックスなので解決不可能とのこと。今後は、国内でも安定したクラウド環境ができていくことを期待したいものです。
sudo npx create-react-app react-sample --template typescript
では、だめで、sudoなしだと、うまくいくようだった。
node関連のインストールを行うが、バージョンが合わないといろいろ設定に手間がかかるようだった。
なお、警告が出たので
npm WARN deprecated tar@2.2.2: This version of tar is no longer supported, and will not receive security updates. Please upgrade asap.
npm install tar@6 -gtar としたら、解決
18年目になる車なので、あちこち不具合も出やすい。一度、プラグがオイル汚れが原因で調子悪かった時があり、修理してもらったが、また似たような症状出ている。イグニッションコイルもまだ大丈夫なはずだし。
試しに、プラグへのケーブルの差込口すべてに、接点復活材をつけてみたら、少し安定してきたような気もする。イグニッションコイルへのヒューズも念のため、接点復活材をかけておいた。昔、カローラに乗っていたとき、エンジンが安定しないときがあり、ディーラーでもしばらく原因をつかめなかったが、しばらくしてプラグコードの断線が原因だったことが判明。エンジンの不安定は、電気系統が原因になっていることが多い感じもするので、これで、少し様子をみてみたい。
ネット上には、C#の例がなかったので、curlのサンプルをもとに、ChatGPTも活用しながら、コードをつくったら、うまくいった。
wslでLive Server使おうとしたらブラウザが開かない現象があった。
settignsを以下のようにしたら解消した。
raspiでもdockerが使えそうなので試してみた。
https://tech-lab.sios.jp/archives/27798
上記が参考になった。ただ、OSは64bitでないとだめだった。dhcpcd.confの設定で手間取った。固定にするための設定が、こちら
https://qiita.com/trtrbohz/items/f7357d44b2b3d08d9c24
リンクを参考に、Wslでセットしてみたが、権限の関係でうまくいかない
minikube start --driver=docker --force として、--forceをつけたらうまくいった。
https://zenn.dev/yukiko_bass/articles/397e3270f1f3de
にあるように、minikube dashboardで、ローカルのリンクをクリックすると
ブラウザで状態を確認することもできるよう。まだまだ奥が深いようで、概要を把握するだけでも、時間はかかりそうです。
※その後、しばらくして 試したら
Exiting due to HOST_JUJU_LOCK_PERMISSION: というエラー
rm /tmp/juju-*で解決した。rootユーザーと非rootユーザーの切り替えあたりが関係しているとか、ネットにはでている。
コマンドだけで、簡単にサーバが追加できたり、なかなか便利なものだと感心する。そのためのコマンドを理解してないとだめなわけですが。
最新版で試したが、ディフォルトでは、投稿などが保存されなかった。設定のパーマリンクのところは、[基本]にするとうまく動作するようになった。何らかの環境の違いが影響している?と思われる。