by shigemk2

当面は技術的なことしか書かない

ゆーすけべーさんの「Webサービスのつくり方」を読んでみたでゲソ

サブタイが「新しい」を生み出すための33のエッセイでゲソ。
まるでThe Federalistみたいじゃなイカ。
本家は85篇あったでゲソ。The Federalistもサブタイをつけるなら、
連邦政府」を生み出すための85のエッセイじゃなイカ。


これと併せて読めばいいんじゃなイカ?

そんなことはどうでもいいので、とりあえず33のエッセイの内容をさらっとメモしてみるでゲソ。

第一章 心構えと下準備

1. ぐだぐだ言ってないでコードを書けよ、ハゲ Shut the fuck up and write soome code 一番重要なのはとにかくまずコードを書くことである
2. Mac 1つあれば… homebrew AppleStoreなど、Macは開発自体を目的化、現時点で最高の環境である
3. エディタという道具 自分の好きなエディタを使ってカスタマイズし、自分の手に馴染む道具を探し、作る
4. なければつくる 車輪の再発明はしないで車輪を利用したほうが早いが、なければつくるという精神はずっと持っておきたい
5. 言語習得にまつわるエピソード 言語習得には「これだ」というのに出会うまで、いろんなやり方を試すべき
6. データ表現について分かった瞬間 ハッシュや配列などデータ表現方法を習得することで言語に対する理解が深まる
7. 僕がPerlを使うことから見る言語の選択 PHPはプラモ Perlはレゴ MG ExSガンダムのパーツの数からも分かるように、PHPPerlに比べて用意されてる関数が多い
8. ブログの効用 有名人から捕捉と添削を受けてブログが有名になることもある
9. 勉強会にとびこむ 勉強会は面白くて刺激的
10. ライブラリという文化 ライブラリ開発者が偉いという風潮に押されずにライブラリ利用者もどんどん新しい利用方法を提案するべき

第二章 企画

11. 実装までにつくる「企画」の全て 企画づくりの流れは、哲学 アイデア テーマ コンセプト 名前 デザイン 内部設計の7つに分かれている
12. アイデアの発想法 新しいアイデアは既存のアイデアの組み合わせである
13. そこに潜むリスク Webサービスを作る際にも、行動を起こす前にリスクをある程度考慮することが必要

第三章 設計

14. ユースケースを書こう ユースケース図を利用して、ユーザーと機能を明確化する
15. データベース設計 データを永続化するために必要な操作であるCRUDを再確認する
16. クールなURI? Cool URIs don't change(by W3C)
17. Webサービスを動かすための要素 HTML CSS Javascriptが最低限必要で、その他DBやバックエンドの技術が必要になるときもある

第四章 開発

18. 30分、JavaScriptでつくるWebサービスの動くモック JavaScriptを使うと、短い時間で「Webサービスのアイデアの検証」ができるかもしれない
19. 月額980円のさくらVPSを個人用に使い倒す 自由度が高いサーバ環境を月額980円で!!
20. Web APIで巨人の肩の上に立つ 今巨神って言いそうになったけど、Web APIインスタンス化やメソッド呼び出しの「やり方・取り決め」などを指す。これを利用することで、さまざまな応用の可能性がある
21. いかにして大量のおっぱい画像をダウンロードするか クローラーやスパイダーのコードを書くのは楽しい
22. 全裸で学ぶMVC事始め Mojolicious::Lite + zenrize
23. MVCのMについて アプリケーションのデータとロジックを司るモデル部分が一番重要なので、モデルから実装していこう。そのほうがテストしやすい
24. WAFあれこれ フルスタックかどうかより、「より手に馴染んだもの」がよい。欲しい機能がなければモジュールを組み合わせて作ればいいわけだし
25. テストを書こう TDDの実践により、ライブラリを使う立場から記述し同時にテストできる。
26. イカ娘でTwitter OAuth 認証 yusukebe/Twitter-Ikamusume · GitHub
27. CSS Frameworkを持つ フォントや要素ごとの余白など、最低限の要望を満たしてくれるフレームワークCSSを一から構築する必要がなくなる。

第五章 プロモーションと運用

28. Webサービス、最初の宣伝 初期のプロモーションに必要なのは、プレスリリース、自身のブログでの紹介、Twitterでの拡散、はてブで注目を集める
29. 「普通の」サーバ構成 アプリケーションサーバ(Starman) + フロントエンドサーバ(nginx) + DBサーバ (MySQL) + キャッシュサーバ (memcached)
30. 運用してこそWebサービス 運用は、システム運用(死活監視)とコンテンツ運用に分けられる
31. Webアプリのパフォーマンスアップ作戦 チェックすべきパフォーマンスは、 バックエンドと、フロントエンド、クライアントの3つの負荷である
32. キャッシュ、キャッシュ、キャッシュ memcachedは高速なので、DBにアクセスした結果をキャッシュするのにも使われる
33. サービスをスケールさせる時 サーバの負荷が高すぎると感じたら、スケールアップ(サーバのスペックを上げる)と、スケールアウト(サーバの台数を増やす)を考える

おわりに

Perlのスローガンに

There's More Than One Way To Do It.

がある。「やり方は一つじゃない」ってこと。自分なりの「Webサービスのつくりかた」を生み出せばいいんじゃなイカ?