フロントエンドの地獄

みせてやりますよ。本当の地獄ってやつをね。

React Native + Expoでアプリ作ってみて、採用するならこんな感じの時かな〜という記事

どうも @nabettu です。 フロントエンドエンジニアとして、Webサイト作ったりスマートフォン向けのアプリを作ったりしています。

仕事でも個人としてもReact Native + Expo でアプリを作ってiOSとAndroidの両対応したりしてます。

たまに、新しく作るアプリや既存のアプリの方針転換の相談とかうけるんですが、とにかく 技術選定って難しい・・・

Swift/Kotlin使ってネイティブで作るのか、React NativeかCordovaか、はたまたFlutterか

考えること多いんですよね。適当に「Flutter流行ってるからFlutterでいんじゃね?」とか気軽に言えないじゃないですか。

前提として「iOSとAndroid両対応のアプリを出す」ってのは確実にあるとします。

そしてまず相談受けた時にこのあたりのことをざっくりヒヤリングしたり、一緒に考えたりします。

  • サービスの今後の展開予定
  • 企業の予定規模・予算
  • 既存メンバーのレベル感
  • 採用する技術に関する人材の採用しやすさと平均単価
  • 現在確定してる仕様と不確定要素の洗い出し
  • アプリ開発に導入できる人数と予算、期間
  • メンテナンスの必須期間

などなど、、、

その上でですね、 あくまでざっくり React Native + Expoを使ったほうがいいかな〜って場合の話と、メリットとデメリットを書こうと思います。

React Native + Expoを採用する理由

こうゆう状況だと積極的に採用してもいいかも

  • 割と開発陣が仕様をコントロール可能
  • めちゃ細かいインタラクションを詰めるレベルではない
  • 載せる機能が基本的にWebとそんなに変わらない・Webでやれる範疇をあまり超えない(ARとかOSの決済とかBTとかない)
  • 既存のWebがある・今後Web版を作る予定がある
  • ↑がReact.jsだとなおよし
  • ↑のメンバーが兼任する(JSエンジニアがいる)
  • アプリが頓挫してPWAという方針になるかも(なっても採用したJSエンジニアはWeb版やれるんじゃないかな)

と、Webとの共通化の話題が多いですが、Expoでは今βでReact Native for Webが導入されているようです。

blog.expo.io

それを使って、Expoの中心メンバーであるEvanさんがinstagramクローンをexpoで作ってWebで公開するというのをやっていました。

今後はこれを使って頑張ればソースの一本化がかなり進みそうです。全部一つにはできないけど共通化出来る部分はかなり増えそうです。

私も最近個人でアプリを作ってから、それのWeb版(PCのみ)を作ったんですが↓

tabmemo.com

結局データ管理するmodel部分は共通化して、View部分は別々で普通に作りました。React Nativeなら少なくともそういう感じで頑張れば結構共通化できます。(React Native for WebにExpoが正式対応したらそっちに移行したい。。。笑)

Expo使うメリット

ただのReact Nativeでなく、Expoを使った開発についてです。

  • Node.jsの資産が使える
  • OTAを使ってAppStoreを通さずにバグ修正が出来る(OTAでの機能の変更はAppleに怒られるだろうからbugfixにとどめておこう)
  • ExpoでやるとOTAのサーバーの運用やPushサーバーを立てる工数がグンと減る。Hot Reloadとかもすぐできる。
  • Expoでやる分にはiOSで作ったアプリのAndroid対応工数がプラス0.2倍くらいで済む肌感(Expo無しのReact Nativeなら、完全JSで作っといてライブラリ選定ミスらなければ0.5くらいかな〜)
  • ビジネス要件が変わってネイティブSDK導入が必須になっても普通のReact Nativeにejectしつつ、作りによってはExpoの便利機能(OTAなど)も使って開発を続けられる場合がある(これが意外とデカい)

注意するところ

  • ビルドは楽なんだけど、結局証明書とかストア申請とかはネイティブの知見ゼロだとキツい(アドバイスもらえる人が近くにいると良い)
  • 困ったらWebviewで切り抜ける気合いが大事(結局Webフロントの知識が必要)
  • 市場にReact Nativeエンジニアが少ないので直接的なエンジニア採用しづらい(ただ、すでにReact.js出来るWebエンジニアならある程度気合でなんとかなるとは思う)

他の言語・フレームワークとざっくり比較すると、、、

ネイティブ(Swift/Kotlin)

  • 比較的エンジニアが採用しやすい(絶対数が多い)
  • それぞれ作るので工数はほぼ2倍だけど確実
  • ネイティブSDKが必要になっても問題なし、ビジネス要件に柔軟に対応可能
  • Webとの共通化なんて夢は見ない

Cordova(Ionicなど)

  • 同じくJSで書ける(Angular大好きマンならこれだ!)
  • Web版との共通化はこれが一番いい
  • ネイティブSDKとかが必要になったときにしんどいのは同じ
  • OTAとか出来るけどExpoほどは足元が整ってない

Flutter

  • firebase使うなら組み合わせやすそう
  • まだDartの資産・事例が少ない
  • 少なくともAndroidの開発だけみたらこっちのがDX良いかも(React NativeはiOS中心に作ってる感が否めないのでAndroid側で足を引っ張る場面がたまにある)
  • イケイケなので話題になりそう(やりたい!って人がいるので意外とエンジニア採用できるかも?)

(Flutter for Web は今後どうなるんでしょうね・・・ワクワク)

まとめ

技術選定は会社の状況にかなり左右されるので、詳細を聞かないと「これだ!」とは言えないですが、なんとなくこのあたりの情報をもとに決めるといいのかな〜という話でした。参考になれば幸いです。

以上です。

タブでメモの一覧を分けられる tabmemo というアプリを作った話

こんにちは渡邊です。お久しぶりです。

2019年始まって早くも1月が終わろうとしています😱みなさんいかがお過ごしでしょうか。

私事なんですが、去年の年末あたりからせっせと作っていたアプリがApp StoreとGoogle Playの両方に出す事ができました🎉パチパチパチ〜

それがこちらのtabmemoというメモアプリです。

tabmemo

tabmemo

Tatsuaki Watanabe¥120posted withアプリーチ

tabmemoとは

tabmemoはこんな風に”タブでカテゴリーごとにメモを分けて管理出来るメモアプリ"です。

Webブラウザのタブの着想をそのままメモアプリに引き継いで、ささっと切り替えられたら楽で使いやすいものが出来るんじゃないかと思ったので作りました。

おかげさまでストアのランキングに載りました🎉

iOSアプリのApp Storeでは左が有料ユーティリティアプリの8位、右が全体の有料アプリランキングで63位

f:id:tatsuaki_w:20190131145052p:plain

AndroidアプリのGoogle Playでは全体の新着有料アプリランキングで9位

