2012年08月20日

FW:メンテナンスのお知らせ(2012年8月23日実施)

メンテナンスのお知らせ(2012年8月23日実施):Seesaaからのお知らせ

■ 期間
2012年8月23日(木) 午前2時 から 午前8時 までを予定
*メンテナンス終了時刻は、作業状況によって前後する場合がございます。

■ 範囲
・Seesaaアカウントの登録、変更
・Seesaaブログの閲覧、投稿など操作全般

ラベル:Seesaa_blog
posted by 天井冴太 at 00:38| Comment(0) | TrackBack(0) | Information | 更新情報をチェックする

2012年07月22日

Qiita user following tags feed - Qiitaでフォロー中のタグを付けられた新着記事を取得するfeedを吐くYahoo!Pipesを作った

タイトルは一息に読む(変に長くてごめんなさい)。

作成途中に一度Qiitaに投稿したけど、どうも上手く動いてるようなので公開。"どうも"なんて不確かな表現なのはPipeの動作確認が超絶面倒だから。お察しくださいな。

コレは何?

任意のQiitaアカウントがフォローしているタグを付与された新着記事をfeed(RSS等)として出力するPipe。

例えば私の場合、アカウント名は"AmaiSaeta"なので、AmaiSaetaがフォロー中のタグ - Qiitaでリストアップされる24種(2012年7月22日現在)のタグが対象になる。

使い方

Qiita following tags feedにアクセスし、feedを取得したいユーザーのアカウント名を"Input a user name."テキストフィールドに入力しRun Pipe。後は"Get as RSS"のリンクをフィードリーダーに登録するなりなんなりお好きなように。

稀にtimeoutしている……ような気がする。Pipesレベルじゃ対処法が思いつかないので、仕様って事で。

ラベル:Qiita pipes Feed
posted by 天井冴太 at 11:00| Comment(0) | TrackBack(0) | Tool | 更新情報をチェックする

2012年07月19日

Yahoo! Pipesのtips的な何か

Pipesの用語がイマイチ分かってない。Moduleの名称や作成画面左下の説明文から推察して使ってる。

既存sourceに別のelementを足す

既存のsourceに、別のelementを足したい時。

Item BuilderとUnionを使うと別のelementになってしまう。[Yahoo!Pipesで既存sourceに別のelementを足す: Item BuilderとUnionでは、別のelementになってしまう]

