ボードゲーム界隈での興味深い４つの試み - One For Owl
今回は最近ボードゲーム界隈で見られたいくつかの興味深い挑戦について紹介したい。 「GitHubでアナログゲームを開発する」 「クラウドファンディングでアナログゲームの資金集め」 「アナログゲームの制作ハッカソン」 「アナログゲームのダウンロード頒布」 「GitHubでアナログゲームを開発する」 『Githubでアナログゲームを開発する | Open Design Games』 GitHubというのはバージョン管理システムの一種だ。複数のファイルを管理して「いつ」「誰が」「何を」編集したか記録しておき、ある時点まで状態を戻したり出来る。一般にはソフトウェアを複数人で開発する際に使うが、これをアナログゲームの開発に利用してみようというのが@fullkawa氏の試みである。 @fullkawa氏が行ったのは自身が制作するdqz(a.k.a Xan)というアナログゲームのルールやカードをファイルと
Git の diff を美しく表示するために必要なたった 1 つの設定 #git - 詩と創作・思索のひろば
Git に同梱されている contrib/diff-highlight を使います。 あとは README に書いてあることの引き写しですが、PATH の通ったディレクトリに置いて、~/.gitconfig に以下のように設定を書く。 [pager] log = diff-highlight | less show = diff-highlight | less diff = diff-highlight | less すると、対応するコマンドの出力がこんな風になります。 行レベルの diff に加えて、単語レベルでの diff もハイライトされ、GitHub での diff のように描画されました。 組み込みのオプションで --color-words というのがありますが、こちらを使うと行レベルの diff 情報が失われるので、少し不便だったわけですね。とすべて README に書いてあ
探検！編集、執筆工場〜某媒体の記事ができるまで - Fragments of Works
明けましてメリークリスマス！ 2013年の12月がやってまいりました。 CodeGridの記事ができるまで Editors' & Writers' Advent Calendar 2013の第1日目です。 第2日目は、えどさんの記事を書くときに気をつけていることです。 この記事では「探検！編集、執筆工場〜某媒体の記事ができるまで」と題しまして、CodeGridというフロントエンドまわりの技術情報を配信するサービス（有料）の記事ができあがるまでをご紹介したいと思います。 対象としては、技術者でちょっとなにか記事を書いたりしたいんだよね、という方や、技術書の編集に関わる方を想定しています。エンジニアではないフツーの編集者のワークフローなので、そこまで複雑なことはしていません。 技術情報系の記事の特徴 技術情報記事といいますと、まず情報自体に間違いがあってはいけません。そのため執筆者（いい感じの
tig なんて目じゃない！ Git のログ系 Vim プラグイン gitv ＆ gitv をGit 統合インターフェース化する最強の設定 - 反省はしても後悔はしない
この記事は Vim Advent Calendar 2012 の 168 日目の記事です。 昨日は id:yonchu さんの accelerated-smooth-scroll という Vimプラグイン を作った (Vim Advent Calendar 2012, 167日目) - よんちゅBlog でした。 はじめに 最近、Git のログを見る系のエントリが多い気がします。今回の Vim Advent Calendar でも はじめての unite source(unite-tig) - Design x Verification vac143 - YouTube Vimでgitのログをきれいに表示する - derisの日記 という記事がありましたし、また最近 git? tig! | Atlassian Japan CUI で Git 使うなら入れておきたいツールまとめ | バシャロ
pull request を利用した開発ワークフロー
pull request を利用した開発ワークフローの話しですが、あんまりプルリの話ししてないし、コードレビュー的なお話しが多いです…。
2013年、WebデザイナはGitを学ぶべきか？ そして1993年、編集者の7つ道具とは何だったか？ - QA@IT公式ブログ
WebデザイナはGitを学ぶべきでしょうか。答えはイエスだと思います。やらなくてもいいかもしれませんが、やればアドバンテージになるでしょうし、やらないことが今後マイナスになっていくように思えます。 仕事に必要な道具は常に進化します。その変化の過程で「ツールは本質ではない」と、うそぶいたまま時代の波に乗り遅れた人たちを過去に少なからず見て来ました。ツール（道具）が本質でないのは当然です。でも、そのときどきに使うべきツールを使わなければ、良い仕事はできませんし、市場ニーズに応えられません。 そのことを個人的な体験談を混じえて書いてみたいと思います。 今から20年ほど前、学生時代にバイトをしていた出版社で呆れられました。人文系の書籍や雑誌を手がけてきた筋金入りの編集者だった上司は、こう言いました。 「キミは編集者の7つ道具も知らんのかね！」 1993年時点で雑誌や書籍の編集者が必ず持っているとさ
「githug」でgitの基本操作を算数ドリルみたいに学ぼう！ | Act as Professional
GitHubのイベントである「The GitHub poweredby Agile渋谷 〜日本のSOCIAL CODINGの今を見る〜」の懇親会を受付始めました@HIROCASTERでございませう。 イベント参加者以外でも参加可能のため、イベントは補欠だったけど、どういうふうにGitHubを使っているのか聞きたい人は、ご参加ください。（イベント参加者優先で、空気読んで登録してください） イベントではGitHubの話をするので、Gitが使えることが前提になっています。 そこで、Gitの基本操作方法を学べる「githug」を紹介します。 githug Gazler/githug「githug」はgitの基本操作を実践的に学ぶための良いソフトウェアです。 特に他のバージョン管理システムを使ったことのある人がgitの基本操作だけを学ぶだけならちょうど良い。 インストールgemで公開されているのでイ
branchを切った時点のコミットとbranchの最新コミットとのlogとdiffをみたい - （ひ）メモ
Pro Gitから図を引用すると、こういう 場合に、分岐した時点のmasterとexperimentの先っちょのlogやdiffをみたいというお話です。実際的には、topic branchをmasterにマージする前に変更点を確認したいといった局面です。 log logの場合は「..」です。 $ git log --pretty=oneline master..experiment ec8428d4d1884d3413e0949603c0c5cdd8aef414 D 863f5738a395fe090afaeaa120b67c45d65131c4 Clogにおける「..」についてPro Gitから引用すると、以下のように書かれています。 これは "experiment からはたどれるけれど、master からはたどれないすべてのコミット" という意味です。 Git - リビジョンの選択 一
Mac で heroku を触ってみる - プログラマー探求日記
d:id:nshibazaki:20110723 の続きです。 今日は、公式サイトのGetting Started の"Getting Your App on Heroku" のところをがんばります。 主に、使い方 サンプルアプリの作成 デプロイする前に、サンプルアプリの作成を行います。 ここでは簡単な、Message Board を作ります。 以下のコマンドを実行してください。 $ rails new myapp $ rails generate scaffold message name:string text:string それでは、本題であるデプロイ作業に移ります。 デプロイ手順 ここでは、以下のドキュメントを参照しています。 Getting Started with Heroku (Getting Your App on Heroku) Getting Started on He
GitHubのセキュリティホールがふさがったのでSSH Keyを確認しよう - ただのにっき(2012-03-08)
■ GitHubのセキュリティホールがふさがったのでSSH Keyを確認しよう 先日、Railsアプリにありがちなセキュリティホールがあることが判明したGitHub。詳細は@sora_hによる「github の mass assignment 脆弱性が突かれた件」が非常によくまとまっているので参照のこと。脆弱性の内容そのものもだけど、開発者として脆弱性指摘をどのように受容、対応すべきかを考えさせられる事例だった。 で、これはようするに赤の他人が任意のリポジトリへのコミット権を取得できてしまうという事例だったのだけど、脆弱性の内容をみる限りその他のさまざまな入力もスルーされていた可能性がある。ということで、その対策が(おそらく)なされたのだろう、今朝になってGitHubから「SSH Keyの確認をせよ」というメールがいっせいにユーザに配信された。3日で修正とか、GitHubの中の人もずいぶん
git rebaseって超便利じゃね？ - Seasons.NET
Gitでとても便利だと思っているのが、rebaseというコマンド。 ブランチを切った時点からオリジナルは刻一刻と変化していくわけで、 自分のブランチはあくまで現在最新のオリジナルに対するパッチである 必要がある場合は、このrebaseというコマンドを使って、オリジナル(HEAD)と マージすると、最新のオリジナル(HEAD)に対して、ブランチを切ったことになります。 これチョー便利じゃね？ 以下、git-rebaseから引用 git-rebase を使用して一連のパッチを最新に保つ リモート追跡ブランチ "origin" の上にブランチ "mywork" を作成し、幾つかコミットを作成したとします： $ git checkout -b mywork origin $ vi file.txt $ git commit $ vi otherfile.txt $ git commit ... m
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
HugeDomains.com
Captcha security check hisasann.com is for sale Please prove you're not a robot View Price Processing
gitでコンフリクトの解決結果を再利用する | Webシステム開発／教育ソリューションのタイムインターメディア
問題 gitでは空気を吸うようにブランチを作り空気を吐くようにマージを行います。 gitでマージ作業を中止して元の状態に戻すではマージに際してよくある問題の対処方法について紹介しました。 運用をきちんとしていればトピックブランチのマージでコンフリクトが発生することは稀です。 しかし稀とはいえコンフリクトが発生するときは発生します。 例えば新機能Xの実装を始めるとしましょう: $ git checkout -b topic-x master $ $EDITOR $ git commit -am 'Fix outdated comments' $ $EDITOR $ git commit -am 'Revise existing API' $ $EDITOR $ git commit -am 'Implement X' o---o---o <- topic-x / o---o---o <- m
Accueil
Les Sociétés Civiles de Placement Immobilier (SCPI) se sont imposées comme une solution d'investissement de choix, attirant un nombre croissant d'investisseurs en quête de diversification et de rendements potentiellement plus élevés. Dans un contexte économique en constante évolution, où les investisseurs cherchent à optimiser leur portefeuille tout en minimisant les risques, les SCPI représentent
blog.katsuma.tv
いろんなBlog巡回してると、どこもかしこもgit, gitなのでアカウントだけ作って放置してたgithubで昔に書いたちょこちょこしたコードをコミットしてみました。 github/katsuma katsuma / mt-delicious-bookmark-counter katsuma / flickr-gadget katsuma / sbm-comment さすがにはじめてのgitは戸惑うことばかりだったので、メモを残しておきたいと思います。 gitのインストール 作業OSはMac OSXです。ソースからもインストールできますが、管理しやすいようにMac portsでインストールしてしまいます。 sudo port -d sync # 同期 port search git # cogito, git-core, stgit, cgitあたりがあるはず. git-coreを選択 p
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
こわくない Git
IDEA * IDEA
GitHub - hatena/Git-for-Designers: はてなのデザイナ向けの Git 入門ドキュメントです。
