DEV Community: aggre

“Dev” - Tokens for your OSS sustainability

aggre — Sun, 05 Aug 2018 03:45:46 +0000

We have released “Dev” tokens in order to support the sustainability of Open
Source Software (OSS).

What is “Dev”?

“Dev” works to achieve fair monetization of your OSS.

Neither commission fees nor usage fees are required.

Utilizing the token economy allows developers to concentrate on development, and
investors to effectively support any OSS.

For the most part, OSS are provided free of charge. OSS developers maintain
their OSS projects by securing a revenue source separate from their OSS.

Typical sources of revenue are as follows.

Working at a company
Freelancing
Donations
OSS provided as SaaS
Enterprise support

Since [1] and [2] are not revenue produced by the OSS itself, the OSS is only
allocated a limited amount of their disposable time.

The revenue of [3] tends to be an amount that deviates from the value of their
OSS due to the arbitrary model of high evaluations. OSS developers are required
to focus their efforts on fields other than just technology so that they can
continue to raise their evaluations.

[4] and [5] essentially achieve monetization directly from the OSS, but this can
be done only with a few limited large-scale projects.

“Dev” works to realizes revenue proportional to the real value of the OSS. In
addition, it does not require changes to the OSS itself. With this
loosely-coupled system, we evaluate the OSS with simple and powerful evaluation
logic and actualize monetization according to that evaluation.

How “Dev” works

To begin, it can be depicted in a simple diagram.

“Dev” is created based on the ecosystem of Ethereum. It is easy to understand if
one has an understanding of block chains, but it doesn’t matter even if they
don’t.

“Dev” can be traded on the market like Ethereum or Bitcoin. Since “Dev” conforms
to the Ethereum standard (ERC20), the price of 1 DEV is determined by the rate
between 1 DEV and 1 ETH.

The outline is as follows.

The price is determined by investors trading “Dev” (updated in real time)
devtoken.rocks mints “Dev” every month
The increase by devtoken.rocks is allocated to the OSS

OSS developers can liquidate their “Dev” by exchanging their “Dev” for Ethereum.

As “Dev” is a token that continues to mint, there is a mechanism to suppress the
dilution of the value of “Dev” itself. This involves evaluation logic.

Evaluation logic for “Dev”

The following variables are used in calculations to determine allocation to the
OSS:

pdl = Number of downloads of the package (OSS) from the 20th day of the last month to the 19th day of the current month
adl = Number of downloads of all packages (OSS) from the 20th day of the last month to the 19th day of the current month
t = Number of tokens retained by the distribution address
d = Number of days elapsed since the OSS registration
p = t / d
ta = Total of p for all addresses
m = Annual number of mints

The calculation formula is as follows.

x = (p + pdl) / (ta + adl) × m / 12

The per-diem rate of “Dev” tokens retained by that OSS is added to the number of
OSS downloads. The same equation is calculated for each OSS individually and all
OSS total, and the ratio is determined for each OSS.

The number of allocations is determined by multiplying the monthly number of
mints by that percentage.

The number of tokens retained by the OSS are added to suppress dilution of the
value of “Dev.”

The more tokens possessed by an OSS, the more tokens will be allocated each
month. In other words, you can increase the number of shares by purchasing or
saving tokens. This will prevent tokens from being sold all at once and suddenly
diluting the value. Investors don’t want the value of the token to be diluted.

As an application of this mechanism, if you send “Dev” tokens to the OSS you
want to support, you can increase the number of token allocations to that OSS.

The calculation logic is available for viewing on GitHub
(frame00/dev-distribution).

Future plans to distribute to contributors

“Dev” is currently in alpha. Tokens are distributed to the owner of the OSS.

We want to implement the ability to distribute tokens to OSS contributors.
Contributors would be able to receive compensation relative to their
contribution.

With active use of “Dev,” we would be able to proceed to advance functional
development as soon as possible.

How to connect with “Dev”

There are a number of ways to get involved in the OSS community for “Dev”.

I want to monetize my OSS

If you are self-publishing your OSS, you can begin to achieve monetization by
registering your OSS on devtoken.rocks.

Registration is quick and easy, and there is no need to make any changes to your
OSS.

As it is currently in alpha, only OSS that are published in npm can be
registered.

I want to support OSS

You can contribute to an OSS by using “Dev” tokens.

“Dev” can be contribute efficiently in order to realize a world where OSS are
more actively developed.

Order Book can be opened from devtoken.rocks to buy
and sell “Dev.” EtherDelta is used for main exchanges.

There is an OSS that I want to directly support

If the OSS that you want to support is registered in “Dev,” you can send “Dev”
directly to the wallet address of the OSS.

If the number of tokens retained by the OSS increases, it increases the amount
of monthly distributions made to that OSS. In this way, you can provide
continuous support even without making a new contribution every month.

Refer to GitHub
(frame00/dev-distribution) to
check the wallet address of the OSS. OSS information is stored in
config/packages.ts.

