ラベル Git の投稿を表示しています。 すべての投稿を表示
ラベル Git の投稿を表示しています。 すべての投稿を表示

3.08.2015

Working with Multiple GitHub Accounts

複数のGitHubアカウントを使い分ける

 

モチベーション

  • クローン元のリポジトリによって、接続する GitHub アカウントを使い分ける
  • GitHub アカウントが異なれば、SSH 鍵も異なる
  • Git にコミットする user.name, user.email もアカウントによって切り替えたい

セットアップ

ディレクトリを作成

mkdir -p ~/.git-wrapper/shims
mkdir -p ~/.git-wrapper/ssh

ssh ディレクトリに実行ファイルを作り、SSH鍵との紐付けを定義

#! /bin/sh
exec ssh -oIdentitiesOnly=yes -oIdentityFile=~/.ssh/yourname1.github "$@"
#! /bin/sh
exec ssh -oIdentitiesOnly=yes -oIdentityFile=~/.ssh/yourname2.github "$@"

shims ディレクトリにラッパーシェルを作る。18-26行目は適宜書き換える。

  • ~/.git-wrapper/shims/git

.bashrc または .zshrc で以下のようにパスを追加

export PATH="${HOME}/.git-wrapper/shims:${PATH}"

注意

A-7 無料アカウントを複数作るのは規約違反。

GitHub Terms of Service - User Documentation

 

References

11.06.2014

Cheat Sheets for My Sake

自分向け各種チートシートまとめ

 

自分が忘れがち or 使用頻度の高い事柄だけ書いておく。

12.12.2013

How to Clone a Large Git Repocitory

巨大な Git リポジトリを少しずつクローンする方法

ファイルサイズの非常に大きな Git リポジトリの場合、git clone を行った時に メモリが不足しエラーとなってしまうケースがある。

$ git clone git://xxxxxxxx.xxx:awesome-project.git
Cloning into 'awesome-project'...
remote: Counting objects: 9999, done.
remote: warning: suboptimal pack - out of memory
remote: fatal: Out of memory, malloc failed
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

depth を指定して shallow copy を行うことで解決できる場合がある。

具体的な手順は、以下のブログが参考になった。

4.22.2013

Git: How to Rewrite Author's Name of the Last Commit

Git: 直前のコミットログの「作者」を書き換える

Gitで誤った名前でコミットをしてしまった場合の対応方法のメモ。

ディレクトリ単位のユーザ名・メールアドレスの設定 (--global でも可)

$ git config user.name 名前
$ git config user.email メールアドレス

を行って

$ git commit --amend

としても 前に記録された Author は書き変わってくれない。

$ git commit --amend --author="名前 <メールアドレス>"

とするのが正解。

3.17.2013

Enhancing GitHub Pages with Jekyll

Jekyll で GitHub Pages を拡張する

GitHub Pages には、Jekyll (ジキル) によるHTMLのレンダリング機能が標準で備わっている。
これを利用すれば、GitHub Pages のコンテンツを Markdown で管理することができるようになる。

 

Jekyllとは

静的サイトのジェネレータ。Rubyで実装されている。

Markdown はもちろんのこと、Syntax Highlighting などの機能も持っており、
シンプルな形式のテキストからモダンなHTMLを生成することが容易となる。

 

事前準備

 

Jekyll のインストール

GitHub Pages 上で Jekyll を利用するだけであれば必須ではないが、
動作確認用にまずはローカルに Jekyll をインストールする。 

ruby、gem をインストールの上、"gem install jekyll" を行えばよい。

Install · mojombo/jekyll Wiki

 

Jekyll の概要を知る

こちらの記事が分かりやすかった。

30分のチュートリアルでJekyllを理解する 

 

ローカルでの動作確認

まずは既存のHTMLで Jekyll の動作を確認。ローカルリポジトリのルートで以下のコマンドを実行する。

$ jekyll --server

 その後、ブラウザで http://localhost:4000/ へアクセスし、Webページが表示されればOK。

 

対応手順

 

.gitignore の作成

Jekyllの設定を行う前に、Jekyll の出力ディレクトリを Git 対象外にするため
以下のような .gitignore ファイルを作成する。

.DS_Store
Thumbs.db
*~
_site

 

レイアウトファイルの作成

index.html をもとに default という名前のレイアウト(テンプレート)を作る。
_layouts ディレクトリを新規作成し、その配下に default.html を作ればよい。

$ mkdir _layouts
$ cp -pi ./index.html ./_layouts/default.html

