ローカルで作成したGitリポジトリを GitHub に push する

最近Git使い始めた。（仕事ではもっぱらSVN）
ローカル作業のバージョン管理だけやってたけどせっかくならGitHubも利用してみたい…ということでローカルに作成したリポジトリをGitHubに push する方法を調べた。

ほとんど↓に書いてある方法で出来たが、使ったことないコマンドあったのでメモしておく。
GitHubで、ローカルで作ったリポジトリから新規作成する - by shigemk2 - 

1. ローカルリポジトリ作成

今回はすでに完了していたけれども、まずローカルでリポジトリ作成〜コミットまで。

$ git init 
$ git add -A
$ git commit -m "optional message"

2. GitHubでリポジトリ作成

GitHubで "new repository" 。

3. リモートリポジトリを追加する

下記コマンドでリモートリポジトリ追加。

$ git remote add origin "https://github.com/<user name>/<repository name>"

4. ようやく push

$ git fetch
$ git merge origin/master
$ git push -u origin master

"-u branch master" は紐付けのために初回のみ必要とのこと。

git fetch ってとは。
git merge はなんとなくわかるがどんな挙動なんだ…というのは下記で。
fetch【リモートリポジトリ】 | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ - 

git fetchの理解からgit mergeとpullの役割 - Qiita - 


結果、GitHubに push できた。
https://github.com/ohbarye/PlayPractice

【余談】

途中、リモートリポジトリ名を間違えた。再度 git remote add しようとしたら、エラーが出た。その時の対応は下記。
【githubエラー】fatal: remote origin already exists.の対処 - iwaheiもといロックソルジャーのweb(メモ||日記) - 

APPLE MacBook Pro Retinaディスプレイ 2200/15.4 MGXA2J/A 買ったら最高だった

 Mac mini 売った

MacBook Pro 買ったと言いつつ、まず Mac mini 打った話。

長らく Windows を使いつつも Mac に対する漠然とした憧れがあって今年6月に Mac mini を買った。主に開発と音楽編集とかやろうと思ってた。

けど周辺機器を全然揃えてなかったのでほとんど使えなかった。

• ディスプレイがないのでテレビにHDMI接続してたけど、解像度を合わせるのも面倒でそのまま見てたら目が疲れた
• Mac 用のキーボードがないので Windows 用のキーボードを使っていたけど、キー配置が訳わからなくなって入力に疲れた
• トラックパッドがないので操作時にはマウスを使うことになってこれも疲れた

いろいろ揃えればなんとかなるってわかってももはや面倒くさくて熱が冷めていたので、テレビで映画観る時には Mac mini から再生する…ぐらいにしか使ってなかった。

Mac の利点をまったく活かせていないどころかPCとして全然機能しておらずインテリアになっていたので ¥44,000 で売却した。

全部自分のせいっちゃせいなんだけど、こういうのをいちいち調べて揃えるのも面倒な人はけっこういると思う。Mac mini、低価格で Mac に触れられるのは良いと思うけど、そいう意味で自分には向いてなかった。ケチって失敗したパターンだと思う。

MacBook 買った

なので最初からオールインワンになってる MacBook Pro 買うことにした。この時、もともと使ってた Lenovo のノートが限界近かった＆ので選択肢はノート一択。

先に書いた通りめんどうくさがりで機能を全部集約したく、もう「コレ買っておけばもういいだろ」的なやつをケチらずに買おうとしてたので 15.4 インチの 16GB, SSD 256GB の MacBook Pro Retina : MGXA2J/A にした。

MGXA2J/A MacBook Pro Retinaディスプレイ 2200/15.4

posted with カエレバ

購入価格 ¥180,000 ぐらいだったので mini の売却資金差し引いてもややキツかったけど、買ってよかった。この買い物は全肯定できる。

ファーストインプレッション

いろんな人がいろんな利点を褒めてるので今更感しかないけれども、
第一印象はこんな感じ。

• Retina ディスプレイ、フォントが良い。目に優しいし、ブラウジングもコーディングも長時間集中してても疲れにくくなった。たしかにこの後に Windows 触ったら文字がギザギザして見えた。
• トラックパッドのおかげでマウス捨てた。iPhone みたいに操作できてストレスがない。
• 見た目がかっこいい。出社するときに家に置いて行きたくない。
• ボディ、トラックパッドの質感が良い。すべすべしてるので指がひっかかったりしない。
• いちいちヌルヌル動くのが良い。トラックパッドでスクロールした時に指を離しても吹っ飛んでいったり、最下まで行ったあとにバウンドするように戻っていったりする。なんでこんな無駄っぽい動きに感動するんだろう、って思ったけど、これ本能っぽい。自然界の慣性を模倣した動きを前にすると優しい気持ちになれる気がする。感性学とかで説明してほしい。
• SSDだと起動がめちゃ早い。Windows、基本的に再起動したくなかった。パッチ適用〜再起動とかいう最悪の定期作業で大体5分ぐらいかかっててその間は休憩するか〜とか言って携帯で twitter 見てた。二度とやりたくない。

