Redirecting… Click here if you are not redirected.
Redirecting… Click here if you are not redirected.
こんにちは、ツカノ(@snuffkin)です。 先日、Google Codeが2016年1月に閉鎖されると発表されました。 長年使っており残念だ、と言う方もいらっしゃると思いますが、時代の流れでしょうか。 Google Codeにホスティングしている方は、忘れないうちにGitHub等への移行が必要です。 幸いにもツールが用意されているため、いくつかの制約を許容すれば、3分で移行できます。 そこで、今回はGoogle Code上のコードをGitHubへ移行してみましょう。 実際に、移行してみましょう ここでは、Google Codeにある「mibible」というプロジェクトを例に説明します。 事前に、Google Code、GitHubにログインしているものとします。 それではまず、移行したいGoogle Codeのページに行きましょう。 すると、「Export to GitHub」というボ
rebuildfm 67にNaoya Itoさんが出るというので、もしかしたらHow Google Worksの話が出るかと思ったらでなくて残念。でも別の機会に話してくれそうなのでそれを楽しみに待ちます。 How Google Works 作者: エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル,ラリー・ペイジ出版社/メーカー: 日本経済新聞出版社発売日: 2014/10/17メディア: Kindle版この商品を含むブログ (7件) を見る この本ですが、僕はちょっと前に読了しました。注釈が20%を占めていて、この手の本にありがちなんだけどカタカナが多い。 で、内容的には、、、正直に言ってしまうと期待していたほど面白くなかった。 一番面白かった部分はAPMというあるポジションに登用したかったけどコンピュータ科学の学位を持ってなかったためそれが出来なかった優秀な社員がいた。
2014-09-11 社内クローズドなリポジトリをGitHubに公開するのは色々つらいけど、おかげで色々解き放たれた件 Github Maven Scala どうもこんにちは 先月AeromockをOSSとして公開しましたが、もともとこれは社内のGithub Enterpriseにあったリポジトリで、OSSとして公開するためには色々と紆余曲折がありました。というわけでクローズドなリポジトリをGitHubに公開するまでにやったことをまとめてみます。 概要 リポジトリはAmeba内のGitHub Enterprise Scalaで書いてて、ビルドはsbt サブプロジェクトだけ一部Gradleプロジェクト 成果物（Jar）は社内クローズドなnexusにディプロイ ドキュメントは全てAmebaのCofluenceに書いてた（社内限定情報含む） Mavenリポジトリ OSS化前は、社内のクローズドな
これです。 ちゃんと社労士チェックを入れて、2014年時点の法運用Validな感じにしてあるので、下手な中小企業はおろか、ろくにメンテされていない大企業の就業規則よりマトモな内容になっているはずです。 なんで就業規則を公開したのか マトモな規則が作ってあれば公開しても特にデメリットはない むしろマトモな会社アピールができてよい 個人的には「無限RedBullです！！！！」みたいな事をアピールする会社よりマトモな広報・求人活動の一環だと思っている 自分で就業規則を作ろうにも、良いサンプルがなかった（後述あり） いわゆるOSS的な話。就業規則にも再利用性が合っても良いはず これを書いてて、就業規則にライセンスを明示するのを忘れていたことに気が付いた GitHubだと、就業規則の改定にプルリクを飛ばせて楽しいし、改定履歴も一目瞭然 零細企業に就業規則って要らないんじゃないの？ 従業員が10人未満
「Working In Progress」な WIP Pull Request という概念を知ったのでメモ。 【元ネタ】 Github を使って雑誌原稿を書く - naoyaのはてなダイアリー git commit --allow-empty を使った WIP PR ワークフロー - Qiita WIP (Work in Progress) な Pull Request を目立たなくする Chrome 拡張をリリース - @kyanny's blog 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog github を用いた開発フロー テンプレート pull request を利用した開発ワークフロー // Speaker Deck 「Working In Progress」な WIP Pull Request とは、ソースの
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
2014年6月1日（日）、東京・渋谷マークシティにおいて、GitHubユーザグループ主催によるイベント「GitHub Kaigi」が開催されました。500人の定員に対し800人を超える参加申し込みのあったこのイベントには、日本におけるGitHub活用の第一人者たちはもちろん、米GitHub社から招いた開発者たちも登壇し、いずれ劣らぬ濃いセッションが繰り広げられました。ここではその様子を紹介します。 GitHub実践入門 ── Pull Requestによる開発の変革 トップバッターとして登壇したのは、WEB+DB PRESS plusシリーズ『GitHub実践入門 ── Pull Requestによる開発の変革』の著者である大塚弘記氏です。 『GitHub実践入門』の著者、大塚弘記氏 同氏はまず、「GitHubを利用した開発の世界を知る」「GitHubを（利用｜活用）する違いを
We are going to skip instructing you on how to add your files for commit in this explanation. Let's assume you already know how to do that. If you don't, go read some other tutorials. Pretend that you already have your files staged for commit and enter git commit as many times as you like in the terminal box. git branch name will create a new branch named "name". Creating branches just creates a n
The Syncthing Foundation stands for peace and with Ukraine! Read about what we're doing. Syncthing is a continuous file synchronization program. It synchronizes files between two or more computers in real time, safely protected from prying eyes. Your data is your data alone and you deserve to choose where it is stored, whether it is shared with some third party, and how it’s transmitted over the i
Gitterに感動した 金曜にメールチェックしてたら「Gitterが一般βになったから誰でも参加できるようになったよ」ってメールが届いてた。 確か以前は抽選かなんかだったんだけど、アイディアがちょっと面白いなーと思って参加できるようになったらメールでお知らせしてもらおうと登録してたんだけど。 Gitter - Chat, for GitHub 早速、試してみたんだけど…久々に感動するレベルのWebサービスでした。 そもそもこのサービス何なのか知らない人が大半だと思うんで、ちょっと説明するとこんな感じです。 GitHubのリポジトリやOrganization単位でチャットルームを作ることができる まあ、これだけなんですが。WebアプリとMacアプリがあってiPhoneとかのモバイル対応はまだらしい。とはいえ、Webアプリの方をMobile Safariなんかで見たらそこそこ見やすい感じではあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
