no_picture

GitHubに馴れると何ができるのか

コンピュータに疎い人にGitHubに馴れると何ができるのか聞かれたので、その時に書いた文章を残しておく。 GitHubに馴れると何ができるのか GitHubの操作になれると、他の人の協力して「ものづくり」しやすくなります。 「ものづくり」と書きましたが、なんにでも使えるわけではないです。 基本的にはコンピュータ上で動くものを作るときでであり、作るものは、文字で表現できるものが主となります。 文字で表現できるものは、例えば、コンピュータ言語を記述して作るものがあります。 コンピュータ言語を使って作成できるものは、アプリケーションやウェブページなどなどがあります。 コンピュータに疎いということであれば、GitHubに慣れることよりもまず、コンピュータを使って何かを作ることになれる必要があるかもしれません。 もし、コンピュータを使って、アプリケーションやウェブページを作成しているのであれば、GitHubに馴れることで、他の人と協力しやすくなります。 HTMLというものやCSS、JavaScriptなどを利用して、なにかを作成している場合、今の時代であれば、どこかでGitHubというものに出会うと思います。 蛇足 書いてて、思い出したのは「ものづくりにっぽん: Gitとかわかんなくても死なないです」だけど、Gitとかわかんなくても死なないのは事実だな、と思いながら書いた記憶があります。 ただ協力して作業する場合に、便利なサービスとしてGitHubをたくさんの人が使うようになると、Gitが使えない人は協力して作業するのが難しくなると思います。 そのコストを誰かが払ってでも一緒にものをつくれるのであれば、Gitとかわかんなくても生きていけると思うのでした。 何を学ぶかは、誰と作りたいのか、何を作りたいのか、それをどうやって作るのか。 僕はGitがないと仕事できないので、一緒につくりたい人のためにはGitの使い方なんていくらでも教える。 マイノリティーが生きるのはどこへいっても辛いものです。

no_picture

GitHub戦闘力を提案してみた - 座駆動LT大会

座駆動LT大会で「戦闘力」というLTをしてきました。 座駆動LT大会とは、岡山にはRyouteiという素晴しいお店があり、そこの座スタジアムという部屋は非常にLTに適した場所です。 大都会岡山が誇る最強の懇親会会場「Ryoutei 座・スタジアム」でLT大会を開催します! というわけで、今回参加してきた時のスライドを紹介します。 戦闘力といえば、Vim戦闘力やEmacs戦闘力がありますが、GitHub戦闘力を適当に定義してみました。 スターの数がGitHub戦闘力と言われているのもみかけましたが、折角なのでいろいろ考えてみました。 実はオープンソースカンフェレンス2014広島のために制作しているものの中でGitHub APIを使用してつくっていたものがあり、そのノウハウで、そのついでに作成したのが今回のgithub_scouterです。 eiel/github_scouter · GitHub オープンソースカンファレンスは今週末の土曜日、2014年9月20日に予定されています。 予約数があまり多くないらしいので、今後も継続して欲しいと考えている方は参加や告知を協力していただけると助かります。 ちなみに私はLT駆動開発ベストセッションズでLTをする予定です。 閑話休題。 今回はGitHub戦闘力を攻撃力、知力、すばやさの3種類に分けて戦闘力を定義しました。 攻撃力は所有リポジトリを元に算出しました。 知力はさまざまな言語を利用していると高くなるようにしました。 すばやさはOrganizationの情報を元にチーム力の高さとして算出しました。 と、非常にどうでもいい戦闘力ですが、みなさんも御自分の戦闘力を算出してみてはいかがでしょうか。 また、APIの利用しすぎにご注意ください。 .@eielh 「わたしの戦闘力は168Gです」 #zadrvnlt — (っ’ヮ’c) < 君のほうがかわいいよ (@ryosms) 2014, 9月 13 かけ算バージョンは表計算で出したので、コマンドを用意していません。 0にならないように1を加えてからかけ算しています。 今後、計算式を定義しなおしてVersion2も検討したいと考えているのはまた別の話です。 追記 Gem化して欲しいって要望があったのでしておきました。 $ gem install github_scouter $ github_scouter [GitHub ID] で利用できます。

no_picture

GitHub Pages で jekyll を使うなら safe: false で開発したほうが良いかもしれない

