オープンソースの持続可能性、IssueHuntの挑戦

オープンソースを取り巻く環境

「オープンソースでは食えない」

数十年前から蔓延している業界の通説です。

今、世界中の大半のIT企業が、オープンソースを活用して開発を行っていると言っても過言ではなく、日頃私たちが何となしに使っているそのOSSは、その多くが無償のボランティアで作られています。

その裏側には、誰かのクリエイティビティであったり、誰かの労働力が発生しています。機械が自動生成しているわけではありません。

世の中への貢献は正当に評価される権利がある、評価される仕組みが無いのなら、それを作って一般化させよう。その一心でIssueHuntを毎日コツコツ作っています。

Boostnoteがくれた、IssueHuntに挑戦するきっかけ

f:id:kazup_bot:20181206115108p:plain

オープンソースプロジェクトであるBoostnoteを、僕ら自身が2年に渡り運営し、多くのOSS開発者たちと対話を行う過程で、持続性に欠けるオープンソースエコシステムへの課題意識を、身を持って実感してきました。

Boostnoteは、今となってはほぼ全世界にユーザーがいますが、ここに至る90%以上は開発者コミュニティからの貢献のおかげであり、今やコアチームが開発に関わることはほとんど無くコミュニティが主体となり運営が行われています。

IssueHuntは当初、そんな素晴らしいBoostnoteの貢献者の為に作られた報酬プログラムでした。

BoostnoteコミュニティへBounty Programを公開してみると、僕たちの予想を超え、たった一週間でレビューが追いつかなくなるほど膨大なPull Requestが届きました。

これは、今のOSS環境が抱える課題を解決できるのではないかーー、その一心でIssueHuntの公開に至ったのが、2018年の7月のことです。

その後、今年の7月頃に一般向けに公開したのですが、著名ライブラリのMaterial UIやアリババ製のAntDesign等が続々と参加してくれ、少しずつムーブメントを作り出せている感覚があります。

IssueHunt Fest 2018に寄せて

f:id:kazup_bot:20181206115259p:plain

12月の一ヶ月間をかけて、オープンソースの寄付啓蒙を目的とし、IssueHunt Fest 2018を実施しています。

今日において、世界のオープンソース市場における日本の影響力が大きいかと問われれば、YESで無いことは確かですが、IssueHunt Festをきっかけに日本から大きなムーブメントを作り出し、作る人・使う人・支える人の関係が歪なオープンソースエコシステム全体に、国を超えて議論を巻き起こしたいなと思っています。

fest2018.issuehunt.io

当イベントは毎年4月と12月に恒例イベント化させる予定なのですが、今回はMicrosoft様はじめ、素晴らしい企業様よりスポンサードを頂く事が出来ました。

頂いたスポンサー資金は全て、世界中のオープンソースプロジェクトへ注ぎ込みます。

IssueHunt Festだけではなく、Monthlyでオープンソース支援の実施もIssueHuntを通して行うことが出来ますので、興味があられる企業さんがいらっしゃいましたらこちらから申請をお願い致します!

数社、誰でも名前を知っているIT企業さんより既にスポンサードが決まっており、San Francisco同様「オープンソースを支援しないIT企業はダサい」文化に必然的になっていくと思いますので、是非ご検討頂けましたら幸いです。

issuehunt.io

なお、IssueHunt以外にもオープンソース支援サービスはいくつかあります。僕たちはオープンソースを支援する文化を作りたいのであり、決してIssueHuntを押し売りしたいわけではありません。

特にオススメなサービスを下記に記載しておきますので、合わせて利用を是非ご検討ください。

OpenCollective

オープンソースプロジェクトに対して月々寄付を行うことが出来るサービス。寄付の引受先はもちろんOpenCollective運営チームの資金繰りも全てオープンにしており、資金の流れが透明性によって担保されていることが特徴。ニューヨークにいた時に創業者のXavierと朝ごはん食べましたが、めちゃくちゃ良い人でした。

Patreon

広義のクリエイター向け資金調達サービス。サービス名の通り、クリエイターのパトロンになることが出来る。OSSプロジェクトそのものというよりは、OSSを作っている開発者(個人)を支援するサービス。

