概要

個人開発関連の記事を移行し、

個人開発や個人事業として行っている内容関連の技術記事
を、
Rapid-epsilon.com　（仮）
へと移行することを考えています。
また、その延長として、
それをプラットフォームへと昇華できないかと考えています。

また、このrapid-epsilonというサービス名に込めた思いに関して下に書き下していきます。
（noteにもあとでまとめようと思っています。）

これまでいろいろ記事を投稿してきたものの、、？

これまで、秘密計算に関して（特にその中でも準同型暗号について）
記事をたくさん書いてきました。
かなり拙い記事も多かったですし、説明能力があまりなく、伝わりにくい記事となってしまったものも
多かったように思います。
しかしながら、（かなりたまにですが）数人の人に技術ブログ記事を褒めていただいたり、
コメントをもらって質問を受けたりと反応をいただけたことが数回あり、とても嬉しかったのを覚えています。

もちろん秘密計算に関しては、EAGLYS株式会社のエンジニアとして今後とも今以上にキャッチアップし、少しでもキータにアウトプットしていきたいと考えています。

その一方で、最近は個人開発や、個人事業として秘密計算以外のことにも自分の時間を使うことが多くなり、
そこで得たエンジニアリングの技術であったり、リサーチで得た知見、考えたことなどのアウトプット先として、
別のアカウント、もしくは媒体に分けようか、と考えるようになりました。

たとえば技術記事とは関係のない内容については、
今年に入ってからnoteで、日頃考えたことなどを数記事投稿したりしました。
そちらには主にスタートアップ企業に４年ほど携わって変わってきた考え方などを書いていますので、
もし覗いてみてもいいかなと思ってくれる人がいたら、ぜひみてみてください。
https://note.com/kenmaro

目指すプラットフォーム

エンジアリングの記事について、とりわけ実装関連の記事というのは多く存在していますが、
私が感じるそれらの記事の問題点などについて言及した後、どのようなプラットフォームを目指したいのかを書いていきたいと思います。

無数のプロトタイプが集まる場所

一言で言うと、個人開発、個人事業関連でプロトタイプを作った際のアウトプット先として情報が蓄積していくような場所にしたいと考えています。
また、ハッカソンに参加するときは、必ず最初にチェックするプラットフォームになれたらとても価値があるのではないかと思っています。

Rapid Epsilon という名前について

まず初めに、Rapid-epsilonという名前にした思いをスタートアップでの経験や、個人開発などを通して学んだことから綴りたいと思います。
スタートアップや個人開発を行った数年間は、高速にプロトタイプを作る大切さや難しさなどについて考えさせられた数年間でした。

このあたりは
https://note.com/kenmaro/n/n513ee6972ff5
この記事の（もしダメになったら壊して作り直せばいいこと）で少し言及しました。

高速に実験を繰り返す

作っては壊し、作っては壊す
という開発の仕方が今の自分の考え方にはあっています。
上記事にも書きましたが、もちろんシステムとして設計をきちんと行い、丁寧に作ることのできるスキルというのももちろん大事だという前提での話です。
このような開発手法をRapid prototyping と読んだりしますが、そこから「Rapid」という単語を持ってきました。

微小でもいいから作り上げて、世の中に変化を与えてみる

Epsilon については、個人開発としてモバイルアプリ「Yorimichi」を
iOS, android アプリとして合計半年ほどかけて開発し、リリースを行ったと言う経験から選んだ言葉です。
この開発体験（iOS版の開発体験記）は、
https://qiita.com/kenmaro/items/149417e96c82e6ebe541
ここに書きました。（このあとのAndroid版も記事を執筆中です。）

Yorimichiは日本語の寄り道をそのままアプリ名にしたのですが、
このアプリが目指すこととして、誰かの寄り道に再現性を持たせ、他の誰かの寄り道の手助けをしたいと考えています。

寄り道というのは、今のルーティンと少しだけ違うことを生活に取り入れ、小さな挑戦をやってみる、ことを行動に移したものです。
何気ない寄り道先で新しいお店を発見したり、新しい出会いがあったり、少しだけリフレッシュになって明日少しだけもっと頑張れたり、
いつものルーティンにちょっとした違いを加えていき、もっと冒険してみたら少しだけハッピーになれるのでは、という願いが込められています。

イプシロンは、数学においては微小な数を表すことが多いです。
そういった意味で、この少しだけの「寄り道」によって、人生に「ε」（イプシロンと呼びます）を加えていけたらいいな、
という思いからこの「イプシロン」という言葉をチョイスしました。

個人開発において（企業での開発はもちろん考え方が違いますが）、このようなRapid Prototyping を行い、自身の経験に小さな「ε」を加えていくことで、
エンジニアリングが好きになったり、自分のアイディアをプロダクト化して現実で実際につかってもらう、
そのような開発をしたいエンジニアの方達に少しでもプラスになるようなブログの運用ができたらと思っています。

高速なプロトタイプの構築を支援する３つの大きなフィーチャー

その意味で、このブログは「高速なプロトタイプの構築を支援する」ということを一番の目標として運営していきたいと思っています。
それを実現するために、以下のフィーチャを持ったブログにしていきたいと思っています。

プラットフォームのコンテンツは、小さな機能、大きなプロダクト内容問わず、実装したもののを再現可能な記事にすること
記事を読んで実装を再現するときにかかる時間を明記すること
開発者が記事を編集できるようにすること（編集リクエストではなく、forkの形をとる。）

