ライブコーディングで GitHub Copilot を使うべきかどうか - TechとPoemeの間
TL; DR 場合による "How to" を教えるライブコーディングの場合は、切ったほうが良い 設計議論を中心に行うライブコーディングの場合は、使うと良いことがある 文脈 最近の仕事の中で、プログラミングを学んでいる人々の前で、オーディエンスのスキルアップを目的としたライブコーディングを実施したり、ライブコーディングセッションのアレンジをしたりファシリテーションをしたりしている。少々性格の異なるライブコーディングを数パターン行うなかで、「ライブコーディングで GitHub Copilot を有効にするべきかどうか」という問いに答えるに当たって一つの指針が見えてきたので書き残しておく。 How to を教えるライブコーディングでは Copilot を切る 自分が担当したライブコーディングは、特定のテスティングフレームワークの使い方やテスト駆動開発の講義だったのだけど、このような「特定のツー
github という公的なインフラを使うために必要なこと - アンカテ
馬しか見たことない人に、これと自動車を両方見せて「どっちが欲しい」と聞いたら、どちらを選ぶだろうか？ 理性的な人だったら、自動車が平らな道しか走れないことを一番気にするだろう。 ボストンダイナミクスの四足自走機械は、馬が走れる道ならほとんどそのまま進める。道が舗装されてなかったら、自動車で行ける範囲は本当に限られている。どうみても、四足自走機械の方がずっと実用性が高い。 「道を舗装して、トンネルや橋を作って道を平らにすればいいんですよ」なんて言ったら、「たかが乗り物のためにどうしてそんな手間をかけなきゃいけない？」とあきれてしまうだろう。 私は、今、github を中心に仕事が回る職場で働いている。実際使ってみて、この github というものは非常に便利だと思うのだが、過去の自分にこれを勧めてみたらどういう反応するか想像してみると、これと同じ反応になると思う。 私が働きはじめたのはワープ
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
gitのbranch ruleを決める際の個人的チェック事項 - 愛と勇気と缶ビール
プロダクションリリースの前は適当でいい。適当にfeature branch切ってガンガンmasterにmergeしてdeployすればいい。変更の種類によっては直接masterにぶち込んでしまえばいい。スピード感が大切な時期なので、いちいちbranch ruleを定めてそれを遵守すること自体が時間の無駄。 プロダクションリリースからそれ以降は、 プロダクションにはmasterとか特定のbranchではなくtagを切ってそれをdeploy。切り戻す先は一つ前のtag プロダクション以外の環境には特定のbranchをdeploy。切り戻すというか修正の仕方は適宜。 という感じにする。それに加えて、「feature branchを現在の最新安定版にmergeした状態で結合testが出来るbranch」があるとよい。「それってmasterじゃね？」masterではない。masterをこの目的に使う
意識の低いgitの始め方 - Qiita
対象 意識低い人 これから始めたいけどなんかgit使ってる人怖いって人 操作 これだけは覚えとけって操作 コミット これができないとお話にならないので 以上 これ以外は使いながら覚えればおｋ （リモート使うんならpull/pushも必要かもね） ツール 意識高い人「gitはコマンドライン叩いてナンボ」 - 最初はコマンドとかほっとけばいいよ とりあえずオススメのGUI系 Windows GitExtensions http://gitextensions.github.io/ Mac SourceTree http://sourcetreeapp.com/ Linux 意識低い人がLinux使ってるはずないので省略 WindowsにもSourceTreeあるけど、UIが英語なので意識低い人は日本語化されてるGitExtensions使っとけ 「WinもMacも使うんだよ！」って人はSour
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
bitbucketの使い方