おすすめの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'等の中身に関しては参考記事はいくつもあるはずですが、今回この記事作成にあたってはそれらの文献への参照がないことをご容赦いただきたく思います。

MacOS Catalinaにしたらbash起動時に毎回メッセージが出る件

tl;dr

ここはすっ飛ばしても大丈夫。

catalinaからはzshがデフォルトShellになっているとのこと(下記参照) support.apple.com まぁ、それはいいんですが。 いつも使ってる.bashrcとか他のShell対応の移行してないためBashを引き続き使いたいと思い

$ chsh -s /bin/bash

で bashを使うようにすれば、Bashは当然使えますが、↓↓↓↓のようなメッセージが毎回出てきて、正直 邪魔 です

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.

まぁOSとしてzshを標準にしてるんだからそっちを使えって話はわかるんですが、もうちょっとやり方ないのかなとおもったり.........

解決策

homebrewでbashを入れてbrewのbashをdefault shellにすることで上記のメッセージから回避できました。

ref: Mac で homebrew の bash をログインシェルにする - Qiita

$ brew install bash
$  echo '/usr/local/bin/bash' | sudo tee -a /etc/shells
// 不安ならcatして末尾に追加されてるかみる
$ chsh -s /usr/local/bin/bash

まぁ当分はBash使う予定の人はこちらで良いのではないでしょうか。

p.s.

zshに乗り換えるなら fish shellに乗り換えたいという気持ちがありつつ、今まで書いてきたbashrcの整理と移行がめんどくさくて踏み切れない。。

fishshell.com

AWS certificate cloud practitionerを受けてみた話

はじめに

夏が終わったような気温になったと思った翌日には30度をこえる猛暑(?)に襲われ、一瞬で体調を崩してしまいました。

こんばんは。最近、TypeScript/ReactNativeでアプリ開発を行なっているfumihumiです。

ReactはHooksが出るか出ないかと騒がれた頃(?)(v15 ~ v16.4)に触って以来に(ちゃんと)触って(学んで)います。 Hooksが正式にExpo(が依存しているRN)でもサポートされたので基本的にはFunctionalComponentを使って開発するようにしています。

最近の悩みはAtomicDesignです。(そのうちブログにまとめたい。)

.と、そんなわけで今回の記事はタイトルの通りAWS認定資格のCloudPractionerを受けた話です。

目次

  • なんで受けたの。きっかけは？
  • どうしてCloudPractionerなの？
  • どんな対策したの？
  • 受けてみてどうだったの？

なんで受けたの。きっかけは？

秋のIPA資格(AP)の申し込み締め切りをすっかり忘れており、見事 申込技術者試験に落ちてしまいなんとなく、体系的に学ぶ機会を失っていたため。 なんとなく(ベンダー)資格を受けて、実力を試してみたい。という欲求がありました。

選択肢として、

などが候補にありました。

  • ruby技術者試験はだいぶ過去のRubyバージョンを対象にしている試験だったため受けることをやめました。
  • Oracleの試験に関しては今まで曖昧に学んできたDB周りの知識を再定着させるという意味でも改めて学ぶのはとても良さそうでしたが、それ以上に自分の中のCloudへの苦手意識をどうにかしたいという思いがあったため今回はAWS認定資格を受けることにしました。
  • AWS認定資格の中で開発者向けの資格の一番入門(?)向けの資格だったから選びました。

ref: 学習パス - デベロッパー

この試験により、AWS クラウドについての全体的な理解を持つ人が、業界で広く認知された認定によって、その知識を証明することが可能です。
この試験には、クラウドの概念、セキュリティ、テクノロジー、請求と料金という 4 つの分野があります。

どうしてCloudPractionerなの？

参考までに、受験時の自分がAWSのサービスの中で触ったことがあるのは

EC2, RDS, Route53, S3, CloudFront,
lambda, Elastic BeansTalk, 
securityGroup, IAM..etc

