ECSを運用で使っていて難しいと思った点 - アジャイルSEの憂鬱
ECSを触っていて今まで難しいと思ったことを雑にまとめておく。 ECSを仕事で運用するときに必要な知識が多すぎる。こんなの社内に1人AWSマスターいないと無理だ...— 神速 (@sinsoku_listy) 2021年8月10日 タスクロールとタスク実行ロールの違い ECSを長く触っているのに、いつも混乱する。 タスクロール コンテナ内の権限 S3やSESなどの権限をつける タスク実行ロール コンテナ外の権限 ECRやParameter Storeの権限をつける ECSのデプロイ時に静的ファイルが404になる ECSを触った初期に遭遇した。 詳細は以下のQiitaの記事が分かりやすい。 参照: ECSのデプロイ時に一定確率で静的ファイルが404になる問題を回避する 回避する方法はいくつかある。 静的ファイルをS3に置く CodeDeployの OneAtATime を使う CodeDep
Gitのプルリク（ブランチ）単位でログを追う方法 - アジャイルSEの憂鬱
過去に「よいコミットメッセージとは」みたいな記事を書いたこともある。 sinsoku.hatenablog.com なぜコミットメッセージは良くならないのか どうしたらGitのコミットメッセージが良くなるか考えてみたけど、 他人に期待するには無理がある という結論に至った。 技術的な課題 Gitで rebase -i を使ってコミットを直すのが難しい コミットメッセージを直すたびにCIが走る デプロイが遅くなる 会社的な理由 雑なコミットメッセージでもマージされるケースが多い レビュワーはコミットメッセージまで読まない コミットメッセージは評価（＝給与）に繋がらない コミットする人の心理 コミットメッセージなんて使わない 雑なコミットする人は git-log や git-blame をそもそも使っていない Slackで聞くなり、テレカンで相談すれば済むので 現実的な解決案 プルリクにだけは
git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
git-worktree を使って時間のかかる処理を別の作業ディレクトリで行う - アジャイルSEの憂鬱
時間のかかる処理の実行中、別の作業を進められるようにする方法。備忘録。 時間のかかる処理の例 テストの実行中 デプロイの実行中 など。 git-worktree を使う 簡単に作業ディレクトリを増やせる。 $ cd ~/works/app $ git worktree add ~/works/app_deploy $ cd ~/works/app_deploy $ git status On branch app_deploy nothing to commit, working tree clean 新しく作成された app_deploy の作業ディレクトリでも普通のリポジトリと同じように作業ができる。 注意点 両方の作業ディレクトリで同じブランチを使えない 作業ディレクトリを2つに増やしても、同じブランチは使えません。 別名のブランチを作る必要があります。 リポジトリは共通 リポジトリ
Railsアプリの開発環境を速くするための調査 その1 - gemの読み込み時間 - アジャイルSEの憂鬱
その1って書いたけど、続くかは不明。 今回は使っているgemの読み込み時間を測ってみた。 Benchmark を仕込む config/application.rb でgemを読み込む前に Kernel.require を上書きして、計測する。 +require 'benchmark' +$result = {} +Kernel.singleton_class.prepend(Module.new do + def require(feature) + ret = nil + $result[feature] = Benchmark.realtime { ret = super } + ret + end +end) Bundler.require(*Rails.groups) +$result.sort_by { |_, t| -t }.take(20) + .each { |featur
Rails の issue を解決するまでの手順とOSS初心者でもできること - アジャイルSEの憂鬱
突然ですが、あなたはRailsのissueとプルリクがいくつあるかご存知でしょうか？ 2019年10月17日現在、それぞれ issue 384 / PR 803 になります。 多いですよね...。 個人的に、最近このissueを減らすのを少しでも手伝えないものかとissueにコメントしてみたり、パッチを書いたりしてるけど、 なかなか大変なので、コントリビューターの敷居を下げるためにブログ記事を書いてみました。 コントリビュータが増えれば、きっとissueも減るはず！！ Rails への貢献について Railsガイドに丁寧な説明が記載されているので、読んだ事がない方は一読するのをオススメします。 railsguides.jp この記事で紹介すること Rails への貢献方法は色々なものがあります。 新機能の追加 バグの報告 バグを修正するプルリク作成 ドキュメントの追加や修正 ...etc
コミットメッセージを書くときに気をつけていること - アジャイルSEの憂鬱
コミットメッセージに関するブログを読んだので、自分がコミットメッセージを書くときに気にしてることを書いておく。 chiastolite.hatenablog.com sue445.hatenablog.com 基本的な話 まずは Gitのコミットメッセージの書き方 を読んでおく。 コミットメッセージは "将来の同僚のため" に書く 3ヶ月後にチームに入った人が理解できる内容 になっているのが理想。 チームメンバーが分かる内容で満足すると、暗黙的な業務知識に依存したコミットメッセージになっていることがあるので注意。 XXXを追加/変更/削除しました はダメ 油断するとこういうメッセージを書いてしまいがち。 git-diff の内容を日本語で書いただけだと意味がないので、コミットメッセージで付加価値がつくように気をつける。 コミットした後に見直す コミットした後、git show @ を実行し
2月末に株式会社groovesを退職します - アジャイルSEの憂鬱
2018年2月末に株式会社groovesを辞めます。 おそらく、退職エントリってやつです。 株式会社groovesでやってきたこと Forkwellの開発を担当していました。サービスの詳細はリンク先を読んで頂くとして、私が主に関わっていたのは下記の2つです。 Forkwell Jobs: エンジニア専門の求人サイト Forkwell Portfolio: エンジニア向けのポートフォリオサイト 特にPortfolioの「エンジニアの技術力を可視化する」というコンセプトは私の提案から始まっていて、仕様の作成、設計、実装とだいたい全てを担当していました。 技術的にやってきたこと 新しい機能の実装以外で、開発環境を色々と改善してきました。 Werckerを導入して、ブランチ毎にテストを実行するようにした Jenkinsをリストラした wheneverでcronの設定をコード化した RuboCopを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
