ちょっと厨二っぽいSEのブログ

プログラミングとかのシステム備忘録など

【Git】特定のフォルダのみを操作対象にする

同じシステムの改修が何年も続くと、Gitリポジトリが重くなっていきます。
さらに同一のリポジトリに複数のシステムが乗っておりPullするだけでヒドイ状態・・なんてことがプロジェクトによってはありえますよね。(最近経験した話)

そんな時は特定フォルダのみを操作対象にして動作を軽くしましょう。
sparsecheckout という機能を使うことで、対象フォルダ以外の存在を隠し、動作を高速にすることが出来ます。

git config core.sparsecheckout true
echo 対象フォルダのPATH/ > .git/info/sparse-checkout
git read-tree -m -u HEAD

対象リポジトリに対して行います。
まず、sparsecheckoutを有効にします。
その後、以下のファイルに、必要なフォルダを相対Pathで記述します。
.git/info/sparse-checkout 
Windowsだとしても / 区切りで記述してください。

これで準備は完了です。以下のコマンドを実行すると、不要なファイルはいなくなります。

git read-tree -m -u HEAD

.git/info/sparse-checkoutには改行区切りで複数のフォルダを記載できます。

echo 追加で表示させるPATH/ >> .git/info/sparse-checkout

【Git】Gitプロンプトを便利にする方法

以下のことを実現します。


・Gitコマンドの自動補完
・Gitのプロンプトの表示を変更

Gitの自動補完

コマンドの途中でTabを押すことで入力を行う、自動補完
下記URLから「git-completion.bash」をコピーし読み込み。
git bashの場合は追加ずみ(C:\Program Files (x86)\Git\etc\git-completion.bash)
https://github.com/git/git/tree/master/contrib/completion/git-completion.bash
設定の読み込みには.bashrcを使います(後述)

Gitのプロンプトの表示を変更

ブランチ名を表示

同じく以下のファイルをコピー、読み込み。(同じくgit bashには追加されている)
https://github.com/git/git/blob/master/contrib/completion/git-prompt.sh

オプション

gitプロンプトにもオプションがあり、以下の変数の変更することでプロンプトの表示を変えるることができます。

GIT_PS1_SHOWDIRTYSTATE
addされてない変更(unstaged)があったとき"*"を表示する、addされているがcommitされていない変更(staged)があったとき"+"を表示する

GIT_PS1_SHOWSTASHSTATE
stashになにか入っている(stashed)とき"$"を表示する

GIT_PS1_SHOWUNTRACKEDFILES
addされてない新規ファイルがある(untracked)とき"%"を表示する

GIT_PS1_SHOWUPSTREAM
現在のブランチが追跡ブランチより進んでいるとき">"を、遅れているとき"<"を、遅れてるけど独自の変更もあるとき"<>"を表示する。

PS1の設定方法

コンソールの表示
色の変更や、2行を1行に変更ができます。
http://qiita.com/caad1229/items/6d71d84933c8a87af0c4
f:id:ryokwkm:20170921125254p:plain 

f:id:ryokwkm:20170921125506p:plain

・設定

.bashrcで設定を行う

自己紹介

このブログはシステムやビジネスに関する備忘録として作りました。

web系システム中心に、上流から実装まで役立つ情報をまとめようと考えています、
その他に、ビジネスパーソンとして必要なスキルについてもご紹介いたします。

フリーでシステムエンジニアをやってまして、現在は大学院にて経営関連のことを学びながら活動中。


2016 - 2017 :
上流を中心に担当
アーキテクチャの選定、設計
ベンダーコントロール、外部企業との折衝など
大学院に入学

2008 - 2015 :
上流から下流まで担当
会社に勤めつつ、プライベートでアプリをリリース


業務知識:
予算管理から、要件定義、開発、システム運用まで、開発に必要な幅広いフェーズを経験いたしました。
人の採用や、評価といった部分も経験。
様々な立場の方との折衝も経験しております。未熟な点もありますが、一通りの業務をこなすことが可能です。


アプリ:
幅広く経験しており、Android, iOS各プラットフォームのネイティブでの開発から、
フレームワークを使ったクロスプラットフォームアプリの開発、証明書まわりを含めて深い知識があります。
またアプリ内イベントの計測、アプリ外流入経路等の計測、広告露出部分についても携わっており、アプリのリリースからその後の運用までサポートが可能です。


