結局Githubに学習履歴を統一した方が諸々良かった
改めて説明する必要もないのですが、本や動画サービスによるインプットに関してはマークダウン形式でまとながら行うため、そこまでアウトプットが苦ではありません。 逆に外部サービスを使った資格学習のための問題演習などは少し手間です。 読書や動画サービスのようにマークダウンにまとめながらアウトプットしてもよいのですが、資格系の問題演習は移動時間や隙間時間に利用することも多いので、都度Githubにコミットするのは難しいです。 なんとか作業を自動化したいので以下のような方法を利用するようにしてみました。 学習履歴のデータを取得する 例えばStudyplusではAPIが提供されています。 利用しているサービスによっては、このようにAPIを提供してくれていたりするので、これを利用してデータを取得します。 またサービスの利用規約を確認して、常識的な範囲で自身の学習履歴のデータをスクリプトを組んで取得するのも
rebase 教から脱退します - Qiita
rebase で色々あったので、備忘録として簡単に書いていきます。 前提背景 開発作業中、元のブランチに変更があった場合、私は変更を取り込むために常に rebase を使用します。これを選ぶ主な理由は「コミットログが見やすく保たれるため」です。 Gitには同様のコマンドとして merge がありますが、これは変更を取り込む際にマージコミットを作成する点が異なります。私はマージコミットによってコミットログが煩雑になると感じています。 このような理由から、私はrebaseを積極的に使用しています。 何があったのか 簡単に言うと、レビュー中にブランチ元の変更があったので、 git rebase からの git push -f origin [ブランチ名] やったらレビュアーのコメントが吹き飛びました。 いやー、めっちゃ怒られたよね💦 原因 「レビュー中」という状況がまずかった。 コードを共有し
サーバーレスの次はなんなんだ
はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい！」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください！ メガクラウドと特化型クラウド／ハイパーバイザーのSoC化／ライセンスとクラウドベンダー／イベント駆動型API／LLM時代のAIペアプロ力／生活必需品としてのGPU・NPU／Passkey／ウェブアクセシビリティ／リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS（Function-as-a-Ser
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