default.html は以下のように編集する。

  • コンテンツ格納領域を {{ content }} に置き換える
        <!-- MAIN CONTENT -->
        <div id="main_content_wrap" class="outer">
          <section id="main_content" class="inner">
            {{ content }}
          </section>
        </div>
  • タイトルを {{ page.title }} などの変数に書き換えてもよい

 

Markdown ファイルの作成

index.html のコンテンツの内容を index.md として Markdown で記述する。

先頭の 3行は、レイアウトを指定してレンダリングを行うために必須の設定。

---
layout: default
---

example
=======

Repository for example

* This is a README file written using Markdown syntax.
* This line is appended.
* Enhanced with Jekyll.

 

ローカルでの動作確認

ローカルリポジトリのルートで以下のコマンドを実行する。

$ jekyll --server --auto

ブラウザで確認し、問題があればファイルを修正する。
--auto オプションを付けると、ファイルを更新してもデーモン再起動不要ですぐに反映が行われる。

 

GitHub へのアップロード

これは通常の Git の手順と同じ。gh-pages ブランチの内容を origin へ push する。

git add .
git rm index.html
git commit -m “Enhanced with Jekyll”
git push

 

作ったもの 

  • example リポジトリ: gh-pages ブランチ
    mogproject/example at gh-pages · GitHub
  • GitHub Pages の URL
    http://mogproject.github.com/example/
  • ファイル構成
    % tree -a -I .git
    .
    ├── .gitignore
    ├── _layouts
    │   └── default.html
    ├── _site
    │   ├── images
    │   │   ├── bg_hr.png
    │   │   ├── blacktocat.png
    │   │   ├── icon_download.png
    │   │   └── sprite_download.png
    │   ├── index.html
    │   ├── javascripts
    │   │   └── main.js
    │   ├── params.json
    │   └── stylesheets
    │       ├── pygment_trac.css
    │       └── stylesheet.css
    ├── images
    │   ├── bg_hr.png
    │   ├── blacktocat.png
    │   ├── icon_download.png
    │   └── sprite_download.png
    ├── index.md
    ├── javascripts
    │   └── main.js
    ├── params.json
    └── stylesheets
        ├── pygment_trac.css
        └── stylesheet.css
    
  • 画面 
    Example 2
    今回は、レイアウトファイル _layouts/default.html にソーシャルボタン (twitter/facebook) も追加してみた。

とりあえず、これで Markdown を GitHub Pages に装備されている Jekyll でレンダリングするという
最低限の目標は達成できた。

あとは _config.yml を作ってグローバルな定義を行ったり
Jekyll Bootstrap や Twitter Bootstrap なりを取り入れていけば、さらに良くなっていくはず。

 

Related Posts

 

References

3.16.2013

Setting Up GitHub Pages

GitHub Pages の開設

リポジトリの GitHub Pages 化を試してみた記録。

 

GitHub Pages とは

GitHub が無償で提供している Webサイトのホスティングサービス。
簡単な手順で、リポジトリを華麗に Webサイトへ変身させることができる。

 

セットアップ前の状態

適当に作った example リポジトリでセットアップを行う。

  • ブランチ構成: master のみ
  • ファイル構成: 
    $ tree -a -I .git
    .
    ├── .gitignore
    ├── README.md
    └── example.py
    

 

セットアップ手順 

 

Options 2

リポジトリの Settings -> Options
-> GitHub Pages -> Automatic Page Generator ボタンをクリック

Create Page  mogproject example

トップページ(index.html)へ適用されるパラメータを定義する。

Load README.md ボタンをクリックすると、Body が README.md の内容に置き換わる

Create Page  mogproject example 2 必要に応じて編集した後、
Continue to Layouts ボタンをクリック
GitHub  Build software better together 2 10種類程度あるテンプレートから適当なものを選択し、PUBLISH ボタンをクリック
 Mogproject example  GitHub

リポジトリの画面に戻る。

表示されているように、GitHub Pages の URL が有効になるには 10分程度の時間を要する。

Mogproject example at gh pages  GitHub リポジトリ内に gh-pages という新しいブランチが作成された。
Example

以下の URL で GitHub Pages へアクセスできる。
実に簡単である。

http://ユーザID.github.com/リポジトリ名

 

セットアップ後の状態

ローカルリポジトリで以下のコマンドを実行すれば、新しいブランチの追跡が可能となる。

$ git fetch
$ git checkout gh-pages

 

  • ブランチ構成: master, gh-pages
  • gh-pages ブランチのファイル構成 (Slate テンプレートの例): 
    $ tree -a -I .git
    .
    ├── images
    │   ├── bg_hr.png
    │   ├── blacktocat.png
    │   ├── icon_download.png
    │   └── sprite_download.png
    ├── index.html
    ├── javascripts
    │   └── main.js
    ├── params.json
    └── stylesheets
        ├── pygment_trac.css
        └── stylesheet.css
    