インフラ:
LAMP環境構築に関することはもちろんのこと、AWSに関する幅広い知識があります。
EC2, RDS, S3などの基本的なところから、ElasticSearch, Dynamo DB, Lambda, SNS等もメインで活用しております。

Push通知の証明書、p12 -> pem変換について

Push通知の証明書をP12からPEMに変換する方法、Push通知のテストをする方法、Push通知の証明書の種類などをまとめました。
範囲としては、キーチェーンからp12を作るところから、pemに変換するところまでになります。

証明書(PEM、P12)の種類

push通知の証明書はその役割によって4パターンのファイルにわけることができます。
push通知はサーバーに置いて使いますが、送信実行するにあたりパスワードや秘密鍵を設定することができます。
ここではわかりやすいように、以下のファイル名を使用します。
拡張子はp12とありますが、システムによりpemに変換する必要があります。

xxx_push_production.p12 : パスありの証明書
xxx_push_production_secret.p12 : 証明書の秘密鍵
xxx_push_production_secret_noenc.p12 : 証明書の公開鍵(秘密鍵のパスワードを解除したもの)
xxx_push_production_test.p12 or xxx_push_production_all.p12 : パス無しの証明書(=証明書と公開鍵をあわせたもの)

p12 書き出し方法

一番簡単なものはパスワード無しの証明書を作成する方法です。
push通知を送る際パスワードを使用しませんので、テストに使用するのには良いと思います。
キーチェーンからp12を書き出す際は、以下のように証明書を選択(鍵ごと選択します)
xxx_push_production_test.p12 という名前で保存します。
f:id:ryokwkm:20170627194939p:plain


サービスを運用するにあたり、証明書とキーは分けて管理するのが一般的です。
やり方はそれぞれ以下のとおりで、
書き出し後にパスワードを求められますので、設定してください。

証明書の書き出し

xxx_push_production.p12 として保存
f:id:ryokwkm:20170627200317p:plain

秘密鍵の書き出し

xxx_push_production_secret.p12 として保存
f:id:ryokwkm:20170627200344p:plain




P12ファイルからPEMファイルへの変換方法

pemの種類によってコマンドが異なります。
コマンド実行時にパスワードを求められますが、これは出力時に設定したパスワードを入力してください。

・証明書(パス無し)

openssl pkcs12 -clcerts -nodes -out xxx_push_production_test.pem -in xxx_push_production_test.p12

・証明書(パス付き)

openssl pkcs12 -clcerts -nokeys -out xxx_push_production.pem -in xxx_push_production.p12

秘密鍵

openssl pkcs12 -nocerts -out xxx_push_production_secret.pem -in xxx_push_production_secret.p12

秘密鍵パスフレーズを解除し、公開鍵へ変換

openssl rsa -in xxx_push_production_secret.pem -out xxx_push_production_secret_noenc.pem

パスレーズを解除する目的や使い方

鍵ありの状態ですと、apache等のサーバーでは起動のたびにPEMフレーズ (PEM phrase) の入力を求められます。そのため、暗号化された秘密鍵は復号化して使うのが一般的です。
復号化した秘密鍵はroot以外は読めない状態で保存すべきです。

証明書と公開鍵をあわせる

cat xxx_push_production.pem xxx_push_production_secret_noenc.pem > xxx_push_production_all.pem



証明書のパスワードを確認する方法

古い証明書や自分以外が作成した証明書など、パスワードを確認したい場合があると思います。
方法はいくつかあると思いますが、以下のコマンドを実行するとパスワードが求められますので、
それが想定したものとあっているか確認する方法が最も簡単な方法です。
openssl rsa -in xxxx_push_production.pem




疎通テスト方法

証明書が正しいか、ターミナルからお手軽にテストすることができます。
注意すべきなのは、Xcodeから実機インストールした場合、テストできるのはdevelopのpush通知のみだということです。

・疎通テスト(パス無し)

openssl s_client -connect gateway.push.apple.com:2195 -cert xxx_push_production_all.pem

・疎通テスト(パスあり)

openssl s_client -connect gateway.push.apple.com:2195 -cert xxx_push_production.pem -key xxx_push_production_secret.pem

Push通知を送ってみる

アプリと証明書、両方のテストがしたい場合、実際にPush通知を送ってテストします。
PHPとは違い、Rubyでしたら数行書くだけで簡単に送れますので、そのサンプルを載せておきます。

gist.github.com

Tech Crunch Tokyo 2016 レポート 一日目

