自分のリポジトリ(git_test1)を作り、まずは普通のコミットメッセージを付けてコミットします。file1次に変なコミットメッセージを付けてコミットします。2000(=日付)」という行が「変な部分」ですが、コミットの時点では特に何も起きません。コミットログを確認します。Abnormal、2つのコミットのパッチを作ります。0000000..e69de29--1.7.10.4こんなパッチができます。am)ができないパッチ適用の前に、パッチを受け取った相手のリポジトリを作ります。history順調です。--abort".このように止まってしまいます。パッチを貼りつけてあることが良くあります。開発プロジェクトのメーリングリストの文面をコピペしたんですね。パッチファイルのヘッダと勘違いして、パッチが変だ、中身が無いよ!と怒っているようです。22:34:51)すずき>たけうちさんお役に立てて良かったです。気づけば当然なのですが、意外と気づかないです...。転記しておくことにした。00:28]コメント一覧コメントはありません。組み込みで勝っているとは言えないけど、なぜだろう。電力/性能比はイマイチかもしれないけど結構速い。売りしたみたいだけど、売れた様子はない。OneもAMDはいってる:2013年末、いよいよ“新生AMD”が新たなステージへ単純な問題ではないのだろうなあ...。転記しておくことにした。00:36]コメント一覧コメントはありません。16日permalink編集するエンジニアならエンジニアを成長させる、たった6つの指針。橋本健太に訊く![前編]一番わかりやすいコミュニケーションは、「動くもの」と「数字」。エンジニアならば、「これだよ」と作って見せてみる。(記事中「議論のための議論はしない〜動くものと数字で示す」より引用)エンジニアなら、ほんとこれしかないと思います。「本番で動くモンはこれ、どう?便利でしょ?」って見せるんです。ここがダメなら、どんな資料も説明も意味無いでしょう?だってテメーの商品のことはわかった、だが気に入らん、と言われてるに等しいのだから。転記しておくことにした。00:39]コメント一覧コメントはありません。「路線がループしているときの運賃の扱いがよくわからん」的なことを書いたら「大回り乗車」を教えていただいたので、ちょっと調べてみました。電車の基本ルールとしては、乗る時に使った切符の範囲外に行ってはいけません。運賃を追加で払う必要があります。駅までの運賃も払う必要がありそうです。駅の切符で乗車できます。ループしている大都市圏には、運賃計算の特殊ルールが存在します。説明によると「実際に乗った経路に関わらず、最も安い経路で運賃が計算される」というルールです。このルールを逆手にとって、1駅分の切符を購入し、出発駅→目的の駅→出発駅の隣接駅、と乗ること(大回り乗車)が可能です。2度通れない(交差はダメなのか??)途中下車できない定期券は使えない(条件ではないが)駅員に乗車経路を聞かれることがあるです。駅から出ない乗り方、例えば電車や駅の写真を撮りたい人、電車に乗るのが好きな人に向いていますね。駅の外に出たい場合には使えませんけどね。鉄道関連の法律ちなみに、不正乗車の罰については、鉄道営業法という古い法律(明治三十三年施行)に述べられているようです。叩きだす」ぞ、わかったかこの野郎。50円(※)の辺りに時代を感じます。2万円になるようです(罰金等臨時措置法)。第十九条)、不正乗車はやめた方が良いですねー。回って東京に戻るのをやったことがあります。さんうは、すごい大回り。私もせっかく大都市圏(大阪)に居るので、景色の良い季節に環状線でやってみようかな。2度通ると不正乗車になります。乗ることはできません。分を払わずに乗っているためです。運賃を追加で払う必要があります。駅で一度降りて再び乗れば特に問題ないですね。乗る方が早く着くことがあるので、嬉しいのです。つくばに居た時の、研究学園駅(車停めたい時の最寄り)とつくば駅(主要)ですとか、今住んでる摂津富田駅(最寄り)と高槻駅(主要)が当てはまります。5〜15分早く着くだけでしょうし、そのために追加運賃と乗り換えの手間を掛けることを考えると効果は微妙...。急いでいる時でない限り、積極的にはやりたくないですね。さん始発駅が隣にある場合、座れるというメリットもありますね。横浜駅→みなとみらい駅の例が載っていました。とお友達ですが、未だに文法やら動きがワケわかりません。俺、この言語向いてないのかなー、なんて思いつつもチマチマと書いています。っぽくない書き方をして後で気づいたり、間違えてバグらせたりで、気づいたら「死んでる...」となっていることが多いです。グチャグチャになる前にテストを書こう、後でリファクタリングするときの役にも立つ、と思い立ちました。メジャーなテストフレームワークについて何も知りません。ようなスタンダードがあるととても助かりますが...。いうのが有名処のようです。「テスト」ではなく「スペック」というようです。私の理解だと「テストのためにプログラムの動作結果の羅列するのはおかしいんよ。振る舞いや期待する仕様を書けばテストになる方が自然なんよー。」というスタイルみたいです。ビヘイビア駆動開発の項)と言うそうです。ような「テスト」から、振る舞いを書く「スペック」まで、何でも出来るようにしてしまったせいで、ゴチャゴチャです。初心者には何を使えば良いか判断がつきません。連携させたいと思います。選ぶ、ほぼそれだけです。結果表示ウインドウに、ツリー状に見やすく配置されます。トリオはなかなか素敵です。結果表示ウインドウにも出て欲しいですが、どう書いたら良いのでしょう??さっぱりわかりません...。1度に動作させるという想定で、思いつく手だてを試してみたいと思います。TEST」という悲しい結果を表示します。シングルトンにしてスペックは関数内に入れ、まとめ用のクラスから呼んでみました。FugaSpec.fugaTest}シングルトンでまとめた結果AllSpec:AllSpec何も出なくなりました。