フロントエンドの地獄

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

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

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

個人開発のモチベーションが続かない、作り終わらない。原因と対策を考えてみた。

運営者ギルドという、個人や少人数チームでWebサービスやアプリを作っている人のSlackチームがありまして、そこで furuta さんやnaichi さんとチャットしていて、個人サービスを作っていて「モチベーションが続かない」「いつの間にか辛くなってくる」という個人開発あるあるについて話していました。

個人開発は「自分の作りたいもの」「自分の使いたい技術」「自分の好き」に作れる最高の舞台です。クリエイターならやらない手はないでしょう。

しかし、何も考えずにいざ足を踏み入れてみると、思ったよりも険しい道だと気づくのです。

仕事でもなく「自分が作りたくて作っていた」はずなのに、いつの間にかどこかに逃げ出してしまうモチベーション。何ヶ月経っても作り終わらない現代のサグラダ・ファミリア。仕事がバタついて1週間面倒見ていなかっただけで「え、なにこのクソコード」と毒づいてしまうほど荒れ果てたmasterブランチ。あのころ目指していた「一発当てて平日昼間から温かいこたつでレディボーデンを頬張っている自分の姿」はどこへやら。

そんな目も当てられない状況、私にもありました。振り返ってみて「どうしてこうなった。」とならないために、原因と対策を考えてみたのでみなさんのご参考になればと思います。

構想がでかすぎて作りきれない

まずこれ。

「すっげーいいアイディア思いついた!!!」ってテンション上がって「どうせなら高いレンタルサーバー借りよう」とか(そもそも借りるのは公開直前でいい)言い出してて気づいていない落とし穴。

スケールがデカイのはいいことですが、本当にそれは自分ひとりで作りきれるサイズ感でしょうか。

1ヶ月で作りきれるものにしよう

職業プログラマなら、なんとなく自分の工数計算できるはず。

1ヶ月空いてる時間すべてつぎ込んでも作れないようなものなら、考え直したほうがいい。ほぼ確実にガウディる。

削るところは削ってまずはMVPを出す

作れる人はいいんだけど、そうじゃない人は1ヶ月で作りきれるMVPをまずは考えてみよう。

例えばTwitterみたいなサービスを作るとするなら、ログインもマイページもフォロー機能も一旦置いておいて、投稿画面とその一覧画面だけを作ってどんな感じになるかを見てみよう。

ログインして、マイページで自己紹介文を編集して、ユーザー画像を変更できるように画像アップロード機能を作って・・・とかやってるうちに大概モチベーションはどっか行きます

ひとまずそのサービスで一番コアになる部分を分かるように作りましょ!

公開できる部分に切って、そこだけ作ってユーザーテストする

そんな感じでMVPが出来たら、知り合いに見せてみましょう。

TOPページの説明は無いから自分でざっくり説明してから投稿画面を触ってもらいましょう。

「よくわかんないね。hahaha」とか「これってtwitterと何が違うの?」とか言われて落ち込むかもしれません。

でも「あ〜これ、こういう使い方もできるね」「逆ににゃーんしか呟けないようにしたら?」とか意見がもらえるかも。

モチベーションが逃げちゃわないように、少しづつでもいいのでそういったプラスな声を聞いて歩みを止めないようにしましょう。

作る時間をしっかりとれるように計画しよう

あとは進めていくウチに中だるみするのを防ぐために「一人開発合宿!」とか叫びながら「ビジネスホテルにPCだけ持って一泊する」みたいなのをやってみてもいいかも。

とにかく時間を確保しないことには進捗は生まれないので、上司に媚びを売るための会社の忘年会なんか行ってる場合じゃないんですよ!

技術的にしんどい

次は作ってみたら思ったより難しくって「ProgateとRailsチュートリアルを終わらせた俺に作れないものなど無いはずなのに。。。」みたいな気持ちが生まれてしまうやつ。

ここに書いてあることを頭にいれて、心が折れるのを未然に防ぎましょう。

未経験な技術はできるだけ使わない、使っても1つだけにしよう

基本的に全部未経験みたいなのでやろうとするのは個人開発アンチパターンです。よっぽど作りたいものじゃないと作りきれません。

ここは的を絞って、ちょっと背伸びすれば作れるレベルのものにして、壮大な構想は後にとっておきましょう。「千里の道も一歩」からです。

技術習得と、新規開発はできるだけ分離しよう

