一定期間更新がないため広告を表示しています
宮城交通(仙台市泉区)や同社の関連会社が運行するバスの運転が原因で今年2月中旬までに、前年同月の1か月間と比べ3倍に当たる40件の事故を起こしていたことが13日、分かった。 同社の関係者によると、関連会社を含めた宮城交通グループでは2月に、事故が急増。昨年2月は十数件だったが、今年は2月中旬の時点で既に40件に達した。今年は自損事故や、車内の乗客がけがする事故が多かったという。 事態を重くみた同社は2月下旬、運転手に対し、注意喚起していたが、3月3日、富山県小矢部市の北陸道で死傷者28人を出す高速バス事故が起きた。宮城交通は「事故の多くは確認不足や漫然運転が原因」としている。
昨日、下北沢オープンソースカフェで行われた「静的サイトジェネレーター祭り」にてJekyllについてのセッションを担当しました。 都合によりMiddlemanのセッションはキャンセルされましたが様々なツールについてのナレッジが共有されました。 今ご覧になっているEngine Yardのサイトとブログは元々、RailsアプリケーションとWordPressだったものをJekyllに移行したものです。 JekyllというとやはりGitHub Pagesの印象が強いですが、しっかり使ってみると既存のサイトの移行やEngine Yardのような独自環境でのホスティングにも耐える汎用性の高いツールであると実感しました。 セッションからいくつかハイライトをご紹介します。 GitHub創業者の手によって生まれたブログエンジン Jekyll(じゃこる)は2008年10月にGitHubの共同創業者のmojomb
Docker で開発環境を作る話 こんにちは、Docker 0.9 が出ましたね。 ちょっと Docker を触っていて幾つかアレな点があったので共有しておこうと思います。 その他も合わせてまとめてます。 私の Docker TIPS Docker を使って開発環境、および開発環境の土台を作る まあよくある Docker の使い方って nginx だの redis だのいろんなサーバーを構築する感じだと思いますが。 今回は開発環境を構築する話をしたいと思います。 よく dotfiles なんかを github においてーなんてことやってる方多いと思います。 もうここは思い切って Docker のイメージにしてしまいましょう。 利点 モテる なんかイケてる感じがする 案件、プロジェクト毎に個別環境をクリーンなまま維持できる みんな同じ環境で作業することができる(ライブラリのバージョンなどが揃
Pretty Pull Requests (Github) Chromeウェブストア - Pretty Pull Requests (Github) Pull Request を読むときに便利なエクステンション。 ファイルをアコーディオンで開閉したり、追加された行または削除された行のみを表示することができる。 長い PR を読むときに特に便利。 GitHub Wiki Search Chromeウェブストア - GitHub Wiki Search GitHub Wiki を検索するためのエクステンション。シンプルで使いやすい。 検索語をハイライトしてくれたり、検索中はプログレスバーがでたりと気が効いている。 これを使わずに検索しようとすると GitHub Wiki の git リポジトリをクローンして、 git grep するはめになる。 GitHub.Expandinizr Chrom
php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolutionの対応 PHPのgethostbyname関数で、ドメインからIPを引く場合に次のようなエラーが出ることがあります。 php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution これはPHPからネームサーバでの名前解決ができないときに発生するエラーです。 サーバにSSHやtelnetなどで接続して、nslookupやdigコマンドで名前解決ができないならサーバのDNS設定が間違っています。 もし名前解決ができるなら、apacheの再起動をすることで解決できると思ってしまいますが、再起動では解決しない場合があります。 apac
Table of contents 知っていると便利な辺り grep の検索結果から、その場所へ移動する。 キーワードとかを探す。 開いてるバッファすべてに対して検索 / 置換 ウェブ検索 Google 検索 Grep grep-dialog の拡張 grep 結果からダブルクリックでファイルを開く grep 結果からウィンドウサイズを場合により変更し検索先に移動 grep 結果から読取専用で検索先を開く コマンドラインからディレクトリを開こうとするとgrepになってほしい。 バッファ検索 カレントワードを検索 いろいろ edict 英和をメッセージボックスで 知っていると便利な辺り grep の検索結果から、その場所へ移動する。 F10 (first-error) を押す。次の検索結果へ移動する場合は、 F11 (next-error) 。 前の検索結果へ移動する場合は、C-u F11
最近は、こんな感じでやるといいかなと思っています。 outline masterが中心 masterからbranchを作って作業する 作業が終わったらmasterにmergeする master masterブランチは、常にデプロイ可能である。 テストされていないもの、リリース前のものはmasterにはコミットしない。 masterは他のブランチからmergeすることで更新していき、masterでは作業しない。 branch 機能の開発やバグ修正などは、branchを作成し、そこで行う。 branchはmasterから作成する。 まず、masterを最新の状態にするために、リモートからpullする。 git checkout master git pull origin master 続いて、masterからbranchを作成する。 git checkout -b yourname/feat
rebase 便利だよ、というだけのエントリです。 AA で書いてる部分は時間があれば画像に置き換えます。 rebase とは ブランチを作成した場所を変更することと理解しています。つまり、そのブランチの「親」を変更する、ということです。 もう少し動作に踏み込むと、指定したコミットの後ろに現在のブランチで行ったコミットをリプレイするように適用します*1。単なるリプレイではなく、その過程をいじくれるのが rebase のすごいところです。 単純な rebase はたとえばこんな感じです。 以下のようなリポジトリの状態があったとして (現在チェックアウトされているブランチは dev ということを表すのに * を使っています)、 1---2---3 *dev / A---B---C---D master次のコマンドを実行します。 $ git rebase masterこれにより、リポジトリの状態
はじめに ※ 以前git rebase -i して何か失敗して痛い目にあったりした ※ これ。git rebase master に失敗した模様のとき【git】 ※ でも最近ちゃんとgitを理解し出したので再挑戦したらgit rebase -i がやっぱりイケてる 前提 ※ .zshrc (.bash_profile?) にて、gitのデフォルトエディタを設定しときます .zshrc export GIT_EDITOR=vim ※ あと、念のためローカルbranchは新しく切って試します % git branch * develop master % git branch rebase_test % git branch rebase_test * develop master % git checkout rebase_test ※ ぜんぜん関係無いけど、tigあるとちょっと幸せかも そ
エンジニアの友達にgithubなどgitを使用した共同開発時の豆知識を教えてもらったので、忘れないようにメモしておきます。Thanks, Shawn! マスターとのマージ時には事前にgit rebaseを使う gitを使って共同開発をすると、たまにこんなコミットメッセージを見る機会があるかもしれません。 Merge branch ‘master’ of git://github.com/hogehoge これは、最新のマスターを私のブランチにマージしたわよ、という意味合いのコミットメッセージなのですが、正直いりません。開発者それぞれがブランチとマスターをマージするたびにこのようなメッセージをログに残してしまうと、それだけでコミット履歴を占有し、重要な情報をたどるのが困難になります。 このマージ時のコミットメッセージが発生してしまう原因は、左側の図のようにpull requestを出す前に最
Chapter 1 〜 4 http://d.hatena.ne.jp/koba04/20110114/1294936149 Chapter 5 〜 6 http://d.hatena.ne.jp/koba04/20110124/1295795842 Chapter 7 http://d.hatena.ne.jp/koba04/20110130/1296377653 この章は7章の続きのような感じになっていて、複数人での開発の方法について書かれています。 基本的な流れ 「git clone」する まずはリポジトリをとってきます。 % git clone /path/to/public/myproject.git myproject 「git branch」でブランチを確認する。 「git branch」でローカルにあるブランチの確認が出来ます。最初はmasterだけでmasterが選択され
GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko
チーム開発で Git を使ってから半年ちょい位経ちました。 Git 玄人な人たちに囲まれて開発していたおかげで、そこそこ Git 力がついてきました。 そんな中で、ブランチの統合(マージ)についての考え方が大分固まって来たのでまとめます。 まずは結論から。 統合するブランチ → 統合されるブランチ : 統合の為に使うコマンド ローカル(自分用) → ローカル(自分用) : 適当に ローカル(自分用) → ローカル(リモート用) : merge --squash リモート → ローカル(リモート用) : pull --rebase ローカル(リモート用) → ローカル(自分用) : rebase ローカル(リモート用) → ローカル(リモート用) : merge --no-ff ローカル(リモート用)は、リモートドラッキングブランチからチェックアウトしたブランチを指してます。 要は、git
先日GITを使ってて、ちょっとお粗末なミスをしてしまいました。 今日はそんなミスを犯さないためにやっておくべきことについて書きたいと思います。 お粗末なミス私がやっちゃったミスは、ずばり「コミットグラフ汚し」です。 図のように、「別の人」とのマージコミットをコミットグラフに追加してしまいました。 このときのコミットグラフ マージコミットのメッセージは 「Merge branch 'xxxx' of ....」 「Merge commit 'xxxx'」という本質的でないメッセージになります。 この「マージした」という情報は「自分 <==> ある時点でのコミット」のマージを指しており、チーム全体(リモート)として意識するようなコミットログではありません。 このようなコミットをしてしまったことによって、リモートブランチのコミットグラフの見通しを悪くしてしまいました。 本来はこのようなコミットロ
今までもgithubにpushするためだけにgitは使ってたんだけど、最近他人と共同作業するようになって、真面目にgitを学び始めた。 とりあえず今日わかったこと。 困ったら git reflog しろ! ということで終わりなんだけど、一応以下にメモ的に書いておく。 ツッコミ大歓迎というか、いろいろ教えて欲しいのでむしろツッコンでください。。 自分の作業はこまめにcommitしたいけど、共同リポジトリには意味のある単位でpushしたい こんな風にやればいいのかなという感触を持った。 作業ブランチ(branch1)を作る。 $ git branch branch1 ブランチを切り替える $ git checkout branch1 で、作業ブランチでいろいろ作業してコミットを積み重ねた後、 master に切り替える $ git checkout master 作業ブランチの変更をマージする
svnのときはrevertすればいいのだが、gitではリモートリポジトリにpushするまでのステップ数が多いのでややこしい。各ステップで巻き戻し方が異なるので、使い分けが必要。 この記事でそれらの方法についてまとめる。 最も確実な方法 ローカルリポジトリの変更を完全に破棄して構わない場合、リモートリポジトリから git clone し直すのが最も確実である。 これはたぶん、最後の手段になる。 ただこれだとpushは取り消せないので、そのやり方は後述する。 ローカル編集を消したい。 まだaddすらしていない状態だけど、行った変更を取り消したい。 そんなときは以下を打つ。 git checkout <path><path>にディレクトリを指定すれば、再帰的にcheckoutしてくれる。 ワーキングツリーの変更を全部取り消していい場合は、次のコマンドでもいい。 git reset --hard
バックアップ データベースのエクスポートを利用する。 出力するフォーマットは構造とデータを選び、SQLにする。 そうするとデータベースを再構築するためのSQLファイルが作成される。 リストア データベースを削除する。 再度データベースを作成する。 復元するデータベースを選び、SQLタブをクリック バックアップで作ったsqlファイルを指定する サイズが大きければ「結果のページ分割処理を行う」にチェックを入れる 実行する 図入りの解説はこちら http://support.kagoya.jp/manual/pgadmin/export.html http://support.kagoya.jp/manual/pgadmin/import.html
ruby のアプリを動かす時にいちいち bundle exec って書くのがダルい。書きたくない。でもシステムに入ってたり違うバージョンの物が動いて変な動作をされても困る。 どうにかしてこのダルさを解消できないかと考えてみた。 まず rbenv を使ってるなら gem でインストールされるコマンドは必ずシェルのラッパとして生成され、そこから本物が起動する様になっている。例えば rails であれば以下の様なシェルになっている。 #!/usr/bin/env bash set -e [ -n "$RBENV_DEBUG" ] && set -x program="${0##*/}" if [ "$program" = "ruby" ]; then for arg; do case "$arg" in -e* | -- ) break ;; */* ) if [ -f "$arg" ]; th
--------------------------------------------------------------------------- ◆エクスポート方法 --------------------------------------------------------------------------- ・phpPgAdminにアクセスします。 ・左側の画面で→データベース名→スキーマ一覧→public→テーブル一覧→テーブル名を選択します ・右側フレームのエクスポートをクリックします ・オプションSQLを選択するとdump.sqlというファイル名でパソコン上に保存可能です。 --------------------------------------------------------------------------- ◆インポート方法 --------------
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く