gh-pages ブランチでファイルの編集を行い、commit, push を行えば即座に Webサイトのコンテンツも更新される。

Git のリポジトリと Webサイトの内容が完全に同期されるという点が非常に便利である。

 Example 2

 

その他のトピック
  • ユーザID と同名のリポジトリを作成し GitHub ページ化すれば
    ドメインルートの Webサイトを構築できるらしい
    (ただし既存のリポジトリ名と同名のディレクトリを作るとよろしくない様子)
  •  Jekyll レンダリングを活用することで、Markdown で簡単にリッチなサイトを作れるらしい
    (別エントリで紹介予定)

 

Related Posts

  

References

2.25.2013

The Twelve Steps of Recovery in Git Phobia

Git 恐怖症を克服する 12 のステップ

「周りでGitを使っている人がいない」「コマンドを覚えきれない」
「エラーが出ても何をすればいいかわからない」など、Git の習得の過程にはいくつか阻害要因が存在する。

以下は、私のような凡人でも Git / GitHub に対する抵抗感をなくすための 12 の処方箋である。
所要時間の目安も記載した。 

 

1. トレンドを知る [5min]

Google トレンド - ウェブ検索の人気度: git, subversion, mercurial, cvs - すべての国, 2004年 - 現在

Google トレンドのグラフは、バージョン管理システムの覇者は誰かを明白に示している。
目指すべき方向性が間違っていないことを確認できるはずだ。

 

2. 英語に慣れる [5min]

Git / GitHub を使いこなすためには、どうしても英語の壁は避けて通れない。
とはいえ辞書があれば英語力がなくても問題ない。英語を見ても逃げ出さない勇気を持てばよいだけだ。

壁の向こう側には果てしなく広い世界が待っている。

 

3. コマンドラインに親しむ [5min]

Git に対応した GUI のツールは数多く存在する。
しかしデファクト・スタンダードがあるわけではないし、不安定なプロダクトも多い。
何より、理解しなくても何となく使えてしまうのが一番の問題だ。(エラーが出てから泣くこととなった私のように)

まずはコマンドラインによる操作で基本を習得するのが、最終的には一番の近道である。

 

4. Git をインストールする [5min]

これがなくては始まらない。
OS に標準でインストールされている場合も、最新バージョンをチェックすることをお勧めする。

 
5. GitHub のアカウントを作る [5min]

Git といえば GitHub。
Git ホスティングサービスを提供し、世界最大のオープンソース開発基盤を作り上げた
GitHub のアカウントを作成する。 

 

6. Git ポケットリファレンス の1章を読む [3h]

Git に関する(日本語の)書籍はいくつか出版されているが、「Git ポケットリファレンス」は
手元に持っておきたい一冊だ。

その第一章「まずは Git を使ってみよう」を読めば、Git の概要を理解できる。

 

7. tryGit をプレイする [30min]

ここからは実際手を動かしていく。

tryGit は GitHub の中にある簡単なチュートリアル。
表示されるコマンドを入力していくことで、Git の利用の流れが見えてくる。

 

8. ドットインストールのレッスンを視聴する [2h]

3分ほどの動画が22回に分かれて置いてある。全て無料で視聴可能。

 

9. githug をプレイする [6h]

ギットハブではなく、ギットハ「グ」。
出題される問題を順番に解いていくことで徐々に  Git に対する理解が深まっていく。

このとき、「Git ポケットリファレンス」の第二章(コマンドリファレンス)が役に立つ。

 
10. Learn Git Branching をプレイする [未実施]

Git のブランチの仕組みをパズル形式で学習できる。

 
11. GitHub Flow を読む [2h]

GitHub の運用にあたってのベストプラクティスが書かれている。

 

12. 入門Git を読む [未読]

タイトルとは裏腹に、中級者向けの本らしい。著者自身が Git 開発者である。

Git の内部仕様や考え方などが書いてあるとのこと。

 

 

やっぱり無理矢理12個も書くのは大変だった。

1.13.2013

Sharing a Personal Eclipse Project with Dropbox + Git [Updated]

Dropbox + Git を使って個人用の Eclipse プロジェクトを共有する

以前のエントリ
mog project: Sharing a Personal Eclipse Project with Dropbox + Git 
の手順を更新。

EGitに頼り切るのではなく、部分的にgitコマンドを活用するほうが簡単なことに気づいた。

 

前提条件

使用する複数のマシン全てで以下がインストールされていること 

  • Dropbox
  • Git
  • Eclipse
  • Eclipse プラグイン EGit
 