また、来年の4月には大規模なオープンソースカンファレンスの実施を予定しており、企画が進行しています。

ありきたりなカンファレンスではなく、ロックバンドのライブのように仕上げる予定です。詳細は追ってアナウンスしますので、是非楽しみにお待ちいただけたらと思います。

「オープンソースでは食えない」

果たしてそれで良いのでしょうか?

このスクリーン上の文字が網膜に届くまでのコンマ一秒の為に、膨大なオープンソース技術の開発が行われています。

私達自身が直接的・間接的にオープンソースの恩恵を受けている身として、IssueHunt Festが議論を生むきっかけになれば、チーム一同嬉しく思います。

IssueHunt Fest 2018について

毎年4月と12月の一ヶ月ずつをかけて実施する、オープンソースへの寄付啓蒙イベントです。IssueHuntがスポンサーを募り、頂いたスポンサー資金を使い、IssueHuntに掲載されているオープンソースプロジェクトへの支援を行います。

今回の初開催にあたり、Microsoft様・LINE様・Framgia様・Mercari様・Cryptoeconomics Lab様よりスポンサードを、Unity様・JetBrains様・匿名希望スポンサー様よりグッズスポンサードを頂いております。関係者の皆様に、この場をお借りして改めて感謝申し上げます。本当にありがとうございました!

f:id:kazup_bot:20181206115547p:plain

また、プロジェクトオーナーだけではなく、参加者特典としてIssueHunt経由で3つ以上Pull Requestを出した参加者の方にはステッカー等のグッズを、貢献度ランキング上位10人には、オリジナルティーシャツを差し上げます!

日本からオープンソースの貢献を爆発的に増やし、世界の開発者コミュニティをあっと言わせてやりたいなと強く思っています。

*合わせて読みたい hackernoon.com

自分だけの仮想通貨発行・ハンズオンを開催しました by Ineeza.inc & BoostIO

この記事では、5/12(土)に行われた独自トークン発行ハンズオンの様子を紹介します。

f:id:junp0819:20180514162320p:plain

講師

講師として、株式会社Ineeza.inc CEO / Blockchain Engineerの竹本 哲郎さんに登壇していただきました。

f:id:kazup_bot:20180514170343j:plain

講義 & ハンズオン

講義内容の概要

  • ブロックチェーンの特徴
  • イーサリアム開発ツールについて
  • カスタム通貨作成方法
  • Supplyの初期化
  • Truffle
  • コンパイル & デプロイ

竹本さんによる講義の後、実際に手を動かし、参加者によるハンズオンを行いました。

f:id:kazup_bot:20180514170045j:plain

流れとしては、竹本さんのスライドで次に行うことを確認しながら作業を行い、 実際にわからない部分を参加者が質問して一人一人竹本さんが教えに来てくれるという形でイベントを進行しました。

プログラミング初心者の著者の結果

プログラミングに詳しくない初心者の著者でも、無事にCoinのトークンを発行することができ、最後は、アプリTrustWalletに、TESTESTCoinを送金できました!

f:id:junp0819:20180514163201j:plain:w300

誰でも作れるよう竹本さんがアドバイスをくれるので安心です。

ハンズオンを終えての感想

初めてハンズオンのイベントを開催しましたが、LTだけのイベントに比べて、参加者同士の話し合いや、登壇者との会話が圧倒的に多く、参加者同士の交流が円滑に行なわれていたと感じました。
途中わからなくなっても講師の竹本さんや、周りの方が助けてくれるので初心者の方も気軽に参加できると思います。

f:id:kazup_bot:20180514170112j:plain

毎月技術系の企業さんと連携し、ミートアップを行っています。

今回イベントに参加できなかった方も、是非参加してみてくださいね!

React x Typescript ミートアップ by Boostnoteを開催しました!

4月14日(土)に、React x Typescriptのミートアップを実施しました! 
当記事ではミートアップイベントの様子を紹介します。

f:id:junp0819:20180427145833p:plain

イベント概要