それでも結局、自分の作れる範囲のものなんて作っても仕方がない・大したものが作れないとなってしまったら、技術習得と、新規開発はできるだけ分離しましょう。

これは、「習得をマイルストーンにしてないと、開発していて新しい技術を習得している過程では、開発が全く進んでないように見えて心が病んでしまう」のを未然に防ぐためです。

習得していく技術については、別途技術習得チェックリストを作って、開発のtodoと別で積み上がっていくのが見えるようにしておくといいと思います。

また「技術習得のために作っている」というパターンならあまり心配ないですが。作れなくとも技術を習得できれば目標は達成ですから。

汚いコードでも、まずは動くものを作ってからリファクタリングしよう

「完璧を目指すよりまず終わらせろ Done is better than perfect.」

ってやつですね。ひとまず動くものを書きましょう。

動的な部分も静的なもので一旦作る

ひとまず後から入るであろう数字とか、まずは決め打ちで書いてしまって後から直しましょう。

細部にこだわるより一旦全体を通して使えるものにするのが先です!

デザインを別で作ってるなら、その部分はもう画像貼って終わりにして、後からコードにおこすとかもいいですね。

一旦PCだけ対応 、iOSだけ対応とかにする

レスポンシブ対応とかはまだまだ先でいいですよ。

このご時世一旦スマホで見れるものを作ったったらええんや!

CSS一切書かないでコアな部分だけ先に作る

「CSS書くの辛いマン」の人手を上げて〜

一旦bootstrapとかCSSフレームワークを突っ込んだだけにしておいて、あとから書きましょ。ね?

外注する

絶対作ってやるぞ!って場合にはもう自分が苦手な部分は外注してみましょう。

あとは例えばクイズを誰でも作れるサービスみたいな、CGMを作る場合なんかはコンテンツを外注してみて、10問でも人が作ったデータが入ってるとそれっぽい感じになります。

作ってる間に似たようなサービスが先に出てきた

これもあるある。個人だろうが仕事だろうがあるんですよね。

Webサービスなんてだいたい「掲示板」ですから。カキコしたら一緒ですよ。

同じ事を考える人はたくさんいるので、気にしない

「Google は18番目の検索エンジン」

今日はこれだけ覚えて帰ってください。

Webサービスなんていう狭い枠組みで考えてたらそりゃあ被りますよw

それでも全く同じサービスにはならない

機能は似ていても、思想まで一致するってことはないんじゃないかと思います。

facebookもTwitterも結局なんか書き込んでタイムラインにするだけなのに、いつの間にかこんなに違う。

思想が違うと方向性も変わってくるので、しっかり自分の考えを固めて振り返ってみるといいと思います。

チームでやっていて、他のメンバーが動かない or 自分の負担が大きい

これは個人じゃない場合なんですが、人によってモチベーションもかけられる時間もコストもリスクも変わっちゃうんですよね。

チームを小さくする

まぁ煩わしいなと思ったらさっさと解散しましょう。時間の無駄です。またなんか思いついたときに集まればいいじゃないですか。

もし続けたいメンバーがいたら、そのときにある資産を誰が持ち帰るかだけもめないようにしましょう。

作ったけど誰にも使われなくて悲しい

これは今度作りきった後なんだけど、色々頑張って作ったものの使われないのは悲しい。

でも一つのものを作り切るってすごいことですから、思い入れがあるなら今までの努力を無駄にしないようにもうちょっとだけ頑張ってみましょうよ。

自分でとにかく使う

まずは「自分が欲しくて作った」んじゃないですかね?使ってみて、少しでもいいところがあったらまた友達に見せてみたりしてもいいですし、色々使ってみてると「あ、こんな使いかたできるかも」とか「横展開してこういうのできそう」とか思いついたりもします。

あのtwitterトレンドにぽこぽこ出てくるアプリ☆メーカーも、最初は流行るまで何ヶ月もひたすら自分たちでコンテンツを作り続けたらしいですよ。

自分が欲しい部分をとにかく作る

使いまくっていると今度は「コレも欲しい」「あれも欲しい」となってくるはず。

自分がファーストユーザーになれないサービスなんて作っても全然面白くないですから、自分のための機能どんどん作っちゃいましょうw

最悪自分のための最高のサービスになってもいいじゃないですか。

他の開発者と交流する

(11/25追記)

Twitterでwebサービスを作ろうとしている人と交流するってのもいいかもしれません。 駆け出しエンジニアと繋がりたい人たくさんいますし、同じようにwebサービス作りたい方を探してお互いに意見出し合うとかもいいですね。

