SlackメッセージからGitHub issueを作成するSlackアプリです。Flow情報をStock情報に変換することで価値ある行動につなぐことができます。issueをTODO管理として活用したい人にもおすすめです。
より良いコミットメッセージを残すことは Git を使った開発をする上で重要なことです。優れたコミットメッセージは、それを読んだ人がコードを理解するのに大いに役立ちます。 では、どのようなメッセージが良いもので、どのようなメッセージが悪いものなのでしょうか? それについて掘り下げていきたいと思います。 基本的な Git Commit Message の書き方 詳しいところは、以下の3サイトを参照してください。特に「How to Write a Git Commit Message」には基本がすべて書かれています。 How to Write a Git Commit Message https://cbea.ms/git-commit/ Gitのコミットメッセージをうまく作成する7つのルール (「How to Write a Git Commit Message」の和訳記事) https://
はじめに はじめまして、yasuda_naoto と申します。 未経験から WEB エンジニアとして活躍するために RUNTEQ というプログラミングスクールで学習しています。 概要 RUNTEQ ではミニアプリ作成会というものがあり、2023 年の 8 月に青春をテーマにたくさんのアプリが投稿されました。 その際に、愚かな私は「面倒だからgit add .してそれらを一気に commit して push すればええやろ」という、プログラマにあってはならないめんどくさがり精神で作ったアプリをリモートリポジトリに push してしまったのです。 その際に起きた悲劇を再現します。 更に、同じ轍を踏まないように、それを防ぐ方法と、もしあなたが同じしくじりをしてしまったら、そこから立て直す方法をご紹介します。 要点 細かく add & commit しなかったばかりに push が途中で進まなくな
分散型バージョン管理システムのGitは2005年の登場以降シェアを伸ばし続け、2022年の調査では約94%のユーザーに利用されるほど一般的なツールとなっています。Gitにはさまざまな機能が搭載されていますが、その中で特に混乱を引き起こしがちな用語について、Gitを15年近く使用してきたというジュリア・エヴァンスさんが解説しています。 Confusing git terminology https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ ◆HEADと「heads」 HEADは現在チェックアウト中のブランチやコミットを指しており、「.git/HEAD」に保存されています。一方「.git/refs/heads」に保存されているのはブランチで、「heads」は「branches」と読み替えればOKとのこと。 ◆detached HE
タイトルがすべて。 思いついたら手を動かしてしまう性質なので、秘蔵のブランチを大量に持っている。 秘蔵のブランチというのは、動いたけどチームメンバーを説得するのが面倒とか、テスト書くのが面倒とか、だいたい動いているけどやりきるのが面倒とかで main にマージしていないヤツ。 例えばフレームワークのメジャーバージョン上げるブランチとか、依存ライブラリをより一般的/現代的なものに交換するブランチや、より良い設計を思いついたのでガッと書き換えてしまうブランチが多いかな。 だいたい 1 年所属していると 80 ブランチぐらい溜まるので、週 1 つ以上は何か作りかけてる計算になる。 ローカルブランチの数、プロンプトに出しておくかな……。(秘蔵のブランチが溜まってる— Takafumi ONAKA (@onk) March 28, 2017 もちろん自分でいいアイディアだと思っているから実装している
ホームソフトウェアLinus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス Linus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス 2023 2/22 LinuxおよびGitを開発したLinus Torvalds氏が、Gitのマージに関して直々にアドバイスしていた事がわかり、注目を集めています(Phoronix)。 Linus Torvalds氏のGitマージに関する実践的なアドバイスは「もしマージのことを説明できないのなら、やらないことだ。これは本当に簡単なことです。マージの理由を説明しないままマージすることは絶対に許されない」というものです。 Linus氏はマージに対するコメントが十分に含まれていないプルリクエストを発見し、我慢の限界を突破し
こんにちは、id:rokuokunです。 Perlとの出会いは突然やってきます。 いつ求められてもサッと対応できるように、いち早くPerlを書けるようになっておきましょう。 perl --version 今回入門するにあたり使用するバージョンは Perl 5.40.0 です。 インストール作業については割愛しますが、困ったらplenvを使っておけばいいと思います。 ❯ perl --version This is perl 5, version 40, subversion 0 (v5.40.0) built for darwin-2level Copyright 1987-2024, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Pu
前置き2022.7.24 一般公開シンポジウム 「フェミ科研と学問の自由」 https://www.youtube.com/watch?v=FP8rL7KfisI より、清水晶子氏発言部の文字起こしである。 長いため講演部Part1~Part5+質疑応答の6部に分割する。 分割の境界はスライドにある番号に従うが、副題は増田の判断である。 スライドはすべて図表のない文字ベースのものであったため、引用記法を用いて本文に組み込んだ。 講演部については、「女性スペースを守る会」が公開している文字起こしをベースに、 増田が誤字の修正や、句読点の変更、改行の追加などの編集を行った。 質疑応答部、スライド部の文字起こしはすべて増田が行った。 批判記事の紹介まず、江口聡先生による、8/9のブログ記事は必読だと考える。 「清水晶子先生の「学問の自由とキャンセルカルチャー」講演」(https://yonosu
アメリカにおける黒人差別問題が再び大きく話題となる昨今だが、プログラミング界隈でもGitのデフォルトブランチ名である「master」が奴隷制に基づくものであるとして「trunk」に変えようという動きが上がっているらしい(outsider reflex、blacklist/whitelist master/slave に関する情報集め)。 特に大きな話題となっているのは、GitHub公式のCLIツールが、デフォルトブランチ名を「master」から「trunk」に変える変更を行った話である。この件についてのissueは反対意見も出ていたものの、管理者の一存で5月27日にマージされており、今後利用者に大きな影響を与えることになるとみられる。 なおGitでは「slave」は使われておらず、Gitの「master」は奴隷と関係ない「master」ではないかという意見もあるが、Gitの「master」
人種差別の問題、経済格差の問題、男女差別の問題 これらをリベラル派は「構造的な要因」に原因を求めている 「構造的な要因」に原因を求めるということは、人間の行動は構造によって決定されるという考え方をとっているわけで、自由意志を否定している にも関わらず、自由意志をリベラル派は尊重しているのである 例えば、アファーマティブアクションとして、理系の大学に女子枠を作る話などもそうである 構造的な要因で、女性が理系の大学に進学できないという説明をするのならば、当然にしてそこに人間の自由意志はない しかし、リベラル派は「女性は構造的な要因で理系の大学に進学できない」「女性の自由意志で大学を選べるようにするべき」という二つを主張しているのである これは明らかにおかしい 自由意志を認めるならば、有名大学に黒人が少ないのも、経済格差があるのも、議員に女性が少ないのも、全て「自由意志の結果」のはずである 自由
まだまだ 2022 年の振り返りが終わらないぜということで今日は dotfiles の振り返り。dotfiles はその変遷を見ると面白いので、毎年やろうと思い早速やっていきたい。 ちょっと前に M2 の MBA 買って、dotfiles を一新した。 これが今の dotfiles だ。 https://github.com/sadnessOjisan/dotfiles コンセプト 自分は Mac しか使わない が、WSL 環境も持ってるのでシェル周りの環境は移せるように作っておく(原神しかしないけど・・・) make all だけでセットアップが完結する 手作業はしない なるべく標準に準拠し、プラグインやライブラリへの依存を減らす。入れる場合も単体で剥がせるものを選ぶ。 シンボリックリンクを貼って、dotfiles の変更が即時に反映されるようにする .config など XDG に準拠
環境構築 以下の手順で構築していきます. Overleaf-Workshopの拡張機能をVScodeに入れる Latex-Workshopの拡張機能をVSCodeに入れる Latex-Workshopの設定を変更 texliveをインストール +α Grammarlyの拡張機能をVSCodeに入れる Grammarlyの設定を変更 1, 3, 5はVSCodeの拡張機能で検索すれば一瞬で出てくるのでスキップ. Latex-Workshopの設定を変更 Latex-Workshopの設定を変更します.以下を設定から変えましょう.cmd+,で設定のタブが開けると思います. Latex-workshop › Latex › Recipe: Default - first + lastUsed onSaveでtexソースをビルドするときに、デフォルト設定のfirstのままだとpdflatexのビル
On June 23rd, the WebKit project froze its Subversion tree and transitioned management and interaction with our source code to git on GitHub. Why git? git’s distributed nature makes it easy for not just multiple developers, but multiple organizations to collaborate on a single project. git’s local record of changes makes moving commits between branches or reverting changes simple and quick. git’s
Agile Journeyをご覧のみなさん、はじめまして。川口恭伸(@kawaguti)と申します。 私はアジャイル開発やスクラムに関する知識を提供し、モダンなソフトウェア開発の要素の研究、プロダクト開発の進め方やチームの目標設定など、さまざまな領域でのコンサルティングを手掛けています。 また、アギレルゴコンサルティング株式会社においてシニアアジャイルコーチとして活動しており、一般社団法人スクラムギャザリング東京実行委員会と一般社団法人DevOpsDays Tokyoの代表理事も務めています。さらに、コミュニティ活動としては、毎週水曜日に品川アジャイルに参加しており、RSGT、スクラムフェス、DevOpsDaysといったカンファレンスでのスタッフワークも担当しています。 このように、ほぼ公私の境なくアジャイルやスクラムを基にした活動を長く行っていますが、本稿では、私がスクラムを始めるまでの
GitHubがSubversionのサポート終了を発表、2024年1月8日まで。その後は全面的にGitに注力予定 GitHubは、GitHub.comとGitHub Enterprise ServerにおけるSubversionのサポートを、今から約1年後の2024年1月8日で完全に終了することを明らかにしました。 We'll be removing Subversion support from versions of GitHub Enterprise Server after January 8, 2024. Learn more here: https://t.co/djXDh1QCzh — GitHub (@github) January 23, 2023 Subversionは、プログラムのソースコードを管理するシステムもしくはその仕組みの名前で、クラアイント/サーバ型のアーキ
サマーズが第二次トランプ政権の危険性について深刻な懸念を表明している。 以下は12/20ツイート。 The @FT's Unhedged asked me about the macroeconomic implications of a second Trump term: When you have a president who challenges the results of elections and brags about what he could do in one day as a dictator, it is not something that can be completely relied on. That is a profound threat to our long-run prosperity, and therefore short-run asse
Pull Request(PR)やMerge Request(MR)を作る中で、コミット履歴はできるだけ綺麗にしておきたいものです。 プルリクエストについて - GitHub Docs Merge requests | GitLab ぼくはあまりコミット履歴の綺麗さを気にしない方でした。 しかし大きめのPRやMRをレビューする側に回ると、「変更のまとまり」が追えないと「なぜこの変更をしたのか」が非常に追いにくくなります。 だからこそ最近は、コミット履歴をかなり意識するようになりました。 その時に活躍しているのが、タイトルの通りgit commit --fixupとgit rebase --autosquashです。 git commit --fixup git rebase --autosquash そのほかおすすめ git commit --fixup git commit --fixu
「値オブジェクト」の定義について不勉強だったので「DDDの値オブジェクト」の定義とDDD以外の「値オブジェクト」との違いについて、改めて関連書籍を読み直し整理してみました。 すごい長いし細かいので他人に読ませるような記事ではなく、自分のために書いたメモです。 もし読むなら興味がある人だけで。 自分向けのメモですが、一応 この記事の前提や意図を書いておきます。 「DDDの値オブジェクト」以外を否定する記事ではありません。 原理主義のように書籍の理想どおり実践するべきだと主張するつもりはありません 「理想に従えばよい」「理想に従うの無意味だ」と決め付けの二項対立的な思考ではなく、理想と現実の絡み合ったグレーゾーンを見極めつつ、現場で手を打つのが優れた実践者ではないでしょうか 下記に紹介する、それぞれの値オブジェクトの優劣について細かく議論し、論破する・されることを目的としていません。 言い訳と
前回 は継続的にデプロイしてるよって話をしたので、その流れで今日からちょっと Git を使った開発フローに対するデプロイについて考えてみたいと思う。まず最初はやっぱり Git-flow からかな。と、その前に 前置き 自分は CircleCI だとどうなるかなぁとか考えながら書いてるけど、どの CI サービス・ツールを使っても大丈夫 自分の頭の中にあるのはウェブ系の自社サービス。スマホアプリとか組み込みとかは経験がないから分かんない どんな風にテストを実行するかみたいな話も面白いけど、今回は CI のことは忘れてデプロイだけ考える どのフローが良い・悪いという話ではない Git-flow ということで Git-flow 。この絵は有名ですね どこが始まりなんだろう?って思ったら2010年のこの記事みたい: https://nvie.com/posts/a-successful-git-br
みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。 先日 NTT グループのソフトウェアエンジニアを対象とした Git / GitHub の研修を NTT グループのエンジニア有志で行ったので、そのことについてお話しします。 ちなみに、以前に 社内のソースコードをGitHub Enterprise にとりまとめてる話 という記事も書いたことがありますので、興味があればそちらもご覧ください。 背景 本研修のきっかけは、ソフトウェアエンジニアの育成に関して NTT グループ内のエンジニアたちと議論が盛り上がったことです。 現在 NTT グループにはグループのエンジニア有志の集まる非公式なコミュニティがあります。私は不定期に Meetup を開催しているのですが、そこで「ソフトウェアエンジニア育成
数千万行に及ぶLinuxカーネルのコードのうち、どんなときにどこのコードを読めばいいか、そのときに何を手がかりにすればいいか、などについてお話します。 本記事は、TechFeed Experts Night#19 〜 達人に聞く、Linuxカーネルコードの歩き方のセッション書き起こし記事になります。 イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。 本セッションの登壇者 セッション動画 「カーネルコードの歩き方」というタイトルでお話しする武内覚と申します。ふだんはsatと呼ばれています。社会人1年目から15年ぐらいカーネルの開発とサポートをずっとやってきました。今も必要に応じてカーネルソースを見ています。 本LTで学べるのは「Linuxのカーネルソースの読み方についての勘所」です。直接読んでいくというより、もう少しメタな
世界最大のソフトウェア開発プラットフォームであるGitHubは2008年にリリースされ、2023年には開発者が1億人を突破するほどの規模に成長しました。そんなGitHubの共同創業者であるスコット・チャコン氏が、「一体なぜGitHubは成功したのか」について自ら解説しています。 Why GitHub Actually Won https://blog.gitbutler.com/why-github-actually-won/ チャコン氏によると、GitHubの共同創業者である4人はそれ以前に別のサービスを立ち上げた経験があり、製品としての品質もセンスも良かったものの、市場の環境やタイミングが合わなかったためそれほど成長できなかったとのこと。それなのにGitHubが成功した理由について、チャコン氏は「適切なタイミングで立ち上げたこと」「センスが良かったこと」の2つに要約できるとしています。
何年後かの自分へ こんにちは、のんピ(@non____97)です。 業務で使用する新しいMacが届きました。 新しいMacを初期セットアップするにあたって「今の設定どうだったっけ...」と調べる時間が結構かかってしまいました ということで何年後かの自分がまた新しいMacに乗り換える際に手間取らないように、設定した内容を書き記しておきます。 移行先のMacの情報は以下の通りです。M1 Max、嬉しい。 # OSのバージョンの確認 > sw_vers ProductName: macOS ProductVersion: 12.4 BuildVersion: 21F79 # カーネルのバージョン確認 > uname -r 21.5.0 # CPUのアーキテクチャの確認 > uname -m arm64 # CPUの詳細確認 > sysctl -a machdep.cpu machdep.cpu.
はじめに システム運用においては、なんらかのリソースを作成や削除したり、設定値を変更したりとさまざまな変更作業が発生します。その際、なんらかの手順書(Markdown や Excel 等)を準備して、作業をすることが一般的だと思います。 本記事では「変更手順の作成」と「その手順を実施する」という 2 点にフォーカスして、これらを支援する Visual Studio Code(以下、VS Code)の Extention をご紹介します。 なお、本 Extention は Azure でのみ使用可能な点にご注意ください。 補足: 手順書がどうあるべきかについては多くの意見があるため、この記事では触れません。 この辺りについては、運用設計ラボ様の素晴らしいスライドがあるので、末尾の参考資料にリンクしておきます。 Azure CLI Tools について 今回ご紹介するのは、Azure CLI
Hello! I’m slowly working on explaining git. One of my biggest problems is that after almost 15 years of using git, I’ve become very used to git’s idiosyncracies and it’s easy for me to forget what’s confusing about it. So I asked people on Mastodon: what git jargon do you find confusing? thinking of writing a blog post that explains some of git’s weirder terminology: “detached HEAD state”, “fast-
Hi fellow devs, For my first post, I'm just documenting my VSCode configurations here for posterity's sake or just for my reference later. Keep in mind that this list is going to be language agnostic and more so utility/aesthetic suggestions (though these are inevitably tied to what languages I work with, so take that as you will). Please feel free to suggest any good extensions that I've missed o
今や開発者にとって欠かせない存在といっても過言ではないのが「GitHub(ギットハブ)」。これは、世界中の人々がプログラムコードやデザインデータを保存・公開できるソースコード管理サービスのことです。 現在ではプロジェクトで使用することも増え、使えることが前提というものも多くなってきました。そこで今回は、GitHubとはどんなものか、インストールの方法から実際のコマンドの使い方までを解説していきます。 GitHubとは GitHubという言葉を分解すると、git(ギット)のhub(ハブ)。日本語で「拠点」の「集まり」と訳すことができます。 GitHub上で、エンジニア各々が公開用のプログラムをアップして自分以外のエンジニアに共有。その後、履歴を残しながら更新したり、自分以外のエンジニアも修正を加えることが可能です。 https://desktop.github.com/ そもそもgitとは
ソフトウェアのバージョン管理といえば、GitとGitHubを用いるのが主流。しかし、バージョン管理システムにはCVSやSubversion、Mercurial、GitLab、Bitbucketなど、「GitとGitHub」以外の選択肢も存在します。そんな「GitとGitHub」とは別の選択肢のひとつが、データベースのSQLiteと同じくD. Richard Hipp氏によって開発された「Fossil」です。 Fossil: Home https://www.fossil-scm.org/home/doc/trunk/www/index.wiki FossilはLinuxやmacOS、Windowsに対応しており、ソースコードから自分でバイナリをビルドすることも可能。今回はUbuntu 20.04上でFossilを利用してみます。 まずは下記コマンドを実行して、Fossilのバイナリを実行可
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
この記事は、「CMS Advent Calendar 2023」の21日目の記事で、WordPress に関してもしかするとあまり知られていないかもしれない事を、とりとめもなく独断でまとめたものです。 特に、ここ数年 WordPress に触れておらず、今の WordPress はどうなっているのか? という事を知りたい方向けの情報も少し盛り込んでいます。 クラシックエディターはいつまで使えますか ? Classic Editor プラグインの説明には、この記事を書いている時点で「Classic Editor は公式な WordPress プラグインであり、少なくとも2024年まで、または必要なくなるまでの間、完全にサポート・保守されます。」と記載されています。 それでは2025年以降、クラシックエディターが使えなくなる可能性があるのでしょうか ? 自分は、クラシックエディターは残り続ける
git add {ファイル名} でステージングするファイル単位で選べます。10ファイル変更しててそのうち3ファイルだけコミットしたい時とかに便利です。 git add -p でステージングする変更を行の塊単位で選べます。関係ないコメントを足しちゃったのとか、うっかりついでに変えてしまった変更をコミットから避けたり、別のコミットにしたい時とかに便利です。 間違いなく便利な機能ではあるんだけど、常用するものじゃないと思ってます。 なので git add -A を基本にする。 ……とか言いつつ git add . を常用している私。単にタイプ数と手の慣れ。ちなみにgitのaliasは使わない派です。これは違う環境でコマンド叩く機会が多かったりする都合です。 理由 を並べてみます。 コミット対象を選択するのがいちいちブロッキングなので時間がかかる 10ファイルの変更から3ファイル選択する時間は g
GitHub、自動でマージが実行される「Pull request auto-merge」機能を発表。GitHub Universe 2020 GitHubは、オンラインイベント「GitHub Universe 2020」において、自動的にマージを実行してくれる新機能「Pull request auto-merge」を発表しました。 Check out auto-merge! Now, when your branch protection rules are met, your changes approved, and your checks are green, GitHub can automatically merge your pull request for you. #GitHubUniverse #Keynote https://t.co/9gQRFt3aqQ pic.tw
iOSDC2021で14年前にObjective-Cで書かれた2tch(にたち)のコードがコンパイル,実行できるか?というチャレンジをアンカンファレンスとして発表しました.Zoomで開催し,最大100人が参加する事態となり,色々なことが話題になりました. 1.Subversionって知ってますか. 2._synthesizeってなんだよ. 3.あぁ・・・id型で全部よかったんだ・・・・・. 4.Trueじゃなくて,YESね 5.releaseとautorelease 6.ARC?なにそれ,型あんの? 7.Perlって知ってる? 全部,答えられたら,あなたも古参です.また,高校時代に2tchを使ってくれていた@freddiさん が登場し,感涙するなど・・・・.まさにAAなしでは語りきれない盛り上がりになりました(ってか高校時代・・・・・?14年前だと当時高校生でも今30歳だもんね・・・・・)
モンスターストライクの信頼性 を⽀えるSREの組織化について 株式会社ミクシィ XFLAG スタジオ ゲーム開発室 SREグループ 清⽔ 勲 Internet Week 2017 S15 ⾼信頼性運⽤を実現するSREという新潮流 2 ⾃⼰紹介 清⽔ 勲 / Isao SHIMIZU @isaoshimizu 株式会社ミクシィ XFLAG 事業本部 ゲーム開発室 SREグループ 所属 経歴 • SIerで受託開発、⾃社プロダクト開発、運⽤を約8年 • 株式会社ミクシィ • 2011.8〜 運⽤部 アプリ運⽤グループ所属、SNSの運⽤ • 2014.4〜 モンスターストライクの運⽤にジョイン • 2015.8〜 XFLAG スタジオが創設される • 2016.7〜 XFLAG スタジオにSRE グループ創設 3 ミクシィグループ 2017年11⽉8⽇ 2018年3⽉期 第2四半期 決算説明会資
https://github.com/motemen/ghq/releases/tag/v1.0.0 年末にアナウンスしていた通り、先程ghq v1.0.0をリリースしました。変更点は以下のエントリでお知らせしていたとおりです。その他Subversion周りの対応を無駄に頑張って強化したりしました。 https://songmu.jp/riji/entry/2019-12-28-ghq.html 是非ご利用ください。 年末年始休暇中にドキュメントを書いていたのですが、思ったよりもしっかりとした分量になったので、思い立って電子書籍にして販売してみることにしました。 https://leanpub.com/ghq-handbook 日本語で20ページほどです。値段は$1.99くらいにしたかったのですが、Leanpubで収益を上げる場合には$4.99が下限のようなので、その額に設定させてもらいま
tl;dr; 検証内容 サンプルコード masterブランチに普通にpushした時 PullRequestに対してpushした場合 pushイベントの結果 pull_requestイベントの結果 解説 2021/01/08 追記 GITHUB_SHAが異なることで何が困るか 余談:tfnotifyでpull_requestイベントの時にもPullRequestにコメントをつけたい FAQ Q. だったらpull_requestは不要では? 今の心境 tl;dr; タイトルが全て 検証内容 サンプルコード GitHub Actionsで使える(事前定義済みの)環境変数 *1を列挙するだけのシンプルなワークフローです on: - push - pull_request jobs: show_env: runs-on: ubuntu-latest steps: - run: env | grep
この記事は「本番環境でやらかしちゃった人 Advent Calendar 2020」の12日目です。参加できて嬉しいです。 https://qiita.com/advent-calendar/2020/yarakashi-production ※この話はフィクションです。また、派手な内容ではありません。 AM8:35 私は某ソフトウェア開発会社でシステムのヘルプデスクを担当している。いつも通りに出勤し、パソコンを立ち上げ、問い合わせメールがないかチェックする。 正確には「開発以外担当」である。体制図にも文字通りそう書いてある。開発担当が「開発の要件が決まってから商用リリースまで」を、開発以外担当が「それ以外」をやる。ユーザニーズをまとめて開発内容を整理するのも「以外担当」であるし、開発担当が作ったバグも、リリース後ならお客様対応含め「以外担当」がやる。あなた方に瑕疵担保責任という概念はない
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く