正解はRenameとRegexを使う。先ずRenameで挿入先sourceの適当なelementをCopy Asし、次にその要素の中身をRegexで入れ替える。[Yahoo!Pipesで既存sourceに別のelementを足す: Renameでelementをコピー(Copy As)し、その値全体をRegexで書き換える(replace [^.*$] with [追加する値])と上手く行く

或るelement内のtextに別のtextを連結する

取得したURLに別のqueryを追加したい場合とか。

Regexを使う。適当なタグ(例図では"//TAG//")を決めて、それの追加、置換という順で処理。[Yahoo!Pipesで或るelement内のtextに別のtextを連結する: 連結位置にタグを追加(replace [^(.*)$] with [$1タグ文字列])し、そのタグを置換(replace [タグ文字列] with [連結したい文字列])するという手順をとる]


うーん、「痒い所に手が届く」ようなModuleが足りない。上に挙げた手もこうやってメモっとかないと1週間後には何故こうしてるのか忘れてそうだ。個人的にはelementの値をtextで取得する手段が欲しい。あとコメントを付ける手段。何かそれを実現するトリックとか在るんだろうか?

あと、Pipesって文字列で表現出来ないからテキストで書きにくいね

ラベル:pipes
posted by 天井冴太 at 20:11| Comment(0) | TrackBack(0) | Hack | 更新情報をチェックする

2012年07月05日

コミットログの書き方のアレコレ細かい点

  1. コミットログは現在形?過去形?それとも?
  2. 続: コミットログは現在形?過去形?それとも?

この話題の細かい点。

  • アンケートの2問目で、ついでにログ書く時に使っている言語について聞いてみたんだが、母語でも、住んでる地区の言語でもない、別の言語と回答する人が多かった。やっぱり英語なんだろうか。使用言語とその理由も併せて聞けばよかった。しまった。
  • 某所で「Git使いはコミットメッセージの書き方を気にする人が多い印象が有る」という意見が……そうなんだろうか。真っ当にVCS使い始めたのがGitからだしよく分からない。
ラベル:vcs
posted by 天井冴太 at 22:40| Comment(0) | TrackBack(0) | Tool | 更新情報をチェックする

続: コミットログは現在形?過去形?それとも?

というわけでアンケートを採ってみた結果。

コミットログは現在形?過去形?それとも……(択一)

現在形
5
過去形
3

現在形で書く人の方が多いらしい事が分かった。

まぁ、回答数が少なすぎて、有効な結果と言えるのかかなり怪しいけど……

とはいえ、役に立つ知見を得られたのも事実。

id:yossiy7yossiy7 現在形・過去形というのは、ちょっと違っていて、実際は「誤:??→正:○○」とかそんな感じで一応過去形なので過去形にしたけど、両方ってのが正解かな。

「文章ではなく、記号的に記述する」というパターンは完全に想定外だった……

コメント欄でid:tyruさんが言及しているStack Overflow上の質問に付けられたこのコメント引用している文章には以下の様に書かれている。

The use of the imperative, present tense is one that takes a little getting used to. When I started mentioning it, it was met with resistance. Usually along the lines of “The commit message records what I have done”. But, Git is a distributed version control system where there are potentially many places to get changes from. Rather than writing messages that say what you’ve done; consider these messages as the instructions for what applying the commit will do.

自分の(悲惨な)英語力を動員して読んでみるに、「Gitは分散VCSなので、(他の開発者の為に?)『そのコミットで何を行ったか』ではなく『そのコミットを適用する事で何が起こるか』を記述しろ」という事らしい。

私は今まで、「コミットログとは(ログの名の示す通り)変更内容を記述する物だ」という認識だったので、このようなコミットログの捉え方は考えた事がなかった。成る程この考え方ならば過去形はおかしいな。

しかし、その考え方は、適用する(pullしてくる)コミットを好き勝手に選べる環境じゃないと意味を成さないような……例えば、オリジナルのリポジトリからcloneし、その後変更点をpullする迄に、オリジナルに複数のコミットが追加されていた場合、「1つ目のコミットは無視するが、2つ目のコミットはpullする」のような場合(そもそも出来るのだろうか?)でも問題ないと保証出来る時に限られるのではないか?

それはかなり難しいと思うので、私はこのガイドラインには否定的。

尤も、件の365Gitには次のようにも書かれている。

Having said all that - it’s your code, your repository: so set up your own guidelines and stick to them.

あんまり気にせずに自分の好きなように運営するのが一番なのかもしれない。

ラベル:vcs tool
posted by 天井冴太 at 22:23| Comment(0) | TrackBack(1) | Tool | 更新情報をチェックする

2012年07月04日

getsが返す文字列の末尾には漏れなく改行が付いてくる

お供が付いてくる!!!

v = STDIN.gets
if    v == "foo"   then puts '"foo"'
elsif v == "foo\n" then puts '"foo\n"'
else                    puts 'other'
end

このコードで、"foo"を入力した場合、以下の出力となる。

"foo\n"

改行要らない場合は、vに対しchomp呼ぶ。getsと同時にやっちゃうのが妥当か。

v = STDIN.gets.chomp
OAuthの認証で、STDIN.getsでPINコード入力させて、それをそのままoauth_verifierとして使ってたら、まぁ認証が通らない事通らない事。暫く嵌った。

参照文献

Rubyist Magazine - Ruby ではじめるプログラミング 【第 2 回】

ラベル:ruby
posted by 天井冴太 at 03:50| Comment(0) | TrackBack(0) | Study | 更新情報をチェックする

2012年06月25日

コミットログは現在形?過去形?それとも?

という@takano32のtweetが気になった。

自分自身は英語の現在形で書いている。特に深い考えが有っての事ではない。以前何処かで「過去形は使わない方が良い」という話を読んでそれに倣っているだけだ。が、考えてみたら何やら妙だ。

文法的に変な気がしてきた……

どうにも気になるのでGoogle先生にお伺いを立ててみる。"コミットログ 過去形"で検索し、検索結果5頁分からそれっぽい物をばーっと開いてみる。

うーん、人に依りけり。同じように悩んでる人(ログ)も。

イマイチはっきりしないので、人力検索はてなにアンケートを立ててみた。はてなのアカウント持ってる人は是非回答を寄せて欲しい。

貴方のコミットログの書き方について - 人力検索はてな

ラベル:vcs
posted by 天井冴太 at 00:46| Comment(0) | TrackBack(2) | Question | 更新情報をチェックする

2012年05月09日

Androidのwebブラウザ(コンポーネント)ではWeb Workersが使えない

……という、ただのメモ。

Disable workers

This is because V8 on Android does not have the required locking.
Also disables channel messaging, which is used only with workers.

2.1以前では使えたけど、実装に問題が有ったので無効化したよ!ってかんじかな(あまり詳しく追いかけていない)。When can I use Web Workers?に拠ると、4.0でも対応してないようだ。

マジかー。使おうと思ってたんだけどなー……

ラベル:android javascript
posted by 天井冴太 at 00:42| Comment(0) | TrackBack(0) | Networking | 更新情報をチェックする

2012年03月29日

Herokuのconfig varをローカル環境下のスクリプト内で取得するには

2012年11月5日追記

現在、heroku gemのAPIを用いてのHerokuへのアクセスはdeprecatedになり、替わりに、heroku-apiを用いるようになっている(herokuコマンド自体は引き続き利用出来る)。
Herokuのconfig varをローカル環境下のスクリプト内で取得するには(heroku-api版)を参照されたし。


HerokuとGitHubの両方にプッシュできるようになったのはいいけど、例えばTwitterOAuth認証用のトークンとか、何かのAPIを利用するためのAPIキーとか、あるいはもっと大事な何かのパスワードなど、秘密にしておきたい情報は、GitHubにプッシュしてしまうと全世界に公開されるので非常にマズい。

かといって書いておかないと、Herokuにプッシュしたときに情報が足らなくてアプリが正常に動かない。

どうするん?毎回消したり書いたりするの?

config varというのは、上記のようにHerokuとGitHubの両方にプッシュする時の秘密にしたい値の扱い - アインシュタインの電話番号?に記されているような要求をこなす時に使うheroku config:addで追加する値の事ね。
ENVでアクセス出来るし、正体はただの環境変数だと思うが、heroku help configにはconfig varsと表記されてるのでそっちの表記を採用。

さて、このconfig vars、ruedapさんも言及してるように、Herokuの環境下でしか利用出来ない値で、ローカル環境での開発時にはENVに無い。彼も言っているような、ローカル環境かどうか判定して、同一内容をENVに突っ込むスクリプトをrequire、そのファイルは間違ってHeroku側のリポジトリにcommitしないように.gitignoreに書いておく……というのがサッと思いつく対処法か。だが、値の追加/編集時に、heroku configとそのスクリプト、両方を同一内容になるように保持するというのは流石にめんどくさい。

そんな馬鹿な。
おかしい。
あり得ない。
ぜんっぜんprogrammableじゃない。
そもそも、herokuコマンドはgemで導入する物だし、もしかしてライブラリとして利用する方法があるんじゃないの?

という訳で、herokuコマンドのソースを斜め読んでみると、次のようにしてRubyのスクリプトから取得出来る事が分かった。

#!/usr/bin/ruby
require 'rubygems'
require 'heroku'
require 'pp'

EMAIL       = '(Herokuに登録した時に使ったメールアドレス)'
PASSWORD    = '(Herokuのパスワード)'
APPLICATION = '(アプリケーション名)'
KEY         = '(値を取得したいconfig varのKEY)'

heroku = Heroku::Client.new(EMAIL, PASSWORD)

# APPLICATIONの全config varを取得
vars   = heroku.config_vars(APPLICATION)
pp vars	# heroku.config_varsの戻り値はただのHash

# 特定のconfig varを取得
var    = vars[KEY]
p val

……コード中にメールアドレスだのパスワードだの埋め込むのは美しくない。何の為にconfig vars使おうとしてるのやら。

もうちょっとherokuのコードを読み進めてみると、既にheroku loginしているならば、Heroku::Client.newの替わりにHeroku::Auth::clientでも良さそう。

という事は、実際に使う時は次のような感じだろうか。

# 既にheroku loginしている事前提
require 'rubygems'

# ...snip...

if !ENV.key?('VAR1')	# config varのどれか一つでも存在しない場合
	require 'heroku'

	config_vars = Heroku::Auth.client.config_vars(APPLICATION)

	# PATHやLANGといったheroku config:addで登録した物以外も出てくるので、愚直に代入処理をしている
	ENV['VAR1'] = config_vars['VAR1']
	ENV['VAR2'] = config_vars['VAR2']
	# ...以下全てのconfig varについて同様に
end

#...snip...

うーん、ローカルかリモート(Heroku上)かの判定をENV.key?で行うのは何か変だな……もっとスマートな方法が在りそうな気がするが……

ラベル:ruby heroku
posted by 天井冴太 at 03:05| Comment(0) | TrackBack(1) | Tool | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は90日以上新しい記事の投稿がないブログに表示されております。