このミートアップはReact x Typescriptのスキルアップのための会であり、
実際にReact x Typescriptを使用している方によるLTを実施しました。
現場のエンジニアの話を聞くことで、高度な技術を知ったり、
効率的な方法を知ることができるイベントでした!

LT1 "ReduxからMobXへ移行した理由" - Choi Junyoung

f:id:junp0819:20180427150305j:plain
Boostnoteを開発している、弊社CTO Choi JunyoungによるLTを行いました。
ReduxからMobXに移行した話をしてもらいました。

www.slideshare.net

LT概要

・2年以上の実務でReduxを使って経験した苦痛に対し、MobXではそれぞれの問題がどれほど簡単に解決できるのか
・Memorization
・Multiple mutations
・Deep state and immutable
・ まとめ: 指先の辛さと割と大きいラーニングコスト

Twitterアカウント: @Rokt33r

LT2 " React + Redux で開発がしたかった" - 成 英柱さん

f:id:junp0819:20180427150702j:plain
参加枠より、成 英柱さんに「React + Redux で開発がしたかった」のLTを行っていただきました。
登壇していただいた際のスライド内容を以下のリンクから確認できます。

github.com

LT概要

・なぜ React なのか
・内部ステート vs 外部ステート
・React の罠
・ ビュー or ドメイン
・理想のディレクトリ構造
・ステートの正規化
・アクションが Reduce されたときに別のアクションを Dispatch したい
・型チェック
・React + Redux で型をどう使う?
・まとめ

Twitterアカウント:@sei40kr

LT3 "Reactで動画プレーヤーを作った話" - yugoさん

f:id:junp0819:20180427150717j:plain

参加枠より、yugoさんに「Reactで動画プレーヤーを作った話」のLTを行っていただきました。
登壇していただいた際のスライド内容を以下のリンクから確認できます。

www.slideshare.net
・動画プレーヤーの仕様
・ライブラリの選定
・大いなる勘違い
・状態管理について

Twitterアカウント:@ymmmo1

各、LTの後には参加者からLTへの質疑応答の時間もあり、現場のエンジニアに質問ができるという貴重な体験になったと思います。

懇親会

f:id:junp0819:20180427163212p:plain
LTが終わった後は、ビールを飲みながら懇親会を行いました。
乗り物 ~ 観光メディアまで多様な仕事を行っているエンジニアの方々との会話ができ、
とてもためになる話を聞くことができました。
遠くからは函館からいらっしゃった方もいて、イベントを通してしか出会えない方にも会うことができるのがイベントの良いところだと実感しました。

まとめ

イベントを通して色々な方と交流できるのは本当に良い体験です。
新たな知識や方法を知ることはもちろん、他の方の話を聞くことで自分自身のこともより理解できます。
イベント自体は、開催からビール片手にゆるっと行っている会なので、今後また開催した時は是非皆様お気軽にお越しくださいませ!
また、お越し頂いた方には、BoostnoteとBoostlogステッカーをプレゼントしています。

f:id:junp0819:20180427152230j:plain

イベントページ

boost.connpass.com

conpassにてイベントを随時開催しているのでよろしければフォローをお願いします。   

SNS

SNS上でも発信しております。
よろしければこちらもフォローやLikeをお願いします。

www.facebook.com


以上、4/14(土) に行われた「React x Typescript ミートアップ」の様子でした。
イベント会場は主にスローガン株式会社 イベントスペースにて行っております。

次のイベントではあなたのご参加をお待ちしております。

どんなチームがReact Nativeによる開発に向いているか

はじめに

最近はアプリ開発にReact Native(以下RN)を使用するケースも増えてきているようですが、RNはネイティブアプリを開発する最強のライブラリというわけではありません。

メリットをうまく利用すればとても良いアプリができると思いますが、失敗すると、さらに倍の時間をかけてSwift、Javaで作りなおし、、、といったことも発生するかもしれません。

特徴や他社事例をよく調査し、チームの状況に応じて、採用するかどうか判断することがとても大事です。 この記事では、どういった状況に置かれたチームが、RNで開発するのに適しているか、僕なりの考えを書きますので、参考にしていただければと思います。

