no strict

ちゃんとしない。面白いことからやる。

自分を理解し意見を発信することが人生を切り開く:書評「自分の意見で生きていこう」

ちきりん氏が過去10年に及んで実践してきた、「自分の意見にとって選んできた、自分だけの人生」の作り方の解説本。

自分がどのような意見を持っている人間なのかを知るために、まずは情報を元に考えたこと・感じたことを整理しまとめることで、自分を理解し自己肯定を行うことができる。 また、自分が深く理解しているまとまった自分の意見を外部に発信することで、承認欲求を満たすことができる。

自分の内面情報を広く深く他者に伝えることはとても時間がかかるので、かつては近しい人しか自分の本質を理解することができなかった。だが、ネットを用いて自分が考えたこと(意見)を発信することで、理解者を数多く作ることができる。これがコンテンツにもなり、人生を切り開くツールにもなる、という話。

当時から私の日記は(中略)行動の記録ではありませんでした。そうではなく「今日はこのコトについてこう考えた」とか、「今日知ったある事件について、こう感じた」という、自分の感情や思考の記録だったのです。 (中略) そうすることのモチベーションはどこにあったのでしょう? 端的に言えばそれは「自分で自分という人間を理解したい」という欲求に基づくものでした。つまりは自分自身のため、「自我の確立のため」だったのです。(P163)

という下りが目からウロコでした。自分という人間を理解するプロセスを考えたことがありませんでした。

「自分の考えていることを自分で理解するために思考を整理し、それを発信することが理解者の獲得につながり、それこそが人生を切り開いていく」というシンプルなメッセージなのですが、著者の実体験に基づく自伝のようなものであることから説得力を感じます。

自分には、意見を外部に発信することをリスクと感じ、なるべくオリジナルの意見を出さないようにすることで周囲に同調して軋轢を避ける、という生き方をしてきた部分があるのだと気付かされる本でした。

まずは自分から、「こういうことに興味がある!」「自分の考えはこうだ!」と発信してみるのです。そうすれば、「実は自分もそれについて興味がある。しっかり考えてみたかった!」という人が身近な場所からもきっと見つかることでしょう。 (中略) そうすれば人生はごく自然に「自分の意見にとって選んできた、自分だけの人生」になっていきます。そして、「自分でしっかりと考えてこの道を選んできた」という自覚こそが人生に誇りと自信を与えてくれるのです。

という提言に完全同意。

今後は意見を明らかにし、なるべくポジションをとるように動いていこうと思います。

デスクの高さと床を変えたら集中できるようになった話

自宅で集中して作業することができない

長い間、自宅のデスクで集中して作業することができませんでした。

自宅ではできないのに、カフェやファミレスや図書館では勉強や読書や仕事が捗る。自宅は怠ける誘惑が多く、適度に他人がいて居眠りもできない環境が自分に合っているのだと思い、集中して作業する必要がある時にはコメダ珈琲デニーズやルノアールや図書館を利用する生活を続けてきました。

COVID-19でほぼ完全に在宅の業務スタイルに変化しても、集中したい時はなるべく外出して作業する日々。費用はかかるけれど、必要なコストだと割り切って過ごしてきました。

オフィスではもっと集中できた気がするのに、自宅だとできない。仕事は自宅でもこなせるのですが、趣味でパソコンを触り続けることができないのです。

そんなある日、浅草橋のWORKAHOLICのチェアコンシェルジュサービスを受けてみたところ自宅のデスク環境に問題があることが判明しました。お店で教えてもらったベストポジションは、普段の自宅での姿勢とは全く異なり非常に快適でリラックスできるものでした。

原因

自宅のデスク環境は、高さ74cmのデスクにポリカーボネートのチェアマット、それにアーロンチェアという構成です。

WORKAHOLICで指南して頂いた問題点は以下の2点

  1. デスクが高すぎる。身長177に最適なデスクの高さは70cm
  2. 床がつるつるだとチェアが滑ってしまい姿勢が保持できない。カーペットを敷くことが必要