といったようなシンプルな構成で利用するようなサービスしか利用したことがありません。

知識レベルで言えば、概要としてPros/Consを知っているものとして

cloud watch, cloud trail, SQS, SNS, 
dynamoDB, ElasticCache, ELB(ALB), 
ECS, Fargate, VPC, ..etc

というものです。

これらの物は弊学の授業にて行われた、クラウド開発実践(?)という授業内で、

  1. 各回の授業でテーマを与えられ*1
  2. 構成図を作成
  3. 構成のPros/Cons, Cost見積もりや障害対応はどうするのか等を説明する

といったような(割と実践的な構成を検討する)機会があったためこれらの主要サービスについて学び、知ることができていました。

といったようんななんとなくわかってる(つもり)になっていても改めて学習する機会を設けないと知らないサービスを知る機会が少ない && 間違って記憶しているものがあるかもしれない。という思いがあったため、改めて学習する機会にちょうど良さそうな、AWSクラウドプラクティショナー試験を受けてみることにしました。

どんな対策したの？

結論から言えば、クラウドプラクティショナー試験への対策はしていません。

受験を決めてから申込、当日の間に3日しか時間がなかったため取り急ぎ、知らないサービスを抑えないといけないと思い、次の書籍を読んでいました。 徹底攻略 AWS認定 ソリューションアーキテクト – アソシエイト教科書 徹底攻略シリーズ | 鳥谷部 昭寛, 宮口 光平, 菖蒲淳司 | 工学 | Kindleストア | Amazon

クラウドプラクティショナーとソリューションアーキテクトでの範囲はあまり変化はないため問題ないだろうと思いこちらを選択しました。

基本的には概念の部分は読んでみてPros/Consは実際のアーキテクチャと一緒に 'どんなときに採用するのか'に焦点を当ててみていました。

教科書と書いてある通り、解説はかなりわかりやすく、すんなりと読むことができました。 3日前に買ったこともあり、読み終えたのは試験前夜になってしまいましたが、最後まで読んでよかったなと思います。 特に '料金と請求'の分野は普段コストの見積もりを元にアーキテクチャを検討する機会が全くないためこの部分を知れたのはよかったです。（試験ではこの範囲が見事に爆死したが。）

受けてみてどうだったの？

結果から言えば合格しました :tada: スコア的にはある程度余裕を持って合格はしたのですが、 先ほど記載してように '料金と請求'の項目があまり正答率がよくなかったみたいです。 その他の項目 (クラウドの概念 | テクノロジー | セキュリティ)に関してはスコアレポート的には "十分な知識を有する"と分類されていました。一安心....

感想

数年前にFEを受けたときに感じましたが、資格試験に向けて勉強をすると :money_with_wings: を出していることもあり、落ちて受験して2倍の金額を払うことに若干のプレッシャーがあることや、締め切り(受験日)が明確に設けられているため学習スケジュールが組みやすい。なと感じました。受験まで3日しかないのでスケジュールなんてなく、本を読んで本にある問題を解くだけだったっが、

卒業までに "AWS 認定デベロッパー アソシエイト"*2に挑戦したいな、とぼんやり検討しています。

*1:オンプレのサービスをクラウドに移行するといったテーマや、新規サービスとしてECサイトを構築するというテーマ等

*2:AWS 認定デベロッパー – アソシエイト

react nativeのImage読み込みが遅くてつらい

react nativeで画像の読み込みがなぜかおそい

表題の件で悩んでいました。

docs.expo.io Imageコンポーネント使っていい感じにやれば、良さそうで、

< Image source={require('../../assets/sample.png')} />

っていう風にやれば良いらしい。

これの通りに書いてはいるんですが、なぜか読み込みに数秒かかったりするんですよねw

いろいろ調べてみたんですが、画像の読み込みが遅い というような悩みを抱えてる人がほとんどいなかったw