凡例

以下、適宜読み替えを行うこと

path_to_dropbox -> Dropbox ディレクトリへのパス
path_to_workspace -> Eclipse のワークスペースのパス 
project_name -> プロジェクトの名前

 

1. 共有リポジトリの作成

最初に、複数のマシンから共有するため空リポジトリを Dropbox 上に作成する。
1つのリポジトリで複数の Eclipse プロジェクトを管理することも可能だが、今回は 1対1 の構成とする。

 

ベアリポジトリ作成

共有するのはベアリポジトリ(作業ファイルを持たないリポジトリ)とする。

以下は、Dropbox 配下の proj ディレクトリ配下に、共有リポジトリを配置する例。
ディレクトリの名前は、末尾に .git を付けるのが通例とのこと。 

$ cd path_to_dropbox/proj
$ mkdir project_name.git
$ cd project_name.git
$ git init --bare --shared

 

2. ローカルリポジトリの作成

元となるプロジェクトを作成し、共有リポジトリへアップロードする。

 

Eclipse プロジェクト作成

まずは通常と同じ手順でローカル(Dropbox以外の場所)にプロジェクトを新規作成する。

プロジェクトのパスは path_to_workspace/project_name とする。

 

ローカルリポジトリ作成

Eclipse プロジェクトのコンテキストメニューから、Team -> Share Project… を実行。

  • Share Project: Git を選択
  • Configure Git Repository
    • Use or create repository in parent folder of project: チェックを付ける
    • Create Repository ボタンを押下
    • 対象プロジェクトがチェック状態となったことを確認し finish

 

.gitignore ファイル作成

プロジェクトパス直下に「.gitignore」というファイルを作成し、管理対象外とする資源を定義する。

Eclipse のパッケージエクスプローラではデフォルトでは .* ファイルは表示されないので
まずは表示の設定を変える。 

  • パッケージエクスプローラのウィンドウ右上の下向き三角を押下し、Customize View… を選択。
     workspace
  • .* resources のチェックを外す

プロジェクトのコンテキストメニューからNew -> File で「.gitignore」を作成。

以下は Python プロジェクトの一例。

「.project」を管理対象とするかどうかは適宜判断要。
OSが異なると、同じプロジェクト設定では正しく動作しない可能性がある。 

# OS files
.DS_Store
*~
 
# Eclipse files
.project
.pydevproject
.settings/

# Python objects
*.py[cod]

 

アップストリームの設定

ローカルリポジトリに、上流のリポジトリを定義する。

ここは EGit ではなくコマンドで実行した方が早い。
Dropbox 上の共有リポジトリを origin という名前で登録。

 

$ cd path_to_workspace/project_name
$ git remote add origin path_to_dropbox/proj/project_name.git
$ git remote -v

最後のコマンドは確認のコマンド。このように表示されれば問題ない。

origin path_to_dropbox/proj/project_name.git (fetch)
origin path_to_dropbox/proj/project_name.git (push)

 

コミットと共有リポジトリへのプッシュ

Eclipse に戻り、プロジェクトのコンテキストメニューから Team -> Commit… を選択。

  • Commit Changes to Git Repositor
    • Commit messages: 適切なメッセージを記入 (未記入はNG)
    • Files: 全て選択 (管理対象外にしたいファイルが含まれていた場合は .gitignore を見直す)
    • Push: Push the changes to upstream のチェックを付ける (Eclipse のバージョンによって存在しない場合がある?)
  • Pushed to project_name - origin
    • OK を選択すれば、上流である共有リポジトリへのプッシュが行われる。
上流へのプッシュが行われなかった場合は、Team -> Push to Upstream で同じウィザードが出現する。

 

 

3. 別のマシンで共有リポジトリを利用

プロジェクト作成元と別のマシンで同じプロジェクトを使用するための方法。

 

クローンリポジトリの作成

作業をしたいマシンで Eclipse を起動し、Window -> Show View -> Other… を選択。
Git -> Git Repositories を選択する。 

Git Repositories ウィンドウで、右上のアイコンから
「Clone a Git Repository and add the clone to this view」(左から4番目?)を押下。 
workspace

  • Select Git Repository
    • Location URI: path_to_dropbox/proj/project_name.git を選択
    • Connection Protocol: file
  • Branch Selection: master を選択
  • Local Destination
    • Destination Directory: path_to_workspace/project_name
    • Destination Initial branch: master
    • Configuration Remote name: origin
    • Import all existing projects after clone finishes: チェックしない
 
 
プロジェクトのインポート

Eclipse メニューの FIle -> Import… から以下の手順を行う。