対処

早速、カーペットを敷き、デスクの脚を買い直して高さ70cmに修正したところ、姿勢が劇的に改善しました。デスクの高低差はわずか4cmですが、高さを4cm下げるだけでまるで別世界のようにデスクでの姿勢が変化したことが驚きです。

しっかりと腰が支えられている感覚、足の裏でしっかりと床をつかんでいる感覚、手首が机に張り付くような安定感、無理のない腕と肩の位置など、姿勢のすべてが変化しました。まだ変更して1週間ですが、キーボードで書き物をしても集中力が持続できるようになった気がします。

また、滑る床ではなくカーペットにしたことも姿勢の安定にはとても重要でした。チェアコンシェルジュサービスを受ける前は問題はチェア側だと考えていたのですが、主原因はデスクと床だったようです。

教訓

自宅でパソコン作業ができないのは自分の怠慢・気力不足のせいだと思っていましたが、姿勢の問題が大きかったことに長い間気づけなかったことは、これまでの期間を考えると実に残念。もしこの環境が以前からあれば、もっと多くのブログを書いたりアプリを書いたりできたかもしれません。

集中力を構成する要素はメンタル面だけでなく環境面も大きいことを痛感しました。「できないから気合で頑張る」前に、環境の問題を解決することを考えるべきでした。

デスクワーク姿勢の覚え書き

(1)デスクの高さは70cm「以下」にすること

身長によって異なる。キーボードを叩く最適な高さは65〜68あたりの場合も。

(2)「必ず」カーペットを敷くこと

フローリング、チェアでは姿勢を保持できない

(3)腕をおろして肘の角度を90度にした高さにアームレストをもってくること

アームレストを下げてデスクに腕を乗せる形も可。

(4)チェアに腰を密着させること

座り方の基本。

(5)膝の角度はやや90度以上。足の裏が地面をつかむ高さにすること

デスクが高すぎ→チェアが高すぎ→足が浮きがち。 フットレストでも多少は改善しましたが、足の位置の自由度が低いことが問題。適切なデスクの高さでないとこの角度になりません。

(6)モニターは違和感のない距離に調整すること

モニターアームの費用対効果は高い。

今後

オフィスでワークしていた時と同程度に集中できる環境を自宅に作ることはできたのですが、自分は少し後傾よりのポジションが好みなのでアーロンチェアではないほうが良い気がしてきました。アーロンチェアは良いものなのですが前傾姿勢での使用が前提となっていたりと集中するためのチェアという性格であり、仕事の合間のリラックスには向かないような印象があります。

元々ヤフオクで捨て値で買ったものでもあるので、次はワーキングチェアを刷新して更にしっくりくる環境にグレードアップしていこうと思います。

エヴァンゲリオンにさよならを言うためのウェブサービスを作ってみた

3月8日にシン・エヴァンゲリオン劇場版されてから早4ヶ月。そろそろ終映が近づいてきました。

前作のQからもかなりの時間が経っているのでエヴァンゲリオンは忘れかけていたのですが、完結作であるシン・エヴァを見てTV版からの四半世紀を改めて振り返ったりと、自分の中で大きな存在だったことを思い出させてくれました。

数年もすれば、エヴァンゲリオンについての記憶はまた薄れて、いずれ消えていくでしょう。今は日本中がエヴァンゲリオンという感傷の中にいるような気がしていますが、そんな人達の衝動を書き残す場所があってもいいのではないかと思い、「寄せ書き・メッセージボード」としてのウェブサイトを作ってみました。

Next.jsとVercelに興味があったので、学習も兼ねてこの構成で開発。データを単に格納して表示するだけのサイトですが、慣れないこともあり公開までは一ヶ月かかりました。

完成したサイト↓ eva.nostrict.dev

Next.jsはルーティング周りの仕様がよく変わる問題だったり、表示の遅さだったりというReactの不満を解消してくれていて快適です。githubにpushするだけでSSL付きで公開してくれるvercelもとても簡単でした。 あえてサーバー上に環境を構築するメリットはもはやないのかもしれない、と実感します。

