タグ

2017年3月9日のブックマーク (6件)

  • 明晰ではあるが、会社に文句ばかり言っていた人の話。

    Tさんは、都内の有名国立大を卒業し、大手企業に新卒で入社した。 もともと明晰であったため、研修期間中にすでに頭角をあらわし注目されたため、同期からは「出世頭となるだろう」と目されていた。 ところが、配属は彼の希望通りとはならなかった。 人事は彼の希望を考慮はしたが、全体のことを考え「今、彼の能力を一番必要としている部署」に配置をしたからだった。 彼は憤慨したが決定は覆らず、彼のキャリアのスタートは不意なものとなった。 そして研修期間は終了し、Tさんはあるチームに配属された。 チームのリーダーは、中途採用された人物であったが、大きな期待をかけられていた。 前職で大きな成果を出していたと思われていたからだ。 だが実際は、控えめに言っても平凡な人物、悪く言えばリーダーシップに欠ける人物だった。実のところ前職での成果は、単に運が良かっただけ、であった。 配属されてきた彼は、その明晰さですぐにリー

    明晰ではあるが、会社に文句ばかり言っていた人の話。
    s5ot
    s5ot 2017/03/09
  • 「追跡ブランチ」って言うのやめましょう - Qiita

    TL;DR 突然ですがクイズです。「追跡ブランチ (tracking branch)」という言葉の使い方で正しいのはどれだと思いますか? origin/master はリモートリポジトリの master を追跡する追跡ブランチである origin/master はローカルの master に追跡される追跡ブランチである ローカルの master は origin/master を追跡する追跡ブランチである 現在の正解は多分3番です。過去には1番でした。 分からなかった方、分かったけど他人に「追跡ブランチ」と言って伝わるか不安な方。大丈夫です。正確な用語1で言い換えることにしましょう。 origin/master はリモートリポジトリの master を追跡するリモート追跡ブランチ (remote-tracking branch)である origin/master はローカルの master

    「追跡ブランチ」って言うのやめましょう - Qiita
    s5ot
    s5ot 2017/03/09
  • Karma + webpack + TypeScript 2017/2 - Qiita

    Help us understand the problem. What is going on with this article?

    Karma + webpack + TypeScript 2017/2 - Qiita
  • 今さら聞けないgit pushコマンド - Shoichi Matsuda's diary

    id:koogawaさんのgitの記事を読みました。 これを読んでそういえばみんな知ってるのかなと思った点があるので書いておきます。 取り上げるのはgitのpush周りのお話です。 (これ以降の記事中のリモートは全てoriginとします。) このコロンは何?? リモートブランチの削除で以下のようなコマンドを実行すると思います。 git push origin :hoge コロンが付いていますがこのコロン正体、正しく説明できますか? 実用Git 作者: Jon Loeliger,吉藤英明(監訳),間雅洋,渡邉健太郎,浜階生出版社/メーカー: オライリージャパン発売日: 2010/02/19メディア: 大型購入: 7人 クリック: 287回この商品を含むブログ (44件) を見る pushコマンドの実体 普通、ローカルブランチをリモートに反映する際のコマンドはこんな感じです。 git p

    今さら聞けないgit pushコマンド - Shoichi Matsuda's diary
    s5ot
    s5ot 2017/03/09
  • git pullの詳細な挙動を追ってみる - hokaccha memo

    git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう? $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ(master)にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ

    git pullの詳細な挙動を追ってみる - hokaccha memo
    s5ot
    s5ot 2017/03/09
  • どのようにエンジニアの目標設定を行うか - $shibayu36->blog;

    以前 ゴールを決め目標を決める・解決案ではなく質問する - コーチングの学習で学んだこと - $shibayu36->blog; で、「ゴールを決め、現在位置とのギャップを考え、目標を決める」と良いということをまとめた。イメージとしては以下の図の通り。 しかし、前回の記事だと具体的にどのようにエンジニアの目標設定を行うかイメージが湧かない。そこで、もう少し具体的に最近どのようにやっていたかを書いてみたいと思う。 僕がメンティーと目標設定を行うときは、以下のフローを辿っている。 なんでも良いのでゴールのイメージを明確にする 現在の自分とゴールのイメージのギャップを考える ギャップを埋める目標を考え、アクションを定める ちなみに今回は、チームの成果達成のために個人の目標を決めるのではなく、エンジニアのスキル向上の目標を立てるという前提で書いていく。 なんでも良いのでゴールのイメージを明確にする

    どのようにエンジニアの目標設定を行うか - $shibayu36->blog;
    s5ot
    s5ot 2017/03/09