雑記: 引越しをした。

初めての引っ越し(一人暮らし)で一週間ほどたったのでいろいろとざつにまとめておく。

次の引っ越しの時の参考にしたり、誰かのためになれば。


22年ほど生きていて、初めて実家をでることになった。

理由は単純に 職場までの移動時間を極限まで減らしたい から。

専門学校にはいり、3年次以降はインターンシップ(アルバイト)等での移動時間が馬鹿にならなくなっていた。とは言え、一人暮らしをするほどの財力があるわけでもないのでいままでは実家から通っていた。

就活をしていたのはちょうど1年ほど前で、内定をいただいた各社にはインターンシップという形で少しの期間(1週間~2週間ほど)働いたりしていた。その時に強く思ったのは、実家から毎日通うことが "通えない距離ではないが、これをずっと続けるのがしんどい"ということ。 Door to Door で1.5 ~ 2時間、場所によってはもう少しかかったりする。

なので就職を機に、引っ越すことにした。

引っ越して一人暮らしにつかれたら実家に戻れば良いという安直な考えで引っ越した。

(実家が神奈川にあるので業者に頼んでもそれなりの金額でさくっと戻れることが気軽に引っ越しに踏み切れる大きな理由なのかもしれない。)


もともと実家にいたこともあり自分の家具/家電みたいなものは特に持っていないので、自宅から運んだもの(大きなもの)はPC用のモニター2枚、座椅子、PS4くらい。あとは、洋服と本類(技術書/漫画/小説),

次のものたちは↓の理由により運んでいない。

  • 以前使っていたデスク/椅子:
    • 昔から使っていたもので長時間作業すると体が痛くなったりするので買うことに。
  • 本棚:
    • 既存本棚はすでに大きくあふれており、平積みされているものが多かったので買い替えることに。
  • ベッド:
    • 新居のスペース的に固定幅をとるベッドより布団の方が(なんとなく)広く使えそうなため

買ったもの


echoを買うか、他のちゃんとしたスピーカーをつかうか。迷っている。 Echo (エコー) 第3世代

ANKERとかBOSEとかよく聞くけど実際コスパとか考えるとどうなんだろう。Spotifyとの連携ができると嬉しい。 PCをクラムシェルで使いたいが音が曇って聞こえるので"今は"開いて使っている、早くスピーカーを用意したい おすすめをおしえてください........!


PCデスクを買おうとしている

  • 昇降式にする?
  • L字デスク?
  • 横幅(120, 140,...etc)

この辺で悩んでおり、まだ購入に至っていない。

同様にオフィスチェア/フローリングを痛めないようにチェアマットこの辺も購入を迷っており、まだ決めかねている。

早くこれを卒業したいが、急いで変なの買う方がしんどそうだし、一旦このままでいいかなと。

追記: 入社直後からリモートワーク(研修)になるとの連絡を受け早急にデスク環境を整える必要になったのでここから次のセクションまで追記している。

以下購入したもの

デスク:

  • 幅120 or 140 で悩んでいたが、友人のデスク環境をみたり今の現状を考えると120だと少し物足りなさそうなので w140
  • 奥行きが60くらいでいいかなと思っていたものの、60だと少し物足りない感があるとのこと(友人より)だった && 今の自分の環境(※1)がJust60を使い切っていたので余裕が欲しくD70で探すことにした。
  • 正直昇降式である必要はないが、w140xD70でさがし && モニターアームがつけやすいことを考慮するとこのデスクがちょうど良さそうだった。昇降式のため多少値段は張るがまぁいいだろうということで購入

    ※1 今の自分の環境: モニターの段ボールにモニターを配置し、その手前にPCスタンドを利用してキーボード(mistel md600)とmagic trackpadを置いている

    検討していたが不採用だったもの

    • LOWYA L字型デスク 幅145cm

      こちらはモニターアームが取り付けにくいとレビュー欄にあったこと。また正直机の下に収納スペースはいらない気がしたため不採用

    • IKEA bekant コーナーデスク

      デザインやサイズが好きなので、正直もともと買おうとしていたのはこのデスクであるが、IKEAオンラインショップでは自宅までの配送をしていないため断念した