それぞれのポイントについて詳細に解説します。

1. ブログのコンテンツは、小さな機能、大きなプロダクト内容問わず、実装したもののを再現可能な記事にすること

まず、コンテンツはその記事のオーナーが行った実装を、閲覧者がもれなく再現できることを重視します。
したがって、プラットフォームに投稿されるジャンルは「xxxxを実装してみた」というような記事を想定しています。
ここで、「再現可能」という言葉を使ったことには理由があります。
ディベロッパーの方であれば大きく理解していただけると思いますが、何か機能やプロダクトを実装を行おうとしたとき、
現在以下のような問題点があると考えています。

再現できるかどうかそもそもわからない

記事が古かったり、全てのコードや手順が書かれていないと言う理由で、
実装を追う際にエラーなどが発生、コンパイルできない、などが発生し、実装を再現する前に他の手法を試すという決断を行うことになることはしばしばです。
これはディベロッパーとしては非常にフラストレーションの溜まる状況です。
アイディアをサクッと試してみたいときに、良さげな記事を見つけて検証を行うときに想定よりも大量に時間を投下することになり、モチベーションと体力が削られてしまうからです。
この意味で、記事には実際に再現した人の数や、スムーズにいった件数などを可視化（いいね数や、LGTM数のようなものを想定）
し、数ある実装記事の中で優先的に試すべき記事がわかりやすいようにできればと思っています。

2.記事を読んで実装を再現するときにかかる時間を明記すること

実装を試してみたいと考えたときに、いろいろな記事を調査することになりますが、

再現にどのくらい時間がかかるのか、実装してみないと把握できない
というような問題点を実感することが多いです。

よくまとまっている記事を発見し、これを実際にやってみよう、と考えたときに、どのくらいの時間が実装時間にかかるのかを記事から把握することは困難です。
その分野に精通しているのであればある程度あたりをつけることができるかもしれませんが、多くの場合は自分のあまり知らない分野、使ったことのないライブラリを活用することがほとんどですので、実質的にかかる時間を事前に判断するのは困難になります。
ハッカソンなどを想定すると、限られた時間の中でどのようなライブラリや実装方法を使うべきか、と考えるときに実装時間がどのくらいか想定することは非常に大事です。
一般の技術ブログでは、実装時間を想定することは閲覧者に委ねられますが、
Rapid-epsilon.com　では、記事に実際にかかった実装時間を記事のオーナーに記載してもらい、大きな記事であればそれぞれのフィーチャーに対してどのくらいの時間で実装可能だったのかということを簡単にわかるようなUIを作りたいと思っています。
それにより、閲覧者はあらかじめどのくらいの時間をかければこの記事の内容を再現できるのか、と把握することができ、実装を行うのかもしくは他の手法を試すのか選択できるようになると考えています。

3.開発者が記事を編集できるようにすること（編集リクエストではなく、forkの形をとる。）

仮に記事が未完成の状態であったり、書いてあることを実装したのにエラーが出るため記事の内容を修正した方がいいと思われるとき、
基本的にコメントなどで記事のオーナーに修正を依頼したり、編集リクエストが機能として実装されていることもあります。

しかしながら、オーナーが編集をきちんと行ってくれるかはオーナー自身の判断に任されており、あまり修正リクエストが反映されないような仕組みになっている気がしています。

結果として、記事の質が書かれた時点より上がることは基本的にはありません。
というよりも、記事の質は時と共に下がっていきます。
理由はその記事が使用したライブラリや周辺知識などは時と共に古くなっていくので、実装を行うときにそもそもライブラリの仕様が変わっていたり互換性がなかったりする可能性があるからです。
基本的になにかを実装しようとして参照する記事は、３年以上前の記事だと敬遠するような風潮があると思います。

このように、ディベロッパーが記事に書いてあるステップに沿って実行しエラーなどに遭遇し、解決するための記事を見つけに行って想定外の時間を使ってしまうことを解決したいと考えています。

そのためには、記事がより完成度の高いものであり、日々アクティブに更新されている必要があります。
そこで、その更新にかかる労力を記事のオーナーの仕事にするのではなく、だれもが簡単に記事を更新できるようなプラトフォームにしたいと考えています。
それにより、実装をやってみた人たちの気づきなどが加味されて記事が更新されていき、より再現性の確度が高い記事がメンテナンス可能になると考えています。

GitHub のようなfork機能を採用することで、編集リクエストを送りオーナーに編集を一任するのではなく、forkした記事の管理は自分の権限で行えるため、記事の編集が簡単になります。また、これによりオーナーの貢献度が下がるかと言われればそうではなく、記事の変更履歴はたどることでオーナーがもともとの記事を書いたことはわかるため、オーナーの記事に対するそもそもの大きな貢献度も担保されます。

また、２で記載した実装時間に対するフィードバックも閲覧者が実行可能にすることで、より一般的にかかる実装時間が共有されることでしょう。
（たとえば、非常に技術力の高い人が記事のオーナーであり、彼であれば３時間で完了する実装であるが、他の人がやると平均して５時間くらいかかっている、など）

初めから世界中で使われるサービスになることを想定する

ハッカソンやRapid-Prototyping は世界中で盛んに行われているため、
参加者や興味のある人がまず訪れるプラットフォームとして、初めから英語ベースでのプラットフォームとして構築することを考えています。