また、冒頭で出てきた運営者ギルドは個人レベルでwebサービスを作っている、作ろうとしている人達のコミュニティなので そこで他の個人サービス運営はどうやってるのかなーとのぞいてみたり、意見をもらってもいいかもしれません。

有料ですが入江開発室というのもそんな感じのコミュニティみたいです。

まとめ

こんな感じで私の考える、個人サービスのモチベーション問題を未然に防ぐ・発生してもどうにかするための方法を書いてみました。

個人で作れるものの範囲が年々大きくなっていくWeb業界ですが、華々しくデビューを飾るサービスの裏にはたくさんの折れた心達があります。

モチベーションとか関係なく作れちゃう人はいいんですが「Webサービス作ってみたい!」って人は挑戦する前に少し心がけてもらって、心を折らずに作りきって欲しいと思います!

終わり

【私信】今年やったこととか、これからやりたいこととか

最近バタバタしていて全然振り返れてないので、自分と身内向けの内容ですが、頭の整理がてら書いています。

公開するのは、なにかしらここに書いた内容で「これ面白そうだから一緒にやりたい!」とか「これ困ってるならこれを読んだほうがいいよ!」というアドバイスがもらえる事を期待してのことです。

なので「お前誰やねん」という方は回れ右してください🙇‍

今年やれたこと

  • 法人化
  • 出版
  • ちゃんと使われるWebサービスをリリース

法人化

1月に妻と二人で法人を立ち上げました。

もともとは前に退職エントリーにも書いた通り妻のブログなどのメディア運営を手伝うために、会社をやめてコミットする形に。

とはいえ私も受託とかをやらないとあまり新しい技術を触らなくなってしまうため、今は週3日受託開発、後は妻のメディアのサポートや本書いたりWebサービス作ったりしています。 (といいつつ、先月は技術書典の準備、今月は月末に1週間旅行に行くために週4日稼働に調整しているため最近全く手伝えていませんw)

出版

技術書典というイベントで書いていた技術同人誌にインプレスR&Dさんから声を書けてもらって本を出しました。買ってくれた人へのサポートとかも含めて色々やっています。

またその次の技術同人誌を、カヤック時代の同僚達と書いたのでよかったらどうぞ。

ちゃんと使われるWebサービスをリリース

ためしがきというサービスが7月のローンチ時にすごくバズってTwitterトレンドに載ったり2000はてブとかになりました。ありがとうございます。

ただバズるだけのサービスって「初速はいいんだけどその後使われない」ってあるあるだと思うんですが、そもそもがバズコンテンツはおまけでフォントを試すツール系のサービスなので、PVはもちろん多くないですが継続して使われています。

(今までたくさんWebサービス作ってますが、全然使われないのばっかりだったのですよ!笑)

直近やりたいこと

今年中に全部は多分やりきれないので、半年くらいをめどにある程度出来ていたいお気持ち。気持ちはあるよ。気持ちはね。

Webサービスをしっかり収益化

アプリーチというサービスとかも作ってるんですが、それも含めてちゃんと収益化したいですね。

有料プランとか、広告枠の販売とか色々あると思うんですが、時間がとれてなくて進められていません。(そもそもためしがきはフォントの追加作業がまだ3分の1くらい)

サービス自体を売却ってのも全然アリです。

さらに他にサービスとかアプリも作っていきたい・・・!(すださんとやろうって言ってるやつとかビジモ図解とか止まっている・・・)

エンジニアとしてのスキルセット

最近はReactNativeを書いてて、それに合わせてWebもReact.jsにして、、、という感じなのでVue.jsあまり書いてないのです><

  • ReactNative(Expo)
  • TypeScript
  • JavaScriptのテスト駆動開発
  • Firebaseを使ったサービスの設計(NoSQLのDB設計とか)
  • 中規模以上のSPAサイトの設計

この辺り実務をやりつつも課題意識があるので、技術顧問的に相談とかのれるレベルになりたいと思っています。なんかオススメの書籍とかあったら教えてください!(技術書典5のこの辺の話題の本はだいたい買ったと思うw)

んで、そのために本読んだり実際に手を動かしながら考えてみたり。。。でもやっぱり色々人に相談したいよな〜

ゆるいチームを組む

