2017-07-14

エンジニアの勉強について

まず勉強には二種類あると思っている。それでこれら二つってお互いにすごく関連している気がする。たとえばあの基礎が抑えられてないから、これが理解できなくて、調べ方の指針もたたないみたいなことがたまにある。

仕事に必要な知識を得るための勉強、勉強というより調べ物に近いのかな例）terraformでこういうリソースを追加したいのだがそのコードはどう書けば良いか
長期で見たときに必要になってくる知識を得るための勉強、技術書中心、公式のリファレンスとか例）オブジェクト指向設計実践ガイドを読む (3. それらの仕事の仕方、仕事の効率化、)

1は仕事の仕方、問題解決に通じていると思うのだが、そもそもゴールがあって、それを解決するために調べる感じ。 - やりたいことがそもそも公式で推奨されていることとして存在するかどうか公式ドキュメントを見て探す in English あったらそれ読んでやってみる。わからなかったら日本語で読んでみる

その上でわからないことがあったら、仕事に必要になると考えられる条件を決めて 調べる

2は何かそれを使ってやりたいときにすぐわからないことにアプローチするためにインデックスを貼るためにやる感じ。一時期は本の内容の70%をメモしていた感じだったけど、今はどこに何が書いてあるのか、またその書いてあることを理解するために最低限必要な知識を書くようにしている。

でも問題なのが自分の投下時間におけるこれらの比率で、2をやりすぎたら普段の仕事終わらないし、1だけだと長期で考えたときにあの基礎が抑えられてないから、これが理解できなくて、調べ方の指針もたたないみたいなこともたまにある。

だから自分の中で長期の勉強と目の前のことのための勉強で時間を分ける必要がある。あと仕事の時間って、基本的に調べる（勉強する）時間+作業時間（実際に動かしたり、レビューもらう時間）に分かれると思っててその比率はそのタスクの達成難易度（作業量×自分の能力）による。自分の能力がそのタスクに関して低いと調べる時間が多くなるし、やり方わかってて動かすだけならほぼ作業だけで済む。

あと何かをやるときはかならず二日以上かけるように予定を立てる、つまりこの日に全部やろうと思って10時間まとまった時間をつくるより、5時間×2とかでやったほうがいい。そうすると多少伸びても時間の融通がきく。

自分の時間分け

そうすると朝起きての2時間は長期の勉強にあてる→絶対この時間は長期の勉強をする。この時間に勉強しないと長期の勉強はできないと思え！！またその日のタスクの調べ物は絶対にしない。キリがなくなるから。
仕事の際の調べ物はゴールを決めて調べて、最初から記事を書くつもりで読む。今までは一度読む→もう一度流し読みしながらまとめるみたいな感じだったので、最初から記事を書きながらみたいな感じでもいいから調べる。記事を書くこともそのタスクの一環として、調べたらすぐ記事を書く
あと早く自分の遊び場をつくる。

2017-07-12

SEOまとめ

SEOと検索エンジン

Webマーケティング

メルマガ
アフィリエイト
RSS
プレスリリース
Twitter
SEM(Search Engine Marketing)
- PPC(Pay Per Click)クリック課金の広告
- SEO(Search Engine Optimization)検索エンジン最適化←ここ

SEOとは、検索エンジンを利用するユーザーが入力するキーワードを導線としたキーワードマーケティング

キーワードとカテゴリーの設計 web担当者、マーチャンダイザー、インフォメーションアーキテクト
内的施策サイトのドメイン名やURL構成、HTML/CSSなどサイトの内側に施す対策　←ここ
外的施策 PageRank(価値やキーワードの関連性が高いページやドメイン、サイトからどのくらいのリンクを受け取っているか、被リンクがあるか)を上げるための対策 ex メディアサイトに取り上げてもらう、ブロガーにリンクを貼ってもらう。

検索エンジンの技術的な仕組み

検索エンジンの種類
- ディレクトリ型人間が作ったリンク集。整理、審査されているため探しやすいが、ほとんどがサイト単位
- ロボット型ソフトウェアによる自動収集型。ページ単位にインデックスしているため、情報が膨大クローラーがHTTPプロトコルでコンテンツを取得 →インデクサーが取得したコンテンツを解析し、分析結果とそのファイル自体をデータベースに保存。その際キーワードごとの検索結果も作成。 →クエリサーバーがユーザーからの検索クエリー（キーワード）の結果ページを返す

