このエントリーをはてなブックマークに追加

2016年12月6日火曜日

【Git】マージコミットを消したい

こんにちは、Taroです。
今回はGitのケーススタディ的なものを書きたいと思います。
反面教師として利用してください。

例えば、下図のようなことってないでしょうか?


同じ開発ブランチで、既にリモートブランチが進んでいると、「プルしなさい」と怒られてしまいます。
ここで「git pull --rebase」を使用すれば、マージコミットもできず、綺麗にリモートを取り込めます。
「git pull」と「git pull --rebase」の違いはこちらのサイトで紹介されております。

ただ、頭が弱い私はrebaseオプションを付け忘れ、ふつうにpullしてしまいました。
そうすると、下図のようなブランチになります。

このマージコミットが非常に邪魔です。
コミットを巻き戻すときには「reset」や「revert」が使用されるかと思います。
「revert」だと「消したというログができてしまうため、「reset」を使用します。
「reset」にも大きく2種類あり、コミットと一緒に変更したファイルまで消してしまうhardオプションと、変更したファイルは残しておくsoftオプションがあります。
ケースバイケースで使い分けるとして、今回はsoftオプションでコミットだけ消し、rebaseしたいと思います。

# マージコミットをなかったことに
$ git reset --soft
# 自分のコミットをなかったことに
$ git reset --soft
# 1回stashで逃がす
$ git stash save "テンポラリ"
# rebaseして綺麗な状態に
$ git rebase origin/ブランチ名
# stashした差分を取り込む
$ git stash pop stash@{0}
「reset」を2回やって巻き戻していますが、1回でも良いかと思います。
これで、Bさんはローカルブランチを修復できましたとさ。
めでたしめでたし。
(このようなケースでもっとスマートな方法があれば、ぜひ教えてください!!)





2016年12月5日月曜日

新型MacBook Pro(Late 2016)使用レビュー

こんにちは。h_ono_222です。
先日、新型MacBook Pro (15-inch, Late 2016) 15 inchモデルが届きましたので、3日間使ってみた感想を軽くまとめようと思います。

1. 仕様

購入したモデルのスペックは下記の通りです。

ディスプレイ15.4インチ(2880 × 1800)
プロセッサ2.7GHz Core i7(4コア)
グラフィックRadeon Pro 455(2GB GDD)
メモリ16GB
ストレージ512GB
重量1.83kg

2. サイズ比較

下の写真はMacBook Pro (13-inch, Mid 2012)モデルとの比較です。


1枚目の写真の通り、2012年の13インチ版(非Retina)とのサイズの差はわずかで、開封した時は間違って13インチ版が送られてきたのかと勘違いしました。

また、厚みも非常に薄く重量的にもなんとか持ち運びできます。
(ちなみに前モデルの重量は13インチ版で1.58kg、15インチ版で2.04kg)

3. Touch Bar

スリープから復帰した際など、Touch Barの右端をタッチするだけでパスワード入力なしにロックを解除できます。


下の画像はSafari、Xcode(実行中)、Finder(未選択)、Finder(表示切り替え)画面でのTouch Barの表示です。


基本的には、画面内のボタンと同じアイコンが表示されています。
まだ使い始めて間もないので、Touch Bar?フーン…という感じ(音量操作などは2タップしなければならないので若干面倒)なので、今後のアップデートに期待です。

4. 気になる点

現状殆ど不満はありませんが、一点気になることはキーの打鍵感です。
ストロークが浅く、パコパコとした感覚で、音も大きい?です。

5. おまけ

下記に13インチ版と15インチ版の簡易な比較を載せました。少しでも購入を検討されている方の参考になれば幸いです。

13インチ版15インチ版
ディスプレイ13.3inch15.4inch
プロセッサ2コア(低電圧版)4コア
グラフィックスCPU統合Radeon Pro(+CPU統合)
重量1.37kg1.83kg