f:id:tatsuaki_w:20190131143916p:plain

まで、それぞれ"観測"上一番上でした!いえい✌️みなさまのおかげです🙏

(これ自動でランキングの集計とかしてくれてるサービスで、おすすめとかあったら教えてください)

なぜ作ったのかの話

みなさんメモってとってますか?

1月はメモの魔力という本も話題になっていましたね。

メモの魔力 The Magic of Memos (NewsPicks Book)

メモの魔力 The Magic of Memos (NewsPicks Book)

前田さんは紙メモ派らしいですが。笑

私も結構メモるのですが、紙のメモは面倒でUIの絵コンテ書く時とかしか使ってません。

私のメモのとり方について

基本的にはスマホアプリでメモを取っていまして、日頃のメモでは

  • ためておきたいメモ
  • 書き捨てたいメモ

の2つがあると思って、それぞれ使い分けています。

ためておきたいメモは後々からじっくり見返す事もあるであろうログとしてのメモ。

書捨てたいメモは、その場でまとめない内容やTODOを記録して、終わったら消してしまうメモ。

それぞれの2つのメモの役割の違いがあって、私はためるメモはevernoteにためていますが、アプリが重くて書捨てるメモには使っていません。

書捨てたいメモはsimple noteというアプリが起動が早くて気に入っているんですが、カテゴリを分けるのにいちいちtagを入力するのが面倒なのでざっくばらんに入れておいてなにかあったら検索機能で検索していました。

そんなわけで、カテゴリー分けの機能が欲しいは欲しいんですが、書捨てメモには詳細なカテゴリー分けは必要としていなくて、せいぜい5個か6個のカテゴリーがあれば十分だと思っています。

メモを取る上では カテゴリを詳細に分けられる事よりも、カテゴリごとにババっと雑に放り込める利便性が大切 だと思っています。

そんな思想をアプリに落とし込んだのが、今回開発したtabmemoです。

カテゴリーをタブとして、ササッと切り替えて、メモを追加するボタンを押したらすぐにメモの編集が始められます。

機能自体は非常にシンプルで迷わずに使えるようにしています。今後もコアな機能は大きく変えずに進めていこうと考えています。

技術的な話

tabmemoはReact Nativeを利用してiOSとAndroidでワンソースで開発しております。

また、React Nativeでの開発において便利なツール群がまとまったexpoというものを利用して開発しています。

expo.io

expoについて

React Nativeで開発を進める上で、色々と環境の準備や事前知識が必要な場面が多いです。

React Nativeで開発していて特に困るポイントとして、それぞれのネイティブ部分でエラーが出た際にネイティブアプリ開発の知識と経験が必要になってきます。

iOSとAndroidで作っていたら、それぞれ

  • iOSアプリ開発の知識
  • Androidアプリ開発の知識
  • React Nativeの知識
  • React.js及び周辺ライブラリの知識

が必要になります。これはなかなか大変です。

しかしexpoを利用して開発を始めると、ネイティブ側の実装はすべてexpoに隠蔽された状態で始められるのです!

そのためネイティブ側を意識せずにJavaScriptファイルだけを書いて進められるため、先程の4項目の下2つだけで進められます。

そのかわりに逆にexpoがカバーしていない範囲のAPIが利用できない制約があります。(ネイティブSDKの利用など)

とはいえ最近のexpoの利用出来る範囲がどんどん広がっており、今回のような汎用的ユーティリティアプリや、SNSのようなアプリを開発する上で必要な機能は概ね揃っています。

Expoがどんなものか知りたい!触ってみたい!とい方はこちらの本がおすすめです↓

実践Expo React NativeとFirebaseで、SNSアプリを最速ストアリリース! (NextPublishing)

実践Expo React NativeとFirebaseで、SNSアプリを最速ストアリリース! (NextPublishing)

  • 作者: 前田翼,渡邊雄,中川幸哉
  • 出版社/メーカー: インプレスR&D
  • 発売日: 2018/12/14
  • メディア: オンデマンド (ペーパーバック)
  • この商品を含むブログを見る

こちらの本私もレビュアーとして参加したんですが、Instagramのようなアプリの基礎部分をざっと作ってみるハンズオン本となっていて、何が作れるかわかりやすい&ここから本格的なアプリ開発を始められます。

Expoでクロスプラットフォームって工数的にどう?

React Native単品での開発は先程も記載したようにネイティブの知識がそれぞれ必要になってきます。

結構肌感ですが、両OSの開発工数をiOSを1、Androidを1とするとReactNativeでの開発は差分吸収なネイティブ部分の実装に時間がかかるため1.5〜1.8ほどになって、そこまで工数を削減出来るかと言われると微妙です。それでいてクオリティや拡張性は確実にネイティブのほうが良くなると思います。

ですがExpoを利用すると差分吸収がかなり縮小されるので1.2〜1.5くらいまで縮まるんじゃないかな〜と思っています。(無論制約は大きいですよ)

そのかわりReact Nativeでのアニメーションは結構しんどかったり、大規模になって結局ネイティブSDKが必要になったらExpoからeject(通常のReact Nativeプロジェクトに落とす事)になるので、ejectしないで(もしくはしても影響範囲を最小に収めて)進められるような体制であればおすすめできます。

また、React.js自体の学習コストがあるのも考慮する必要がありますが、逆にWebフロント出身の私のようなエンジニアなら学習コストも少なく、割とすぐ始められます。

「こんなアプリを両OSで作ろうと思ってるんだけどどうかな!?」って相談あったら個別に聞いてください〜

今後のtabmemoのロードマップ

ざっくりですが、

  1. iOSリリース
  2. Androidリリース
  3. tabmemo.comにランディングページ作成
  4. クラウドバックアップ機能開発
  5. 端末間データ共有機能開発
  6. PC版の開発
  7. evernoteへのエクスポートなどの追加機能開発

がマイルストーンです。他の仕事もあるので時期は決めていません。現状2まで終わったので、Androidでの不具合の調整などが落ち着いたら3に進みます。

tabmemoアカウントはGoogleログインで、Firebaseを利用してデータを保持しようと思います。

また、4か5のあたりでアプリの料金は今の120円から240円に、6の公開作業が終わったタイミングで360円に設定する予定です。

PC版は無料で、スマホ版と同期するために有料のスマホアプリを購入していただくという形にして行こうと思っています。

その後基本機能以外の追加機能を開発していく上で、その利用にいくらかのサブスクリプション(月額課金)の導入も考えています。

料金を徐々に上げていく事について

「最終的に360円のアプリにするなら最初からその値段に設定するべきでは?」という意見もあると思います。

現状まだバックアップ機能もないので、機能に対して360円では見合っていないと思っています。

