Vue.jsからReact.js村に旅行する話

注意: これはポエムです

この記事はCPS Lab Advent Calendar 2017 2日目の記事です。

緑髪でB3のスポーンです。僕は家が茨城県にあって、大学まで通っているのでバイトで帰りが遅くなったときはラボの伝統を継承して残留しています。

「残留」と聞いてラボに入るまでは、夜中遅くまで研究を強いられているのかな?とビクビクしていましたが、実際は合宿のような感じで先輩や同期とワイワイたのしくやっています。

さて、今回は普段Vue.jsを使ってる僕がReact.js+TypeScriptを始めたのでVue.jsとの違いも含めてポエムを書いていこうと思います。 Vue.jsもReact.jsも初学者なので見当違いなところがあればコメント等でご指摘いただけると助かります。

CLI

昨今の複雑化したフロントエンド環境において、環境構築を一発でできるCLIツールはなくてはならない存在です。 Vue.jsのCLIvue-cliを使っていました。vue init webpack アプリ名を叩くだけでモダンな開発環境が手に入るのはお手頃と言えます。

React.jsの場合はcreate-react-appを使いました。個人的に良いなと思ったのは、scaffoldの際にオプションの--scripts-version=react-scripts-tsを付けるだけでTypeScriptのプロジェクトになることです。Vue.jsの場合はTypeScriptのボイラープレートを見つけてくるのが結構めんどくさかったので、これは本質的な2つの違いではありませんが、感動しました。

コンポーネント

Vue.jsでは単一ファイルコンポーネントとして.vueファイルがあり、HTML, JS, CSSを一つに書いていくスタイルが一般的です。 React.jsでは基本的にJavaScriptで、render()メソッドの中にHTMLを書いていきます。 最初は慣れなくて気持ち悪いと感じましたが、慣れてくるとコンポーネントは単純なメソッドの集合と考えられるので、ユニットテストする際はこっちのほうが恩恵を受けやすそうだなと思いました。

Vue.jsはVueインスタンス内に、methodsや状態であるdataを持ちオブジェクトの中にどんどん書いていくので個人的に見通しが悪いように感じます。

イベントハンドラと状態

これは自分のVueでの設計の悪さが問題かもしれませんが、React.jsではStateやEventを引数で取ってそれをハンドルして戻り値で渡してあげるのが一般的なようです。 Vue.jsよりも記述量が増えてやや複雑に感じる部分もありますが、疎結合になるのは、やはりテストのしやすさという面でも良いなと思いました。

ディレクティブ

Vue.jsにはv-forなどのディレクティブがありますが、React.jsではHTMLタグをfor文で回すような記述をするようです。 やはりVue.jsのディレクティブに慣れているので、便利なv-forv-ifを使えずにfor文や三項演算子で書いていくスタイルは少し泥臭く感じました。

まとめ

React.jsを書き始めて一週間くらいですが、色々とVue.jsとの違いに戸惑いながらも新鮮な気持ちで書いています。 前述の通りコンポーネントが関数の集合なので、TypeScriptとの相性も良くPropsをinterfaceで定義できたり型のおかげで強力なサジェストが使えることで、歓喜しています。(これはTypeScriptの利点ですが...)

また、エコシステムもVue.js以上に大きいのでReactNative等色々触ってみようと思います。

P.S.

Weexはマジでクソなので絶対に触るな

mixi git challengeに行った

仮面ライダーフォーゼを見直したら面白すぎてハマっているスポーンです。

mixi主催のgit challengeに応募したら通ったので行ってきました。

git challengeとは

問題としてgitリポジトリを与えられてgit操作をしながら様々な課題を解決し、それをpushするとスコアサーバーが自動で 採点をしてくれるものです。イメージとしては競技プログラミングやCTFが近いでしょう。

二人一組でチームを組んで行いました。

問題

サンプル問題が公開されているのでそれを見ると感覚がつかめると思います。