13インチ版と15インチ版とで大きく異なるのはディスプレイ、プロセッサ、グラフィックだと思います。
ディスプレイは言わずもがななので割愛します。プロセッサは13インチモデルは低電圧版となります。
ですので、13インチ版のカスタマイズ(特にCPU)をするくらいなら、思い切って15インチ版を購入することをお勧めします。

ちなみに、15インチ版の最下位モデルのCPUの共通L3キャッシュは6MBで15インチ版の他のモデルと比べて2MB少なくなっています(体感速度は変わらないかもしれませんが一応)

また、最新の第7世代であるKaby Lakeではなくその前のSkylake(13インチ版はBroadwell)です。
現状、不具合もあるようですし、待てる人はマイナーチェンジ版を待つのもいいと思います。

6. 参考

2016年12月4日日曜日

はじめの一歩 -Rails 時間・タイムゾーン編-

どうも、はじめです。
本日から「はじめの一歩 -時間・タイムゾーン編」ということで、
何度かに分けてRailsの時間・タイムゾーンについての記事を連載していきます。

今回の内容は「strftime」についてです。

はじめに

strftimeとは、

Rubyの組み込みオブジェクトとして用意されており、
時刻を指定したフォーマットに沿って文字列へ変換してくれるものになります。


time = Time.now # Sun Dec 03 16:06:18 +0900 2016
time.strftime('%Y年%m月%d日 %H:%M:%S')
# => 2016年12月04日 16:06:18

それではフォーマットについて見ていきたいと思います。
今回は例としてTime型での実行結果をまとめてみました。

フォーマット


フォーマット説明実行結果
%Y西暦を表す数 2016
%y西暦の下2桁16
%m月を表す数字(01-12)12
%B月の名称(January,February,March,April,May,June,July,August,September,October,November,December)December
%b月の省略名(Jan,Feb,Mar,Aprl,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)Dec
%d日(01-31)04
%x日付 ('%m/%d/%y')と同じ意味になります12/04/16
%j年中の通算日(001-366)339
曜日
%A曜日の名称(Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday)Sunday
%a曜日の略称(Sun,Mon,Tue,Wed,Thu,Fri,Sat)Sun
%w曜日を表す数。日曜日が0(0-6)0
%U週を表す数。最初の日曜日が第1週の始まり(00-53)49
%W週を表す数。最初の月曜日が第1週の始まり(00-53)48
%H24時間制の時(00-23)16
%I12時間制の時(01-12)04
%M分(00-59)06
%S週秒(00-60)(60はうるう秒)18
その他
%c日付と時間"Sun Dec 4 16:06:18 2016"
%p午前または午後(AM,PM)PM
%X時刻"16:06:18"
%ZタイムゾーンJST
%%パーセント%

下記はオプション一覧です。


オプション
フォーマット説明
^大文字で出力
#小文字は大文字に、大文字は小文字に変換
-左寄せ
_空白埋め
00埋め
数値指定した表示桁数での表示

オプションを幾つか組み合わせて実行した結果がこちらになります。
桁数指定をしている状態で左寄せを行うと通常と同じ表示になるようです。

time.strftime('%^10A') # => "    SUNDAY"
time.strftime('%0#6Z') # => "000jst"
time.strftime('%Y/%-m/%-d %X') # => "2017/1/4 16:06:18"
ちなみに、、、
曜日を日本語で表示したいときは以下のように書きます。
Time.now.strftime("#{%w(日 月 火 水 木 金 土)[Time.now.wday]}")
# => 日

まとめ


年月日、曜日、週に関してはTime型、Date型、DateTime型、TimeWithZone型のどれであっても
表示される内容は同じでした。
ですが、時刻やその他のフォーマットに関してはデータ型によって出力内容が異なってきます。
実際に使用する際には、一度想定通りに表示されているかを確認してから使用する用にしましょう。
(今回の時刻、その他の項目に表示されている実行結果はTimeWithZone型となっております。)

次回


今回の最後に出てきましたデータ型について、
時刻だけでも幾つかのデータ型がありますのでそちらをやってみようと思います。