皆のエヴァンゲリオンという作品やキャラクターへの熱い想いが残っているうちに、メッセージが集まると良いなとおもうのですが、知ってもらうことが難しい...

プライベートで毎日コードを書いて、React Native + firebaseなアプリを開発する

以前、React + Node.jsでSPAなウェブアプリを作ってみたので、次はReact Nativeでアプリを作ってみようと思いました。主な構成は以下。サーバレス構成です。

現在は職業的プログラマではないので、コーディングに割ける時間は平日ランチタイムと夜、そして土日のみ。継続することが重要だと思い、余裕のない時でもgithubに無理やり草をはやし続けてみました。 f:id:nostrict:20190208013034p:plain

当初は半年もあれば完成すると思っていたアプリは一年以上経過しても公開に至っていませんが、開発自体はほぼ終わり、結合テストフェーズに入ったことで、ゴールが見えてきました。このあたりで、いくつかの気づきや、反省点を書き残してみます。

新しい言語を使う時は小さなプロジェクトから始めるべき。

2017年秋の時点では、スマートフォンアプリ開発の知識はゼロでした。Reactは多少触っていたものの、React Native、firebase、Algoliaの使用経験はありません。

このようなズブの素人が空き時間にReact Nativeのアプリ開発を進めた結果、このような日程となりました。開発時間は平日2時間・週末5~10時間といったところです。

  • 2017年10月:React Nativeでの画面の作り方調査
  • 2017年11月~12月:DBなしのモックアップ作成
  • 2018年1月~3月:firebase RealtimeDatabaseで仮実装(プロトタイプ)
  • 2018年4月~5月:全体のリファクタリング。firebase RealtimeDatabaseをfirestoreに変更
  • 2018年6月:検索にAlgoliaを導入
  • 2018年7月~11月:実装
  • 2018年12月~1月:UI調整
  • 2019年2月~:結合テスト

当初の3ヶ月は、ほぼReactNativeの学習期間でした。その後の3ヶ月でプロトタイプができましたが、redux/firebaseに慣れてくると初期の頃に実装したDB周りの酷さに気が付きました。リファクタリングすると同時にfirestore化&algolia導入を行ったため開発が長期化する一因となりました。 開発期間が半年を超えたあたりからモチベーションが低下してコードを書く量が減ってしまったこともあり、実装期間は4ヶ月にも及んでいます。

画面数は100以上、書いたソースコードは合計11000行以上、2019年2月8日現在のコミット数は610。最初に作るスマホアプリとしてはあまりにも規模が大きすぎるものでした。

最初は4~5画面程度の小さなアプリを作り、まず公開まで持っていくプロセスを経験しておくべきだったと思います。 (とはいえ、そのようなアプリのアイデアが思い浮かばかなった)

スキマ時間にコーディングを進めると、カオスなコードになりがち

ランチタイムの30分、平日夜の2時間など、細かい時間を見つけてコーディングするスタイルで開発を進めると、「あと15分でこの処理を動くようにしたい」というような焦りが生まれてしまい、場当たり的なコードを書きがちです。また、その後時間が取れないとその事実を忘れてしまうことも多く、全体的な整合性が失われていく結果となりました。

全体の構成を考慮して、目の前の処理を動かすことを優先するのではなく、時には後戻りするような組み立て方をするべきでした。このようなことを考えながら書くには、ある程度まとまった時間集中する必要がありますが、30分を繋いで書いていくスタイルでは難しかった。

細切れの時間で開発すると、前回何を考えていたのかを忘れがちです。個人slackプロジェクトを作ってgithubと連携し、考えていたことをメモしたりコミット内容をタイムラインに流すことで、「何をやろうとしてたんだっけ?」と思い出す時間を削減することができました。

初期にDB周りの設計をかなり細かくやっておくべきだった。