第1回git challengeの出題内容を一部公開します

難易度が☆1〜☆6くらいまで別れていて、相方が偶数で自分が奇数で解いていき分からない問題はパスして多くの問題に目を通す方針でやっていました。

着手する問題をslackで伝えて相方とのコンフリクトが起きないようにしていました。

使ってて便利だったコマンド

  • merge --no-ff
  • add -p
  • reflog
  • commit --amend
  • rebase -i

とくに git add -pは初めて使ってかなり便利なコマンドだと思いました。

小規模なチームで開発していてノリにのって色々やった時に1コミットに複数機能の追加とかをやってしまいがちなので、 それをインタラクティブに分割できるのは快適でした。

ランチと懇親会

ランチではお好み焼きが出てきて、mixi社員の方と話をする機会をいただきました。 テストについてのこだわりや品質保証のためのテストと開発をドライブするためのテストの違い、テスト初心者へのオススメの本を教えていただいてすごく勉強になりました。

紹介していただいた本を忘れないように貼っておきます。

テスト駆動開発

テスト駆動開発

初めての自動テスト ―Webシステムのための自動テスト基礎

初めての自動テスト ―Webシステムのための自動テスト基礎

懇親会ではプレモルを飲みながら他の大学の人達や社員さんたちと美味しいケータリングを食べながら盛り上がりました。

感想

行くまではgitは使ったことあるけど複雑なことは知らない上に詰んだらとりあえずリポジトリをリセットするか卍フォースの力卍を使うことしかしていませんでしたが、 gitが爆発した時のTipsや知らないコマンドの勉強、gitオブジェクトについての理解が深まりすごく楽しかったです。

問題は相方がすごく解いてくれて5位になりました。 普段はgit発破技士などと呼ばれていますが、これを気に爆発時の対処力も鍛えたいと思います。

新卒向けのイベントなので就活をしている人にはいい機会になるし、就活とか関係なしにすごく面白いイベントなので次回開催されたときは参加することをオススメします。

最後に

mixiに行くまで僕はマキシマムザホルモンの「Kill all the 394」を聴きながら渋谷を歩いていました。

ごめんなさい

デザインについて雑なまとめ

デザインするときの考え方

業務だったりなんだりでデザインをしなければいけない時があるかと思います。 印刷物だったり、Webだったりと色々ありますが、どちらにも共通の基本的な考え方を共有しておきます。

自分は「デザイナーじゃないから無理や〜」とか「美術の成績は1だったぞオイ」みたいな色々ありますが、やる場合の大まかな流れを書いておきます。

センスがない

デザインをしたことが無い人がまずはじめに言う言葉は「自分にはセンスがない」です。 これは9割の人が言っていますし、誰もあなたにセンスがあるとは思ってません。 この記事を書いている自分すら、オタクなのでセンスが無いです。

誰も美大生のようなものを作れとは言いません。

デザインとアートは全くの別物(designとartを辞書で引いてみてください)なので、 知識をつければある程度はできるようになります。

日本の武道の世界では守破離という言葉があります。 これは人のレベルを3段階で表していて、 では師匠から教わったこと、所謂「型」を守るところからスタートします。 では、教わった「型」と自分を比べ、そこから自分に合うように研究し、型を破る段階です。 は、完全に独立し、型から離れ自由になります。

この考えはデザインにも適応できると思っています。はじめは良いデザインをたくさん見て、それを「型」に真似をしていきます。そこから自分で「これはこうしたほうが良いんじゃないか?」と考えて自分なりにアレンジしていき、最終的にはゼロから作り出せるという流れです。

参考の欄に幾つかWebデザインに関するサイトを載せておくので、EvernoteやPocketに良いなと思ったのを保存して、デザインをする際に振り返ってみると良いでしょう。

デザインの基本

そもそもデザインとは伝えたいことを、相手により伝えやすくするために行います。

