コツコツと開発を続けてきた、テキストエディター向けの色テーマ「Iceberg」。開発6年目にして、とうとうGitHubのスター数が1,000を越えました！めでたい🎉🎉🎉
自作カラースキームがGitHubで1,000スターを越えるまでの6年間の軌跡 - ここぽんのーと
コツコツと開発を続けてきた、テキストエディター向けの色テーマ「Iceberg」。開発6年目にして、とうとうGitHubのスター数が1,000を越えました！めでたい🎉🎉🎉
祝Jenkins15周年、「Developer Productivity Engineering」に貢献してきたことを誇りに思うと川口氏。DevOps World / Jenkins World 2019 Sanfrancisco
祝Jenkins15周年、「Developer Productivity Engineering」に貢献してきたことを誇りに思うと川口氏。DevOps World / Jenkins World 2019 Sanfrancisco 8月12日から15日にかけて、サンフランシスコのモスコーニセンターで「DevOps World / Jenkins World 2019 Sanfrancisco」が開催されました。 今年はJenkinsの15周年にあたります。基調講演にはJenkins開発者である川口耕介が登壇。Jenkins開発当時のことを振り返りつつ、会場の参加者とともに15周年を祝いました。 本記事では、その内容をダイジェストで紹介します（講演は英語で行われており、本記事ではその内容の一部を翻訳して紹介しています）。 Jenkinsの開発当初を振り返る Jenkinsの開発者 川口耕介氏
deoplete.nvim開発者、Shougoが考える「Viｍの限界ギリギリ」を攻めるプラグイン開発の裏側 - エンジニアHub｜Webエンジニアのキャリアを考える！
deoplete.nvim開発者、Shougoが考える「Viｍの限界ギリギリ」を攻めるプラグイン開発の裏側 多くのエンジニアに愛されるテキストエディタ『Vim』のプラグインを作り続けるShougoさん。Vimmerならば一度は使ったことがある、というほどに広く知られたプラグインを作り続ける理由を聞きました。 「あなたにとって、テキストエディタとは何ですか？」 こう聞かれたとき、あなたは何と答えるでしょうか。開発に不可欠な大事なツール、あるいは、ただの道具──。きっと十人十色の回答が返ってくるでしょう。 この問いに対し、「テキストエディタとは世界」と迷いなく答えるエンジニアがいます。Vim/Neovimのプラグインマネージャーdein.vimや、Neovim/Vim8用の入力補完プラグインdeoplete.nvimなどの開発者であるShougo（しょうご／ @ShougoMatsu ）さんで
直面する問題を解決したらkaminariができた。Ruby / Railsコミッター松田明のOSS開発の実像 - エンジニアHub｜Webエンジニアのキャリアを考える！
直面する問題を解決したらkaminariができた。Ruby / Railsコミッター松田明のOSS開発の実像 世界中のRubyプログラマに使用されるOSSであるkaminari。これを手がけたRuby / Railsコミッター松田明さんに、開発背景を聞きました。 「これがあったら便利なはずだ」という予測。 あるいは、「これが問題だから、解決する」という現状認識。 新たな技術が生み出される源流にあるものとは、一体なんでしょうか。 Ruby on Rails（以下、Rails）を用いたWebアプリケーション開発において、圧倒的な存在感を放つページネータであるkaminariを開発した松田明（まつだ・あきら／ @a_matsuda ）さんの場合は、“絶対に”後者であると語ります。 Rails、そしてRubyのコミッターでもある松田さんは、まさにRubyを用いた開発の最中、先行するソフトウェアに感
Rebuild: 161: Angry Jenkins Angers Me (kohsuke)
Kohsuke Kawaguchi さんをゲストに迎えて、Jenkins, Sun, オープンソース、旅行などについて話しました。 Show Notes Hudson (software) CVS - Open Source Version Control Jenkins EU Issues Objections to Sun-Oracle Deal Hudson devs vote for name change; Oracle declares fork CloudBees List of fictional butlers - Wikipedia Logo - Jenkins Rebuild: 152: The True Jenkins Master (naoya) Pipeline Blue Ocean The Groovy programming language Jenkins
続: OSSプロダクトとコミュニティの話 - たごもりすメモ
先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。 t-wada.hatenablog.jp t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。 明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。 なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく
Rebuild: 106: Forced Annual Update (typester)
Daisuke Murase さんをゲストに迎えて、オープンソース、Go, Swift, iPhone, Apple TV などについて話しました。 スポンサー: Flinto for Mac Show Notes Rebuild: Aftershow 105: C, Lisp, and a Bit of Ruby (Matz, Naoya Ito) Rebuild Meetup 2015 実況まとめ #rebuildfm 我々にできるOSSとそのコミュニティの育てかた / tagomoris OSS開発の活発さの維持と良いソフトウェア設計の間には緊張関係があるのだろうか? - t-wadaのブログ Ansible Galaxy | Find, reuse, and share the best Ansible content Go 1.5's vendor/ experiment Par
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 はデー
(rust report) 1.0に向けてコミュニティの努力 - テストステ論
私が半年以上前にRustを書いていた時, そこはまるで粗野だった. 簡単なチュートリアルがあるのみで, それを読んだらいきなり実践, IRCに張り付き, API docを読むしかないという感じだった. C++を学生時代に少しかじっていたので, 所有権に関する理解はいくぶん楽だったが, coreutilsの簡単なコマンドを作るくらいでも, 苦労したものである. そして嫌になって引退した. その時の引退理由は「言語は良いと思うがあまりに粗野すぎてコスパが悪い. 一旦OCamlに移動する」であった. 私はNimを引退し, 確信を持ってRustに戻ってきたわけだが, その理由は1.0に向けて着地直前であることが大きい. 当時は, 数日すぎればコンパイルが通らないなんてことはザラで, その度にうんざりしたものだ. コンパイルが通らないならば直せばいいじゃないかと思うかも知れないが, 事はそう簡単では
本の虫: Clang VS 自由ソフトウェア
オープンソースで有名なEric S. Raymondが、自由ソフトウェアで有名なRichard Stallmanに、GCCのアンチプラグインポリシーについて突っ込んでいる。 GCCは、長年、コンパイラーのモジュール化を政治的な理由で行っていなかった。もし、例えばパーサーや意味解析だけを分離して使えるようにしたり、内部表現を規格化したりしてしまうと、GCCの一部が、不自由なソフトウェアに取り込まれたり、あるいは不自由なソフトウェアがGCCのプラグインという形で入り込むことになってしまう。これは、利用者の自由を第一とする自由ソフトウェアにとって、悪夢のような未来である。そのような未来を未然に防ぐために、政治的な理由で、GCCのはプラグインに反対するポリシーを採用している。もし、GCCを改良したければ、自由なソフトウェアとなるべきなのだ。そして、GCCのプロジェクトに参加するべきなのだ。 とはい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Third Party Add ons