金額は固定せず機能に合わせて流動的に変化させていくことが、ユーザーに対して誠実だと考えて今は低い値段で購入していただく形にしています。

初期ユーザーのみなさんは値段とともに徐々にtabmemoが育っていくのを温かく見守っていただければと思います!

逆に後から購入するユーザーはある程度機能が出揃った状態で使っていただくので、多少値段が高くてもいいのかなと。

サービスとしてのマネタイズに答えがあるわけではないため、このあたりは試行錯誤していければと思っています。そのため予定が変わっていく可能性があるのはご了承ください!

まとめ

今後もサクッと使いやすいメモアプリとして発展させてWebサービスとして進化させていくつもりですので、みなさんよろしくお願いします。

長くなってしまいましたが、最後までお読みいただきありがとうございました!

【私信】2018年の振り返り

2018年の振り返りです。ほとんど個人的な記事ですね。

法人化したよ

株式会社クリモという名前で法人化しました。

f:id:tatsuaki_w:20190102113648p:plain

妻が代表です!

妻のメディア事業を軸にしてやっていくぞ〜ということで、二人でやるので法人に。

このかわいいロゴはHayato Iida (a-dot/KARASU)に作ってもらいました。いいでしょ〜

妻のメディアをサポート

そもそもが妻のメディアをサポートするために前職を退職していたので、

  • ままはっくリニューアル
  • ほいくびより改修
  • いらすとびよりの立ち上げ

などなど。2017年に引き続き、WordPressをゴリゴリとやりました。

家庭

妻とお互いの実家に帰省したり、両親と旅行したり。

海外旅行でプーケット&シンガポール行ったり。

子どものピアノ教室に毎週一緒に通ったり。年少クラスだけ発表会が親もセットなんですが、父親が一緒だったの私だけでした笑

受託開発

メディア事業の作業が落ち着いて来てからは受託もぼちぼち。

色々やりましたが、実績として出せるやつは会社のサイトに書いてるやつとかかな?

前職のカヤックの仕事も受けたり、コーポレートサイトをNuxt.js + ヘッドレスCMSで作ったりもしました。

8月からはReact Native(Expo)のアプリ案件をガッツリ目で受けてて、他の仕事はあんまり受けてません。

そのアプリはバックエンドがほぼFirebaseでやっていて、そのデータの管理画面も作ってるんですが、React Nativeに合わせて管理画面もReact.jsで作ってます。

それと別でもう一個React Nativeでアプリを作る案件に、他の案件の入ってない日だけ参加するような形で開発に参加しています。

Webサービス開発

7月に出したためしがきがローンチ時にたくさん使われてよかったですね〜やっとまともに使われてる代表作的なのが出来た感。

tameshigaki.jp

アプリーチとか、comtes(途中だけど)とかをリニューアルしました。

mama-hack.com

comets.nabettu.com

chatblogとか気合入れて作ったけど全然使われてないw悲しみですね。他にも色々作ったけど使われてないやつちょいちょいありますw

アプリーチに有料プランを設立してみたりもしました。

blog.nabettu.com

ブログ結構書きました

ちょいちょい読まれる記事書けたと思います。

はてブが10以上ついたやつは

  • 有料プランのMVPとしてのpixiv FANBOX:12
  • 2019年やりたいことリスト を作ってみた : 23
  • 読まれる技術記事を書くには? : 100
  • 個人開発のモチベーションが続かない、: 518
  • 静的サイトを公開するならどこがいいの? : 630
  • 日本語のフリーフォントをまとめて試せるサイト「 #ためしがき 」をなんで作ったのかと技術的な話 : 562
  • 退職エントリー : 172
  • Webサービス分解 「Peing-質問箱-」の分解 : 48
  • 技術書典サークル参加して冊子完売しました : 25
  • 技術書典で初心者でもWebサービス作れる方法まとめた本売るので買いにきて! : 45
  • フロントエンドエンジニアに求められるもの多すぎ問題 : 499

で、ためしがきの影響もあって、技術同人誌のboothのページもはてブ500ちょい、ためしがきが今2106なので、

全部足して合計5200被はてブくらいになりました。炎上なしでこの数だけ見るとちょっと多いんじゃないですか?結構頑張ったんじゃない自分?笑

執筆

技術書典に参加して、技術同人誌を何冊か出しました。

そのまま商業出版化したのが1冊

改訂新版 Vue.jsとFirebaseで作るミニWebサービス (技術書典シリーズ(NextPublishing))

改訂新版 Vue.jsとFirebaseで作るミニWebサービス (技術書典シリーズ(NextPublishing))

Netlifyの本、Botの本、UIの本を共著で書きました。多分Netlify本は今年中に出版社からも出せると思います。

nabettu.booth.pm

Botの本は共著で書いて、そのまま各人の章はそれぞれがバラで管理する事になって、その部分をnoteなどで売っています。

note.mu

犬テトラ+というサークルで、もっとx2&のりぴーと書いたUIの本はこちら。きっと次回の技術書典までに各々加筆&atsucoさんが1章追加で書きます。笑

booth.pm

あとレビュー&テスター的に参加した商業誌も3冊

  • ぐぐたまさん&ハムカツおじさんのExpo本

実践Expo React NativeとFirebaseで、SNSアプリを最速ストアリリース! (NextPublishing)

実践Expo React NativeとFirebaseで、SNSアプリを最速ストアリリース! (NextPublishing)

  • 作者: 前田翼,渡邊雄,中川幸哉
  • 出版社/メーカー: インプレスR&D
  • 発売日: 2018/12/14
  • メディア: オンデマンド (ペーパーバック)
  • この商品を含むブログを見る

  • たかもそさんのcss本
  • もっとx2さんのNetlifyでサーバーレス本

レビュー、意外と大変だ!でも面白くていい本に関われて嬉しいですね。

Netlifyでサーバーレス本はもうちょっとで書影が出るのかな。もっとx2さんのやつなんですが、私のNetlify本の表紙と同じくたかゆりさんの描くねっとりさんの新作が見れるのでみなさん楽しみににしていてください。

登壇も少し

最近はあんまりLTとかしてなかったんですが、ありがたいことに登壇に呼ばれる機会が何度かあって、

  • フリーランスエンジニアでプロジェクトを進めることについて考える会
  • 秋のJavaScript祭り

で登壇したりしました。

netlify meetup tokyoでは、Netlifyの技術同人誌を書いてたらイベントに来てくれ〜ってnetlifyのの人に呼ばれたのでLTもしてきました。

↓そのへんの発表資料はこの中

https://speakerdeck.com/nabettu

クソアプリ

毎年末あんどさんが中心になってやっているクソアプリアドベントカレンダーで文字通りのクソアプリを作りました。

qiita.com

一年間の締めに相応しいクソアプリですね。

まとめ

個人活動はためしがきにブログに執筆に、、、文字ばっかの2018年でした!笑