単純にカッコ良いいものを作りたければ、東急ハンズに行って絵の具とキャンパスを買ってきてそれに描いてください。たぶん欲求は満たせます。

色々な情報から伝えたいことを抜粋し、それを整理することがデザインの基本です。

最も基本かつ重要なことは揃えるということです。

人がもっとも美しいと感じるのは揃っていることなので、まずはそれをしっかりとやりましょう。

よく学校や地方自治体などの資料で、文字がギチギチに詰まったスライドや、文字の大きさや揃え方がバラバラのものを目にした経験があるかと思います。

その時にどんな印象をあなたは感じたでしょうか?

「なんとなく見づらい」、「何が重要なのかよくわからない」

あれは、伝えたいことを抜粋し、整理してないからです。

整理

まず相手(ポスターやサイトを見る人)のことを考えてみましょう。

女性? 男性? 年齢は? 趣味は? デザインしたものを見る、使う時のその人の状況は?

など色々なことを考えてみます。もちろん、ターゲットが複数の層や十人十色という言葉どうりバラバラな時もありますが、大まかに意識してターゲットを絞込みます。

ターゲットを絞り込むと、相手にとって何が重要なのかが掴みやすくなりますね。 そこから伝えたい情報を整理していくと良いでしょう。

レイアウト

盛り込む情報が定まったら、配置していきましょう。

タイトルなどの重要な情報は大きく、それ以外は小さくします。

こんなことは当たり前だしわかってるわ!と思うかもしれません。 しかしやってみると、どこまで大きくすればいいのか分からずにほとんど均一なサイズになります。

ビビらずに大胆にやりましょう。

そして、重要な揃えることです。ドロー系ソフトの中央揃えや左揃えなどの他にも、文字の縦のラインを見えない一本の線にそって合わせてみたり、黄金比白銀比に合わせたりして、法則性をもたせます。

前述しましたが、世の中の素晴らしいロゴや建築物はある方則できっちりと揃っていることで美しさが評価されています。

色やフォントなどのスタイルを考える以前に、要素をそろえてください。

フォント

フォントに関してもなんとなくカッコいいフォントを使っているわけではありません。 用途に応じて大まかな種類があります。まずはそれを覚えましょう。

和文フォント

明朝

明朝体はウロコといわれるアクセントがあります。書道で書いたみたいなアレです。縦の線が太く、横の線が細くなっています。

ゴシック

線の太さが均一です。装飾がないので、視認性が高い。昔の解像度が劣悪な環境では、明朝体を使うと字が潰れて終了となり、ゴシック体がコンピュータのスタンダードでしたが、今日の解像度が高い環境では気にしなくても大丈夫でしょう。Windowsのようなフォント描画が劣悪な環境ではやはりゴシック体のほうが良いかもしれません。

欧文フォント

ブラックレタ

12世紀あたりのヨーロッパで使われていた文体です。黒い面積が多く、重厚感を表したい時に使います。

ローマン体

傾かずに垂直した文体です。古代ローマとかが起源らしいです。

サンセリフ

ウロコがない欧文フォントです。サンとはフランス語で「〜がない」という意味でセリフ(ウロコ)がないフォントという意味でサンセリフだそうです。 19世紀あたりに発明され、現代ではかなり広く使われています。

以上が大まかなフォントの分類です。

和文なら游ゴシックとヒラギノメイリオ。欧文ならHelveticaFuturaを使っておけばどうにかなるだろう、みたいなところがあります。

色彩だとかなんだとか色々ありますが、そんなものは分かりません。

https://coolors.co/

を使って一発です。

まとめ

色々と書きましたが、とにかく実際に手を動かして作ってみることが1番上達すると思います。 1分で1個とかのペースで作ってみたりするとイラレとかSketchとかAffinity Designerとかの使い方も覚えるしオススメです。

参考

デザインの際に参考になるものを書いておきます。