PageRank

「多くの良質なページからリンクされているページはやはり良質なページである」という再帰的な関係を元に全てのページの重要度を判定したもので、ランクされていないのPageRank 0 ~ 10までの全部で11段階の評価になっている。

被リンク数（リンクされているリンクの数）
評価の高いページからのリンクかどうか
リンク元ページでの放出リンク数（貼ってあるリンクの数）

検索エンジンのシェア googleとyahooが主 https://seopack.jp/seoblog/20160816-s-e-share/

SEOサイクルとクローラビリティー（webサイトをいかに巡回しやすいか）

SEOサイクル

診断　アクセス解析・仮説
設計　コンテンツ・SEO・カテゴリー・キーワード設計
実行　HTML/CSS作成、開発、リリース
外的施策　インバウンドリンク対策、メディア対策、プレスリリース

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には以下を使うASPがある

ファーストパーティcookie 現在閲覧しているサイトと同じドメインが発行するcookie →google analytics
サードパーティー cookie 現在閲覧しているサイトとは異なるドメイン、例えばアクセス解析 ASPのドメインが発行するcookie

バケットキャプチャー型

データセンターにネットワーク上を流れるパケットを受信できる機材を用意して、パケットの中身を取り出して集計する。どんなトラフィックでも解析が可能。リダイレクトやファイルのダウンロードのようなものも対象にできる

生ログ型

生ログを解析する。JS, Cookie, ネットワーク機器に依存していないため、ほぼどんなシステムを利用していても分析が可能。携帯電話からのアクセスが携帯キャリアの設置するゲートウェイサーバーになっているため、ログにそのサーバのIPアドレスが記録されるため、複数の携帯電話からのアクセスが一つのセッションにまとまってしまう。

検索エンジンスパム

スパムとは、検索エンジンのアルゴリズムを利用して、意図的に検索順位を上げようとする検索エンジンにとっての迷惑行為。あらかじめ自分のサイトにしかけをしておき、クローラーやインデクサーを騙してサイトの評価をあげ、自然検索結果の露出を高める行為。

ペナルティ

一時的もしくは恒久的に意図的に検索順位を下げられる
一番のキーワードで検索結果に出なくなる
そのドメインごと、検索結果に表示されなくなる

ソフトウェアでのチェック→目視でのチェック

スパム手法

HTML系
- 隠しテキスト
- 隠しリンク
- 極小フォント
- キーワード反復
- CSS系
サーバ系
- ドアウェイページ、リダイレクト
- クローキング
- 複製コンテンツ

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

これからはじめる SEO内部対策の教科書

作者: 瀧内賢
出版社/メーカー: 技術評論社
発売日: 2012/10/11
メディア: 単行本（ソフトカバー）
購入: 3人クリック: 21回
この商品を含むブログ (20件) を見る

SEOを強化する技術エンジニアが内側から支えるサイト設計・構築術

作者: 安川洋,伊藤大典
出版社/メーカー: インプレス
発売日: 2009/12/18
メディア: 単行本
購入: 10人クリック: 353回
この商品を含むブログ (10件) を見る

2017-07-09

junior engneerがインターン先Rでそこそこちゃんと仕事をして思ったことまとめ

ライブラリの選定

何かプラグインなり、ライブラリを使いたい時は、なぜそれを使いたいのか、なぜそれが良いと思うか、どう使いたいかを伝える。

ライブラリ導入時のチェック項目

[ ] issueの数
[ ] 星の数
[ ] それに関連する技術のバージョンを調べる
[ ] 何年前から使われているか調べる（枯れているか）

仕事の順序

(自分が手がけているプロジェクトと同様の環境の遊び場を使っていじったりする)

1.ゴールを理解する、解決したいことを明確にする（それについてわからないこと、知りたいことを明確にする、それは調べる方法（ググるのか、githubでコードを読むのか）も同様） ex)　一部のリソースへアクセスするポリシーの作りかた、またそのコード

2.その解決方法を調べて、上長にこの方向で解決しようと思うのだがどうか？（自分なりの仮説、メリットデメリットを具体的かつ簡潔に伝える）という形で質問する

3.PRをwipで出して、実装方針を整理し、正しい方向性か上長に聞く。そのコードについて深く考える。その冗長だったら何て言うか考える。