書き出してみると、意外とやった感ありました。

やりたかったけどやれなかった事とかは引き続きこちらに

blog.nabettu.com

2019年はこの記事にあるようなことをやっていきたいぞ!

終わり!

有料プランのMVPとしてのpixiv FANBOX

はい、こんにちは〜わたなべです。年末いかがお過ごしでしょうか。

開発をしたいのですが、子どもの面倒をみたりでかけたりしなければならないので、スキマ時間にスマホで文章を書くくらいしか出来ていません。ということでブログを書きます。笑

ところで本題ですが、みなさんwebサービス作ってますか。私は年に何個か作っては潰してたりしています。

その中の一つで、こんな感じのブログパーツを作れるサービスを運営してます。

グラバー

グラバー

Wanta, Inc.無料posted withアプリーチ

  (↑これめちゃいい文字起こしメモアプリ)  

アプリーチというサービスで、おかげさまで色んなブロガーやメディア運営の方にご利用頂いてます。  

iOSとAndroidのアプリを横断検索してブログパーツを作るというシンプルなサービスになっています。

mama-hack.com

マネタイズ

このサービスは基本的に無料で利用が出来て、サイト内の広告収入だけで運営しています。

そんなアプリーチですが、こちらでブログパーツを作ると「アプリーチへのリンク」が入るのですが、以前「有料でもいいのでこのリンクのないブログパーツを発行したい」という、非常にありがたい問い合わせがありました。

特に予定もしていなかった「広告以外のマネタイズ」の兆しが。。。!  

とはいえ、一昔前よりは大分環境が揃ってはいますが、まだ有料課金をサービスに組み込むのは色々とハードルがあります

いくら希望していただいたとしても「有料プランは10000円で!」と言うわけにも行きませんし。笑

MVPという考え方

  リーンスタートアップとは、最小限の機能を要した製品:MVP(Minimum Viable Product)をまず作って、顧客の反応を見ながら改善していく手法です。

  今回アプリーチでは「有料プランを作って問い合わせしてくださった方以外にも本当に加入する人がいるのか」を確かめるために、まずpixiv FANBOXで月額500円のプランを設置しました。

  決して実装がめんどくさかったからではありません。リーンスタートアップ的手法で進めるためです!本当ですよ!笑  

FANBOXって?

  pixivさんが運営する、お気に入りのクリエイターのパトロンになって毎月活動支援を行うサービスです。

  そのため私の開発活動報告として、毎月アプリーチの開発裏話的なコンテンツを発信しています。

  あとはアプリーチの「リンクのないパーツ」を発行する機能の利用方法を記載しています。  

個人で作っているからこそリーンに

  エンジニアは自分で作れるからこそついついすぐになんでも作ってしまいがちです。  

「あれもこれも」とたくさんの機能をやたらめったら増やしてしまうと、そのサービスに本当に大切なバリューがなんなのかが曖昧になってしまいますし、使わない機能はサービスにとってただのノイズです。  

今回はまず「作らない」という選択肢をとって、本当に有料会員が増えるのかどうかを確かめてから実装するでも遅くないかな〜と思ってこの形で進めてみています。  

とはいえ

  • 勉強のために作ってる
  • サービスにとってなくてはならない機能
  • 作らないと価値が検証できない

などの状況なら作ったらいいと思いますし、私もプロトタイプならガンガン作った方がいい派です。  

というわけでFANBOXを開設してみたので、興味がある方は覗いてみて下さい!

www.pixiv.net

以上わたなべでした〜  

最後までお読みいただきありがとうございます。  

#2019年やりたいことリスト を作ってみた

ぴょんさんの↓のnoteを見て私もやってみました。

note.mu

やりたい事といいつつ3分の1くらいはやる事がほぼ決まっているし、やるぞ!

あと目標も混ざってます💪

仕事&ものづくり

  • 個人でアプリを両OSで出す(たくさん)
  • 仕事でもアプリ出す(10件くらい関わる
  • 自分の作ったwebサービスやアプリ収益で月30円万くらいまでいく(今10万弱くらい?)
  • 海外から収入を得る(コンテンツを売るでも、アプリを売るでも)
  • ビジネスモデル図解webをローンチする(年末忙しくて全然進められなかった、、、😭)
  • ゲームを作ってローンチ
  • OSSに貢献する
  • お金の稼ぎ方を考える。PDCAを回す
  • 本たくさん出す
  • 出版社経由でない自分の本を流通させる
  • バーチャルユーチューバーかなんか、文書以外の情報発信をする
  • チームを作る
  • 「この技術ならこの人」ななんかを見つける・なる
    • netlify
    • Firebase
    • Nuxt.js
    • Expo(react native)
    • 辺りをもっと流行らせる&人に聞かれるレベルになる
  • typescriptちゃんとやる
  • テスト書けるようになる
  • 脱wordpressを引き続きみんなで考える
  • ハッカソン出てみる
  • ソフトウェアでないものを作る・売る
    • ボードゲーム作る
    • 絵本作る

趣味

  • 技術書以外の本読む
  • 開発以外の趣味に時間を取る
    • 毎月ボルダリング行くとか
    • 音楽を再開するとか
    • マンガを毎月30冊読むとか
    • はたまた別な趣味を見つけるとか
  • お気に入りのシャツを増やす
  • 積みゲーを消化する(今cupheadやってる)

家族、友達

  • 引っ越す(今後の住むとこ決める・子どもの小学校を決める)
  • 海外旅行行く(友達とも行く・家族にはアメリカのデカいディズニーに行きたいと言われてるので行く・妻にも友達と行ってもらう機会を作る)
  • 子どもと自転車の練習をして乗れるようにして少し遠出する(クリスマスプレゼントに自転車買ったところ)
  • 友達と飲みに行く(けどアルコールの摂取は少なくする)
  • ランチなら結構いつでもいけるから誘ってくれ〜
  • 友達のビジネスを応援する
    • 応援する仕組みを作る
  • こないだ15年ぶりくらいに再会できたいとこと飯に行く
  • 実家の両親と旅行に行く(妻と私双方)

その他

  • 母校になんかしら貢献する
  • 高専の同窓会する
  • 2019年もエンジニアとして生き残ってクソアプリアドベントカレンダーでみんなと再会する

以上!だいたいが「なんか作る」的なやつだったw

今日からやれることやっていくぞ〜

cometsを支える技術 ~ Crieit 個人開発サービスに用いられている技術アドベントカレンダー ~

こんにちは!渡邊です!

この記事はCrieitでの 個人開発サービスに用いられている技術 Advent Calendar 2018 の13日目の記事です。

今回はcometsというWebサービスについて書きます。

cometsとは

f:id:tatsuaki_w:20181212163001p:plain

https://comets.nabettu.com

発表スライド上にコメントが流せるWebサービスです。

Google Slideなどでブラウザを利用して発表しているスライドの上に、視聴者からのコメントをリアルタイムに流せるサービスとなっております。

こないだのjs祭りで使われた様子はこちら↓

(こくしんよく撮れてる動画ありがとう!)

これを使うとどうなる

普通のスライド発表って発表者の言いたいことを言って終わりになりがちですが、これを使うと一方通行にならずにインタラクティブな発表が出来ます。「リアクション」だったり「質問」などをそのタイミングで見ている人が投げる事ができるのです。

終わった後に「質問ある人〜?」などで聞いてもシャイな人はなかなか手を挙げられないと思います。そこで、cometsがあれば匿名で意見を送る事ができます。

また、QRコード生成機能があるので、cometsの画面で作ったQRコードをスライドに貼っておくとスムーズに共有出来ます。

アンケートを集計するのにも使えます

cometsにはボタンを押すだけで簡単に定形のコメントを送れます。そのボタンの中に🍎や🍌などの果物ボタンが5つあります。 これを使うと、スライドに質問を書いておいて会場の視聴者にそのままアンケートをとれます。

例)発表スライドは何でつくってる?

  • 🍎Keynote
  • 🍊PowerPoint
  • 🍌Google Slide
  • 🍇Slides
  • 🍈Prezi
  • その他(コメントで)