椅子:

  • なんとなく昔から気になっていたということ。
  • メッシュのほうが個人的に好きであるということ。
  • レビュー欄に動画があり雰囲気が伝わったこと。

以上の理由で採用

マット:

マットにこだわりはないのであとは適当に選びました。


引っ越しして感じているのは、電車での移動が水面下のストレスになっていたという事実に気がつけたこと。

ここ数日は短い移動(数駅/徒歩40分くらい)は歩くようにしてみた。そうすると想像以上に気分転換になるし、多少の運動になる。

たまに電車にのると、パーソナルスペースが侵されるのはもちろん、空気が悪い。

昨今はcovid19で騒がれていることもあって換気している電車(車両)が多いが、換気されていない電車に改めて乗ると不快に感じることがある。

というか就職して速攻リモートワークになったりでもしたら引っ越しした意味がほとんどなくなってしまうんだよな 追記: 研修を含めリモートになったので早急に自宅環境構築をしないといけないようだ.......


例のものを置いておきます、気が向いたら是非に。

Amazon CAPTCHA

tips: javascriptでnestedObjectでも動的にget,setする

TL;DR nested objectから任意のkeyで動的にget, setしたい時に使えるスニペット


ソースコードはこちらです

gist.github.com

モチベーション

const obj = {
  key1: {
    key2: {
      key3: 'value'
    }
  }
}

上記のようなnested objectがあった時に、

静的にアクセスするのであれば↓のような方法が取れると思います。

  1. object['key1']['key2']['key3']
  2. object.key1.key2.key3

しかし、これを動的に行うとしたらどうしましょう。

lodashという声が聞こえそうですが、彼を入れるとプロジェクトのバンドルサイズがおおきくなるので今回は不採用です。すでに入ってるなら .set, .getを使いましょう。

object[val1][val2]のようにおこなうのでしょう?。これを行うとすると各種変数が存在しない場合を考慮したりしないといけないため少し面倒です。

e.g. getValue(obj, 'key1.key2.key3'), setValue(obj, path, value) のような取得するためのpath(文字列)くらいであればjsでさくっと作成できそうですね。なので今回はこれを目指しました。

ざっと再起やreduce で書いた後に、いやこれ過去に考えた人いるだろうと思って調べるとstack over flowに質問&回答があったのでそれを拝借し↑のコードに至りました。

bashの起動速度を5倍速にしたので褒めて

はじめに

あけましておめでとうございます。気がついたら年が明けていました。本年こそ頑張って技術ブログを更新していきたいものですね。

さてこの記事はクリスマスを迎えるためのカレンダーこと、MakeITアドベントカレンダーの25日目の記事になります。 qiita.com

え?もう1月だって?

Google先生によるとクリスマス - Wikipedia

キリスト教の中でもカトリックの影響の強いイタリア、ポーランド、フランス、スペインなどでは、クリスマスは12月25日に始まり、1月6日の公現祭(エピファニア)に終わる。クリスマスの飾り付けは23日頃に行う。24日はクリスマス・イヴとして夜を祝う。

1月6日まではクリスマスですし、片付けのこととかを考えれば今日も実質クリスマスですよね。なので今日は25日目のブログの日です。(は?)

もともとは別の人担当でしたがまだカレンダーが空いている&&面白いネタができたので変わって私が投稿します。 というわけでやっていきたいと思います。


bashの起動速度をはやくしました

該当PR:

github.com

before

{ fumihumi } (master *) (dotfiles): time source ~/.bashrc
real    0m2.709s
user    0m1.295s
sys     0m1.097s

after

{ fumihumi } (master *) (dotfiles): time source ~/.bashrc
real    0m0.481s
user    0m0.208s
sys     0m0.246s

🎉 なんとびっくり、計測誤差が多少ありますが、平均して4~5倍速に!!! 🎉