MacBook に触ってるうちに「PCに対して自分が今までどれだけ我慢してきたか」に気づいた。これまで意識もしてなかったことが、実は積もり積もってけっこうなストレスになっていたっぽい。書いてて熟年離婚感がある。

高価な買い物して魔法にかかっている感も否めないけれども、PCは毎日触るので毎日満足感に浸れる。なので今年一番の満足してる。
とにかく家でPCに向かうのが以前より遥かに好きになったので良かった。

ただ会社では支給される Windows7 しか使えないのでいろいろ辛い。

選挙での「白票」を「社会を変える力がある」と主張していた団体について、福沢諭吉的な観点から思ったこと

選挙での「白票」を「社会を変える力がある」とミスリードする謎の集団「日本未来ネットワーク」のサイトが突如出現 | BUZZAP！（バザップ！） - http://goo.gl/Fx820u

こういうのに飛びつく人間が周囲にいたので、なんだかなぁ…と思っていた。

思っているだけだったので、諭吉の言葉などを使って表現してみた。

政治に関心の無い人間の一例として、"コンディショナル・グッド-条件付き善-"、つまり絶対的な価値判断でなくて状況によって制約された善悪というものを理解していない。かんたんに言えば相対的な価値判断ができない。

価値判断ではたびたび、ベストな選択ではなくベターな選択を強いられる。また、政治的な判断に代表されるように、「悪さ加減」が価値判断の根拠となることもある。これは状況認識の話だが、悪いものばかり並べてみるのは精神的に苦痛、という精神衛生にも関わってくる。こうした状況に手っ取り早い結論を求めるようなひ弱な精神は耐えられない。だから判断を投げ出す。

投げ出すだけならまだ良いのだが、投げ出す行為にあたかも主体性があるかのように振る舞うタイプの人間もいる。これは独立ではなく単なる機会主義であり、やはり"惑溺"の一種なのである。

この"惑溺"こそ福沢が激しく批判した状況認識・判断の誤りであるからこそ、絶対にブッ飛ばす必要があるのでムカついてたとわかった。

福沢諭吉の哲学―他六篇 (岩波文庫)

posted with カエレバ

丸山 眞男 岩波書店 2001-06-15

『プロとしてのデータモデリング入門』書評

担当案件でDB設計やることになった。
ERDなどの設計書類は読んでいたけれども、ゼロからどうやって設計するのかをきちんと理解しないとな～と思い、評判良かった『プロとしてのデータモデリング入門』を読んだ。

とにかく実践的で良かった。
データモデリング、データベース設計の入門におすすめ。

説明が丁寧

入門と付くだけあって平易な表現で基礎的な説明から入っていき、説明に冗長な印象もあったが入門ということで特に気にはならなかった。何より、なぜその要素が大切なのか？現場ではどのように捉えられているのか？をしっかり解説してくれていので丁寧さと映った。

特に、モデリングにて最重要となるER図の書き方には多くのページを割いていて、これ一冊でER図は書けるようになる。

実用的なテクニックが多い

アプリケーションとの連携や実運用をきちんと見据えた方法論を提示してくれていて、これがまた良い。現場ですぐに使える。

• 業務要件が固まっている場合のトップダウン・アプローチ、画面イメージから入る場合のボトムアップ・アプローチ
• 性能要件を満たすための導出項目の設計や非正規化
• データの更新・参照頻度を意識した索引の設計　　etc.

スーパータイプ／サブタイプ使える

個人的に最も役に立ったのがスーパータイプとサブタイプの分割。
オブジェクト指向的な考え方をデータ設計でもできるのか～と眼から鱗。

これを実際に現場で試してみて、現実で単一／複数のエンティティでも、実態を整理すると分割／統合できることがわかり、そうして整理することでより説明に適したERDが書けるようになった。

また、概念的にスーパー／サブタイプに分かれていても、論理設計（テーブル設計）では必ずしも分割する必要は無い、というのも実践的なポイント。これを取り入れることで、概念的なERと実際のテーブルの関連それぞれを多層的に捉えられるようになった。


当然ながらこれ一冊でDB設計が完璧になることはない。
処理（プロセス）との関連を含めて最適なアーキテクチャを探る方法や、データベース製品の機能を利用して実現できるプラクティスについて多くは触れていない。そこを考える以前の話なので。

データモデリングの基礎の理解が曖昧で、もう少し正確に理解したい…という人にはおすすめ。
DB設計面白い。