具体的にどのあたりがカオスなコードになっていったかと言えば、それはデータストア周りです。

React Nativeでは、reduxアーキテクチャ、ローカルストレージ(AsyncStorage)、firebase、algoliaという複数のデータストアの連携を意識する必要があり、RDBMSとは異なる設計が必要だと感じました。 次回アプリを作るときは、このあたりのDB設計をもう少し詳細化してから取り組むと思います。

breaking changeのつらみ

React Native系のモジュールは安定していないものが多く、たまに後方互換のないバージョンアップ(breaking change)が行われます。特にreact-navigation周りは大胆な変更が多く、ついていくのが大変でした。モジュールはなるべく最新版に追従したほうが良いと思いますが、バージョン追従にトータルで一ヶ月ほどは費やしている気がします。

現在は、毎日「npm outdated」で最新バージョンを確認し、breaking changeがあるかどうかをチェックしています。

まとめ:継続すれば素人でも大きなアプリは作れる(はず)

上記の気づきは、開発に慣れている人にとってはどれも当たり前のことだと思います。

しかし、プライベートの時間を活用して、どうにかアプリの開発を進められていることや、React Nativeならではの課題・プライベート開発ならではの課題と対策を蓄積するサイクルを継続できている点は、達成感もあります。

今後も、職業的プログラマではない、プライベートベースの開発のやり方を模索していくつもりです。

2017年に読んだ本ベスト10

2017年は通勤時間の読書が捗り、目標の100冊読破を達成できました。目標達成記念に、読んだ本ベスト10を書いてみます。ビジネスデベロップメントとアプリ開発系が多め。

第10位「マンションは10年で買い替えなさい 人口減少時代の新・住宅すごろく」

マンションは10年で買い替えなさい 人口減少時代の新・住宅すごろく (朝日新書)

マンションは10年で買い替えなさい 人口減少時代の新・住宅すごろく (朝日新書)

  • 自宅を資産を考え、資産価値が落ちにくい物件と期間を意識して購入する。
  • 常に中古価格と賃料とローン残債を意識し、基本は10年で売る。
  • 価値の下落しづらいのは広く高く駅近のタワーマンション

など、この本で自宅を資産としてみなすという視点を身につけることができた気がします。サイトでマンションの時価を公開していたりもしますが、サイトの使い勝手はいまいち。

第9位「はじめてのNode.js」

はじめてのNode.js -サーバーサイドJavaScriptでWebアプリを開発する-

はじめてのNode.js -サーバーサイドJavaScriptでWebアプリを開発する-

非同期通信のアプリを作るためにまず手に取った本。コードを10年書いていなかった当時の自分でもわかりやすく、Node.jsとSocket.ioの概要が理解できました。易しく、優しい本。

第8位「LIFE SHIFT」

LIFE SHIFT(ライフ・シフト)

LIFE SHIFT(ライフ・シフト)

長寿化時代には無形の資産に投資し、いくつかのステージを変身しながら渡り歩く必要がある、という内容に共感。寿命は伸びており、今を生きる人は100年を見据えなければいけない。かつてのロールモデルは長寿化に対応できていないため、新しいライフプランを考えなければならないということ。目からうろこでした。

第7位「WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用」

WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用

WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用

2017年3月当時に刊行されていたReactの書籍を全て読みましたが、この本が最も分かりやすかった。Reactの基礎が易しく学べます。

第6位「フェイス・トゥ・フェイス・ブック」

フェイス・トゥ・フェイス・ブック -- クチコミ・マーケティングの効果を最大限に高める秘訣

フェイス・トゥ・フェイス・ブック -- クチコミ・マーケティングの効果を最大限に高める秘訣

バイラルマーケティングの統計的・科学的な分析と豊富な事例で非常に参考になりました。なぜオフラインのクチコミが大切なのかがわかる本。翻訳のせいか、文章がちょっと読みづらいです。

第5位「MBAコースでは教えない「創刊男」の仕事術」

MBAコースでは教えない「創刊男」の仕事術