はてなって:tada:できないんですね。

そもそもどうしておそかったの

いや気がついたらストレスがたまるくらいには遅くなっていたんですよね。

普段はターミナル立ち上げてから基本的にはtmuxinatorで自動化しているレイアウトを復活させていて、その時にdockerとかを立ち上げたりしてるので生のbashを新規立ち上げたりする機会があまりなく普段使いにはあまり支障がありませんでした。

ただ、年末年始に仕事以外のプロジェクトを触ろうとするとtmuxinatorのconfigがないため手動でいろいろ立ち上げるわけですが、1度なら気にならないがなんどもbashを立ち上げるとストレスを感じるほど遅かったわけです..........

そんな悩みを友人に投げてみると

Image from Gyazo

次の記事を共有してもらいました。

zshrcの中でbrew --prefixしないほうがよい理由 - Qiita

実際にHomebrew側のISSUE等も調べてみるといまだに完全はされておらずbrew --prefixは悪手のように見えてきます。

github.com

なにしたの

そこで、一度 brew --prefixを実行したらそれを変数にいれて実行結果をキャッシュさせるという手段を取りました。

remove 'brew --prefix' command call. by fumihumi · Pull Request #21 · fumihumi/dotfiles · GitHub

brew --prefix ってPCの環境問わずにbrewのpathを出してくれるため環境構築する際のサンプルコードとしてよく出てくるきがしますが、実際にそれを複数回利用したり、自分のように source コマンドを使うために if で調べた後に source するみたいな rc の書き方をしていると sourceするファイル数 * 2回も brew --prefixを実行してしまいます。 なので初回に実行してそれを読み込めば多少は早くなるやろ。って考えでした。

これが思ったより効果的面でして、タイトルにあるように実測値で5倍弱の速さになりました。すごい!

最後に

今回はbashの起動速度というトピックでしたが、brewを使っている環境であればおそらくどの環境(zsh, fish)でも再現すると思います。 是非一度自分のdotfiles配下で git grep 'brew --prefix'をためしてみて、複数個見かけたらそれをやめてみてはどうでしょうか。きっと早くなると思います。

P.S. Macの標準シェルがzshになったのでそろそろ乗り換えようと思いつつもbashrcを移行するのがちょっとめんどくさくてまだできていません。


参考にしたもの。 - Profiling zsh startup time

2019の振り返りしてみる

2019の振り返り

1年に1回くらいはブログっぽい記事を投稿したいもので、今年も年末なので振り返り記事を書こうかなと思い書き始めることにしました。(12/18に雑に書いていて12/31に書き上げている)

~5月

いわゆる就職活動をやってました。 何社か選考をうけ、無事(?)内定をいただくことができた各社様にてインターンシップをさせてもらいました。 この辺は特に詳しく書くつもりもないので :beer: が混ざってるときにでも聞いてみてください。

就活、スケジュール周りの調整が大変という点を除けば、終わってみれば終始楽しかったですね。

このまま無事に卒業さえすれば新卒としてエンジニアになってると思います。

就活を考えたくなかった時の現実逃避としてiOS(swift)を勉強してアプリ作ってみたりしていました。 RxSwift便利だなぁと思いつつも自分の実装が正しいのかわからなくなり、いろいろスクラップしていた記憶があります。こういうとき身近に実装まわりを相談できる人がいると良いなぁなんて思ったりしました。

後日談になりますが。この時がんばってauto-layoutとかUIkitで頑張っていたのにswiftUIが出てきてしまっていろいろ悲しくなった記憶があります。

~6月

この辺で今(12月現在)もやってるゼミの開発案件が始まりました。(NDA的にアレなので詳しくは書きません)控えめに言って精神的に辛い

~7月

長期インターン先でReactNative(以下RN)での新規開発が始まったので業務内容がほとんどそれになりました。(今(12月)もやってる) 技術選定から実装、なかには仕様検討までまかせていただき、苦しみながら頑張った記憶があります。