のようなスライドを作っておいて当日にアンケートを取れます。

アンケートによって話す内容を変えると非常にいい発表が出来ると思います。(「Netlifyについて知らない人が多いみたいだから詳しく話そう」とかとか)

ぜひ取り入れてみてください!

どうやって作ってるの? 発表者編

発表者がGoogle Slideを起動している画面で、指定のブックマークレットを実行します。Chromeエクステンションではないので、どんなブラウザでも基本的に機能します。

実行すると視聴者と共有する合言葉を入れる欄が出てくるので、合言葉を入力してコメントを受け取ります。

裏側ではFirebaseのRealtime Databeseを利用して、視聴者がDBに追加したデータを検知して、同じ合言葉のテキストを画面に追加します。

画面に追加されたテキストはCSSアニメーションで右から左に流れていきます。

どうやって作ってるの? 視聴者編

コメント画面はNetlifyでホスティングされた静的Webサイトで、画面を開くとFirebaseに匿名ログインして、コメント書いて送信ボタンを押すとFirebaseのRealtime DBに書き込みます。

開くURLには合言葉をパラメータでセットできるので、そのままURLをシェアも出来ます。

Twitterにそのままつぶやくチェックをオンにしておくと、コメントを送ってそのままTwitterの投稿画面に遷移出来るようになっています。その際合言葉はハッシュタグになるので、イベント指定のハッシュタグがある場合にはそれを合言葉としておくといいでしょう。

FirebaseのDBにはFirestoreという上位互換的なものもあるんですが、リアルタイムなデータのやり取りに関してはRealtime DBをFunctionsなどを挟まずに利用するのが早いです。

今後の展望

  • 合言葉が日本語のときにQRコードがバグる
  • Twitterでハッシュタグのツイートがあったらそのままcometsと同じように流す機能
  • electronでローカルのスライドツールでもコメントを流せるようにする機能
  • サイトがBootstrapバリバリなのでモダンなデザインにする

などを、時間あるときにやろうと思っています。

ぜひ皆さんcometsを使って、インタラクティブな発表をやってみてください!

明日はあのnaichiさんが unityroomを支える技術について話してくれます!明日もまた見てくれよな!

読まれる技術記事を書くには?技術記事を書く時のポイントまとめてみた

Crieitのアドベントカレンダー3日目です。担当の渡邊がお送りいたします。

みなさん、qiitaや自分のブログ、はたまたCrieitなどに技術記事書いていますか?

せっかく技術記事投稿サイトのアドベントカレンダーなので、技術記事自体を書くことについて書きます。

ノウハウと見せかけて当たり前の事を書こうと思います。

そもそも技術記事って書くべきなのか

エンジニアじゃなくても「情報発信」は大事です。フリーランスじゃなくともそこから仕事につながることもあるでしょう。100%書かないよりは書いたほうがいい

もちろん仕事をとってくる目的で書いてるなら立派な営業活動なので書くべき。最新情報とかの発信はブランディングになるんですよね〜mizchiさんとかすごい。

そうでない方も、エラーで困った内容とかはできるだけログとして残しておくといいでしょう。どうせ3ヶ月後に同じでエラーが出て自分が読むことになります。笑

とはいえ無理してまで書くのは微妙ではある。コードを書く時間を減らさないように、息抜きレベルにしよう。

せっかくなら読まれたいよね

そしてせっかく書いた技術記事、どうせならたくさんの人に読まれたいですよね。

まず技術記事ってどんな種類のがあるか、分類しました。翻訳記事についても内容自体は以下の感じではないでしょうか。

  • トレンド発信
  • 困った事をまとめた記事
  • 自分で調べる必要があってついでにまとめた記事
  • 作っていたものを事例として紹介した記事
  • 人に聞かれた事を書く記事
  • ポエム

それぞれについて、読まれるための大事なポイントを書いていきます。

読まれるトレンド記事

トレンド記事はとにかくスピードが大事

界隈の人が「お、新しいライブラリが出てるな〜」とか、なんだなんだと言っている3日以内にさっと記事を出しましょう。

そしてトレンド記事は簡潔であることが結構大事。あくまで概要を知りたいって人が中心なので。

そのため「わかった気にさせる」ような内容を書けると「あ〜React hooksね。完全に理解した」って言ってシェアできる。

あとはブログじゃなくてもいいかも。TwitterとかYoutubeでいい場合もある。

困った事をまとめる

これはとにかくエラーログが大事!

できればタイトルにエラーで出る一番重要な文言を入れましょう

これはそのエラーでググった人がたどり着けるようにです。つまり、書いてすぐ読まれることは期待してはいけません。

あとはそうすると、ググってヒットする必要があるので最低限のSEOが大事!teratailで回答ゼロの質問に負けたりしたら目も当てられません笑

エラーじゃないとしても「〇〇が効かない」とか、ググられそうな形のタイトルにしましょう。

とはいえニッチなエラー文言で記事書いてたら大丈夫な気もします。

自分が忘れたころに過去の自分に感謝することになったりもします。

自分で何かを調べる必要があってまとめた記事

これは網羅性が大事

比較記事を書くとしてもリファレンス的記事を書くとして、長くなってもしっかり網羅的に書かれていることが大切です。

「これとこれで、結局速度はどっちのが早いんだ・・・???」ってなって離脱されるようなことは避けたい

あとこれもSEO大事かな〜そのワードで上位表示してないと読まれないので。

自分で作っていたものについて事例として紹介して書く

