before or since

たまたま聞いた言葉。

単語だけ見るとわからないけど、

意味を聞くと、

あー、なるほど。

『後にも先にも』

Raspberry Pi の設定 - Windows編

Raspberry Piはとても小さいですが、
単独ですべての動作ができるコンピュータです。
OSはLinuxを使っています。

まずは、この"Linux OS"のセットアップが必要です。
ハードディスクなんてものはなく、記憶領域はSDカードです。

このSDカードにLinux OSを書き込みます。

ここからの作業は「Raspberry Pi 電子工作レシピ」という本を参考に進めていきます。

Linux OSのイメージファイル準備

Linux OSといっても実はいろんな種類のディストリビューションがあります。
カーネルと呼ばれるコアの部分とそれ以外のソフトウェアは組み合わせが自由で、
それらをいろいろ組み合わせて「ディストリビューション」という単位で配られています。

今回は本に載っていた「Raspian-FABLIB」というディストリビューションを使います。
普通のPCで使う「Debian」をRaspberry Pi用にした「Raspian」というのがあるのですが、
それをさらに本の著者が少し変更を加えたものです。

ダウンロードは以下から行いました。
FABLIB - ダウンロードファイル一覧

PCのセットアップ

■1. cygwin

上記で準備した「Raspian-FABLIB」のOSイメージをSDカードに書き込むのですが、
その前にPC側の設定もしておく必要があります。
てことで、Cygwinという、Windows上で動作するLinuxライクなコマンド群のパッケージをインストールします。

これも実は上記茶者のページで使いやすいようにカスタマイズされたものが配られているので、それを使うことにします。

cygwin.zipというファイルを取ってきて解凍し、できたcygwinディレクトリをc:\に配置する。
＃これ、本には何も書いてなかったからちょっと困るかも
＃サポートサイトには書いてありました

■2. Ext2Fsd

以下のURLに行き、"Downloads"ページからたどってバイナリを取ってくる。
http://www.ext2fsd.com/

2014/12/21現在では、Ext2Fsd-0.53.exeが最新。
で、これをダブルクリックしてインストールしておく。

Raspian-FABLIBファイルの書き込み

■1. OSイメージファイルの解凍

まずは本に従って、cygwinを起動してチェックサムでファイルを確認する。
・c:\cygwin\cygwin.batを実行する。
・開いたターミナルで、sha1sumを実行する。
てしてみたけど、sha1sumがどこにもない。。
てことで、
・md5sumを実行、Webページの値と比較。

で問題なかったのでファイルを解凍。
$ unzip raspian-FABLIB-20140928.img.zip

■2. SDカードのデバイス名の確認

次に書き込み先のSDカードのデバイス名を調べる。
まずSDカードが刺さっていない時に以下のコマンドを実行
$ cat /proc/partitions

そして、SDカードを刺した後に同じコマンドを実行。
そうすると増えているデバイスがあるので、それがSDカードのデバイス名です。

こちらの環境では以下のsdbが相当しました。
    8    16   7782400 sdb
    8    17   7778304 sdb1

■3. SDカード上にOSイメージファイルを書き込む

cygwin.batを『管理者として実行』して以下のコマンドを実行
$ dd if=raspian-FABLIB-20140928.img of=/dev/sdb bs=512

ここではまったのですが、cygwinのターミナルをそのまま開くと
権限がないために書き込みができません。

そして。。
かかった時間は５時間半。。。なにがいけなかったのかなぁ。
本には４０分くらいとあったけど。


さてさて、とはいえ、なんとかたどり着いたので、
次はRaspberry Pi でOS起動！と行きましょう！

Raspberry Pi はじめました

さて、今日の本題。

Raspberry Pi、はじめました。

食べ物ではありませんよ(笑)
でも、きっと美味しい。

子供たちにまずはコンピュータというものを、
目に見える、小さなところから感じてほしいと思い、
電子工作的に触ってもらおうと。

その前に、自分である程度触っておこう！ということで、
一つ、買ってみました。

これ、写真じゃ伝わらないんだけど、想像以上に小さいです。
iPhone6 Plusと比べたら、iPhone6 Plusの方が大きかった(笑)

中を空けてみるとシンプルで。
ボード１枚と紙切れ１枚。

まずはOSのセットアップが必要なので、
そのあたりの情報を調べて書いていこうと思います。

参考にしてるのは以下のURLです。
Raspberry Pi (本家)
IT女子のラズベリーパイ入門奮闘記

EPSON PM-D750 のインクカートリッジの交換をしたら、ときどき認識してくれない。。

ついでにこれも書いておこう。

インクがなくなった、とプリンタがいうので交換したんですが、
カートリッジを認識できないエラーが出て１時間以上格闘しました。

急きょお店に行ってカートリッジを買ってきたんですが、
エコカートリッジという値段の安いものを選んだわけです。
レジでお店の人に「一週間しか初期不良は交換できませんがいいですか？」と聞かれました。
頭の中で「？？」となってましたが、倍くらい値段が違うのでそのまま買いました。
まぁ前回も同じもの使ってたし大丈夫だろうと。

さっそく家に帰り、カートリッジを交換したんですが、
カートリッジが認識できません、、というエラーメッセージが。
あーだこーだしていたら、システムエラーが出た、とエラーメッセージが。
このプリンタを使っていて初めてです、このエラー。
電源ボタンと中止ボタンを同時に７秒以上押してるとプリンタが再起動する、とのこと。

で、再起動してみてもまだ認識できません、という。。


最終的にやってみて効いたのは、
全部のカートリッジを外して、またつける、ということ。
エラーが出ていたカートリッジはやってたんだけど、
関係ないと思われるもの全部やってみたら
改善することがわかりました。
＃それでも、タイミングによってはまだエラーが出る

ほんとね、壊れたと思ったんですよ。
買ってこなきゃいけないのか、と思ったんだけど、
最後の最後で復活したのでよかったです。


とりあえず、メモとして残しとこ。

EPSON PM-D750 のプリンタダイアログが以前と違う？！

この時期、プリンタのお世話になる方も多いと思いますが、

僕もその一人。さっそく使いまくっています。

ただ、以前と違うなぁ、と思うことがあったのでメモ。

うちのプリンタは『EPSON PM-D750』というかなり古いモデル。

最初についてきたCDでドライバを入れたときは、

マニュアル通りの画面が出てたんですが、時代を経て

PCが変わりOSが変わり、としているうちに、

いつのまにか選べる用紙の種類が変わってました。。

以前のダイアログ

（写真のプリンタ名は違うけど、同じのよう）

参照元：[FAQ番号:002400-1]四辺フチなし印刷でB5、往復ハガキ、封筒、ユーザー定義サイズなどが使用できない｜よくある質問(FAQ)｜エプソン

でも、いまのうちの状況は↓。

なんでそんな話になってるかというと、

はがき印刷での「フチなし」設定がうまくできなかったから。

以前は何気なく使えていたのにねぇ。

しょうがないのでよくわからないけど、

用紙設定を「PM写真用紙」、サイズを「はがき」にして印刷しました。

ドライバを再インストールしたらいいような気もしたんだけど、

EPSONのFAQとかに行ってみると、

Windows7の場合はOS標準ドライバを使うように書いてあって。

えぇ・・という感じです。

とりあえず印刷はできたので良しとしますが、

用紙設定によって色合いが変わるのでなんとかしたいなぁ・・。

MacOS X (Yosemite) に更新したら、日本語入力ができなくなるときがある。。

最近 MacOS X をYosemite にバージョンアップしました。