RNでのアプリ開発は2度目になるのですが以前やった時はプロトタイプだったこともありいろいろと雑な実装をしていましたが今回のコレはちゃんとした業務案件ということもあり、ライブラリ選定するときや実装する時も将来性等を'ちゃんと'考慮しながら実装するように心がけ、社のエンジニアに相談しながら実装をしたりしました。 苦しいながらにもとても楽しい経験になっています。

~8月

夏休みだった気がしますが記憶がありません。

非技術的プライベートな話だと夏コミに行ったり五等分の花嫁展に行った気がします

~9月

isuconの予選に参加して惨敗しました。練習しないとだめですね。 そろそろ反省(去年ぶり2度目)してちゃんと準備して参加したいです。

~12月

記憶が薄いので3ヶ月分まとめます。

ゼミの開発案件を放置気味だったのがやばいので焦りながら頑張り始めたのがこの辺です。今も頑張ってます。 業務のRNでの躓きどころがある程度おさまってきて、プライベートな時間は比較的余裕が生まれたのでflutter(Dart)をスクラップするようになりました。RNで実装した内容をFlutterでやってみてどんなコードになるのかどこが辛いのかとかを雑にみていました。双方の差分をざっくり把握するにはとても良い時間だった気がしています。 とはいえ、flutterのお作法はまだまだ馴染めていないところが多いのでそこはこれからあらためて学んでいきたい。

私用ですが冬コミに参加したら足が痛いです辛い。運動不足ってこんなに体にダメージがくるんですね。

ポエム

お前本当に一年間過ごしてきたのか???って感じな文章になってしまいました。 就活時期が印象に残りすぎて他の時期が薄く感じてるんだと思います。*1 わりと就活は真剣になやんだりしていてその節で各社の人事の方にはお世話になりました。この場でお礼を伝えさせていただきます。’本当にありがとうございました。’。 自分の将来とかを検討する上でいろいろなエンジニアの方と話す機会はとても貴重な経験になりましたし自分の視野を広げる機会になりました。

あと'伊藤美来'さんにどハマりした1年でした。五等分の花嫁をはじめとした作品はもちろんバンドリ(ハロハピ)のこころんもとても可愛く、これからも推していきたいです。はい。

昨年の目標の振り返りもサクっとする

2018の振り返りしてみる - fumihumiのブログ

来年は自分の道を決定し、その道に進むためにいろいろ頑張っていきたいです。
まず進路の確定。自分がどの会社でなら自分らしく働けるのかをしっかり考えたいと思ってます。

また、今まではWeb系の技術に触れていましたが、モバイル開発を再度しっかり学び直したいとも感じています。 
インターンやイベントでアプリの開発にした方が良い場面が何度かあったのにも関わらず、僕の力不足でWebにしたこともあるため、
自分都合での選択肢を減らすことがない様にしたいなと思っています。

こんなことを昨年書いていました。 進路は決まりました。とはいえそこでなにを'したい/する'のかはまだ曖昧なままですが、自分らしく、自分が一番パフォーマンスをだせる場所でなにかしていきたいと思っています。

モバイル開発という点では就活時期にswiftを触っていましたが業務でRNをさわるようになったこともあり中盤からはXplatな開発をメインにしてました。Xplatは便利な反面普段使ってない方(自分の場合android)の対応をする際にすこし戸惑ったりすることもありました。これは各種OSの特徴を捉え切れていない私自身のダメな点だと思います。とは言えiPhone便利なので.... スタートアップ(ベンチャー)企業において開発スピードを優先するという点においてはRNやFlutterのようなXplatな開発はとても事業スピード及びエンジニアにたいしてとても良い選択なのかなと改めて実感することができた年になりました。実際に何箇所かちょっとめんどくさい対応はありましたがそれいがいを除けば基本的なコードはiOS,Androidで共通できてロジックも一つにまとめられるRNとても良いというのが率直な感想になります。 とは言え、Swift、KotlinのようなネイティブアプリはXplatに比べ各種OSへの対応が優れているためUXを追求するのであればまぁ間違いなくXplat->ネイティブへの移行というフェーズはおとずれるのかなと感じる側面もありました。これはRNで実装している時に自分が普段使っているアプリとの比較をしてしまったりしたためとても強く感じている部分になります。

  • 来年の目標とか