しっかり宣伝になるように書くのが大事!

結局その作ったものに人が来てくれないのなら、それ載せる意味ないやん。

理想は「プロダクトローンチ」→「このサービスのここどうやって作ってるんだ!?」→「うわ〜解説記事あるやんなるほどなシェアシェア」ってなること。

ただただ宣伝したいだけの記事はノイズだ〜qiitaじゃないとこに書いてくれ〜

とかこういうの気にしなきゃならないような内容がある記事は自分のブログに書いたほうがいいよ。文句いわれないでしょう。

あくまでqiitaに書きたい時にはちゃんと技術的な内容を中心に書くのよ〜(あたりまえ)

人に聞かれた事を書く

誰かに質問された内容を記事に落とし込む場合。2回も同じ事違う人に聞かれても記事のURLをシュッと出すことでありがたがられる。

これは聞かれた人が満足する内容だったのかどうかが大事。内容について聞いてきた人にチェックしてもらうとより良いかな〜

あとは、聞かれるってことは確実に需要がある記事なので、そういう機会があったらしっかり記事に書いたほうがいいよ。

ポエム

エモさが大事。なにはなくともエモ散らかしましょう。エモさがあれば、あとは何もいらない。裸になるほど読まれますよ。ザッツインターネット。

どこで書くか問題

次にどこで発信したらいいんだ〜っての結構悩みどころですね。

qiita

先程も触れましたが、qiitaはコミュニティなので、公式のコミュニティガイドラインがあります。それにそった記事を書いていれば、ランキング機能だったりSEOもよかったりして結構読まれるようになりますね。困ったらqiitaでいいかも。

自分のブログ

自分で立ち上げたブログなら何を書いても文句は言われません。「技術記事なのかどうか怪しいから」とか迷う必要もない。

ただ、ホスティングを自分でやる必要があるのは正直めんどくさい。笑

しかしそれ自体が技術アピールになったりしますので、ポートフォリオ代わりに作ってしまうのもあり。

「俺様のサイトはGatsby.jsだ。お前のサイトより早い」(これGatsbyの謳い文句ね)

そして細かいところが気になって、肝心の記事が書けないという負のスパイラルに陥らないように笑

QrunchやCrieit

そこでポエムだろうがなんだろうが書き散らかしてもいい上に無料の記事投稿サービスがありますから、この辺を使うのもいいですね。

note

SEOは強そうですね。ただ、エディタの書き心地が地獄なので私はマークダウンエディタが出たらなにかしら書こうと思います。有料にもできるし。

全体的に書くときに重要なポイント

タイトルが大事

使った技術内容とか引きになるようなものを織り込むのが大事。30字とかよりは長くならないようにしたい(google検索で文字が切れる限界そんなもんじゃなかったっけ)

記事を書いた日付がわかるようにしておく

qiitaなんかは「この記事は古いぜ〜」って勝手に出してくれるからありがたい。個人ブログはそもそも日付の表示忘れてたりするよね。古い記事は古いとちゃんと書いておかないと自分も後で困る。

動作環境などもできるだけ書いておく

そしてバージョン情報とかはできるだけ載せておこう。再現環境がcodepenとかであると最高。

短くても書いたほうがいいの?

以前はてな匿名ブログで「ゴミ記事を書くな」みたいなエントリーがありました。

るせぇぇぇぇーーーー!!!!!

どんなに短くても書かないよりも書いたほうがいいです。

エラー文言

hoge.js の3行目に fuga

この1行書いたら直った

たった3行でも、価値があります!

同じエラーで困っている誰かの助けになるかもしれません。

たとえ情報が古くて微妙になってしまったとしても、その記事をググって出ないようにするのはgoogleの仕事なので、あなたは気にせずアウトプットしていいのです。

また、Qiitaには「編集リクエスト」って素敵な機能がありますよ!ミスってるのに気づいたらリクエスト送ってあげて。

あとQrunchは「ログ」って機能があって、ユーザーが執筆時にググっても出てこないようにするように設定する機能もあるので、気になったらログに設定とかもアリ。

なにはなくとも、書く余裕があるなら、書きましょう。マイナスになることはないです。

まとめ

  • 書く記事によって読まれるポイントがあるので意識しよう
  • まぁそもそもほとんどの記事は読まれませんので、読まれなくても気にすんな
  • できるだけ親切丁寧に書いたほうがいいけど、しんどかったらさっと出してしまおう
  • 場所はどういうアウトプットをしていきたいかによって変えてもいいかも
  • あとはとにかく書いて徳を積みましょう

こう、色々書いたけど、まず発信するだけで偉い!もし余裕があって、気が使えたら(自分にとっても)色々読みやすい記事を書きましょうという話なので!とにかくまずは3行あればオーケー!!!

以上です。

明日はクソアプリ友達のあんどさんがいい感じの記事を書いてくれます!

面白法人カヤックどうだっかな〜という振り返り

この記事はex-KAYAC Advent Calendar 2018の2日目の記事となります。

在職期間のこと

カヤックではHTMLファイ部に所属していました。

Webフロントエンドで、びゃんびゃん動くキャンペーンサイトとかを作るのに特化した部門です。

在職期間にやった仕事の中で公開できるやつ一覧↓↓↓

www.kayac.com

もともとがWeb系じゃない会社から業務未経験で入社したので、入社当時はわからないことしかない状態で、諸先輩方に色々と手取り足取り教えていただきました。

なんで辞めたか

別途退職エントリーみたいなのも書いてますが、基本的にはフリーランスでやっていた妻の仕事を手伝うために退職しました。

フリーランス&会社員という夫婦構成で仕事していると、どうしても家庭や子どものことで時間をとらなきゃならない場合に、フリーランスで時間に融通きく方の負担が多くなっちゃうんですよね。

それで負担を私に寄せるためにフルタイムでない働き方にしつつ妻の仕事を手伝おうと退職した感じです。

今やっていること

一旦二人でやるので法人にして、株式会社クリモという社名で妻を代表にして経営しています。

退職してからは、妻の作っているメディアのリニューアルをしたり、新しいメディアの立ち上げをしたりとちょこちょこやっていって、

一年くらいしてその辺が少し落ち着いてきたので、私もエンジニアとしての腕が落ちるのを防ぐためもあって最近は受託開発をわりとしっかりやっています。

他にも空いた時間を見つけてwebサービスを作ったりしています。

カヤックどうだった?

「exカヤック」な記事なので、カヤックから離れてみてからカヤックがどうだったかについて。

上場してて結構デカいので200人以上いました

  • 受託開発
  • 自社サービス
  • ソシャゲ

の3つに大きく分かれていて、受託開発部門にしかいなかったので他の部門がどうかについてはあまり知りません。

やってる事は結構違いますが、各部門間での異動希望とかはすんなり通る感じでした。

