銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

当ブログではアフィリエイト広告を利用しています

エンジニアがMac購入後にやっておきたい設定・環境構築・便利なツールまとめ

(2024/3 更新)

注文していたMacBook Airが昨日届きました。

同時にMacBook Air注文して、先に届いていた妻が参考にしたURLをまとめてくれており、設定・環境構築がすぐ終わりました

そんなツイートをしたところ、参考にしたURLを教えて欲しいと2人の方からリプをいただいたので簡単にまとめてみます。

せっかくなので僕が使っている便利なツールも紹介しています。

初めてMacを購入した方、MacからMacへ買い替えた方の設定・環境構築の参考になれば嬉しいです。

ちなみに、僕はRuby on Railsを使って開発をしていて、使用しているエディタはVimです。(Vim大好き!)

Macのバージョン:macOS Mojave 10.14.1 

f:id:ysk_pro:20190101115249p:plain

1. 必要なアプリのインストール(デスクトップアプリ)

まず必要なデスクトップアプリをApp Storeでインストールします。

  • Google Chrome : インストールするだけで同期してくれるので楽々
  • slack
  • LINE

 

2. 必要なソフトのインストール

 

3. 基本的なPCの設定

 

4. 開発環境構築

 

おわりに

みなさんが知っているものばかりだったでしょうか。

「こんな便利なツールあるよ!」など教えていただけるととても嬉しいです!

 

2018年に僕がエンジニアになって作ってきた個人開発webサービス 12個や書いてきたnoteなどをこちら↓の記事で紹介しているので、合わせてご覧いただけると嬉しいです!

また、使っているキーボードや椅子などの物理的な環境についてはこちら↓の記事に書いているのでご興味あればご覧ください!

エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り

もうすぐ2018年おわりますねー!

ということで、2018年にやったことを書き出して、KPTで振り返りをしてみました!

あー、楽しい1年だった。 

KPTというのは僕の会社で使っている振り返りのフレームワークです)

f:id:ysk_pro:20181231220832p:plain

(↑の画像は今まで作ったサービスの画像を適当にくっつけてみました。めっちゃごちゃごちゃしてる 笑)

1. 2018年にやったこと

  • ブログ 41記事
  • note 3記事
  • LT・登壇 4回
  • エンジニアのコミュニティに 3つ参加(もくもく会などは多数参加)

 

2. KPT

2-1. Keep(良かったこと / 今後も続けること)

  • インプット→アウトプットの習慣が作れたこと(学んだことをブログ・Twitter等でアウトプット)
  • 学習する習慣が作れたこと(技術書・個人開発での新技術等をほぼ毎日学習できた)

 

2-2. Problem(悪かったこと / 今後はやめること)

  • 勉強会などにあまり行けなかった(もっと人脈を広げたかった)

 

2-3. Try(次に挑戦すること)

  • 勉強会などに月1回以上参加する

※ 一応3つとも定量化したので、月1回以上は振り返って絶対達成するようにしたい

 

3. おまけ(1. の詳細)

ここからは長いのでご興味ある方はご覧ください。

作ってきたサービスnote技術チュートリアルLTを簡単に全て紹介していきます。

3-1. 2018年にリリースしたサービス

3-1-1. Jobmiru

渾身の処女作です...!

このサービスのおかげでDEMODAYというオリジナルサービスを発表するイベントに登壇できたり、エンジニアへ転職することができました。

最も思い入れのあるサービスです。

業種特化などして何とか使われるサービスに育てていきたい。

このサービスに込めた想いなどはこちらのブログに書いています。


3-1-2. Powertweet

 

3-1-3. BigTweet"1"(後に "2"を開発します) 

 

3-1-4. アイデアtweet