唯一みつけたのが↓これ forums.expo.io

↑のリンクとExampleのコードに 'Asset.loadAsync'を利用すれば良いというような文面をみたため

github.com

↑この Asset.loadAsyncの中に画像ファイルを置くことで解決しました。

:thinking:

きっと画像を扱う際の初歩の話なのでどこにもまとまってなかったのかなとか思ったのでめも程度に書き留めたいと思いました。

2018の振り返りしてみる

生活

2018の振り返り

  • 2018の振り返り
  • いろいろ感じたこと
  • 来年の目標とか

みたいなことを書いていこうかなと思います。

1月

  • 昨年から引き続きアルバイトでプログラミング教室のメンターをしたりしてた
  • 昨年12月よりPythonと数学を学び始め、’統計や機械学習’といった分野の入門をしていたりしました
    • 短期間で本格的に学ぶことはできなかたですが、基礎的な概念を学ぶことができたのはよかったのかなと思っています

2月

  • iOSの学習をし、簡単なアプリであればなんとなく作れる程度に。
  • Webフロントエンド（React）を改めて学び始め、React,SPA,PWAといったモダンなものを知った。
  • 冬休みということもあり時間が取れそうだったためスタートアップの会社にてインターンを始めました

3月

  • 前述した会社とは別にアルバイトとして働き始める

4月

  • 学校にてプログラミングサークル(Make IT)を設立
    • プログラミングを教えたり

5月

6月

  • サマーインターンの面接とか。
    • 面接や面談をとおして自分が求めている会社、環境とかを改めて考えたり

7月

  • サマーインターンの面接とか
  • (これといって何もしてないw)

8月

9月

10月

11月

12月

  • 就活するために面談させてもらったり。
  • 同時に就活したり。

振り返ってみて

端的に言えばエンジニアとしての成長、またサービス開発全般において１つ前に成長できたなと感じています。 サーバサイドやフロントエンド、どちらもまだ未熟ですが昨年に比べれば大きく前に進めたのかなと感じており、 以前は曖昧だったことも今ではちゃんとわかる様になったことが多くなりました。

サービス開発全般。というとよくわからない感じになっていますが、

  1. アイデア
  2. ビジネス
  3. 開発（設計、手法、機能開発、デプロイ、保守）

こういったことに関して今まで以上に関わることが多かったです。

スタートアップの会社ではサービスの開発と同時に改善などに関わることができました。 また、サービスにとってクリティカルなバグを生んでしまったり、機能開発に携われたり、それ以上にサービスについて真剣に考えたり。といった様なことに挑戦できたのはとても良い経験になっていると感じています。

サマーインターンでもアイデア出しから開発というサービス開発において大事な部分を実践で学ぶことができました。 また、他の参加者からは個性的な人が多く、色々な意味で多くの刺激をもらうことができました。 （忘年会の時期は終わってしまったが、久しぶりに会いたいなとか思ったり。）

Akatsuki。コロプラさんのサマーインターン、isuconではサーバサイドエンジニアとしての挑戦、そして自分に足りないもの等を身を以てしれたと感じてます。 実際にエンジニアとしって働くためにはこれらのイベントで体感し、改善したことを挑戦し続けなければいけないと思うと、不安に感じることが多いですが、もっと学び、これらに対応できる様になりたいと感じています。 来年こそisuconでそれなりの結果出したい。 （惨敗した）

参加したイベントの直後にブログを書こう書こうとおもってたら複数のイベント終わってて、 9月の末にまとめて書こうとしてたら気づいたら九月がおわってて、 気づいたら年末になってた。（つらい）

来年は

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

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

情報が錯綜する世界の中で頑張る(生き残る)ために...

Make IT アドベントカレンダー25日目、最終日の投稿です。