3月ぐらいから GitHub Pages でも使える Jekyll のプラグインが一部使えるようになりました。 最新の github-pages gem の v18 だと jemoji - GitHubの絵文字が使える jekyll-mentions - @github-id と、書くと自動でユーザへのリンクになる jekyll-redirect-from - 別のページからこのページに飛ばせる jekyll-sitemap - sitemap.xml が自動生成される が使えます。 ローカルで開発する場合、_config.yml に safe: true と記述してしまうと、これらのプラグインが動作しません。 GitHubに push すると動作してました。 ただし、GitHub上では safe: true の状態で動いてるはずなので、注意が必要です。(実際に確認はしてないけど) github-pages v19 で Jekyll が 2.0.2 になるのでこれはこれでまた違ってくるかもしれませんが、確認していません。(まだリリースされてない) そういえば、SASS とか CoffeeScript が使えるようになりそうなので非常に期待したい v19 です。 ローカルやTravisで生成すればだいたいのことができますが GitHub で生成できるとGitHub 入門として使いやすいですし、どんどん機能拡張されると良いですねー。 補足 プラグインを利用するには _config.yml に gems: - jekyll-mentions - jekyll-redirect-from - jemoji - jekyll-sitemap の記載が必要です。

no_picture

Travis-CI でコミットして GitHub にプッシュする - 公開鍵認証を利用してみる

静的サイトジェネレータとGitHub Pagesを使っていると、Travis-CIでHTMLを生成してコミットを行い、masterを自動で更新して欲しいですね。 普通なら下記の記事の方法で充分でした。 Middleman で作った web サイトを Travis + GitHub pages でお手軽に運用する - tricknotesのぼうけんのしょ しかし、 Organization のリポジトリに対してこの方法を使うとメンバーが私個人のリポジトリを操作ができる気がする。 仕方ないので別の方法を模索してみた。 GitHub には、リポジトリごとに公開鍵を追加する機能があったのでこれを使ってみました。 考えないといけないことは、秘密鍵をどうやってTarvisへもっていくかです。 秘密鍵を共通鍵で暗号化して、リポジトリに追加する方法を選んでみました。 共通鍵を .travis.yml の中に暗号化してに保存しておきます。 この共通鍵の復号は Travis 側で自動的にされます。この共通鍵を使い Travis 側でリポジトリに含まれる秘密鍵を復号します。 秘密鍵さえ手に入れば GitHub に push できます。 やることを整理します。 Travis-CI の設定 秘密鍵と公開鍵の作成 秘密鍵を暗号化するための共通鍵の生成 秘密鍵の暗号化してリポジトリに追加 GitHub のリポジトリに公開鍵を追加 .travis.yml へ暗号化した共通鍵を設定 .travis.yml にGitHubへ pushする処理などを記述 Travis-CIの設定 割愛します。 ログインして、設定したいリポジトリをONにします。 秘密鍵と公開鍵の作成 ssh-gen コマンドを使います。 作る鍵を deploy_key として進めます。 $ ssh-keygen -f deploy_key deploy_key と deploy_key.pub が生成されます。 秘密鍵を暗号化するための共通鍵の生成 適当につくります。shell変数 password に保存しておく例を書いておきます。 $ password=`cat /dev/urandom | head -c 10000 | openssl sha1` 秘密鍵の暗号化してリポジトリに追加 さっき作成した共通鍵で deploy_key を暗号化して deploy_key.encを作成します。 $ openssl aes-256-cbc -k "$password" -in deploy_key -out deploy_key.enc -a あとは適当にコミットします。 deploy_key をコミットしないように気をつけてください。 $ git add deploy_key.enc $ git commit -m 'Add deploy key' GitHub のリポジトリに公開鍵を追加 deploy_key.pub をGitHubに登録します。 GitHubのリポジトリのページを表示して、設定 > Deploy keys > Add deploy key で登録できます。区別がつくように名前は好きにつけましょう。 .travis.yml へ暗号化した共通鍵を設定 travis gem をインストールしていない場合はインストールしましょう。 $ gem install travis travis encrypt コマンドを使用します。 $ travis encrypt -r [ユーザ名や組織名]/[リポジトリ名] "SERVER_KEY=$password" -a .travis.yml の env.global へ情報が記録されます。 すごい広島を例にすると、こんな感じになります。 $ travis encrypt -r great-h/great-h.github.io "SERVER_KEY=$password" -a .travis.yml にGitHubへ pushする処理などを記述 .tarvis.yml の after_success にやりたいことを書きましょう。 鍵の設定の部分はこんな感じ。 after_success: - echo -e "Host github.com\n\tStrictHostKeyChecking no\nIdentityFile ~/.ssh/deploy.key\n" >> ~/.ssh/config - openssl aes-256-cbc -k "$SERVER_KEY" -in .travis/deploy_key.enc -d -a -out deploy.key - cp deploy.key ~/.ssh/ - chmod 600 ~/.ssh/deploy.key あとは煮るなり焼くなり。 すごい広島での例を上げておきます。 _site にファイルが生成されているので、それを master ブランチにコミットしてプッシュしています。 language: ruby rvm: - 2.1.0 after_success: - echo -e "Host github.com\n\tStrictHostKeyChecking no\nIdentityFile ~/.ssh/deploy.key\n" >> ~/.ssh/config - openssl aes-256-cbc -k "$secret" -in .travis/deploy_key.enc -d -a -out deploy.key - cp deploy.key ~/.ssh/ - chmod 600 ~/.ssh/deploy.key - git clone git@github.com:great-h/great-h.github.io.git -b master - cd great-h.github.io - cp -a ../_site/ .