というのも踏まえて、フリーランス的に働いているとどうしても一人でゴリゴリやって終わりーとなりがちなので、フロントエンド周りの人でチームを組んで技術相談ができる場所とかを作りたいな〜。

会社員の人でも、会社の中でコミュニティが閉じてるとちょっと不安ないですか?

為藤さんがそういう取り組みをしようとしてて誘ってもらってるのとか、たじーと一瞬そういう話出たけどやってないのとか、この辺同じような課題意識がある方いましたら(会社員フリーランス問わず)なんかお話できればと思っています。

あと今年は少なくとも今持ってる仕事以外受けれないので、追加の相談とか来たときに信頼できるエンジニアにそのままパス出来たらな〜というのもあります。フロントの仕事くれって人も教えて(最近副業やるマン増えてると思うので)

長期スパンでやりたいこと・やるかもしれないこと

東京にいつまで住むのか問題

後1年ちょいしたら子どもも小学校なので、そのタイミングで引っ越しは少なくともしたい(家がいよいよもって狭い)

妻の実家の近く(大阪)に住むとか、福岡良さそうじゃないかとか、なんだかなんだ満員電車乗らないあから東京便利すぎる〜とかあるので、場所も含めて考えていきたい。

自分の作ってるWebサービスだけで飯食ってけるレベルにする

サービス売却も含めて、ある程度その辺でちゃんと収入を得られる体制にしたいぞ〜Inkdropの人みたいに私も「週休7日で働きたい」ですね。

ボドゲを作るとか、絵本を作るとか、世界一周したな〜とかぼんやり。

音楽を再開するとかも。昔はライブハウスでライブしてたりしてたんですが、バンド組むのは大変なのでDTMおじさんになるとか。

なんか趣味らしい趣味が最近無いからなんかしたいですね。Webサービス開発も趣味だけど。クソアプリアドベントカレンダーに向けて助走を開始しておいたりも。

あと全然体動かさないからボルダリング再開もしたい。やってる人いたら教えて!

以上です。

Twitterだと収まらないScrapbox的ブログでした。技術ブログとかを期待して購読している方はすいません><

静的サイトを公開するならNetlifyでしょ!って本出すよ! #技術書典

やぁやぁみなさん!3連休いかがお過ごしでしょうか!?台風も関東直撃しなかったから安心して外に出れますね〜

nabettu.hatenablog.com

こないだ625はてブもついて好評だった↑の記事なんですが、一言で言うと静的サイト公開するならNetlifyがめっちゃ手軽でいいよ!って記事だったのですが、この度 10月8日(月)に開催される技術書典5で、そのNetlifyを詳しく紹介する技術同人誌を売りますので、紹介させてください!

どんな本?

「ゼロから始めるNetlify」と題して、Netlifyの豊富な機能をまるっと紹介する本になっております。

Netlifyにはサイトホスティング以外にも下記の色々機能が備わっていまして、それぞれについて実例や、実装時の実際のコード等も含めて紹介しています。

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

まだ使ったことがなかった方はもちろん、使ったことがあるかたも「実はこんな機能があったのか・・・!」と発見ができる内容となっていると思います。

冊子版・電子版がそれぞれ1000円、セットで1500円となっております。(電子版はダウンロードカードになります。)

イカれたメンバーを紹介するぜ!

今回は私ともう二人、前職の面白法人カヤックのHTMLファイ部のリーダーのびーさんと、若手エースひめちゃんの2人と力を合わせて3人で分担して執筆しました!

更に表紙は前回に引き続きイラスト&デザインを一人でこなすスーパーウーマンのタカユリさんが担当しました。

更に表紙のNetlifyを擬人化したキャラクター、ねっとりさんの描き下ろし漫画も収録!計72ページのなかなかのボリュームになりました。

↓こちらがサークルページへのリンクとなっておりますので、ぜひログイン・サークルチェックして当日お忘れないように!

techbookfest.org

他にも頒布します!

前回の技術書典で好評で、インプレスR&D社から商業出版を果たした #Webサービスを作る本 こと「Vue.jsとFirebaseで作るミニWebサービス」を、会場特価の1500円で販売します。

こちら誤字等を修正した改訂版がなんと昨日発売になったのですが、その改訂内容とFirestoreへの移行マニュアルを小冊子としてセットにしますので、ご安心ください!

さらにタカユリさんが以前にデザフェスで頒布した「フォント擬人化イラストイラスト・設定集」も500円で販売しております!

↓こちらがお品書きになっております! f:id:tatsuaki_w:20181006170726p:plain