MBAコースでは教えない「創刊男」の仕事術

徹底的にヒアリングし、感情移入し、提案し、どんどん直すということが大切ということ。MBAのカリキュラムとは異なるビジネスと起業の本質が書かれています。数あるリクルート本の中でも一押し。

第4位「7つの習慣」

7つの習慣-成功には原則があった!

7つの習慣-成功には原則があった!

  • 作者: スティーブン・R.コヴィー,Stephen R. Covey,ジェームススキナー,川西茂
  • 出版社/メーカー: キングベアー出版
  • 発売日: 1996/12/25
  • メディア: 単行本
  • 購入: 148人 クリック: 4,806回
  • この商品を含むブログ (773件) を見る
人徳をどう形成するかということをロジカルに考えた本。わかりやすく納得感が高いです。さすが名著。

第3位「顧客視点の企業戦略」

顧客視点の企業戦略 -アンバサダープログラム的思考-

顧客視点の企業戦略 -アンバサダープログラム的思考-

コミュニティマーケティングの実践的な指南書。これからのマーケティングはこの本を基本にすべきなのでは、とまで感じる良書。

第2位「小さな会社・儲けのルール―ランチェスター経営7つの成功戦略」

徹底したセグメンテーション、オフラインファーストなど、中小企業の採るべき戦略が細かく書かれている本。売上5億を50億に伸ばす戦略と言えそうです。バイラルマーケティングとの親和性・関連性も高く非常に参考になる良書でした。

第1位「アントレプレナーの教科書」

アントレプレナーの教科書

アントレプレナーの教科書

* ビジョンを売る。ロードマップを提示する * 顧客アドバイザリーボードを作り、製品アドバイスをもらう。 * ビジョナリーとエバンジェリストユーザーの発掘とヒアリングがなにより大切 などなど。徹底した顧客のヒアリングと軌道修正がビジネスの成功因子だということがよくわかる本。この本で「顧客開発」という概念を知りました。手元において、折りに触れ何度も読み返すべき名著。

まとめ

10冊にまとめてみると、2017年は以下の3点を学んだと言えそうです。

  • ユーザーと向き合うマーケティングがビジネスの成功因子だということ
  • JavaScriptはサーバサイドもスマホアプリも作れる良いツールだということ
  • 長期的な人生戦略が大切だということ

コモディティ化したサービスをムダに使うと次のビジネスが見えてくる:書評「フリー」

フリー 〈無料〉からお金を生みだす新戦略

フリー 〈無料〉からお金を生みだす新戦略

YouTubeクックパッドなどのウェブサービス、フリーペーパー、無料体験コーナー、スーパーの試食コーナーなど、無料で受けられるサービスは多数あります。なぜ無料でサービスが提供できるのか、その背景にあるものは何なのか、という点を掘り下げてまとめた本。

インターネットが普及してからは特に、無料で受けられるサービスがあまりにも多く、あまりにも当たり前になってしまいました。しかし、無料サービスをマネタイズすることはとても難しいことです。フリーミアムのビジネスモデルと成り立ちを理解することは、これからのビジネスモデルを考えるにあたり必須な気もします。

本書では、潤沢に供給されるものの価値は下落し、最終的には無料になると述べています。

人々が欲するものをタダであげて、彼らがどうしても必要とするときにだけ有料で売るビジネスモデルをつくるのだ。

とのこと。無料サービスで集客して有償サービスにシフトさせるとか、広告モデルとか、フリーミアムのビジネスモデルは成功が困難であることが多いですが、コモディティ化するものは対価をとらず、希少なものでフィーを得るという考え方は納得できます。

その上で、本書ではコモディティ化による価格の低下を前提に、その活用の仕方がカギとなるとも述べています。

今日の革命者とは、新たに潤沢になったものに着目して、それをどのように浪費すればいいかを考えつく人なのだ。

