htmlファイルの上の方にいるあいつら
ブログ長らく放置していたけど、しれっと再開しますw
あまり肩肘張らずちょっとした内容でもちょいちょい更新していきます。
そして基本的には丁寧語とか使わず、自分用のメモに近い形で書いていきます。
htmlファイルの先頭とかhead内にいろいろ書くと思うんだけど今までコピペで済ませていた。 ちょっくら必須なやつだけでも簡単にまとめてみようと思う。
例
この例に出てくる<body>より上の要素を解説
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width">
<meta name="description" content="...">
<title>解説するお</title>
<link rel="stylesheet" href="css/style.css">
<script scr="js/script.js"></script>
</head>
<body>
<!-- なんかいろいろ -->
</body>
</html>
<!DOCTYPE html>
- 文書が
HTML5で書かれたことをブラウザなどに対して明示する宣言HTML5では、videoタグなど新たな便利なタグが使えたり、フォームの機能が拡張されていて便利- 参考：yahooのブログ
- 文書の先頭に記述する
<html lang="ja">
lanf="ja"と指定することで、日本語の文書であることを明示する
<head>
<meta name="viewport" content="width=device-width">
- 仮想的に表示領域を指定する
- この書き方だと、デバイスのサイズに合わせてページを表示する
- content="width=360"ってすると、横幅360px用の描画を行う
- コピペで済ませていませんか？改めて学び直したい「Viewport」のすべて
<meta name="description" content="...">
- 検索結果の説明文に表示される文言
- SEOの効果を高めるために重要らしい
<link rel="stylesheet" href="css/style.css">
- 読み込むスタイルシートを指定する
<script scr="js/script.js"></script>
- 読み込むスクリプトを指定する
参考
ハイパフォーマンスWebサイトを読んで
こんにちは。
寒くなってきましたね。
半袖じゃ若干きついですね、、、
仮想通貨を少し買ってみてるんですが、値段の乱高下が半端ないですね。
ビットコインの分裂があーだこーだというのを聞いても実際がよく分からないので、
近々ブロックチェーン技術を勉強しようと思います。
とはいえ今回は別のテーマで、前回に引き続きWebの基本的なところです。
何を読んでも知らないことばかりなのは変わりありませんが、
少しずつ理解が容易になってきていることで自分の成長を感じるここ最近ですw
概要
サイトを高速化するための方法について。
サイトが表示されるまでの処理で時間が消費される割合はフロントエンドが80%程度とほとんどの割合を占めている。
ブラウザがサーバーからHTML文書を取ってくるバックエンドの処理は20％に過ぎないので、
フロントエンドの処理を変えることで大幅な高速化を実現できる可能性がある。
全体の構成
- フロントエンドパフォーマンスの重要性
- HTTPの概要
- ルール1: HTTPリクエストを減らす
- ルール2: CDNを使う
- ルール3: Expiresヘッダを設定する
- ルール4: コンポーネントをgzipする
- ルール5: スタイルシートを先頭に置く
- ルール6: スクリプトは最後に置く
- ルール7: CSS expressionの使用を控える
- ルール8: JavaScriptとCSSは外部ファイル化する
- ルール9: DNSルックアップを減らす
- ルール10: JavaScriptを縮小化する
- ルール11: リダイレクトを避ける
- ルール12: スクリプトを重複させない
- ルール13: Etagの設定を変更する
- ルール14: Ajaxをキャッシュ可能にする
- 米国トップ10サイトの分析
HTTPリクエストを減らす
- 複数の画像を個別に取得する代わりにイメージマップを使う
- CSSスプライトを活用する
- Data URIスキームを使用する
- スクリプトおよびスタイルシートを結合する
CDNを使う
- CDN(Contents Delivery Network)を使うこと
Expiresヘッダを設定する
- Expiresヘッダをしていない場合、条件付きGETリクエストを発行する
- 最終的にはキャッシュを使うことになってもHTTPリクエストが送られるため、オーバーヘッドとなる
- Expiresヘッダを指定して、コンポーネントの取得時にキャッシュを使用するようにする
- max-ageを使うと、日付ではなく保持期間を秒単位で指定できる
- Apacheのmod_expiresを使うと、DxpiresDefaultをディレクティブでExpiresヘッダとmax-ageヘッダ療法を指定できる
- ファイル名にバージョンや日付などを付加することで、Expiresヘッダを長めに指定してもファイル変更時にファイルを取得しに行ってくれる
nekootoko.js?20171111やnekootoko.css?v=91と行った感じ
コンポーネントをgzipする
スタイルシートは先頭に置く
- スタイルシートはLINKタグを使用してドキュメントのHEADに置く、普通に
スクリプトは最後に置く
CSS expressionの使用を控える
- CSS expressionは、ロードの遅延やバグの原因になりうるので極力使用を控えるべき
JavaScriptとCSSは外部ファイル化する
- インラインと外部ファイルだとキャッシュがない状態での単純な比較だとインラインが早い
- HTTPリクエスト数が少なくなるため
- コンポーネントの再利用化やコンポーネントがキャッシュされるメリットが大きいので基本的に外部ファイル化するべき
- onloadイベントで、ページが完全にロードされた後で外部コンポーネントを動的にダウンロードする
DNSルックアップ回数の削減
JavaScriptを縮小化する
- JavaScriptのソースコードを縮小化する
- 縮小化(推奨)
- コードのコメントや余白を削除する
- JSMinなどのツールあり
- 難読化(非推奨)
- コードの変数を短いものに置き換える
- 保守性が低下する
- Dojo Compresser などのツールあり
- 縮小化(推奨)
- 縮小化とgzipの組み合わせを推奨
- CSSはコメントや空白文字が少ないので効果が薄い -> JSだけでよい
リダイレクトを避ける
- リダイレクトはHTMLドキュメント全体の配信を遅らせる
- 末尾のスラッシュの欠如の場合
- ウェブサイトの連結の場合
- 内部トラフィックの追跡の場合
- HTTPヘッダのRefererを活用する
- 外向きトラフィックの追跡の場合
- ビーコンもしくはリダイレクトもやむなし
- 覚えやすいURL
スクリプトを重複させない
- スクリプトが重複することでパフォーマンスが低下する要因は2つ
- HTTPリクエストが発生する
- Chromeはしなかったけど、最近のはするのかなぁ
- JavaScriptが無駄に実行される
- HTTPリクエストが発生する
- サーバーサイドで
insertScriptといった関数を作成する- 依存関係やバージョンも同時に扱えばなおよし(やりたい)
ETagの設定を変更する
- EtagはHTTPレスポンスヘッダに含まれている
- サーバーが異なる場合、異なったEtagとなるためファイルに変更がなくとも、304レスポンスではなく200レスポンスとなる
- Etagは設定を変えるか削除する方がよい
参考: HTTPヘッダチューニング Etag・Last-Modified
Ajaxをキャッシュ可能にする
終わりに
この本の執筆された2008年にはまだ一般的ではなかったこと(特にAjaxなど)が、
今では普通になっていることを考えるとWebの世界の移り変わりの速さを感じます。
ただ、今でもこの本のルールを活かせる部分も多いと思うので、
早速に会社に改善提案を出してみます！
安全なwebアプリケーションの作り方を読んだ
こんにちは。秋ですね。
昨日暖かかったし、今日は半袖で行けるやろって外出して後悔しています。
アラサー男とは思えない軽はずみな判断に我ながら絶句しています。
それでも今日も僕は元気です。
そんなどうでもいいことはともかくとして、
今回は「安全なWebアプリケーションの作り方」を取り上げます。
この本を読もうと思った背景ですが、ズバリ上司からの指摘です。
基本情報は取ったから知識としてはあっても、
それが実際の開発においてどう対策されているかといったことが分かっていない、と。
おっしゃる通り。
そこでよさげな本を調べた結果、この本に行き着いたわけです。
というわけで、この本の全体の構成から入ります。
全体の構成
- 第1章 脆弱性とはそもそも何か
- 第2章 実習環境のセットアップ
- 第3章 HTTP、クッキー、セッション
- 第4章 Webアプリケーションの機能毎の脆弱性
- 第5章 代表的なセキュリティ機能
- 第6章 文字コードとセキュリティ
- 第7章 携帯電話特有の脆弱性
- 第8章 Webアプリケーション以外の側面からの安全性向上施策
- 第9章 開発プロセス
第1章 Webアプリケーションの脆弱性とは
脆弱性とは、悪用できるバグのこと。 セキュリティバグとも言う。
- 悪用の例
- 個人情報などの秘密情報を勝手に閲覧する
- Webサイトの内容を書き換える
- サイトを閲覧した利用者のPCをウイルスに感染させる
経済的損失、法的な問題への発展、利用者への回復不能なダメージ、
ボットネットワークへの構築なんかにつながるからダメ！！
- ボットネットワークとは? ボットとは、PCに感染後、外部からの指令を受けて不正活動を行うマルウェアの事。 ボットネットワークとは、脆弱性のある改ざんされたWebサイトを閲覧した利用者のPCが ボットに感染して、そうしたPC同士がネットーワーク化した状態のこと。 攻撃者はボットネットワークを使ってDDos攻撃や迷惑メール送信を行う。
脆弱性には2種類ある。
- バグによるもの
- セキュリティ意識の不足からチェック機能が不足しているもの
脆弱性はバグだけではなくHTTPSを使っていないなど、セキュリティ機能の不足も含まれる。
第2章 環境設定
mac * vagrant なので、このサイトを参考に環境構築。
第3章 Webセキュリティの基礎
HTTPやセッション管理についての知識がなければ脆弱性を作り込む原因になるためHTTPを学ぶ必要がある。
GETとPOSTの使い分け
- GET
- 参照(リソースの取得にのみ用いる)
- データ更新など副作用を伴うリクエストには用いない
- POST
- 送信データが多い場合
- 秘密情報を送信する場合
- データ更新など副作用を伴う場合
セッションとクッキー
- クッキーセット、クッキーを含めたリクエストの流れ
- アプリケーションデータの保持のためにクッキーは通常利用しない
- クッキーが保持できる値の個数や文字列長には制限があるから
- クッキーの値は利用者本人には参照・変更できるので、秘密情報の格納に向かないから
- クッキーには整理番号としてのセッションIDを格納しておき、実際の値はサーバー側で管理する。
- クッキーの属性
- Domain
- Path
- ブラウザがクッキー値を送信するURLのディレクトリ
- Expires
- クッキー値の有効期限。設定しない場合はブラウザの終了まで
- Secure
- SSLの場合のみクッキーを送信
- HttpOnly
- JavaScriptから送信できないようにする。
- クロスサイトスクリプティング等の脆弱性対策として有用。
受動的攻撃と同一生成元ポリシー
- Webアプリケーションに対する攻撃は2種類ある
- 能動的攻撃
- 攻撃者がWebサーバーに直接攻撃すること
- 受動的攻撃
- Webサイトの利用者に罠を仕掛けることで、罠を閲覧したユーザを通してアプリケーションを攻撃すること。
- 罠サイトへの誘導、正規サイトに罠を仕掛けるなど。
- 同一生成元ポリシー
- JavaScriptで異なるホストからのアクセス(クロスドメインアクセス)を拒否すること
- 同一生成元(同じホスト)である条件
- 第三者のJavaScriptを許可することもある
- JS以外のクロスドメインアクセス
Webアプリケーションの機能別に見るセキュリティバグ
脆弱性の分類
- 脆弱性は大きく分けて2種類
- 出力に起因する脆弱性(=インジェクション系脆弱性)
- HTML、HTTP、SQLなど、Webアプリケーションに関わる技術がテキスト形式のインターフェースであることを利用。
- カンマやタブ、シングルクオートなど、決められた文法を持っていることを利用して攻撃する。
- HTML、HTTP、SQLなど、Webアプリケーションに関わる技術がテキスト形式のインターフェースであることを利用。
- 処理に起因する脆弱性
- ディクトリラバーサル、クロスサイトリクエストフォージェリなど
- 出力に起因する脆弱性(=インジェクション系脆弱性)
入力処理とセキュリティ
- 入力値検証はアプリケーションの仕様に基づいて行う
- 文字エンコーディングの検証
- 制御文字を含む文字種の検証
- バイナリセーフな関数かどうかの確認も必要
- バイナリセーフ - Unixなどで文字列の終端を示す'\0'を示すを正しく扱えるかどうか
- バイナリセーフな関数かどうかの確認も必要
- 各パラメータの文字種や文字数の検証
クロスサイトスクリプティング(XSS)
- 外部からの入力に応じて表示内容が変化する箇所のHTML生成の実装の問題から生じる脆弱性
- (ex)フォームに入力した内容をそのまま次のページで確認するとする。
入力内容が「
<script>alert(document.cookie)</script>」出会った場合、 クッキーが表示される。 - 上の例のように、サイト内容の書き換えやJSの実行などができる。
- (ex)フォームに入力した内容をそのまま次のページで確認するとする。
入力内容が「
- 3種類の被害
- クッキー値の盗難
- JSによる攻撃
- 画面の書き換え
- 対策
SQLインジェクション
データベースと連動したWebサイトで、データベースへの問い合わせや操作を行うプログラムにパラメータとしてSQL文の断片を与えることにより、 データベースを改ざんしたり不正に情報を入手する攻撃。また、そのような攻撃を許してしまうプログラムの脆弱性のこと。
例
- SQLインジェクションによる認証回避
- 下のように入力フォームの ID と パスワード を変数で直接SQLに入れているとき。
SELECT * FROM users WHERE id = "$user" AND password = "$id";
$user = 'yoshinaga', $password = ' " OR "a" = "a' とすると、下記のようなSQL文になる。
SELECT * FROM users WHERE id = "yoshinaga" AND password = " " OR "a" = "a";
id が存在する場合、ログインできてしまう。 同様の形で、データの消去、改ざん、挿入などが行うことができる。
- 考えられる被害
- データベース内の情報が盗まれる。
- データベースの内容が書き換えられる。
- 認証を回避される。 ( ID と password を用いずにログインされる )
- 対策
my $sql = 'SELECT id, name, weight, muscle FROM users WHERE muscle = ?';
my $sth = $dbh->prepare($sql);
$sth->bind_params(1, '; DELETE FROM users;');
$sth->execute();
- 上の例の場合、プレースホルダを用いていなければusersテーブルのデータが全て消去されてしまうが、 プレースホルダを用いることによって、? 箇所に入る文字列が必要に応じてエスケープされるため、データ消去は起こらない。
クロスサイト・リクエストフォージェリ(CSRF)
決済、送金、ユーザー情報の変更など、ログインした利用者のアカウントにより行われる取り消しできない操作の脆弱性。
- 攻撃手順例
- 対策が必要な箇所
- 購入や変更などの実際に処理が行われる箇所
- 確認画面ではないので注意
- 対策方法
- その他の保険的対策
- 処理があったことをメール送信することで不正に早く気づける
セッションハイジャック
Webアプリケーションでは認証結果などの現在の状態を記録するのにセッション管理機構が使われている。 現在主流のセッション管理機構は、クッキーなどにセッションIDという識別子を記憶させて、 セッションIDをキーとしてサーバー側で情報を記憶する方法。 ある利用者のセッションIDが第三者に知られると、その利用者になりすましてアクセスできる。
- 第三者がセッションIDを知る手段
- 対策
- クッキー管理機構は自作せず、Webアプリケーション開発ツールのものを使う
- クッキーにセッションIDを保存する(URLではなく)
- 認証成功時にセッションIDを変更する(固定攻撃対策)
- 認証前にセッション変数に秘密情報を保存しない
リダイレクト処理関連の脆弱性
- オープンリダイレクト脆弱性
- HTTPヘッダインジェクション
- 2つの脆弱性への対策
- リダイレクト処理には極力専用のライブラリ関数を用いる
- リダイレクト先のURLを固定にする
- リダイレクト先のURLを直接指定せず、番号指定などにする
- リダイレクト先のURLのドメインを十分にチェックする
クッキー出力にまつわる脆弱性
- 基本的にはクッキーにはセッションIDのみを用いる
- クッキーは改変されうるため
- クッキーの流出を避けるため、https通信の場合クッキーにセキュア属性をつける
メール送信の問題
ファイルアクセスに関わる問題
OSコマンド呼び出しの際に発生する脆弱性
- シェル呼び出し機能を呼び出す関数(system関数)に外部からのパラメータを渡した場合に発生する
- 「;cat /etc/passwd」といったような変数が渡されると情報漏洩する
- 原則としてOSコマンドを使わない実装方法を使うこと
- シェル呼び出し機能のある関数を避ける
- 使う場合には外部から入力された文字列を渡さない、渡す場合はエスケープする等の処理を行う
ファイルアップロードに関わる問題
不正を働くスクリプトがアップロードされ、 そのスクリプトが公開サーバにあって直接アクセスできる場合には、 不正なスクリプトの実行によって情報が流出する恐れがある
- 対策
- 拡張子をチェックすること
- コンテンツ内容をチェックすること
- 画像として読み込めるかなど
- 公開サーバに置かず、スクリプトでアクセスするようにすること
長かったのでまとめ
- ライブラリが用意されている場合には独自実装せずに素直にライブラリを使うこと
- 外部から入力されるパラメータを処理すること
- 重要な処理がされる前にはサイド認証すること
- クッキーにはパスワードなど重要情報をセットしないこと
- クッキーのセキュア属性、ドメイン属性、HttpOnly属性など正しく設定すること
- ログイン操作がある場合には、ログイン時にセッションIDを変えるとよい
代表的なセキュリティ機能
認証機能
- ログイン機能のセキュリティに必要なこと
- 前章までのSQLインジェクション、XSS、セッションID固定化などの対策
- パスワードの文字種、桁数の要件を検討する
- ログインIDを公開しないこと
- 積極的なパスワードポリシーのチェック
- ユーザーIDと同じパスワードは弾くなど(ジョーアカウントと呼ばれる)
- 総当たり攻撃対策のため、パスワードの保存方法を工夫すること
- 自動ログインに関して
- エラーメッセージを詳細にしない
- IDが間違っています等、だと使用されているIDが判明してしまう
アカウント管理
- ユーザーが入力したメールアドレスは必ず受信確認を行う
- 重要な処理に際しては再認証
- 重要な処理のメール通知
- アカウント管理では以下の脆弱性が発生しやすい
- CSRF
- SQLインジェクション
- メールヘッダインジェクション
認可
- 認可とは認証された利用者に対して権限を与えること
- 認可不備が発生するケース
- URLやhiddenパラメータ、クッキーなどに権限情報を格納して、それが書き換えられる
- ディレクトリやファイル名の直打ちでアクセスできる
- 対策
- データベースでロール毎に管理するのが望ましい
- ユーザー1は、管理者権限。 ユーザーには一般ユーザー権限といった形で登録しておき、
それぞれの権限毎に実行できる処理、表示する情報を変えて、情報の表示・処理実行前に権限を確認する
- ユーザー1は、管理者権限。 ユーザーには一般ユーザー権限といった形で登録しておき、
- データベースでロール毎に管理するのが望ましい
### ログ
- ログの必要性
- 攻撃や事故の予兆をログから把握し、早期に対策する
- 攻撃や事故の予後調査のため
- アプリケーションの運用監査のため
- ログの種類
- 記録すべきログ
- ログイン・ログアウト(失敗も含む)
- アカウントロック
- ユーザ登録・削除
- パスワード変更
- 重要情報の参照
- 重要な操作
- ログ出力の実装はログ用のライブラリが言語毎にたいていは用意されている
文字コードとセキュリティ
Webサイトの安全性を高めるために
開発マネジメント
- 開発ガイドラインの策定
- 脆弱性毎の対処方法
- 認証、セッション管理、ログ出力の実装方式
- 各フェーズでのレビューとテストの方法
- 開発メンバーの教育による体制の整備
- 事件事例の紹介
- 主要な脆弱性の原理と影響
- 遵守すべき事項
- 開発プロセスの整備
おわりに
すみません、度を超えた長さになってしまいやした。
こんだけ色々書いといてなんですが、
一番重要なのは、
Webアプリケーションの機能別に見るセキュリティバグ
の章まとめとして書いた部分数行です。
読みながら自分の会社のアプリケーションのコードに出てくるような対策が出てきて、
うちはセキュリティちゃんとやってんだなぁ、と当たり前のことをしみじみ感じました。
それではみなさん、3連休明けの月曜日を張り切って迎えましょう、、、
ソフトウェア開発者の人生マニュアルを読んで
こんにちは。
今日はこれからバスケの試合です！
東京はまた台風です、、、
室内競技でよかった！
今日は『ソフトウェア開発者の人生マニュアル』の内容をまとめます。
特に自分が取り組もうと思った内容だったりを中心にまとめていきます。
基本的な構成
- はじめに
- 第1部 キャリアを築こう
- 第2部 自分を売り込め
- 第3部 学ぶことを学ぼう
- 第4部 生産性を高めよう
- 第5部 お金に強くなろう
- 第6部 やっぱり体が大事
- 第7部 負けない心を鍛えよう
この中で特に印象に残った部分を中心に取り上げる。
はじめに
第1章の『あなたが読んだどの本とも「この本」が違う理由』にこの本の概略書かれているので、 まずはこの部分の一読を勧める。 簡単に紹介するとこの本では キャリア、マーケティング、学習、生産性、お金、健康、精神 について扱うので、この辺りに興味がある人はぜひ読んでみるといいと思う。 加えて、この本はそれぞれのテーマの中でも細かいテーマ別に分けて書かれているので、 合わせて目次を読んでみると自分が興味ある内容かも分かりやすいと思う。
キャリア
目標について
- 自分のキャリアの大きな目標を決める。
- 出世したいのか、ソフトウェア開発会社を立ち上げたいのか、独立したいのかなど、自分をどうしたいのか。
- 細かく決めなくてもいい。大まかにでも決めて、いつでも目に入る場所に置いておこう。
- 大目標がなんとなくでも決まったら、月、週、日の小目標を設定する。
プロであるということ
- プロとアマチュアの違い
| プロ | アマチュア |
|---|---|
| 常に従う原則を持っている | 頼まれたことなら何でもする |
| 間違っている時や知らない時に認めることを恐れない | 仕事をとにかく終わらせようとする |
| 首尾一貫して安定している | 持っていない知識を持っているふりをする |
| 責任を取る | 責任を避ける |
- プロであるためには
- いい習慣を身につけ
- 正しいことを行い
- 品質の追求と自己研鑽を欠かさない
その他のキャリアのこと
- 当然ながら社交は大事だよ
- 『人を動かす』がいいらしいので読まなあかん。
- 面接や履歴書にはコツがあるので戦略を立てよう
- 自分の市場価値を高めるために専門を絞ろう
- 働き方には大きく分けて3つあって、それぞれメリットデメリットがある。
- 会社で働く
- 大企業なのか中小企業なのかでも異なる
- フリーランスになる
- 起業する
- 会社で働く
- 特定のテクノロジーに固執せず、新しいものを受け入れよう
マーケティング
- 自分を売り込むこと、自分と働きたいと思ってもらうこと
- エキスパートでないことはマーケティングを始めないことの理由にならない
- ユニークな視点とか、他のソフトウェア開発者とは異なった視点だったり何かしら提供できるものはあるはず。
- ブログがもっとも手軽に始められてオススメ。(コレ)
- 他人の利益になることを発信しよう
- 講演する機会などがあれば積極的にやろう。書籍の出版なども
- 直接的な収益にはなりにくいが、自分を強くブランディングできる。
- ブログにせよ、講演にせよ、バカにされることを恐れない
学習
学び方を学ぶ
- 学ぶための最良の方法をまずはやってみること。
言語の本を最初から最後まで読んでも結局あまり書けないというのは実際に経験した。 - 学習の10ステップ
- 全体像を掴む
- 最初は分からないことすら分からない状態(実体験としてすごく分かる)
- まずはテーマ全体について調査して、テーマがどんなものか、どれくらい大きいのかについて調査する
- スコープを決める
- 自分がそのテーマの中で特に学ぶ必要があることはなんなのかを絞る。
- その際には自分が使える時間がどれくらいあるのかも考慮する。
- 成功の基準を決める
- 参考資料を見つける
- クオリティはとりあえず考えず、資料を書籍にも限定せずできるだけたくさん見つける。
- 学習プランを作る
- 参考資料の目次などを参考にして、学ぶ道筋を定める。
- リソースをフィルターにかける
- amazonレビューなどを参考にして、ベストな参考資料を選定する
- 使い始められるようにする方法を学ぶ
- 何も知らずに対象に飛び込むことも、飛び込む前に準備しすぎることも避けよう
- 教材の流し読み、章のまとめやイントロダクションだけ読んで、最小限だけ学ぶ
- 新しいゲームを買ってきて、プレイする前にさっと説明書を読むイメージ
- 遊び回る
- ステップ7でざっと学んだことを実際にどんどん使ってみる。
- そこで疑問に思ったことなどを参考資料に戻って調べて、見つからないものは書き出しておく。
- 役に立つところまで学ぶ
- 疑問に感じたこと、今学ぶ必要があることに焦点を当てて学ぶ
- 全部読もうとせず、ステップ3の成功基準の前進に役立つものを中心に学ぶ。
- . 教える
- 誰かに教える
- 教える人がいなければ、ブログポストに投稿する。
その他の学習のこと
- メンターを見つけて成長を加速させよう
- メンターになることにもメリットはある
- 教えることによって、自分の知識を確固たるものにできる。
- 知識の隙間を見つけて埋めよう
- 日常作業の中で苦痛に感じることを見つけ、知識の隙間を埋めてその苦痛を取り除く方法を考える。
- ex) ポインタを分からないままなんとなくやっててよくエラーが出るときには、
一度ポインタを深く学んでみるとか
- ex) ポインタを分からないままなんとなくやっててよくエラーが出るときには、
- 日常作業の中で苦痛に感じることを見つけ、知識の隙間を埋めてその苦痛を取り除く方法を考える。
生産性
- 何よりも集中することが大事。
- そのメール、チャットは集中の妨げになっている
- ポモドーロテクニックの導入(詳細はググろう)
- タイマーで仕事と休憩のサイクルを管理する手法
- 仕事(25min) - 休憩(5min) - 仕事(25min) - 休憩(5min) - 仕事(25min) - 休憩(5min) - 仕事(25min) - 休憩(25min)
- 四半期、月次、週次、日次といった計画表を作る
- クオータシステム
- 反復可能なタスクを選び、期間中に何度やる必要があるかなどを決める
- ex) ブログは週に一度、腹筋は週に3回など
- 期間中は厳格に行う(頑張ろう)
- 反復可能なタスクを選び、期間中に何度やる必要があるかなどを決める
- 責任を持って取り組む。責任を持ってやることを報告する相手がいるといい
- 仕事が分散しないようにする。メール処理は随時行うのではなく3時間に一度など
- 燃え尽き症候群は壁に当たって逃げているだけ。粘ろう
- 自分の習慣を見直そう。いい習慣、ルーチンを見直そう
- 朝起きて30分くらい2chまとめを見るのをやめて、すぐに起きて会社に行って毎朝勉強時間にあてます。
- 大変そうなタスクはブレイクダウンして少しずつ取り組もう。
- まずはやってみよう！行動しよう！
お金、健康
お金と体について。 お金についてはこの本でも勧められている『金持ち父さん貧乏父さん』はかなりお勧め。 自分の資産について考えるいい契機になるだろう。 体については筋トレして健康的な食生活を送りましょうw
精神
- プラス思考をしよう
- 自分に対してプラスなイメージを持つようにしよう
- 瞑想をするとか、たまには遊ぶとか自分の心のバランスを保とう
おわりに
このブログを始めるきっかけになった本をまとめてみました！
まずはブログを週一投稿するというクオータを少なくとも年内はコミットします！
gitのcommitについて調べてみた
こんばんは。 かまいたちがコント優勝しましたね！ かまちたちが昔やってた伏せさせて手をあげる奴めっちゃ好きです。 あらびき団懐かしい、、、
Git
gitを使っているもののよく分からないことが多かったんですよね。 HEAD ってなんだろとか、gitってそもそもなんなんだろ、生きてるってなんだろ、みたいな。 そんな時、後輩からプレゼントという言葉とともにこのリンクが送られてきました。 Gitのコミットの裏側で起こっていること この記事がとても面白かったので、この記事を元にいろいろコミットに関わることをまとめてみました！
コミットについて
- コミット情報の中には、5つの情報が入っている。
- 「コミット時のファイルの状態」の情報 = インデックス(staging area)にあった情報
- 「親コミットはどれか」という情報 親 - 現在選択しているコミット 子 - 新たにコミットしたことで作成されたコミットオブジェクト
- 作成者
- コミット者
- コミットメッセージ
- 親子のコミット情報を比べることで「2つのコミット間の差分」を知ることができる。
- ただし、最初のコミットはルートコミットと呼ばれ、親コミットの情報の代わりに、 以前は何もない状態であったことが記録される。
// 最新のコミット情報を表示 $git cat-file -p HEAD tree 80f6c9625d2da5708724f2fd12db101e43ddfe4d -> 1 parent 8d5e087b279d9d2003e532e78078eae14d05ff2b -> 2 author nekootoko3 <nekootoko3@gmail.com> 1508682946 +0900 -> 3 committer nekootoko3 <nekootoko3@gmail.com> 1508682946 +0900 -> 4 neko ni kansuru commit wo shitazo-! -> 5 // 最初のコミットの場合 // parent がない！！ tree 08585692ce06452da6f82ae66b90d98b55536fca author nekootoko3 <nekootoko3@gmail.com> 1508683149 +0900 committer nekootoko3 <nekootoko3@gmail.com> 1508683149 +0900 first commit dayo
1 の コミット時のファイルの状態については Gitのコミットの裏側で起こっていること こちらに詳しく載っておりましたが、今回割愛してます。
ブランチについて
- ブランチは特定のコミットオブジェクトを指し示すもの
HEADとは
- 特殊なブランチで「選択中のブランチ」を指し示す
- HEADが指し示すbranch = 今いるbranch
- なので、HEADとブランチとコミットオブジェクトはこのような関係になっている。
- HEAD -> ブランチ -> コミットオブジェクト
git branchあるいは.git/HEADを見ることで、 現在のブランチ (HEAD) を確認できる。HEAD -> ブランチ -> コミットオブジェクト の関係を確認。
// HEADの位置を確認 $ git branch * master neko $ cat .git/HEAD ref: refs/heads/master -> masterブランチが選択されていて、 masterブランチはどうやら refs/heads/master にあるらしい // ブランチの内容を確認 $ cat .git/refs/heads/master 9dd7cd67a1e8ce67e68b8e73fd162db78dce5b3e -> コミットオブジェクトようだ // ブランチの中身を確認 $ git cat-file -p 9dd7cd67a1e8ce67e68b8e73fd162db78dce5b3e tree 80f6c9625d2da5708724f2fd12db101e43ddfe4d parent 8d5e087b279d9d2003e532e78078eae14d05ff2b author nekootoko3 <nekootoko3@gmail.com> 1508682946 +0900 committer nekootoko3 <nekootoko3@gmail.com> 1508682946 +0900 neko ni kansuru commit wo shitazo-!
checkoutについて
git checkoutすると、2つのことが行われる。- HEADを指定したブランチに切り替える。
- 作業ディレクトリの内容を、そのブランチが指し示すコミットの状態に復元する。
mergeとrebaseについて
- マージすると、マージコミットという特殊なコミットが行われる。
- コミットオブジェクトが持つ情報もコミット時と少し異なる。
- 親コミットはマージしたブランチ2つになる。
- 「コミット時のファイルの状態」は、2つの親が持っていた情報を合わせたものになる。
- コミットオブジェクトが持つ情報もコミット時と少し異なる。
// マージしたコミット情報を出力 $git cat-file -p 8d5e087b279d9d2003e532e78078eae14d05ff2b tree 217f98d1f04a427cb1736ebe7e984ec71fb6f4ad parent 7b0c7594c52290df009b3fbe6ffe4bf144e46934 -> parentが2つになった！ parent fe656e3cd007b35cc492d879db944eb0494518e0 -/ author nekootoko3 <nekootoko3@gmail.com> 1508679080 +0900 committer nekootoko3 <nekootoko3@gmail.com> 1508679080 +0900 Merge branch 'neko'
- rebaseした時に行われる処理
- そもそもrebaseとは？gitのgraphを先に見よう。
// これが元のgraph * コミット4 (HEAD, master) Merge branch '修正2のブランチ' |\ | * コミット3 修正2 |/ | * コミット2 (開発ブランチ) 修正1 |/ * コミット1 // git merge 開発ブランチするとこうなる * コミット5 (HEAD, master) Merge branch '開発ブランチ' | \ * | コミット4 (HEAD, master) Merge branch '修正2のブランチ' |\ \ | * | コミット3 修正2 |/ / | * コミット2 (開発ブランチ) 修正1 |/ * コミット1 // git checkout 開発ブランチ // git rebase master するとこうなる * コミット2 (HEAD, 開発ブランチ) 修正1 * コミット4 (master) Merge branch '修正2のブランチ' |\ | * コミット3 修正2 |/ * コミット1
- rebaseであたかもmasterの最新コミットから、修正ブランチを切ったかのようにできる。
- ここで行なっている処理は次の流れ。
- 開発ブランチの各コミットで「どのような変更を行なったか」を記憶する。
- masterにcheckoutする
- そこから新しく開発ブランチを切る
- 記憶しておいた「どのような変更を行なったか」を適用し直していく
- 4の処理を行なっている際にはconflictが起きる可能性もある
その場合にはconflictを修正して、
git rebase --continue- やっぱやーめたって時には
git rebase --abort
- やっぱやーめたって時には
- ここで行なっている処理は次の流れ。
おわり
ということで、今回はgitについて書いてみました。 何事も深く理解するのは楽しいものですね！
参考リンク
git pull と git pull –rebase の違いって？図を交えて説明します！
Git をはじめからていねいに