f:id:ryokwkm:20161120111711j:plain

2016/11/17(木)、2016/11/18(金)の二日間、Tech Crunch Tokyo 2016に参加してきました。


まずこのイベントがなんなのか

Tech Crunchは、スタートアップ企業の紹介やインターネットの新しいプロダクトのレビュー、そして業界の重要なニュースを扱うテクノロジーメディアです。

Tech Crunch Tokyoは年に一回開催される上記サービスのイベントで、日本最大のスタートアップ祭典と呼ばれます。

名前からはテクニカル系の情報がメインと感じますが、
メインの内容としてはサービスのプロダクトや、スタートアップに関する情報でした。

もちろんテクノロジーに関するプロダクトのイベントなので話題は出てきますが、
VCやアクセラレータに関すること、スタートアップ企業の事業計画の説明やプレゼンなどがほとんどを占めます。

イベントステージ以外の通路にも企業の出店があり、プロモーションや参加者との交流が盛んにおこなわれていました。

内容としては、もう軌道に乗りはじめている企業から、
「今年新しいSNSを立ち上げましたー」というような企業まで様々です。

様々な催しがありましたが、
特に興味深かったのは、「スタートアップバトル」です。
これは今年プロダクトをローンチしたスタートアップ企業がプレゼンで競い合うイベントで、
「市場性」「独自性」「将来性」の3点で審査を行い、最優秀プロダクトを決めるものです。

約5分間を2000名の来場者全員の前で話します。

優秀者はこのイベントで資金調達をできたり、その他にも様々なメリットを享受できます。

今回はスタートアップバトルの中で気になった一つを紹介します。

出張のための計画を自動で作ってくれるサービス「AI Travel」です。
AI Travel:世界一シンプルな国内出張・海外出張の予約手配サービス


旅行のプランをざっくり伝えると計画してくれるサービスで、
出張する場所はどこで、ホテルはこんな感じ、交通手段はこれ などと入力すると
新幹線や泊まるホテルの案をいくつか出してくれます。

また最寄り駅に近いかなどの他に、ホテルがコンビニや繁華街に近いかなど、人が実際にホテルを予約する時の判断基準も考慮されています。
私も旅行するときに一番苦労するのがホテル選びになるので、個人的に使ってみたいと感じました。

またこの「プランを立ててくれる機能」は今後色々な企業が行ってくるのではと思います。

例えば居酒屋なんかは特にこだわりはなく、場所や値段、雰囲気がマッチすればそれでいいと思いますので
それらを設定するとマッチしたものの候補を出してくれるようなものは使ってみたいです。

このプランの選出には機械学習や独自のアルゴリズムを使っているらしく
テクノロジーとしてはそこも将来性を感じました。

【プロジェクトマネジメント】見積もりについて考えてみましょう【PMBOK】

■見積もりの種類

一言で見積もりといっても、色々あります。
まず、「何のための見積もりか」について考えてみましょう。

例えば以下のように、見積もりを提出する先によって見積もりの意味が変わってきます。

1.自チームのPMが見積もった、そのプロジェクトに実際にかかるコスト
2.自チームのPMが見積もった、ある程度のバグフィックス(バッファ)を加味した現実的なコスト
3.自チームのPMが見積もった、クライアントに報告するための少しゆとりのあるコスト
4.お客様ベンダーに対して報告するための見積もり

たとえば4の場合、競合他社に勝つために実際よりも少ないコストを報告する場合があります。
いわゆるコンペの場合などがそれにあたり、実際に見積もりコストとかけ離れる場合があります。

と、このように
「見積もり」と言ったらどの見積もりを指すのかを把握しておかないと、後々のノウハウになりません。


■見積もり粒度には2種類ある

PMBOK的には、見積もりは以下の種類があります。

概算見積もり
確定見積もり


概算見積もりは読んで字のごとく、ざっくりとした見積もりです。
このような不確実な見積もりでも、ざっくりとした予定が立てられたり、投資の妥当性(そのプロジェクトをやる意味があるのか)などがわかります。

確定見積もりは、実際にプロジェクトを行う時に必要な、最終的に確定した見積もりのことです。

■見積もりの不確実性

見積もりは不確実なものです。
プロジェクトの大きさにもよりますが、初期段階の見積もりは実際のコストに対して0.25倍~4倍程度の誤差が生まれます。

多くの場合、納期の見積もりは過小見積もりである場合が多く
開発者自身が見積もりを行う場合においてその傾向が強いと言われています。

