Swiftでカメラアプリを作る。

最近、暇を見つけてはSwiftを勉強しています。
今日は半日くらいマルッと使えそうだったので、Swiftでカメラアプリなぞ作ってみました。

先人達のコードを参考にしつつ、XCode6.01のSwiftで書き直してあります。

コードはこちら。 Github

どーせ書き方が違うだけだろと思ってたんですが、全然そうでもなく、Obj-Cで書いたプログラムをそのまま書き直せば動くっていう感じでは無さそうです。
また、言語としての抽象度が上がっているので、逆に色々ハマりどころがあります。

以下ハマった所。
なかなかdeviceInputが取得出来なくて苦労しました。サンプルを持って来ると何故かnilが帰ってくるという。とりあえず、こんな感じに修正して動きました。

    var videoDevice:AVCaptureDevice?

~~~~~~~~~~~~~中略~~~~~~~~~~~~~~~~
        var error:NSError?
        videoDevice = CameraViewController.device(AVMediaTypeVideo, position: AVCaptureDevicePosition.Back)
        let videoDeviceInput = AVCaptureDeviceInput.deviceInputWithDevice(videoDevice!, error: &error) as AVCaptureDeviceInput

~~~~~~~~~~~~~中略~~~~~~~~~~~~~~~~
    class func device(mediaType: NSString!, position: AVCaptureDevicePosition) -> AVCaptureDevice? {
        var devices = AVCaptureDevice.devicesWithMediaType(mediaType) as [AVCaptureDevice]
        
        if devices.isEmpty {
            return nil
        }
        
        var captureDevice = devices[0]
        for device in devices {
            if device.position == position {
                captureDevice = device
                break
            }
        }
        return captureDevice
    }

あとイメージをキャプチャして保存するのが結構ハマりました。

 
    func takePict(sender: AnyObject){

        var layer : AVCaptureVideoPreviewLayer = previewLayer! as AVCaptureVideoPreviewLayer
        
        self.stillImageOutput?.connectionWithMediaType(AVMediaTypeVideo).videoOrientation = layer.connection.videoOrientation
        
        var error:NSError
        
        self.stillImageOutput?.captureStillImageAsynchronouslyFromConnection(self.stillImageOutput?.connectionWithMediaType(AVMediaTypeVideo), completionHandler: {
            (imageDataSampleBuffer,error) -> Void in
            if ((imageDataSampleBuffer) != nil) {
                var imageData : NSData = AVCaptureStillImageOutput.jpegStillImageNSDataRepresentation(imageDataSampleBuffer)
                var image : UIImage = UIImage(data: imageData)
                ALAssetsLibrary().writeImageToSavedPhotosAlbum(image.CGImage, orientation: ALAssetOrientation.fromRaw(image.imageOrientation.toRaw())!, completionBlock: nil)
            }
        })

    }

一応こんな感じで何とか動いてます。（正直まだ良く分からない所が多い。）

なんというか、Obj-Cよりも難しいなと思うのは、書き方のパターンが色々ある所とXcodeがまだ自動補完とか完全で無い感じの所ですね。
構造体とかの使い方が特徴的らしいので、その辺りをマスターすればよりSwiftっぽい書き方になるんじゃないかなーと思います。

参考になれば幸いです。

ipython notebookとscikit-learn

だいぶご無沙汰です。
ここの所、iOSやったりAndroidやったり色々でした。
ちょっとアルゴリズムの検証として数値計算するニーズがありまして、Rでも覚えようかどうしようかなと思っていた所kzfmさんからipython notebookとscikit-learnがいいよと教えて貰ったので、早速インストールしてみました。
インストールはpythonのパッケージ管理ツールpipが動けば全然楽勝だったんですが、最初easy_install pipしても

DistributionNotFound: setuptools==0.6c12dev-r85381

とか言われて全然インストール出来ず。ググったら親切な外人が/usr/bin/local/以下のeasy_installが複数入ってる可能性があるから一個消せば動くよって教えてくれたので、解消しました。感謝！


で、pipが動く様になったら後は楽勝です。まずは、ipythonのインストールから。あ、環境はMac OSX marverikです。

$ sudo pip install ipython

としてから、

$ sudo pip install jinja2
$ sudo pip install tornado
$ sudo pip install pyzmq

として

$ ipython notebook

ってやると、おもむろにブラウザがこんな感じで立ち上がります。こりゃ便利そう。


んで、数値計算の方なんですが、scikit-learnを動かすにはnumpy,scipyが必要なので、こちらもpipでインストールしてから、