例えばムーアの法則により半導体の性能は年々向上し、CPU性能はある程度ムダに使ってもコスト的に問題ないものとなりました。開発手法で言えば富豪的プログラミングが可能となったわけです。 同じように、情報や人件費など、コモディティ化し、価格がゼロに近づいたものを思い切り使うことでそれまでできなかったことができるようになります。これまでの市場を理解している人であればあるほど、かつて希少で高価だったものは大切に、節約して使ってしまう。このようなものを意図的に浪費することで、事業機会が生まれるというわけです。 コモディティ化するサービスについては、多くの人にメンタルブロックがあるとも言えそうです。

本書ではこうまとめています。

フリーと競争するには、潤沢なものを素通りしてその近くで希少なものを見つけることだ。ソフトウェアが無料なら、サポートを売る。(中略)もしも自分のスキルがソフトウェアにとって代わられたことでコモディティ化したならば、まだコモディティ化されていない上流にのぼって行って、人間が直接かかわる必要のある、より複雑な問題解決に挑めばいい。

無料に見えるサービスはコモディティ化しているものであり、思い切り浪費することで何ができるのか、または無料の周辺に「希少なもの」が眠っている可能性がないか、などと思いを巡らせてみると新たなビジネスチャンスが見えてきそうです。

多くの気づきが得られた良書でした。

ランチタイムを開発の時間に当てたら半年でNode.js+Socket.io+Reactを使ったウェブサービスができた話

はじめに

「コードを書いているときが一番楽しい。プログラミングを仕事にしよう。」そう思って就職し、プログラムを書くことでお金をもらうことができた夢のような日々。でもそんな日は長くは続きませんでした。数年のプログラマ生活の後、徐々にマネジメントが主な業務になり、コードを書く仕事から離れてしまい、いつのまにか十年が過ぎました。かつて覚えた技術は、いつしか全て時代遅れになってしまいました。

俺はもっとコードを書く仕事がしたい。 SEだなんてつまらない。なぜか? ..

上記のエントリーにとても共感できました。気力・努力・技術力が足りないために何も書けず何も作り出せず、そんな状況に負い目を感じるような日々を過ごしてきました。

しかし、ある日発想を転換し、時間を確保して手を動かしてみたところ驚くほどスムーズに学習と開発が進み、半年間で最近のトレンドっぽい技術(ES2015/Node.js/Express/MongoDB/Socket.io/React/React-Router/Material-UI)でWebサービスを作ることができました。どれも初めて覚えた技術要素です。

折角なので、この学習プロセスをまとめてみます。

目的

最近の技術を使ってウェブサービスを作ること。

学習・開発方針

普段の生活の時間を削って開発に当てることは負担が大きいので、以下の2つの時間を使うことにしました。

  1. 通過時間に技術系の書籍を読む
  2. ランチタイムは60分きっちり開発に当てる

一念発起して夜中や早朝に時間を確保する、なんてことは自分にはできませんでした。この方針ならほぼこれまで通りの生活で毎日開発時間を確保できます。短時間ですが、毎日のことになるので前日やっていたことを忘れづらいのもメリットです。 ランチタイムを使うことで平日5時間、月に20時間、年間240時間を確保することができます。これだけあれば何かできるでしょう。

前提

保有スキル

10年前にLAMPでWebアプリケーションを作っていたことがあるものの、現在のフロントエンドの知識はゼロ。マネジメント寄りの仕事になっているため、仕事でコードを見ることはありません。エンジニアとしてはそろそろ使い物にならない感じです。

作るもの

昔から興味があったのでなんとなくチャットを作ることにしました。作り終える頃には別のものを作れるノウハウも得られるはずです。

学習・開発プロセス

1ヶ月目:技術の方向性検討〜基礎学習(読書)

チャットということで非同期通信を試してみることにしました。非同期通信でチャットを作る場合、Node.js + socket.ioが定番のようです。このあたりから覚えることにしました。 JavaScript周りの技術を使うことになりそうだったので、まずJS系の書籍を2冊とGithubの書籍を買ってきて通勤時間に斜め読み。なんとなく目を通して雰囲気をつかみました。読み終えたら細かい内容は忘れましたが、全体像がつかめました。