来年は業務でなにをするのかに応じて臨機応変に対応したいと思っています。 その時に必要になったことを学ぶでも良し、自分が戦えるなら戦いたいと思っています。

その上で新規に学ぶとすれば、Golang, elixir, typescript(もっと)のどれかになるのかなぁとぼんやり検討しています。typescriptに関して言えばReactを書く過程にて触っていますし、今も書いていますが複雑な型定義やいわゆる応用的な型に関してはまだまだ対応できていないというのが本にになります。この辺をサクッと対応できるようになる。もしくは新規のプログラミング言語としてgolang, elixirといったものを学びたいなという側面もあります。 goに関しては言わずもがな、昨今のブームがここにあるので1サーバーサイドエンジニアとしては抑えておきたいものだと認識しています。 elixirは関数型パラダイムプログラミング言語を学ぶ上でrubyに文法が近いということを知ったため親和性があるのではないかときたいをしてわくわくしています。 とは言え、新卒というアレになり、今までとは生活スタイルが変わるはずで。その中で何ができて何ができないのか不明なことが多いというのが本音になります。 実際問題として自分は身体の体調を崩しやすく、すぐに体調に出てしまうので下手に無理をすればすぐに迷惑をかけることは自明なので。程々にプライベート学習時間を確保しつつ頑張っていきたいなぁと考えています。 来年の自分がコレをみているのか不明ですが、楽しんでいれば今の私的には嬉しいと思います。楽しくないのであれば、今を楽しく感じることを1番に考えてみてはどうだろうか????????俺は今楽しいぞ。と伝えたい。


はい。これにて振り返りブログを締めたいと思います。良いお年を.

*1:きっと。

electronをつかってブロック崩し作ってみた。

electronをつかってブロック崩しを作ってみました。

(12/31) 編集しましたタイトルからwipが消えました。

  - 各セクションをfixしました。

今年もあと数日で終わりますね。はやい、年末年始は何をして過ごそうかなとぼんやり考えています。

この記事はMakeITアドベントカレンダー 23日目の記事になっています。今日は12/2x日なので (2x - 23)日の遅刻です。言い出しっぺのくせにすみません。

カレンダー的には 昨日(22日目)は feketerigo222による Tkinterを使ってサンタになりきる

明日(24日目)は haduki1208によるSCSSとstyled-componentsの勉強と比較のための環境を作った でした。

どうして将来の記事のが先にあるんだろうな?時間軸がずれているみたいですね。

昨日はすでに終了ムードになっており罪悪感に包まれていました

gyazo.com

最初に

作ったものはこちらです。 GitHub - fumihumi/block_breaker_electron_app: Touch Barでブロック崩ししたい

Image from Gyazo


どうして作ったのか

先日electronとTouch Barで遊んでおり、

github.com

これを作った時にTouch Barを使って何か作れないかなと画策していました。そういったこともあり、今回はブロック崩しのバー部分をTouch Barで操作してみるようにしてみました。

つくってみて

基本的なブロック崩しのコードは以前インターネットで見かけていた次のjsfiddleから拝借しています。

arkanoid - JSFiddle

いじった点はes6ベースに置き換え、reactで書き直した点でしょうか。

今回自分がやりたかったことのメインであるTouch Bar周りはすべてmain.jsに記述しています。 例えば次の部分ですが。

https://github.com/fumihumi/block_breaker_electron_app/blob/master/main.js#L13:L18

この辺の処理もうすこしいい感じにできないのかなぁと思いながらドキュメント眺めてました。 (dom側からtouchbarAPIをいい感じに叩きたいがうまくできなかったのでmain.jsで window.webContents.executeJavaScriptをするようにしました。)