no_picture

そういえば彼氏募集というネタリポジトリがありましたね。真似するならこんな感じかなぁ。

最近、C++界や、ひろし魔界で暴れているらしいまさかず氏が彼氏募集のリポジトリを真似して彼女募集のリポジトリを作成してました。 条件さえ揃えば真似してもよかったのですが、条件が揃ってなかったので真似してませんでした。 気がついたら条件が揃ってたので真似してみることにしてみました。 eiel/need_a_girlfriend - GitHub やったこと fork したけど 空のブランチつくって、fork元とはコード的には関係をなくした Haskell で DSL したかった。結局、Writer モナドの上に構築した。 source ブランチを push すると travis で README.md を生成して master ブランチに自動で push する リポジトリの名前を変更した fork したけど 空のブランチつくって、fork元とはコード的には関係をなくした fork したので、その上から上書きしてもよかったのですが、だいぶ違うし、ゼロからつくりたいけど fork したことは残したいよね。 ということで空のブランチをつくってから作りました。 git checkout --orphan <branch名> で空のブランチが作れます。 Haskell で DSL したかった。 README.md は手書きせずにプログラムから生成するようにしてみました。 まさかず氏を真似ただけである。 Haskell で DSL 作るのにはどうしたらいいんだろうなぁ。たぶんモナド作ればいいんだろうと、コード書きはじめたけど、途中でよくわからなくなった。 それはそれで別に勉強すればいいやということから途中から Writer モナドでつくりました。 background = do h1 '背景' p 'ほげほげごろごろ' みたいに書きたかった。というか、このように書いてから h1 や p 関数を実装しました。 Writer モナド は

no_picture

Jekyll 使うときは exclude: vendor しとけって話らしい。

素のJekyll なんて使う人はあまりいないと思うけど一応書いておこう。 以前から jekyll build が失敗するっていう話をしてる人がいて自分の環境じゃ、おきてなかったんだけど、bundle install --path vendor/bundle してるのが原因だったらしい。 _config.yml に exclude: ['vendor'] するのがよいでしょう。 ついでに以下のような感じにした。 exclude: ['Gemfile','Gemfile.lock','Rakefile','vendor'] 具体的なコミットはこちら 素のJekyllから拡張してる場合は注意。 middleman などなどを使うことをおすすめしとこう。 自分が発見したネタじゃないけど記録しておいた。

no_picture

GitHub からの通知が迷惑メールになった - 見ないリポジトリは unwatch しよう