認知バイアスとは

例えばあなたが以下のような質問をされたとします。

「だいたい5日くらいで作れる?」
「だいたい100万円くらいで作れる?」

このような質問をされると最初に出された数字(アンカー)に近づくバイアスがかかってしまいます。

その数字で実現しようとする力が働き、過小見積もりをしてしまうのです。

このことを「アンカリング」と呼びます。

このような間違った見積もりを避けるための手法として、
チームメンバーでバラバラに見積もる方法があります。

■よく使われる見積もり手法

以下のように、タスクや要件の難易度をポイント化(重み付け)して見積もる方法が主流です。

ファンクションポイント法

それぞれのタスクを難易度によってポイント付けをし、それを集計して見積もる。
また、ユーザーから見た機能を5種類に分類して集計する。
f:id:ryokwkm:20160725010354p:plain

それぞれ
内部論理ファイル(ILF):アプリケーション内部にあるデータ
外部インターフェースファイル(EIF):アプリケーション外にあるデータ
外部入力(EI):アプリケーションの外部からデータや命令を受け取って行う処理
外部出力(EO):アプリケーション外部にデータを出力
外部紹介(EQ):アプリケーション外部に対して、データ照会(検索など)結果を出力する処理

このようにあらかじめ定義しておくことで、恣意性が入らず制度の高い見積もりが多いという調査結果があります。

ユースケースポイント法

システムのユースケースを複雑度に応じてポイント化し、集計する方法

f:id:ryokwkm:20160725011420p:plain

COCOMOⅡ法

見積もったシステムの規模から、費用・納期を見積もる手法
システムの規模と工数は比例関係にないという知見から、さまざまな工数変動要因を取り込むモデルを提示している

f:id:ryokwkm:20160725011834p:plain

CoBRA

定量的なモデルと熟練者の意見を取り込むハイブリッドな見積もり方法

【Swift】iOSの通信について【GET, POST】

iosで通信処理を実装する方法です。

Androidですと、
threadを作って、そこに通信処理と、コールバック関数を無名クラスで作成したりしますよね。

ではiOSではどうなんでしょう


◆一番単純な書き方

class ViewController: UIViewController {

    override func viewDidLoad() {
        ....

        //urlを生成
        let url:NSURL = NSURL(string:"http://xxx.com")!

        //リクエストを生成
        let request:NSURLRequest  = NSURLRequest(URL: url)

        //リクエストを投げる self.getHttpはレスポンス取得後の処理
        NSURLConnection.sendAsynchronousRequest(request, queue: NSOperationQueue.mainQueue(), completionHandler: self.getHttp)

    }

    //レスポンス取得後の処理
    func getHttp(response:NSURLResponse?,data:NSData?,error:NSError?){
        print( NSString(data: data!, encoding: NSUTF8StringEncoding)! );
    }

NSOperationQueue.mainQueue()部分がThread部分です。
Androidのように自分で作る必要はなく、あらかじめ用意されたキューを指定します。
この場合はメインスレッドを指定しています。


◆1つの関数内で完結させる

また上記の書き方ではコールバックを別の関数として書いていますが
Swiftの場合、無名関数で書くことが出来ます。

こんな感じ

let url:NSURL = NSURL(string:"http://xxx.com")!
let request:NSURLRequest  = NSURLRequest(URL: url)

NSURLConnection.sendAsynchronousRequest(request, queue: NSOperationQueue.mainQueue(),
    completionHandler: {(response:NSURLResponse?, data:NSData?, error:NSError? ) in
        
        print(NSString(data: data!, encoding: NSUTF8StringEncoding)!)
    } )


◆POST通信

NSURLRequestの代わりに、NSMutableURLRequestを使用するとPOSTを送ることができます。

let query = "param1=1&param2=abc&param3=test"
let url:NSURL = NSURL(string:"http://xxx.com")!
let request = NSMutableURLRequest(URL: url!)

request.HTTPMethod = "POST"
request.HTTPBody = query.dataUsingEncoding(NSUTF8StringEncoding)

NSURLConnection.sendAsynchronousRequest(apiRequest, queue: NSOperationQueue.mainQueue(),
    completionHandler: {(response:NSURLResponse?, data:NSData?, error:NSError? ) in
        
        print( NSString(data: data!, encoding: NSUTF8StringEncoding)! )
    } )


以上です。
Androidに比べてスマートに書くことができますね。