.project ファイルを .gitignore に含めた場合は直接プロジェクトをインポートすることはできない。
一旦一般プロジェクトとして読み込んだ後、プロジェクトの変換を行う。 

  • Select: Git -> Projects from Git
    • Select Repository Source: Local
    • Select a Git Repository: project_name - path_to_workspace/project_name
    • Select a wizard to use for importing projects: Import as general project
    • Import Projects Project name: project_name
      • Use the New Projects wizard を選択 (*1)
      • Select a wizard: 適切なウィザードを選択
      • プロジェクト新規作成ウィザードを実行
    • Select a wizard: プロジェクトに応じて適宜設定

プロジェクト種類の変換手順はプラグインなどによって異なっているようだ。
PyDev の場合は、コンテキストメニューから PyDev -> Set as PyDev Project で変換できた。

これで、晴れてプロジェクトを Dropbox を使って複数のマシンで共有することができるようになった。

 

 

補足. github へのアップロード

作成したプロジェクトを github へアップロードして公開する場合の手順。

 

SSH公開キーの登録

そのマシンで初めて github に接続する場合のみ実行。
手順はgithub公式ヘルプを参照。

Generating SSH Keys · github:help 

 

github 上のリポジトリ作成

これは github のWeb画面から実行する必要があるようだ。
Create a new repo アイコンを押下し、リポジトリ名などを登録する。 

 

github へプッシュ

ローカルリポジトリの remote の定義として github を追加する場合の例。
以下のコマンドを実行。($USER$ は github アカウントに書き換え)

$ cd path_to_workspace/project_name
$ git remote add github https://github.com/$USER$/project_name.git
$ git push -u github master

 

 

 

Related Posts

mog project: Sharing a Personal Eclipse Project with Dropbox + Git

 

12.31.2012

Scala: How to Create Countdown Twitter Bot

Scala: カウントダウンを行う Twitter ボットの作成方法

2ヶ月ほど前に、予備知識ゼロの状態から bot を作ってみた。その時のメモ。

 

使用したテクノロジー、サービス

 

1. TwitterAPI の設定

まずは、Twitter 側の環境セットアップから。

 

1.1 アカウント開設

bot 用の新規アカウントを作成する。

ユニークなメールアドレスの登録が必要だが、gmail のアカウントを持っているなら
ドットの位置を変えたり、エイリアスを付けることで同じメールアカウントを共有できるので便利だ。 

https://support.google.com/mail/bin/answer.py?hl=en&answer=10313
http://support.google.com/mail/bin/answer.py?hl=en&answer=12096

 

1.2 認証用トークンの取得

TwitterAPIに接続するためには、OAuth認証を行う必要がある。そのための準備。

  • 以下のURLを開く
    https://dev.twitter.com/apps/new
  • 先ほど作成したアカウントでサインイン
  • 必要な情報を入力して Create your Twitter application を押下Create an application | Twitter Developers 2
    • Application Details -> Name: ユニークなアプリケーション名 (32文字以内)
          ツイートの「○○から」(via ○○) の部分に使用される。日本語可。 
    • Application Details -> Description:  アプリケーションの説明 (10文字〜200文字)
    • Application Details -> Website:  WebサイトのURL
          ツイートの 「○○から」(via ○○) のリンクとして使用される。
    • Application Details -> Callback URL:  コールバックURL
          ブラウザアプリケーションの場合は必要だが、今回は
          クライアントアプリケーションなので ブランクのままとする。
    • Developer Rules of the Road: (規約を読んでから) Yes, I agree にチェックする
    • CAPTCHA: 画像にかかれた文字を入力
  • アプリケーションの登録に成功すると、以下のような画面が表示される。
     m
  • OAuth アクセス権限の変更
    デフォルトでは Read only となっているため、このままではツイートの作成ができない。 
    Settings タブ -> Application Type -> Access を Read and Write に変更し、
    Update this Twitter application's settings ボタンを押下。
  • アクセストークンの取得
    Detail タブに戻り、Your access token -> Create my access token ボタンを押下。
    Access level が Read and Write と表示されていることを確認。
  • 以下の4種類のパラメータを、後ほどアプリケーションから指定することとなる。
    • OAuth settings -> Consumer key
    • OAuth settings -> Consumer secret
    • Your access token -> Access token
    • Your access token -> Access token secret

 

2. 開発環境の準備

このチュートリアルに従って、環境のセットアップを行う。
https://devcenter.heroku.com/articles/scala 

 

2.1 Scala のインストール

公式サイト、パッケージ管理システムなどからパッケージをダウンロードし、インストール。
詳細は割愛する。
http://www.scala-lang.org/downloads

 