またmain.jsファイル上部にて定義している, window, paddleですが

let paddle;

sliderの changeイベントのコールバック関数にて毎回 const paddle = xxxのように記述したりしるとなぜかエラーになってしまった(定数宣言複数あるとおこられるやつ(has already been declared))ため windowと同じように一度外で定義したものを使い回すようにしました。 windowを外で定義する書き方はexampleに合わせています。

感想

Electronを使って何かおもしろいことができないものかと思い、APIドキュメントを見始め、Touch Barが面白そうだなと思ってTouch Barがどのくらい使いやすいかを確かめるために今回のブロック崩しを作ってみました。

さきほど記載したように executeJavascriptをしている箇所があまり直感的ではないためかなり使いにくいなぁと感じています。

この部分をReact側(WebView)の方からElectronのAPIをよし何叩けないかなと調べてみると次のライブラリがあったのですがうまく動かず(時間がなかったので調査仕切れてない)という事情がありました。

GitHub - patrikholcak/react-touchbar-electron: Define TouchBar layout in your components/routes

仮にこのライブラリがやっているようにWebView側からよしなにElectronAPIを叩けるのであればかなり柔軟に対応ができるんじゃないかなぁと感じました。

改めて調べてみたいと思います。

おすすめのgitconfigと周辺ツール

はじめに

本記事は Make IT Advent Calendar 2019の 2 日目の記事です。

qiita.com

明日も isshun がなにかを書いてくれるはずです。

TL;DR

git を普段使いしており、自分の dotfiles をそれなりに管理していて、ls ~/.git*これの結果がすでに存在していて、自分で中身を書いたことがある人にとっては常識のような話かもしれません。 gitconfigや実際に使ってみて便利な設定について書きます。

agenda

  • gitconfig とは
  • これはやっておいた方が便利
  • git やその周辺でつかってる便利ツール

の流れで書いていきます


gitconfig とは

ref: 1.6 使い始める - 最初の Git の構成 とはその名の通りで git コマンドを実行する際の設定を記述するファイル、およびその設定のことをです。 ※ ファイル自体を示す時は明示的に '.gitconfig'のように記載します

git を初めて install した後に以下のようなコマンドを実行した覚えはないでしょうか。

$ git config --global user.name "YOUR NAME"
$ git config --global user.email "YOUR EMAIL"

これも gitconfig を設定するためのコマンドです。

これは誰がコミットをしたのかを保存するために利用すされますので本名ないし、ハンドルネーム等を利用しましょう。ユニークであれば良いような気がします(?)

また、この gitconfig は三箇所で設定することができ、次の各コマンドに --edit, --listオプションを渡してあげることで、それぞれ編集 or 一覧を表示することができます。

それぞれの設定ファイルは以下に作成されます (DOC より引用)

  • system: /etc/gitconfig
  • global: ~/.gitconfig or ~/.config/git/config
  • local: PROJECT_ROOT/.git/config
$ git config --global -l # or -e
$ git config --system -l # or -e
$ git config --local -l # or -e

基本的に PC として利用する全般的な設定は global を編集するようにし、repositoryURL 等は local の gitconfig に記述することで基本的な対応はできると思います。

※ ちなみに筆者の環境(MBP)においては git を brew にて管理しているためか system の設定ファイルは以下に作成されていました。

brew --prefix/etc/gitconfig

FYI: 参考までに私の gitconfig をおいておきます。 ref: github.com:fumihumi/dotfiles/gitconfig

これはやっておいた方が便利

⚠️ これより先は実際に設定用のコマンドを記載します。前後にその設定が何を意味するのか Doc や参考記事をリンクするので各自で見てその設定が自分にあってるなぁと感じたら設定してみて下さい。

$ git config --global push.default current

ref: https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault

value description
simple _default_: upstream が登録されていて、ブランチ名が同一の時に push する
nothing git push origin masterのように remote ブランチを明示して push する
matching ローカルとリモートで同一の名前のリポジトリがあれば全て push する。
upstream 今のブランチに upstream が登録されている場合そこに push する
tracking deprecated, これをつかうなら一つ前の upstream を使う
current 今のブランチと同名のブランチを push する

