自分だけの仮想通貨発行・ハンズオンを開催しました 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


オープンソースのJavascriptプロジェクト 5選 [12/21~12/27]

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

No.1

Chalarangelo / 30-seconds-of-code

f:id:junp0819:20171227174917p:plain
30秒以内に理解できる有用なJavascriptスニペットの整理されたコレクション。
Star:12,556🌟
github.com

No.2

danilowoz / react-content-loader

f:id:junp0819:20171227174926j:plain
SVGを使用して、Facebookカードローダーと同様にロードされるコンテンツの構造をシミュレートするローダーのコレクションを作成するコンポーネントを使用します。
Star:2,637🌟
github.com

No.3

parcel-bundler / parcel

f:id:junp0819:20171227175024g:plain
急速にWebアプリケーションバンドラの設定をする
Star: 13,267🌟
github.com

No.4

google / boardgame.io

f:id:junp0819:20171227175305p:plain
状態管理など、ターンベースのゲームにも適しています。
Star:4,580🌟
github.com

No.5

facebook / Docusaurus

f:id:junp0819:20171227175338p:plain
オープンソースのドキュメンテーションWebサイトを簡単に管理できます。
Star:2,860🌟
github.com