デザインスプリントを読んだ

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイドを読んで面白かったので、メモや実践するときの共有用として書いておきます。 流石に全部は書けないので、個人的にオッと思った箇所を抜粋してます。

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

デザインスプリント ―プロダクトを成功に導く短期集中実践ガイド

デザインスプリントとは

Googleベンチャーズとかで実施されている、サービスやプロダクトのアイディアを出して検証するビジネスフレームワークです。

「デザイン」と言う言葉がはいっていますが所謂デザイナー向けというわけではなく、 広くアイデアを継続的に出して改善していく手法です。

イデアがミーティングの場や閃いた時には「これはいける!!」と盛り上がったものの、いざリリースしたら全く使う人がいなかったということは、 サービスやプロダクト制作に関わったことのある方なら、経験したことも少なくはないでしょう。

そのまま勢いで開発してリリースした場合、多くの時間とコストを無駄にしてしまいます。

デザインスプリントでは5日間で

  • 理解
  • 発散
  • 決定
  • プロトタイプ
  • テスト

の項目について活動し、アイデアについて検証します。

僕が良いなと思ったポイントとしては、5つのフェーズに分かれているので、各フェーズに集中できるところです。 アイデアを出すところはクソなものでも出す。 評価するところでは良いと思ったものは良いと、悪いものは悪いとしっかりと評価する。 これが明確に別れていることがデザインスプリントのメリットかなと思います。

また、アイデア出しって正解が無いので悩んで時間がかかりすぎたりしますが、時間がかなりタイトなので夏休み最終日にやる宿題のような感覚で火事場のクソ力を発揮できます。

準備

デザインスプリントでは、ホワイトボードとポストイットが大活躍します。 出し惜しみせず、ガンガン使いましょう。 また、使うペンはボールペンやシャーペンだと細かく書きすぎるので、マッキー的な太いペンを使うと効果的だと思います。

理解

目的 - 背景理解 - ヒント - 課題発見 - ユーザーについて

事実と仮定

固定観念や思い込みといったバイアスを避けるために行います。

  • 事実と仮定にそれぞれポストイットに書き出す(10min)
  • 事実と仮定をグループ化する(10min)
  • もし事実に対して異論が出たら仮定グループへ移動

課題定義(20min)

  • プロダクトが行わなければいけないことは何か?
  • 何を解決するのか?
  • その動機はなんなのか?

を書き出します。

ここで重要なのは、出てきたものに対して解決法を考えたり出したりしないことです。 それは別のフェーズでやるので、ここでは課題定義に集中しましょう。

チャレンジマップ(20min)

上で出た課題に対して、何故必要か?と考えて答えを課題の周りに貼る。 その答えにも何故必要か?と問いかけて、「お金を儲けるため」みたいな原初的な回答が出るまで続けます。

Who/Doエクササイズ

ホワイトボードを縦で区切って、左に「誰が?」右に「何をする」(何をすべきか、成し遂げたいか)を書きます ここで、プロダクトのユーザが見えてきます。

発散

目的 - 解決策 - アイデア出し

一日目で出てきた課題、タスクをストーリーにします 「私は〜〜〜の時、◯◯のために☓☓したい」 と虫食いで書いて、各課題ごとに埋めていきます。

8アップ

A4の紙を横にして八つ折りし、8個のマスを作って1個30秒で埋めます。 ここでは絵でも文字でもなんでもいいのでガンガンアイデアを出していきます。

5分で8個作って、5分で説明のサイクルを2回以上やります。

ストーリーボード(20min)

右にコマ、横に説明というふうに8アップで出したアイデアから良い物を使うユーザーの背景、流れ、人の関わり方を含めてストーリーにします。 8アップで出た他の人のアイデアから作っても大丈夫です。 あとの評価のときに他の人がこれを見ても理解できるように書きます。

サイレント評価