なので受託も自社も経験したい〜って人にはいいですね。 転職は色々エネルギー使いますから、異動で済むなら異動にしときたいですよね笑

受託開発部門の良いところ

案件実績見たらわかると思いますが、広告業界の仕事が多いです。

キャンペーン系の仕事のいいところはですね、サイトが1週間で閉じるとかがザラにあるんですよ。

そうするとですね、作るときに運用についてあんまり考慮しないでいいので、比較的「使いたい技術を使いまくれる」のが良い所です。

webフロントエンドはとにかく流行の流れが早いと思うのですが、去年もてはやされた技術が今年には「オワコン」呼ばわりされたりするわけです。

そう言うのを考えると技術選定において「メンテナがこの人だから大丈夫か」とかまぁそんな細かいことは気にせずに、割と使いたい技術を使えるわけですね。(もちろん公開時にはしっかり色んな環境でテストするのでその時点でバグがない前提ですよ)

「エンジニアたるもの自主的な学習は必須」みたいなのはどこの会社にいてももちろんあると思うんですが、なんだかんだ「仕事でやるのが一番力がつく」と思うんですよね。

なのでバシバシ新しい技術を取り入れられる環境はありがたかったです。

※「独学でもある程度使えるレベルのものを実践投入して更に使いこなせるようになる」のが前提なので「何もわからんけど覚えたいから使う」とかではないですよ。

労働環境

前述の「フルタイムでなくして妻の仕事を手伝う」の部分、実は会社辞める前に一旦「カヤックに在籍しながら週3日勤務にしてみる」のもやってみたんですよ。

カヤックは結構そういうスタイルで仕事する人もちらほらいまして、このアドベントカレンダーの前日のデニールも「ベンチャー立ち上げ期間は売り上げもないから、カヤックに在籍しながら」やってました。

上司とチームの了承がとれていれば、そういう前例があるので、役員や人事に話して書類をぴょぴょっと作ってもらって「はい、では来月から週3日勤務でよろしくお願いします。」となりまして、半年くらいそれでやってました。

結局やってみて、残りの週2日を保育園送り迎えしたりしながらやってもあんまり成果出せないなって事で退職したんですが、まずはそれを試せる労働環境があるのは有り難いですよね。

まとめ

  • 広告系は比較的サイトを作り捨てやすいので、使いたい技術が使いやすい
  • 週2日で保育園送り迎えとかしながらだとあまり成果出ない笑

そんなカヤックライフでしたが、辞めてからも仲良くやっていまして技術書典で一緒に本書いて出したりしてます。

退職者アドベントカレンダーはなんか軽く振り返るのにいいですね〜

おわり

知ってました?Netlifyにはこんな機能もあるんだよ!

この記事はJAMstack Advent Calendar 2018の1日目の記事です!

JAMstack関連の記事をみんながワイワイ好き放題に書いていく感じですね!ってことで私もJAMStackの提唱者であるMatt Biilmannさんが創業・運営しているNetlifyについて書いていこうと思います。

JAMstackは「クライアントサイドJavaScript、再利用可能なAPI、予めビルドされたマークアップの3つで構成されたWeb開発アーキテクチャ」のことですね。

Netlifyってどんなサービス

そんなJAMstackを実現する際にビルドされた静的サイトのホスティングが非常に簡単にできるサービス。それがNetlifyです。

netlify.com

NetlifyではGitHubなどで管理しているリポジトリから自動的にデプロイを行える他に、フォームやCI機能など静的サイトを運用する上で便利な機能が豊富に揃っています。

どんな機能があるの?

2018年11月時点でNetlifyには次の機能が備わっています。

  • 静的サイトホスティング
  • ビルド機能
  • 独自ドメイン設定
  • CMS機能
  • フォーム設置
  • Functions
  • A/Bテスト
  • Prerendering
  • チーム機能

Netlifyはものすごいスピードで新しい機能を開発しているので、今後もサイト運用する上で便利な機能が加わっていくことでしょう。

この中でも「Netlifyはホスティングだけじゃ無い!」って機能について触れていきます。

CMS機能

www.netlifycms.org

NetlifyCMSは文字どおり、Netlifyを用いてCMS(Content Management System)を構築するためのライブラリ群です。

管理画面からコンテンツを入稿するだけブログやニュースサイトのようなサイトも手軽に構築することができるんです!!!

もちろん、使うサービスはNetlifyだけで、別のレンタルサーバーを借りたり、面倒なセットアップ作業を行う必要もありません

NetlifyCMSにはデータベースはありませんが、代わりにGitHubレポジトリ上に命名規則をつけてコミットされたファイルを使って、記事データの管理をしていきます。

そのため、Netlifyはレポジトリに新しいコミットがあったタイミングでビルドを行い、静的サイトを生成することで、同様の機能を実現しているわけです。これもJAMstackなサイト構成になるので、サーバーの負荷などもかからずラクラク運用が可能です。

フォーム機能

コーポレートサイトや商品・サービスの紹介LPなど「サイトのほとんどは静的コンテンツなんだけど、どうしても問い合わせフォームだけは必要!」という理由でサーバーサイドのある環境を必要としている人は多いと思います。

しかしNetlifyを使えばこの問題も解決可能です。サーバーサイドのコードを一切書くことなく、Netlifyがフォームのサーバー側の機能を代替してくれるため、静的サイトなのにフォーム機能を実現することができるのです。すごいぞNetlify。

Netlify Functions

このFunctions機能は、簡単にいうとAWS Lambda FunctionsをラップしてNetlify上でもパスを切って使えるようにした機能です。しかしAWSのようなごちゃついた管理画面を使わず・しかもクレジットカードも登録せずにすぐに使い始めることが出来ます。

静的サイト上では隠蔽したい内容など、functionsを補助的に使えるだけで、静的サイトで出来なかったことが多々できるようになると思います。

A/Bテスト

ブログやECサイトを運用していると、バナーの置き換えや応募ボタンの位置を置き換えて、ユーザーの流入がどれくらい変わるのかを測定するようなA/Bテストを実施することがあるかもしれません。

Netlifyが提供しているSplit Testingという機能を用いることで、GitHubのブランチをベースにしたA/Bテストを導入することができます。超簡単。

ブランチごとにテストしたいコンテンツを変えておき、計測はGAでオプションの内容を変えて別途計測する形で集計します。

Prerendering

SEO対策というよりも、TwitterやFacebookでのOGPの表示を切り替えたいな〜って時ありますよね。

静的サイトで動作しているシングルページアプリケーションでは、meta情報の更新をJavaScript上でのみしか行えないため、1つのサイトで1つのOGタグしか表示することができません。