Growth of “Dev” is accelerated through active use by OSS developers and
investors.

For questions please contact us on
Twitter. Inquiries can be made in either
Japanese or English.

This article was originally posted on Medium.

Read the original article here.

PRPL パターンから非 SPA のパフォーマンスを考えたときのメモ

aggre — Mon, 27 Nov 2017 09:27:38 +0000

SPA ではない構成のウェブアプリでパフォーマンスを出すための施策を、PRPL パターンを発想の起点にして考えてみた。

動機

JavaScript によるコンポーネントベースの開発はフロントエンドの実装を効率的にした。

しかし toC のサービスにおいて、Bot フレンドリーであるための施策が重荷になっている。<meta> タグだけサーバー側で作っておく対策もあるが、Pocket や未知のサービスも含めると本文が必要なケースは依然として多い。個人的には、SPA をいくつかリリースしていく中で、ドキュメントとしての HTML なのにスクリプトを実行しないとドキュメントにならないことへの違和感も感じていた。

そこでドキュメントとして成立するための最小限の要素だけをサーバー側で生成することで、Bot 施策の回避を考えた。

SPA を保ったままで ドキュメントとして成立した HTML を扱うためには密結合な構成か SSR の要件が出てくるという判断に至り、SPA を廃止することにした。

SPA ではなくても、ドキュメント向けの要素以外は Web Components として引き続き開発できる。

その上でパフォーマンスを向上させるための施策を検討した。

施策

PRPL パターンを起点に考えた施策は次のとおり。

Push

HTTP/2 の Push はブラウザのキャッシュを考慮することが現状難しいため対応を保留する。

Endpoint

例として /page/1 へのリクエストで、次のような HTML を返却する。

<!DOCTYPE html>
<html lang="en-US" dir="ltr">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1,user-scalable=yes">
    <title>Page 1</title>

    <!-- Preload CSS -->
    <link rel="preload" as="style" href="/style.css" onload="this.rel='stylesheet'">

    <!-- Preload critical Custom Element -->
    <link rel="preload" as="script" href="/x-header.js" onload="var s = document.createElement('script');
    s.src = this.href;
    document.body.appendChild(s);">

    <!-- Preload service worker -->
    <link rel="preload" as="script" href="/service-worker.js">

    <!-- Preload lazy load script -->
    <link rel="preload" as="script" href="/lazy-load.js" onload="var s = document.createElement('script');
    s.src = this.href;
    document.body.appendChild(s);">

    <!-- Prefetch next page -->
    <link rel="prefetch" href="/page/2">

    <!-- Prefetch home page -->
    <link rel="prefetch" href="/">

    <link rel="manifest" href="/manifest.json">
</head>
<body>
    <!-- Custom Element for header -->
    <x-header></x-header>

    <main>
        <article>
            <section>
                <h1>Title</h1>
                <p>The content</p>
                <p>

                    <!-- Custom Element for article -->
                    <x-content-gallery lazy-load="/x-content-gallery.js"></x-content-gallery>

                </p>
                <p><a href="/page/2">Next</a></p>
            </section>
        <article>
    </main>

    <!-- Custom Element for footer -->
    <x-footer lazy-load="/x-footer.js"></x-footer>

    <script async defer src="/polyfill-of-preload.js"></script>
    <script>
        // Add a service worker
        'serviceWorker'in navigator&&window.addEventListener('load',function(){navigator.serviceWorker.register('/service-worker.js')});
    </script>
</body>
</html>

クリティカルなリソースの preload と、遷移する可能性のあるページの prefetch を行なう。

lazy-load 属性が追加されている要素は、その要素がビューポート内に出現した時点で依存解決をする。この属性名は仮なのと、ビューポートに出現した時点では UX を損なうリスクもあるため工夫は必要。

Render

HTML をレンダリングする。

SPA ではないので異なるルートのための処理は必要ない。

Pre-cache

SPA ではないことから、Service Worker による事前キャッシュ( Pre-cache )は行わない。

Service Worker は通信発生時のキャッシュや通知などの用途に限定される。

Lazy-load

SPA ではないことから、PRPL パターンにおける Lazy-load とは少し趣が違う。

PRPL パターンでは異なるルートのためのリソースを遅延読込することと、画像などのリソースがビューポートに現れるときに遅延読込するというアプローチがとられると理解している。

今回は SPA ではないため、異なるルートのための遅延読込は考慮しない。

アーキテクチャ

データソースは REST API で取得できるようにしておく。

その上でローカルとサーバーをなるべく近い構成にすることを考えると、HTML の配信は Node.js などで立てたサーバーをそのままクラウドでも走らせたい。

この場合、REST API はサーバーレスに構築できるが、HTML はサーバーレスでは構築しづらくなる。

しかしデータソースが REST API なら HTML はステートレスに返却可能なので、CDN によるキャッシュが有効に機能するはず。

早い段階でこの構成を実戦投入してみたい。