ストーリーボードの作者は目隠しをしながら、他の人が良いと思ったストーリーボードの良いと思った箇所に丸いシールを貼ります。 これをストーリーボードの数繰り返します。

その後、製作者は人気の箇所を説明したりワイヤーフレームを作ってもう一度シールで投票します。

ここで、このサイクルをもう一度繰り返します。 アイデアを質より量で出しましょう。

決定

目的 - アイデアの収束

1万円テスト(15min)

参加者にニセのお金として、1万円分を配ってワイヤーフレームに投資します。 ここでは発散フェーズで行った投票とは全く関係ありません。 良いと思ったアイデア、箇所に投資しましょう。

ここで、理解フェーズで出た仮設に対しても解決手段や条件がないかを考慮しながら1万円テストで優先順位をつけます。

異論の儀式(20min)

1万円テストのあとに、ある程度詳細なワイヤーフレームを作ったら製作者は目を隠して異論を聞きます。 他の人はガツガツ思ったことを遠慮なく言いましょう。 ここで重要なのは、アイデアを批判するのであって人間を批判しないことです。

このサイクルを行って、2つか3つ程度までアイデアが収束したら、プロトタイプのスケッチを書きます。


プロトタイプやテストの項は省略します。 詳細は以下が詳しいです。

また、実践例ははじめてデザインスプリントをやってみたで詳しく載っています。

イデアって考えても考えても浮かばないと思っていたので、こうした手法はチーム内でのモノ作りへの意識の共有や、仮定、実験、検証を含む合理的なUX改善プロセスなどは非情に勉強になりました。

hojiroLTを作った話

この記事は「dendai sie; Advent Calendar 2016 - Adventar」21日目の記事です。

アドベントカレンダー書く書く詐欺からついに卒業です。 今回は、最近自分が作った「hojiroLT」について書いていこうと思います。

hojiroLTとは?

人格破綻者や社会性のないオタク、常識人などが集結した非公式サークルです。

月に一度、「帰ってきたhojiroLT」と称したLT会を学内限定でやっています。 千住キャンパスはセキュリティ的に外部の人が入るのが難しいので、学内限定としていますが、将来的には外部の方も呼べればなと思っています。

なんで作ったのか

千住キャンパスにはソフトウェア研究会という、ゲーム制作やCG制作、DTMなどをしている技術系の部活があります。(活動内容が違ってたらごめんなさい)

個人的に部活ほどガチで何かをやるよりは技術が好きだったりする人が集まったり集まらなかったりするサークルがほしいなと思っていました。

しかし千住キャンパスでは"サークル"というものがなく、原則部活にしなくてはいけないようです。

電機大の技術系コミュニティだと TDU FENというはるさん主催のLT会( 詳細 )や、千葉NTの学生だったみそいぬ主催のdendai sie; LT(詳細)などがありました。

自分がそこで先輩や強い同期などを知るきっかけになったり、刺激をもらったりをしたので、そういった場所を作れないかと思いhojiroLTを作りました。

LTを開催してみて

記念すべき第一回を扁桃炎で寝込んで前日に先輩に丸投げするという厄介をしてしまいました。

僕の顔写真が遺影にされたりと色々ありましたが、20人の参加者が集まってくださって成功に終わったようです。

第二回でも前回を超える参加者が集まってくださり、自分と全く接点のない方も来てくださいました。

やはり月一ペースでの開催は大変なこともありますが、前回来れなかった人も来てくれたり、一年生でもとりあえずやってみるかみたいなノリで敷居が低くなったんじゃないかなと思っています。

今後

LT会以外にもハッカソンだったり、前回僕がやったgit超初心者勉強会のような勉強会をやれたらなと思っています。 会場用意とかは僕がするので、こんな企画やりたい!というのがあれば是非僕に言ってください。

おわりに

メンバーを随時募集してるので、興味のある人は気軽に@gn_spawnまでリプライやDMをしてくれればと思います。

あと、焼肉を食べに行きたい。頼むぞ