しかも特典がつくよ!

先着約300名様に表紙のねっとりさんポストカードもプレゼント!レトロ印刷ですごくいい感じ!

イベント以外での販売はあるの?

一応終わって一段落したら、BoothやCodespotを利用して販売する予定です!(予定ですが、ダウンロードカードもかわいく出来ているので、ぜひ会場に足を運んでいただけると・・・!笑)

技術書典はどんなイベントでどこでやるの?

行ったことないけど気になっている人はこちらのもちこさんの記事がめっちゃまとまっていていい感じですので、まだの方はご一読ください。

note.mu

以上です。

みなさん3連休最終日の10月8日(月)は池袋で技術書を買いあさりましょう!よろしくお願いします!!!

静的サイトを公開するならどこがいいの? #技術書典

静的サイト(PHPやRubyなどのサーバープログラムを走らせない環境でのWebサイト)でSPAを公開するにあたって、運用・配信(ホスティング)するならどこがいいかと最近聞かれまして、その際の回答を技術書典の宣伝も兼ねてブログにしたためます。

今回は次の4つで比較しています。

  • GitHub Pages
  • Firebase Hosting
  • GitLab Pages
  • Netlify

上記4つはどれも独自ドメインの設定とSSL対応が無料で行うことが出来ます。

※比較的初心者に向けて書いている前提です。

AWS S3やGCP等の利用は初心者がいきなり設定を行うには項目が多いため除外しています。

レンタルサーバーも基本料金が発生し、スケール・管理し辛いため今回は除外しています。

また、少し機能について説明が必要な部分があるので、先に説明を書きます。

Rewrite設定について

静的サイト化したSPAを公開する際にありがちなミスなのですが、URLを変更してサブディレクトに進んでからリロードすると404ページになってしまうというものです。

これは公開サイトでページの404のRewrite設定が出来ていない場合に起こってしまう事象です。

「ファイルの読み込み時に404だったら index.html を返す設定」をすることで、リロードしても継続してサイト閲覧することが可能になります。(その場合はJavaScriptで404ページかどうかを判定します。)

設定が出来ない環境でSPAのルーティングを利用する場合はハッシュルーターにする必要があります。

ビルド機能について

プロジェクトによってはWebpackなどを利用して、html,css,jsファイルをコンパイル(トランスパイル)してから公開すると思います。

そのときにビルド機能がついている環境の場合は、「手元でビルドしたものをgitで管理したり、Circle CIなどでビルドしてdeployする」等の手間が省けます。

テストを書いていたらテストが通るかどうかなどもそこでチェックして、デプロイするかどうかを選択できたりもします。

各サービスの機能を紹介

GitHub Pages

  • とにかくタダで使えます!
  • 使えますが、下記の記事のような制限があります

GitHub Pagesでホストするサイトのアクセス上限は月10万リクエストが目安

  • 設定した特定のブランチが自動で公開されるので管理が楽。
  • ×: SPA用のRewrite設定不可
  • ×: ビルド機能無し

Firebase Hosting

  • △: たくさんアクセスがあるとデータ容量に応じて課金が必要になります

(無料枠で利用していて制限まで行ったら、通知が来るのみで勝手に課金されるようなことはありません。)

  • SPA用のRewrite設定可能
  • 特定のパスをFirebase Functionsに繋ぐことができる
  • ×: ビルド機能無し

GitLab Pages

  • とにかくタダで使える
  • SPA用のRewrite設定可能
  • 特定のブランチが自動公開できて管理が楽
  • ビルド機能アリ

Netlify

  • とにかくタダで使える
  • SPA用のRewrite設定可能
  • GitHubやGitLabと連携して、静的サイトを自動で公開可能
  • ビルド機能アリ
  • 特定のパスにAWS lambda(Netlify Functions)接続可能

まとめ

すでにGitHub、GitLabでソースを管理しているとして、ライブラリのリファレンスなどのちょっとしたサイトならそれぞれのPages機能を使うと手軽です。

Firebaseを利用していて、FunctionsとパスをつなぎたいならFirebase Hostingを利用しましょう。しかしビルド機能がないので必要な場合はCircle CIなどと併用が必要です。

他、Firebase Functionsとつなぎたい場合を除いて便利な機能が揃っているNetlifyをおすすめしています。Netlifyには他にもたくさんの便利な機能が備わっています。