RNがどういったものであるかの説明や、実装方法については書きません。

目次

1. なるべく早くリリースしたいチーム

RNはiOS/Androidのソースを一括で記述/管理することが可能です。

また、ホットリロードが可能なので、修正後のビルドの時間も短くてすみます。

そのため、なるべく早くiOS/Androidアプリを開発したいというチームには適しているかと思います。 また、記述するのは主にJSなので、エディタやIDEも好みのものを使えます。

そのため、開発がより進むこともあるかもしれません。

2. iOS/Androidで仕様・見た目を揃えたいチーム

iOS、Androidを別の人が実装すると、仕様や認識のズレが発生したり、OS固有の理由により、出来る出来ないが発生したりするというのが、アプリ開発におけるあるあるかと思います。 RNで1ソースで管理すれば、そういったことも少なくなるでしょう。

また、もちろん、OSによって適したデザインがあると思いますが、それでも見た目を揃えたい箇所がある場合、実装が1箇所になるので目的は果たされるかと思います。

ただ、1箇所にまとめたコードの中で、あえてiOS/Androidそれぞれで処理を分岐させる箇所が多くなってくると、「一括でソースを管理しているのはなんでだっけ?」となるくらい、分岐が多く、読みづらいコードになる可能性もあります。

そういった場合には、*.ios.js*.android.js などとファイルごと分けてしまうなど、設計を考える必要があるかと思います。

3. WEBのエンジニアは足りているけど、ネイティブのエンジニアが十分にはいないチーム

アプリの需要は依然として高く、ネイティブのエンジニアは売り手市場です。

基本的にどのチームもネイティブのエンジニアは足りていないと思います。

ただ、アプリ以外のエンジニアにも目を向けてみると、WEBのエンジニアであればJSを書いたことが無い人はあまりいないかと思うので、どうしても手が足りない場合には、少し(?)Reactを勉強してもらって、開発に携わってもらうこともできるかと思います。 ただ、リリースの際にXcodeを使うなど、iOS、Androidの知識は少なからず必要なので、ネイティブのエンジニアが全くいない状態でJSだけで書けるからとRNを採用するのはおすすめしません。 (その状態ではSwift、Android Javaでもアプリが作れるかというとわかりませんが。。。)

まとめると、ネイティブの知識はゼロでは無く、少しは必要。ただ、WEBのエンジニアに手伝ってもらえる可能性もある、ということです。

4. アプリのデザイン経験が無いデザイナが多いチーム

RNの見た目の部分はcssライクに書くことができます。 また、見た目もネイティブよりかは自由度があります。 なので、アプリの経験がなくても、開発時には対応できるかと思います。

ただ、やはりアプリらしいデザインや、それぞれのOSに適したデザインがあるので、それは常に勉強して、改善していくのがいいかと思います。

5. アプリの改善サイクルをなるべく早く回したいチーム

RNを利用する大きなメリットとして、CodePushが利用可能であることがあげられます。

そのため、デリバリーの高速化が可能です。 ネイティブのデメリットとして、特にiOSですが、実装してもリリースまで時間がかかる、リリースしてもユーザーがアップデートしないと使ってもらえない/バグが直らない、というのがあります。

CodePushを使えば、実装したものをすぐに届けられるので、細かなバグ修正や、見た目の修正、ABテストもやりやすくなるのかなと思います。

6. WEBとアプリの見た目を合わせたいチーム

React Native for Webというものがあります。

最初は名前に少し違和感があるかと思いますが、スマホのブラウザから見た場合のWEBのHTMLをRNのようにコンポーネントでラップして開発できると考えるといいかもしれません。

こういったものを利用すれば、WEBとアプリの見た目を揃えたり、コンポーネントを共通化させて開発速度を上げることができるかもしれません。

少し難易度は高そうですが、細部から少しずつ挑戦してみるといいと思います。

7. 最初から最速・最高を求めないチーム

RNは一度JSを経由するため、ネイティブ実装に速度でまさることは出来ません。