毎度思うことですが、良いこともあれば悪いこともある。
今日はその悪いことの方を書きます。

もうすでにいろいろな人があげてますが、「ことえり」が変わったようです。
そう日本語入力機能のあれです。

だけど、新しいOSでは、ときどき日本語入力できなくなってます。

参考URL
httpYosemite(OSX)で日本語入力できないトラブル時の対策


これってね、普段思いっきり使う機能なので、
それがダメになるってかなりのダメージです。。

ということで、さっそくgoogleの日本語入力に変えてしまいました。

google日本が入力

せっかくことえり気に入ってたのになぁ。
こういうバージョンアップは、ほんと気をつけないとね、て思いました。

iPhone6 Plus セカンドインプレッション

iPhone6 Plusを使い始めて早2ヶ月弱。
久々にiPhone5を触ることがあって、改めて違いに気づかされました。

ということで、少し感想を。

iPhone5、とにかく小さくて軽かった（笑
こんなにも？！と思うくらい。

iPhone4から5にしたときに、4を触ったら
こんなに重かった？！という感想だったんだけどね。

逆に言えば、大きさに馴染んできているってことですね。
画面の広さを改めて感じました。
あの狭さには戻れない（笑

でも、やっぱり重いかなぁ。
iPhone6くらいがよかったのかもしれない。
まぁ、大は小を兼ねるってことで。

あと気になるのは、電源ボタンの位置。
片手で画面を消そうとして電源ボタンを押すんですが、
どうしても反対側についてる音量ボタンも一緒に押してしまうんです。
なので、たいがい音量が最小になってます。

あとは、、指紋認証について。
とっても便利で、人前でパスコードいれなくて済むし、
片手ですぐ見れるから便利です。

が、しかし。ちょっと時間が見たいなぁと思って、

ホームボタンを押して、あーなんかいっぱい通知きてんじゃん、

て見てると、ロック画面が解除されて。（汗

結局、なんの通知だっけ？てなることが多々あった。

まぁ、これは人間が慣れていけばいいことなんでしょうけど、

これまでと違って困ったところです。

ということで、しばらく使っていて

思いついたこと、つらつらと書いてみました。

iPhone6 Plus インプレッション

最初は、すごい大きい！

とにかくそんな感想ばかりで。

アプリによってはiPhone5のデザインのままなので、

文字が大きすぎ？！みたいになってました。

特にゲームとかはデザインが固定だから

その傾向が強かったんですが、

例えば、標準のメールアプリは、表示量が増えたのでとても便利。

あと一番画面の広さをありがたく思ったのは『ウェブブラウジング』

見える範囲が広くてちゃんと読めるサイズ。

情報収集が楽しくなるね。

他には、バッテリーがiPhone5から倍増したのはとても嬉しい。

あと薄くなったことかな。

困ることは、やっぱり片手での操作が難しくなったこと。

少しずつ慣れてきてるけど、まだ恐々片手操作ですね。

iPhone6 Plus - 新機能 ホームボタンをダブルタップで、画面上部へのアクセスを楽にする！

iPhone6 Plus の設定周りを覗いていて、新しい機能に気づきました。
そう先日も友達が「ホームボタンをダブルタップすると・・」と教えてくれて、
「これ、なんだろうね？」と言っていたところ。

まずは「ホームボタンをダブルタップ（クリックじゃなくてね）をする」と何が起きるか？

例えば、以下のような状態だったとして、
片手で操作しようとすると、あー、ボタン上の方だなぁと思いますよね。

そこで「ホームボタンをダブルタップ」すると、
下の図の矢印ように画面が下に下がって、上の方のボタンが触りやすくなる機能です。

こういう細かいとこ、攻めてきますよね、Appleさん。

ついでに、設定がどこにあるかというと、

「設定」アプリの「一般」-「アクセシビリティ」-「簡易アクセス」で設定できます。

デフォルトでは「on」になってます。

iPhone6 Plus のアプリ更新がヤバい

で、さっそくだけど、
iPhone6 Plusでトラブルシュートがあったので書いておきます。

元々はiPhone5だったので、OSはiOS7。
iOS8にはせずにiTuneでバックアップしておいて、
iPhone6 Plusを接続してそのまま復元！
そのとき、iOS8に未対応なアプリは戻らず、
対応してるものだけが入ったみたい。

ここまでは、よくできたシステムだなぁと感心していたのですが。。


しばらく使っていて、さて、iTuneと同期、と思って
Macにつないで放置していたら。
なかなか終わらないなぁと見てみたらまったく進んでない。。。

で、さっそくgoogle先生に聞いてみたら、
どうもiOS8に未対応なアプリが悪さしてるとのこと。

ひとまずの対応としては、iTune経由でアプリの更新をせずに、
iPhone6 Plus本体でアプリの更新をするようにしました。