2.2 sbt のインストール

こちらも公式サイト、パッケージ管理システムなどからパッケージをダウンロードし、インストールする。

ただし、必ず heroku でサポートされているバージョンを導入すること。
https://devcenter.heroku.com/articles/scala-support#build-behavior 

手動インストールを行う場合は、jar ファイルと起動スクリプトを設置すればよい。
http://www.scala-sbt.org/release/docs/Getting-Started/Setup.html 

 

2.3 JDKの準備

OpenJDK バージョン6 上で動作させること。

 

2.4 heroku アカウントの作成

下記のページからメールアドレスを登録するだけで heroku を利用できる。
https://api.heroku.com/signup

随所に見られる日本へのリスペクトを感じさせてくれるデザインが嬉しい。
 Heroku | Login

 2.5 heroku toolbelt のインストール

下記のURLから heroku toolbelt をインストールする。
https://toolbelt.heroku.com/

heroku toolbelt とは、以下の3つのツールが同梱されたパッケージである。

  • Heroku client: heroku 管理用のCLIツール
  • Foreman: Procfile ベースのプロセス管理ツール
  • Git

 

3. sbtプロジェクトの作成

sbt 用のディレクトリおよび設定ファイルの作成を行う。

 

3.1 ディレクトリの作成

以下のような構成でディレクトリを作成する。

プロジェクトディレクトリ
├── project
└── src
    └── main
        └── scala

 

3.2 設定ファイルの作成

 

4. プログラム作成

いよいよプログラム本体の作成に入る。

 

4.1 ソースコードの作成

プロジェクトディレクトリ/src/main/scala 配下に Scalaプログラムのソースを作成する。

色々と改善の余地はあると思うが、できたものはこんな感じ。
https://github.com/mogproject/scalaconfjp-countdown/blob/master/src/main/scala/ScalaConfJPCountDown.scala

仕様

  • OAuth認証のパラメータは全て環境変数に設定することとし、tweet() という関数を定義。
  • java の Calendar クラスを利用して現在の日時を取得。
    カウントダウンの目的の日との日数の差を求め、その値によって異なるメッセージをツイートする仕様。 

注意点

  • heroku の日時は UTC で得られるので、それを前提に実行時間の計算ロジックを作ること
  • TwitterAPI の制約に注意
    • 同一のメッセージは "Status is a duplicate." エラーとなり、受け付けられない
    • レート制限 (TwitterAPI v1.0 では、OAuth接続の場合 350コール/時)
      https://dev.twitter.com/docs/rate-limiting 

 

4.2 ローカル環境変数の設定

プログラム中で参照するOAuth認証のための環境変数をローカルマシン上で設定する。 

  • CONSUMER_KEY
  • CONSUMER_SECRET
  • ACCESS_TOKEN
  • ACCESS_TOKEN_SECRET

 

4.3 sbt 実行テスト

この段階でローカルで sbt からプログラムを実行できるようになる。

プロジェクトディレクトリにて、以下のコマンドを実行する。

  • ビルド
    初回はダウンロードなどが行われるので時間がかかる。
    $ sbt clean compile stage
  • 実行
    $ sbt run

 

5. foreman の設定

プロジェクトディレクトリ直下に Procfile というファイルを作成する。

本来はWebサービスなどのプロセスを指定するのだが、今回の用途はバッチ処理のみなので
行頭に # を付けて内容をコメントアウトする。

(例) https://github.com/mogproject/scalaconfjp-countdown/blob/master/Procfile 

 

6. git リポジトリの作成

heroku を利用する前に、ローカルに git リポジトリを作成する。

 

6.1 .gitignore ファイルの作成

プロジェクトディレクトリ直下に .gitignore ファイルを作成し、git の管理対象としないファイルの定義を行う。

ひとまずこんな感じで指定。(おそらく管理対象外とすべきファイルは他にもあると思われる)
https://github.com/mogproject/scalaconfjp-countdown/blob/master/.gitignore 

最終的に、ファイル構成はこのようになった。

プロジェクトディレクトリ
├── .gitignore
├── Procfile
├── build.sbt
├── project
│   ├── build.properties
│   └── plugins.sbt
└── src
    └── main
        └── scala
            └── (クラス名).scala

 

6.2 リポジトリの作成

プロジェクトディレクトリ直下で以下のコマンドを実行し、最初のコミットを行う。

$ git init
$ git add .
$ git commit -m "init"

 

7. heroku アプリケーションの作成

プログラムを heroku へデプロイし、スケジュール実行の設定を行う。

 

7.1 アプリケーションの新規作成