3-1-5. 今日雨降るよちゃん(LINE bot

僕が一番気に入ってるLINE botです。

開発のきっかけなどをこちらの記事に書いています。


3-1-6. お買い物メモ君(LINE bot

こちらのサービスについてはこの記事に書いています。


3-1-7. Tweet Searcher(LINE bot

自分で毎日使っているLINE botの一つです。便利!

 

3-1-8. BigTweet"2"

 

3-1-9. Blog Reader(LINE bot

 

3-1-10. いちにちをシェア


3-1-11. いちねんをシェア


3-1-12.  いちねんのさいてん

いちにちをシェア、いちねんをシェア、いちねんのさいてんについてはこちらのブログに書いています。


3-2. note

3-2-1. 僕はなぜ銀行を辞めたのか、なぜITエンジニアになったのか (+ 実際の転職活動について)


3-2-2. プログラミング歴6ヶ月の僕が自社サービスRailsエンジニアになりました!〜実際の転職活動について〜


3-2-3. 【資格試験勉強法】大量の資格を取得する銀行員時代に身につけた、そこそこの資格に「1ヶ月」で合格してきた超実践的勉強法


3-3. 技術チュートリアル

3-3-1. 【Big TweetチュートリアルRuby on Railsで簡単なサービスを作ってみよう!(初学者向け)


 3-3-2. LINE botチュートリアル【初学者向け】 〜Ruby on Railsでアイデアtweetを作ってみよう〜

 

3-3-3. 「今日雨降るよちゃん」を作ってみよう!【初学者向け】〜Ruby on RailsによるLINE botチュートリアル②〜 


3-3-4. 【初学者向け】Ruby on RailsでのLINE botチュートリアル第3弾〜Amazon API楽天APIを使ってお買い物Botを作ってみよう〜


3-3-5. 【BigTweetチュートリアル2】Ruby on Rails / JavaScriptで簡単なサービスを作ってみよう!(初学者向け)


3-4. LT・登壇

3-4-1. DEMODAY


3-4-2. 勉強会でのLT

 

3-4-3. DIVE INTO CODE(プログラミングスクール)のイベント


3-4-4. Ebisu.rb


4. おわりに 

ここまで読んでいただきありがとうございます。

こうまとめるとなんか色々やってきたなーという感じがします。

 

色々とやってこれたのは週末一緒に勉強 / 開発に付き合ってくれる妻(妻もエンジニアです!)のおかげであり、本当に感謝してもしきれないです。

 

エンジニアになってまだ半年、ここからさらに加速していきますー! 

【技術書まとめ18】Web API The Good Parts

毎週1冊技術書を読んでブログでアウトプットすることが目標で今回が第18弾です。

今回は Web API The Good Parts を読みました。

Web APIの設計、開発、運用について解説しており、Web APIの開発者は必読と言われている本です。

今後のAPI開発で活かせそうなところ満載の良書でした。

Web API: The Good Parts

Web API: The Good Parts

 

f:id:ysk_pro:20181230095506p:plain

1章 Web APIとは何か

  • Web APIとは、あるURIにアクセスすることで、サーバ側の情報を書き換えたり、サーバ側に置かれた情報を取得したりすることができるwebシステムで、プログラムからアクセスしてそのデータを機械的に利用するためのものである。機械的にと言うのは、ブラウザを使って人間が直接アクセスすることを目的としたURIではないことを意味している
  • 新しいシステム、サービスを公開する力を持った開発者にAPIを公開することで、彼らがサービスに付加価値を与えてくれ、コアとなる自分たちのサービスがより発展する可能性がある
  • サービスにある機能を追加したいと思った時、デファクトとなっているサービスがすでに存在し、APIを公開している場合にはそこに繋いだ方が有利であることが多い。APIを用意することで様々なサービスと共存共栄することができるようになる
  • スマートフォンのアプリケーションがサーバと通信する必要がある場合、Web APIが利用されるのが最も一般的である
  • 設計の美しいWeb APIは変更しやすいモバイルアプリケーションの場合、アプリケーションのアップデートのタイミングはユーザー次第であり、バージョンアップをしたとしても古いバージョンを使うユーザーは存在し続けてしまうAPIの仕様を急に変化させるとそうした古いバージョンのアプリケーションは動かなくなってしまうので、APIの変更をいかに利用者に影響なく行うかは重要である
 

2章 エンドポイント設計とリクエストの形式

  • Web APIにおけるエンドポイントとはAPIにアクセスするためのURIのことであり、一般的なwebページのURIの設計の考え方がそのまま適用できる
  • 良いURI設計の原則は、覚えやすく、どんな機能を持つURIなのかが一目でわかることである
  • URIに大文字は使わず、すべて小文字を使うべき。HTTPにおいてURIは、スキーマとホスト名を除いて大文字と小文字は区別されるため、大文字を使うと別のURIとなってしまう
  • HTTPメソッドのPUTとPOSTの使い分け:どちらもサーバ側の情報を変更するためのメソッドであるが、Web APIではデータを修正する場合にPUTを用い、新しいリソースを生成する場合はPOSTを用いるのが一般的である
  • データの集合と個々のデータをエンドポイントとして表現し、それに対する操作をHTTPメソッドで表す考え方は、Web API設計の基本であり、多くのAPIがこれに沿った設計となっている
  • エンドポイントには複数形の名詞を用いるのが基本である。また、エンドポイント内で単語を2つ以上繋げる必要がある場合はハイフンを利用することが多い
  • クエリパラメータとパスの使い分け:一意なリソースを表すのに必要な情報はパスに入れた方が良く、省略可能な情報はクエリパラメータに入れる方が良い
  • ホスト名とエンドポイントの共通部分は「api.example.com」が主流であり、わかりやすさ、簡素さの観点から適切であると言える
  • 「1スクリーン1API、1セーブ1APIコール」という言葉があり、何度もAPIへのアクセスを繰り返すことは、速度の問題だけでなく、データの一部だけが表示されてしまう状態や、保存の際に一部のデータだけが保存されて整合性が保たれなくなってしまうといった問題を引き起こす可能性もあるので極力避けるべきである
  • 良い設計を見極めるには様々なAPIの実際の設計を調べ、比較してみることも重要である
 

3章 レスポンスデータの設計

  • JSONXMLよりも広まった理由は、JSONの方がシンプルで同じデータを表すのにサイズが小さくて済むこと、webの世界においてクライアントのデフォルト言語であるJavaScriptとの相性がとても良いことがあげられる
  • JSONPを使うと、JSONをscript要素を使ってJavaScriptとして読み込み、ドメインを超えたアクセスが可能となる。JSONPに対応しているAPIは多く存在するが、必要がないのであればセキュリティの観点からはなるべく対応しない方がよいとされている
  • クエリパラメータを使って、レスポンスの内容をユーザーが選択できるようにすることも有用である
  • レスポンスデータをフラットにするか階層化させるかについてGoogleJSON Style Guideでは「なるべくフラットにした方がいいが、階層構造を持った方がわかりやすい場合もある」とされており、それに従うのが良い
  • レスポンスで配列を返したい場合に、配列をそのまま返すことも、オブジェクトに包むこともできるが、セキュリティの観点からオブジェクトに包んだ方がベターである。トップレベルが配列であるJSONは、JSONインジェクションという脆弱性に対するリスクが大きくなる
  • 各データ項目(JSONのキー)の名前のつけ方のポイント
    • 多くのAPIで同じ意味に利用されている一般的な単語を用いる
    • なるべく少ない単語数で表現する
    • 複数の単語を連結する場合、連結方法はAPI全体を通して統一する:JSONではキャメルケースを使うのがよいとされているが、スネークケースなどを使っているAPIも多数存在する
    • 変な省略形は極力利用しない
    • 単数形/複数形に気をつける:そのキーで返るデータが複数なのか単数なのかで使い分ける(データを配列で返すときは複数形に、それ以外は単数形にする)
  • サーバがエラーを返す際に真っ先に行うべきことは、適切なステータスコードを使うことである。エラーの詳細を返す方法は、HTTPのレスポンスヘッダに入れて返す方法と、レスポンスボディで返す方法があるが、多くのAPIはレスポンスボディにエラーメッセージを格納する方法をとっている
 

4章 HTTPの仕様を最大限利用する

  • HTTPのキャッシュの仕組みをAPIでも利用する。HTTPのキャッシュは、2つのタイプがある
    • Expiration Model(期限切れモデル):あらかじめレスポンスデータに保存期限を決めておき、期限が切れたら再度アクセスをして取得を行うもの
    • Validation Model(検証モデル):今保持しているキャッシュが最新であるかを問い合わせて、データが更新されていた場合にのみ取得を行うもの
  • Content-Typeヘッダを使ってメディアタイプを指定するのは非常に重要であり、すべてのAPIは適切なメディアタイプをクライアントに返すべきである。クライアントの多くは、Content-Typeの値を使ってデータ形式を判断しており、その指定を間違えるとクライアントが正しくデータを読み出すことができないケースが出てくるためである
  • 独自のHTTPヘッダを定義して利用することも可能である
 

5章 設計変更しやすいWeb APIを作る

  • 一度公開したWeb APIの仕様を変更する場合は、新しいAPIを別のエンドポイント、あるいは別のパラメータをつけたURIなど、何らかの新しいアクセス形式で公開するのが良い。つまり、古い形式でアクセスしてきているクライアントに対してはそれまでと変わらないデータを送り、新しい形式でのアクセスには新しい形式のデータを返すといった複数のバージョンのAPIを提供するということである
  • APIのバージョンを表す方法は、URIのパスに”/v2/“のようにバージョンを埋め込む方法が最も一般的である
  • バージョニングのルールとして広く知られている手法にセマンティックバージョニングがある。Rubyなどでも基本的な考え方が導入されている。”1.2.3”という表記でそれぞれの数値はメジャー、マイナー、パッチと呼ばれ、以下のルールが適用される。(APIURIのバスにはメジャーバージョンのみを含める場合が多い)
    • メジャーバージョン:後方互換性のない変更が行われた際に増える
    • マイナーバージョン:後方互換性のある機能変更、あるいは特定の機能が今後廃止されることが決まった場合に増える
    • パッチバージョン:ソフトウェアのAPIに変更がないバグ修正などを行ったときに増える
  • 自社のアプリ向けAPIなどの場合には、あらかじめAPIの提供が終了した際の仕組みをクライアント側にも組み込んでおくべきである。一番簡単なのは強制アップデートで、アプリケーションを立ち上げた際に、現在のバージョンと最低限サポートされるクライアントのバージョンを比較し、サポートの切れたバージョンを使っていた場合は「サービスを使い続けるにはアップデート」してくださいと表示して、AppStoreなどを開くことである
 

6章 堅牢なWeb APIを作る

  • 本来アクセスできないはずの情報はサーバ側できちんとチェックをし、アクセスを禁止しておくべきである
  • パラメータなどを修正してリクエストを送ってくる場合もあるので、クライアントから送られてきた情報を信頼せず、サーバ側でも整合性をきちんとチェックする必要がある
  • 同じリクエストを再度送信される場合もあるので、そのような場合を想定したサーバ側でのチェックが必要となる
  • 一度に大量のアクセスをされてしまう問題を解決するための最も現実的な方法は、ユーザーごとのアクセス数を制限することである。つまり単位時間あたりの最大アクセス回数(レートリミット)を決め、それ以上のアクセスがあった場合にエラーを返すようにする
  • XSSXSRFなど通常のwebと同様のセキュリティだけでなく、JSONハイジャック(APIからJSONで送られてくる情報を悪意ある第三者が盗み取ること)などAPI特有の脆弱性に気を配る必要がある
  • セキュリティ強化につながるHTTPヘッダをきちんとつけるべきである
 

おわりに

ここまで読んでいただきありがとうございます。

Web APIの開発に関わっていて本書をまだ読んでいない方は是非読んでみることをおすすめします!

Web API: The Good Parts

Web API: The Good Parts

 

やっぱり年末年始は読書が捗りますね。

来週も頑張ります!

【年末年始に読みたい!】2018年に読んでよかった本5選

2018年も終わりますね。

個人的に2018年は、人生で一番かもしれないくらい激動の1年でした。(そんな1年のことはこちらの記事に書いていますのでご興味ある方はご覧ください。 エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り - 銀行員からのRailsエンジニア )

銀行員からエンジニアになったこともあり、今年は技術書を多く読みました。
(合計28冊の本を読んで、内18冊が技術書でした。)

その中で特に良かったなーと思う5冊を紹介します。

年末年始はTVを見るのもいいですが、ゆっくり読書して過ごすのも素晴らしいです

f:id:ysk_pro:20181228074105p:plain

1. チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

 2018年で一番衝撃を受けた本です。

チーミング」という概念をもとに、学習する強い組織の作り方について書かれた本です。

最近よく耳にする心理的安全性」についてもこの本の中で詳しく解説されています。

マネジメントに関わる人は必読そうでない人も読んでおいて絶対に損ではない本だと思います。

リーダーが、管理ではなくエンパワーメントをするようになったら、適切な答えを与えるのではなく適切な質問をするようになったら、そして規則の遵守を主張するのではなく柔軟性に着目するようになったら、メンバーはもっと高いレベルで仕事を行えるようになる

心理的安全とは、関連のある考えや感情について人々が気兼ねなく発言できる雰囲気をさす。簡単なことに思えるが、同僚が見ているところで支援を求めたり失敗を許したりできるというのは思いのほか難しい場合がある。しかし、チーミングによって様々な意見の違いを超えて協働できるようになると、率直に会話したり失敗を隠さず話したり出来るようになる

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

 

2. お金2.0 新しい経済のルールと生き方

 「お金」というよりも「経済システム」の作り方について書かれており、僕が新しいwebサービスを作る際の考え方に大きな影響を与えてくれた本です。

この本はブログにまとめていないので、一部を引用にて紹介します。

 持続的かつ自動的に発展していくような「経済システム」にはどんな要素があるかを調べていった結果、5つほど共通点があることに気がつきました。 ①インセンティブ、②リアルタイム、③不確実性、④ヒエラルキー、⑤コミュニケーション、の5つです。

実際に社会で広く普及した経済システムは例外なくヒエラルキーが可視化されていて、明確な指標の役割を担います。  世の中には、偏差値、年収、売上、価格、順位のような数字として把握できるものから、身分や肩書きのような分類に至るまで、階層や序列に溢れています。

「世界を変える」とは、前時代に塗り固められた社会の共同幻想を壊して、そこに新しい幻想を上書きする行為に他なりません。国家、通貨、宗教、偏差値、学歴、経歴、年収、資産、倫理、権利など、私たちの精神や行動を縛る概念のほぼ全てが人工的に作られた幻想ですが、これらの効力が薄れ、時にはまた別の幻想が誕生し、人々の新たな価値判断の基準になっていきます。

これからは価値という観点から、自分なりの独自の枠組みを作れるかどうかの競争になります。枠組みの中の競争ではなく、枠組みそのものを作る競争です。そのためには自分の興味や情熱と向きあい、自らの価値に気づき、それを育てていく。そしてその価値を軸に自分なりの経済圏を作っていきます。

お金2.0 新しい経済のルールと生き方 (NewsPicks Book)

お金2.0 新しい経済のルールと生き方 (NewsPicks Book)

 

  

3. 漫画 君たちはどう生きるか

おいおい、オススメの本と言いながら漫画じゃねーか、と思った方もいると思います。

そうです、漫画です。

漫画なのでサクッと読めるのですが、学ぶこと・感じることがとても多かったです。

ベストセラーにもなっていたのでお読みになった方も多いかと思います。

少し長いですが、一部を引用にて紹介します。

悲しいことや、辛いことや、苦しいことに出会うおかげで、僕たちは本来人間がどういうものであるか、ということを知る。身体の痛みは、正常でないことを僕たちに知らせてくれるなくてはないのと同じように、心に感じる苦しみやつらさは、人間が人間として正常な状態にいないこと僕たちに知らせてくれるものであり。僕たちはその苦痛のおかげで、人間が本来どういうものであるべきかということを、心にとらえることができる。人間は、お互いに愛し合い、好意をつくしあって生きてゆくべきであり、誰だって自分の才能を伸ばし、その才能に応じて働いてゆけるのが本当なのに、そうでない場合があるから、人間はそれを苦しいと感じるのだ。僕たちは、自分の苦しみや悲しみから、いつでも、こういう知識をくみ出してこなければいけない。僕たちが、悔恨の思いに打たれるのは、自分はそうでなく行動することもできたのに、と考えるから。それだけの能力が自分にはあったのに、と考えるから。人間である限り、過ちは誰にだってある。そして、僕たちに苦しい思いをさせる。しかし、この苦しい思いの中から、いつも新たな自信をくみ出していこう。正しい道に従って歩いてゆく力があるから、こんな苦しむのだと。僕たちは自分で自分を決定する力を持っている。だから、誤りから立ち直ることも出来るのだ。

漫画 君たちはどう生きるか

漫画 君たちはどう生きるか

 

 

4. Webを支える技術

ここから2冊は技術書です。

エンジニア界隈では超有名なので説明するまでもないかもしれませんが、こちらはHTTP、URI、HTML、RESTなどのWebの基礎となる技術を解説している本です。

エンジニアとして働くにあたってWebの基礎知識は、知っていることが前提となる必須の知識であり、僕はこの本を通算4周読んでいます。

Webの基礎知識の概要を掴みたい方は必読だと思います。

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

 

5. 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

Webアプリケーションの脆弱性に関する名著です。

最近の話題に対応するべく第2版が2018/6に発売されました。

言うまでもないですがセキュリティはwebサービスを運営するにあたって超重要事項であり、僕の会社でこの本は勉強会の題材になりました

内容についてはこちらの記事にまとめているので、ご興味あればご覧ください。

 

番外編 マンガ キングダム

今アツいマンガはやっぱりキングダムではないでしょうか。

もしまだ読んでいない方がいれば正月に一気読みしちゃいましょう!

(まだ読んでいない人はこれからこのマンガが読めると思うとうらやましい 笑)

  

おわりに

今年はエンジニアになったばかりということもあって、ベテランのエンジニアの方に聞いたおすすめの本を読むのが中心で、素晴らしい本にたくさん出会うことができました。

業務、書籍などから少しずつ知識がついてきたと感じているので、来年は自分に必要な本を自分で選んでいくことも行い、エンジニアとして知識の幅をどんどん広げていきたいと思っています。

来年も素晴らしい本、人生の幅を広げてくれるような本に出会えるのが楽しみです。

是非みなさんのおすすめの本も教えてください!

Twitterにグラフをシェアできるサービスを3つ作りました!〜サービスの紹介、作った背景、使った技術など〜

今月は久々にwebサービスを開発していて、似たようなサービスですが3つリリースすることができました💪 

サービスの紹介作った背景使った技術などをまとめたのでご興味ある方は是非ご覧ください!

いつも僕がどんな感じでサービスを作っているのかも書いています。

(記事は読まなくてもいいので是非サービスだけでも触ってみてください(> <))

f:id:ysk_pro:20181224204243p:plain

作ったサービスの紹介

1. いちにちをシェア

自分の1日をかんたんにシェアできるサービスです。


2. いちねんをシェア

いちにちをシェアの1年バージョンです。

 

3. いちねんのさいてん

レーダーチャートで1年を振り返れるサービスです。
1年を振り返る以外の用途でも、レーダーチャートでステータスを表示して遊べます。

 

なんで作ったの?

仕事の1日のスケジュールや、休日の1日のスケジュールをTwitterでシェアしたい、また他の人のスケジュールを見てみたいなー、と思ったことが開発のきっかけです。
 
余談ですが、webサービスのアイデアは思いついたらすぐにEvernoteにメモをするようにしており、もう既に開発したものを合わせて現在64個のアイデアがたまってます。作り切れない、、、笑
 
いちにちをシェアを作った後に、年末なので1年を振り返れる機能をつけたいなーと思って、いちねんをシェア、いちねんのさいてんを開発しました。
 
手書きのデザイン案が残っていたので一応載せます。

いつもこんな感じで手書きでざっくり書いてます。f:id:ysk_pro:20181224192909j:plain

 

どんな技術を使っているの?

当初予定していた構成

バックエンド Firebase × フロントエンド Vue.js でいこうと思っていました...
 
理由はモダンでかっこいいから!
 
どちらも使ったことはなく、本やチュートリアルで勉強したりしながら頑張りましたが挫折してしまいました、、、
 
やっぱり一気に新しい技術を使いすぎるのは良くないですね...みたいなことはこの記事に書いているので是非読んでみてくださいー!

 

採用した構成

結局はいつもの構成に落ち着きました。
 
バックエンド Ruby on Rails × フロントエンド jQuery
 
jQueryをまだ使いこなせていないレベルだったので、今回はjQueryをたくさん使って使いやすいサービスにすることをテーマとしました。
 
例えば、
値を入力したら自動でグラフが生成されたり

1つ前の時間以降しか表示させなくしたりしました(触ってみてね!)

 
チャート生成は chart.js というJavaScriptのライブラリを使っています。
このドキュメントはもう暗記するぐらい読み込みました 笑
ドキュメントが日本語でしっかりまとまっているのでとてもやりやすかったです。
 
サーバーは、いつも通り Heroku です。
使いすぎて無料枠の月1,000時間をオーバーするようになってしまったので、現在は苦肉の策としてアカウントを2つに分けて運用しています。
 
画像の保存は Amazon S3 を利用しています。
 

どれくらい時間がかかったの?

Rails × jQuery で作り始めてからは土日を5日くらい使って完成させました。
 
僕の開発の仕方は、自分で書いたチュートリアルを組み合わせてベースを作り、そこからやったことがないことに挑戦していくスタイルです。
今回であれば、このチュートリアルを見ながら進めました。

 
僕が技術チュートリアルを書いているのは他の人の役に立てばいいなというのが一番ですが、このように将来の自分のためでもあります。
過去に作ったものも、コードしか残っていないと自分のコードであっても分からなくなってしまうことがありますが、チュートリアルであれば他人でもわかるように書くので自分で後から理解できておすすめです。
 
今回もできればチュートリアルにまとめたいと思ってます。
(コードがぐっちゃぐちゃなのでリファクタするのが面倒ですが、、、個人開発はどんなにコードが汚くても動けばOK、テストコードも書かない派です)
 

おわりに

みんな是非遊んでみてねー!!!

【読書まとめ17】説明がなくても伝わる 図解の教科書

毎週1冊本をを読んでブログでアウトプットすることが目標で今回が第17弾です。

今回は、説明がなくても伝わる 図解の教科書 を読みました。

会社でデザイナーの方にオススメしてもらった、図解の仕方を実例を交えながら分かりやすく解説している本です。

ノンデザイナーの僕でもすぐ実践できそうな内容ばかりでとても為になったのでおすすめです。

説明がなくても伝わる 図解の教科書

説明がなくても伝わる 図解の教科書

  

f:id:ysk_pro:20181223171216p:plain

Chapter1 「図」がすべてを語ってくれる

  • 資料やスライド画面を見たときに、人が最初に目にするのはタイトルでも見出しでもなく、図解や写真といった「視覚イメージ」。人は生理的に図やイラスト、写真を見て、その資料や文書が自分にとって重要かどうかを判断し、重要であれば文章を読み始める
  • 抽象的・概念的な内容は、文字に頼らなければならない場合が多いが、文字を視覚イメージと一緒に示したり、分類方法を変えて整理したりすることで、伝わりやすくなることが多い
  • 図解をつくる基本手順は、基本原則を身につけて、伝えたいメッセージを図解の型に流し込むことである
  • デザイナーはまず手書きで始める。図をつくるときには、事前のアイデア出しやラフスケッチづくりが、最終的な品質に大きな影響を及ぼす
  • 図解のプロセスは頭文字をとってDTMと呼ばれる
    • Discovery(発見):参考となる事例を見つける
    • Transformation(変形):課題に合わせ、事例に手を加える
    • Making(形成):スケッチをもとに図を仕上げる
 

Chapter2 伝わる「図」の5つのポイント

  • 図解の5つの基本機能
    • 一瞬で伝える
    • 親しみやすくなる
    • 不安を解消する
    • 真剣に受け止めてもらう
    • 誤解やミスを防止する
  • 図解づくりの目標
    • 伝えたいことを、受け手が予想できるようになる
    • 受け手が困らないように道案内をする
  • 「すでに広く使われていること」は、誰にでも理解されるための重要な要素である。すでにみんなが慣れ親しんだものを使う方が、手間もコストもいらず、人の役に立つことができる
  • どのようなプロセスで手続きが進み、どうすれば終了できるのかを、全体・部分・流れを示して提示すると読み手に安心を与えることができる。ステップを踏みながら説明するステップバイステップ技法が有用である
  • 重要部分を赤文字にすると、むしろ見えづらくなってしまうことがある。赤文字は黒文字よりも視認性が悪い。色を使わずに文字を強調するには、下線を引く、大きな字を使う、単語を囲む、太字を使うことが有用
  • 良い例と悪い例など相反する2つの例があることで、情報がより明快になる
 

Chapter3 「主題」「見せ方」「仕上げ」の3つの山を超える

  • 整理されていない情報は、情報とは言えない。つまり、整理されていない情報から価値は生まれない
  • 「立場」「作業内容」「時間軸」の3つで情報を分類すると伝わりやすい
  • 同じ分類内容に一貫して同じ形式(文字や線などの形式)を使う
  • 写真とイラストの使い分け
    • 写真:リアリティが重要で、雰囲気や広く詳細な情報を伝えたい時に役立つ
    • イラスト:焦点を絞り、必要なことだけを伝えたい時に役立つ。イラストは不必要な情報をあらかじめ省いておくことができる
  • グラフにはそれぞれ機能がある
    • 円グラフ:全体に占める割合を伝えるだけ。ある割合と別の割合を比較させる目的では使わない。また、円グラフの分割は最小限に留めるべき
    • 分割棒グラフ:割合の違いを伝えるだけ。円グラフの弱点を補う一方で、全体に占める割合は伝わりにくい
    • 折れ線グラフ:時間軸に沿った動向を伝えるだけ。時間軸は必ず等間隔に表示する
    • 棒グラフ:数値の差を伝えるだけ。必ずゼロを基準値として、バーの長さを省略しない
    • 数値一覧表:具体的な数値を伝えるだけ。大量の数値情報を1箇所に示す場合に役立つが、受け手の読み取りに大きな労力を強いるので、他のグラフによる提示方法があればそちらを優先した方がいい。使うのであれば、グリッド(格子状の線)を消し去り、平均値を示し、数値を縦に並べ、キリのいい数値で示すと理解しやすくなる
  • 図解の仕上げのポイント
    • インパクトを弱める:情報を全て強調してしまうと逆効果であり、主題に関わらない部分のインパクトは弱めるべき
    • 多様性を否定する:異なる情報は全く異なっているように見せ、同じ種類の情報は同じもののように見せる
    • 自分を信じない:自分はバイアスのかかった状態にあることを自覚し、実際に人に見てもらう
  • ポイントは箇条書きにし、可能なら図解化する。長い文章よりも箇条書きの方が目に入りやすい。文章から図解化する手順は、文章を要点ごとに分解し、それを箇条書きにして要点を絞ってから図解をする
 

Chapter4 「図」を変えれば全て伝わる

  • テキストで1行足らずのシンプルな情報でも、枠で囲んで並べるだけで図解となり情報が読み取りやすくなる
  • 手順を説明するときは、イラストと説明文を近くに配置すると、受け手の誤解や見落としが少なくなる
  • 数値は右揃え、単位は左揃えを原則とする
  • グラフは凡例を分離せずに、グラフ内に直接書き込んだ方が伝わりやすい
※ Chapter4では、50個の事例(それぞれ悪い図解と良い図解の比較)を分かりやすく解説しています
 

おわりに

ここまで読んでいただきありがとうございます。
 
会社でよく先輩に図解を交えて教えてもらっていて、言葉で説明してもらうよりもスッと入ってくる図解の威力を感じているので、本書を読み込んで図解力UPしていこうと思います。
このブログには掲載できませんでしたが、当然本書の中でも図解を多用しておりとっても分かりやすかったので是非お手にとってご覧ください。
説明がなくても伝わる 図解の教科書

説明がなくても伝わる 図解の教科書

 

最近はサービス作りに夢中で本を読めていませんでしたが、またここからどんどん本を読んでいきますー。

来週も頑張ります。

Ruby初学者の楽しい個人開発 〜 モチベーションの維持・どんなサービスがオススメ? 〜

こんにちは。ゆうすけです。

先日、Ebisu.rb に初参加して初LTしてきました!

Ebisu.rb は恵比寿界隈のRubyistの交流を目的として結成された地域Rubyコミュニティです。発表を通して知見を共有しながら、懇親会で交流を深めていきたいと思います。

勉強になるLTを聞くことができ、普段関わることのない他社のRubyエンジニアの方々と交流ができ、とても有意義なイベントでした。

せっかくなので、僕が行ったLT「Ruby初学者の楽しい個人開発」をまとめてみます。

↓こんな内容について話したので、ご興味ある方は是非ご覧ください。

f:id:ysk_pro:20181201091059p:plain

僕の個人開発Life

f:id:ysk_pro:20181201092203p:plain

僕は1年前の2017/11に DIVE INTO CODE というスクールでプログラミングを始めました。

スクールの課題でオリジナルWebサービス作ったことがきっかけで個人開発にハマり、これまでに9個のサービスをリリースしてきました。

初めてサービスをリリースしたのはプログラミング歴4ヶ月の時でした。プログラミングのスキルが低くても個人開発はできます。

個人開発において大切なのはプログラミングのスキルよりも、作りたいというやる気や情熱だと思っています。

 

なぜ個人開発をやっているのか

f:id:ysk_pro:20181201092225p:plain

自分が作ったサービスが使ってもらえた時の嬉しさがやっぱり一番です。

ほんとに嬉しいです。 

(でもやっぱりいつか一発当ててみたいなぁ..)

 

モチベーションの維持

f:id:ysk_pro:20181201092240p:plain

モチベーションの維持は個人開発の中で最も難しいことの一つだと思います。

サービスを作っていると技術的にどうしようもできないこと類似サービスの存在などの壁にぶつかることも多く、やらなかったからといって誰かに何か言われることもありません

会社の同僚などと話していても、個人開発や知人との共同開発を始めたけれど、モチベーションが続かなくて完成までたどり着けなかったという話はよく聞きます。

僕がモチベーションの維持のためにしていることは2つです。

 

① 作ったサービスは全く自信が無くてもTwitterで発表するようにしています。(使ってもらわないと意味がない!)

優しい人もいるもので、感想やフィードバックをくださる神が毎回現れます。(←嬉しい!モチベーション爆上がり)

さらに、サービスを発表するとなぜかTwitterのフォロワーが増え、フォロワーが増えるとサービスを使ってくださる方・リアクションしてくださる方も増えるという正のループが生まれていました。

僕のTwitterアカウントはこちらです → ゆうすけ@Railsエンジニア (@ysk_pro) | Twitter

 

個人開発者の集まりに参加しています。( 運営者ギルド というグループです)

月1くらいで飲み会があります。すごい人ばかりですがみなさん優しくて、自分のサービスについて語り合うっていうのは思っているよりも楽しくて刺激になります。「もっとすげえサービスを作りたい」という気持ちに毎回なってます。

 

失敗談

f:id:ysk_pro:20181201092313p:plain

「Jobmiru」は僕の処女作です。

プログラミングを始めたばかりの頃は、毎日このサービスのことを考えて、デザインも頑張って整えて、4ヶ月かけてなんとか作り上げましたが、ほとんど使われませんでした...(でも転職活動で使えたので作り上げることができて良かった)

Heroku有料版 → 無料版に切り替えて現在も存続はしています。(ドメイン更新しようか迷うなぁ)

www.jobmiru.com

 

f:id:ysk_pro:20181201092349p:plain

Jobmiruがなんで使われなかったのかなー、などと色々考えたりして学んだことがコチラ↑です。

僕が作ったJobmiruのような口コミサイトは、投稿のインセンティブを作るのが難しいです。以下記事にあるように他のサービスの事例を研究して、なんとかしようと模索しましたがうまくいきませんでした。

ysk-pro.hatenablog.com

また、最近流行り(?)のマッチングサイトに関しても、多数のユーザーがいないと成立しないサービスであり、口コミサイト同様に初期ユーザーを集めるのが大変なことから、個人開発には難しいのではないかなーと個人的には思っています。 (もちろん、うまくいっているすごいサービスもありますよ)

 

個人開発にはどんなサービスがオススメか

f:id:ysk_pro:20181201092330p:plain

逆にどんなサービスがオススメかというと、こちら↑の図にあるように「Simple」×「Easy」なサービスだと思います。

シンプルなサービスでログイン無しで気軽に使えるのであれば、ちょっと使ってみるかー、と思ってもらいやすいはずです。

また、<+α> のところに書きましたが、スキルアップのために新しい言語や技術を使うのは素晴らしいですが、一度にやり過ぎてしまうとそれが挫折の原因になってしまうので少しずつにした方がいいと思っています。

実際に、最近全く使ったことのなかった Vue.js × Firebase でサービスを作ろうとして挫折しちゃって学びました...泣

 

f:id:ysk_pro:20181201092426p:plain

Simple × Easy の例として、僕が作ってきたサービスの中で気に入っているものを2つ紹介します。

 

BigTweetは画像に文字が入ったツイートを10秒でできるサービスで、ログインなしで使えます。 

bigtweet2.herokuapp.com

 

今日雨降るよちゃんは、雨が降る日の朝だけお知らせしてくれるLINE botです。

こちらは、LINE APIのお友達制限数いっぱいになってしまい、新規お友達追加ができないので、紹介ブログを掲載します。

ysk-pro.hatenablog.com

どちらもこんなサービスがあったらいいなあ、と思うことを余計な機能をつけずに最低限の機能で作ったイメージです。

 

まとめ

f:id:ysk_pro:20181201092412p:plain

個人サービス開発に必要なのは、プログラミングスキルよりも、作りたいという気持ちです!

是非楽しい個人開発Lifeを送りましょう!!

 

全スライド

全スライドはこちらです。

 

 

おわりに

ずっと気になっていた地域.rbへの参加・LTはとっても楽しかったです。(いきなりLTをすることにビビってた僕の背中を押してくれて、発表練習まで付き合ってくれた先輩方に感謝)

この記事のご感想はコチラのBigTweetから是非お願いします!!笑

bigtweet2.herokuapp.com

ここまでお読みいただきありがとうございました。