すごい広島での出来事である。 いつかなる気がしていた。 GitHub からの通知のメールが迷惑メールとして判定された。 多数のユーザが同様のメッセージを迷惑メールとして報告しています。 迷惑ならそもそも通知が来ないようにするか、単に自動でアーカイブするようにして欲しいですね。迷惑メール報告すること自体が迷惑になります。 私が知る限りの通知の設定方法を紹介しておきます。 GitHub は常に進化しているので、動作や画面はいずれ変わってしまうかもしれません。 そもそもの通知設定 「GitHub からメールに通知して欲しくないよ!」という人は基本的な設定を見直しましょう。 Noticification Centerにアクセスをします。 設定 > Notification Center でアクセスすることができます。 自分が参加しているグループがだだ漏れですが、特に隠しません。 How you receive notifications に注目してください。 「通知をどのように受信するか」を設定します。 Participating Watching の二種類があります。 Participating のほうは @自分のGitHub ID が付いているような「自分が参加しているところに変化があった時」にどこに通知するかを設定できます。 Watching のほうは GitHub にリポジトリを watchする機能があり、「watch してるものに変化があった時」にどこに通知するかを設定できます。 Email のチェックを外せばメールは届かなくなるでしょう。そうではなくて、一部のリポジトリが活発すぎてついていけない場合もあります。 そのリポジトリを unwatch することで調整できます。これについては後述します。 Email という項目の他にも Web という項目があります。Web での通知は画面左上にあります。 クリックすれば通知内容を確認できます。 リポジトリのウォッチ リポジトリが活発すぎて、そのリポジトリの通知はちょっと見てる余裕がない場合はリポジトリを unwatch しましょう。 あるチームにいつの間にか入れらたしまった場合、自動的に watch されてしますので、こういうことがあります。 これは watch している状態です。 外す場合は、Unwatch を選択して Not watching を選びます。 自分のGitHub IDが登場しない限りは通知がこなくなります。 自分が呼ばれていれば通知がきます。 Not

no_picture

GitHub で SSH 接続できなくなった。SSH をつかった場合に高速化する設定が原因だった。

さっき、GitHub に push しようとしたら下記のエラーが発生した。 no matching cipher found: client arcfour256 server aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc 「arcfour256 に対応してねーよ」ってことが書かれている。 ~/.ssh/config を確認したら Host github.com Compression yes Ciphers arcfour256 思いっきり自分で指定しています。 設定した記憶もないし、arcfour256 ってなんだっけなとググると「GitHub で ssh をつかっていると遅くなるから、こういう設定したら速くなるよ」という記事がでてきた。 GitHub で clone するときは SSH じゃなく HTTP を使ったほうが高速 - てっく煮ブログ 「なるほど、設定をコピペしたから記憶に残ってないんだ」と、思った。 コピペした設定は、ちゃんと勉強した上で使わないとダメですね。 そんな感想を抱いた。

no_picture

コミュニティに GitHub に使ってみて - すごい広島

すごい広島 も20回を越えて、そろそろ半年経とうとしています。 すごいですね。 #知らんけど そんなわけでコミュニティのとして GitHub を使ってみた感想を自分の中でまとめてみようと思います。 簡単に「すごい広島」について書いておくと、毎週やっている勉強会もどきでミートアップです。ITエンジニアが集まって雑談してたり作業していたりします。 思ってたより人が集まってる みんな GitHub になれてきた? マージされない Pull Request もっと Issue が作成されてもいいんじゃないか 思ってたより人が集まってる 自分が想像していたよりも人が集まっています。 みなさんありがとうございます。 どうせ「すぐ一人二人でもくもくーってなる」と、思ってたのですが、3人以下になったのは1回ぐらいしかないように思います。 参加条件は徐々に緩くしているのもあるかもしれません。 未参加の人からよくあった意見は、 行ってみたい ブログを書くのは無理 敷居が高そう 目的がよくわからない です。 「行ってみたい」の人は来れない場合の話がありますが、来れる人が言ってる場合はお世辞なんですかね。(煽り ブログを書くのは必須ではなくしたので、代わりに GitHub を思う存分試してみて欲しいです。 最近は Issue に作業をメモをとったりしています。 参考にしてください。 敷居が高くみえてしまうのは、変態扱いされない人のアウトプットが鍵になる気がしています。 期待したい。 「目的がよくわからない」の一番の理由は名称のせいかな。 やっぱり情報が読まれるかどうかはタイトル次第というのを改めて感じました。 それでも 「Web を見て参加しました!」が登場したので個人的には満足です。 目的のひとつが達成されました。 改めて「広島 勉強会」で Google で検索しましたが、ちょっと SEO 的にはまだまだです。その辺の工夫が必要そうでした。 みんな GitHub に馴れてきた? 参加者のほとんどが GitHub に馴れてない人です。 それだけ GitHub を使う環境がまだまだないのだと思います。 説明せずに Pull Request した人は僅かです。 そういう意味では効果があったと思います。 また、「非プログラマでも Pull Request はできているので難しくないよ」と言いたいのですが、なかなか良い方法がないです。(チラリ ちなみに、半分以上の人が

no_picture

GitHub に課金した

GitHub に課金した。月7ドル。 課金した理由は「プライベートリポジトリが欲しくなった」で充分だろうか。 いや、充分ではない。 「プライベートリポジトリが欲しいならBitbBucketを使えばいいじゃない」と、言われてしまうのである。 BitBucket は日本語化されているし、プライベートリポジトリは制限なく作れる。 しかし、チームの人数は5人という制限がある。 というわけで、「チーム人数が5人越えそうだ」 というわけでもあるけど、本当の理由は別のところにある。 Github と BitBucket 両方使っていますが、どちらを使いたいかと言われると GitHub なのである。 GitHub も BitBucket も、日々変化している。 変化に対応するためにも毎日利用したい。 というわけで、毎日使いたい GitHub に課金したのである。 しかし、主な利用法が Wiki になりそうというのは秘密である。 最近 iPhone のパケットプランをフラットプランに変更したので、Macローカルにある固有のデータをなるべく減らして情報はどの端末からも参照したくなってきた。 Wikiのデータは Gitリポジトリアクセスできるので、好きなエディタでも編集しやすい。 Dropbox となるとハイパーリンクの利用は HTML となりそうだし、HTML の編集はしたくない。 話は戻るけど、もちろん、チームメンバー5人を越えそうなプライベートリポジトリが必要になりそうなところであった。 しかし、プライベートなリポジトリが欲しいのであれば自分で作ればよく、いままでそうしてきた。今回は GitHub のサービスを利用したいのである。 コードレビューするための Pull Request 機能、課題を管理のための Issues機能である。 BitBucket は自分に書き込み権限があるリポジトリへのプルリクエストができませんでした。 また、Issues で画像をつかいたい場合、自分でどこかにアップロードしないといけないみたいでした。 そのあたりが、「コードレビューのする際の不便さを感じそうだった」というのもあります。 そんなわけで、お世話になりっぱなしの GitHub さんに課金を決めたという話でした。 課金までの流れ 折角なので、課金までの流れを紹介しておきます。 まず、GitHub にサインインした状態で http://github.com/ へアクセスします。 そこから、設定画面に移動します。(下記画像参照) つづいて、左のメニューから Billingを選択します。 次にお好みのプランをクリックします。Micro を選択しました。 するとクレジットカードの入力を要求されます。適当に入力します。 これで終わりです。こんな表示になりました。 料金を考えると1リポジトリあたり月100円だと思うことにしております。

no_picture

github-pages Gem というのが用意された - Github Page で使う gem のバージョンをあわせてくれる

Github Page は Jekyll プロジェクトを push すれば HTML に変換してくれます。 これを使う場合、Github 側とローカルで確認するときの Gem のバージョンを揃えておきたいです。 そのために Gemfile を記述しますが、github-pages という gem が用意されました。 というわけで、試してみた。 source 'https://rubygems.org' gem 'github-pages' bundle install とか実行せばあ必要な gem が手に入ります。 以前は、 source 'https://rubygems.org' ruby '1.9.3' gem 'jekyll', '=1.1.2' gem 'liquid', '=2.5.1' gem 'redcarpet', '=2.2.2' gem 'maruku', '=0.6.1' gem 'rdiscount', '=1.6.8' gem 'RedCloth', '=4.2.9' gem 'kramdown', '=1.0.2' のように書く必要ありました。 とてもすっきりしています。 利用する gem が更新されても bundle update ですむので、とても嬉しいですね。 もっと具体的に 依存している Gem の情報は gemspec にあります。 github-pages

no_picture

Github の Feed が溜りすぎてやばい。ついでに気になるのをメモっとく - すごい広島 010