プロとしてのデータモデリング入門 (Oracle現場主義)

posted with カエレバ

(株)システムテクノロジー・アイ 林優子 ソフトバンククリエイティブ 2006-11-30

[DB設計] リレーショナルデータベースでは履歴の管理をすべきでない？

リレーショナルデータベースで履歴の管理は難しい。


いまDB設計を担当している案件で、業務用件として履歴管理が現れた。
「データの更新の度に更新前後のデータを保持し、過去のある時点のデータを再現したい」という。

どう実装するか。。

追加のみ行うよう設計する

はじめに考えたのはテーブルAにはレコードの追加のみ行う、という方法。
しかし…下記の理由により断念。

1. テーブルAのオカレンスは頻繁に更新され、レコード数が大変なことになる。オンライン処理の為、厳しい。
2. また、今回はテーブルAだけでなく、テーブルAとリレーションを持つ他の幾つかのテーブルの履歴も持たなければならない。つまり、テーブルAを更新する為に他の複数のテーブルにINSERTを行わなければならなくなってしまう。これをアプリケーション実装者に強いるのはリスク。

本体と履歴の情報を分ける

テーブルAとは別にテーブルA履歴を用意する方法。履歴テーブルにはテーブルAの主キーとリビジョンなどを持たせる。最新のデータを取得するにはテーブルAを見るだけで良いので問題1.は解決。

テーブルAの更新と同時にテーブルA履歴にINSERT。これも問題2.を孕んでいるが、テーブルUPDATE,INSERT,DELETE時に履歴系テーブルにINSERTするトリガーを作成することでやや改善する。データの追加・更新・削除は履歴を意識せず、本体に行えば良いのでアプリ実装負担にはならないはず。


ひとまずこんな感じで設計したが、未だ残る一番の懸念は履歴に対する検索処理。とにかく重そう。
集計表としてマテリアライズド・ビューの作成も検討しているが、検索条件の柔軟な変更に対応できるだろうか？また、対応コストは高くつかないだろうか？
もう少し、考えてみたい。

履歴とは

ちなみに【DOAコラム】-更新と履歴によると、履歴には3種類があるという。（詳細はリンク先参照）

１．単純に行為・出来事の事実を記録する履歴
２．元の行為・出来事が変更されるので、変更前の状態を記録する履歴
３．継続的な発生を前提にして、行為・出来事の事実を記録する履歴

今回の要件では２．に当たる。このうち１．と３．の実態はイベント（行為／出来事）の集積であって、イベントテーブルを作ってそこにレコードを追加していけばよいとのこと。

【参考】

漢(オトコ)のコンピュータ道: データベースアプリケーション開発を炎上させる負のスパイラル
そろそろ履歴データについて真面目に考えてみていいんじゃないの - iakioの日記 - 

[html] name属性を定義していないinputタグのformデータは送信されない

当たり前のことだけどこれの不理解に起因するバグがあって時間とられたのが悔しいのでメモ。
まぁ、テンプレートエンジン使ってると見落としがちなのかもしれないが…。

[JavaScript] wait～リトライを行う処理

クライアントサイドJavaScriptでwait処理に相当するものが必要になったので調べてみた。

そもそもJavaScriptにはwait / sleep に相当する関数が無いみたいだが、
遅延処理を実現する setInterval() / clearInterval() の2つのメソッドにて同様の関数を実装できると判明。

今回は純粋なwait処理だけでなく、非同期に行われる処理との同期をとるためのチェックも行える必要があったのでこんな関数を書いた。

/* 
 * 条件を満たすか、指定回数だけリトライするまで待つ
 * ループ処理としても使える
 * [引数]    test        :終了条件を満たすかどうか判断する関数
 *             callback    :終了条件を満たした後に呼び出す関数
 *             time        :ポーリングタイム（ms）
 *             retry        :リトライ回数
 */
function wait(test,callback,time,retry) {
    // リトライ指定が無い場合はデフォルト回数を設定
    if(retry === undefined) { retry = 3; }
    
    var count = 0;
    
    // wait条件を満たすまで繰り返す処理
    var process = function() {
                        count++;
                        if(test() || (count > max)) {
                            clearInterval(timer);
                            callback();
                        }
                    };
    var timer = setInterval(process(),time);
}

参考にしたサイトでも指摘されていたが、時刻の取得→比較を繰り返すのはブラウザが固まってしまうアンチパターンなのでNG。

普段はJavaばかり書いてるので、JavaScriptでクロージャを意識したコードを書くの楽しい。

【参考】
【JavaScript】処理の実行タイミングを遅らせる方法 | Web制作会社スタイル
遅延実行 | JavaScript プログラミング解説
javascript で wait処理 - 新みのる日記