Netlifyの上記以外便利機能紹介

  • ブランチ毎に自動でサイトを公開できる(プルリクを確認するときなど便利)
  • Webhookでビルドしたり、ビルドしてデプロイしたらSlackに通知する(GitLabも可能)
  • ブランチごとのA/Bテスト用に出し分けができる
  • サーバーサイドレンダリングしないSPAでも、コンテンツに応じてOGP画像などのmeta情報を出し分けられる(Prerendering機能)
  • 静的サイトであるあるな「フォームだけ設置したい」場合もNetlify Formが利用できる
  • ブログなどを作りたい場合にコンテンツを管理できるNetlify CMSもあります

他にもチーム開発で必要な機能や、BASIC認証の設定(有料)など様々な静的サイト公開に便利な機能が備わっています!

ということで宣伝

そんなNetlifyの様々な機能を1から10までほぼ全て実例を使って解説する本を今度の10月8日に開催される技術書典で販売しますので、いらっしゃる方はログインして下記のページをチェックしてぜひぜひ買いに来てください!!!

techbookfest.org

以上ですが、本買わなくともNetlifyはめっちゃ便利なので一度使ってみて下さい!

【書評】React Native+Expoではじめるスマホアプリ開発

React Native+Expoではじめるスマホアプリ開発 ~JavaScriptによるアプリ構築の実際~

React Native+Expoではじめるスマホアプリ開発 ~JavaScriptによるアプリ構築の実際~

これです。重い(固定レイアウトが苦手なので紙で買った)。

380ページあるので読み応えは結構あります。半分くらいを写経しつつ、あとはコードを読みました。

読んだ感じのレベル感・ターゲット層

  • JavaScript概ね書ける
  • React触ったことある

くらいじゃないと流石にキツイ。

すでに380ページあるので、JSの初心者向けに解説書いてたら倍の厚さになってしまうので仕方ないですね。

なので流石にReact触ったこと無い人はついていけないので買わないほうがいいですね。

あとはReact Native特有のハマりどころみたいなのがあるんですが、その辺りをある程度自己解決できないと、ちょっとtypoしたら謎のエラー出てハマります笑

ただ、React Nativeを直接触るよりもExpoを使うことでかなりマイルドになっているので、Reactの基本概念とES6以降の書き方が分かってれば結構ちゃんと動くアプリが作れます。

内容

TodoアプリやMapアプリを作りながらサンプルをもとに進めていく感じです。

ただ、色々なAPIを利用したサンプル集という感じが強く、ある程度以上の規模のアプリを作る際に「この先どうしたらいいんだ・・・」となる未来が見える。

本ではReduxの触りだけ触れているので、規模が大きくなるものについてはReact自体での大規模Webアプリの設計がある程度持ってこれるのでそっちはそっちで勉強しましょうという感じですね。

良かったところ

1冊で割と幅広いタイプのアプリを作れるようになるのはいいですね。

あとから「地図入れる事になったから見返そう」とかなりそうな気がします。

特にWebViewとの組み合わせの章など、Expoで出来ないことをWebViewで補うとかは結構ありそうなパターンなので。

いまひとつだと思ったところ

もうちょっとExpoというプラットフォームについて触れたり、特有の機能(Push周りとか)について触れてほしかったですね。

Nativeモジュールの導入やストアでの公開方法はいいんですが、Expo上での配布なども解説欲しいですね。概ねReact Nativeの技術書であって、Expoについてはおまけレベルな気がします。

あとはサンプルで使う駅すぱあとAPIは「申請してから使えるまで数日かかります」とありますが、著者が使い慣れているからと言っても他にもっと楽にすぐ使えるAPIなかったんでしょうか。

React Native+Expoではじめるスマホアプリ開発 ~JavaScriptによるアプリ構築の実際~

React Native+Expoではじめるスマホアプリ開発 ~JavaScriptによるアプリ構築の実際~

全体としてReact書けてアプリもやるぞ〜ってWebフロントエンドエンジニアの人には、今後Expoどんどん良くなっていくのでおすすめできると思います!

初心者はまずReactの概念をかじってから触ろう!

著書「Vue.jsとFirebaseで作るミニWebサービス」が発売されました!🎉本に込めた想いと経緯など

技術書典に参加の際に書き下ろし、Boothなど売っていた技術同人誌の商業版がこの度無事に発売されました🎉

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

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

みなさんありがとうございます🙇密林デビューしました!

なんで本書いたの?