また、ネイティブをちゃんと実装できるエンジニアがいて、時間も十分ある場合、(codepushを除いては)RNを利用するメリットはありません。 アプリ開発において、それに越したことはないです。 ただ、最初のリリースは品質は2の次でとにかく早く出したい、ユーザーの意見を聞いて早く改善していきたい、という場合には適しています。

それでサービスがスケールしたら、ネイティブのエンジニアを採用して、ネイティブで書き直すのがいいと思います。

まとめ

上にも書いたように、RNはアプリ開発における最適解ではありません。

ただ、適した場所で使用すればとてもメリットがあると思います。 上に書いたような環境に置かれた時に、開発の選択肢を増やす意味でも、RNを勉強しておくのがよいと思います。

ReactのFunctionComponentでライフサイクル

こんにちは。Boostnoteのメンテナのsosukesuzukiです。BoostnoteはReactで書かれていています。そして実はBoostnoteは作られてから結構時間が経っていて至る所に肥大化したコンポーネントが存在します。Boostnoteでは肥大化したコンポーネントはコントリビュータの皆様のおかげもあって以前と比べたらマシになってはいますが、放置され気味になっています。それについていつかなんとかしたいと考えていて、なんとかする方法についての記事です。

極力StatelessFunctionalComponent

肥大化したコンポーネントは読みにくく、管理がしづらいので、適切な大きさにコンポーネントを分割していくことがが必要です。分割していく上で重要なのは省けるStateは全て省きコンポーネントは極力StatelessFunctionalComponentにすることです。extends React.ComponentではなくStatelessFunctionalComponentとして実装することで状態を保持していないことが自明になります。

// StatelessFunctionalComponentの例

const component = ({hoge, huga}) => (
  <h1>{hoge}</h1>
  <h2>{huga}</h2>
)

ある程度コンポーネントが状態を保有するのは仕方がないことだとしても、状態の管理に気を遣わなければならない箇所はできるだけ増やしたくはありません。そんな所まで頭が回りません。

ライフサイクルはHigherOrderComponent(HOC)

そんな理由があって、StatelessFunctionalComponentを使う方が人間にとって結果的に易しくなることが多いわけですが、アプリケーションを作る上での欠点として、StatelessFunctionalComponent単体ではlifecycleを扱うことができません。それを実現するためにはHighrtOrderComponentを使う必要があります。 HigherOrderComponentはReactコンポーネントを引数として受取りReactコンポーネントを引数として返す関数により実装されます。型シグネチャをHaskellライクに表すと次のようになるでしょう。 hocFactotryがHOC(HigherOrderComponent)のファクトリーとなる関数の名前、Wが引数に渡すReactコンポーネント、Eが返り値のReactコンポーネントです。

HigherOrderComponent:: W: React.Component => E: React.Component

HOCはコンポーネントの抽象性を高め、さらなる再利用を可能にします。 HOCを使うとStatelessFunctionalComponentのライフサイクルをフックすることができます(それ以外にも様々なことに使えますが、この記事ではHOCについての詳しい解説はしません。FaceBookの公式ドキュメント、franleplant氏のReact Higher Order Component in depthなどが非常にわかりやすくHOCについて解説しています。)。

// HOCでStatelessFunctionalComponentのライフサイクルをフックする例
const InputComponent = ({hoge, boo}) => (
  <h1>{hoge}</h1>
  <h2>{boo}</h2>
)

function logProps(WrappedComponent) {
  return class extends React.Component {
    componentWillReceiveProps(nextProps) {
      console.log('Current props: ', this.props);
      console.log('Next props: ', nextProps);
    }
    render() {
      return <WrappedComponent {...this.props} />;
    }
  }
}

const EnhancedComponent = logProps(InputComponent);

この方法をとるにしてもHOCで返すコンポーネントはextends React.Componentを使って記述する必要があります。この形をとるコンポーネントが増えていくと、class宣言とrenderはボイラープレートになっていきます。

recomposeでHOCを楽に

