windowsマシンでのpythonGAE開発環境が遅くて仕事にならない件の解決法
GitHubでのIssue管理及びPullRequestの流れ
画面左側の「Issue」ボタンを押します。
2.画面左上の「New issue」を押します。
3.タイトルと内容を記入して、「Submit new issue」を押します。
4.Issue番号が発行されました。これを覚えておきます。後で作成するブランチ名をこのIssue番号にするからです。
5.eclipseの「Git リポジトリー」タブにて、新規ブランチを作成します。
ブランチ名は何でも良いのですが、慣習的にIsuue番号と同じにしましょう。
※後々ぱっと見で分かりやすいので。
6.新規ブランチとして「#6」というブランチが作成されました。
このブランチを編集していきましょう。
7.編集が完了したら、コミットしてリモートリポジトリにこのブランチをプッシュします。
この時、コミットコメントに「#6」とIssue番号を書くことを絶対に忘れないでください。
このコミットコメントを以て、このコミットとIssueが紐づくわけです。
(自動でブランチ名をコミットコメントに追加するプラグインでもあれば忘れにくくなるでしょう。要調査)
8.以下のような画面が出てきたら、ソース参照から現在のブランチを選択し、「仕様の追加」を押します。「完了」ボタンを押すことで、#6のブランチがリモートリポジトリにプッシュされます。
9.GitHubに戻ると、「Compare & pull rquest」というボタンが表示されています。
このボタンから、管理者(※1)に「ちゃんとしたソースだったらmasterブランチ(本番環境)(※2)にマージしてくださいな♪」というお願いを出します。
次の画面でコメントを入力し、「Create pull request」を押します。
10.管理者(※1)でGitHubのリポジトリを開くと、Pull requestが届いています。
リンクから変更点なども見れます。実際にローカルに落としたりして動作確認します。
11.ソースの修正に問題がなければ、「Merge pull request」ボタンを押して、#6のブランチをmasterブランチにマージします。
12.masterブランチにマージされました。pull requestも自動でcloseされました。
13.Issueは自動でcloseされないようです(※3)。Isuueをcloseしましょう。
リポジトリトップ画面からIsuue -> #6のIsuueを選択し、開きます。
(尚、先ほどのコミットコメントがこのIssueに紐づいていることもこの画面で確認できます)
close用コメントを入力し、closeします。
14.次に、不要になったブランチも削除します。こちらも自動でremoveされないようです(※4)
リポジトリトップ画面のbranchを押します。
次の画面で、#6のブランチのゴミ箱アイコンを押すことで、このリモートリポジトリから#6のブランチを消すことができます。
15.最後にローカルの開発環境を整理します。リモートの変更をローカルはまだ知りません。以下の画面のようにリモートブランチが残っています。
16.ローカルの該当リポジトリにて「git remote prune origin」コマンドを実行します。
これで、ローカルにもリモートの変更が同期されます。
17.残った#6ブランチは名前を変えて、リベースすれば、また次の作業ブランチとして使えます。
(※1)管理者って？
→おそらくリポジトリのownerだと思われるが調査不足。複数アカウントで実際にやってみないと分からない。また、ソースレビュアとして複数人をpull requestの受信者(マージ権限者)に設定することができるかも調査不足。
(※2) masterブランチにマージするのか？developブランチなど別ブランチではないのか？
GitHubFlowでは、今までのGitFlowのようにいろいろなブランチを作らず、masterと作業用のブランチという2種類のみにすることで、GitFlowを簡略化する目的があるそうです。
Gitブランチを使いこなすgit-flow／GitHub Flow入門（終）：プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - ＠IT
(※3)Issueの自動closeはできないのか？
調べていたら、コミットコメントでできるかもって感じでした。
できました。
但し、これもコミットに書き忘れると不要Issueが残りまくる可能性もあると思います。
【Github, Gitlab】コミットメッセージにissueクローズを書き忘れたときの対処法 - Qiita
(※4)マージした不要ブランチは自動で削除されないのか？
されません。が、上記12の画面(マージ完了画面)で「Delete branch」ってボタンがありました。これを押せばすぐに該当ブランチは消えます。
html5のcanvas × スクロールで自由描画がずれる？
html5のcanvasのmoveToやlineToを駆使して、お絵かきツールを作成するような参考ソースは、ggればたくさん出てくる。しかし、表題の通り、画面をスクロールすると、ペンの描画がカーソルと全然違うところから始まってイライラすることはないだろうか。
この原因は、以下、
// 開始位置を取得
var startX, startY;
$("#canvas").on("mousedown", function(e) {
startX = e.x;
startY = e.y;
});
$("#canvas").on("mouseup", function(e) {
var ctx = document.getElementById("canvas").getContext("2d");
ctx.moveTo(startX, startY);
ctx.lineTo(e.x, e.y);
ctx.closePath();
ctx.stroke();
});
と、まぁソースはこんな感じになるだろうが、曲者は、
「e.x, e.y」
こいつらである。つまり、マウスの開始終了座標の指定方法にある。
なんとなく察しはつくと思うが、スクロール分が考慮されていないのである。
マウスが持つ座標の取得方法としては、
- e.pageX = スクロールしてもhtmlの一番左上からの距離
- e.layerX = スクロールしても対象要素の一番左上からの距離
- e.clientX = ブラウザの描画画面の左上からの距離(スクロール無視して)
- e.screenX = PCモニターの左上からの距離(スクロール無視して)
- e.x = e.clientXと同じ
のように、モダンブラウザでは多様にプロパティを持つため、適切なプロパティを選択してやる必要がある。
上記サンプルでは、clientXとして座標を取られてしまうため、スクロール分を無視して描画されるというわけだ。よって、pageXに変更することで、このズレを解消できるはずだ。
上記サンプルのように簡単な例なら問題ないが、これが、独自のスクロールを持つdivブロックがhtml中に存在すると、body本体のスクロール量と、divのスクロール量とを引き算して、、とか訳わからん計算で十中八九死ぬ。
私が今使っている、fabric.jsというcanvasのフレームワークは、有難いことにこれら問題を簡単にやっつけてくれるのだ。
http://fabricjs.com/freedrawing/
fabric.jsの細かい説明はしないが、自由描画デモのリンクだけ貼っておく。
以下のように、fabric.utilに対して、scrollする可能性があるブロック要素を全てリッスンする。
var canvas = new fabric.Canvas("canvas");
fabric.util.addListener($("body")[0], "scroll", function() {
canvas.calcOffset();
});
fabric.util.addListener($("#div-block")[0], "scroll", function() {
canvas.calcOffset();
});
すると、指定されたブロックがスクロールするたびに、自動で描画開始終了位置を再計算し直してくれるのだ！神だ！
全ての開発者が、こんな細かいところまで好き好んでごにょごにょできない。
このような面倒を減らしてくれるフレームワーク開発者は素晴らしい。
開発者は基本面倒くさいからフレームワーク作って2度と面倒くさいことをしないようにする仕事をするくらい面倒くさがりだから開発者なのであって、そーゆー面倒くさい奴は、大体開発者に向いてると思う。
CSSの優先順位
CSSは、書いても思い通り適用されない、複雑になるというイメージがある。
確かに複雑なのだが、少しだけ救われるヒント。
・基本的には、後に書いたもの、読み込まれたものが優先される。
・CSSはポイント制になっており、ポイントに従って適用される優先順位が変わる。
[ポイントについて]
<div id="section-a" class="section-block">こんにちは</div>
という要素があるとして、
1.タグ(divなど)での指定は1ポイント
例)
div {
color: #F00;
}
2.クラスでの指定は10ポイント
例)
.section-block {
color: #0F0;
}
3.IDでの指定は100ポイント
例)
#section-a {
color: #00F;
}
上記3つがすべてCSSに指定されていたら、書かれた順(読み込み順)に関係なく、文字色は最高ポイントを持ったスタイルが適用され、青くなる。
これらを踏まえて、、
div.section-block {
color: #FF0;
}
のようなセレクタ指定では、1 + 10 = 11ポイント。
.section-block#section-a {
color: #0FF;
}
のようなセレクタ指定では、10 + 100 = 110ポイントとなる。
後に書かれていても、ポイントが高い方に書かれているスタイルが適用される。
また、ポイントが同じスタイルが存在した場合は、後に書かれている(読み込まれている)スタイルが適用される。
それでもやはりCSSは複雑なのだが、知ってると少しはマシになるだろう。