4.PRのreviewをお願いする。PRはreviewerが疑問に思う可能性がある処についてなぜそうしたのか、ちゃんと説明す。reviewerの負担を減らすことを考える、他のメンバーのことも考える。

一言

「仕事とはただqiitaにまとめてあるような実装をして、コードを書いて動かすようにするだけではない。そのコードに責任感を持ち、問題解決を行うのが仕事である。」と思いました。

なんか自分がやってきたことってわりとrailsのコードを書いて何かを動かすようにするという感じで、しかもゴリゴリのスタートアップだったのでとりあえず動くようにして当然のごとくテストなんて書かないしという感じだったので、仕事といえばただ動かすようにすればいいという感じでした。だから、Rに入って技術選定からドキュメントの作成、社内でのコミュニケーションなどあーエンジニアってコード書くだけじゃなくて、問題解決が仕事なんだと思いました。なんか自分で作る時はデバッグして動いたー！！楽しい！！って感じだけど、仕事はそうじゃないなと。ググって一番上に出て来たやつを何も考えずに採用している場合ではないなとおもいました。

あと仕事って最終的なゴールはこのフローを上長の存在なしでできるようにすることだと思う。そうすると自然と上長に何か聞くことが少なくなって、あいつは「仕事ができる」ということになるのではないか。

また明日から頑張っていきたい。

2017-07-05

これを見るだけで読んだ気になれるリーダブルコードチェックリスト +α

名前に情報を詰め込む

[ ] 明確な単語を選べていますか？
- 類語辞典
- 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.その言語の命名規則にそって命名する

命名する前に読んだほうがいいリンク

コードのレイアウト

[ ] 一貫性のある簡潔な改行位置ですか？
[ ] メソッドを使って冗長な処理をまとめていますか？
[ ] たての線（列）はまっすぐですか？

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

テスト

今後追加します

参考リンク

http://qiita.com/Kenya/items/faec4cc374edd5ffbba6

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

作者: Dustin Boswell,Trevor Foucher,須藤功平,角征典
出版社/メーカー: オライリージャパン
発売日: 2012/06/23
メディア: 単行本（ソフトカバー）
購入: 68人クリック: 1,802回
この商品を含むブログ (137件) を見る

2017-06-28

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/

2017-06-26

誰もあなたには興味がない、恥をかいた分だけ幸せになろう　「多動力」堀江貴文

多動力 (NewsPicks Book)

作者: 堀江貴文
出版社/メーカー: 幻冬舎
発売日: 2017/05/27
メディア: 単行本
この商品を含むブログ (3件) を見る

メモ

車輪の再発明をしないように気をつける
三つの肩書きを持てば1/100万。一万時間→1/100。仕事を掛け算するときは遠く離れてるものを掛け合わせた方が希少性が高まる。
全部自分でやらなければならないという思い込みをしていては多くの仕事をすることはできない、自分がもっとも力を発揮できる仕事だけをやろう
やりたいことはやりたいときに全部やり倒す習慣をつける
恥をかいた分だけ自由になれる
資産が人をダメにする。自分が持っているものをなんとか生かそうとすることであなたの動きは遅くなる、手持ちのカードを捨てやりたいことに最短距離で行こう hogeをしたい→hogeが必要が重要であり hogeをもっている→hogeをしないともったいないというのはよくない
予定調和の幸福を求める人生はつまらない、未体験の予定を詰め込んでみたことのない景色を見よう

感想、所感

ホリエモンはどの本でも一貫して、「やりたいことを今すぐやれ」ということしか言ってない気がする。すべてはそこから始まると

実際にできること

[ ] 一万時間がどのくらいなのか、年で計算する
[ ] 抱えているタスクをすべて書き出す
[ ] やらないタスクをやらない方法を考える
[ ] どんな形でもいいからアウトプットをする
[ ] 一日24時間をこと細かに書き出す
[ ] その中でワクワクしないことをやめる
[ ] 会うことがワクワクしない人は次会うので最後にする
[ ] 受けない仕事リストを作る
[ ] 退社時間を早めることで効率的に仕事を終わらせられるようにする
[ ] 同じような予定を過ごさない、土日の予定を考える

2017-06-26

あきらめない強い精神とは、まるで実態のない「できる」という呪文を頭のなかで反復する行為　「図解モチベーション大百科」

動機付け

