改めて説明する必要もないのですが、本や動画サービスによるインプットに関してはマークダウン形式でまとながら行うため、そこまでアウトプットが苦ではありません。 逆に外部サービスを使った資格学習のための問題演習などは少し手間です。 読書や動画サービスのようにマークダウンにまとめながらアウトプットしてもよいのですが、資格系の問題演習は移動時間や隙間時間に利用することも多いので、都度Githubにコミットするのは難しいです。 なんとか作業を自動化したいので以下のような方法を利用するようにしてみました。 学習履歴のデータを取得する 例えばStudyplusではAPIが提供されています。 利用しているサービスによっては、このようにAPIを提供してくれていたりするので、これを利用してデータを取得します。 またサービスの利用規約を確認して、常識的な範囲で自身の学習履歴のデータをスクリプトを組んで取得するのも

VP of Technology の星 (@kani_b) です。技術基盤や研究開発領域などを担当しつつ、社内の色々なことを技術の力でいい感じにする仕事をしています。セキュリティや AWS の話が好きです。 さて、みなさんは、ご自身が勤務する会社の就業規則を読んだことはあるでしょうか。 エンジニアに限らず、会社の全スタッフが仕事をする上で関わってくるのが、就業規則や情報セキュリティドキュメントなど、会社のルールや規程を記す文書です。 特にセキュリティやインフラに携わるエンジニアは、その改訂も含め携わったことがある方もいるのではと思います。 よくある文書管理 こうした文書は、以下のように管理されていることが多いようです。 ベースドキュメントは Word 保存時は PDF で保存 版管理は Word の編集履歴 + PDF に保存する際のファイル名 編集は担当部門, 担当者のみが行う かつての

Pythonプロフェッショナルプログラミング 第3版 作者:株式会社ビープラウド秀和システムAmazon これすんごい良いです。 まだChapter 06までしか読んでないんですけども。 すんごいよさそうです。 プロフェッショナルプログラミングだからプロプロって呼ぶんかと思ったら、 pypro(ぱいぷろ)って呼ぶらしいですね。気に食わないからプロプロって呼びますね。 ということで、今回は、プロプロにも書いてあった内容（Chapter 03）gitconfig について。 まずは以下を打ちましょう。 $ git config --list ハイ、何が出てきますか。 何も出てこないあなたは人生損してます。 定番 git config --global user.name {ユーザー名} git config --global user.email {メールアドレス} これを設定していないとpu

git を使っているとよく遭遇する「autocrlf どう設定する？」問題について、詳細を忘れた頃にまた相談を受け、またまた色々と調べて理解が深まり折角なのでメモっておきます。今回は git config について、です。 ゴール 結局のところ、現在、有効になっている設定は何？を確認したい。また、それはどこで設定されている値が生きてるの？（どこを変更すれば変えられるの？）を理解したい。 現在の設定値は？ 対象の設定Keyが明確な場合 特定の設定 key について、現在、有効になっている設定を確認したい場合は、下記のコマンドを入力すればいい。

GitHubは、GTP-4ベースのAIを用いた開発支援機能「GitHub Copilot Chat」を、GitHub Copilot for Businessユーザー向けに限定パブリックベータとして公開すると発表しました。 GitHub Copilot Chatは、今年3月に発表された同社のビジョン「GitHub Copilot X」で登場が予告されていた機能の1つです。 現在提供されているGitHub CopilotはGPT-3のAIをベースに、コードエディタ内でプログラマがコメントを記述するとそれに基づいてコードを自動生成する機能などを提供しています。 「GitHub Copilot X」では、強化されたAIであるGPT-4を用い、さらに高い精度でのコード生成やバグの指摘などを始めとする、以下のさまざまな新機能などを備えると説明されていました。 コードエディタ内でAIとテキストチャット

TL;DR 読むのが面倒な人は 私が一番訴えたい事： PR がレビューされない環境を作らない を読んでください。 その他のものは、周りの開発者体験をより良くするための手法について提示しています。 初めに この記事は GitHub での開発者体験をより良いものとするため、チームメイトにこの記事を見せて GitHub 上での開発手法を合わせたいという意図があります。 より良い開発体験を見つけたり躓いた部分があった場合は適宜更新されます。 また記事を見ている方の意見も募集しております 皆でより良い開発者体験を得られる環境を考えられたらと思います。 私が一番訴えたい事： PR がレビューされない環境を作らない Git を使った開発をした事なら誰にでもある、PR が全然レビューされない問題 は開発者体験を下げる大きな要因です。 そこが タスクを止めている明確とした要因 にも関わらず、誰もレビューしな

これをみるとinputやfalseはLF -> CRLFの自動変換を行わないので、これらを選んでしまいそうですが、 大規模開発で多数の開発者がtrueでインストールしてしまった場合、わざわざ変更をしてもらうまでの悪影響があるのか？がわからなかったので、それについて調べた結果を記載しようかと思います。また、これを書くきっかけとなった私のチームではまった落とし穴について書こうと思います。 core.autocrlfをtrueに設定をした場合 core.autocrlfをtrueに設定をした場合について整理します。 チェックアウトやコミットした場合の動きや、開発者がCRLFでファイルを作成した場合の動きは以下のようになります。 上記の図から確かにwroking directory上ではCRLFとLFが混在してしまう可能性がありますが、 repository上のファイルがLFである以上、core.

4 月から新入社員となって本格的にエンジニアとして生活し始めた方も多いかと思います．いままであまり GitHub を使っておらず，会社から要求されてはじめてまともに使い始めた方もいるかもしれません． そんな方々にお願いがあります． GitHub を使うなら通知くらいまともに設定してくれ あなたがこのタイトルを読んでピンときていないのであれば，あなたの通知設定はおそらく間違っています．GitHub は初期設定だと非常に多くの通知を送信します．それは GitHub 自身が通知ページで述べているくらいです． 通知はあなたが思う以上に大切な存在です．必要とする通知は人によって様々であり，それを見逃してはいけないため，ときに GitHub は必要以上の通知を送信しています．しかし，必要以上な通知を受け取ると，人は通知を見ないようになってしまいます． 個人開発ならそれでもよいかもしれません．しかし，あ

スタートアップの技術情報交換の場を提供することを目的として設立された「Microsoft Startup Tech Community」。「Microsoft Startup Tech Meetup #0 kick off」は、「Microsoft Build 2023」をテーマに開催されました。ここで登壇したのは、株式会社ワークスアプリケーションズの菊地洋氏。「GitHub Copilot Chat」のフロー体験について発表しました。 GitHub Copilot Chatを触ることでWindows Copilotの後の世界を体感できる 菊地洋氏：私は菊地と申します。ワークスアプリケーションズという、日本企業向けに会計ソフトなんかを作っている会社で働いています。勤続十数年で、実は基本的には同じ製品をずっと開発・保守しているキャリアなので、みなさんとは違ったキャリアという点でちょっと違った

先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように