Git で特定のコミットからブランチを切りたい（作成したい） - Qiitaあるブランチにコミットしていって、「あ、やっぱりこのコミットハッシュの時点のソースをいじくりたいなあ」と思うときがあると思います。 そのままチェックアウトすると無名ブランチに迷い込んでしまうのでブランチ名を指定してチェックアウトします。 コミットハッシュの一部を指定して feature/some-function というブランチを作成する例です。 特定のコミットをチェックアウト
はてなで実践している社内コミュニケーション方法 - Hatena Design Group
こんにちは。はてな デザインチームの id:ueday です。 どうしたら会社（あるいはチーム）でのコミュニケーションを円滑に・楽しく行うか、というのは常に悩みどころですよね。私達も今までに色々なツールや方法を試していて、日々ベストプラクティスを探しているところです。 この記事では、はてなで実践している社内コミュニケーション方法についてご紹介しますが、常に試行錯誤しているので、これが最適、とは言い切れないところがあります。現時点の方法としてご紹介したいと思います。 東京・京都の2拠点を繋ぐ はてなでは、京都と東京の2拠点で開発をしています。そこで活躍するのが、「ポリコム」というテレビ会議システムです。打ち合わせや朝会はこのポリコムを通じて行うので、物理的な距離を感じずにコミュニケーションがとれるのです。詳しくははてなのカルチャーをご覧ください。 カルチャー - 株式会社はてな メールは使わ
スタートアップが採用でつまづく意外な理由 - sudoken Blog
これは、自戒を込めてのエントリー。 なんで採用がそんなにうまくいっているんですか？と聞かれることが増えました。 うまくいってるという風に言って頂けるのは嬉しいですし、 とてもいいチームになってきていますが、 採用においてはもっと頑張らないとと正直焦っているのが本音です。 なので、採用に関する勉強会はなるべく参加し、 西にいい人がいると聞いたら飛んで行き、 東に凄い人がいると聞いたらお茶をする。 少し時間が空いていると聞いたら、すぐに飛んで行ってます。 相手がビビるくらいのスピードで。 それほど採用を死ぬ気でやっています。 なぜ、死ぬ気でやるかというと採用しないと死ぬと思ってるからです。 単純です。 我々には、できないことがたくさんあると強く認識してるからです。 その問題を解決しない限り、事業が成長しないと確信してるからです。 我々の中に解決策を持っていない問題が、我々にはたくさんあります。
ピクシブでの開発 - 金髪の神エンジニア、kamipoさんに開発の全てを教わった話
爆速で成長していた、ベンチャー企業ピクシブ 面接の時の話はこちら=>ピクシブに入るときの話 そんな訳で、ピクシブでアルバイトとして働くこととなった私は、初出勤の日を迎えた。 （↑ピクシブのユニークなオフィス） ほぼ何も分からず始まった開発 プログラミングスキルはほぼ無く、やることも決まっていなかった私は、早速開発の統括をしていたCTOの青木さんからの指示を仰いだ。
QiitaやKobitoの開発フローと，それを支えるサービス一覧 - Qiita Blog
こんにちは，yaottiです． 前回はQiitaやKobitoを作る開発チームの文化について書きましたが，今回は具体的にどういうツールを使いながら開発しているのか，また開発の雰囲気などを紹介します． QiitaやKobito開発で利用しているツール，サービス一覧 Trello: 開発以外のタスクや仮説の管理Pivotal Tracker: 開発ストーリー管理GitHub: ソースコードのホスティング，レビュー，ディスカッションCircle CI: CI環境Sentry: エラーの補足&通知New Relic: パフォーマンス改善用の測定Amazon Web Services: インフラ(EC2, RDS, ElastiCache)コミュニケーションSlack: チャットQiita Team (& Kobito): テキスト共有&ディスカッションその他Mixpanel: イベント計測Goog
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
「取材記事は発表前に確認させてください」？時代遅れな広報パーソンに物申す｜まだ仮想通貨持ってないの？
これからの情報発信アプローチについて考えることがあったので、書き落としておきます。 「広報確認」という時代遅れの考え方 ぼくは取材記事を書くことも多いんですが、基本的に「広報確認」という作業が発生しないようにしています。必要に応じてインタビュー対象者に原稿を「こちらから」ご確認いただくことはありますが、基本は確認なしで発信させていただくのが前提ですね。これまでそう大きなトラブルは起こしていません。 で、特に大きな企業だと、インタビューをする際に「広報確認」が必須だったりするんですよね。「インタビューするのはいいですが、まずはできあがった原稿を見せてください。あと画像素材もすべて。広報に確認します」的な。 これがライターとしては非常にだるい。先方に何の悪気はなくても、げんなりします。「ここはオフレコでよろしく」と、注意点を口頭ベースで伝えてくれれば、それで十分じゃないかなぁ、と思ってしまうわ
グアルディオラのバイエルンのお話 - pal-9999のサッカーレポート
さて、皆さん、こんにちは。先日、CL決勝ラウンド一回戦が行われまして、バイエルン対アーセナルの試合がありました。内容的には、途中でアーセナルのGKのスチェスニーが赤紙＋PKで退場食らってしまい、そこからは一方的な展開になって、バイエルンが２－０で勝ってます。アウェーで２－０なんで、ほぼバイエルンの勝ち抜けは決定ですね、こりゃ。 でもって、なんでペップバイヤンの話を急にする気になったかというと、 戦術大国イタリアが脅威の分析「ペップ・バイエルンはたった1つの練習しかしていない」 こいつのせいです。 これは、先日発売された「欧州サッカー批評」の記事でして、 欧州サッカー批評(9) (双葉社スーパームック) 作者: 第一書籍編集部出版社/メーカー: 双葉社発売日: 2014/02/13メディア: ムックこの商品を含むブログを見る この中にバイヤンの分析が入ってたからです。内容的にはグアルディオラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TiShadow with ACS · Issue #41 · dbankier/TiShadow