Make IT アドベントカレンダー 2018もそろそろ終わりを迎えます。
サークルのメンバーでアドベントカレンダーをやってみよう！
とのことで始まりましたが
- 「情報を発信することの意義」
- 「人に伝えることの難しさ」
が後輩に伝わったのであれば、このアドベントカレンダーは大団円です。

昨日 @haduki1208が上記のように書いてくれましたが、改めて

  • 情報の発信
  • 伝えること
  • 情報の収集

といったようなことについて技術ポエムを書こうと思います。

--ここから余談--

そもそも今回のアドベントカレンダーですが、 スクリーンショット - d0cb6150162a3587170ad0b4da8a1828 - Gyazo

みたいな雑な感じで投げたら翌日に作成され、初日を持ってかれた次第です。:sob:

スクリーンショット - b0b64aef2625867733657223f07f9891 - Gyazo

11月頭の時点では、割と早い段階でカレンダー登録をしている企業様が多く、

すごいメンツの中

というような表現になってた（と記憶してます そんな感じで提案翌日にはノリと勢いでカレンダーが作成され日程を埋めていった感じです。

改めてですが、本カレンダーを作成してるMake ITって'?????'ですが,私たちは情報科学専門学校の技術サークルです。

一言で言えば、プログラミングの楽しさを追求しわくわくするものづくりをしていくサークルです。*1

本サークル(Make IT)は今年より活動を始めたのでこれから何をしていくのか。といったようなことはまだ明確になっていません。まさに今検討をしている最中です。

ざっくりと説明しますと - ものづくり、プログラミングの楽しさを知ること - 技術を楽しく学べるようになること といったようなことをしているサークルです。（2回目w）

私自身がプログラミングを始めたときは弊学の先生に

1. 親身に教わり、
2. プログラム組むことの楽しさを知って、
3. コンテスト等に出たりして
4. 楽しくなってまた勉強する
5. １に戻る

みたいなことをしていました. こういったことをいい感じに広めたいという思い、今は活動していて、来年も多分続けます。

-余談終わり-

情報の発信や、情報を人に伝えること。また人に質問すること。といったことについて書いていきたいと思います

「情報を発信することの意義」

プログラミングを学んだりするとすでに発信されている情報の恩恵を受けることが多いと思います。最近だとQiitaやMedium,Note,hatenaといった様な媒体の記事がSEO的にも強く、〇〇 hogehoge 実装とかで調べるだけでサンプル実装が出てきたりします。 また、概念の様なものを調べたりする場合、（TDD,DDD...ex）といったものでも前述した媒体の記事を見かけることが多いのではないのでしょうか。

人はなぜこういった媒体に発信をするのか。 私も以前まではこういった媒体は１人の情報収集者として使うことが多かったです。

自分自身発信者としては未熟ですが発信することには以下の様なメリットがあると感じています。

  • Blogが自分の価値になることもある
  • 情報を発信しようとする際にまとめる必要があるため、ある程度の知識が必要になる
  • 実際に公開しなくとも自分と向き合うことができる
  • （いろいろ頑張れば）稼ぐことも可能

ブログ。という形を例に記載していますが媒体は、自作のブログでもいいですし、既存媒体に頼ってもいいと思います。

1. 情報を発信しようとする際にまとめる必要があるため、ある程度の知識が必要になる
2. 実際に公開しなくとも自分と向き合うことができる

この二つは特に、他者のためでなく自分自身のためにも実践する価値があるのかなと思います。

曖昧なことを改めて文章にまとめて見ようとすると、

  • 自分がわかった気になってたことが改めてわかる
  • 本当にわからないことを改めて調べる機会になる
  • また、まとめようとすることの周辺知識も必要になる

こういったことを学ぶ（まとめる）機会になるため一歩成長できるのではないかとおもっています。

個人で開発していることや、最近学んだこと、興味のあることについてまとめ、それを発信してみてはいかがでしょうか？ 仮に自信がないのであればそれはPublicに公開せずに手元にメモとして残すこともオススメです。 半年、１年後に改めて見返すと自分の成長や、過去の自分の考えなどについて改めて知るきっかけになることがあります。

