いや~、このドット絵と横スクロール! 懐かしいなー!!…あっ、死んだ。 こんにちは、ネルソン水嶋です。 はじめて買ったゲームは「ドラクエ4」と「スーパーマリオブラザーズ3」です。 これは、昨年11月に任天堂から発売された「ニンテンドークラシックミニ」。一見するとファミコンですが、60%ほどのミニサイズ。テレビにつなぐだけで昔なつかしのファミコンゲームが30タイトルも遊べるというゲーム機です。 今はスマホで気軽に外でゲームができる時代ですが、「ゲームは家でやるもの!」というイメージを抱いている方もまだまだ多いのではないでしょうか? かく言う私も小中学校時代はゲーム大好キッズで、放課後に校庭でサッカーに汗を流す同級生を尻目にゲーム漬けの日々を過ごしました。やりすぎで親から叱られ、ゲームを手の届かない場所に置かれた人は私だけではないはず。 「うん、あったあった」と頷いている……(20代後半~40
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く