キャンディ効果　メンバーのいい気分を作る　作業捗る
ご褒美の効果は二ヶ月
自問式セルフトーク　断定よりも疑問の方が答えとモチベーションを引き出す助けになる
日記に自分にとって今一番大切なことは何か、その価値に結びつくどんな行動をとったか書いてもらう、自分の価値観を思い出すと自信が強まり、周りの人に対する愛情が深まる
自発的な行動に対してご褒美を与えると内発的動機づけが損なわれる
なんの見返りも意義も生産性もないからこそ良い
やりたいことは手順を減らし、やめたいことは手順を減らす
他人の比較よりも自分の成長度合いによって評価された方が人は努力しやすい、前と比べてどうだったかを評価規準にする、客観的理由でやらない
インセンティブは成功したらあげるより、失敗したら取り上げる方が効果がある。基本的には安定や現状維持をめざしながら生きている

人をうごかすものは最終的には6つしかない

安定感
変化（不安定感）
重要感
つながり
成長
貢献

人材育成

人の考えは理由をたずねると強化され、目的をたずねると軟化する傾向がある
他人の言葉遣いに引っ張られず自分らしい言葉を使おう
やりたくないことはどうしたらやりたくなるかを考えよう
存在にむすびつけて褒めた方が意識の深いところに影響を与える
人は自分と主義が似ているけど考えを徹底していない人のことを嫌う傾向がある
仕事のずっと先を想像する、今自分が取り組んでいる仕事が社会にどんな風に役立つかを考えるとモチベーションが上がる
ダメだったものをまた試す、つまり何度か失敗したというだけでうまくいく可能性が残されているのにも関わらず私たちはいともたやすくあきらめやすい

目標設定

人は求められた以上のことはしない傾向にあるが、具体的で難しすぎず、受け入れられるレベルの目標を提示されるとやる気をだす、いつでもだれでも同じように解釈できる具体的なもの
競争心ではなく、あなたならできると向上心をあおる
信頼関係を築くには一緒に楽しいことをするより、協力が必要な場面を共有した方が信頼関係が芽生えやすい
目の前で起きている出来事そのものが、ラッキーかアンラッキーか決めているわけではなく、結果はその出来事に対して、どういう意味づけをするのかによって変化する
人は期限が見えないと集中できない
理由を考えると行動力が鈍り、何をすべきかに意識を向けると具体的な行動をしやすくなる
守らないと他人にどういう影響があるかを伝えよう
自分の作業日数は楽観的に見積もりやい
自分のこととなると安定志向になるが他人のことになると「なにをすれば後悔しないのかわかる」
エクササイズは2/3で疲れると予想する（コーチに10回やれと言われたら、15回くらいだと思うことにする）

意思決定

プロスペクト理論、得るものか失うものか話の順番によって選びたいものが変わる傾向がある
得られるものは何かにフォーカス→リスクのある選択肢を避ける、失うものは何かにフォーカス→多少のリスクをとってもいいと考えるようになる
穏やかに快適に暮らす幸せもある。あとで振り返った時にあのときは大変だったけど、良い経験だったと思える方が脳はより幸福を感じる。
自分の作業計画書を作る、必要なものをあたまで覚えていると必要以外のものも買ってしまいやすくなる、必要なものを紙に書いておけば衝動買いは減る、これは一日の予定も同様、朝一番に今日やることを紙に書いて、デスクの一番目立つところに貼っておく、シチュエーション別にやることを決める。休日も同様。
決定を先延ばしにすることによって自分にとって最適な答えを見つけやすくなる
常識はずれなものごとからはじめると独創的なアイデアがうまれやすい

OOCEMR

OUTCOME 何を差し置いても得たい結果を明らかにする
OPTION 選択肢を出し続けること
CONSEQUENSE なんでもいいからとにかく結果を出すこと
EVALUATE 得たい結果にどれだけ近づいているかを評価する
MITIGRATE マイナス面を減らすこと
RESOLVE 締め切りをつくること

自己管理

疲れているときほど、動作を大きくゆっくりにしよう
背中を丸めるとストレスのホルモンが出る
事前に考えすぎたり、分析しすぎたりすると行動力が鈍っていく
やりたくないことをするたびに自制心が減っていき、感情的になり、目の前の出来事に流されやすくなる
交互練習は集中練習と比べて、理解しづらく、成果も実感しにくいが、長期記憶の役にたつ
自分でコントロールできることがあると、幸せで健康的な生活を維持できる
ポジティブな空想は人をリラックスさせると同時に人の行動力を奪う可能性がある

