Miro時差や場所に関係なく、いつでも、どこでも オンラインホワイトボードでのコラボレーションを実現しましょう。
How to run a big(ger) project as a SWE / Manager
Similar to How to run a big(ger) project as a SWE / Manager(20)
リスペクトがない人はOSSから排除するしかない
Question regarding writeboost and MYSQL · Issue #146 · akiradeveloper/dm-writeboost · GitHub 最近ライトブーストを試し始めたユーザだが、他人に対するリスペクトがないため「お前の質問には一切答えない」と言って打ち切った。出来るだけそういうことはしたくなかったため、過去に同様のことをした時は忠告する程度に止めていたが、再発したため追放することとした。(Issue 141でも同様に、foolなど罵る言葉を使っていたため忠告した) OSSでは、会ったこともなく、それこそ本名も知らない人がコミュニケーションをとることになる。言語は英語だが、お互いにネイティブである方が稀である。そこで大事なのは、他人をリスペクトする気持ちだ。まじでリスペクトする必要はない。本当にリスペクト出来ないなら去ればいいだけだし、リスペ
チーム開発で暗黙的に行なわれている批評というプロセス - snoozer05's blog
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査（査読）を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
Latest topics > もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - outsider reflex
Latest topics > もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « Firefox for Android用のアドオンを作った Main Firefox for Androidに仮想的なスクロールバーを導入するScrollbar Like Scrollerを更新した » もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - Nov 10, 2013 人格攻撃をしたくて書いてるわけじゃないですよ、という事はまず最初に表明しておきます。 GitHubで公開してるプロジェクトについて、幸いなことに時々プルリクエストをもらえる事があるんだけれども、そ
アメリカ人開発者が日本の開発者に怒ってた。
食事する機会があって、話してたら日本へ愚痴がおおくて苦笑いした たしかになぁと思う部分をここに書く 日本のWEBは残念につながる話なのかも知れない 要約すると 日本の開発者は、とにかく私的で内輪ネタを好む。そして後先を考えない。 というお話なんだけど この前TOMOYOLinuxがカーネルマージされたことをその人も知ってたんだけど 元ネタはカードキャプチャーさくらっていうアニメだと知って苦笑いしてた。 幼稚だなって言ってた。個人ならともかく企業がやる事じゃないと。 そのひとが来日したのは、もともとはSFC時代のゲーム開発のためなんだけど 日本の開発で一番困ったのは、その場のことしか考えない開発体制と方針だそうだ とくに怒ってたのは、RPGでキャラクター名を入れる画面があるんだが 欧米の人からすれば、６文字以上の名前もあたりまえのようにあるから、そうしてくれればいいのに 日本の開発者達は当た
要求仕様書について
「要求仕様書」の必要性は、多くの人が認めているにも関わらず、実際には殆ど書かれていません。仕様を意識していることは、プログラムのバグの原因分析において、「仕様モレ」や「仕様の勘違い」といった項目で集計されることからも分かります。でもそこまでです。 開発組織によっては、それに代わるものとして「機能仕様書」と呼ばれるものが書かれていることがありますが、その場合、内容は当然のことに「機能」に限定されます。残念ながら「機能」だけでは要求を満たすのに十分ではありません。「品質」も製品を構成する重要な要素です。また、機能仕様がどうやって抽出されたかが問題です。 多くの開発現場で遭遇する混乱のおおもとは、殆どが「要求仕様書」の不備に起因しているのです。一体、「要求仕様書」にはどんな役割があって、どのようなところに注意して書けばよいのか。 また、よく分からないものとして「要求」と「要求仕様」の違いにつ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「OpenSSH 8.4」リリース
