羽生先生の発言は何が開発者の反発を招いたのか？ | やねうら王 公式サイト
2つ前の投稿で羽生先生のインタビュー記事の発言を取り上げたらプチ炎上しました。私は特に炎上を狙ってやっているわけではなく、羽生先生の発言が将棋AI界隈に悪い影響が残り兼ねないので書いたのですが、開発関係者からは一定の同意が得られたものの、将棋ファンからは殺害予告やら、こんなツイートやらが届く始末です。 まあ、一線を越えているものに関しては関係各所と連携しつつ、粛々と対応させていただく次第です。(念のために言っておきますと、将棋ファンのすべてがこういう人たちばかりだとは私は思っていません。極一部にちょっとややこしい人がいらっしゃるという認識です。) この記事は大変長くなるので、「最新版のやねうら王が(お金を出してでも)欲しい！」と言う方や、「やねうら王の開発に支援してやる！」と言う方は、とりあえず、この記事の末尾のリンクから御支援くださいませ。 今回は、前回の羽生先生の発言を再度取り上げ、何
サンタ逃亡のお知らせ | やねうら王 公式サイト
毎年、やねうら王プロジェクトでは、クリスマスシーズンになると何かしらのプレゼントを行ってきました。詰将棋問題集100万問であったり、やねうら王のメジャーバージョンのリリースであったり、教師用データセットの公開であったり。今年は、最新版であるやねうら王V8.00をクリスマスに公開しようと準備を粛々と進めてきました。 そんななか、とても心を抉られる記事を目にしました。羽生先生のインタビュー記事です。 将棋をこよなく愛する開発者のみなさんは、将棋ソフトの開発で稼ごうと思っている人たちが少ないのです。 そのため、開発したプログラムを自分のスキルを披露する場として捉えて公開し、私たちが将棋AIを使うためのアプリも無償で公開してくれています。 <a href="https://www.kumon.ne.jp/kumonnow/obog/100_1/" target="_blank" rel="noop
なぜ我々は筑波大を便利にすることができなかったのか？ - いなにわうどん
早いもので筑波に来て 3 度目の春を迎えます。2 年前の春を憶えていますか。 筑波大学を便利にするサークルが爆誕 元々は大学の KdB と呼ばれる開設科目データベースがダウンし、その代替サイト「KdB もどき」を作成したことに端を発します*1。懐かしいですね。 ミラーを立ち上げただけと言えばそうなのですが、新入生が大学をディスりながらシステム開発！みたいな構図が予想以上にウケたっぽく、Twitter がバズったりメディアに取り上げられたりしている間にサークルを新設する流れになりました*2。 togetter.com 筑波大には学生が開発した数多のサービスやアプリケーションが存在しますが、その多くは個人レベルで開発が行われているため、開発者が大学を離籍するとシステムが保守されなくなる傾向にあります*3。そこで、筑波大学の学生生活を便利にする各種サービスを総括的に管理・保守することで持続可能な
中国版ギットハブ、コードを検閲・遮断か？ OSS開発者に衝撃
中国におけるギットハブの競合サービスとして人気の「ギッティ（Gitee）」で公開されていたソースコードが一部非公開となり、中国のオープンソース・コミュニティに衝撃を与えている。理由は明らかではないが、中国政府による検閲が疑われており、イノベーションを阻害する恐れが指摘されている。 by Zeyi Yang2022.06.01 171 2 5月18日の朝のことだ。中国の数千人ものソフトウェア開発者たちは、中国企業「ギッティ（Gitee）」にホストされているオープンソース・コードがロックされ、非公開になっていたことに気づいた。ギッティは、国際的なコード・リポジトリ・プラットフォームであるギットハブ（GitHub）の競合サービスで、中国政府の支援を受けている。 ギッティはその日の遅くに声明を発表し、ロックされたコードは手作業でレビューされており、今後はすべてのオープンソース・コードが公開前にレビ
インフィニットループは PHP の継続的な発展を目指す The PHP Foundation に寄付をしました｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
生産性・技術的負債をMetabaseで可視化した話 - LIFULL Creators Blog
技術開発部の清水です。好きな食べ物は広島風お好み焼きと広島県産牡蠣と広島県産穴子です。 拡張に次ぐ拡張でサービスは便利なものに成長していく一方でソースコードは次第に複雑になっていきます。 そのまま放っておくと積み上げた技術的負債により開発コストが上がっていき、最悪の場合にはサービスの発展を停止させてしまう可能性もあります。 このような理由から、弊社では技術的負債を着実に返済していくべく生産性・技術的負債の可視化をMetabaseで行っています。 可視化する情報元はGithub API、CodeClimateQuality APIの2つのみです。 生産性の可視化 本流ブランチにマージされたPR数（生産数） 本流ブランチにマージされたPRによる意味のある変更行数（生産規模） 本流ブランチにマージされたPRの平均レビュー応答数（生産を助けた人員の労力） 本流ブランチにマージされた「1コミッターあ
ARCHITECTURE.md
ARCHITECTURE.md Feb 6, 2021 If you maintain an open-source project in the range of 10k-200k lines of code, I strongly encourage you to add an ARCHITECTURE document next to README and CONTRIBUTING. Before going into the details of why and how, I want to emphasize that this is not another “docs are good, write more docs” advice. I am pretty sloppy about documentation, and, e.g., I often use just “si
OSS活動を細く長く続ける技術
Profile id: Songmu (ソンムー) Masayuki Matsuki / 松木雅幸 Nature 株式会社 取締役CTO おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU 好きな言語は、PerlとGoと中国語 3 Times ISUCON Winner Using Perl 入門監視 付録C 執筆 「みんなのGo言語」共著者 【宣伝】Nature Remo 赤外線リモコン代替となるIoTスマートリモコン https://nature.global エンジニアも絶賛募集中です 同時接続20万台を超えるIoTサービスの裏側を一緒に開発しませんか！ https://nature.global/jp/careers アジェンダ 最近のOSS活動 私とOSS OSSの原体験 業務
個人開発者とCovid-19 Radarプロジェクト - laiso
Endless road | During our roadtrip we turned off the highway… https://www.flickr.com/photos/98063470@N00/326044514 GitHubリポジトリ Covid19Radar に対して起ったことがかなり特殊な状況だったため、開発を追い掛けていた視線からレポートをします。 この記事の著者について 代表作のない個人アプリ開発者(かなしい) Covid-19 Radar Japan の人ではない GAFAMやCode for Japan の人でもない 4/8 Covid-19 Radarを発見する Covid-19 Radarとは、この時点ではシンガポールのTraceTogetherの日本版を目指した個人開発者 廣瀬一海さんのアプリのリポジトリ 4月にContact Tracing技術について
東京都の新型コロナ対策サイト“爆速開発”の舞台裏 オープンソース化に踏み切った特別広報チームの正体
東京都が公開した「新型コロナウイルス感染症対策サイト」が、都としては異例のオープンソースなWebサイトとして話題になっている。このサイトは、元ヤフー社長の宮坂学副知事率いる「特別広報チーム」が、発足からたった1週間で公開した“爆速開発サイト”だった。 新型コロナウイルス感染症対策サイトでは、都内の新型コロナウイルス感染者数やコールセンターへの相談件数などをグラフや表として掲載し、視覚的に分かりやすくまとめている。 異例なのは、サイトのソースコードをGitHubで公開している点だ。一般の人々でもサイトの構造を確認できるうえ、コードの改善提案（プルリクエスト）を出したり、他の自治体がコードをコピーしてそれぞれの対策サイトを作ったりできる。これまでは、東京都のサイトやサービスでソースコードが公開されることはなかった。 8日ごろには、台湾のデジタル担当政務委員（デジタル大臣）であるオードリー・タン
アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法 - メソッド屋のブログ
アメリカに移住してもうすぐ４ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。 最初の２ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ４ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日本で仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう？焦っていても何も改善しないので、直接仕事をしているクリスと、日本人エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。 仕事が完了しない焦り 何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみ
オープンソースの開発現場では限られたリソースで品質管理をどうしているのか。Twitter4J、GitBucket、Asakusa Framework、power-assertの作者が討論（前編）
和田氏 このセッションは、OSSにおける品質管理やテストなどをどう考え、運営しているのか、という内容でパネルディスカッションをさせていただきます。まずは登壇者がどんな方か、自己紹介してもらおうと思います。 竹添氏 ビズリーチの竹添と申します。転職サービスの会社なのですが、今日は個人で「GitBucket」という、GitHubのような機能を提供するWebアプリケーションを作っているので、その立場で参加させていただきます。 もともと僕はSIerにいて、そのときはGitHubのような外部のサービスを使えなくて、それで社内でもGitHubのようなサービスが使えたらいいなと思ってGitBucketをはじめました。 なのでGitBucketはGitHubを参考に開発を始めたのですが、同じようなニーズを持ったお客さんが国内にも、海外にも多くいるので開発を続けています。 川口氏 ノーチラス・テクノロジーズ
[core-workflow] We will be moving to GitHub
Brett Cannon brett at python.org Fri Jan 1 14:21:05 EST 2016 Previous message (by thread): [core-workflow] Longer term idea: consider Rust's homu for CPython merge gating Next message (by thread): [core-workflow] We will be moving to GitHub Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] I don't think this will be a shock to anyone who has followed the discussion on this list. The d
SVNを捨ててGitを使うべき5つの理由 - Qiita
まえがき 私はGit好きの人間です。 もっと言えば、Gitを愛している（Git Lover）と言ってもいいくらいです。 そんな私がなぜこんなタイトルの記事をいまさら書こうと思ったかというと、 いまだにGitの便利さを知らず、Subversionを強い理由もなく使い続ける開発者が多いからです。 そんなわけで 「会社にGit/GitHubを導入するための説得する」 という目的でこの記事を書こうと思います。 Gitの良さってなんだろう？ 実は私もこれまで強く意識して考えたことはありませんでした。 Gitを使い出したら、 それがあるのが当たり前でGitなしの開発など考えられなくなっていたからです。 そういう意味では、Gitって 中世における自動車 に近いものがあるのかもしれません。 その時代、移動手段といえば馬が普通であり、 自動車などが普及するとは誰も考えなかったわけです（たぶん）。 それが今で
デザイナーがXcodeを使って 開発効率をUPさせた 5つのエピソード + 現場エンジニアのコメント付き
非エンジニアリング脳なデザイナーが新規アプリ開発の現場でXcodeを使用することがどのような影響を与えたか。について、自身の経験を元にまとめました。Read less
人気オープンソースプロジェクトは何人欠員が出たら破綻するのか | スラド オープンソース
ストーリー by hylom 2015年07月15日 16時20分 個人の活躍が大きいプロジェクト、という指標 部門より Marco Tulio Valentemtov氏は、GitHub上にある人気の高い133本のオープンソースプロジェクトにおけるトラック係数（Truck-Factor）を調査したそうだ（Marco Tulio Valentemtov、Slashdot）。 トラック係数は不意の事故などによってメンバーに何人欠員が出るとプロジェクトが破たんするかを表す係数で、バス係数とも呼ばれる。プロジェクトの進行で理想的なのは、メンバーが欠けても被害が最小になるように均等に負担することだ。しかし、多くのプロジェクトは一人の実力者に支えられていることが多い。 先のMarco Tulio Valentemtov氏の調査によると、6種類の言語系プロジェクトにおけるトラック係数はJavaScrip
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームでプロダクト開発するための取り組み/cookpadtechconf2017
Cookpad iOS Release Flow