プロジェクトディレクトリ直下で以下のコマンドを実行する。

$ heroku login
Enter your Heroku credentials.
Email:
Password (typing will be hidden):
Authentication successful.
$ heroku create

アプリケーションの名前は一意のものがランダムに設定される。(後で変更可能)

 

7.2 資源のデプロイ

リモートリポジトリ heroku は自動的に設定されているため、以下のコマンドを行うだけでよい。

$ git push heroku master

 

7.3 heroku 環境変数の設定

heroku 上での環境変数を設定するため、heroku config:add コマンドを実行する。

(実行例)

$ git config:add CONSUMER_KEY=xxxxxxxxxxxxxxxxxxxxxx
$ git config:add CONSUMER_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
$ git config:add ACCESS_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
$ git config:add ACCESS_TOKEN_SECRET=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 

7.4 手動実行テスト

ここで、heroku 上でのプログラム実行テストが可能となる。
heroku run コマンドを行えばよい。

$ heroku run 'target/start (クラス名)'

 

7.5 スケジュール設定

heroku のアドオンである Heroku Scheduler を利用する。

heroku dashboard (heroku のサイトへログインした後の画面) から、Add-ons をクリックすれば
アドオンの選択画面に入る。

Utilities -> Heroku Scheduler を選択し、登録を行う。 

Heroku | Add ons

Heroku Scheduler 自体は無料のアドオンであるが、この時クレジットカードの登録を要求される。

登録が終わったら heroku dashboard に戻り
Apps -> 今回作成したアプリケーション -> Resources -> Add-ons -> Heroku Scheduler Standard と選択していく。

Add job… ボタンを押下し、
コマンド(target/start (クラス名))、頻度(10分おき/1時間おき/1日おき)、実行時間
を選択して Save すればスケジュール設定完了。

時間の指定は UTC となる。

 

8. heroku の運用

運用中の heroku コマンド。実行時にはログインが必要である。 
プロジェクトディレクトリ直下でコマンドを実行すれば、アプリケーションの指定(--app)を省略できる。

 

8.1 アプリケーション一覧の参照
$ heroku apps
=== My Apps
xxx
yyy
zzz

 

8.2 ログの参照
$ heroku logs 

 

8.3 プロセス状態の参照
$ heroku ps 

今回のプログラムに関しては、Webサービスではないので常駐プロセスは存在しない。

 

8.4 コンソールの操作

bash

$ heroku run bash

sbt コンソール

$ heroku run sbt console

 

 

References

作ったもの
https://twitter.com/scalaconfjp_cd

ソース置き場
https://github.com/mogproject/scalaconfjp-countdown 

11.11.2012

Sharing a Personal Eclipse Project with Dropbox + Git

Dropbox + Git を使って個人用の Eclipse プロジェクト(今回はC++)を共有する方法

 

2013-01-13 手順更新
mog project: Sharing a Personal Eclipse Project with Dropbox + Git [Updated]

 

何番煎じか分からないけど、意外とハマったのでメモ。

1. 事前準備

  • Git の導入
    • Linux では $ sudo apt-get install git-core
  • Eclipse プラグイン EGit の導入
  • EGit の共通設定
    • メニューから Window -> Preferences (Mac は Eclipse -> Preferences)
    • Team -> Git
      • Default repository folder を適宜設定 (デフォルトは ~/git)
    • Team -> Git -> Configuration
      • User Settings -> Add Entry... を押下
      • Key: user.name, Value: ユーザ名 を設定
      • Key: user.email, Value: メールアドレス を設定

2. ローカルリポジトリの作成

  • まずは普通にプロジェクトを作成。今回はCDTプロジェクトとした。
  • プロジェクトのコンテキストメニューから、Team -> Share Project…
  • Share Project: Git
  • Configure Git Repository
    • 今回のプロジェクトはワークスペースの直下にあるため、
      Use or create repository in parent folder of project にはチェックを付けない
Git リポジトリの配下にプロジェクトのディレクトリが作成される。
ワークスペースと同じ場所にリポジトリを作るのは非推奨。
      • Repository -> Create を押下
        • Parent directory: ローカルマシン上のディレクトリ
        • Name: プロジェクトの集合の名前を入力し Finish
作業用レポジトリをローカルに作成することで、Dropbox の使用量および通信量を節約できる。
    • 設定例
      • Current Location: ワークスペース/プロジェクト名
      • Target Location: ~/git/eclipse/プロジェクト名
    • プロジェクトにチェックが付いていることを確認し Finish
  • この段階ではまだ NO-HEAD
  • プロジェクトディレクトリ直下にファイル .gitignore を作成
    ※ファイル末尾に改行を入れないと、Macでは最後の行が評価されなくなったので注意