recomposeというライブラリがあります。このライブラリはHOCのためのユーティリティ関数群で、react版lodashと例えられているのを見たこともあります。このライブラリには様々な関数があり、それらはrecomponseのGithubでドキュメントを見ることができます。 上述の通りHOCには様々な使い方があって、それらのための関数が大半でライフサイクルに関係する関数はごく一部です。なので、比較的簡単に導入することはできるんじゃないでしょうか。このあたりは本当にlodashみたいですね。適宜必要な関数だけ使えばよくて、ライブラリ自体が複雑な構造になっているということはありません。 HOCでライフサイクルを楽に実装する上で必要な関数はlifecycle関数です。 lifecycle関数は次のような型シグネチャを持ちます。

lifecycle :: spec: Object => H: HigherOrderComponent 

そして、このようにして使われます。

const PostsList = ({ posts }) => (
  <ul>{posts.map(p => <li>{p.title}</li>)}</ul>
)

const PostsListWithData = lifecycle({
  componentDidMount() {
    fetchPosts().then(posts => {
      this.setState({ posts });
    })
  }
})(PostsList);

lifecycleの引数の中でのStateは、HOCの引数に渡すコンポーネントにpropsとして渡されます。 また、lifecycleの型シグネチャは次のように書き換えることもできます。

lifecycle :: spec: Object => W: React.Component => E:Component

HOCの型がHOC:: W: React.Component => E: React.Componentなので当然なのですが、Haskellやらそのあたりの人にはこのように書いた方がわかりやすいかもしれません。

よさそう

reomposeでHOCを使えばStatelessFunctionalComponentで簡単にライフサイクルまで扱うことができるようになります。状態について考えることがなくなるのも記述が簡潔になるのも人間にとってはよいことだと思うので、使える機会がありそうだったらどんどん使っていったらいいと思います。時間があればBoostnoteでもこのようにコンポーネントを適度に分割していきたいと思っています。

オープンソースのPYTHONプロジェクト 5選 [12/24~12/30]

GitHubで公開されているオープンソースの人気PYTHONプロジェクトを紹介していきます🌟 f:id:junp0819:20171230184337p:plain

No.1

wangshub / wechat_jump_game

f:id:junp0819:20171230183323p:plain:w300
https://wangshub.github.io/
Star:809🌟
github.com

No.2

gaojiuli / toapi

f:id:junp0819:20171230183402p:plain
すべてのウェブサイトはAPIを提供しています。
Star:1,321🌟
github.com

No.3

zhoubear / open-paperless

f:id:junp0819:20171230183511p:plain
すべての紙文書をスキャンし、索引付けし、アーカイブする。
Star: 1,563🌟
github.com

No.4

rockyzhengwu / FoolNLTK

f:id:junp0819:20171230183702j:plain
中国語自然言語ツールキット
Star:543🌟
github.com

No.5

sb2nov / mac-setup

f:id:junp0819:20171230183744g:plain
Mac OS Xでの開発環境のインストール
Star: 3,523🌟
github.com


Curated by Boostnote boostnote.io

GitHub Repository github.com

オープンソースのSwiftプロジェクト 5選 [12/23~12/29]

GitHubで公開されているオープンソースの人気Swiftプロジェクトを紹介していきます🌟

No.1

SoySauceLab / CollectionKit

f:id:junp0819:20171229171432j:plain:w300
再利用可能なデータ駆動型コレクションコンポーネントを構築するための最新のSwiftフレームワーク。
Star:1,627🌟
github.com

No.2

efremidze / Shiny

f:id:junp0819:20171229171442g:plain
Iridescent Effect View (Apple Pay Cash)
Star:300🌟
github.com

No.3

EyreFree / EFQRCode

f:id:junp0819:20171229171523j:plain
Swiftで迅速な応答コードを操作するためのより良い方法。
Star: 2,370🌟
github.com

No.4

kmikiy / SpotMenu

f:id:junp0819:20171229171652p:plain
メニューバーにSpotifyとiTunesを追加。
Star:540🌟
github.com

No.5

lhc70000 / iina

f:id:junp0819:20171229171534p:plain
MacOS用の最新のビデオプレーヤー。
Star: 9,803🌟
github.com