いや、出かける直前だったからけっこう焦りました。。(^^;


てことで、他にもあるかと調べたらけっこうあるのね。
やっぱりファーストモデルは、いろいろ出ますね。

iPhone6 Plus

うわ、めちゃ久々になってしまいました。。

が、これを機会にまた少しずつ書いていきましょう。

で、iPhoneについて。

前回買ってから２年が過ぎて、新しいモデルが出たので変えました。

最近画面の文字が見づらいなぁと思っていたので、

画面の大きな『iPhone6 Plus』にしてみました。

しかし、これがでかい！(^^;

画面の右上が親指で届きません。。

＃ちなみに左利きなので左手で

まぁ、これはなれだと思うので、文字が大きくて見やすくなったことを喜びましょう！

git でソース差分をチェック (git difftool)

うわぁ、、気づいたら１ヶ月以上経ってる。。
週１回を目指していたのに、半年で早くも挫折か。

・・と、めげていてもしょうがない！

まずは、書こう。


ということで、復帰第一弾。
ではありますが、少し軽めなところから。

普段、会社で使っているバージョン管理システムのgit。
かれこれ、４ヶ月ほど使っているので、
ルーチンでやりたいと思っているコマンドは、
なにも考えずに打てるようになってきた。

そこで、最近覚えたコマンドを書いておく。

複数の人で使っているので、ソース差分をチェックすることがあるのだけど、
最初の頃は普通に以下のコマンドを使っていた。

$ git diff HEAD^

でも、どうしても全体像が見えないままソースを読むことになり、
どうもしっくりこなかったのですが。

次のコマンドを覚えて、少し改善されました。

$ git difftool HEAD^

これ、diffを実行するコマンドが選べるのです。
で、標準では vimdiff。
ファイルが複数ある場合でも、vimdiffを終了すると次のファイルに自動で遷移してくれる。

もう差分チェックがめちゃめちゃ楽になりました。

Swift の第一印象とよいと思う点

新しいプログラミング言語かぁと、少し穿ちながら見ていたわけですが、
Swift についていろいろ情報を見ていくうちに触ってみたいな！と思いました。

とりあえず、Appleが提供してくれている以下の電子書籍を少しずつ読んでます。

The Swift Programming Language (iBook store)


ようやく４割弱くらいかな、前半読んでみて思ったことを少し書いてみます。

まず、何よりも感じたこと。それは、、

間違えやすい書き方を減らそうとしている

CやC++をよく使ってプログラムを書くのですが、これって間違えやすいよなぁと思う点がいくつかある。

１．とにかく型安全

コンパイラが必ず型チェックを行う。以下のは、まぁ普通にできないと思うけど。

let a : String = "1.5"
let b : Int = 2

var x = a + b // コンパイルエラー

一方で、あきらかに確定できる型に対しては、積極的に暗黙に型推定を行っている。
慣れればかなり書きやすいのではないかな。

２．行末の";"がいらない

いらんやろ、と思った人が何人いるか、という行末の";"。改行コードでちゃんと切り分けられる。
もちろん一行に複数行書く場合はちゃんと";"を入れて書ける。

let a = 1.5  // ";"がいらない
let b = 1; let c = 2

３．大きな数字の桁が分かりやすいように"_"で桁割ができる

これも小さなところだけど、大きな特徴。
定数なんか見直したりしないから、打ち間違えていたらなかなか気づかない。

let MILLION = 1_000_000

４．複数行コメントがネストできる

複数行コメントアウトを、さらにそれを包含して複数行コメントアウトできるようになった。

これも以前思ったんだよね、なんでできないの？！て。

こういうところ、うれしい。

/*
    let a = 10
    /*  let b = 20 */
    let c = 30
*/

５．switchが拡張

caseの条件が一致したところだけ実行（最終行に明示的なbreakがいらない！）。
C/C++の場合はcase文が終わっても実行が次のcase文に突入していってしまう。

var x = 3
switch x {
    case 0:
        println('zero.')
    case 1:
        println('one.')
    case 2:
        println('two.')
    default:
        println('many!')
}

また、caseに複数条件書けるようになった。関数化しておけばよいが、短いコードの場合面倒なので便利。

var x = 3
switch x {
    case 0, 1, 2:
        println('less than 3.')
    case 3:
        println('equal to 3.')
    case 4, 5, 6:
        println('more than 3.')
    default:
        println('many!')
}

caseの条件を数式で書けるようにwhere句が追加された。

var x = 2
switch x {
    case let a where a % 2 == 0:
        println('even.')
    case let a where a % 2 == 1:
        println('odd.')
}

てところで、長くなってきたので、ひとまず、続く！

新入りSwift、勉強中

開発環境を手に入れるには開発者登録しなくちゃいけないのだけど、

まずは手に入る情報から勉強。

The Swift Programming Language - iTunes, Apple inc.

Swift Programming Language - Apple Developer

The Swift Parallel Scripting Language

かなり変わった印象なのでポイントを押さえないとね。

iOS8と新入りSwift

昨日、、というよりは今朝かな、アップルのいつもの催しがありました。

WWDC 2014。

とはいえ、一度もリアルタイムで見たことないのですが。
新しもの好きの血が騒ぎました。

アップル、新プログラミング言語Swiftを発表。レガシーを廃して高速化したiOS/OS X開発用

そう、iOS8が出るのは、まぁさておき。
新しいプログラミング言語！

Swift！

swift: definition of swift in Oxford dictionary

すばやく、みたいな意味かな。
会社の同僚曰く、pythonみたいなスクリプト系の言語らしいよ？
とのこと。

まぁとにかくです、いまがチャンスじゃないか？と思っている訳です。
新しいことには先にたどり着いた人が有利なのです。

さて、どうしたものか？

makefile、それは避けて通れない道

気づけば、また日にちがあいてしまった。。
技術系ブログなのだから、もっと頻度を上げたいんだけどなぁ。

ということは、さておき。


オープン系、とくにC/C++を扱っていると必ずmakefileと対峙するときがある。

今回はそんなお話。

久々にmakefileをいじって、効率よくコンパイルできるようにしようとしたのだけれど。

makefile内で設定した変数がいつ値がセットされるのか？をよくよく考える必要があるよ、ということです。

背景ですが、複数の異なるプロセッサに対して、同じソースでそれぞれで動作するバイナリを作成したい、そんなときにハマりました。

以下、はまったときのmakefile

projA: PRJ_SUFFIX=_A
projA: proj

projB: PRJ_SUFFIX=_B
projB: proj

OBJDIR=obj$(PRJ_SUFFIX)
BINDIR=bin$(PRJ_SUFFIX)
SRCS=main.c tool.c
OBJS=$(patsubst %.c,$(OBJDIR)/%.o,$(SRCS))
CFLAGS=-D__DEF$(PRJ_SUFFIX)__

proj: $(BINDIR)/proj

$(BINDIR)/proj: $(OBJS)
    @if [ ! -e $(BINDIR) ]; then mkdir -p $(BINDIR);fi
    gcc -o $@ $(OBJS)

$(OBJS): $(OBJDIR)/%.o: %.c
    @if [ ! -e $(OBJDIR) ]; then mkdir -p $(OBJDIR);fi
    gcc -o $@ $(CFLAGS) -c $<

projAのときはprojA用のdefineを定義し、projBのときはprojB用のdefineを定義することで、プロセッサ個別のソースをコンパイルする、という流れです。

何が問題か？というと、ターゲットごとに設定した変数の値がmakefile内ですべてに適用される訳ではない、ということ。

具体的にみていくと、まずターゲット特有の変数を参照した他の変数は、正しく値が変わります。

上記の例でいけば、PRJ_SUFFIXはprojAのときは正しく"_A"が設定され、それを参照したOBJDIRも"obj_A"となります。

しかし、問題なのはターゲットにある変数で、例えば以下の場合。

$(OBJS): $(OBJDIR)/%.o: %.c
    @if [ ! -e $(OBJDIR) ]; then mkdir -p $(OBJDIR);fi
    gcc -o $@ $(CFLAGS) -c $<

このときの「ターゲット」としてはprojA特有の変数によって$(OBJDIR)/%.oは"obj_A/%.o"となっているのでいいのですが、自動変数である$@が正しく設定されないのです。。projA特有の変数が空の状態で設定されるので、この場合$@が"obj/%.o"という値を返してきます。

これ、ほんと悩みましたよ。。echoで出してみてやっと理解。

おそらく$@だけは最初の処理で確定してしまうのでしょうね。

ちなみに、PRJ_SUFFIXを外部から環境変数として渡すと期待通りの動きをするので、余計悩みました。

ということで、正しく動くmakefileは以下です。

projA: PRJ_SUFFIX=_A
projA: proj

projB: PRJ_SUFFIX=_B
projB: proj

OBJDIR=obj$(PRJ_SUFFIX)
BINDIR=bin$(PRJ_SUFFIX)
SRCS=main.c tool.c
OBJS=$(patsubst %.c,$(OBJDIR)/%.o,$(SRCS))
CFLAGS=-D__DEF$(PRJ_SUFFIX)__

proj: $(BINDIR)/proj

$(BINDIR)/proj: $(OBJS)
    @if [ ! -e $(BINDIR) ]; then mkdir -p $(BINDIR);fi
    gcc -o $(BINDIR)/$(@F) $(OBJS)

$(OBJS): $(OBJDIR)/%.o: %.c
    @if [ ! -e $(OBJDIR) ]; then mkdir -p $(OBJDIR);fi
    gcc -o $(OBJDIR)/$(@F) $(CFLAGS) -c $<

$(@F)は、ディレクトリを除いたファイル名部分を取り出す書式です。

以下、参考URL。助かりましたぁ。

GNU make

自動変数

ターゲット特有の変数値

トリビアなmakefile入門

git で作業を取り消したい！

gitでは作業がいろいろな方法で取り消せる。

以前ざっと調べたときにはそういうイメージを持ったのですが、

今回間違えてcommitしてしまって、

さらにpushまでしてしまい、

どうしたものか？と調べたことのまとめ。

結果的には、リモートまで行ってしまったものは『なかったことにできない』という理解。

reset について

基本的には、ローカルでの変更をなしにしよう、というときに使う。
３つの状態を整理しておく。
状態としては、ワーキングツリー、インデックス、HEADがある。
ワーキングツリーは、いま操作しているファイル、目の前にあるファイルの状態のこと。
インデックスは、commitするためにaddされているファイルのこと。
HEADは、ローカルリポジトリの最新ファイルのこと。

git resetは、上述した３つをどうするか？によってオプションが変わる。

$ git reset --soft HEAD^

ワーキングツリー、インデックスは変えずに、HEADの位置だけHEAD^に移動する。

$ git reset --hard HEAD^

ワーキングツリー、インデックス、HEADの位置すべてをHEAD^に移動する。

$ git reset --mixed HEAD^

ワーキングツリーを変えずに、インデックス、HEADの位置をHEAD^に移動する。

ややこしい。

rebase について

まず、rebaseの基本的な使い方を整理する。

rebaseは別ブランチの変更(commit)をいまいるブランチに取り込む方法の一つで、
mergeみたいにいまいるところの「後ろ」に加えるのではなく、
「前」に加える操作。もちろん、一番最初にというわけではなく、
別ブランチと共通の祖先、つまり分岐した部分にうまく追加する。

これをいまいるブランチの過去に対して実行すると、commitを選択して再commitできるようになる。つまり、そのとき、あるcommitを消してしまえばなかったことにできる、ということ。

$ git rebase HEAD~3

ただ、気をつけなくちゃいけないのは、すでに"push"してしまっていると、これ、リモートリポジトリに反映できないです。
ローカルではうまくいくので、しめしめ、と思っているとハマるので注意。

revert について

こちらも実行してしまったcommitをなかったことにするが、ログにちゃんと残る形で実行する。
そうすると、じつはうれしいことがあって、リモートリポジトリもちゃんと変更できる。

$ git revert HEAD

ただし、これも注意点があって。
このコマンドは一つのcommitを打ち消す、というのが機能。
なので、複数ある場合は一度に消されない。

bloggerの引用（blockquote）をかっこよくする！

引用として書いてるのに、なにか味気ない。。
ということで、以下をcssに追加してかっこよくしました。

blockquote {
    background-color : aliceblue;
    border-style : dotted;
    border-color : lightskyblue;
    border-width : 0.1em;
    padding : 1em 1em 1em 3em;
    position : relative;
}
blockquote:before {
    content: "\201C";
    font-family: 'Times New Roman' ,"ＭＳ Ｐゴシック" ,sans-serif;
    font-size : 500%;
    line-height : 1em;
    color : lightskyblue;
    position : absolute;
    left : 0;
    top : 0;
}

ローマは一日して成らず

ちなみに、参考URLは以下です。

【保存版】引用 (blockquote) CSSデザインおすすめコピペサイトまとめ

blockquoteタグをCSSだけで格好良いデザインにする【画像不要】

Awesome Blockquote Styling with CSS

content:に指定した"\201C"は秀逸。しばらく文字化けと格闘したので。

gitのmergeとrebaseを考える - その２

昨日も少し書いたけど、いまのところrebaseの使い方は以下のようにしようと思っています。

• 個人的なブランチをきったときに、メインブランチからの取り込みを簡易に済ませたい
• メインブランチへのマージのときには使わない

ほんとのところ、どういった使い方を想定してるんでしょう？
参考に以下のページを読んでみました。
Git - リベース

リベース後と元のブランチは確かに同じだと思うのですが、個人的に作業したコミットの履歴を正確には追えなくなると思うんですよね。
まぁ、追う必要がないと言ってしまえばそうなのかもしれないけど。

あと、リベースしてからのマージの利点は「メインブランチへのマージのとき、fast-forwardのみでできる」ということですよね。

うーん、思想の問題で、どっちでもいいような気がしていた。難しいなぁ。

あ、ひとつ、リベースしないでメインブランチにマージすることの利点を思いつきました。
個人的なブランチの分岐点が簡単にわかりますね。そうするとどういった背景で開発してたのかがわかりやすい。

最後までさっきのページを読んでわかりました。
そう、ちゃんと注意書きされている。。(^^;

リモートリポジトリに上げてしまったコミットを変更するようなリベースはしないこと！

てことで、個人的なブランチに取り込む以外は使わない。
うん、やっぱり最初に書いた方針で行こう。

git のmergeとrebaseを考える

いま会社では二人だけの小さなプロジェクトでgitを使っている。

で、僕が管理者なので、もう一人からpull request的なお知らせが来て、
変更したコードを確認して（いわゆるコードレビュー）、
で、その変更を取り込む、という流れな訳だけど。

gitを使い始めた当初はrebaseを使って取り込むようにしていた。
なぜかというと、mergeコマンドの動作を勘違いしていたから、です。

rebaseしてからmergeする

簡単にいうと、修正していたブランチに本筋のブランチ（ここではmaster）の修正点をまず取り込んでおいてから、本筋のブランチにマージする、というやり方。

こんな状態だったとする

例えば、まず以下のブランチがあったとする。

$ git branch
  branch_fix_A
* master

それぞれのログは以下とする。

$ git checkout master
$ git log --graph --oneline --decorate
* 8d03efb (HEAD master) add B.
* 2dcd836 (tag: v_1.0.0) initial commit.

$ git checkout branch_fix_A
$ git log --graph --oneline --decorate
* ac292d9 (HEAD, branch_fix_A) fix A1.
* 5a7c805 fix A.
* 2dcd836 (tag: v_1.0.0) initial commit.

つまり、branch_fix_Aはmasterのタグv_1.0.0からブランチを作成して、

二つのコミットをした状態。

masterの方は、その後に一つのコミットをした状態。

branch_fix_Aをmasterに取り込もうとしている、という状況。

ここでまず、branch_fix_Aでmasterをrebaseする

$ git rebase -i master

そうすると、branch_fix_Aで行ったコミットを取り込むのか、すっ飛ばすのか、などなどを選べる。

pick 5a7c805 fix A.
pick ac292d9 fix A1.
# Rebase 8d03efb..ac292d9 onto 8d03efb
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

今回はこのまま取り込む。

・・・おっと、同じファイルを編集してたので、conflictしてるよ。

error: could not apply 5a7c805... fix A.
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Could not apply 5a7c80521adfa971cdda95b942cbf962f83e7419... fix A.

てことで、conflictを解消してrebaseを継続する。

$ git add readme.txt
$ git rebase --continue

現状のログを見ると以下となる。

$ git log --graph --oneline --decorate
* 67b268c (HEAD, branch_fix_A) fix A1.
* ef0bb01 fix A.
* 8d03efb (master) add B.
* 2dcd836 (tag: v_1.0.0) initial commit.

で、masterに戻ってmerge

$ git checkout master
$ git merge --no-ff branch_fix_A
Merge made by the 'recursive' strategy.
readme.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

でOK。

$ git log --graph --oneline --decorate
*   f639397 (HEAD, master) Merge branch 'branch_fix_A'
|\ 
| * 67b268c (branch_fix_A) fix A1.
| * ef0bb01 fix A.
|/
* 8d03efb add B.
* 2dcd836 (tag: v_1.0.0) initial commit.

こんな感じで、取り込んだコミットだけ見れて、masterブランチから見て、どのタイミングで取り込んだのかがわかっていいかなぁと思ってたのですが。

実はこれ、branch_fix_Aの二つのコミットのIDが変わっちゃってます。

つまり、修正したときの元の完全な状態に戻せない、ということですね。。

それはまずいかなぁと思って、昨日から（^^; 普通にマージするようにしました。

単純にmergeする

上述と同じ状況でmasterでmergeするだけ

$ git checkout master
$ git merge --no-ff branch_fix_A
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

て、conflictするので解消してcommitする。

$ git commit -m "fix confilict on merge with branch_fix_A."
$ git log --graph --oneline --decorate
*   3aa835d (HEAD, master) fix confilict on merge with branch_fix_A.
|\
| * ac292d9 (branch_fix_A) fix A1.
| * 5a7c805 fix A.
* | 8d03efb add B.
|/
* 2dcd836 (tag: v_1.0.0) initial commit.

これがすっきりしててよいのでしょうね。

で、git mergeのなにを勘違いしていたのかというと、

マージしたい二つのソースがあったときに、手動で差分をとってソースを取り込む、という動作を想像してしまったんです。

えっと、ややこしいですね。。

ブランチが分岐した後のmasterに入ったコミットが、マージのときにややこしくなるんじゃないか？と思ってたんですよね。

人間が手動でやる場合には上述のことを考慮しなくちゃいけないけど、

gitはブランチの分岐点を知ってるので、差分だけをマージしてくれるのです！

もちろんコンフリクトするソースは手動で直すのですが。

てことで、ソース取り込みも手間が少なくなりました。

git で空ディレクトリの登録するには

なかなか手が動いてないけど、仕事ではgitを快調に使用中。

いろいろな場面に遭遇して、あれ？これどうするんだろう？ということばかり。
まだわからないこともあるけど、簡単なところからメモ。

さて、今回は、空のディレクトリを登録する方法。

最初、気づいてなかった。。空のディレクトリを登録してくれないって。
cloneし直してmake通らないじゃん、てなったので気づいた。

空のディレクトリを登録しないのは、gitの仕様らしい。
なので、サイズのないファイルを配置して登録、というのが慣習のようだ。

空のディレクトリの登録

例えば、ファイルが入っていない空のdir_aディレクトリを登録したい場合、以下のように".gitkeep"ファイルを作成しておく。

$ mkdir dir_a
$ touch dir_a/.gitkeep

で、それをコミットすれば登録される。

$ git add dir_a/.gitkeep
$ git commit

まぁ、これはそういうものだと思うしかないね。
バージョン管理システムごとに色合いがあっておもしろい。

CVSの場合は、登録したディレクトリは消せなくなってしまう。
subversionの場合は、ちゃんと管理してくれる。

そう考えると、なにか設計上の思想があるのかな？

earth-shattering

こういう熟語的な言葉って、
イメージだけでいくと訳が分からないことがある。

earth-shattering

とても重要な、みたいな意味らしい。

earth-shattering

あと、上に貼っておいたリンク。
辞書サイトがいっぱいあってどこにしようかと思ったんだけど、
Google先生に聞いて最初に出てきたのでとりあえず。

Google AdSense - 開通です！

あっさりと。
待っていた時間が長かっただけに。

というか、自分が悪いのだけど、ね。
ちゃんと説明を読め、ということですね。

審査 → 配置、ではなく、配置 → 審査。

git のリモートブランチ

git ではやりたいことが複数の方法でできることが多い。

今日は「リモートブランチ」の話。

一人で開発しているうちはあまり気にならないが、
複数で作業を始めるとお互いの作業分を共有したくなる。

まぁそれが共同開発なわけですが。

リモートリポジトリへブランチを上げる

git push <remote name> <branch-name>

例えば、以下が代表的。

$ git push origin master

リモートブランチをローカルで参照できるようにする

で、他の人がbranch-fix-bug-1というブランチをリモートに上げていて、
ローカルで参照したいといった場合。

git branch <local branch-name> <remote branch-name>

例えば、以下。

$ git branch branch-fix-bug-1 origin/branch-fix-bug-1

実はこれ、ローカルでトラックするよーと宣言するだけでもよかったりする。

git checkout --track <remote branch-name>

例えば、以下。

$ git checkout --track origin/branch-fix-bug-2

方法が複数あるってのはどうしても混乱する。
いろいろ理解した後だと、あーそれはこことここがつながってるのね、
と思うんだけど。

でも、わかればわかるほど、かめばかむほど味があるのが git なんだと思う。

Road to windows 8.1! - 回復ドライブの作成

購入したノートパソコンには、実はリカバリ用のディスクがついてきていない。
Windows8になってrecovery partitionという隠れパーティションが
OEMパソコンにはあったりするようになったみたい。

で、普段はOSが調子悪いくらいの場合であれば、
そのパーティションから起動して修復することも可能になっているんだけど、
もしハードディスクごと壊れたらどうするの？
復活できないじゃん？！

て、ことで調べてみました。
＃前回、ブログ書いたときに調べてたことですが

参考URL:  システムの修復用にWindows 8の回復ドライブを作成する

要は、Windows8のOS機能を使って回復ドライブを作成することで
上述したrecovery partitionをUSBメモリにバックアップできる、ということです。

実際にやってみたところ、9GBくらいのサイズになりました。
なので、16GBのUSBメモリに収まりました。

これで、ひとまず安心ですね。

Google AdSense - 続き（２）

もう一度、Google AdSenseの手続きページを読んでみた。

サイトで Google の広告掲載が開始されるまでの時間

さてはて。

もしや「審査中」なのは、まだ広告リンクを配置してないためでは。。
てっきり審査が通ってから配置するのだと思っていたのですが。
ということで、さっそく配置しておきました。

やれやれ。

iTunes Musicのフォルダを変更したい

最近、パソコンの調子がほんと悪い。
で、いろいろな設定をし直すことがあるんだけど、
データはそのままさっと移行したかったりする。

 で、iTunes Music。 

これは昔から移行するのが簡単なデータなんだけど、
ユーザのフォルダ以外に配置して
OSの再インストールの影響を受けないようにしたくなったので調べてメモ。

 参考URL: “iTunes Music”フォルダの移動について

単純に、optionキーを押しながらiTunesを起動すると、
使うiTunes Musicフォルダを選択できるので、
移動先のフォルダを指定。

That's it!

git 運用、続けてます

プライベートでの開発はなかなか進んでいませんが、会社での開発ではgitを使っています。

work directoryとstage(cache)とremote repositoryの感覚がなんとなくついてきました。

でも、あー、これどうするんだろ？ということが多いです。

やっぱり困るのが、あ、間違えた、やり直したい！というとき。

例えば、checkoutでちゃんとブランチ作らずにメインブランチで作業を始めてしまったとき。

あ、ブランチ切り忘れてる・・・。

今回やってみた方法は以下。

$ git stash save

$ git checkout -b <branch_work> master

$ git stash pop

$ git commit

つまり、一時退避して、ブランチ切り替えて、退避したところから戻す、ということです。

Google AdSense - 続き

あれ、そういえば、4/6にGoogle AdSenseの申し込みしたけど、まだ「審査中」だよ。。

Road to windows 8.1! - 検索

そうそう、今回の「はまり」で学んだもう一つのこと。

とにかく「検索」しろ、という解決策が多かった。

何を言っているのかというと、画面右下へマウスを持っていくと出てくるサイドバー。
あの一番上に出てくる「検索」。
これでいろいろなやり方が出てくる、と。

例えば、OS再インストール用にリカバリディスク作っておきたい。。

「検索」で「回復」と入れると「回復ドライブの作成」というのが出てくる。

それに従っていくと、USBメモリにリカバリ用のデータを入れてくれる。

デバイスドライバを更新したい

「検索」で「デバイスドライバ」と入れると「デバイスドライバの更新」というのが出てくる。

で、クリックすればデバイスマネージャーが立ち上がる。

いや、困った・・

「検索」で「トラブルシューティング」と入れると、そのもの「トラブルシューティング」が出てきて、コントロールパネルにあるトラブルシューティングが立ち上がる。

といったあんばいだ。

ちなみに、ショートカットは「ウインドウズキー」＋「Shift」＋「f」です。

Road to windows 8.1! - 今度はドライバですか。。

新しいノートパソコンを買った（人が使うのだが）。

で、入ってたのはWindows 8。
さて、8.1にあげておこう、と気軽に更新を始めたのだが、
予想通り、いや、そうあって欲しくないのだけど、予想通りにはまったので記録しておく。

Window8を更新 (Windows Update)したら、ものすごく時間がかかった。。

これはしょうがないのだけど、買ってきたばかりのパソコンは、出荷時のOS状態なので最新状態ではない。
そのため、大量の更新をかける必要があるのでやったのだけど、ものすごく時間がかかる。

というか、マシンパワーが低いからしょうがないのだけど。
画面に出ている「ダウンロード」中の表示なのに、プログレスバーが進まない。。

不安になって途中で止めたら、ちゃんと進んでいた、というおち。

で、OSを最新状態にしてストアから8.1へ更新しようとしたら、またダウンロード待ち。
まぁ気長に待とう、ということで放っておいたら終わっていた。
さっそく更新作業に入ったら、メールアカウントの確認で失敗した。

なんで？と思いつつも、後回しにする選択でOSを起動させてみたら・・・。

ネットワークにつながらなくなった。。

あれ？ネットワークがつながらない？！ということで、調べ始めて。

まずはドライバを再インストール

付属アプリからドライバを再インストールしてみた。
見た目はドライバが入ってOS的にちゃんと動いている、ってことになってる。

でも、つながらない。はて。

次はドライバを削除して再起動

変わりなし。

パブリックネットワークがおかしい？

以下の方法でプライベートネットワークに変えてみたけど、つながらないまま。

参考URL:
【Windows8.1】パブリックネットワークからプライベートネットワークへの切り替えは簡単にできます【一方通行】

ドライバの再読み込み

どこのページを参考にしたのか見つけられなくなってしまったけど、OSが認識してるドライバをリストしてそこからドライバを再読み込みしてみた。

具体的には、
デバイスマネジャからネットワークアダプタを選んで右クリック、
ドライバソフトウェアの更新を選択。
「コンピュータを参照してドライバソフトウェアを検索します」をクリック、
「コンピュータ上のデバイスドライバーの一覧から選択します」をクリックして。

でてきたリストから順番に試してみたが、すべてダメ。

8.1でOS更新

と、はたと気づいた。

OSの更新(Windows Update)をしたら、実はドライバも更新されるかも？！ということで、更新したら案の定解決しました。

て、なぜ、OS更新できたか？

実は、wifi設定は問題なくできて、すでにネットにつなげられていたから。
あれれ、「にわとりとたまご」みたいな話になってる。

まぁ、そもそも最初の「時間がかかった」というのでOS更新、やりたくなかったんでしょうね。。

Road to windows 8.1! ライセンス認証のばかやろー

まじ、あかんでしょ、これ。
ものすごくめんどうです。

ただ再インストールしてるだけなのに。
お金払って買ったソフトウェアなのに。

電話して４０桁近い数字うたせたり、
その返事の４０桁近い数字をパソコンに入力させたり、、

いや、あかんと思います。

ものすごく使いたくなくなりました。
例え便利だったとしても、使いたくなくなりました。

Road to windows 8.1 !

さて。windowsの話。

windowsはどうしても仕事で使うことが多いし、触れる環境を用意しておかなくちゃ、ということでMacにも入れていて。で、最近のMac不調により再インストールを昨日からやってるんだけど、ものすごく時間がかかる。。

なぜかというと、windows8のアップグレード版ライセンスだから。まずアップグレードされる元のwindowsをインストールして、windows8にアップグレードして、さらにwindows8.1に更新（いまここ）・・・みたいな流れです。

ネットを探してみるといろいろな簡易方法があったので、いくつか試してはいるんだけどうまくいかなかったんですよねぇ。。

でも、下のURLの方法はまだ試していないので、次回（あってほしくないけど）チャレンジしようと思います。ということでメモ。

参考URL：
Windows8のアップグレード版を簡単に新規インストールする方法

Google AdSense

ブログを始めて早数ヶ月。忙しいときもあるのでなかなかコンテンツが増えないけど、いろいろなことにチャレンジ！ということで、今日はGoogle AdSenseに参加してみた。

最初、Google AdSense本家のページから登録しようと進めていたら、途中でBloggerから登録してください、とのこと。。。それなら最初から言ってくださいよ。と思いながら、以下の登録作業をしました。

登録開始

下の画面のように、Bloggerの管理画面の左下（ピンク色の枠）にある「収益」を選ぶ。そうすると、一番下のところ（青色の枠）に「AdSenseに登録」と出てくるので選択する。

 そうすると、下の画面の通り、Googleアカウントを選択する。

 次に、ブログの情報が出るので確認した後「続行」を 押す。

個人の情報を入力するように出るので入力する。

最後に「お申し込みを送信」ボタンを押す。

AdSenseウィジェットが登録されたメッセージが出る。

登録してみたら・・

 あとはまだ「審査中」なので 待つのみ。

こういう感じだと簡単なんだけどねぇ。

gitのブランチとタグ

少しずつ、少しずつだけど、gitの世界にはまり中。

最近覚えた呪文。

$ git log --graph --oneline --color

ステキ。

さて、本題。ブランチとタグについて。

これまでCVSやsubversionで触ってきて、あまりブランチを作って消してを繰り返さないスタイルできたので、gitの世界で初めてそのサイクルを経験。で、タグで要所をしめておく、ということらしい。

読んだところによると、ブランチを消してもタグをつけておくとその状態が復活できる、とな。
参考：http://dev.classmethod.jp/etc/git-branchtag/

ブランチ関連

リモートリポジトリのブランチを表示

$ git branch -r

ローカル・リモートリポジトリを合わせてブランチを表示

$ git branch -a

タグ関連

タグの一覧

$ git tag

ローカルでつけたタグをリモートリポジトリに転送

$ git push origin --tags

loop over

この間投稿したように、いま英語で技術書を読んでいるんだけど、ときどき「へぇ、こうやって表現するんだ」と思うことがある。せっかくなのでメモっておくことにする。

loop over ~

意味は、"〜ごとに繰り返す"といった感じ。

例）

This code loops over every string.
（このコードは、それぞれのstringに対して繰り返して実行する）

この場合は、例えばstring型の配列があって、その配列の要素であるstringすべてをfor分で繰り返して実行する、というときに使える。

追記： loop throuth ~もいけるってさ！

gitに慣れよう！

今日はいい天気で、小春日和だけれども。ブログ更新をがんばろう。^^;

gitの話。

使わないと慣れない！と思い、会社で独自に使用開始。それで思ったことをつらつらと。

なんとなく使っていると、ついつい手順をそのまま実行するだけになってしまう。そうすると、いざ自分で使おうとしたときに、あれ？これ何をすればいいの？！となる。そんなことを記録しておきます。

リモートリポジトリにつく名前を理解すること

"origin"ってなんだ？てまず思った。たしかに以下のコマンドで設定してる。^^;

$ git remote add origin ssh://xxxx@yyy.com/zzz.git

なんとはなしに実行していたこのコマンド。これでリモートのリポジトリが"origin"が設定される、と。ついつい見過ごしてしまうよね。実はリモートは複数指定できて、originを別名にしてやればいい。仕組みがわからないと理解できないところ。

で、これがあって、pushするときの動きがわかってきた。

$ git push origin master

とすると、"リモート"のoriginにmasterブランチをpushする。明示的に、これがリモート、ローカルというのが見えないので最初は混乱するかもしれないね。

cloneできる単位

いままでcvsとかsubversionを使ってきたので最初どうするの？！と思ったこと。実はリポジトリの中の一部を取り出すことができない。cloneするのはリポジトリ単位。なので、それを考慮してリポジトリを切り分ける必要がある。

例えば、大きなプロジェクトを用意して、複数のサブプロジェクトを入れておく、としても、個別に取り出せないので、いっそのこと別々のリポジトリにした方がよい、という話。なかなかここにたどり着けなかった。。

Programming Collective Intelligence

パソコンが壊れたり忙しかったりで、少し期間があいてしまったけどブログ再開。
といってもひとまずは小さなことから。

いま英語の勉強も兼ねつつ「Programming Collective Intelligence」を読んでる。邦訳では「集合知プログラミング」。もともと人工知能や学習には興味があったので楽しい。Pythonのサンプルプログラムがついてて、理解もしやすい内容。まだ１割くらいしか読んでないけど、来月前半に読み切れるといいかな。

Xcodeのstoryboardを使って、UIButtonを押したときのイベントをソースとひもづける

ようやく、ようやくプログラミングの話。

とはいえ前回も実は試しにiOSプログラミングはしてたのだけど、望み通りのスクリーンショットがとれずブログに書けなかったのでした。。

さて、まずXcodeを使ってiOSプログラミングの基本の「き」。storyboardを使った話から始めよう。iOSはユーザの操作を受けて動作することがメインに行われる。つまり、ボタンを押したり文字を入力したり。そこをiOSが標準で扱ってくれる。ただし、画面に配置したボタンと実行する内容は自分で接続する必要がある。

今日のお題：「storyboardに配置したボタンとViewControllerを接続する」

いろいろ触っていて、気づいたところで２通りあった。

今回はテキストの中から文字列を探してハイライトする、というテストアプリを実例とする。

ボタンからViewControllerへ接続

下の画面のようにstoryboardで必要な部品を配置しておく。ここでは一番下の"Clear"ボタンをViewControllerのソースとひもづける。

まずはstoryboardを画面に表示しておいて、右上のアイコンにある下の丸で囲んだボタンを押す。

そうすると、下のように画面が左右に分割されるので、右側に接続したいViewControllerのヘッダファイルを表示させる。今回は"Clear"ボタンを接続したいので、"Clear"ボタンを選択・右クリックすると以下のように黒いメニューが出るから、「Sent Events」ー「Touch Up Inside」の右端の"+"を左クリックしてドラッグ、ヘッダファイルのInterface宣言部へ持っていく。

そうすると下のように接続情報の入力が求められるので、関数名を入れて「Connect」ボタンを押せば出来上がり。めっちゃ簡単。でもすぐ忘れる。(^^;

接続ができると、下のように関数が宣言され、その左横に灰色の丸印がつく。

ViewControllerからボタンへ接続

一方、ViewControllerにあらかじめ関数を宣言しておいてボタンに接続する方法もある。まだ接続されていない関数の左端は下の画面のように中抜きの灰色の丸印になっている。

これを左クリックしてドラッグ、接続したいボタンまで持っていく。これだけで終わり。

そうすると、以下のように「Touch Up Inside」イベントに接続される。

これらは基本中の基本だから、なにも考えずにさらっとできるように早くならないとね。

gitで管理しなくてもよい「Xcodeの管理ファイル」を対象外にするには

Xcodeが管理するファイルには、バージョン管理しなくてもよいものがあるそうで。
参考URL: Xcodeプロジェクト用の.gitignoreを作成する

.gitignoreファイルに以下を設定しておいた。

*.xcodeproj/*
!*.xcodeproj/project.pbxproj
!*.xcworkspace/contents.xcworkspacedata
.DS_Store

Xcodeからgithubを使う

やっとここまで来ましたね。さあ、コードを書こう！

Xcodeでgithubのリポジトリを登録

Xcodeからgithubを使えるようにするために、まずはリポジトリを登録する。

「Xcode」メニューの「Preferences...」を開く

開いたウインドウの「Accounts」を選択して左下の「＋」を押す。メニューから「Add Repository...」を選択する

そして、出てきたテキストボックスに追加したいリポジトリのアドレスを入力して「Next」ボタンを押す

そうすると、以下のウインドウのようにリポジトリが左側に追加されるので、あとは「Uer Name」と「Password」を設定しておく

ちなみに、さっきのリポジトリのアドレスは、以下のように自分のgithubリポジトリページ右下から取得する

Xcodeで新規プロジェクトを作成

「FIle」メニューの「New」ー「Project...」を開く

これからiOSアプリを作って行くので、まずはテストがてら簡単なボタン操作のアプリを作ってみよう。ということで、「Single View Application」を選択する

ここはいつも悩むけど、とりあえず項目を埋めて「Next」

プロジェクトの保存先を決めたらはじまり！

「Source Control」メニューを見ると、以下のようにうまく接続できてることがわかる

gitのブランチ管理

せっかく始めるので、、といつもの気合い入れ過ぎ？！な状態ですが、まずはブランチ管理について。
これまでのCVS, subversion もそれほど大人数で触っている訳ではないので、なんとなくなタグ管理しかしてなかった。

てことで、まずは勉強。世間では「git-flow」と「GitHub Flow」が流行っているようだ。とりあえず以下のリンクをざっと見てみる。

git-flow

参考URL

• A successful Git branching model
• いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 (1/2)

「A successful Git branching model」より引用

以下のブランチを用いる。

• develop
• feature
• release
• master
• hotfix

git-flowをインストールするとgitにプラグインとして使えるようになり、git-flowを使うことでVincent Driessen氏が提唱するgit-flowモデルに従ったマージやコミットを裏でやってくれる。

GitHub Flow

参考URL

• GitHub Flow - Scott Chacon（原文）
• プルリクエスト／レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2)

以下のブランチを用いる。

• master
• 作業を表す名称のブランチ

git-flowの場合は少し詳細に分かれ過ぎていて、個人で始めるには面倒な気がする。そんなに頻繁に上げないし、なによりも変更が衝突する相手がいない。なので、まずは「GitHub Flow」に従って始めてみようと思う。・・て、一人でプルリクエストって、ないかなぁ。

SourceTreeにgithubを設定する / リポジトリをローカルにクローンする

さて、ようやく開発の「か」の字に辿り着けるだろうか、ね。
まずは、SourceTreeでgitを使ってみるために、githubの設定をする。
参考URL: Mac で Git するなら SourceTree がオススメ

SourceTreeにgithubアカウントを追加

起動時の右上にあるアイコン「ホスティングプロジェクト」をクリック（カーソルをしばらく重ねておくと出てくる）。

次に右上の「アカウントを編集」をクリック。

左下の「アカウントを追加...」をクリック。

「ホスティングサービス」に「github」を選択し、「ユーザ名」に自分のgithubユーザ名(at4k)を入れパスワードを設定する。

githubにあるリポジトリが表示される。

ここでは既存のリポジトリから開発を進めるので、以下のようにリポジトリをローカルにクローンする。

リポジトリをローカルにクローン

メニューの「ファイル」ー「新規／クローンを作成する」を選択。

「ソースパス / URL」の右端にある地球アイコンの「Hosted Repositories」をクリック。

先ほどのリポジトリのリストが出てくるので、開発したいリポジトリを選択して「OK」ボタンを押す。

「ソースパス / URL」が埋まるので、「保存先のパス」と「ブックマーク名」を適宜変えて「クローン」ボタンを押す。

という感じで「ブックマーク」画面にリストされる。

準備完了！

githubへの接続をsshで行うようにする

また一週間が経ちました。がんばってブログ更新してこ。

今日はgithubへの接続をsshで行えるように設定します。
webからはhttpsで接続していますが、ターミナルからは素でつなぐことになるのでssh経由がよかろう、と。

参考：
github help: Generating SSH Keys

では、さっそく始めよう。

新しいsshキーを作成

ssh-keygenでsshキーを作成

$ ssh-keygen -t rsa -C "at4k@users.noreply.github.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/xxxx/.ssh/id_rsa): /Users/xxxx/.ssh/id_rsa_github
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/xxxx/.ssh/id_rsa_github.
Your public key has been saved in /Users/xxxx/.ssh/id_rsa_github.pub.
The key fingerprint is:
(omitted below)

sshキーをgithubに登録

1. github.comのトップページ右上にある「Account settings」ボタンをクリック

2. 左側のメニューにある「SSH Keys」をクリック
3. 右上の「Add SSH key」をクリック

4. 「Title」を入力、「Key」にsshキーを貼付ける
5. 「Add key」ボタンを押す
6. githubのパスワード確認のためパスワード入力

sshキーが正しく登録されたかの確認

$ ssh -T -i ~/.ssh/id_rsa_github git@github.com

★注：メールアドレスは変更しないこと！

最初はfingerprintの確認メッセージが出るので「yes」と入力

以下のメッセージが返ってきたら正常に動作

Hi at4k! You've successfully authenticated, but GitHub does not provide shell access.

上記の途中でキーチェインに登録するか？と聞かれるので、それに保存しておけばパスフレーズは聞かれずにすむようになると思う

sshに渡す引数を初期設定として保存

毎回引数に長々と書くのは面倒なので初期設定に入れておく。

$ vi ~/.ssh/config
  HostName       github.com
  IdentityFile   ~/.ssh/id_rsa_github
  User           git

これで以下のように引数をいっぱい書かずに接続できるようになる

$ ssh github.com

Mac OS Xでアプリ内のウィンドウを切り替えるには

どうしても忘れる（笑）だから忘れたらまた書く。繰り返しが大事。

Mac OS Xでアプリ内のウィンドウを切り替えるには、以下のキーボード・ショートカットを押す。

command (⌘) + F1

1. ただ、これだと押しづらいので、以下のようにして変更
2. 「システム環境設定」ー「キーボード」の「ショートカット」タブを選択
3. 左側のリストから「キーボード」を選択
4. 右側のリストから「次のウインドウを捜査対象にする」を選択
5. 右の方のショートカットキーが書いてあるところをクリックして、変更したいショートカットを押す

新しく変更したショートカットは以下。

control (^) + command (⌘) + Tab

github をsetup / レポジトリを作る

github 事始めから日が過ぎてしまったので、そろそろ次のステップへ進もう。

まずは管理したいレポジトリの作成、、とその前に。

セットアップをしておいた方がよいみたい。

一番左に「Set up Git」を見てみよう。

Set up Git

まず目についたのは「ターミナルを止めて独自アプリはいかが？」と書いてある。

ただ、すでにMac OSXにはgitが入っているので次の「Set Up Git」へ。

最初にユーザ名とメールアドレスの設定。

$ git config --global user.name "Atsushi K"
$ git config --global user.email "at4k@users.noreply.github.com"

今後のキャリアを考えて本名で行こうかと思ったけど、もう少し自信がついてからにしよう。こういうところ、外国人の人たちってさらっと本名載せるよね。同じ名前になる場合がおおいからだろうか？

て話がそれた。

あとソースの差分を見るコマンドをvimdiffにしておく。

$ git config --global merge.tool vimdiff

これらの設定を確認する方法は、例えばユーザ名は以下。

$ git config user.name

最後に、リモートサーバに接続する際、毎度ユーザ名とパスワードを打つのは面倒！てことでキャッシュ機能がある。

すでにその機能が使えるかどうかをチェック。

$ git credential-osxkeychain
usage: git credential-osxkeychain <get|store|erase>

上記の表示が出る場合は、すでにインストール済。てことで「Create repositories」の作業へ。

Create repositories

いよいよリポジトリの作成。作ろうと考えてるソフトウェアはいくつかあるけどまだ考え中なので、ここではテスト用にいっぱい書く小さいコードを登録するリポジトリを作る。

会社でもいっぱい書いてるんだけど、持ち出しできないのでもったいない、よなぁ。

まずはトップページの「New repository」(緑色のボタン)を押す。

必要な箇所を埋めていく。

• Repository name
• Description (optional)

そして、このリポジトリを公開(public)するか非公開(private)にするかを決める。

ここでは公開とする。

最後に、ライセンスの選択。これはいままで利用する側だったのであまり勉強していないですが、以下のURLを参考に概略を知りました。このリポジトリはテストコードばかりなのでMITライセンスにしておきます。

参考URL: Githubによる、オープンソースライセンスの選び方まとめ

て、ことで「Create repository」(緑色ボタン)を押して作成終了！

P.S.

わ、リポジトリ名、まちがえた！！！

てことで、早速削除する方法を学びました。。。

参考URL:  githubでリポジトリを削除する方法

リポジトリのページの右側にある「Settings」をクリックすると、ページの下の方に「Danger Zone」という赤い領域が！

その一番下に「Delete this repository」ボタンがあるのでそれを押して、リポジトリ名を確認のため入力してボタンを押せばあっさり消えました。よかった。

「リーダブルコード」を読んで

2014年 最初のブログ。やっと書き出した。
年末年始で読んだ本「リーダブルコード」についてまとめておく。

今年はいろいろチャレンジする年にしたいので、まずは Amazon アフィリエイトに挑戦。
参考：クリボウの Blogger 入門

学んだこと

1. 書いたコードを積極的に他人に見てもらう
2. 条件分岐ではなるべく単純な条件から書く
3. 条件分岐やループのネストを浅くする

わかりやすさという意味でどちらかな？と悩んでいた部分もあったので、明快にしめしてもらったのはよかった。具体的に少し以下で述べてみる。

「第 I 部　表面上の改善」

基本的には心がけていたことだけど、どうしても日本語を英語にしてわかりやすく、、となると誤解を招く名前をつけてしまうときがある。
だから、再度見直すとか他の人の意見を聞く、というのは、改めてやろうかな、と思った。

「第 II 部　ループとロジックの単純化」

今までどっちかな？と思いながら気分で選んでいたコーディングスタイルがあった。for や while の中での条件分岐についてである。同じことをするのに何通りもの書き方ができる、という時点で、こちらとしてはどっちでもいいじゃんと思ってしまう訳だが、この本を読んでみてなるほど、と思ったので、今後はそういう風に書こうと思う。
つまり人がコードを読むとき、プログラムの動作として現在取りうる状態を考えながら読む。これまでは、それを考慮することが抜けていたのだと思う。

とりあえず、この辺で。
薄い本だったけど久々に完読出来てうれしいね。少しずつ勉強を続けていこう。