エンジニアの勉強について
まず勉強には二種類あると思っている。それでこれら二つってお互いにすごく関連している気がする。たとえばあの基礎が抑えられてないから、これが理解できなくて、調べ方の指針もたたないみたいなことがたまにある。
- 仕事に必要な知識を得るための勉強、勉強というより調べ物に近いのかな 例）terraformでこういうリソースを追加したいのだがそのコードはどう書けば良いか
- 長期で見たときに必要になってくる知識を得るための勉強、技術書中心、公式のリファレンスとか 例）オブジェクト指向設計実践ガイドを読む (3. それらの仕事の仕方、仕事の効率化、)
1は仕事の仕方、問題解決に通じていると思うのだが、そもそもゴールがあって、それを解決するために調べる感じ。 - やりたいことがそもそも公式で推奨されていることとして存在するかどうか公式ドキュメントを見て探す in English あったらそれ読んでやってみる。わからなかったら日本語で読んでみる
- その上でわからないことがあったら、仕事に必要になると考えられる条件を決めて 調べる
2は何かそれを使ってやりたいときにすぐわからないことにアプローチするためにインデックスを貼るためにやる感じ。一時期は本の内容の70%をメモしていた感じだったけど、今はどこに何が書いてあるのか、またその書いてあることを理解するために最低限必要な知識を書くようにしている。
でも問題なのが自分の投下時間におけるこれらの比率で、2をやりすぎたら普段の仕事終わらないし、1だけだと長期で考えたときにあの基礎が抑えられてないから、これが理解できなくて、調べ方の指針もたたないみたいなこともたまにある。
だから自分の中で長期の勉強と目の前のことのための勉強で時間を分ける必要がある。あと仕事の時間って、基本的に調べる（勉強する）時間+作業時間（実際に動かしたり、レビューもらう時間）に分かれると思っててその比率はそのタスクの達成難易度（作業量×自分の能力）による。自分の能力がそのタスクに関して低いと調べる時間が多くなるし、やり方わかってて動かすだけならほぼ作業だけで済む。
あと何かをやるときはかならず二日以上かけるように予定を立てる、つまりこの日に全部やろうと思って10時間まとまった時間をつくるより、5時間×2とかでやったほうがいい。そうすると多少伸びても時間の融通がきく。
自分の時間分け
- そうすると朝起きての2時間は長期の勉強にあてる→絶対この時間は長期の勉強をする。この時間に勉強しないと長期の勉強はできないと思え！！またその日のタスクの調べ物は絶対にしない。キリがなくなるから。
- 仕事の際の調べ物はゴールを決めて調べて、最初から記事を書くつもりで読む。今までは一度読む→もう一度流し読みしながらまとめるみたいな感じだったので、最初から記事を書きながらみたいな感じでもいいから調べる。記事を書くこともそのタスクの一環として、調べたらすぐ記事を書く
- あと早く自分の遊び場をつくる。
SEOまとめ
SEOと検索エンジン
Webマーケティング
SEOとは、検索エンジンを利用するユーザーが入力するキーワードを導線としたキーワードマーケティング
- キーワードとカテゴリーの設計 web担当者、マーチャンダイザー、インフォメーションアーキテクト
- 内的施策 サイトのドメイン名やURL構成、HTML/CSSなどサイトの内側に施す対策 ←ここ
- 外的施策 PageRank(価値やキーワードの関連性が高いページやドメイン、サイトからどのくらいのリンクを受け取っているか、被リンクがあるか)を上げるための対策 ex メディアサイトに取り上げてもらう、ブロガーにリンクを貼ってもらう。
検索エンジンの技術的な仕組み
- 検索エンジンの種類
PageRank
「多くの良質なページからリンクされているページはやはり良質なページである」という再帰的な関係を元に全てのページの重要度を判定したもので、ランクされていないのPageRank 0 ~ 10までの全部で11段階の評価になっている。
- 被リンク数（リンクされているリンクの数）
- 評価の高いページからのリンクかどうか
- リンク元ページでの放出リンク数（貼ってあるリンクの数）
検索エンジンのシェア googleとyahooが主 https://seopack.jp/seoblog/20160816-s-e-share/
SEOサイクルとクローラビリティー（webサイトをいかに巡回しやすいか）
SEOサイクル
SEO対策の三つのポイント
クローラビリティ（クローラーのサイト回避のしやすさ）
- ステータスコードを返す
- URL永続化（一度公開して検索エンジンにインデックスされたコンテンツに対し、そのコンテンツが存在し続ける限り同一のURLを使用し続けること）
- URL正規化（そのキーワードを表すURLはそのサイト内で一つのみ存在する、そのコンテンツはそのサイト内で一つのみの存在する）
- キーワードが分散している（/apple, /apple/index.php）
- ページを進んで戻ってくるとURLが変化している（/camera/list→/camera/list/1）
- トップページへのリンクの分散化（http://www.example.com, http://example.com, http://www.example.com/index.html） → 301リダイレクト
- 大文字小文字や最後の/の有無が揃っていない
- URL静的化（http://hoge.com/dir/file.html?query=fuga < http://hoge.com/dir/file/query/fuga）
- クロールできるa要素とリンク構造
- リンクを貼る際は内容的に関連するページに貼るリンクが効果的
- 1ページから放出する（に貼られている）リンク数は最大でも100本を目安に設計
キーワード・キーフレーズ
- アンサー度（ユーザのニーズを満たせているかどうか）
キーワード
- キーワードとは
- 言葉の一致
- キーワードの守備範囲
- キーワードの人気度の調査
- キーワーードのグループ構成
- キーワードの選定
- 潜在顧客の検索行動の洗い出し
- 人気度・コンバージョン・競合度の調査
- キーワードのグループ分けと優先順位づけ
- 形態素分析
- カテゴリー
- 複数のカテゴリー軸の組み合わせ
アンサー度
- アンサー度とは
- テーマの一致
- 多様性
- 検索語タイプ
HTMLの最適化（これからはじめるSEOの教科書）←ここ
1, title
2, meta description
3, mata keywords
4, h1
5, h2~h6
6, ul, ol
7, strong
8, center
9, imag
10, リンクの最適な使い方（どういうリンクを貼るべきか）
11, ドキュメント宣言
12, headタグ内で必要なものと不必要なものの仕分け
13, 重要キーワードが重要位置にあるか
14, ページ内が適正な文字数・文字比率になるようチェックしよう
15, HTML内の贅肉を落としスリム体質にしよう
16, 重要ではないタグやキーワードを下方に移動させよう
17, パンくずリストを作成しよう
18, サイトマップを作ろう
19, 内部リンクを張り巡らそう
20, ファイルサイズを縮小化しよう
21, 美しいソースコードに修正
22, URL正規化でバックリンク分散を回避しよう（複数存在のURLを一つに統一）
23, 足を引っ張り合うミラーサイトをなくそう
24, SEO対策が行われているかをチェック（http://ferret-plus.com）
25, 上位表示に必要なURLの付け方
26, NGタグの撤廃・改善
27, スパムについて
アクセスログとインデックス状況の分析
アクセスログ
アクセス解析に使う狭義のアクセスログ＝webサーバーの生ログ（webサーバーが生成するテキストファイル）
リファラー ＝あるwebページのリンクをクリックして別のページに移動した時のリンク元のページ。
- Apache(Linux, UNIX系) Combined, Common ※リファラー情報がない、でも容量が多いから保管場所には注意
- IIS(Windows系) W3C Extended(W3C拡張) 自由にフォーマットを変更できるヘッダー領域。
リファラーから検索キーワードがわかる。
インデックス数
クロールされているからといって、インデックスされているとは限らない。したがって定期的にインデックス数を確認する必要がある。
- webの管理ツール
- 検索エンジンコマンド http://himazines.com/web/seo-keyword-kensaku-command/
分析手法
- コンバージョン分析
- 被リンク数
- PageRank
- 検索順位
- 視聴率
アクセス解析の導入
https://analytics.google.com/analytics/web/#report/defaultid/a49424310w110721923p115496641/
ビーコン型アクセス解析
ASP(Application Service Provider)側のサーバーに置かれているJSのタグを全ページに貼り付ける。ページがロードされるとJSのプログラムがCookieの有無を調べCookieが未発行だったり有効期限が過ぎていたりした場合は新規にCookieを発行したりすることで、情報を自動的にASP側に集約していく。JSを実行できないページ（リダイレクトページ、ファイルのダウンロード、ロボットのアクセス）は解析対象にできない。
ファーストパーティcookie 現在閲覧しているサイトと同じドメインが発行するcookie →google analytics
サードパーティーcookie 現在閲覧しているサイトとは異なるドメイン、例えばアクセス解析ASPのドメインが発行するcookie
バケットキャプチャー型
データセンターにネットワーク上を流れるパケットを受信できる機材を用意して、パケットの中身を取り出して集計する。どんなトラフィックでも解析が可能。リダイレクトやファイルのダウンロードのようなものも対象にできる
生ログ型
生ログを解析する。JS, Cookie, ネットワーク機器に依存していないため、ほぼどんなシステムを利用していても分析が可能。携帯電話からのアクセスが携帯キャリアの設置するゲートウェイサーバーになっているため、ログにそのサーバのIPアドレスが記録されるため、複数の携帯電話からのアクセスが一つのセッションにまとまってしまう。
検索エンジンスパム
- スパムとは、検索エンジンのアルゴリズムを利用して、意図的に検索順位を上げようとする検索エンジンにとっての迷惑行為。あらかじめ自分のサイトにしかけをしておき、クローラーやインデクサーを騙してサイトの評価をあげ、自然検索結果の露出を高める行為。
ペナルティ
- 一時的もしくは恒久的に意図的に検索順位を下げられる
- 一番のキーワードで検索結果に出なくなる
- そのドメインごと、検索結果に表示されなくなる
ソフトウェアでのチェック→目視でのチェック
スパム手法
DNSスパムはDNSのワイルドカードを利用してサブドメインを大量作成し、検索エンジンに登録する行為
- 外部リンク系
- リンクファーム、有料リンク
検索エンジンの制御
robots.txt
クローラーにインデックスやクローリングの制御情報を渡すにはrobots.txtというファイルをやりとりする必要がある。 http://www.robotstxt.org/robotstxt.html https://support.google.com/webmasters/answer/6062608?hl=en https://moz.com/learn/seo/robotstxt
サイトのルートディレクトリに設置しておくことで、クローラーがHTTPプロトコルをGETして内容を読み取り、その内容にそったクローリングをしてくれる。
http://www.google.co.jp/robots.txt
- どのロボットに対する指示か
アクセス拒否するディレクトリやファイルの列挙
noindex 検索結果に表示されない、表示する、pagerankはつく、キャッシュもされる。
nofollow このページから、クロールさせる、させないの指示をする
Sitemaps
https://www.sitemaps.org/index.html
googleが策定した規約で、URLの一覧をxmlファイルやテキストファイルで通知する方式 インデックスの促進が目的なので、検索順位に影響が出るわけではない。
縮退運転
クローラーが来ているタイミングでサイトを停止させないため
データベースモデリング
レスポンスが遅いのは検索エンジン側からするとよくない
並び順 重要なものを上に表示する必要があるので、それを考える必要がある。 例 その季節のものを上に表示するようにする
エイリアス キーワードの別名を格納する
事前計算 複雑なクロスカテゴリーなどの場合に、件数を計算しておき、0件の場合は表示しないようにするみたいな
マルチアサインとマスターカテゴリー 一つのカテゴリーが二つの親カテゴリーに紐づくことがある。構造上二つの上位カテゴリーに属していることにする必要があり、そうするとURLの正規性を保つことができる。
キーワードカテゴリー、ショートカットカテゴリー キーワードでの関連性で関連のあるリンクを作るようにする
ID体系とURLの関係 リレーション変更によってURLが変更されないようにDB設計する必要がある
ツール
サイト管理ツール GoogleWebMasterTool
ソースコードエラーチェック http://validator.w3.org/
サイト診断 http://www.seotools.jp/ https://ferret-plus.com/ http://seocheki.net/ https://moz.com/researchtools/ose/
サイトマップ作成 https://www.xml-sitemaps.com/
SEOに関する情報収集 https://www.webmasterworld.com/
参考文献
https://d2eeipcrcdle6.cloudfront.net/seo-cheat-sheet.pdf support.google.com support.google.com
- 作者: 瀧内賢
- 出版社/メーカー: 技術評論社
- 発売日: 2012/10/11
- メディア: 単行本（ソフトカバー）
- 購入: 3人 クリック: 21回
- この商品を含むブログ (20件) を見る
SEOを強化する技術 エンジニアが内側から支えるサイト設計・構築術
- 作者: 安川洋,伊藤大典
- 出版社/メーカー: インプレス
- 発売日: 2009/12/18
- メディア: 単行本
- 購入: 10人 クリック: 353回
- この商品を含むブログ (10件) を見る
junior engneerがインターン先Rでそこそこちゃんと仕事をして思ったことまとめ
ライブラリの選定
何かプラグインなり、ライブラリを使いたい時は、なぜそれを使いたいのか、なぜそれが良いと思うか、どう使いたいかを伝える。
ライブラリ導入時のチェック項目
- [ ] issueの数
- [ ] 星の数
- [ ] それに関連する技術のバージョンを調べる
- [ ] 何年前から使われているか調べる（枯れているか）
仕事の順序
(自分が手がけているプロジェクトと同様の環境の遊び場を使っていじったりする)
1.ゴールを理解する、解決したいことを明確にする（それについてわからないこと、知りたいことを明確にする、それは調べる方法（ググるのか、githubでコードを読むのか）も同様） ex) 一部のリソースへアクセスするポリシーの作りかた、またそのコード
2.その解決方法を調べて、上長にこの方向で解決しようと思うのだがどうか？（自分なりの仮説、メリットデメリットを具体的かつ簡潔に伝える）という形で質問する
3.PRをwipで出して、実装方針を整理し、正しい方向性か上長に聞く。そのコードについて深く考える。その冗長だったら何て言うか考える。
4.PRのreviewをお願いする。PRはreviewerが疑問に思う可能性がある処についてなぜそうしたのか、ちゃんと説明す。reviewerの負担を減らすことを考える、他のメンバーのことも考える。
一言
「仕事とはただqiitaにまとめてあるような実装をして、コードを書いて動かすようにするだけではない。そのコードに責任感を持ち、問題解決を行うのが仕事である。」と思いました。
なんか自分がやってきたことってわりとrailsのコードを書いて何かを動かすようにするという感じで、しかもゴリゴリのスタートアップだったのでとりあえず動くようにして当然のごとくテストなんて書かないしという感じだったので、仕事といえばただ動かすようにすればいいという感じでした。だから、Rに入って技術選定からドキュメントの作成、社内でのコミュニケーションなどあーエンジニアってコード書くだけじゃなくて、問題解決が仕事なんだと思いました。なんか自分で作る時はデバッグして動いたー！！楽しい！！って感じだけど、仕事はそうじゃないなと。ググって一番上に出て来たやつを何も考えずに採用している場合ではないなとおもいました。
あと仕事って最終的なゴールはこのフローを上長の存在なしでできるようにすることだと思う。そうすると自然と上長に何か聞くことが少なくなって、あいつは「仕事ができる」ということになるのではないか。
また明日から頑張っていきたい。
これを見るだけで読んだ気になれるリーダブルコードチェックリスト +α
名前に情報を詰め込む
[ ] 明確な単語を選べていますか？
- 類語辞典
- send, deliver, announce, distribute, route
- find, search, extract, locate, recover
- start, launch, create, begin, open
- make, create, set up, build, generate, compose, add, new
[ ] 汎用的な名前を避けていますか？（あるいは使う状況を選ぶ）
- tmp, retval, イテレータ(i,j,k) これらの汎用的な名前を使うときは。それ相応の理由を用意（一時的な保管が最も大切な場合など）
- [ ] 抽象的な名前より具体的な名前を使えていますか？
[ ] 接尾辞や接頭辞を使って情報を追加していますか？
- 時間やバイト数のように計測できるものであれば単位をつける
[ ] 名前の長さは短いですか？
- 長い名前を避ける
- スコープが小さければ短い名前でもいい
- 頭文字と省略形
- doc document
- eval evaluation
- str string
- 不要な単語を投げ捨てる
名前に含まれる単語を削除しても情報が全く損なわれないこともある
- ConvertToString → ToString
- DoServerLoop() → ServerLoop()
[ ] 名前のフォーマットで情報を伝えていますか？
- クラスのメンバ変数にアンダースコアをつけてローカル変数と区別する
誤解されない名前
名前が他の意味と間違えられることはないだろうかと何度も自問自答する
[ ] より具体的な意味を持った動詞を使えていますか？
- filter() → select, exclude
- clip() → remove, trancate
[ ] 範囲の値の変数はそれで正しいですか？
- min/max 限界値を明確にする場合（未満、以下）
- first/last or begin/end
[ ] 真偽値は以下の項目を満たしていますか？
- [ ] 頭にis, has, can, shouldなどをつけてわかりやすくする
- [ ] 否定形を避け肯定形にする
命名するときの手順
1.その関数、変数に関わる情報を日本語で考えて、ブレストする
2.それを英訳して、類語辞典・githubで調べて適切な単語を抜き出す
3.その言語の命名規則にそって命名する
命名する前に読んだほうがいいリンク
- http://qiita.com/kenichi_cc/items/c3ecca7b7d5fc5c6bf2e#_reference-8eba7b768d7f1352746f
- http://qiita.com/Koki_jp/items/f3d3e824f98d182d4100?utm_content=bufferd7d8b&utm_medium=social&utm_source=facebook.com&utm_campaign=buffer
- http://qiita.com/Ted-HM/items/7dde25dcffae4cdc7923?utm_source=Qiita%E3%83%8B#qiita
- http://qiita.com/jnchito/items/3815a755b889b64a1840
コードのレイアウト
- [ ] 一貫性のある簡潔な改行位置ですか？
- [ ] メソッドを使って冗長な処理をまとめていますか？
- [ ] たての線（列）はまっすぐですか？
hoge("tanakatanaka", "foo" , "");
hoge("sato" , "fugafuga", "");
hoge("matz" , "bar" , "phone");
hoge("dhh" , "piyo" , "jobs");
[ ] 意味のある順番にならべていますか？
- 最重要
- アルファベット順
- 複雑なもの
[ ] 宣言はブロックにまとめられていますか？
- 論理的なグループにわける
- [ ] コードは似ている考えごとに段落に分割されていますか？
コメント
コメントの目的は書き手の意図を読み手に知らせること 基本的にはコードや、その名前でわかるべき。だが関数といして抽出していない処理などは何をやっているかわかりにくい場合があるので補足したほうがいいとは思う
コメントすべきことを知る
- [ ] コードからすぐわかることはコメントすべきでない
- [ ] ひどい名前はコメントせずに名前を変えろ 優れたコード>ひどいコード+優れたコメント
- 自分の考えを記録する（exこのクラスは汚くなってきている）
- コードの欠陥にコメントをつける
TODO: あとで手をつける FIXME: 既知の不具合があるコード HACK: あまり綺麗じゃない解決策 XXX: 危険大きな問題がある
- 定数を定義する際には、その定数が何をするのか、なぜその値を持っているのかという背景が存在する場合が多いのでコメントをしよう
- [ ] 質問されそうなことを想像する
- ハマりそうな罠を告知する
- 全体像についてコメントする
- 処理についての要約のコメント
- コメントは適当に書き出す→コメントを読んで改善が必要なものを見つける→改善の手順で書く。
コメントは正確で簡潔に
コメントはその書いた領域に対する情報の比率が高くないといけない
- [ ] 複数のものを指す可能性がある「それ」や「これ」などのあいまいな代名詞を避ける
- [ ] 歯切れの悪い文章を磨く
- [ ] 関数の動作をより正確に具体的に記述する
- [ ] 入出力のパターンを伝えることができる実例をコメントに書いておく
- [ ] コードの意図を詳細レベルではなく、高レベルで記述する
- [ ] よくわからない引数には、pythonでできるような名前付き引数コメントをつける
- [ ] 情報密度の高い（多くの意味が詰め込まれた言葉や表現）を使ってコメントを簡潔に保つ
制御フローを読みやすくする
- [ ] 左が調査対象（変化する）、右が比較対象（あまり変化しない）
- [ ] 単純な条件を先に書く
- [ ] 関心を引く条件や目立つ条件を先に書く
- [ ] 条件は否定形より肯定形を使う
- [ ] 否定形であっても単純で関心や注意を引く場合があるので、その場合はそっちを先に処理をする
- [ ] 三項演算子はわかりにくくならないもの（単純な二つの値から一つを選ぶようなもの）なら使う
- [ ] do-whileは使わない
- [ ] 関数から早く返す(ネストを浅くするときも使うことができる)
- [ ] if文などのループから返すのを内部で行うにはcontinueを使う
- [ ] go toは使わない
- [ ] ネストを浅くする
巨大な式を分割する
- 説明変数（式を表す変数）を使う
username = line.split(':')[0].strip()
if username == "hoge"
- 要約変数（大きなコードの塊を小さな名前に置き換えて、管理や把握を簡単にする変数）を使う
final boolean user_owns_document = (hoge == fuga);
- ド・モルガンの法則を使う
not (a or b or c) <=> (not a) and (not b) and (not c) not (a and b and c) <=> (not a) or (not b) or (not c)
- 分かりにくい短絡評価は良くない
assert((!(bucket = FindBucket(key)))||!bucket->IsOccupied());
今回の場合以下の方がわかりやすい
bucket = FindBucket(key); if (bucket != null) assert(!bucket->IsOccupied());
- 複雑なロジックはhogeの反対を考えてみたり、否定したりして、もっと簡単で綺麗な書き方を見つける
コードが読みやすくならない変数の削除
変数の追跡が難しくなる、スコープが大きいと把握する時間が長くなる、変数の頻繁な変更に伴い現在の値の把握が難しくなる
- [ ] 複雑な式を分割していない
- [ ] より明確になっていない（変数にしなくても十分明確）
- [ ] 一度しか使っていないので重複コードの削除になっていない
- [ ] 中間結果を削除する
function hoge(array, value_to_remove){
var index_to_remove = null;
for (fugafuga) {
if(array[i] === value_to_remove) {
index_to_remove = i;
break;
}
}
if (index_to_remove !== null) {
array.splice(index_to_remove, 1);
}
}
関数から早く返すことで削除できる
function hoge(array, value_to_remove){
var index_to_remove = null;
for (fugafuga) {
if(array[i] === value_to_remove) {
array.splice(i, 1);
}
}
}
- [ ] 制御フロー変数を削除する プログラムの実行を制御するためだけの変数であり、実際のプログラムに関係のあるデータは含まれていない
boolean done = false;
[ ] 変数のスコープを縮める
- アクセス修飾詞を使う
- 大きなクラスを小さなクラスに分割する
- 最初から全ての変数を知る必要はないので、変数の定義は変数を使う直前に移動する（変数の数による）
[ ] 変数は一度だけ書き込む 変数を操作する場所が増えると、現在値の判断が難しくなる
無関係の下位問題を抽出する
プロジェクト固有のコードから汎用コードを分離するということ 1.関数やコードブロックを見て「このコードの高レベルの目標は何か ？」と自問する 2.コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは無関係の下位の問題を解決しているのか」と自問する 3.無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする
ただし、新しい関数をコードに追加すると、ごくわずかに読みにくさのコストが発生する。そことの兼ね合い。
一度に一つのことを
単一責任の原則
コードに思いを込める
1.コードの動作を簡単な言葉で同僚にもわかるように説明する 2.その説明の中で使っているキーワードやフレーズに注目する 3.その説明に合わせてコードを書く
- [ ] ロジックを明確に説明する
- [ ] ライブラリを知る
- [ ] 解決策を言葉で説明する
プログラムを言語化（自然言語）することで、明確な形となる
短いコードを書く、コードを小さく保つ
もっとも読みやすいコードは何も書かれていないコード
- 不必要な機能をプロダクトから削除する、過剰な機能はもたせない
- [ ] もっとも簡単に問題を解決できるような要求を考える
- [ ] 定期的に全てのAPIを読んで、標準ライブラリに慣れ親しんでおく
- [ ] js
- [ ] ruby
テスト
今後追加します
参考リンク
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
- 購入: 68人 クリック: 1,802回
- この商品を含むブログ (137件) を見る
minify javascript
どうすれば王道の方法にたどりつけるか考えて検索できた。
minify js google でgoogleのdeveloperガイドが出てきて、jsを軽量化するには、uglifyjsかClosure Compilerでやるといいと書いて合ったので、githubのreadmeを読みつつやって見たら、ちゃんと一行にして、軽量化できた。
$ uglifyjs source/javascripts/vendor/cookie.js -c -m -o source/javascripts/vendor/cookie.js
-o, --output <file> Output file (default STDOUT).
-c, --compress [options] Enable compressor/specify compressor options.
-m, --mangle [options] Mangle names/specify mangler options.
参考リンク
https://developers.google.com/speed/docs/insights/MinifyResources https://stackoverflow.com/questions/20653578/how-to-uglify-javascript-using-uglifyjs-2 https://github.com/mishoo/UglifyJS2 https://developers.google.com/closure/compiler/