nothing でやるべきなのかもしれませんが、大抵の場合ローカルのブランチと同名にするのではないでしょうか?そういった使い方をしているなら current にすると楽になると思います。

$ git config --global pull.rebase true

git pullを実行する際に upstream ブランチを rebase してくれます ref: https://git-scm.com/docs/git-config#Documentation/git-config.txt-pullrebase

rebase の説明はここでは割愛しますが知っている前提とします。 大抵 rebase を好む人は git pull --rebase origin master ないし、 git pull --rebase origin develop をしてから push し、PR を開いたりするのではないでしょうか。 この --rebaseを省略してくれるのがこの設定です。

rebase 派の人は設定した方がタイプ数減って便利ですね. これを知るまでは git stash -> git pull or git rebase, git stash pop をしていたのでそれを考えずによくなってかなり快適になりました。

``` ???: alias で設定してるからこんな設定しなくてもいい??

A: それはまた別の話ですし、常に rebase するなら設定していいのでは??? ```

$ git config --global rebase.autostash true

これも rebase 派の人のためのものですね。 rebase を実行する時に毎回 stash をしなくてよくなります。便利.

$ git config --global fetch.prune true

これをすることで git fetch を実行した際に--pruneオプションを付けてくれます。 GitHub 側のリモートブランチを削除してもそれの追跡ブランチがローカルに残っていると汚く感じますよね(?) git branch や git branch -a の結果が不要なブランチで溢れていると使いにくいですよね???削除してないブランチが溜まってきたら不定期で '--prune'を実行する人は少なくないと思いますが、この設定をしておくだけでそのような煩わしさから開放されます! :tada:

git config --global core.***

ここからは coreの設定を紹介します。

$ git config --global core.ignorecase false

これでファイルの大文字/小文字を区別するようになります

$ git confnig --global core.quotepath false

日本語ファイルの文字化けがなくなります。

$ git config --global core.editor vim

git commitコマンドで起動するエディタを指定できます vim なり emacs なり好きなエディタをここで指定してあげましょう。

$ git config --global core.pager "less -R -F -X"

git log などでページングが必要な時にどんな挙動をするのか設定することができます。
今回の less を利用することで less コマンドと同じように使うことができます。(↓ のブログより拝借しました)

ref: https://nojima.hatenablog.com/entry/2017/09/12/103130

git やその周辺でつかってる便利ツール

diff のハイライト系

何も設定をしていない状態での git diff は差分が読みにくく、色合いも正直読みにくいと私は感じます。そういったものをより読みやすくするためのツールをここでは二つ紹介します。

diff-so-fancy: https://github.com/so-fancy/diff-so-fancy diff-highlihght: https://udomomo.hatenablog.com/entry/2019/12/01/181404

私はdiff-so-fancyを利用しています、昨日 diff-highlight を紹介している記事もありましたのでそちらも貼っておきます。 diff-so-fancy, diff-highlight どちらも git diff の結果をよりみやすくするもので色が可視化するツールです。

TUI ツール

Git 関連の便利コマンド

P.S.

私の .gitconfig は今までなにか欲しい機能がある際にぐぐり、誰かのブログや qiita にて良さそうな設定があったらそれを 見様見真似で拝借し自分でアレンジを加えたいわば秘伝のタレ化したようなものです。 例えば gitconfig の[alias]などは git で ○○ したいけどコマンドがわからないって時に調べて、今後も使いそうなら alias にするみたいなことを何度もしてきました。 そのため自分の'.gitconfig'等の中身に関しては参考記事はいくつもあるはずですが、今回この記事作成にあたってはそれらの文献への参照がないことをご容赦いただきたく思います。

vscode更新すると毎回タブか消える件(備忘録)

心なしかVScodeを更新すると毎回(?)設定が変わる気がして(?)

毎回'?????'ってなって困るのでメモ。