2〜3ヶ月目:プロトタイプ作成

一ヶ月間、通勤時間に技術の本を読んでJavaScriptが書けるような気分になってきました。いよいよ開発をはじめます。 でもいきなり白紙からコードを書くのは無理なので、コピペ駆動開発発動です。

  1. 以下のエントリーに書かれているコードを持ってきてそのまま動かす http://creator.cotapon.org/articles/node-js/socket_io-mongodb-chat-sample
  2. コードをgit/Githubに登録
  3. ソースの一部を修正→動作確認→git commit→動作がおかしくなったら以前のコードに戻す、の繰り返し。 動くものがあれば、少しづつ修正していくことができます。問題が出たらconsole.log()で原因を探って修正。大胆に変更してもGithubに残っているので大丈夫。 具体的には、拾ってきたコードをベースに以下のカスタマイズを施していきました。一から書いたりはできないので、それぞれぐぐって出てきたコードを適当に貼り付けて修正していくだけです。レゴブロックのようなものです。

    • Room分割
    • MongoDB導入
    • デーモン化
    • セッション管理
    • アイコンチャット化
    • LINE風表示
    • 現在の参加者リスト表示
    • BootStrapでデザイン付け
    • React.js/React-router導入

4ヶ月目:期初のため仕事が忙しく時間がとれず。

5〜6ヶ月目:プロトタイプを元にベータ版を再作成

プロトタイプは機能を動かすことを目的に適当にコードをツギハギに足していったものなので、かなり酷いスパゲッティコードになっています。 手を動かしているとES2015、Express、Reactの書き方が多少はわかってくるので、この段階で一旦コードを破棄してゼロから書き直すことにしました。 動いている見本があるので、うまく動かずに悩んだ時にはプロトタイプのコードを見れば解決できます。

プロトタイプからの変更点

  • 基本的にゼロベースで書き直し
  • ExpressのViewをJSXに変更(express-react-views)
  • BootstrapからMaterial-UIに変更
  • 簡単なデザイン付け(CSSで色を変える程度)

完成

以下のチャットサービスができました。シンプルなものですが10年間コードを触っていなかった自分がウェブサービスが作れたと思うと感無量です。

作ったもの→brunch.chat

  • 主な構成要素
    • サーバ周り
      • Docker/Rancher
      • Node.js: v7.10.0
      • MongoDB: 2.6.10
      • express-react-views: 0.10.2
      • socket.io: 1.7.3
    • クライアント周り
      • React: 15.5.4
      • react-router-dom: 4.1.1
      • material-ui: 1.0.0-alpha.20
      • superagent: 3.5.1
      • webpack: 3.0.0

サーバ・クライアントをJavaScript/Reactで統一したので頭の切り替えが不要で楽でした。今後、サーバ・クライアント間でコードの共有もできそうです。 開発環境・本番環境共にDocker上で動かしています。

まとめ

何か新しい取り組みが進まないという場合、マインド不足(精神論)よりもリソース不足を先に解消した方が良いと感じました。 手を動かすことによってのみモチベーションは向上するものでもあり、始める前にモチベーション不足を嘆くよりもとにかく行動する時間を確保し、無計画に非効率にだらだらと手を動かす方が良い気がします。結果的に短期間でモチベーションがあがり、楽しく開発を進めることが出来ました。

通勤時間は読書の、ランチタイムは開発のとても良い時間枠です。この2つの時間を活用することで、半年でウェブサービスを作ることができました。最近のフロントエンドの技術をざっくりと使ってみることもできました。 睡眠時間や土日を削るわけではなく、普段の生活は何も変えていないので特に負担なく開発を進めることができました。今後も気楽に続けられそうです。

ということで、今後もコピペ&ランチタイム駆動開発を続けてみようと思います。 ランチタイムに効率悪くダラダラと手を動かしてみるというやり方、オススメです。

補足:その他読んだ書籍