この記事は すごい広島 #010 でやったこと。 GitHub の News Feed が読めてない、ヤバイ。6月17日から溜まってる! この時間を使って眺めて気になったのを簡単にまとめる。 ようするに、頭の中を垂れ流すだけの記事です。 One Hundred Ideas for Computing One Hundred Ideas for Computing 「クラウドコンピューティングでやりたい100のこと」といったころなのでしょうか。本当に100個あってびびった。ネタがないときのインプットにしたい。 あと、すでに存在しているものや、似ているものにリンクが貼られていて面白いです。100個あるとタイトルを読むだけで精一杯でした。 http_configuration http_configuration ruby の gem。Rails の plugin としても利用可能らしい。 NET::HTTP のグローバル設定が可能らしい。タイムアウトする時間やプロキシを登録しておけば、自動で引き継ぐ感じなのでしょうか。試してないから知らない。 config = Net::HTTP::Configuration.new(:proxy => :environment, :read_timeout => 10, :open_timeout => 5) config.apply(:read_timeout => 5) do Net::HTTP.get('http://example.com/') end pjaxメモ pjaxメモ ブラウザの履歴操作のメモのようだ。整然としていてナイスである。 まだまだ充実していくんだろうか。 glim GRUB2 Live ISO Multiboot - glim いろんなOS Live CD をブートできる USB メモリや CD を作成できるみたい。 CDイメージを用意する必要があるのか気になったけど、そこまでは見ませんでした。

no_picture

Jekyll を使ったGithub Pages で関数呼び出し的なことをする

この記事は すごい広島 #005 で試したことです。 Github Pages で Jekyll を使う場合は機能拡張などすることが基本的にできません。 関数のように汎用のHTMLを作成して、引数で動作を変えるようなことがしたい。 本来ではあれば Liquid のカスタムタグなどが使えるのですが、jekyll が safe モードで動いているので、カスタムタグを作成することができません。 しかし、 liquid の includeタグ を利用することでそれっぽいことができます。 流れは あらかじめ変数をセットしておく include を使う セットしておいた変数で分岐したり、表示内容として利用する となります。 変数 変数をセットするには FrontFormatter を利用するか、liquidの assignタグ か caputerタグを利用することになります。 FrontFormatterを使う FrontFormatter は ページの先頭に書く yaml の部分です。 例: title: "すごい広島 #5" date: 2013-06-19 19:00:00 place: tullys page.place という変数を追加して tullys という文字列をセットできます。 assign を使う Liquid の assign タグを利用して { % assign place = tullys % } place という変数を追加して tullys

no_picture

Github Page で公開する サイトを ローカルで preview するのに使ってる方法

すごい広島 #2 でしたことを書きます。 日記のほうはこちら 2013年8月23日追記。下記の方法を改良したものがあります。 ローカルサーバ起動と同時にブラウザで開く。 - Jekyll とかで。 以上、追記終了。 私は、Jekyllを使用したサイトをプレビューする際に、jekyll のインターフェイスが変化しても、または、jekyll 以外のものを使用しているときのことも考えて、 rake preview でサイトのプレビューをできるようにしています。 「Octopressでも、Hakyll でも Jekyll でも rake preview にしたいんだ!!」 具体的には以下のような、Rakefile を作成しました。 desc 'preview する。 http://localhost:4000/' task :preview do sh 'bundle exec jekyll serve --watch' end Jekyll は v1.0.0 で preview するためのコマンド名が変わりました。 あとは、他の人が gem のインストールのを軽減するために、Gemfile も書きました。 source 'https://rubygems.org' gem 'jekyll', '=1.0.2' gem 'liquid', '=2.5.0' gem 'redcarpet', '=2.2.2' これで、ruby と bundler さえ入っている人は bundle instnall というコマンドを実行すれば、サイトのプレビューができるようになります。 bundler は gem

no_picture

Github の楽しみ方

