How I/we got 2k stars - ゆーすけべー日記
Honoという僕が作っているWebフレームワークのGitHubスター数が2,000に迫ってきた。これまで作ってきたOSSのソフトウェアでは最高で revealgo の221、次点で gh-markdown-preview の134だ。それが一気に2,000である。 もちろん、スターの数がソフトウェアの良し悪しを決めるものではない。 それに2,000はとりわけ多いわけではない。 でも、以前の自分には遥か彼方に見えていた数を獲得できたのは、とても嬉しいことだ。 去年12月から作り始めて9ヶ月間、552コミット。 今や使ってくれる人も増えた。 cdnjs のAPI Serverのバックエンドにも使われているし、 HonoをきっかけにGitHubスポンサーをしてくれている企業や人も現れている。 なにより、いろんなことを勉強させてもらった。 今回はHonoというプロダクトがどうやって2,000のスタ
「いつかGitHubで働きたい」10年来の空想を現実にしたソフトウェアエンジニアの紆余曲折な人生 - Findy Engineer Lab
長永健介（@kyanny）と申します。現在はGitHubで働いています。10年前、「いつかここで働きたい」と夢見た会社です。 私は子供の頃から「考えること」が好きでした。難しいこともくだらないことも、真面目に考えて自分なりの意見をまとめる癖がありました。成長するにつれて私の思考様式は洗練され、Webとブログに出会ったことで「書く」という手段に昇華されました。書くことで考えていることを言語化し、言語化した自分の考えを読みながらさらに考えを深める ── この活動を繰り返すことで、起こりうる問題に備えたり、問題を多角的に見つめて活路を見出してきました。 とりわけキャリアの選択において「(思考|志向)を言語化する」習慣が大いに役立ちました。この記事では私のキャリアにおけるいくつかの選択と、その時々で考えていたことについて紹介します。 望んでなかった「けものみち」を変えた日記の言葉 Shut the
「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など
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の原体験 業務
ヤフー株式会社を退職したのでついでに自分の半生を振り返ってみる｜magurotuna
男もすなる退職エントリといふものを我もしてみむとしてするなり。 2020 年 10 月にヤフー株式会社を退職しました。退職に至るまでのあれこれと、今後のキャリアについて漠然と考えていることをまとめたいと思います。 学生時代 小・中・高は普通の公立に通い、1 年浪人して東大に入りました。 涼宮ハルヒの憂鬱からオタクになり、ニコニコ動画全盛期を経て引きこもり属性マシマシと化して、パソコンとゲームばかりしている中学・高校時代を過ごしました。 このオタク属性は大学に入って「声優おっかけ」に昇華し、声優イベントのためであれば日本国内はもちろんのこと、0 泊 2 日で台湾に弾丸で行くこともいとわないような生活を送っていました。 最終的に、大学の学園祭に声優さんを招いて自分でトークイベントを主催するというところまで行き着き、いろいろな意味で充実した学生生活を送ることができました。 電子情報工学科へ 勉強
PEP 8騒動について - methaneのブログ
今週PEP 8の小さい変更についてMLで騒動が起こってしまいました。 該当のコミットはこれです。 PEP 8: Change requirement to adhere to Standard English (#1470) · python/peps@0c6427d · GitHub 変更点はごくごくシンプルなものです。 - When writing English, follow Strunk and White. + Ensure that your comments are clear and easily understandable to other + speakers of the language you are writing in. 今まで知らなかったのですが、変更前の "Strunk and White" とは The Elements of Style というすご
アメリカで、ソフトウェアエンジニアの日本人がインパクトのある仕事をする方法 - メソッド屋のブログ
アメリカに移住してもうすぐ４ヶ月ぐらいになるけど、こちらに来てから面白いほど成果が出ていない。 最初の２ヵ月ぐらいはなんやかんやで仕事にならんやろうなと思っていたから、気にもしなかったが、そろそろ４ヵ月なので、流石に焦りを感じて来た。何一つ仕事が完了しない。日本で仕事をしていた時はこんなことは発生しなかった。こっちの方が一緒に働いている人が同じタイムゾーンだし、近いし、やりやすいはずなのに何故だろう？焦っていても何も改善しないので、直接仕事をしているクリスと、日本人エンジニアの先輩の河野さんに話を聞いてみた。自分の会社限定かもしれないけど、学んだことの記録と、もしかすると誰かの役にたつかもしれないから書いておこうと思う。 仕事が完了しない焦り 何だろう、この仕事の完了しないっぷりは。いくつか、終えたらインパクトがある仕事があるのだが、これがまた完了しない。一緒に働いているエンジニアの人はみ
✓DO、X DO NOT の誤訳事案
だいぶ炎上してる例のあれ doの意味が全体的に逆になっています。 #118 対応ミスってるとはいえさすがにかわいそうなレベルでいいがかり付けられてる感じもするのでちょっと補足を。 元々の問題 マイクロソフトの機械翻訳がよくやらかすのはいつものことなんですが。 今回は何をやらかしたかというと、よくある ✓DO: 〇〇してください X DO NOT: 〇〇はしないでください みたいなやつを、DOもDO NOTもどっちも「しないで」と訳してしまっているという問題。 「しないで」も不自然だし、ましてDOの方は真逆の意味になっているという誤訳。 どうしてこうなる… みたいな気持ちはもちろんあるものの、こういう「普通の文章」になっていない部分の単語ってのは、機械翻訳では一番ミスを起こしがちな部分です。 たぶん、原文の時点で何らかのアノテーションでも付けておくとかしないと、今後も同様の誤訳は起こりまくる
GitHubリポジトリで8000スター獲得、人気OSS「Boostnote」オープンソース化の軌跡 - エンジニアHub｜Webエンジニアのキャリアを考える！
GitHubリポジトリで8000スター獲得、人気OSS「Boostnote」オープンソース化の軌跡 GitHubリポジトリで8000スターを獲得しているプログラマ向けノートアプリのBoostnote。グローバルな開発コミュニティを築き上げた経緯についてインタビューしました。 Boostnoteというアプリをご存知でしょうか？ こちらはElectronで作成されたデベロッパー向けのノートアプリ。実は海外ではとあることでとても有名なアプリなのです。 なんと企業が事業として開発しているアプリにもかかわらず、コードをすべてオープンソースとしてGitHub上に公開しているのです。海外を中心に注目度は高く、世界中のコントリビューターがBoostnoteに携わっています。現在、GitHubのスター数が8000を超える人気のOSSとなっています。 Boostnoteはどのようにグローバル展開とし、どのよう
英語メディアはgithubをどう紹介したか
マイクロソフトによるgithubを報じた日経新聞の記事のタイトルにおいて、githubのことを設計図共有サイトとよんでいて、開発者のみなさん総ツッコミ状態のようですね（現在は開発者向け共有サイトとなっている）。 個人的な感想としては、ソースコードを設計とみなすアナロジーはあって誤りであるとはいいがたいし読者層を念頭におけば気持ちはわかるものの、設計図共有サイトねぇ……という気持ちはないでもない。まあしかし、それ以上とくになにもいうことはない。 ただこれに対応して気になるのは、英語メディアではどのように紹介されてたのか、ってことだ。天下のマイクロソフトが$7.5Bもの額でユニコーン企業を買収となれば、一般紙でも紹介されるだろう。どんなふうに紹介してたんだろうか。 適当にgoogle newsで引っかかったテックメディアでない系の記事を眺めてみた。 Forbes。https://www.for
オープンソースの開発現場では限られたリソースで品質管理をどうしているのか。Twitter4J、GitBucket、Asakusa Framework、power-assertの作者が討論（前編）
和田氏 このセッションは、OSSにおける品質管理やテストなどをどう考え、運営しているのか、という内容でパネルディスカッションをさせていただきます。まずは登壇者がどんな方か、自己紹介してもらおうと思います。 竹添氏 ビズリーチの竹添と申します。転職サービスの会社なのですが、今日は個人で「GitBucket」という、GitHubのような機能を提供するWebアプリケーションを作っているので、その立場で参加させていただきます。 もともと僕はSIerにいて、そのときはGitHubのような外部のサービスを使えなくて、それで社内でもGitHubのようなサービスが使えたらいいなと思ってGitBucketをはじめました。 なのでGitBucketはGitHubを参考に開発を始めたのですが、同じようなニーズを持ったお客さんが国内にも、海外にも多くいるので開発を続けています。 川口氏 ノーチラス・テクノロジーズ
非英語ネイティブにとってのOSSのメンテナンスコスト - once upon a time,
disclaimer: この記事を書いている人はClouderaというHadoop/Sparkのディストリビューターの会社にいます。 codelunch.fmの20回目を聞いていろいろ思うところがあったのでつらつら買いてみます。 codelunch.fm この回のcodelunch.fmでは、前職の同僚である丸山さん（@h13i32maru）と@hokacchaさんが、お互いの家庭環境の変化を交えながら個人プロダクトの開発について話しているエピソードです。これ自体なかなかおもしろい回なので、趣味でプロダクト開発している人は聞いてみるといいんじゃないかなと思います。 丸山さんはJasperやESDocを精力的に開発していますし、hokacchaさんはnodebrewやadventarを作られています。彼らの話していた、個人で趣味プロダクトを開発するモチベーションは何かというところは、以下のよ
オープンソースプロジェクトを最初から英語で運営してみてわかったメリットについて｜Rui Ueyama
僕は最近とあるオープンソースプロジェクトをオーナーとしていわば運営しているのですが、英語でプロジェクトをまわすというのは良いなと思うようになりました。他の言語を使うのに何も悪いことはないのですが、英語のほうがコミュニティがずっと大きいので想定外の幸運なことが起こる可能性が高くなるというのが理由です。 僕がやっているプロジェクトは開発ツールを作るというもので、それなりに専門的な知識が必要になるプロジェクトです。人間が書いたプログラムのコードは最終的に何らかの形でコンピュータが直接実行可能な形に変換されて実行されるわけですが、僕が作っているリンカというのは最後の実行ファイルを作成する部分を担当するプログラムです。つまり僕はプログラムを出力するプログラムを書いているわけで、そのためにはOSやCPU、入力や出力のファイルの形式などについてよく知っている必要があります。 また僕らの目標は既存のものよ
Github issue で質問してはいけない - Qiita
この記事は個人ブログで海外向けに書きかけの記事の日本語版です。そのため、一部日本人向けではない記述が含まれます。 英語版はこちらです Why you must not ask questions on Github issues 現在は GitHub は Discussions を提供しています。 Issue Template から Discussion へと誘導するのがおすすめです。 2023-06-14 追記 TL;DR: Issue Tracker で質問するのは開発者に対する DoS 攻撃になるかもしれない。 Forum がある場合は Issue Tracker で質問してはいけない。 背景 Github の時代になる前は、ある程度の規模のOSSプロジェクトはみんな Issue Tracker と別に フォーラム (BBS, ML など) を持っていました。ユーザーはフォーラムでデ
gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
GitHubで使われている実用英語コメント集 - Qiita
この記事はリクルートライフスタイル Advent Calendar 2015 - Qiita の17日目です。 こんにちは。現在、ホットペッパーグルメのエンジニアをやっている敷地@shikicheeです。 gitで英語のコミットメッセージどう書けばいいの？ と思ったことはありませんか？ 英語で書きたいなーって思っても、いざ書くとなると躊躇しますよね。 ネイティブはどう書いてるのでしょうか。 そこで、github上で実際に使われているコメントを解析し、 よく使われている例をまとめてみました。 解析したデータ github上で1万スター以上を獲得している169リポジトリのコミットメッセージを対象としました。 bootstrap、jquery、react、d3、docker、node、tensorflowなどの有名なプロジェクトばかりなので、良いコメントが期待できます。 解析するコミットメッセー
OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ
YAPC::Asia Tokyo 2015 前夜祭に参加して、柴田さん（ hsbt さん）とモリスさん*1（ tagomoris さん）の講演を聴いた。特に最後のモリスさんの講演を聴いていて、ちょっとした衝撃を受けると共に、気づきや疑問もあったので、久しぶりに blog エントリを書こうという気になった。 なお、このエントリは講演メモや浮かんだ疑問、その後の議論等を記したものであり、すっきりとした結論は無いのでご注意。 モリスさんの講演 講演資料が公開されていた How to create/improve OSS products and its community from SATOSHI TAGOMORI 講演時に取ったメモがこちら 我々にできるOSSとそのコミュニティの育てかた ======================= id:tagomoris TD のモリスさん TD はデー
「GitHubは開発者やデザイナーだけのものではない」日本法人GMが、よりハッピーな仕事環境構築へ意気込みを語る
ジェネラル・マネージャー堀江氏のGitHubとの出会い 堀江大輔氏（以下、堀江）：こんにちは。今日の内容を全部ど忘れするかと思って書いてきたので、ちょっとたどたどしいかもしれないんですけど、許してください（笑）。 この度ギットハブ・ジャパンのジェネラル・マネージャーの就任した堀江大輔と申します。クリスからGitHubの歴史とビジョンについて説明がありましたが、私からはギットハブ・ジャパンの活動について紹介したいと思います。 まず自己紹介から始めます。私は2000年頃からインターネットの業界に参加してキャリアを積んできまして、新規事業の立ち上げやプロジェクトマネージメント、マーケティングや事業開発などの仕事をしてきました。 いろんな職種を経験している中で、ずっとやりたいと思ったけれど、なかなかできない、頑張っても身につかないないことがあったんです。 それは、ずっとソフトウェアのコードを書けな
唐突な Diff に負ける - @kyanny's blog
目的はわかったけどどうしてこの変更で達成できるの？がわからない、文脈が抜け落ちている Diff というのがある。唐突な Diff、と呼ぼう。 唐突な Diff との戦いには二種類ある。 一つは自分が唐突な Diff を作らない、という戦いで、ちょっと込み入ったバグ修正など、変更する箇所は少ないがそのぶん意図がわかりづらくなる場合。自分はバグの原因を解明する過程で関連するコードを読み込んでいるので「流れ」を把握できているが、レビュアーが Diff そのものから全体像を思い描くのは難しい。リグレッションテストを追加してもやはり文脈なしでは説明不足だ。そういうときはコメントを丁寧に書き、場合によっては関連コードのリンクを添えつつステップを順に説明したりする。これにはそれなりに手間と時間がかかる。 もう一つは唐突な Diff に出会ったときちゃんと質問する、という戦いで、「なんだこれは？」と言いた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rebuild: 231: Eternal Updates (atsushieno)