発想転換

あきらめない強い精神とは、まるで実態のない「できる」という呪文を頭のなかで反復する行為
自分が直面している問題より他人が直面している問題の方が答えを見つけやすい
ピンチはチャンスというが、はじめからどこにでもチャンスはあるもの、ただピンチに没頭しているとチャンスが目の前を通っても気づけない
仮定で考えるよりそうなった前提から考えた方が、発想が膨らみやすい

感想、おもったこと

今回はメモしなかったが、人を巻き込む・仕事をしてもらう方法もたくさん書いてあったので、たくさんのひとに仕事を振るような立場になったら、もう一度読み返したい
モチベーションで大事なのは他人ではなく自分がどのくらい成長したか
物事を具体的にすれば行動につながる
期限とかを月単位のもの、週単位のもの、日単位のもの、三時間単位のもの、この30分間というように細かいものにしておくと、すぐに期限がせまってくるので、行動しやすくなる。結局だらだらまだ大丈夫というのは期限が先にあるからであって、常に期限が迫っている状態であれば、ケツに火がついてるどころか、ケツにロケットエンジンつけてるくらいのスピードで仕事できるのではないか。それはあと少し、あと少しと思い続けることによって工夫や行動の回数が増える。そしてその積み重なった達成感が自信に変わり、最終的にでかいことができる
プロスペクト理論はちょっと物事の言い方を変えるだけで、行動を促しやすくなるのでいいと思った。（リスクをとる選択肢を取って欲しかったら失うものは何かにフォーカスすればよい）
だれかに夢を語って気持ちよくなっていたらその時点でリラックスしてしまっているので、早くオフィスに帰って仕事をしましょう

具体的に実践できること

[ ] 今はポモドーロ効果を狙って、25分単位で作業をしているが、期限が細かく設定されていなかったので、二時間単位とかでの細かい目標もたてて、作業をする
[ ] 自分が取り組んでいる作業が自分のまわりの人、それよりもっと多くの人にとってどういう影響を与えているかを考える
[ ] すべてがうまくいったとしてどれくらいまでいけそうかを基準に目標を立てる
[ ] 二ヶ月後にご褒美を用意する
[ ] 自分が投下できると思った時間に2/3をかけて時間を割り出す
[ ] 普段の会話の中でプロスペクト理論を使う
[ ] 更新していないやりたいことリストを更新する
[ ] 前日の夜疲れている時間に次の日にやることを紙に書き出す
[ ] シチュエーション別にやることリストを作っておく
[ ] もう絶対に行かない授業を決める
[ ] 重要なこと（その課題の解決方法・実装方法など）は休憩を挟んでから決める
[ ] 人とは違う視点で物事を見るため、スケボーに引き続き乗り続ける
[ ] 飽きたらすぐ他の技術書・記事・リファレンスを読む
[ ] 夢を語ったら、夢が覚める前に現実に向けた一歩をふむ

図解モチベーション大百科

作者: 池田貴将
出版社/メーカー: サンクチュアリ出版
発売日: 2017/06/12
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

自分の時間分け

SEOと検索エンジン

検索エンジンの技術的な仕組み

SEOサイクルとクローラビリティー（webサイトをいかに巡回しやすいか）

SEO対策の三つのポイント

キーワード

アンサー度

HTMLの最適化（これからはじめるSEOの教科書）←ここ

アクセスログとインデックス状況の分析

インデックス数

分析手法

アクセス解析の導入

ビーコン型アクセス解析

バケットキャプチャー型

生ログ型

スパム手法

検索エンジンの制御

Sitemaps

縮退運転

データベースモデリング

ツール

参考文献

ライブラリの選定

仕事の順序

一言

名前に情報を詰め込む

誤解されない名前

命名するときの手順

命名する前に読んだほうがいいリンク

コードのレイアウト

コメント

コメントすべきことを知る

コメントは正確で簡潔に

制御フローを読みやすくする

巨大な式を分割する

コードが読みやすくならない変数の削除

無関係の下位問題を抽出する

一度に一つのことを

コードに思いを込める

短いコードを書く、コードを小さく保つ

テスト

参考リンク

参考リンク

メモ

感想、所感

実際にできること

動機付け

人をうごかすものは最終的には6つしかない

人材育成

目標設定

意思決定

OOCEMR

自己管理

発想転換

感想、おもったこと

具体的に実践できること