2016年12月3日土曜日

2016年12月2日金曜日

「実行の4つの規律」について考えてみた

こんにちは、Taroです。
私の中で、昨年のブックオブイヤーは「7つの習慣」でした。
(あの当時で今更感はありましたが。。。)
その「7つの習慣」を組織で実行するテーマの「4つの規律」という本が出たようなので、今回題材にしました。

そもそも4つの規律って?

  1. 最重要目標にフォーカスする
  2. 先行指標に基づいて行動する
  3. 行動を促すスコアボードをつける
  4. アカウンタビリティのリズムを生み出す
分かるような分からないような。。。
本に記載されている内容を一部引用しながら、例としてあげると、
  • あるプランニング会社が、今年度の売上を1億円から2億円にあげることを決めた。(最重要目標
  • これを受けて、その目標を達成するためには、高いプランを選択してれる顧客を20 %増やす必要があった。(遅行指標
  • 20 %増やすために、1人1人の目標として「高いプランを勧める営業を毎日2件行うこと」とに決めた。(先行指標
  • 各人が見える場所に、目標と実績を分かりやすい図で掲示した。(スコアボード
  • 毎週必ず1回、この件に関するMTGを行い、進捗と先行指標の修正を行った。(アカウンタビリティ
遅行指標とは、先行指標を行った上での結果と書かれています。
例えば、車が故障する頻度を下げる、という目標は私たちでは関与できません。ただ、車を整備に出すことは私たちの意思で決めることができます。

じゃあ4つの規律でどんな組織を作りたいの?


本にはいろいろ記載がありましたが、私が考えるに、ボトムアップ型の組織だと思っています。
ある程度目標が明確になれば、主体的に考え、意見なども言うことができるようになるかと思います。
本の中で印象的であったのは、レガッタとラフティングの話です。
高度経済成長期のような変化が(今に比べて)乏しいときは、リーダーに合わせて漕ぐことが重要です。
ただ、現代のような、何が起こるかよく分からないような時代では、リーダーはいるにしろ、個々人で判断する機会が増えます。
組織的な動きは当然として、各々でも考えることができる組織を作りたいのかな、と思っています。

技術屋にとっての4つの規律

一概に技術屋といっても様々な職種が存在します。
今回は「製品、サービスを完成させ、納品すること」が業務上の目標である場合を想定します。

  • 最重要目標:自部署、自チームの売り上げアップ(期間と増加幅は省略)
  • 遅行指標:ある製品を納品すること
  • 先行指標:製品の工程を週単位で分割できるところまで落とし込み、その工程が終了したかどうかを指標とする
製品を納品することは、間違いなく売上に貢献できることだと思います。
とはいえ、これは結果なので、コミットできる先行指標が必要です。
これはあくまで私の考えですが、製品の工程を分割して、指標とすれば良いのかな、と思います。
1週間で2つの工程を完了させることを各々のコミットメントとし、スコアボードを作ります。
幸い、そのようなタスク管理系のアプリケーションはたくさんありますし、エクセルで簡単な図を作っても良いかもしれません。
そして、週1回のMTGで進捗報告、および案外手間がかかりそうな工程に関して共有、軌道修正を実施していきます。
あくまで私が考えた一例ですが、漫然といついつまでに完成させる。。。と考えるよりもメリハリがつくのではないかな、と思います。

4つの規律よりも7つの習慣?

4つの規律はどちらかというと管理職、マネジメント職の方向けの本という印象です。
組織の中にいかにルールを作るか、という感じですが、個人向けというと7つの習慣の方がしっくりくるかもしれません。

本の中でも、ビジネスパーソンは木である。根っこに人格(7つの習慣)があって、その上に組織の規律(4つの規律)という幹があり、スキルという葉っぱを茂らせているようです。
良い機会なので、7つの習慣も再読し、歯をみがくかのごとく、良い習慣を根付かせていきたいと思います。