$ sudo pip install scikit-learn

でインストール完了です。どうも途中Xcodeのcommand line toolが必要みたいなんですが、既に入ってるので、問題ナッシンでした。

とりあえず、これで準備は完了なんですが、とりあえず色々触ってみたいと思います。

コードを書く上で、最近気をつけている事について

ここの所、思う所ありコーディングのスタイルを改善しようと思い立ってます。
７月は”コード美化月間”です。

という訳で、気をつけようと思っている事を列挙します。
・インデントの徹底
Pythonですと、普通に書いていれば割りとインデント合うのですが、obj-cはインデントキチンとしてないと後で非常に読み難いです。PHPも徹底すると可読性がグッと上がるので、特に気にして書いています。

・メソッドの機能コメント
メソッドの先頭に機能のコメントを英語で短く書く様にしました。こうする事で、Xcode6Betaで出る自動補完が効かない不具合を回避出来るってのが一番の理由ですが、副産物として考えが整理されるというメリットを発見しました。（英語苦手なだけに）
割と良いかもと思うので習慣化したいです。

・１行コメント
１行コメントで１行使うの辞めました。コードの末尾に書く事に徹底。すげースッキリ。

・"=>"とか"->"とか"="とかの扱い
例えばなんですが、

  
    public  $hasOne     =   array(
                    'hoge' =>  array(
                        'className'  =>  'UserInfomation',
                        'foreignKey'  =>  'user_id',
                        'conditions'  =>  'hoge',
                        'fields'  =>  'fuga',
                        'order'  =>  'hage',
                        'dependent'  =>  false
                    )

こんな感じの所を、こんな感じに直します。

  
    public  $hasOne     =   array(
                    'hoge' =>  array(
                         'className'  =>  'UserInfomation',
                        'foreignKey'  =>  'user_id',
                        'conditions'  =>  'hoge',
                            'fields'  =>  'fuga',
                             'order'  =>  'hage',
                         'dependent'  =>  false
                    )

ラインが揃って超スッキリ。後で読む気になります。
書き直している時に見直しが入るので、間違いも見つけやすいです。

あとは、リスト内包表記で複雑な書き方しないとか、SQL文も改行入れて読みやすくするとか、後で人が読んでも恥ずかしく無い様なコードを書く習慣付けをしています。
地味なんですが、レベルアップして行く為にも必要な事だってのが何となくわかって来たので。

まあ、成果物そのものよりも、多分心がけの問題なのかなとは思いますが、いい習慣だとは思うのでなるべく続けて行きたいなぁと思っております。

iOS開発向けのコマンドラインツール、Nomadが便利そう。

ナゾの背中痛で薄ら死にそうになってるんですが、久々のブログ更新です。

アプリ開発の方が色々と入り組んで来たので、色々省力化の手順を模索していました。

こんな本読んでみたりとか、（ちなみに結構いい本。オススメ）webで情報漁ってみたりとか、まだまだ色々模索中です。

そんな中で、やりたい事、必要そうな事が朧げに見えて来ました。
何をしたいかっていうと、
・似た様なアプリを複数リリースする為に、Assets（素材）やクラスをターゲット毎に切り替えたい。
=>　ビルドターゲットの切り替えで、１つのプロジェクト内でバージョンの少しずつ異なるモノを別々に管理出来る。
=>　共通コードはそのままなので、アップデート時の事故が減る。
=>  それでも不安なので、テストを書く。
=>  ターゲットが増えると、手動でビルドしまくるのは非常に面倒だし時間も掛かる。
=>  CIツール導入検討、もしくはビルド用のシェルスクリプトを書く。

と言う訳で、CIツールを導入検討すると、オンラインで出来るCIサーバとか結構あるんですよね。しかも無償でBitbucket連携とか。
でもでも、それはwebに限った話。そもそもMacでないとiOSのCIサーバ立てられません。コンパイル出来ないからね。なんで、オンラインは無理。
そろそろ、開発用のPCもガタが来てるので、Mac miniを予備機で購入してCIサーバにあてようかと検討していたんですが、そこはちょっと保留。設定に時間取られるのがシンドイ状況なので、とりあえずもう少し時間が出来てから。
じゃあとりあえずビルド用のスクリプト書きますか、という流れです。

実はXcodeはコマンドラインツールは完備していて、シェルスクリプトでビルドからリリースまで一環して行う事が出来ます。ここにテストの工程を挟めば立派なCIの流れが実現可能です。
まずは、テストはXcode上で行って（そもそもまだ一部しか書いてない。）配布、リリース用は個別にスクリプトを書く事にしました。
つーても、コレが結構面倒です。何か楽にする方法無いのかなーと思ってたらありましたよ。こんなのが。

http://nomad-cli.com/

一言でいうと、普通に考えられるiOS開発用のコマンドライン操作を使いやすくまとめたツール郡です。機能別に都市名が付いてて、Cupertinoはアカウント管理関係。Dev Centerの操作とかが可能。HustonはPush通信のトークン周り。（コレ地味に有り難い。）
DubaiはPassBook発行関連。VenisはIn-App-Percheceの管理周辺。Shinzhenはアプリ配布やリリース関連と、イイカンジで揃ってます。
特に、Shinzhenはビルド完了時にTestFlightで配布とかを自動化出来たりします。
ただ現状やりたい事に完全にマッチするかといわれると問題があって、簡易な使い方を目指してるのでビルドターゲットの指定が出来ないです。
なので、ここはちゃんとXcodebuildでビルドスクリプト書くしか無いっぽい。残念。

とはいえ、結構使えそうなツール郡なので、活用してみますよー。

例えば：
Automator君でフォルダアクションを作成して、連携して走るshにコレ書いとけば、フォルダにipaファイル放り込めばテストフライトにアップロードとか簡単に出来る予感。


そんなお話でした。

ライブドアブログの自動投稿について

はい、ご無沙汰です。

ちょっと調べる必要がありライブドアブログの自動投稿をテストしてみて、あまり使えない事が判明したので、メモです。

自動投稿は指定のURLにAtomPubで整形した文書をリクエストするだけ。pythonなどでは普通にurllibとかurllib2なんかで対応可能。
こんな感じのURL
https://livedoor.blogcms.jp/atompub/(ここに自分のブログ)
ブログ設定でAPI Keyという項目があるので、ここで確認出来る。自動投稿をonにするとパスワードも発行されるので、メモっておく。

ブログの自動投稿プロトコルは、xmlrpcやらAtomPubやらあるみたいだけれども、それぞれ規格があるので詳細はそちらを参照されたし。

実際試してみた所、どうも投稿が上手く行く場合とそうでない場合がある。
どうやら以下の様な制限があるみたい。

• 文字数制限（大量のテキストはダメっぽい。制限文字数は未検証）
• 特定のタグを使用していると投稿出来ない（少なくともリンク付きAタグはダメだった。他未検証）
• 仕様がコロコロ変わるっぽい。しかもドキュメントが無い。

自動投稿を認めているサービスとしては、まあ普通にあり得る内容。
まあ、中々使い難い仕様ではある。編集も出来る模様なので、長文でも数回に分けて投稿すればもしかしたら通るのかも知れない。けどリンク貼れない時点で、使い途としては相当制限される印象。
実際こういう使い方したいのであれば、自前のブログシステムをWordPressか何かで作ってそこに投げた方が、制限無くていいんじゃないかなという結論でした。

そんな感じ。

Polaroid PoGoを買ってみた

最近、運動不足が極まって、腹回りがどうにもヤバくなっていて、とうとう体脂肪率が25%をオーバー。体脂肪計によれば、立派な肥満体らしいです。
という訳で、日中ヒマを見つけて運動する様に心がけています。主に自転車でブラブラするだけですが。

んでもって、ついでにハードオフに寄ったら、ジャンクコーナーでこんなの見つけました。

Polaroid のモバイルプリンタ。PoGoっつーのらしいです。

なんと、お値段¥540。
箱、マニュアル無し、動作保証無し。でも見た目は比較的奇麗。
その場で軽く仕様を調べると、Bluetoothで繋がるモバイルプリンタ。iPhoneはムリみたいだけど、Android、Macからは大丈夫との事で、試しに購入。

ジャンクコーナーだし、値段も値段だし、動かねーかなーと思いながら、帰宅後あけて見ると、中に専用用紙が2枚程入っていて、予習通り試しにMacから印刷してみると、、、

普通に動きました。

どうやらバッテリーが死んでるらしく、充電は出来ませんでした。
用紙の入手性が悪そうなので、稼働は良く無さそうですが、540円のオモチャとしては上出来な模様。
持ち歩きの時はACアタプタと一緒に持ち歩けば、問題無さそう。（電源ある所じゃないと印刷出来ないけどね）
コレだからチョイチョイ行っちゃうんですよね、ハードオフ。

plistの読み込み

毎度の事ながら、いつも忘れるのでメモ。
プロパティリスト(plist)は、アプリケーションで持たせたい初期値などを独自のファイル形式で持たせ、アプリケーションのロード時とか、結構色んな所で使うんですが、いつも忘れます。

    //pList読み込み。
    NSBundle* bundle = [NSBundle mainBundle];
    //読み込むファイルパスを指定
    NSString* path = [bundle pathForResource:@"elocution" ofType:@"plist"];
    NSDictionary* dic = [NSDictionary dictionaryWithContentsOfFile:path];

よく使う場面は、CoreDataなんかは初期値を持たせられないので、初期値を持たせたい場合に初回起動時にplistから読み込んでCoreDataに放り込んだりする処理を書きます。
あとはゲームの面データとか、そういう後から調整が必要で固有値をハードコーディングしたくない場合にも使います。
利点はデータを一カ所に纏めるので、更新、閲覧性が良い事と、後々webからデータを引っ張って来る形式にしたい場合に変更が容易です。
例えば、開発段階はローカルのplistから読み込み。途中の段階で、サーバにアップされたplistを読み込む形式に変更などといった具合。

xmlでもいいんじゃないかなーと思ったりしてましたが、実は中身は全くxmlです。拡張子違うだけっぽい。
なので、ちょっとしたツールを作れば割と大規模な初期値データなんかも比較的簡単に管理出来たりします。データ更新の必要が無ければ、コンテンツはplistで管理するのは結構現実的かと。

ここの所、全く時間が足らず。キツいです。自習時間が取れない。
おかげで色々と事は進んでいるんですが、結果として現れるのはもう少し先になりそうなので、まあアレだ。早くやれって感じです。
色んな事情で、進められるのに進まない事ってあるんですよねー。なんだかなあと思います。

K君の話

友達に”K君”という人が居て、K君は僕が今まで生きて来た中で出会った人の中ではトップクラスのバカで、どういうバカかというと、仕事で車使うのに全然平気で飲酒運転とかしちゃうし、それでオマワリサンに捕まって、免停になっても平気でクルマ乗っちゃう感じのバカです。（※たとえ話です。）

飲みながら話をした時に、あんまり反省してないっぽかったので、ちょっと今までに会った事のないタイプの人だなあと面白く観察しておりました。
非常に愛嬌のあるキャラクターで、コンプアライアンスの概念が欠落している所を除けば非常に面白い男で、皆に愛されております。
そんなK君は30代も中盤。結構いいオッサンです。で、K君と仲良しなM君というのが居ます。
M君はまだ20そこそこ。見た目はまぁ、ヤンキーです。黒地に金の刺繍の派手なジャージ上下で見かける事が多いです。僕は最初結構偏見持ってたんですが、これが見た目に反してすげー良い若者で、もの凄く純だしモラリストだし仕事もスゴくマジメに取り組む好青年です。

K君とM君はスゴく仲が良くて、お互いの家に入り浸ったりしてます。例えるなら、まるで大学生のツレ同士が仲良くしてる感じの付き合いです。
K君は色々バカだけど、僕がK君の事を一目置いてるのは、年齢が一回り以上離れた人とも全然フラットに付き合える事。
自分に置き換えて考えてみると、10以上違う人って以外と共通の話題が無かったりするんだよなーと。お互いの家にふつーに行き来するレベルまで仲良くなるのって、自分の中の相手に対するハードルをもの凄く下げないと出来ない事な訳で、多分K君が愛されキャラなのは、誰に大しても抵抗無くハードルを下げられる所にあるのかなと思ったりします。コミュ力が高いってこういう事なのかな。

でも二人は、客観的に見ると田舎のフツーのDQNなので、”身内にはスゲー甘いけど外野には異常に排他的”という特徴があります。共通の知り合いの紹介とかだと一気に身内扱いですが、そうでないと、ただのDQNです。なんなんでしょうね、この傾向。

さておき、後生畏るべし。という言葉がございますが、M君に限らず、最近の知り合う若い人は良く出来た人が多いです。自分に当てはめてみて、俺20の時こんなしっかりしてなかったよーと思う事しばしばです。なんというか、着実に前の世代からの失敗から学んでる感じがします。例えば意外と結婚が早かったりしてね。こういう所は逆に色々学ぶ所が多いなと思う事しきりです。

最近、この二人には会ってないんだけど、ふと思い出したので。K君元気かな。

NSURLについての覚え書き。

何回かやってて、毎回ハマる所。 文字列NSStringから、webアクセスする時のNSURLConnection に渡すときの覚え書き。

NSURL *url = [NSURL URLWithString:[endpoint stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];

つうか、原因不明なんだけど背中がバッキバキで長時間作業が出来ない感じ。なんとかしてくれー。

CoreMotionの使い方

次のアプリに着手してるんですが、CoreMotionで順調にハマっております。
マジで、最高にややこしいです。やっぱ行列苦手とか言ってられないですね。

まず、最初にハマったのが、実行速度が遅い事。
全然数字あってねー、とか思ってたらガンガン処理落ちしてました。

例えば、こんな感じでCoreMotionを呼ぶのですが、

@property (nonatomic, retain) CMMotionManager *manager;
- (void)viewDidLoad
{
    [super viewDidLoad];
    self.manager = [[CMMotionManager alloc] init];
    
    //加速度
    [self startCMGyroData:50];
}

- (void)startCMGyroData:(int)frequency
{
    // ジャイロスコープの有無を確認
    if (self.manager.gyroAvailable) {
        // 更新間隔の指定
        self.manager.gyroUpdateInterval = 1 / frequency;  // 秒
        // ハンドラ
        CMGyroHandler handler = ^(CMGyroData *data, NSError *error) {
            double gyro_x = data.rotationRate.x;
            double gyro_y = data.rotationRate.y;
            double gyro_z = data.rotationRate.z;
            //testGyroRectangle.position= CGPointMake(160+160*gyro_x,240+240*gyro_y);
            testGyroRectangle.frame = CGRectMake(160+160*gyro_x, 240+240*gyro_y, 30*gyro_z, 30*gyro_z);
        };
        // センサーの利用開始
        [self.manager startGyroUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:handler];
    }
}

ここで幾つか落とし穴。

• Blockの所の引数（ここではCMGyroData *data)は使わない。後述のNSLockを使う場合の障壁になる。
• 状況に依るけど、空間座標絡みは、CMRotationMatrixを使うべき。ややこしいけど、理解すれば非常にスマートに処理出来る。
• Block内で、データ取得の際は、NSLockを使う。そーすると、他の処理に引きずられる事無く、割とリアルタイムに数字が取れる。GDCでも良いかも。
• Blockの中のNSLockで記述される処理は極力減らす。（CALayerの更新とかは１つ以上だとスゲー重くなる。）優先度の低い処理は別途timerなどで処理する。

実際の所、CoreMotionの処理は中々の高負荷なので、サンプルコードまんまだと処理が重い場合が結構ある。処理落ちすると、データの追随性が極端に悪くなって、傾けたのに反映されるのが5-10秒後で全然使い物にならない事がままある。
なぜそんなに重いのかというと、カメラと重ねてたから。描画はCALayerなので比較的軽いハズなのだけれども、AVCapture自体が結構重いので、CoreMotionを重ねると激重となってた次第。別スレッドに分けるなどすれば非常に改善されるので、使用する場合はスレッド処理必須かと思う。

また、CoreMotionで取得出来るデータは、幾つか種類があるけど、加速度データは非常に扱いが難しい。
これはジャイロセンサーの特性に依るので、仕方ない。でも、極座標データに変換してくれる関数が入ってる。
取れる値は、CMRotationMatrix、CMQuaternion、CMAttitudeとあるが、それぞれ特性があるので用途によって使い分けるべきところ。
でもオススメは、CMRotationMatrix。情報が少なく概念を理解するのは骨が折れるが、概念を理解すれば、やりたい事が一発でバチっと決まる。計算量が少なく済むので、当然処理も早い。CMAttitudeはオイラー角なので、変換の計算がどうしても多くなる可能性がある。
RotationMatrixはこんな感じで呼ぶ。

        CMDeviceMotionHandler handler = ^(CMDeviceMotion *motion, NSError *error) {
            
            //引数のmotionは使わない。
            CMDeviceMotion* deviceMotion = self.manager.deviceMotion;
            
            CMRotationMatrix rotmatrix = deviceMotion.attitude.rotationMatrix;

　　　 /*各種処理*/
}

こんな感じで、rotmatrix.m11とかそんな感じの3x3の行列が渡される。 最初これ、中身の意味が解らなくて、結構悩んでたんだけど、恐らく下記の様な感じ。

    rotmatrix.m11  //デバイスのx方向を指示するベクトルを表す絶対x軸方向の座標点 　多分-1〜1の範囲。
    rotmatrix.m12  //デバイスのx方向を指示するベクトルを表す絶対y軸方向の座標点 
    rotmatrix.m13  //デバイスのx方向を指示するベクトルを表す絶対z軸方向の座標点 
   /* 以下略 */

中身が解ってしまえば、こっちのもの。後は回転行列に放り込むなりなんなりで、結構自在に操作出来る感じです。
コツは鉛直方向のベクトルは３次元位置補足済みであれば常に(0,0,-1)を示すので、デバイスの表示面がxy平面だと言う事を意識すると色々上手く運びます。
ちなみに、補足までに時間が掛かり、タマに意図せず狂うので、補正が必要です。
こーいうの結構好きなんで楽しかったです。

これを使ったアプリはリリースし次第またご報告します。

アプリをリリースしました。（してます。）

ひっそりと告知でございます。
２本ほどアプリがリリースされてます。

http://muchicoapps.tumblr.com/

一つはなんとイカと一緒に写真が撮れるという画期的アプリ、”イカメラ”。
完全に出落ちです。すいません。一笑して頂ければ幸いです。

もう一つは、色の電卓”ColorCalc”です。
RGBと16進数のカラーコードを相互変換して、保存も出来ます。
保存エリアは10個までですが、課金で増やす事も可能です。

両方とも開発期間は夕方〜の開発で一週間程。電卓の方は、年末年始を挟んだので、審査とおるのに一ヶ月近く掛かりました。

宜しければ、ダウンロードして使って頂ければと思います。
レビュー書いてくれたら、もの凄く嬉しいです。あと、アド踏んでくれたら嬉しいです。

まだまだ、リリース予定のアプリがありますので、乞うご期待です。

ここでアプリサイトをTumblrにした理由なんぞ書き連ねたいと思います。

・サーバがタダ。
まずココがデカイですね。カスタム性が高くて、最近は割と安定してますしそれで無料。

・拡散性に期待。
まだまだ狙い通りでは無いんですが、フォロワーを増やす事によって、リリース情報が拡散しないかなーと言う目論み。実験的な側面が強いです。

デメリットは
・多言語対応したいけど、そんなにページが沢山作れない。
・カスタムが結構メンドクサイ。（特にCSS,JSをどうホストするか。)

あと、この辺のプロモーションは中々難しいですね。アプリベンダーもこの辺が非常にネックなんだろうなと思います。方法論は頭で解ってても、実際ヤルとなると工数が掛かりすぎて、開発止まってしまいますしね。AppStoreが検索性悪いので、競合多いと埋もれてしまいますし。そりゃレビューサイト流行るわ。

本年も宜しくお願いします。

あ。

ッという間に年が明けてしまいました。

本年も宜しくお願い致します。

という訳で、最近のトピックを幾つか。

今までGitは使っていたのですが、ほぼ一人作業なので、ブランチ切ったりとかしないで、commitとaddの直線管理的な運用しかしていなかったんですが、先日ちょっとブランチ切ろうとしたら、上手く出来なくてキィィィイィとなってました。

環境はNetBeansを利用していたんですが、ブランチ切れてる筈なのに、切った先に切り替えると中身が何も入っていないという謎現象。
小２時間ほど悩んだ結果、コマンドラインでやったらアッサリ上手く行きました。

で、後で仲間内で聞いた所、NetBeansのブランチ機能の挙動おかしいよねって話になりましたとさ。

で、SouceTreeなるソフトを勧められたんですが、これがまたイイカンジ。
基本Gitはコマンドラインで運用するのに分かり易い作りになっているので、コマンドライン運用で全然問題無いんですが、SouceTreeはブランチの可視化機能が非常にイイカンジかなと思いました。あと脳細胞が死んでいてコマンド忘れるので、そういう向きにも良いですね。あと黒い画面を触ると死ぬ病気の人とかにもオススメです。

んで、このソフト。BitBucketなるサービスにアカウントつくるかねーって初手から聞いてくるんですが、このBitBucket何ぞやと調べてみた所、無料でプライベートリポジトリが無制限に作れるとの事。プロジェクトに参画するユーザー数で課金するモデルですね。
世に出すには恥ずかしいコードしか書けない身としては、これは有り難いです。
という訳でとりあえずアカウントだけ作ってみましたとさ。

色々環境整備に追われつつ、新しいのが出てて触ってみつつとかやってたら、新年ももう９日です。まじかー。

やっとコードが書ける感じになってきたので、ちょいと頑張りますよ。