「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう － Publickey
「Open Source Friday」をGitHubが提唱。金曜日は自分の好きなオープンソースに貢献しよう これはもともとGitHub社内で行われていた運動を広げ、誰でも参加しやすいようにしたもの。 下記はOpen Source Fridayの提唱を紹介する同社ブログの記事「Contribute on Open Source Friday · GitHub」からの引用です。 Over the last three years, we've encouraged GitHub employees to take time at least every fourth Friday to work on open source and share what we're working on with each other. Open Source Friday has grown from t
オープンソース活動への取り組み方 - Hatena Developer Blog
はじめまして。iOSとAndroidアプリの開発を行っている、アプリケーションエンジニアの id:ikesyo です。今年1月の入社後、初めての開発者ブログでの記事になります。最近の大きな出来事は、家族会議の結果、『ユーリ!!! on ICE』のBlu-ray全巻購入をしたことです。 この記事は、はてなエンジニアアドベントカレンダー2016の17日目の記事です。昨日は id:aereal によるはてなブログのデプロイを約6倍高速化したはなし - Sexually Knowingでした。 私は現在、自分のライブラリであるHimotokiやiOS開発用のパッケージマネージャのCarthageなど、全部で十数個のオープンソースソフトウェアの開発、メンテナンスを行っています。最初の頃はGitHubでPull Requestを出すのも怖かった私ですが、自身の活動を振り返ることで、どのようにオープンソ
大きな組織で情報共有するためのOSSつくってみた - Qiita
この記事は、Fujitsu Advent Calender 2016の6日目の記事です。 はじめに 仕事柄、沢山の人が関わるお仕事の効率化に関心があり、プライベートで研究や開発をしています。システム・インテグレーションをはじめ沢山の人が関わるお仕事は、人海戦術で行なわれる事がよくあります。しかし、経験上ITが関わるお仕事の人海戦術はおすすめできません。効率面、品質面、労務管理の面で問題が発生する事が多いからです。 人海戦術にならないようにするには、「人間的な仕事」と「機械的な作業」を切り分けて、機械的な作業をIT化するのが近道ではないかと考えています。 ITの現場における機械的な作業の例 情報を記録する（課題とか、バグとか、更新履歴とか） 情報を探索する（あの資料どこだっけ？とか） 情報を収集する（進捗どうですか？だめですか？とか） 情報を転記する（メールからエクセルとか） 情報を伝達する
MITライセンスを1行1行読んでいく | POSTD
全てのプログラマが理解すべき171語の文章 MITライセンス は、最も有名なオープンソースソフトウェアのライセンスです。この記事では、その内容を一行一行読んでいきます。 ライセンスを読む オープンソースソフトウェアを利用しているものの、これまでライセンス全文（原文：171語）を読む機会がなかった方は、大した量ではないので、今すぐ読んでください。あなたにとってライセンスが身近なものでないなら尚更です。理解できない箇所などがあれば、その部分は心に留めておき、明確にするようにしてください。これから背景や解説とともに、全文を分割して順番に紹介していきますが、大事なことは全容を頭に入れておくことです。 MITライセンス（MIT） Copyright (c) <年> <著作権保持者> 本ソフトウェアおよび関連文書ファイル（以下「ソフトウェア」）のコピーを入手する全ての人に対し、それらに関する無償のライ
WiXがWordPressのコードを盗用？GPL違反論争のまとめ
Tweet WiXとWordPress間で巻き起こるGPL論争 このブログはWordPressを利用しているのですが、そんなWordPressの創始者であるMatt Mullenweg(以下Matt)が10/29日に自身のブログにて衝撃の記事を投稿します。 日頃から新しいものを試すのが好きなmattがWiXのモバイルアプリを試していて、見慣れた管理画面だと思ったら、WordPressのコードが使われていたという衝撃の内容です。その記事の中でWiX宛にメッセージを発信しています。 Dear Wix This explicitly contravenes the GPL, which requires attribution and a corresponding GPL license on whatever you release publicly built on top of GPL
Work and OSS
MoneyForward Meetup Vol. 6の発表資料 http://moneyforward.connpass.com/event/42287/
きっと何者にもなれない自分というエンジニアとしての生存戦略 - @teitei_tk Blog
2016/10/26 現在26歳で業界歴は6年ほど。 まあ、若いと言えば若いであろう。実際色んな人と話をして年齢の話になると若いねとよく言われる。 が、もうそこまで若いとは言えないだろう。 あと3ヶ月も立つと自分も27になる。新卒の子や学生からしてみると、もはやおっさんであろう。 とまあ自分レベルの人間が自分をおっさんと言うと色んな人に怒られると思うので、おっさん予備軍とでも呼称するか。 で、そのおっさん予備軍として今後若く優秀なエンジニアと対抗する際に何が出来るのかと振り返ってみたが、何も残せていない。 例えば、 OSSで何か作っているか 有名OSSにContributeしているか CxOや役員などの経営者経験をしているのか OSSは趣味で作ったものをGithubで公開はしてはいるが、Star数が0のところを見ると利用されてるとは言えないだろう。 そんな感じで若く優秀な人からすると引っ込
Being an Open Source Developer, at work
Money Forward Meetup #6
Web系企業における小規模OSSの成功パターンを考える - Speee DEVELOPER BLOG
こんにちは、Speee技術顧問のid:gfxです。 最近は社内向けにOSSポリシー*1を策定しようとしており、草案を社内に公開して推敲しているところです。 さて、先日開かれたSpeee Cafe Meetup #02のテーマがOSSだったので、最近OSS活動に関して思っていることをまとめました。 ひとことでまとめると、「プロジェクトを成功させよう、そのためにOSSを活用しよう」という話です。 "OSSにコントリビュート" なんてしてる場合じゃない！ この話の文脈ですが、企業としてプロジェクトを成功させるためにどうOSSを活用するにはどうしたらいいのだろうか、 OSSを開発したり利用するときの成功パターンというのは何かということをもっと議論したい、すべきではないか と考えていて、その結果をまとめたものです。 この資料では「品質向上」というのをひとつのOSS活用の成功パターンとしてとりあげてい
GitHub のプロジェクトなどから学ぶ、サイドプロジェクト成功のパターン
ビジネス上のプロジェクトの成功法則やマネジメント方法は様々な形で語られています。一方で、主に余暇の時間で行われる技術的なサイドプロジェクト（ソフトウェア、ハードウェア含む）に成功パターンはあるのでしょうか。 最近では定量的なプロジェクトの分析を行うために GitHub のプロジェクトのデータを使おうとしている動きがあります。もちろん GitHub を使った研究はあくまでソーシャルコーディングのプロジェクトをスコープとするものですし、一部は因果関係というよりも相関関係でしかありませんが、知見として活用できる部分もあると思うので、GitHub の研究や私個人の経験を通して見てきたサイドプロジェクトの成功パターンをまとめてみたいと思います。 以下では大きく 3 つに分けて解説します。 チームアイデアとテーマプロセス 1. チーム最初に残念なお知らせです。どうやらプロジェクト内部の仕事の多くは少人
Linuxの背後にある精神
Linus Torvalds / 青木靖 訳 2016年2月 (TED2016) クリス・アンダーソン 奇妙な話です。あなたのソフトウェアであるLinuxは何百万というコンピュータの中にあり、インターネットのかなりの部分を動かしています。さらに実際に使われているAndroid端末が15億台くらいあって、その１台１台にもあなたのソフトウェアが入っています。これはすごいことで、その開発本部ともなれば、さぞ大層な施設なんだろうなと思っていたので、この写真を見たときはびっくりしました。これがその — Linux世界本部なんですよね？(笑)(拍手) リーナス･トーバルズ 大したものには見えませんよね。この写真の中で最も興味深く、多くの人が反応する部分は、あのトレッドミル・デスクです。私の仕事場で一番興味深いものですが、私はもう使っていません。この２つは関連していると思います。私の働き方として、外的な
30分でOSSに貢献する方法 - Speaker Deck
・OSSに貢献する突破口の見つけ方 ・短時間で無理なくOSSに貢献する How to contribute to open source within 30 minutes
オープンソースライセンス比較用早見表 - Google ドライブ
このファイルを使用中のユーザーが多すぎるため、一部のツールを利用できない場合があります。再試行詳細閉じる オープンソースライセンス比較用早見表 : Sheet1ABCDEFGHIJKLMN1ライセンスと著作権の表示変更した旨を示すことソースコードの開示ライブラリとして使用すること商用利用改変配布派生物に別のライセンスを課す特許の利用個人利用作者に責任を求めること商標の利用注記2No License必須可能禁止禁止禁止可能GitHubで公開したソフトウェアにライセンスを付記しなかった場合の条件3GPL v2.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし4GPL v3.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし5Affero GPL v3.0必須必須必須必須でない可能可能可能禁止可能可能禁止言及なし6Artistic GPL 2.0必須必須必須必須でない可能可
続: OSSプロダクトとコミュニティの話 - たごもりすメモ
先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。 t-wada.hatenablog.jp t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。 明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。 なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく
OSS関係で英語を書くときに心がけていること - ジンジャー研究室
最近、OSS関係でGitHubとかMLとかに顔を出していて、当然ながら会話は全部英語。 というわけで、英語を書くときに心がけていることを簡単に書く。 「英語が下手ですいません」とか前置きしない 読めば下手だって分かるから、わざわざ言う必要ない。これ言ってる人を見かけるとほぼ確実に日本人なんだけど、必要以上に卑屈なオーラを感じるので良くないと思っている。いくら日本人が英語苦手とは言え、英語圏の人は糞な英語に慣れてるから大体分かってくれるし、分からない場合はこういう意味かとレスが来るから、その都度説明すればいい。ただし後にも書くように礼儀は必要なので、甘え切って雑になるのはよろしくない。逆に丁寧に書けば懸命さが伝わり好印象。 あと、日本人以外にも非ネイティブは沢山居ると思うと結構気が楽。自分の感覚としては非ネイティブの書く英語ほど分かりやすい気がしていて、ネイティブの方が表現が小洒落てて時とし
NetflixのgithubリポジトリはWeb技術の百貨店だった - DiaryException
検索しているとなにかとNetflixのgithubリポジトリがヒットするので、全部（2015/07/18現在分）調査してみた。 github APIで https://github.com/Netflix のリストを全部取得して、名前・概要・URL・最終更新日時 (なんの更新だ?) を抽出。 AWS用のプロダクトが多かったのでまずそれらと、その他という分類にした。その他はほとんどがJavaライブラリ・システムだが、一部WebアプリケーションやPythonライブラリがある。 日本語での説明はReadmeやWikiを見て書いているが、理解が正しくないかもしれない。 AWS用 aws-autoscaling Tools and Documentation about using Auto Scaling URL: https://github.com/Netflix/aws-autoscalin
ショボいPull Requestを積み重ねて、自分の中でOSS活動の敷居を下げる - not good but great
GitHubのプロフィールページがパッとしない https://github.com/naoyashiga 「Repositories contributed to」がスカスカ GitHubの自分のプロフィールページを見るたびに、なんかパッとしないなあと思っていた。それは「Repositories contributed to」のところがスカスカだったからだ。Contributeをしてプロフィールページを豪華にしたいと思った。 スターが多いリポジトリは難しい できればスターが多いリポジトリにContributeしたい。自分はSwiftを使うことが多く、例えばAlamofireのような人気リポジトリに、プログラミング能力が低い自分がContributeするのは難しい。実際にリポジトリを見ても、何が問題なのか全くわからなかった笑 ショボいPull Requestを送る 「Repositorie
勝手自作OSSライブラリを会社のアプリに組み込んだ話 - クックパッド開発者ブログ
こんにちは、レシピ投稿推進室の小室（id:hogelog）です。 今回は私が実装したAndroid向けグラフ描画ライブラリline-chart-viewの紹介、ではなくついカッとなってOSSとしてこのライブラリを作りクックパッド (Androidアプリ)に組み込んだ話について書きます。 line-chart-view 最低限の紹介をするとline-chart-viewというのは List<LineChartView.Point> points = new ArrayList<>(); points.add(new LineChartView.Point(date("2014/07/01"), 100)); points.add(new LineChartView.Point(date("2014/07/02"), 200)); points.add(new LineChartView.Po
「Google I/O」公式AndroidアプリのソースコードをGitHubで公開
米Googleが、開発者向けカンファレンス「Google I/O」の公式AndroidアプリのソースコードをGitHubで無償公開した。 講演の題目や登壇者の確認、自分のスケジュールの登録、参加講演直前のアラート、NFC対応デバイスを使った参加者バッジのスキャン――など、カンファレンス参加者向け機能を多数盛り込み、Googleの提供する各サービスとも連携する。 新たなデザインアプローチとして発表した「Material Design」を採用し、Androidアプリの主要な機能を網羅。効率的なアプリ開発の1例として、学習や開発時のリファレンスとして広く活用してほしいという。 関連記事 AndroidのMAUは倍増の10億人──Google I/Oの数字まとめ 今年で7回目になるGoogle I/Oで発表された主な統計数字を抜き出した。Androidの月間アクティブユーザー（MAU）数は10億人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「SaCSS Special08 : WordPress + フロントエンド 鍋パーティー」でフリーランスとしての僕の考え方とオープンソースの楽しさについてお話しました
