まつもとゆきひろ氏が“幻のPerl6”から学んだ教訓 「OSSの最大の敵」と「セカンドシステムの危険性」
プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。3回目は、「Second System Syndrome」について。前回はこちら。 退屈は最大の敵 まつもとゆきひろ氏：次はPerlですね。ここまでですでに4回ぐらいPerlの話題が出てきています。なぜかというと、私はPerlが大好きなんですね。実は、Perlが大好きなんですが、Perlのプログラミングは大好きじゃないんですね。あと、Perlのソースコードも大好きじゃないんですね
OSS 活動を通して貢献できた Meilisearch を紹介したい - Qiita
この記事はスタンバイ Advent Calendar 2023 の11日目の記事です。 こんにちは。求人検索サービスを提供する株式会社スタンバイでプロダクト開発部長をしている大須賀です。 普段の仕事は開発組織運営などのマネジメントが中心です。一般的にマネージャは、業務として直接的に開発に携わることが少なくなり、Individual Contributor (IC) としてスペシャリストを目指すエンジニアから敬遠されがちです。確かにその通りかもしれませんが、幸運なことに私の場合、仕事をではマネージャとして、OSS 活動ではエンジニアとして、今年一年、充実したキャリアを積むことができたと思っています。 そこで今回は、会社でマネージャをしながらも、OSS の活動でエンジニアとして貢献できた OSS 全文検索サーバー Meilisearch を紹介したいと思います。 私が Meilisearch
lerna-changelogで始める頑張りすぎないリリースノート自動生成
hothouseというpackage.jsonとlockfileを更新してPR出すツールを公開するときに、 「リリースノート頑張りたくないな」と思い、なるべく楽にそれなりのリリースノートを残せる方法を探った結果、 lerna-changelogというLerna公式のツールが良さそうだったので、採用しました。 hothouseではlerna-changelogで自動生成されたリリースノートを公開してます。 https://github.com/Leko/hothouse/releases 規模が大きくなったり、需要が高まったらしっかり書こうと思いながら、 何も書かないのは嫌だし、とは言えまだこの規模でリリース作業に苦労をしたくない。 そんな温度感にちょうどマッチしてくれるツールです。 あまり使ってるリポジトリを見かけないので、紹介してみようと思います。 lerna-changelogとは —
Ship.jsでリリースフローを改善する - Qiita
PLAID で i18n おじさんエンジニアしてる kazupon です。 この記事は plaid advent calendar 2019 の 17日目の記事です。 はじめに 筆者は、PLAID のプロダクト開発以外にも、オープンソースソフトウェア (以下 OSS )開発者として vue-i18n といったオープンソースプロジェクトを持っており、Node.js においては npm または yarn といったパッケージマネージャーと呼ばれるもので、Node.js そして必要に応じてブラウザ向けに動作するコードをパッケージにして OSS として配布しています。 npm / yarn で配布する OSS は、一般的には semver のようなセマンティックバージョンニングの仕様に沿った形で、バージョンをリリース毎に発行して管理して、npm publish や yarn publish によって
自作 OSS のためのロゴを作る | micnncim
著名 OSS にあって自作 OSS に無いものの一つにロゴがあります。 OSS において README の出来不出来はユーザへのリーチを高める重要な要素であり、詳細な Description や GIF によるデモはもちろん、ロゴがあればより魅力的な README になるでしょう。 また、SNS でシェアされる際もロゴがあればより良いでしょう。 はじめにソフトウェアエンジニアの多くはデザイナーではないためロゴを作るコストは低くなく、テキストだけ作るのであればまだ簡単ですが、自作アイコンを作ることはかなりの労力を要することでしょう。 僕も同様で、デザイナーではないため、結論として非デザイナーでも出来る戦略を考えることになりました。 今回は、micnncim 流の、出来るだけ低コストで低くないクオリティの OSS のためのロゴの作成方法について解説します。 慣れれば上の画像のようなロゴが 5
たくさんあるオープンソースライセンスのそれぞれの特徴のまとめ
GitHubが、どのオープンソースライセンスを選択すればよいのか指針となるサイトを公開したので、それぞれの特徴を翻訳してまとめてみました。 Choosing an OSS license Apache v2 License GPL v2 MIT License Mozilla Public License Version 2.0 LGPL v2.1 BSD (3-Clause) License Artistic License 2.0 GPL v3 LGPL v3 Affero GPL Public Domain (Unlicense) No License Eclipse Public License v1.0 BSD 2-Clause license 備考：各項目の補足説明 最後の「備考：各項目の補足説明」に各項目の補足となる説明をまとめました。 Apache v2 License ソ
Githubによる、オープンソースライセンスの選び方 | オープンソース・ライセンスの談話室
「オープンソースライセンスは、分かりにくい。」 まだまだ、このように感じているソフトウェア開発者が多いようです。 たしかに、オープンソースライセンスをお手軽に解説した記事は、かなり人気があります。 ソースコード共有サービスとして人気のGithubの利用者にとっても、これは例外ではないようです。 Githubでは、オープンソースプロジェクトには、無償でレポジトリを提供していますが、「GitHub 上で公開されているソースコードの半分はライセンス的に問題あり」と指摘されていました。公開リポジトリの多くに、ライセンス文が設定されていなかったのです。ライセンスが設定されていないソースコードは、著作権者の明示的な許可が得られていないので、自由に複製・配布・改変できません。 そこで、ここでは、2013年7月にGithubが設置したライセンス選択サイト「Choosing an OSS license d
ライセンスの選択を恐れる必要はありません - Qiita
(訳註: この「はじめに」及び末尾の「訳者による補足」の章は原文にはなく、翻訳者(@tadsan)によるものです。記事の著作権表示及び元Webサイトの利用規約、免責事項、そしてこの記事についての訳者の見解について記します) (この記事の一部または全て ——ただしコメント欄は含まれない—— はCC BY-SA 3.0に則る限り、自由に利用することができます。翻訳と「はじめに」「訳註」については独自の著作権は主張しません。 改竄しても二次利用は独自の責任にて行ってください。) Please consult a legal expert before adopting a software license for your project. This site is licensed under the Creative Commons Attribution 3.0 Unported Lice
千里の道も1パッチから――コミッタライフ入門 － ＠IT自分戦略研究所
今回は「コミッタに興味がある」という人のために、筆者のRubyコミッタとしての経験について紹介します。筆者はRubyプロジェクトを立ち上げたわけではないので、前者の「ほかのコミッタから認められ、推薦される」の方の紹介となります。 ■Ruby 1.9.0リリース時に「面白そう」と思ってコミット権をもらう 大学生だった2003年ごろ、わたしはCGIやテキスト処理など日々の雑務をこなすためのスクリプト言語としてRubyを覚えました。Perlと違って相性が良く、自然と身に付きました。 最初にパッチを送ったのは2005年。大学のSolarisでRubyが動かなかったときです。次は2007年。デバッグ出力用関数pを便利にする提案を行い、（Rubyプロジェクトのリーダーであるmatzさんの説得に半年かかりましたが）採用され、Rubyに思い入れがわくようになりました。 当時、Rubyは笹田耕一さんのYAR
【レビュー】開発前に読んでおきたいOSSライセンスの説明と比較 | エンタープライズ | マイコミジャーナル
情報処理推進機構 情報処理推進機構(IPA)は5月31日、GPL以外の主要なオープンソースソフトウェアライセンスについて、そのライセンスの特徴、プロジェクトにおける利用状況とそのライセンス戦略、ライセンスに関する係争などについて調査した結果を報告書として公開した。GPLv3に関してはすでに別の解説書を提出しているため、同報告書では軽く説明する程度にとどめている。 OSSライセンスの比較、利用動向および係争に関する調査 (報告書PDF) GNU GPLv3 逐条解説書 (解説書PDF) 報告書ではまず、数あるOSSライセンスを「コピーレフト」の観点から3種類に分類。次の2つの条件にどのように当てはまるかで分類している。(a)(b)ともにある場合はコピーレフト型、(a)のみなら準コピーレフト型、どちらも該当しないなら非コピーレフト型となる。 (a) ソースコードを改変した場合に、改変部分のソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - gfx/android-oss-best-practices: Best practices on creating Android OSS library projects [JA]![GitHub - gfx/android-oss-best-practices: Best practices on creating Android OSS library projects [JA]](https://cdn-ak-scissors.b.st-hatena.com/image/square/00627daa5f2d64dd0b35bf3e7276f8481abc50c6/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2F4c0dbe88eb498fda9468fd37561c408b4d8d4366463cdf99e4eabac44d681348%2Fgfx%2Fandroid-oss-best-practices)