Gitの使い方を覚えるにあたって、まず知っておきたいのは――git-cloneだのgit-commitだのは当然として――「操作をミスったときにどのように回復するか」である。それを実現するのは、次の３つのコマンドだ。 git-commit --amend git-reset git-reflog git-commit --amend あるファイルをコミットしたとしよう。 $ (edit...) $ git commit -am 'メッセージ生成処理を実装したよ。'しかし、しばらくして彼は気づいた。 def create_massage(param) ...typoしてる！massageじゃない、messageだ！マッサージを作ってどうする！ 慌てるな。まずは直してステージに上げるんだ*1。 def create_message(param) ...$ git add .そして…。 $ gi
整理して表現する 例 基本 表を圧縮する 表を分割する 補完規則 まとめ 整理して表現する 仕様やテスト項目などを文書にまとめるとき、 どのように表現しているでしょうか。 一般に、慣れない人が書くと、 だらだらとした日本語表現になってしまい、 前提条件や実行手順が今一つよくわからない（曖昧になる）、 という状況に陥ってしまうことがあります。 私の周囲でも、 「ユーザからの要求仕様は、物語風で、よくわからない」 と言っている人がいました。 （要求仕様書） の項では、 仕様の曖昧さを解消するための要求仕様の書き方、 表現のしかたについて解説した書籍を紹介しました。 その書籍の中でも少しだけ触れられていますが、 場合によっては、デシジョン・テーブルの形式で表現した方が 明解でわかりやすくなることがあります。 デシジョン・テーブル（ディシジョン・テーブル）は decision table、 つまり
こんにちは。「livedoor 検索」担当の須田です。 今回はデスマーチを防ぐスケジューリングについて書きます。 以前紹介された、「4つのステップで作る webサイト開発のスケジュール作成」という記事も併せて参考にしてください。 みなさんは周囲で、「このお客様は大事なお客様なので、納期早めでお願いします」または、「大型の案件なので早めに作業してください」という声を聞いたことはありませんか？ 仮に、優先すべき案件だとしても、無理なスケジュールで作業を進行することは好ましくありません。 デスマーチ状態に陥るようなスケジュールを作成してしまった場合、ディレクターとして以下のような原因が考えられます。 1）技術者を魔法使いであるという幻想を持っている。 ※これに関しては、「エンジニアは魔法使いという幻想」という記事にも紹介されています。 2）技術者の作業内容について、「結果」は知っているが、「過程
年始の NHK でのイチロー特集番組を見ていて一番印象に残ったのは、他の人の道具を絶対に触らないというイチローのこだわりでした。曰く、人の道具を触るとその道具の感覚が体に残ってしまい、自分の道具を利用するときの感覚の妨げになるから、ということでした。全体を通して、イチローは他のプレイヤーとの相対的な競争の中に身を置いているのではなく、絶えず自分を改良し続けるという過程の中にいるのだというのがよくわかる内容でした。良い番組だったと思います。 気づけば自分も 30 歳になりました。まだ若いとは思っていますが、さすがに 20 代の頃に比べると、病気や怪我の治りが少し遅くなったと感じることもあり、少しずつ自分の人生、「死」ということを考えるようにもなりました。時間は有限ということが少しずつ実感できるようになってきました。あるいは実感できるようになってしまった、と言った方が良いかもしれません。 ここ
こんにちは、小久保です。今回は受託開発事業と自社媒体事業におけるディレクターの意識の違いについて書きたいと思います。 弊社はもともとウェブ関連のSI事業から始まっており、私が入社した5年前もほとんどの仕事がウェブの受託開発・運用でした。 そこから紆余曲折がありながら、現在のメディア事業中心の会社へと変化してきたわけですが、その過程における組織変更はまさに試行錯誤の連続でした。 以前、面白法人カヤックの柳澤社長が「受託開発と自社開発の両立」という記事を書かれていましたが、この記事を読んだときに「やっぱりどこも同じような悩みをかかえているんだなぁ」と激しく共感したことを覚えています。 ところで皆さんは、受託事業と自社媒体事業について一般的にどのようなイメージを持たれているでしょうか？ 弊社が事業シフトの過渡期にあったときに頻繁に出ていた声は以下のようなものでした。 受託 = クライアントに詰め
Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合 → fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