.DS_Store
Release/
Debug/
.settings/
  • プロジェクトのコンテキストメニューから Team -> Commit…
    • Commit message: 適当なメッセージ
    • Files: Select All アイコン(右上のチェックマーク)を押下し全て選択
    • Push the changes to upstream のチェックを外してから Commit

3. Dropbox 上のリポジトリの設定

  • Eclipse でプロジェクトのコンテキストメニューから Team -> Show in Repositories View
  • Git リポジトリビューのアイコン Create a new Git Repository and add it to this view を選択
    • Create a New Git Repository
      • Parent directory: ここで Dropbox 配下のディレクトリを指定
      • Name: リポジトリの名前 (例: eclipse)
      • Create as bare repository: チェックを付ける
  • Git リポジトリビューでローカルリポジトリのコンテキストメニューから Push
    • Destination Git Repository
      • URI: 先ほど作成したDropbox 配下のディレクトリを指定
      • Connection -> Protocol: file
    • Push Ref Specifications
      • Source ref: master [branch] (refs/heads/master)
      • Add Spec を押下
      • Finish を押下し、Push Results を確認
  • Git リポジトリビューでローカルリポジトリ -> Remotes のコンテキストメニューから Create Remote… を選択
    • Remote name: dropbox などの適当な名前
    • Configure fetch を選択
    • Configure push for remote 'dropbox'
      • URI: Dropbox配下のリポジトリを指定
      • Ref mappings: +refs/heads/*:refs/remotes/dropbox/* であることを確認
      • Save and Fetch を押下し、everything up to date と表示されればOK
  • Git リポジトリビューでローカルリポジトリのコンテキストメニューから Properties を選択
    • Configuration -> Add Entry… を押下
    • Key: branch.master.remote, Value: dropbox (リモートに指定した名前)
    • Key: branch.master.merge, Value: refs/heads/master
    • Key: branch.master.rebase, Value: true

4. 別のPCで Dropbox と同期

  • Eclipse を起動し、Window -> Show View -> Other… -> Git -> Git Repositories
    • Git リポジトリビューのアイコン Clone a Git Repository and add the clone to this view
    • Source Git Repository
      • Location -> URI: Dropbox 配下のディレクトリを指定
      • Connection -> Protocol: file
      • Branch Selection: master
      • Local Destination
        • Destination -> Directory ローカルリポジトリの保存先
        • Initial branch: master
        • Clone submodules: チェック無し
        • Configuration -> Remote name: dropbox など
        • Projects -> Import all existing projects after clone finishes: チェック無し
        • Projects -> Add projects to working sets: チェック無し
        • Select a wizard to use for importing projects: Import existing projects
  • メニューから File -> Import…
    • Select: Git -> Projects from Git
    • Select Repository Source: Local
    • Select a Git Repository: 先ほどクローンを作成したローカルリポジトリを指定
    • Select a wizard to use for importing projects: Import existing projects
    • Import Projects: プロジェクトが選択されていることを確認し Finish
    • Source Git Repository
      • Location -> URI: Dropbox 配下のディレクトリを指定
      • Connection -> Protocol: file
    • Branch Selection: master
    • Local Destination
      • Destination -> Directory ローカルリポジトリの保存先
      • Initial branch: master
      • Clone submodules: チェック無し
      • Configuration -> Remote name: dropbox など
      • Select a wizard to use for importing projects: Import existing projects 

本来であればインポートウィザードで直接クローンを作りたかったのだが、Mac+CDTという環境が悪いのか、どうにもうまくいかなかった。

(具体的には、Dropbox上のリポジトリを選択した後でプロジェクトの一覧に何も出てこない状態に陥る)

リポジトリビューから操作を行うことで、なんとか事象を回避することができた。

 

環境
  • Ubuntu natty(11.04) 64bit: Elipse Juno(4.2) + CDT 8.1.0 + EGit 2.1.0 + Git 1.7.4.1
  • OS X Mountain Lion(10.8.1): Eclipse Juno(4.2) + CDT 8.1.0 + EGit 2.1.0 + Git 1.7.9.6 

 

References

EGit User Guide
http://wiki.eclipse.org/EGit/User_Guide 

Eclipse RCP, RAP Blog: EGit によるソースコード管理(1) ローカルリポジトリの作成:
http://brissyu.blogspot.jp/2012/02/hudson-tycho-4.html 

eclipse 4.2×EGit環境でPush/Pullのハマりどころを回避する  - mooapp 

Git チートシート
http://www.textdrop.net/doc/git-cheat-sheet-ja/