Netlifyではこの課題を解決してくれる、Prerenderingという機能を提供しています。これを有効にすることで、JavaScriptで設定したmetaタグ、Open Graphの設定も、TwitterやFacebookなどのSNSで表示されるようになります。

これはJavaScriptで描画した内容をNetlifyがキャッシュしておいてくれて、初回描画時にそのキャッシュを返してくれるためmetaなどの切り替えにも対応しています。すごい。(中身はprerender.io)

まとめ

Netlify意外と色々便利な機能があるな〜ってことが伝わりましたでしょうか。

宣伝になりますが、この辺りの具体的な利用方法などをまとめた本を書いてますので、もしこの記事で興味がわきましたらぜひご一読していただいてNetlifyを使いこなしてみてください!

nabettu.booth.pm

日本語のフリーフォントを一度に試せる「ためしがき」に用いられている技術について

この記事はcrieitでの 個人開発サービスに用いられている技術 Advent Calendar 2018 における記念すべき1日目の記事です。

このアドベントカレンダーの趣旨

「アドベントカレンダー」という文化については触れませんのであしからず。

この「個人開発サービスに用いられている技術」というカレンダーの言い出しっぺなので、軽く趣旨を説明したいと思います。

このカレンダーで皆さんに書いてもらいたいのは、個人でwebサービスやアプリを開発している方が自分のサービスをどのように作ったかというのを熱く語っていただきたいと思ったからです。

運営者ギルドというslackコミュニティで個人開発者が集まってワイワイやってるんですが、そこのメンバーを中心にして

  • 日頃作ってるサービスの技術面がどうなっているかをこの機会に共有しあって、今後お互いに困った時にスムーズに聞けるようになるといいな〜

というのと

私自身webサービスが作るのも使うのも好きで、特に技術的に何を使って実現しているのかを考えるのも趣味だったりします。 それで過去にこのような「Webサービス分解」というテーマで記事を書いたりもしました。

blog.nabettu.com

それで、それぞれみんなが自分で解説してくれると非常に面白い記事が出来上がるのではないかと考えたからです。

ということで、まずは私から個人で運営している「ためしがき」というサービスについて解説していきます。

ためしがきとは

tameshigaki.jp

日本語の商用利用可能なフリーフォントをまとめて試せて、そのままシェアしたり配布先にリンクしたりできるサイトです。今回はこのサービスの技術面について書いていきます。

ためしがきに用いられている技術

フロントエンド編

このサイトはサーバーレスSPAとなっており、Vue.jsのフレームワークであるNuxt.jsを利用して開発しております。

デザインは特にCSSフレームワークなど使わずにすべて自前でCSSを書いています。

f:id:tatsuaki_w:20181127143603g:plain

このモーダルが開くときのアニメーションや、ボタン色が反転したりというアニメーションも基本的には自前のCSSアニメーションで実現しています。消しゴムも。

PCで見た際に文字数に応じてプレビューのコンポーネントのサイズが動的に変わっていく部分は、頑張って計算して数を決めているんですが、Gridとかにしたらもっと楽だったかも。追々直していきたいですね。

フォントの読み込みはのりぴー先輩のこの本を参考にして、ページ読み込みの際に一気にpreloadさせています。20MBくらいあります😥

誰でもつかえる! ウェブフォント実践マニュアル (技術書典シリーズ(NextPublishing))

誰でもつかえる! ウェブフォント実践マニュアル (技術書典シリーズ(NextPublishing))

あとは計量化のためにフォントファイルはすべてWoff2形式で配信しています。

縦書き機能

これこないだ追加した新機能なんですが、せっかく法人なのでPR TIMESさんにプレス打ったりしてみました。

prtimes.jp

これもCSSで縦書きできないか〜って色々実験していたんですが、結果Safariとかで崩れたり、縦書き対応のフォントとそうでないフォントがあって切り分けが難しいことなど色々ありまして、結局縦書きCSSはやめました。

じゃあどうやって縦書きしているかというと、デベロッパーツールを見てもらうとわかるんですが1文字づつDomを分けて、かっこや点などの約物は回転や移動をして調整という形になりました。これだとフォントが縦書き対応しているかどうかは関係なくなります。

こちらの実装は前職の先輩のスーパーエンジニア中山さんの作った西尾維新の公式サイトの方式等を参考にしています。

ni.siois.in

(このサイト作られたの結構前なんですが、今見てもヤバさがヤバい)

結構CSS以外でもCanvasを使ってjavascriptで縦書きを実現する際にもこの手法をとられている場合が多いですね。フォントに依存しないというのが今回大量のフォントを利用するためしがきでは重要でした。

バックエンド編

ホスティング

ブランチ毎の確認やフォントを本番化前の確認ページにはNetlifyを利用しています。

本番環境のみFirebaseというサービスのHostingを利用しています。(CDNの速さがNetlifyはまだ少し遅いため)

フォントのシェア機能

ユーザーが指定のフォントで任意の文言でシェアを行う機能は基本的にfirebaseを利用していて、

  1. html2canvasでクライアントサイドで画像化
  2. firebase Storageにアップロード
  3. strageのURLや文言をfirestoreに保存
  4. firestoreで発行されたIDをもとにシェア用URL発行
  5. シェア先のURLをgetするとOPimageに「storageに保存された画像が設定されたhtml」を返却するfirebase functionsが起動
  6. 5.にアクセスするとtameshigakiのtopへリダイレクト

という流れになっております。

1の画像化については、ユーザーの環境によっては不安定なためpuppeteerでの画像発行を試みようとしましたが、functionsでpuppeteer起動して画像発行・・・とすると待ち時間が多いため一旦クライアントサイドでの発行としています。これもチューニングして再挑戦したいですね。

CI環境など

Firebase Hostingはビルド環境などがないため、githubにpushしたのを検知してCircle CIでbuildしてfirebase hostingへdeployしてもらっています。

運用

フォントファイルの管理はヘッドレスCMSのcontentfulで行っています。

ただ、フォントファイルが重たい&フォント情報の更新はあまり頻度が高くないためビルド時にcontetntfulからダウンロードしてきてbuildファイルに混ぜてdeployしております。

今後の展望

  • フォントの追加作業が大変で全然出来ていないので、ぼちぼち進めていこうと思っています。
  • フリーフォントを使ってブログ用OGP画像を作る機能とかもあったらいいかな〜と考えています。
  • どこかデザイン系でシナジーがある会社さん、有料フォントのサブスクリプションを行っているサービスさん、なにかしら協業したりできればと思っていますので心当たりある方はご連絡いただけると幸いです。

まとめ

こんな感じで個人で作ったサービスをどのように作っているかというのを、カレンダーに登録したメンバーも書いていってくれます!明日は「Nyaaanを支える技術」でmorixさん!頼んだ!

また、カレンダーにはまだ空きがありますので、参加したいからは遠慮なくどうぞ!!!

crieit.net