「人に伝えることの難しさ」

上記の様な、まとめることをしたものを他人に伝えることはまた別なものですよね。 人に読んでもらうための文章と、人に聞いてもらう文章では構成が違いますよね？ そういったl人に伝えること。というのはとても難しいなと感じています。(めっちゃ苦手)

ただ自分は以下の様な方法を取ることで自分のことを相手に伝え、相手に自分が欲している回答を答えてもらうことができる様になるのかなと感じています。

  1. 自分の状況をまとめる
    • 過去：今まで何をしてきたのか
    • 今：何をしようとしているのか
    • 未来：これから何をしようとしているのか
  2. 相手に求めているものをまとめる
    • 直接的回答
    • 比喩的回答(ヒント）
    • あくまでも相談相手になってほしいのか こういったことをメモした上で、
〇〇をしようとしているんですが。（前提）
××をしようとした際に想定外の'hogehoge'な感じになってしまっているのでヒントいただけませんか？
他にも
”fugafuga”, "piyopiyo"の様なことも試したのですが、’ほげほげ’になってしまっていました。
(相談してもらう)

の様にまとめていると事前に自分の中で相談内容がまとまります。 (内容が次項に被るため次に記載します)

「人にたずねること」

前述した内容にかぶりますが 自分より詳しい人に、知恵を借りるために質問をする。こういったことはとても大事だと思っています。 自分自身で解決に１h以上かけてしまうようなことであっても自分より詳しい人であれば即答、もしくはヒントを提供してくれるかもしれません。

ただ、この’回答’にたどり着くためには、いまの自分の状態を正しく伝え、自分が欲していることに関しても伝えなければなりません。 この質問をする。というのは初回の質問のハードルはとても低いですが、 （ここでいうハードルが低いというのは’〇〇がわからないので教えてください。’というレベル感をさします。） その先の質問された人（以下回答者）にとってはとても答えづらい質問になっています。 前項に記載した様なスタイルで質問をしたらお互いがWin-Winになれると思うので自分なりの質問Formatを作成して質問をしてみてはいかがでしょうか。

先日見かけたQiitaの記事を貼っておきます。

情報を集める力(情報を見抜く力)

私が普段、新しい情報をキャッチアップするために行なっていることについて簡単に描きたいなと思います。

極端な例ですが、１年前には最新だったことも今では少し古いものになったり、他の’何か’が出てきて手段が複数になっていたりということもあり得るのではないでしょうか。 （実際にあるかどうかはわからないです）

こういったことが起きる可能性がある以上、私たち技術者（やそれに近い人）は常に新しい情報をWatchすることが大事だと思っています。 すぐに自分がその技術やその話題を活用することがなくとも、半年後、数年後にはその技術に触れることがあるかもしれません。そういった技術傾向や最新話題をWatchするのは将来的にみても良い投資時間だと思っています。

以下が普段自分が使っている媒体です。

  • slack, discordの様なコミュニティチーム
  • medium, dev.to, qiitaのDaily投稿や、自分が気にしているTagのFeed
  • はてブの最新投稿
  • その他、企業のTechBlog等
  • Twitter(OSS committerさんとか)

こういったものを朝の電車や帰りの電車、また暇な時に見る様にしています。 技術書による、inputも大事にはしていますが、今の私にとってはこういった生きている情報をもらうことの方が勉強になるし面白い話題を知るきっかけになるため楽しく読んでいます。 （あと英語を読む練習にもなりますねw）

p.s 自分が読んだ媒体をいい感じにメモっていい感じに見返す媒体がほしいんですが。オススメありませんか。

以上でMake IT AdventCalender最終日の投稿情報が錯綜する世界の中で頑張る(生き残る)ために...を終了します。 最後まで読んでいただきありがとうございました。

*1:めっちゃ雑