みなさん Github を楽しんでいますか? まだ利用してない場合は、利用しましょう。 「利用しはじめたけど、もう一歩進みたい…」という人のために、私なりの楽しみ方を紹介しておきたいと思います。 今回は以下の遊び方について書きます。 友人のリポジトリにちょっかいを出す 有名なリポジトリに名前を残す 毎日活動して Longest Streak の記録を更新する 友人のリポジトリにちょっかいを出す Github は 「SNS」 です。 SNS なのでは人とコミュニケーションをとって遊びましょう。 なので、コミュニケーションをしましょう。 Github ではユーザ同士がコミュニケーションを取る主な方法は コミットへのコメント Issues Pull Request があります。 こういったものはまずは友人に対して行うのが気軽で、オススメです。 しかし、リポジトリを作成したことや、コミットされたことに気づかなければ、コミュニケーションを取る機会がありません。 友人がリポジトリを作成したことに気がつくためには、友人をフォローしておくことです。 以前紹介しているので、ここを読んでいる方はフォローしていると思います。 これで News Feed を見る癖がついていれば、友人がリポジトリを作成したことに気がつくようになると思います。 しかし、コミットされ、プッシュした情報は流れてきません。プッシュされたことを知りたいなら、watch をしましょう。 Watch する watch をするには リポジトリのページへ移動し、以下の画像の示す部分を Watching にします。 watch するとそのリポジトリへの push や Issuesの作成、 Pull Request の作成などの情報が流れるようになります。 ここまで来れば日々チェックして、相手の隙を伺いアタックをしていきます。 コミットへのコメント Github ではコミットに対してコメントをすることができます。 また、コミットに関連しているファイルの特定の行にもコメントを付けることができます。 まずは、Github で コミットを見てみましょう。 参考用に利用するリポジトリは eiel/hiroshima_hall にしました。 コミットを見るにはコミットを見つける必要があります。 一般的な方法としては 「コミットの一覧」 > 「コミット」と進めばコミットのページへいけます。 コミットの一覧を見るには以下の画像を参考にしてください。 そこからコミットを見るには、見たいコミットの`コミットIDをクリックします。

no_picture

広島Ruby勉強会 #30で Liquidの簡単な説明をした

広島Ruby勉強会 #030で Jekyl の中で使用されている テンプレートエンジン Liquid のざっくりとした説明をする LT しました。 大したネタもないし、そんなに凝ったこともしてないですが、公開しておきます。

no_picture

ruby-build の プルリクエスト バトル

ネタです。 最近もろもろな事情で Ruby がリリースされることが多かったですが、ruby-build の更新を待っていた人はどれくらいいるでしょうか。 みんな待ちきれなくて自分で ruby-build のレシピを書いたんではないでしょうか? そして「俺がと プル リクエストをおくるんだ!!」と燃えたのではないでしょうか? これを Ruby のリリースがあるたびに発生する ruby-bulild プルリクエストバトルだと勝手に想像して楽しんでいます。こんばんは。 僕の場合はだいたいなぜか rbenv のほうをみにいって、「まだ更新がないないなー」っておもってレシピをかくんですが、書いたあとに ruby-build だったと気づく馬鹿なことをしているだけだったりしますが 今日も Ruby 2.0 のリリース がありましたが、このプルリクエスト バトル の行方はどうなったのでしょうか。 https://github.com/sstephenson/ruby-build/pull/299 https://github.com/sstephenson/ruby-build/pull/301 同じ Issue を立てないように気をつけたいですね。 それと Ruby 20周年おめでとうございます。 ついでにレシピの書き方 ネタだけで終わるのもあれなので。 ~/.rbenv にインストールしている場合は ~/.rbenv/plugins/ruby-build/share/ruby-build/ にレシピが配置されています。 今回の 2.0 の場合は install_package "openssl-1.0.1e" "https://www.openssl.org/source/openssl-1.0.1e.tar.gz#66bf6f10f060d561929de96f9dfe5b8c" mac_openssl --if has_broken_mac_openssl install_package "ruby-2.0.0-p0" "ftp://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p0.tar.gz#50d307c4dc9297ae59952527be4e755d" とか前のバージョンを参考にして書けばよいです。簡単ですね。 なんでこんなことかいたのか なんで push してないんだー。って怒られたので Ruby 2.0 リリース & 20 周年 おめでとー。とかそういう記事書きたいじゃないですか

no_picture

Github で Jekyll を使う時に調べたこと

Github で Jekyll を使うときにできることとか調べたので整理しておきます。 今日の成果物。 この記事をいきなりポーンと書いても仕方ない気がして前の記事を書きました。 Github Pages について整理しておきます Jekyll を利用するかしないかの判断材料などに利用してください。 利用できる マークアップ HTML Markdown Textile 関連する gem liquid- テンプレートエンジン redcarpet - 高機能高速動作な Markdown maruku - 高機能な Markdown rdiscount - 高速動作な Markdown RedCloth - Textile Pygemnts.rb - シンタックスハイライト できること Layoutの利用 - ネスト可能 includeの利用 - Jekyll Boostrap がかなり利用してる様子 記事の作成 atom.xmlや記事一覧の作成 - site.posts 変数から参照可能 シンタックスハイライト できなかったこと Rubyのコードを書いて改造 pluginの利用 対応するファイルのないものを自動生成 拡張タグ 利用できるタグの追加 gem を読み込んで情報源などにする Scss, Sass, Less などメタCSSの利用 CoffeeScript などの利用 Jekyll Bootstrap がしてること

no_picture

Github Pages について整理しておきます

Git の練習を兼ねて Github できることといえばひとつとして Github Pages があります。 ウェブサイトを Git で管理して、Github へ プッシュすれば公開できるというものです。 使い方などは 公式のヘルプに書かれていますが自分が Github Pages を使おうとした時に知りたかったことを整理しておきます。 細かいことについてはあまり書きません。 Github Pages の特徴 Github Pages の種類 ユーザぺージ または グループページ プロジェクトページ Github Pages の構築方法 Jekyll 静的ファイル 独自ドメインの利用 Github Pages の特徴 公開リポジトリで作れば無料。容量制限もないと言ってよいです。 CGI,PHPなどで動的ページは生成できません。 代わりに Jekyll というアプリケーションを使い github にページを生成させることができる Github Pages の種類 Github Pages には 2種類あります。 ユーザページ または グループページ プロジェクトページ ユーザページ グループページ ユーザページ と グループページは同じ機能と言えるので同じものと考えてください。 ユーザページはアカウントにひとつだけ作れる Github Pages になります。 グルーページは Github には Organization という グループを作る機能があります。

no_picture

Git がわからなくても Github を利用しよう

みなさん Github を利用していますか? 「Git がわからないから…」と、そんな理由で使わないのはもったいないです。 Webや開発に携わる人間であれば、例えプログラムを書かなくても、Github へアクセスする機会は増えているのではないでしょうか。 Webの人であれば jQueryのプラグインを探したり、サンプルコードが Github においてあったりすると思います。 しかし、いきなり使いこなすのは難しいので、まずは以下のことをはじめてみることをおすすめします。 アカウントを作る 知り合いや気になる人をフォローする 自分が利用しているリポジトリや気になるリポジトリにスターを付ける News Feed を読む 日本人がやってるネタリポジトリの Issues やPull Requestsに絡む Gitを利用しなければいけない機能はとりたててありません。(Pull Requestには突っ込まないで) アカウントを作る まず、アカウントがないと何もできません。作りましょう。 Githubのトップページに “Sign up for free” というボタンから作成することができます。 知り合いや気になる人をフォローする 友達や気になる人をフォローしましょう。相手がフォロー返しをしてこなくても気にすることはないです。News Feed を読む ための布石にすぎません。 フォローすると News Feed にフォローした人の活動が表示されるようになります。これを見るのが目的なので、自分が興味のある活動をしている人がおすすめです。 あまり活動的な人をフォローするとフィードがどんどん流れてしまうので、初心者にはおすすめできません。 フォローする相手がいない場合は、あまり活発でない リポジトリをウォッチするという手もあります。 フォローするには https//github.com/ユーザ名 にアクセスして、画面右上のほうに Followというボタンがあるのでそれをクリックします。 例えば、私をフォローしたい場合は、http://github.com/eiel にアクセスします。 自分が利用しているリポジトリや気になるリポジトリにスターを付ける スターというのは、お気に入り、ブックマーク、いいね!のような機能です。ソーシャルブックマークの効果を感じていれば、説明は不要だと思います。 スターをつけると、自分の活動に このリポジトリにスターをつけました と流れるので、あなたをフォローしている人が目にすることになります。 そうすると、そのリポジトリを見にいく人が増えますので、そのリポジトリがより活発になる可能性が高くなります。 応援したい!! と思えば、すかさず押してしまっても良いでしょう。 News Feed を読む ここが本記事の主旨です。 News Feed を読みましょう。 News Feed はログインした状態で、Githubのトップにアクセスすると閲覧できます。 友人もフォローしたし、スターをつけることを学びました。 友人がスターを付けたことがわかるはずです。

no_picture

Github pages が反映されない?と思ったらスパム扱いされてるかも

ここ最近 github に push しても Github pages が反映されない現象に悩まされておりましたが、スパム判定されていたらしいです。私のgithubのprofileページが私以外の人がみれなくてスパム判定されていることが発覚しました。同じようなことに悩まれることがあれば、運営に確認してみてはどうでしょうか。