git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか？ この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴

はじめに これは Git Advent Calendar 2016 の4日目の記事です。 今回の記事が対象とする大規模なレポジトリは、何年間も開発が続けられ、ファイル数、履歴、ブランチ、タグなど、全般的に肥大化してしまったようなレポジトリです。肥大化したレポジトリを何も気にせず扱った場合、以下のような不幸な自体に見舞われます。 終わらない git clone 止まらない disk full 帰ってこない git status これらは貴重な時間や資源だけでなく、エンジニアや周りの人の精神エネルギーまで持っていきます。 この記事においては、これらの原因を解決するための実践テクニックのうち、明日から利用できるものをまとめます。歴史を改ざんする系のもの、レポジトリ構成を変えるもの、アプリケーション層に入り込んだ改修などは今回の記事の範囲から割愛させていただきます。 また、巨大なレポジトリを扱うた

gitが大きくなると時間かかってしゃーないと思っていたら、ちょうどatlassianのブログにこんな記事があった。 How to handle big repositories with git - Atlassian Blogs 巨大なリポジトリ を Git で上手く扱う方法 直訳ではなく、読んだことを参考に自分用にメモを記す。これは本当にメモ代わりなので原文を参照した方がいいと思う。 gitが重くなる原因は、「長い歴史」と「デカいファイル」の2つがある。その2つの対処法。 長い歴史に対処する shallow cloneを使う gitのhistoryが積み重なると、git cloneに時間がかかる。そのときはshallow cloneを使って、深さを限定してcloneする。 git clone --depth depth remote-url 手元の環境だと23sくらいかかっていたのでも

gitアカウントが煩雑 日々の業務や個人の開発などのバージョン管理において、gitは外せない日々が続いております。 ただ、使うgitアカウントが煩雑しております。。 社内管理は、gitlab 他社管理は、bitbucket 個人の開発は、github などなど。。 ここで、それぞれのアカウントを分けないと、「他社管理のリポジトリ」に「社内管理で使っているハンドルネームでコミット」してしまい、トラブルなどの原因に繋がったり、恥ずかしい思いをしてしまいます。。 メインアカウント設定 業務で良く使うアカウントは、globalにアカウント情報を設定する。(~/.gitconfig) ~/.gitconfigへ設定 $ git config --global user.name "メインアカウント" $ git config --global user.email "メインアカウントメールアドレス"

はじめに SVNが使用されている現場でも、自分のローカル環境だけはGitを使う事ができます。 Gitは分散型リポジトリなので、リポジトリがローカルとリモートに分かれています。この特性を利用して、リモートリポジトリにSVNを使用したまま、ローカルのみGitのリポジトリを導入する事ができるのです。 この記事では、そんな環境を作るための手順と、運用していく上での注意点を記載します。 自分だけGitを使おうとした経緯は、↓の記事に書いてますので、こちらも見てみてください。 SVNな現場に何も問題を感じていなかった俺が、自分だけGitを使ってみることにした理由 完成イメージ ↓こんな感じの運用を想定します。 リモートリポジトリは、プロジェクトでずっと使っているSVN。これはそのまま残し、自分以外のチームメンバは従来通りSVNを利用してコミットしてもらいます。 一方、自分のPCにはGitをインストール

- はじめに - 最近はWebスクレイピングにお熱である。 趣味の機械学習のデータセット集めに利用したり、自身のカードの情報や各アカウントの支払い状況をスクレイピングしてスプレッドシートで管理したりしている。 最近この手の記事は多くあるものの「～してみた」から抜けた記事が見当たらないので、大規模に処理する場合も含めた大きめの記事として知見をまとめておく。 追記 2018/03/05： 大きな内容なのでここに追記します。 github.com phantomJSについての記載が記事内でありますが、phantomJSのメンテナが止めたニュースが記憶に新しいですが、上記issueにて正式にこれ以上バージョンアップされないとの通達。 記事内でも推奨していますがheadless Chrome等を使う方が良さそうです。 - アジェンダ - 主に以下のような話をします。 - はじめに - - アジェンダ

たとえば、shared_secretが"abcdef"でタイムスタンプが"1545315685"の場合、 “abcdef1545315685"をsha1ハッシュすればいいということです。 $ echo -n "abcdef1545315685" | sha1sum e4d673a71b769782541920b7acfcee92a686b91c - 認証 プライベートなデータを取得するような一部のAPIでは、上のバリデーションとはべつに、 認証でusernameとpasswordが必要です。 get_slideshows_by_user APIを使ってみる では実際にget_slideshows_by_userを、まず手作業で実行していきたいと思います。 このAPIでは公開情報のみ使うので認証は必要ありません。 必須パラメータはusername_forのみなので、取得したいユーザの名前だけ

MySQLのdatetime型はそのままSELECTすると、 2013-05-15 13:45:59 のように表示されてしまいます。 yyyy-mm-ddではなく、yyyy/mm/dd がいい場合もあります。 DATE_FORMAT関数でフォーマットします。 使用できる指定子は以下の通りです。 %M 月の名前（January..December）。 %W 曜日名（Sunday..Saturday）。 %D 英語のサフィックス付きの日付（0th、1st、2nd、3rd など）。 %Y 4 桁の数値で表した年。 %y 2 桁の数値で表した年。 %X 日曜日を週の最初の日とした場合の週に使用する、4 桁の数値で表した年。%V と組み合わせて使用。 %x 月曜日を週の最初の日とした場合の週に使用する、4 桁の数値で表した年。%v と組み合わせて使用。 %a 略式の曜日名（Sun..Sat）。 %d

タイトルの通り MySQLのChar型は”(ダブルクォーテーション)ではなく'(シングルクォーテーション)で囲ってSELECT しなければなりません。 正確には、そうしなければパフォーマンスが大幅に低下します。 問題は、”(ダブルクォーテーション)でもselectできてしまう点です。 以下のようなテーブルがあったとします。 mysql# desc sample_table; +-------------+---------------------+------+-----+-------------------+-----------------------------+ | Field | Type | Null | Key | Default | Extra | +-------------+---------------------+------+-----+------------