技術探し

JavaScriptを中心に記事を書いていきます :;(∩´﹏`∩);:

OSS活動のサポートを募集しています

www.patreon.com

3月から始めていましたが、特に自分が何も提供しない状態だったため、これを解消したくて内容を変更することにしました。

JavaScriptがメインのエンジニアです。

今現在、アイルランドのダブリンに在住しており、毎日通うような仕事を持っていません。
厳密に言うと、自分は個人事業主なのでリモートワークとして1つの会社で働かせていただいている + OSSをして生活してます。

現在の活動は、以下のOSSがスコープ対象です。

Node.js

JavaScriptランタイム。

github.com

メインは、ECMAScript Modulesとpathとconsoleのモジュールとなります。

webpack

JavaScriptのバンドラ。

github.com

スコープは、webpack(core)、webpack-dev-server、webpack-dev-middleware, webpack.js.orgとなります。

webpackの次のバージョンであるv5に向けて取り組んでいます。
今現在、アクティブメンバーの一人です。

Fusuma

Markdownを使ってスライドを作るCLI

github.com

ssr-sample

様々なライブラリに対応したSSR/SPAの作り方サンプル。

github.com

変更目的

上に書いたとおり、こちらからサポーターの方々に対して何も返せてなかったのを今後は、自分の持っている知識で還元できればいいなと思ったので、質問をできる場を作成します。

また、もちろんですが自分が持っていない知識も多いため、質問に対して適切な回答をできるとは限りません。
その質問に対して議論し、最適解を見つけていきたいということも目的として存在しています。(言い方があれかもしれませんが、自分も多くのエンジニアから学びたいことが多い)
アーキテクチャの話とか好きです🤗

いずれにせよ、お互いにwin/winになれるような環境を作りたいと思っています。

別の理由としては、アイルランドで寂しくなってきたのでslack作ろうってのはあるかもしれません。

価格帯

変更後は以下のようになります。
新しく$2と$30が追加され、すでに存在していた他の価格帯にslackの招待と質問の可能が追加されました。
当初は、質問を無限に受けようかと思いましたが、どれぐらい大変なのかわからなかったので、とりあえずは週に何回程度という条件を設けさせてください。

$2

特典はありません。
しかし自分のOSSに対するやる気が向上されることは間違いありません。

$5

  • Slackに招待されます。
  • publicでの質問が可能です。(週に1回程度)

$10

  • Slackに招待されます。
  • public/privateでの質問が可能です。(週に2回程度)

$30

  • Slackに招待されます。
  • public/privateでの質問が可能です。(週に2回程度)
  • ペアプロでサポートすることが可能です。(月1回、30分程度)

$100

  • Slackに招待されます。
  • public/privateでの質問が可能です。(週に3回程度)
  • ペアプロでサポートすることが可能です。(月1回、1時間程度)
  • 特定のossに対するあなたの要望についてディスカッションします。

詳しくは、以下のページを見てください。

www.patreon.com

もし、自分のOSS活動に応援してくださる方がいましたら、支援お願いします!
自分が持っている知識を少しでもサポーターの方々に還元できたらと思います。

Markdownだけでスライドを作るCLIのv1.0.0をリリースした

一年前に作ったライブラリのv1.0.0リリースです。

blog.hiroppy.me

リポジトリ

github.com

Fusumaとは?

以下の機能をサポートしているCLIです。

  • 開発環境(webpack-dev-server)
  • 本番環境(最適化含む)
  • GitHub Pagesへのデプロイ
  • PDFの出力
  • SNS, OGP対応
  • 発表者モード
    • 発表者ノートやタイマー等

以下を実行するだけで、スライドが作れます。

$ npm i fusuma -D
$ npx fusuma init
$ mkdir slides && echo '# Hello😄' > slides/title.md
$ npx fusuma build

f:id:about_hiroppy:20190508060526p:plain

内部では、markdownで書いたファイルをhtmlに変換して、それをhtmlで作るスライドライブラリに読み込ませています。

大きな変更

スライドライブラリ

もともと、bespoke.jsというのを使ってたのですが、メンテナンスが2016ぐらいから止まりつつあって、今後しんどいなって気持ちになったので、WebSlidesというライブラリに切り替えました。(メンテもされています)

Fusumaは以下のライブラリにmarkdownからhtmlへ変換し渡す役割を持ちます。

WebSlides

webslides.tv

サイト自体もスライドになっています。

用意されているクラスやコンポーネントがめっちゃ豊富で、レスポンシブ対応されています。
また、独自でプラグインを追加したりできます。

コンポーネント

f:id:about_hiroppy:20190508054212p:plain

サンプルスライド

webslides.tv

クラス

f:id:about_hiroppy:20190508054408p:plain

サンプルスライド

webslides.tv

マークダウンで書く

## 1ページ目

Hi!

---

## 2ページ目

Hi!

みたいに書くと、webSlidesのcssがついた2ページ分のスライドが生成されます。
githubのfileでもmarkdownだと整形して見れるので、案外markdownで書く利点あると思う。

拡張

JSとCSSは拡張できるので、webSlidesの気に入らない部分とかあったら上書きできます。

本番ビルド

画像圧縮やcssの最適化等はすべて設定してあるので、今はwebpackはさわれないようにしています。

発表者モード

f:id:about_hiroppy:20190508060144p:plain

(上記は登壇者画面、UI変更する可能性あり)

Presentation APIを使ってキャストします。(chrome castとかでも多分いけるけど試してない)

developer.mozilla.org

もし、対応していなくてもlocalstrageで同期する仕組みも自動でフォールバックするので、問題は無いと思います。

ノート

以下のようにスライドに書いておくと、ノートとして見れます。

<!-- note
Hi!
-->

サンプルリポジトリ

fusuma/samples/intro at master · hiroppy/fusuma · GitHub

最後に

さくっとスライド使いたいときに便利です:)

github.com

こちらも進んでいます

Node.jsのECMAScript Modulesの紹介

www.meetup.com

ここで話したことの日本語版です。

blog.hiroppy.me

ECMAScript Modulesとは?

JavaScriptには、AMDUMD、CJSのような多くのモジュールシステムがあります。
ECMAScript Modulesは当初ES2015に入る予定でした。
さて、ESMの仕様はWHATWGとTC39が管理しますが、役割が違います。

TC39はESMのシンタックスやJSのルールを管理します。
例えば、モジュールはstrict modeになるとか、thisの扱いとか。

しかし、モジュールの読み込みに関しては、WHATWGが管理します。
理由は、ブラウザとNode.jsの間でこれは処理系依存になり、異なるからです。

HTML

<!-- ESMをサポートしているブラウザ -->
<script type="module" src="esm.js"></script>
<script nomodule src="fallback.js"></script>

<!-- ESMをサポートしていないブラウザの解釈 -->
<!-- <script type="module" src="esm.js"></script> --> <!-- type:moduleは存在しないため無視 -->
<script src="fallback.js"></script> <!-- `nomodule`属性だけ無視して実行(type:text/javascript) -->

scriptタグにtype="module"を指定することにより、ブラウザにそのファイルがESMだということを伝えます。しかし、ESMをサポートしていないブラウザはその属性を識別できないため実行しません。

なので、nomoduleを使うことにより、ESMをサポートしていないブラウザに対応します。この場合、type自体は変更していないため、サポートしてないブラウザはnomodule属性を無視してただのscriptとして実行します。また、ESMに対応しているブラウザは、この属性がある場合、この行を無視します。

実装状況

f:id:about_hiroppy:20190427192502p:plain

IE以外はサポートされています。

ただ、現状はパフォーマンス的にもバンドルするべきです。

ESM

import defaultExport from 'module-name';
import * as name from 'module-name1';
import { name } from 'module-name2';
import { export as alias } from 'module-name';
import 'module-name';

export { name as name2 };
export let name1 = '1', name2 = '2';
export function FunctionName() {}
export class ClassName {}

(async () => {
  const { default: foo } = await import('module-name3');
})();

多くの人がすでに使っていると思います。

特徴

  • import / export はトップレベルのみでしか宣言できない
    • これにより実行前にエラーを発見することが可能です
    • もし非同期で取得したい場合は、dynamic importを使ってください
  • import はhoistingされる
    • どこに書いても宣言がモジュールの最初で行われます
    • これは関数と同じ挙動です
  • トップレベルのthisundefinedになる
  • モジュールはstrict modeになる

ESM in Node.js

現在は、stability:1(実験的)のフェイズに存在します。

なぜ時間がかかったのか?

Node.jsには2つのブラウザにはない大きな問題がありました。

  • 読み込むときにtypeみたいな属性がつけれないので、読み込まれるファイルがESMなのかCJSなのかわからない
  • すでにCJSというモジュールシステムがNode.jsには存在する
    • 互換を維持しなければならない

どのようにNode.jsではESMとCJSを判断し解決するか?

.mjs ?

多くの人は過去にこのファイル名を聞いたことがあるでしょう。
たしかに、拡張子で判断することは簡単です。.mjsであればそのファイルはESMで書かれているということです。

しかし、今後、ESMがデファクトスタンダードになることは容易に想像でき、.mjsという拡張子にしていくことが本当にいいかというと疑問です。
我々はできれば、.jsという拡張子を変えたくありません。(また、この問題はフロントエンドにも影響します。)

そこで我々は別の解決策を模索しました。

Package Mode

詳しくは以下の記事をみてください。

blog.hiroppy.me

blog.hiroppy.me

f:id:about_hiroppy:20190427185658p:plain

一言で言うと、一番近くの親のpackage.jsonによってファイルのモジュールシステムが確定します。

/**
├── esm
│   ├── cjs
│   │   ├── index.js
│   │   └── package.json (commonjs is used because type is not specified)
│   └── index.js
├── package.json (type: module)
└── root.js
 */
// ./root.js ----------------------------------------------------------------- 1
import './esm/index.js';
import './esm/cjs/index.js';
console.log('root.js          :', typeof module !== 'undefined' ? 'cjs' : 'esm'); 

// ./esm/index.js ------------------------------------------------------------ 2
// Refers to the closest parent's package.json.
console.log('esm/index.js    :', typeof module !== 'undefined' ? 'cjs' : 'esm');

// ./esm/cjs/index.js -------------------------------------------------------- 3
console.log('esm/cjs/index.js:', typeof module !== 'undefined' ? 'cjs' : 'esm');
$ node --experimental-modules root.js
esm/index.js    : esm # 2
esm/cjs/index.js: cjs # 3
root.js         : esm # 1
package.json
{
  "type": "module" // or `commonjs`, the default is `commonjs`
}

破壊的変更になるため、デフォルトはcommonjsとなります。
ESMとして動かしたい場合は、moduleを指定する必要があります。

typeというキー名は変わる可能性があり、現在議論中です。

github.com

この解決方法は、すでにNode.jsのコアに入っているため変わることはないと思います。
しかし、プロパティ名等は変わる可能性が高いです。

.mjs.cjs

さて、このルールはすべてのファイルに適応されます。
しかし、特定ファイルだけこのルールの対象にしたくない場合があります。
その時は、拡張子をしてしてください。(.jsはこのルールに準拠します)

// always read as CJS
import './file.cjs';

// always read as ESM
import './file.mjs';

ルール

WHATWG URLに準拠する

import './foo.js';
import 'file:///xxxx/foo.js';

// dynamic import
(async () => {
  const baseURL = new URL('file://');
  baseURL.pathname = `${process.cwd()}/foo.js`;

  const foo = await import(baseURL);

  console.log(foo); // [Module] { default: 'hello' }
})();

相対パス絶対パス、パッケージ名、fileプロトコルの指定が可能です。

使用できない変数

以下の変数は、CJSでは使えますが、ESMでは使えません。

// The following variables don't exist in ESM.
console.log(typeof require);
console.log(typeof module);
console.log(typeof exports);
console.log(typeof __dirname);
console.log(typeof __filename);

そのかわりにESMでは以下の値で代用します。

// Get a path info like __dirname and __filename.
console.log(import.meta);
// [Object: null prototype] {
//   url: 'file:///Users/xxxx/index.js'
// }

// Create `require` function.
import { createRequireFromPath } from 'module';
import { fileURLToPath } from 'url';

// ./
const require = createRequireFromPath(fileURLToPath(import.meta.url));

// ./cjs/index.js
require('./cjs/index.js');

import.metaは現在、tc39のstage-3となっています。
createRequireFromPathmoduleの中に存在しており、ESM内でもrequire関数を生成することができます。

この2つにより、CJSで行えたことをESMでも行えるようにします。

明示的

CJSでは、ファイル名のindexと拡張子の.js, .node, .jsonを省略することができます。
しかし、ESMではこの仕様は存在せず、ブラウザと共通コードで動くことをNode.js側も望んでいるため、今後は省略できなくなります。

フラグは、--es-module-specifier-resolutionで、explcitnodeを持ち、デフォルトはexplicitです。
しかし、多くの存在するファイルは省略していると思うので、nodeを明示的に指定することでしょう。

// strict/index.js

import './foo/index.js'; // --es-module-specifier-resolution=explicit
import './foo'; // --es-module-specifier-resolution=node
$ node --experimental-modules --es-module-specifier-resolution=node ./strict/index.js
$ node --experimental-modules  ./strict/index.js # default is `explicit`

JavaScriptのみ

ESMはJavaScriptのみの実行を許可します。
CJSでは、JSON(.json)とnative modules(.node)が実行できましたが、ESMでは実行できません。

もし、実行したいのであれば、ESM内でmodule.createRequireFromPath()を使い、require 関数を作ることができます。

しかし、JSONだけは、--experimental-json-modulesフラグを持っています。
今現在、ブラウザのESMでもJSONを呼べるようにするプロポーザルが進んでいるからです。

github.com

CJSからESMへの呼び出しはできない

// // Reading ESM at top-level is prohibited.
// import foo from './esm/foo.js'; // invalid

// // An error occurs because the read file is written as ESM.
// // `require` expects read file as CJS
// require('./esm/foo');
//
// // export default typeof module !== 'undefined' ? 'cjs' : 'esm';
// // ^^^^^^
// // SyntaxError: Unexpected token export

console.log('root.js:', typeof module !== 'undefined' ? 'cjs' : 'esm'); // cjs

(async () => {
  const { default: foo } = await import('./esm/foo.js');
  console.log('foo.js :', foo); // esm
})();

// Conclusion
// 🙆<200d>♀️ESM -> CJS
// 🙅<200d>♀️CJS -> ESM (excluding dynamic import)

このファイルはCJSで書かれています。
トップレベルでimportを呼んでも、CJSにはそのシンタックスが存在しないため、エラーとなります。
しかし、dynamic importのみは許可されています。

結論として、CJSはESMをトップレベルでは呼べないが、dynamic importを使えば、ESMを呼び出せ、ESMはCJSもESMも呼べます。

ロードマップ

  • CJS/ESMの両パッケージ対応(現在は、typeで一つしか絞れないため)
  • requireの簡潔さ(module.createRequireFromPathめんどい)
  • package path maps
  • automatic entry point module type detection

github.com

サマリー

  • 近くの親のpackage.jsontype:moduleに依存して、ファイルはESMかCJSになる
  • トップレベルではCJSはESMを呼べない
  • CJSで使えたいくつかの変数がESMでは使えない
  • フラグが外れるゴールはNode12のLTSがリリースされる2019/10の予定

サンプルコード

github.com

全文

medium.com

初めて海外で登壇してきました

概要

ダブリンのnode.js meetupでゲストとして、登壇してきました。

スライド + ノート

内容は、今後のNode.jsのESM実装に関する話です。
以下の記事に文字を書き起こししてありますので、興味あったら見てください。

medium.com

経緯

We had a look at some of your previous talks and our group would definitely love to hear from you!

Let me know if you are interested! 
Chat soon,

と突然メールが来ました。
で、蓋を開けてみるとこの人nearformの人だったんです。(メールに書いてありました)
nearformってNode.jsのコンサルをしている会社で、多分、一番Node.jsのコミッターが多く在籍していると思います。
とりあえずNode.js界隈では有名な会社です。

our group would definitely love to hear from youって文章も最高に嬉しかったんですが、nearformの人にも会えるってのが嬉しくって速攻でOKを出してしまいました。

最初は、30分 + Q&Aだったのですが、この時、次の開催までに一ヶ月ない状態だったので、20分 + Q&Aに変更してもらいました。

英語能力

登壇みたいなやつで英語で話すのは、大学の卒論以来です。
自分の大学は、卒論も英語で発表 + 質疑応答も英語でした。

二年前ぐらいに測ったときにTOEICが680点程度でした。
今現在、ダブリンで生活してますが、生活はできます。
しかし、リスニングも苦手ですし、何よりスピーキングがとても苦手です。
どんなときでも、話すときに緊張して、特に単語がめっちゃ飛ぶんですよね。(まぁ慣れだと思います)

普段は、OSSで英語を書くぐらいです。

会場

100 - 120人ぐらい来ました。
7:00PMから酒を飲んで、アフターパーティーはなかったです。
また、日本と違って、スピーチ中にほぼ誰もTwitterをやっていないのが驚きでした。

自分の弱いところ

登壇前に一回だけネイティブの人に見てもらって練習をしました。
問題点として、以下のことがわかりました。

  • 速く喋りすぎる
    • 対策として、Noteには/を入れてブレスを入れるところを明示的にした
  • lの発音が苦手
    • 日本人には難しい。。
  • 文章で強調する箇所が違う
    • Finallyとかもっと強く言ってみたいな指摘が多かった
  • standardizing の発音がくっそ苦手
    • 本当に苦手

まとめ

本番は緊張したけど、いっぱい学ぶことがあった。

多くのエンジニア仲間ができた。
nearformの方と3人知り合ったし、今度会社に遊びに行くことになった。

もっと英語の勉強をしようと思った。
あと、緊張をなくすには場数を増やすしか無いので、yosuke_furukawaさんが言ってた「一年に一回は海外で登壇する」という目標を真似てみようと思いました。

Node.jsの新しいモジュール方式の実験的導入

💁‍♀️ ブログが移管されたので,新しい方へ移動します。



Node.jsのCoreへESMとCJSの新しい方式が実験的フェイズ(stability: 1)として入ります。

ESM対応は安定化までのプランとしてステージを4つ(0 -3)用意しており、現在が2です。

github.com

2019年の10月に実験的から安定的へ移行するのが最終目標となります。(stage:3)

内容まとめ

https://github.com/nodejs/modules/blob/announcement/doc/announcement.mdgithub.com

  • --es-module-specifier-resolution=node|explicitで処理解決方法を決定する
    • explicit がデフォルト
  • --entry-type=commonjs|moduleでCJSかESMかを決定する
    • デフォルトは近しい親にあるpackage.jsontypeフィールドを参照する
  • ESMではデフォルトでjsonは読み込めない
    • --experimental-json-modulesを付ける必要がある
  • CJSとESMの違い
    • ESMの場合、拡張子が必須
    • NODE_PATHがない
    • require, exports, module.exports, __filename, __dirnameがない
    • require.extensions , require.cache の使用不可
    • URL-basedのパス指定

とりあえず、package.jsontypeフィールド追加すると、そのスコープ内の.jsファイルはそのモジュールタイプになるよって覚えておけばいいです。

ESM事前知識

以下の記事を読んでください。

blog.hiroppy.me

PR

CoreへのPR

github.com

初期提案実装

github.com

--es-module-specifier-resolution

explicitnode が存在し、デフォルトはexplicitです。

違いは以下の通りとなります。

  • 拡張子を省略することができない
  • indexを許容しない

まだ、変更される可能性が高いため注意が必要です。
今までどおりの挙動を望むのであれば、nodeを指定する必要があります。

ゾルアルゴリズム

typeフラグがmoduleの場合、package.jsonを軸に次の package.json までにネストされたフォルダとサブフォルダをすべて ESM とみなす仕様(そしてつぎpackage.jsonのフラグがmoduleの場合は続く)
もしpackage.jsonがない場合は、デフォルトでcommonjsとなります。

blog.hiroppy.me

使用法

実験的なフェイズなため、実行時に--experimental-modulesフラグが必要です。

.mjsがエントリーポイントの場合

この場合は、デフォルトでESMとして読み込みます。

node --experimental-modules index.mjs

また、上記の実行の場合、エントリーポイントからESM形式でimportするファイルは.mjsである必要があります。

しかし、--entry-typeフラグ及び、package.jsontypemoduleを指定すると、.mjsという拡張子を使うことなく、ESMとして読み込むことが可能となります。

// package.json

{
  "type": "module"
}

--entry-type

このフラグには、commonjsmoduleの2つの設定が存在します。

moduleが指定された場合、.js, .mjs, 拡張子がないファイルはESMとして呼び出されます。
この指定がない場合、デフォルトはcjsです。

$ node --experimental-modules --entry-type=module --eval \
  "import { sep } from 'path'; console.log(sep);"
/
$ node --experimental-modules --entry-type=commonjs --eval \
  "import { sep } from 'path'; console.log(sep);"

import { sep } from 'path'; console.log(sep);
       ^

SyntaxError: Unexpected token {

package.jsonのtypeフィールド

--entry-typeのpackage.jsonに書く版です。

最も近い親のpackage.jsontypeフィールドを参照し、モジュール方式を決定していきます。

一般的に今までのnode_modulesのpackage.jsontypeフィールドを持たないため、commonjsで読み込まれ互換性を保つことが期待されます。

// sample/package.json

{
  "type": "module"
}
// ./sample/index.js

// 近しいpackage.jsonのtypeがmoduleなので、このファイルはESMで読み込まれる
import './sample/setup/init.js'; 

// ./node_modules/foo/package.jsonにはtypeが書いてないため、CJSで読み込まれる
import 'foo';

特定ファイルのモジュール形式をロックしたい場合

ユーザーが表現できる拡張子は、.js, .mjs, .cjsとなります。
type: module|commonjs以下では、.jsはそれに従います。

つまり、特定のファイルに対して拡張子で操作することになります。

  • type:module 以下でcommonjsとして扱いたいファイルに対しては、.cjsの拡張子にする
  • type:commonjs以下でesmとして扱いたいファイルに対しては、.mjsの拡張子にする
// 常にcommonjsとして読み込む
import './legacy-file.cjs';

// 常にesmとして読み込む
import 'commonjs-package/src/index.mjs';

OSSで報酬が支給された話

[追記]
無事、税理士さんと相談して支払いを完了しました🎉

f:id:about_hiroppy:20190329163527p:plain

opencollective.com

また、よければ私をサポートしてください🙏

www.patreon.com

以下、編集前の記事


注意: あくまでもこれはwebpackの話です

2月分のOSS活動費

2月分のOSS活動費が以下の額で支給されます。

$1674(186,620.87円)

Total: $2093(233,331.83円)

現状の自分について

今年からwebpackに復帰しました。(以前活動してた時はまだopenCollective に参加してない)

そして、本業の他に個人事業主をやっていますが、今は税理士がいません。
日本では他の会社のお仕事もしているため、毎月ごとに請求書を書いて提出しています。

今回の問題点

海外に対する請求書の書き方がわからない!!

法的請求書でないといけないと言われているのですが、一体それは何を書けばいいんだって感じで悩んでいます。

多分、日本で提出している請求書ではダメそうだよなぁとか思ったりしています。

また、税処理周り等もわからないため、法律等に詳しい人が必要となりました。

そして、今、自分はアイルランドに在住しており、日本にはいないため、税理士さんや法律家さんを探すのが大変です。
またこの処理は25日以内に行わないといけないため、今回は柔軟に対応できず受け取らないかもしれません。
しかし、受け取らないのは今回だけにしたいので、今のうちに海外でのお金周りの扱いを理解しておきたいと思っています。

記事を書いた目的

OSSでもお金を稼ぐことができる という事実を多くの人に知ってもらえたら幸いだと思いますし、これで貢献に対してモチベーションを見出してくれる方がいればさらに嬉しい限りです。

関連記事

blog.hiroppy.me

また、日本人でopenCollectiveの配給を受けている人がいれば話してみたいと思っていてそのために書いています。(が、自分はしらない)

仕事としてOSS活動を行う場合

会社の時間を使って仕事としてOSSを貢献している場合は、お金は出ません。
その場合は、会社に対して社会的影響を与えるものを受け取ることができます(曖昧な表現にしているのは、自分は実際に仕事でossを行っておらずわからないため)

自分は、OSSを専務するエンジニアが会社にいても実際、意味はあると思っていますし、そういう会社が増えてくれることを切実に願います。

現状の自分は、webpack以外にも様々なOSSをメンテナンスしたりしています。
以下のツイートが全てで自分はそろそろ時間が足りなくなってきています。

寄付

我々はここでメンテナに対し資金を使い配給しています。
もし、応援してくれる方や会社があれば、寄付してくれると本当に嬉しいです。

opencollective.com

また、今年も去年に引き続きGoogle Summer of Codeの参加をします。

ja.wikipedia.org

summerofcode.withgoogle.com

個人に対する寄付

Patoreonをはじめましたので、もし私個人を応援してくださる方がいたらこちらでお願いします。

www.patreon.com

OSSをやるモチベーションの支えになります。

さいごに

今後も自分はこのように収入を得ていくでしょう。
このような人をサポートしてくれる会社や個人がいてくれると本当に助かります。
また、このような収入スタイルを確立していく人が増えていくことを望んでいます。

もし、自分の悩みを解決してくれる法律に詳しい方?や税理士の方を知っている人がいれば、連絡(紹介)ください!!
次は資金を得たいので助けてほしいです。。

Twitter の常にDMは開いています。(site: https://hiroppy.me/)

よろしくおねがいします。

OSSの現状と今後

Gatsbyが面白い仕組みを導入していて、驚いたので書くことにしました。

Gatsby

React.jsの静的サイトジェネレーター

github.com

最近、海外ではとても流行っています。

コミュニティ

最近、gatsbyのメンテナチームに所属しました。

f:id:about_hiroppy:20190228075105p:plain

人数が異常ですよね、このチームに所属しているとgatsbyjs/gatsbyのwrite権限を持ちます。

そう、個人的に画期的だと思った仕組みは、メンバーの招待です。
1つPRを出し、マージされるとwrite権限がもらえます。

f:id:about_hiroppy:20190228075357p:plain

githubは、adminとwriteとreadがあり、pushができるのはwrite以上です。
なので、issueのcloseやlabel, prのreview、merge等が行えるようになります。

このように多くの参加者に権限を与えることにより継続的にメンテさせるのは賢いと自分は感動しました。

危険?

最初、自分は人を信用しすぎじゃない?って思いました。

しかし、githubにはcode ownerという仕組みがあり、必ず登録された人を通さないとマージしないようにする仕組みがあります。

f:id:about_hiroppy:20190228074751p:plain

github.blog

なので、ある程度安全が担保できるとは思いますし、そもそも変な人はPRを出す可能性が低いので少しは安心できるかなと思います。

どれだけアクティブか?

大体メールが120通ぐらい1日に来ます。NodeのCoreで70通ぐらいです。
毎日、大量のPRが来て議論をし、マージをしていくため自然と多くなります。

insightsの結果は以下の通り。

f:id:about_hiroppy:20190228080749p:plainf:id:about_hiroppy:20190228080801p:plain

Node Coreがこれぐらい

f:id:about_hiroppy:20190228080910p:plain

GitHubが一年に一回公開しているThe State of the Octoverseでも以下のように言われています。

React-based web development tools like Gatsby are both among the fastest growing topics this year.

2018年では急成長するトピックの5位にgatsbyがいて、来年は更に伸びることが容易に想像できます。

f:id:about_hiroppy:20190228081400p:plain

octoverse.github.com

ここまで人気でアクティブな理由としての1つの要因がこの仕組みじゃないかなと思っています。

現状

さて、自分が所属するOSSの多くはメンテナ不足が問題視されます。(自分の中では)

例えば、webpackを例にとってみます。
現状、webpackであればauthorであるsokra氏が中心で動いており、webpack-dev-server等は自分とevilebottnawi氏で管理しています。(もちろんwebpackの手伝いはするが...)
loader系のメンテナは0のところがありました。

Mark mocha@6 compatibility and upgrade all dependencies by AviVahl · Pull Request #76 · webpack-contrib/mocha-loader · GitHub

上がってくるissueやprの量が多く一日に捌ききれる数は限られます。
大体、webpack以外のを含め自分宛にくるのが1日20件ぐらいで、1日3時間近くを費やしていますが、修正のコードを書いたりするので全部を見ることが難しいです。
また、毎日活動できるわけではないためマージすることができない日もあります。
自分はOSSを義務にしたくないと思っていますが、最近、義務感がありどうにかしたいなと思っています。

どれだけ規模が大きいOSSでも、アクティブメンテナは基本的に不足しています。
なぜこれでも成り立つかというと、成熟したコミュニティがあり、その人達にissueの回答やPRの作成を助けてもらっているからだと思っています。

しかし、結局レビューしてマージできる人間はごく少量に限られるためその人はほぼ毎日活動しなくてはなりません。

これは、webpackだけの話ではなく他の大規模なOSSでも起こっています。
当たり前ですが、自分がずっとアクティブとは限らないため、常に我々も次のメンテナを探さなければいけませんが、会社の採用よりも難しいと思っています。
リクルートみたいなシステムが無いですし、PRを出すこと自体が難易度高いと思うし、そもそも仕事ではないので継続や教育がないことが多いです。

なので、今回のgatsbyの仕組みには驚きましたし、これぐらい潔くwriteを渡したほうが冗長的でいいんじゃないかなって思います。

まとめ

OSSでは、コミュニティやエコシステムや翻訳等もですが、メンテナのアクティブさも重要視されることかと思います。

大切なことは継続的なメンテナの確保であり、それが難しいのは事実です。

いつの日もOSSというのは、メンテナ不足であり、そこからどう活発にし、生かしていくかの戦略としてgatsbyの仕組みはアクティブになる人を生みやすく正しい戦略だと感じ自分は感動したので記事にしました。