新しくウェブ系のシステムを開発するときにやったことがいいことを書いておきます。コードを書くスキルとはちょっと別なのでこういうのは経験がないと身につかないけど超重要です。 1. システム構成図を描く どんなシステムがあってどんな流れで処理が進むのかを絵に描く。かっちょいい設計書じゃなくてもいい。手書きの雑なやつでもいい。一個一個の処理に「〇〇君」のような名前を付けていくといい。「JSON書き出し君」みたいな感じ。 2. 誰が何をやるかを明確に タスクを洗い出すだけではなく、誰がどこまでやるかを明確にする。1で描いた絵に担当をアサインしていくと漏れがない。 3. リリース日を決める リリース日を決めずに開発を始めるとパリッとしない。リリース日を決めて、アプリの申請、 QA の予定などを埋めていくと、何日までに開発を終わらせておかなければならないかが逆算的にわかる。間に合わなそうであればリリース
こんにちは。pixivのnamazuです。 先日開催されたPIXIV DEV MEETUP 2024にて、『pixivというシステムはどんな形をしているのか、それはなぜか。』というテーマで発表をさせていただきました。当日、セッションにご参加いただいた皆さま、そしてフィードバックをいただいた方々に、改めて感謝申し上げます。 Webサービス開発において面白い点の一つは、どのサービスもその要件や状況に応じて異なる選択がなされることです。結果として、類似点がある場合もありますが、細部において同じものはなく、すべてがユニークです。弊社内でもさまざまな違いが見られますが、業界全体を見渡すとさらに多様性が広がっていることでしょう。 今回の発表では、pixivのシステムに関する重要な要件や状況をいくつか取り上げ、現時点でどのような構造になっているかを、インフラストラクチャ、バックエンドアプリケーション、開
本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期
今まで id:mizdra はターミナルで Git ブランチを切り替えるときに、zsh + peco を使った Git ブランチ検索用のキーバインドを使用していた。 # .zshrc function select-git-branch() { selected_branch=$(git branch | cut -c 3- | peco) BUFFER="${LBUFFER}${selected_branch}${RBUFFER}" CURSOR=$#LBUFFER+$#selected_branch zle redisplay } zle -N select-git-branch bindkey '^b' select-git-branch zsh + peco で Git ブランチを切り替える様子 便利っちゃ便利なのだけど...沢山のブランチの中から「あの時作業していたあのブランチ」
開発用適当ツールは Go で作るのがオススメ！？ 先日、開発用適当ツールはGoで作るのがオススメ という記事を拝見しました。 まだ読んでないよという方はぜひ読んでみてください！ とても良い記事でした😌✨ Go 言語も CLI ツールの実装に向いているということも分かりました。 そして、Go 言語の魅力も伝わってきました...！！ まとめると以下のような点がメリットとして挙げられていると思います。 go run で簡単に実行できる シングルバイナリにクロスコンパイルできる go.mod / go.sum が依存性管理を楽にしてくれる 動作速度も申し分なし たしかに開発用適当ツールの作成というユースケースは Go は魅力的な選択肢だと思います！ 開発用適当ツールは Rust で作るのもオススメ 前置き 最初に大事なことを言っておきます。 タイトルにもあるように、Rust も であって GO
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
エンジニアの岡村です。 自分はサーバーがメインではなく、あまり業務でガッツリ触るわけでもないのですが、最近それなりに活用するようになってきました。しかし、ネット上の日本語情報を読んでいるだけではこれの書き方が正しいのかよく分からない、と悩むことが結構あったため、色々情報を漁ってみました。 この記事は、特に自分が気になった部分の調べた結果を記事に纏めてみたものです。対象読者はdocker-composeを雰囲気でupやdownは叩けるけどComposeファイルの書き方がよく分からんとなってる人です。 Docker Composeの概要とcompose.yaml、Compose Specの関係 compose.yamlの書き方は Compose Specに準拠すればOK Compose Specの場所 推奨のファイル名はcompose.yaml compose.yaml内にバージョンを記述する
同僚に「GitHubのMerge Queueってあんまり知らないんだけど、どう思う？」って聞かれて「あー。僕もあれよく分かってないんだよね」って返事をして、ちょうどいい機会なので見てみた 見てみた感想としては、いくつか気をつけておきたい点があるけど、チームの開発の進め方にうまくはまれば便利な機能だな、という感じ（なんでもそうか・・・） Merge Queueって? 2023年の7月にGAになったGitHubの機能 プルリクエストをマージするときに「マージ先のブランチ（ベースブランチ）の最新の変更を取り込んでからChecks（つまりCI）を実行して、それが成功したらマージしといて！」ってお願いできる便利機能。名前のとおりQueueになっているので複数のプルリクエストからenqueueできて前から順番に処理してくれる そうは言われても最初に説明を見た僕は「？？？」状態だった。「なんでこんな機能
GitはLinuxカーネルのソースコード管理に用いるために開発された分散型バージョン管理システムで、GitリポジトリをホスティングするGitHubのユーザー数は1億人を超えます。一方、軽量データベースのSQLiteの開発においてはGitではなくFossilというバージョン管理システムが利用されており、SQLiteの開発陣が「なぜGitを使用しないのか」という理由を公式サイトで説明しています。 Why SQLite Does Not Use Git https://sqlite.org/whynotgit.html なお、Fossilがどんな機能をもつバージョン管理システムなのかについては下記の記事を読むと分かります。 GitとGitHubの機能をひとつのバイナリに詰め込んだ「Fossil」レビュー - GIGAZINE 1：Gitは適切な状況認識を提供しない SQLiteにどんな変更が加え
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
Give Up GitHub! On Wednesday 29 June 2022, we began calling on all FOSS developers to give up on GitHub. We realize this is not an easy task; GitHub is ubiquitous. Through their effective marketing, GitHub has convinced Free and Open Source Software (FOSS) developers that GitHub is the best (and even the only) place for FOSS development. However, as a proprietary, trade-secret tool, GitHub itself
ある Vercel ユーザーが「空っぽの状態」の画面に適切な導線が表示されているのを褒めたら、 Check out this delightful empty state by @Vercel! pic.twitter.com/qFkhFcUlwq— usrnk1 (@usrnk1) 2023年6月14日 Vercel の CEO が GitHub の new repo screen を参考にして意図的にやっているのだといい、 My love language is thoughtfully designed empty states See: @github's timeless new repo screen with `git` copypasta. https://t.co/ADFg52G7Ba— Guillermo Rauch (@rauchg) 2023年6月14日 それを受け
Unit4の永山です。 dotfiles弄りを趣味にしています。 世にdotfilesを題材とした記事は数多く存在していますがその大半は「dotfilesを作ってみた」「こうやって管理しています」などの表層的な部分の紹介に留まり、その奥にあるべき細部のこだわりや個人の思想にまで踏み込んだ記事は数えるほどしかありません。 そこで、本記事では私のdotfilesを題材にその各構成要素についてオススメ, TIPS, こだわりに分類し、可能な限り詳細に紹介します。 github.com 本記事は筆者の関心の都合上、Zshに関する項目に大きく比重を置いています。ご承知おきください。 dotfilesとは dotfilesを作成することの利点 記事の構成 Zsh編 [オススメ] プラグインの管理にZinitを使う 注釈: Zinitについて [オススメ] Zshプラグインは非同期読み込みする [オスス
Note 本記事の内容は Linus 氏の発言が人を傷つける場合に筆者がそれを良しと考えるといった意図はございません 少し古い記事になるが、 Linus Torvalds 氏 の GitHub に対する苦言が記事になっていた。 LinuxカーネルにNTFSドライバーが追加、トーバルズ氏はGitHub経由のマージに苦言 - ZDNet Japan Linus 氏が GitHub について苦言を呈するのは今に始まったことではない（後述）が、 別に GitHub のすべてを否定しているわけではない。[1] では一体何が不満なのか。Linus 氏の理想とする git の開発フローを考察した上で、整理してみたい。 Linus 氏の理想 結論からいうと、 「意味あるコミットを作れ」「コミットを大事にしろ」 という思想が伺える。 では 「意味あるコミット」「大事にされたコミット」 とは何なのか。 筆者な
日常的にターミナル画面からコマンドラインインターフェイス（CLI）を使って仕事をしているITエンジニアであっても、使い慣れないシェルコマンドのオプションをなかなか思い出せないことや、めったに使わないGitコマンドを調べながら試してみる、といったことがあるのではないでしょうか？ GitHubの研究開発部門であるGitHub Nextは、自然言語でAIと対話しコマンドライン入力を支援してくれる「GitHub Copilot CLI」のプロトタイプ公開に向け、ウェイティングリストへの登録を開始しました。 下記はGitHub Copilot CLIの開発者の1人であるMatt Rothenberg氏のツイートです。登録開始はこのツイートで告知された模様です。 We're finally ready to start flagging users in to GitHub Copilot CLI I
Today, I’d like to announce Homebrew 4.0.0. The most significant change since 3.6.0 enables significantly faster Homebrew-maintained tap updates by migrating from Git-cloned taps to JSON downloads. Major changes and deprecations since 3.6.0: Using JSON files downloaded from formulae.brew.sh for package installation rather than local homebrew/core and homebrew/cask taps. Please note: this is the la
GitHub Enterprise Cloudは、SSH証明書をサポートするようになりました。これにより、企業や組織は所属するメンバーがリポジトリにアクセスする方法をより高度にコントロールできます。SSH証明書では、あるSSHキー(認証局)で別のSSHキーに署名でき、キーの所有者である開発者の情報も含まれます。管理者はSSH認証局(CA)の公開鍵をアップロードして、メンバーがGitの認証に使用する証明書の発行を開始できます。証明書は、企業または組織に属するリポジトリへのアクセスのみに使用できます。また、管理者は、リポジトリへのアクセス時に証明書の使用を必須にできます。 SSHキーとの相違点 SSH証明書とSSHキーと相違点について説明します。GitHubでは、当初よりSSHキーをサポートしています。これは、個々のユーザーを安全に識別する暗号キー です。その一方で、SSHにはSSH証明書の
みなさんこんにちは。Backlog課のGitチームに所属するテリーです。Gitを触ってるとたまにちょっとした集計をしたくなります。その度に検索したり考えたりするのも少しめんどくさいので、業務上ではあまり必要ではないがたまに確認したくなるようなコマンドを集めてみました。どのコマンドも書き換えることなくコピーアンドペーストで動くようになっているのでぜひ興味を持った方は自分の環境で試してもらえると嬉しいです。 リポジトリの傾向を知るコマンド 一定期間毎のコミット数を知る 「このリポジトリっていつ頃が一番盛んにコミットされていたのかなー？」 GitHubなどが提供しているこの機能実はBacklogでは提供されていません。（今後の機能開発頑張ります）そのためちょっと気になった時にコマンドで探れると大変嬉しいです。 年別・月別を知る git logの出力結果をAuthor dateだけにして--dat
歴史改変、してますか？ 私は歴史改変が大好きで、毎日 rebase しています。なので割と毎日 git push -f することになっています。 口で -f と言っても、実際には --force-with-lease --force-if-includes をしているので、これらのオプションのご紹介。 この記事は はてなエンジニア Advent Calendar 2022 の 18 日目です。昨日は id:rokoucha さんで 壊れたデータベースとの向きあいかた - rokoucha でした。 qiita.com -f の危険性 ...--F--G--H <-- main という状態で push した後、H をコミットし直したとしよう。 ...--F--G--H' <-- main \ H <-- origin/main このまま H' (main) を origin/main に p
今日は軽めの話題で。 先日 Prettier 2.8 をリリースしました。 We just released Prettier 2.8. This release includes support for TypeScript 4.9 satisfies operator and improvements to the --cache CLI option!https://t.co/Yfs7Pd5MsD — Prettier (@PrettierCode) November 23, 2022 TypeScript 4.9 で追加された satisfies 演算子 のサポートや --cache オプションの改善が含まれていて、人によっては嬉しいんじゃないかと思います。 この Prettier 2.8 ですが、実はリリースするつもりはありませんでした。 というのも、本当は Prettier 2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