そもそも私自身Webサービスってものが大好きで個人でも色々作ってまして。

いくつも作っていく上で「この構成で作ると手軽に始められるし、スケールもしやすい」という自身のノウハウを共有したいと思いまして、それをまとめたのが本書になっております。

サービスを作って人に使ってもらうってめっちゃ楽しいからみんなやろうぜ ってのを伝えたいなってのがまず最初にありまして、

「でもWebサービス開発って結構ハードル高いんでしょう?」って人も一回小さいものを作ってみるとなんとなく流れがわかるので最小限のコンパクトな形にまとめました。

とにかくサービスを作ってみたい!って人はアイディアに集中するためにこういう便利なの使っていくとアイディアに集中出来ますし、

エンジニアの人でそれぞれの技術に興味があるから触ってみたいって人にも触りながら手軽に形にできるのでオススメできます!

FirebaseとVue.js自体の普及もしたかったので、色んな人に届くように同人誌のままで安い値段で提供するよりも出版社からたくさんの人にリーチしてもらったほうがいいだろうという事で出版いたしました。(同人誌だけだと自分の周りの人プラスアルファにしか届けられていないかなと思いまして)

あ、次回技術書典の応募は明後日までなので、技術書を作って売るという経験をするには最高のイベントなので早く応募したほうがいいですよ。

↓ここから応募できます。

https://techbookfest.org/techbookfest.org

それで、Firebaseってなにがいいの?

Firebaseを使うと身長が10cm伸びてめちゃモテるとか話題になってますが、、、

そんなネタはおいておいても、Firebaseは本当に素晴らしいサービスで、Google様に感謝しながらこれを使うとWebサービスを作っていく上で集中すべき事に集中できるようになって素晴らしいです。

Firebaseで年収1000万?というもの、実際今まで二人エンジニアが必要だったレベルのものが一人で済むようになっているのは事実です。(Rails ☓ Herokuとかと同じ話しではありますが)

SNSやメールでのログイン機能・データベースやストレージ、サイトホスティングなど、Webサービスを作る上で今までサーバーサイドプログラムが必要だったものこれ一本で済むのです!驚き

(実は昔私Firebaseみたいなサービスを作ってた事があるんですよ。Twitter連携を使ったWebサービスをたくさん作っていたので、その認証部分だけを利用できるようなやつ。結果私しか使わなくて閉じちゃったんですが。)

もちろんFirebaseにも苦手な部分もあり、DBに対するクエリはそんなに強くないので別途補ってあげる必要はありますが、そうでない状況でクライアントサイドがメインのエンジニアがサービスを作るとなると今はこれ一択ですね。(aws cognitoも対抗できるくらい使いやすくなってくれたらいいのだけど、、、)

Vue.jsはなにがいいの?

もう一方のVue.jsですが、こちらは流行りのSPAのライブラリの一つです。

SPAってそもそもなに?って人向けにも本書ではしっかり説明を入れているので、前提がわからない人も安心できますよ〜(宣伝)

こちらもReact,Angularと比べて得意不得意ありますが、とっつきやすさで言えば一番よいので、「初めてSPAを作ってみる」という人にはピッタリなんじゃないかと思って勧めています!フロントエンド玄人なフレンズは本書のライブラリをHyperappに置き換えたりしてFirebaseだけでも触れてってくれ!


他のSPAライブラリもざっくり触ってみたい!って人にはパンダ本がオススメです!

React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発

React、Angular、Vue.js、React Nativeを使って学ぶ はじめてのフロントエンド開発

  • 作者: 原一浩,taisa,小松大輔,永井孝,池内孝啓,新井正貴,橋本安司,日野洋一郎
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/05/09
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

Vue.jsについて更に深掘りしたいって人には次は猫本もオススメです。

基礎から学ぶ Vue.js

基礎から学ぶ Vue.js

まとめ

こんな感じでとにかくWebサービス作ると楽しいし勉強になるし、作ってみたい人は応援したいし、推しの技術をみんなに使ってもらいたいという色んな気持ちが具現化した本なのでまぁとにかく買ってってくださいよ。

技術的にはProgateでHTML,CSS,JSを勉強した人なら大体オッケーなレベル感になっています!

ある程度売れたらその売上で今度は学割とかの企画を考えて行きたいな〜どこかまとまって勉強会みたいにやってもいいし、とにかく面白いWebサービスを作る人が増えたら嬉しいなと思っています。

~ Fin. ~