以前、このブログでVALUは人間性が試させるシステムであるということを少し書きました。
それが、現実の問題になってしまったようです。
『個人価値売買ＶＡＬＵ、ユーチューバー「売り逃げ」騒動』日本経済新聞（Web版）
http://www.nikkei.com/article/DGXLASDZ17H5P_X10C17A8000000/
現実の株では違法である株価操作が簡単にできてしまうんですね。
VALUと合わせて語られることの多い「評価経済」とか「個人価値」などの単語。これらはまだ使われ始めて間もない単語で、具体的なイメージが定着しきれているとは言い難い。
VALU自体が何をするものなのか、まだはっきりイメージできないので、まだ解釈の定まっていない単語と一緒に説明するほうがしっくりくるのかもしれません。
ただ、今回の問題は、ツイッターでの発言から、新たな優待を期待した購入者が殺到したとのこと。
「個人価値」のようなつかみどころのないものに、人気投票的に投げ銭しているわけではなく、具体的なものはわからないまでも新たな優待と、それによるVALUの価格上昇を当て込んだ買いが集まったということですよね。
サービス開始当初に比べて、購入者側の姿勢はだいぶ変わったのかなという気がします。
そんなことを考えつつ、VALUのヘルプをのぞいていると妙な記述がありました。
Q. 「投資目的で利用した場合の罰則などはありますか？」
ん？ VALUって、投資目的の人を集めるシステムなんじゃないの???……と、思ったら、
A. 「これらの行為を発見次第、退会もしくは取引停止等の対応を行う可能性があります (https://help.valu.is/article/98-article)」
あれ？
まぁ、確かに「換金性の高い優待や、金銭的な見返りの約束などを行う」のは、いろいろ規制があって難しそうですが、「VALUの転売による利益獲得のみを目的とする」のもダメなの？ しかも、後者はVALUのトレードができる市場を作っておいて、転売目的はダメって矛盾してない？ 売ったり買ったりできますよ、でも売ったり買ったりしちゃダメ。ってこと？
なんだかこのあたりも、金融庁か何かに気をつかっているのか、しっくりこないですね。
仮想株式としてのVALUもシステムとしてのVALUも、イメージが固まり切っていない様子。買うにせよ売るにせよ、まだまだ、当事者の人間性に依存する部分が大きいですね。
当分はいろいろ変化・調整が必要なようです。
2017年8月17日木曜日
2017年6月7日水曜日
VALUという個人株発行システム(?)が気になったので調べてみました
VALUという個人株発行システム(?)が、なんだかBitcoinに関係しているということで、気になったので調べてみました。
VALUについてまず読むべきはここ
http://nakamurahiroki.com/2017/06/05/valuというサービスを公開しました/
はじめに有名人の名前が出てきますが、このあたりは読者に信憑性を感じさせるテクニックなので、さらりと流しておいて……
結局は、Counterpartyっておもしろそうだから、とりあえずはじめてみたということなんですね。
VALUの仕組みって、Counterpartyの機能そのままですからね。
https://jpbitcoin.com/bitcoin2/counterparty
たぶん、想定していた使われ方は、
という、クラウドファンディング的なことをCounterpartyを介して行うというものだったのでしょう。
さらに、Counterpartyを使えば、その株をトレードできるので、株を発行した直後からIPOしたのと同じ状況が生まれて面白いんじゃないかってことなんでしょうね。
確かこれ、エストニアの話題で似たようなのあったな。
ただ、思った通りにならないのは世の常。
実質、こんな感じになっちゃってるんですね。
http://mecchanikukyu.hatenablog.com/entry/2017/06/05/185628
そりゃまぁ、ネットサービスだし、インフルエンサーの勢いには勝てませんわな（笑）
真面目に使えば社会的に意味のあるサービスなんでしょうけど、ネット上の人気投票みたいになっちゃってるあいだは……ちょっと使えないかなー
株主に対して、ちゃんと返礼できる価値を継続的に生み出せる仕組みがあれば、慌てていま首を突っ込む必要はないでしょう。
投資するほうも、投資に見合うリターンが継続的に得られると思える株が出てくるまで静観するのが正解のような気がします。
ただ、本物の株と違って、返礼は配当金でなくてもボランティア活動みたいな価値でも株主が納得すればいいわけだから、応用範囲は広いですよね。とはいえ、頻繁に資金調達のために株を発行するようでは株価が下がるので投資してくれる人もいなくなるような気がします。
これまでのクラウドファンディングと違うのは、株が継続的にトレードされるので、形はどうあれ継続的な返礼がないと成り立たない。逆に言えば、短期的な成果ではなく継続性を謳ったサービスを展開できるのなら資金調達しやすいということになりますね。
とりあえず、技術的にも社会的にも結構面白いサービスなんだけど、もうちょっと落ち着くまで待ちですかね。
いまのところ、使う側の人間性が試されるシステムだなー（笑）
VALUについてまず読むべきはここ
http://nakamurahiroki.com/2017/06/05/valuというサービスを公開しました/
はじめに有名人の名前が出てきますが、このあたりは読者に信憑性を感じさせるテクニックなので、さらりと流しておいて……
結局は、Counterpartyっておもしろそうだから、とりあえずはじめてみたということなんですね。
VALUの仕組みって、Counterpartyの機能そのままですからね。
https://jpbitcoin.com/bitcoin2/counterparty
たぶん、想定していた使われ方は、
- 個人が自分の株(のようなもの)を発行すると宣言し、株主に対して、独自の返礼の仕組みを提案する。
- その返礼に納得した人たちが、その人の株をBitcoinで買うという形で投資する。
という、クラウドファンディング的なことをCounterpartyを介して行うというものだったのでしょう。
さらに、Counterpartyを使えば、その株をトレードできるので、株を発行した直後からIPOしたのと同じ状況が生まれて面白いんじゃないかってことなんでしょうね。
確かこれ、エストニアの話題で似たようなのあったな。
ただ、思った通りにならないのは世の常。
実質、こんな感じになっちゃってるんですね。
http://mecchanikukyu.hatenablog.com/entry/2017/06/05/185628
そりゃまぁ、ネットサービスだし、インフルエンサーの勢いには勝てませんわな（笑）
真面目に使えば社会的に意味のあるサービスなんでしょうけど、ネット上の人気投票みたいになっちゃってるあいだは……ちょっと使えないかなー
株主に対して、ちゃんと返礼できる価値を継続的に生み出せる仕組みがあれば、慌てていま首を突っ込む必要はないでしょう。
投資するほうも、投資に見合うリターンが継続的に得られると思える株が出てくるまで静観するのが正解のような気がします。
ただ、本物の株と違って、返礼は配当金でなくてもボランティア活動みたいな価値でも株主が納得すればいいわけだから、応用範囲は広いですよね。とはいえ、頻繁に資金調達のために株を発行するようでは株価が下がるので投資してくれる人もいなくなるような気がします。
これまでのクラウドファンディングと違うのは、株が継続的にトレードされるので、形はどうあれ継続的な返礼がないと成り立たない。逆に言えば、短期的な成果ではなく継続性を謳ったサービスを展開できるのなら資金調達しやすいということになりますね。
とりあえず、技術的にも社会的にも結構面白いサービスなんだけど、もうちょっと落ち着くまで待ちですかね。
いまのところ、使う側の人間性が試されるシステムだなー（笑）
2015年9月13日日曜日
「ステークホルダー」ってなに？
最近、本業の方で、システム開発の会議に参加したのですが、その中で、「ステークホルダー」という単語が頻出しました。
ただ、どうもこの単語、人によって少しずつ捉え方が違うようで、なんとなくかみ合わない会議になってしまいました。
Bitcoinの話とは逸れてしまいますが、「ステークホルダー」について少し考えてみたいと思います。
Wikipediaによると、(Wikipedia : ステークホルダー)
よく読むと「直接・間接的な利害関係」といっています。元々の利害関係者のスコープを広げているんですね。ただ、「間接的な利害関係」までを考え出すとキリがありません。
案の定、挙がっている具体例を見ると、消費者から従業員、株主……行政機関まで放り込まれています。目の前のシステムの話をしているにせよ、一企業の経営の話をしているにせよ、消費者から行政機関までの話をし始めたら、全人類のことを考えろといっているのと同じになってしまいます。
なんかぼんやりしたままだなぁと思いながら、もう少し読み進むと、元々は
ある組織(A)を支援しているグループが複数あって(B,C,D)、そのグループの中で、あってもなくてもいい程度の支援をしているグループ(C)を除いたグループ(B,D)が、組織(A)にとってのステークホルダーというわけですね。
わかりやすいですが、この説明のステークホルダーに消費者とか従業員が入ってくるシチュエーションってなんか考えにくくないですか？
「消費者が支援している」とは……まぁ、お金を払って商品を買ってくれるのだから、それを「支援」と考えられなくもないですが、それだと「お客様は神様です」っていっているのと同じで、思考停止ワードですよね。
それに、少なくとも従業員はある組織(A)の構成要素でしょう。従業員が会社を支援しているなんて考えだしたら、労働力の無償提供こそが最大の支援ですからサービス残業どころの話じゃなくなってしまいます。
う～む、しっくりきませんね。
できれば、会議の中で「この人はステークホルダーなの？」ときかれたら、その会議の出席者は「はい」か「いいえ」で答えられるぐらいに定義をはっきりさせてみたい。「まぁ、『はい』ともいえるけど、必ずしもそういうわけではなく、『いいえ』と言わざるを得ない場面もあるんじゃないの？」みたいな言葉を会議で使うと収集がつかなくなりますからね。
もう少し踏み込んで調べてみました。(……といってもGoogle先生頼みですが)
まず "stakeholder" という英単語の成り立ちを考えてみます。
これは、"stake" と、"holder" という2つの単語で構成されていると思って問題ないでしょう。
そもそも "stake" って、いったい何でしょう？
weblioによると、(welbio : stake) 「くい、棒」という意味と、「賭け」、「賭け金」という意味が出てきます。
それを踏まえたうえで、"stakeholder" を検索すると、こんな解説がされていました(最近話題のステークホルダー 英語でどういう意味？)
最初のページで、株主(= "stockholder")という単語に触れられています。株主以外にも枠を広げた言葉として、ストックホルダーをもじって、ステークホルダーと名付けたのだなという予想は付きます。
ただ次のページに、「当初の意味は、賭け金を保管する人、というものでした」と書かれています。いろいろ意味が転じたようですが、「投資＝賭け」と考えると、その掛け金を保管するのは企業ではないでしょうか？ 賭けの当事者である株主がステークホルダーと呼ばれるのはかなりの違和感があります。
ちょっと語呂合わせがうまいだけでこんなに違和感のある言葉が使われるようになるとは思えません。もっと英語圏の人たちがしっくりきているイメージがあるはずです。
それがわからないと、あえてストックホルダーではなく、ステークホルダーと呼んだときにどこまで枠を広げたらいいのか、境界線がわかりません。
仕方がないので、更にGoogle検索を続けます。
すると、こんな解説を見つけました(山内翼のサイト | yamauchi283.com : ステーク・ホルダー（Stakeholder）)
ここには明確にステークホルダーの語源として以下のような説明が書かれています。
ビジネスシーンで使われる言葉なので、お金にまつわる部分に注目し「賭け金」という意味から語源を探ろうとしてしまいがちですが、実は「くい、棒」のほうに意味があったわけです。
杭を打ち、自分の権利を主張する人たちをステークホルダーというんですね。
だから、株を持っていなくても、その会社に対して何らかの権利を主張してくる人たちをステークホルダーと呼ぶわけです。
そう考えれば、お金を払って商品を買ったからには、正当な対価として商品の効用を求め、それが満たされなかった場合、会社に対して苦情を言ってくる消費者や、働いた分の給料を要求してくる従業員はステークホルダーですね。
逆に、株主でも、いちいち権利を主張してこない人がいた場合、その人だけを見ればステークホルダーではないんですね。
これで線引きができました。
この言葉がビジネス用語として定着しやすかったのも、先に「株主＝ストックホルダー」という言葉があったからというのは間違いないでしょう。
他人事みたいなビジネス本によく書いてある「会社は誰のためにある？」という問いに「株主（ストックホルダー）」と答えた経営者に対して、「その考え方は古いですね。これからはストックホルダーだけでなく、ステークホルダー全てのことを考えた経営をしなくちゃいけません」と、いう、半分ダジャレじみたコンサル用語として広がったというのは、容易に想像がつきます。
さらに、有象無象の三流コンサルたちがクライアントを煙に巻くために、どんどん意味を曖昧にしていったというのもわかります。
ただ、会議で使うからには、「とにかく利害関係者ぜ～んぶ」みたいな曖昧な捉え方ではなく、「権利を主張する人たち」という視点で、その関係者が権利を主張するかしないかを意識しながら線引きをしていくべきでしょう。
ただ、どうもこの単語、人によって少しずつ捉え方が違うようで、なんとなくかみ合わない会議になってしまいました。
Bitcoinの話とは逸れてしまいますが、「ステークホルダー」について少し考えてみたいと思います。
Wikipediaによると、(Wikipedia : ステークホルダー)
ステークホルダー（英: stakeholder）とは、企業・行政・NPO等の利害と行動に直接・間接的な利害関係を有する者を指す。日本語では利害関係者という。具体的には、消費者（顧客）、従業員、株主、債権者、仕入先、得意先、地域社会、行政機関など。利害関係者？ そんな簡単な単語でいい切れるのなら、わざわざ言い換える必要ないですよね。また、日本語で「利害関係者」っていうと、直接の発注元と、その先のユーザーぐらいまででしょう。
よく読むと「直接・間接的な利害関係」といっています。元々の利害関係者のスコープを広げているんですね。ただ、「間接的な利害関係」までを考え出すとキリがありません。
案の定、挙がっている具体例を見ると、消費者から従業員、株主……行政機関まで放り込まれています。目の前のシステムの話をしているにせよ、一企業の経営の話をしているにせよ、消費者から行政機関までの話をし始めたら、全人類のことを考えろといっているのと同じになってしまいます。
なんかぼんやりしたままだなぁと思いながら、もう少し読み進むと、元々は
ある組織にとってのステークホルダーを「そのグループからの支援がなければ、当該組織が存続し得ないようなグループ」と定義していたと、あります。
ある組織(A)を支援しているグループが複数あって(B,C,D)、そのグループの中で、あってもなくてもいい程度の支援をしているグループ(C)を除いたグループ(B,D)が、組織(A)にとってのステークホルダーというわけですね。
わかりやすいですが、この説明のステークホルダーに消費者とか従業員が入ってくるシチュエーションってなんか考えにくくないですか？
「消費者が支援している」とは……まぁ、お金を払って商品を買ってくれるのだから、それを「支援」と考えられなくもないですが、それだと「お客様は神様です」っていっているのと同じで、思考停止ワードですよね。
それに、少なくとも従業員はある組織(A)の構成要素でしょう。従業員が会社を支援しているなんて考えだしたら、労働力の無償提供こそが最大の支援ですからサービス残業どころの話じゃなくなってしまいます。
う～む、しっくりきませんね。
できれば、会議の中で「この人はステークホルダーなの？」ときかれたら、その会議の出席者は「はい」か「いいえ」で答えられるぐらいに定義をはっきりさせてみたい。「まぁ、『はい』ともいえるけど、必ずしもそういうわけではなく、『いいえ』と言わざるを得ない場面もあるんじゃないの？」みたいな言葉を会議で使うと収集がつかなくなりますからね。
もう少し踏み込んで調べてみました。(……といってもGoogle先生頼みですが)
まず "stakeholder" という英単語の成り立ちを考えてみます。
これは、"stake" と、"holder" という2つの単語で構成されていると思って問題ないでしょう。
そもそも "stake" って、いったい何でしょう？
weblioによると、(welbio : stake) 「くい、棒」という意味と、「賭け」、「賭け金」という意味が出てきます。
それを踏まえたうえで、"stakeholder" を検索すると、こんな解説がされていました(最近話題のステークホルダー 英語でどういう意味？)
最初のページで、株主(= "stockholder")という単語に触れられています。株主以外にも枠を広げた言葉として、ストックホルダーをもじって、ステークホルダーと名付けたのだなという予想は付きます。
ただ次のページに、「当初の意味は、賭け金を保管する人、というものでした」と書かれています。いろいろ意味が転じたようですが、「投資＝賭け」と考えると、その掛け金を保管するのは企業ではないでしょうか？ 賭けの当事者である株主がステークホルダーと呼ばれるのはかなりの違和感があります。
ちょっと語呂合わせがうまいだけでこんなに違和感のある言葉が使われるようになるとは思えません。もっと英語圏の人たちがしっくりきているイメージがあるはずです。
それがわからないと、あえてストックホルダーではなく、ステークホルダーと呼んだときにどこまで枠を広げたらいいのか、境界線がわかりません。
仕方がないので、更にGoogle検索を続けます。
すると、こんな解説を見つけました(山内翼のサイト | yamauchi283.com : ステーク・ホルダー（Stakeholder）)
ここには明確にステークホルダーの語源として以下のような説明が書かれています。
語源は、16世紀アメリカの開拓時代に、移住民が土地の周囲に杭（stakes）を打ち、土地の所有権を主張していたことが始まりです。70年代までのアメリカでは「権利を主張する者」として否定的な意味で用いられていました。なるほど、なんとなくしっくりきました。
ビジネスシーンで使われる言葉なので、お金にまつわる部分に注目し「賭け金」という意味から語源を探ろうとしてしまいがちですが、実は「くい、棒」のほうに意味があったわけです。
杭を打ち、自分の権利を主張する人たちをステークホルダーというんですね。
だから、株を持っていなくても、その会社に対して何らかの権利を主張してくる人たちをステークホルダーと呼ぶわけです。
そう考えれば、お金を払って商品を買ったからには、正当な対価として商品の効用を求め、それが満たされなかった場合、会社に対して苦情を言ってくる消費者や、働いた分の給料を要求してくる従業員はステークホルダーですね。
逆に、株主でも、いちいち権利を主張してこない人がいた場合、その人だけを見ればステークホルダーではないんですね。
これで線引きができました。
この言葉がビジネス用語として定着しやすかったのも、先に「株主＝ストックホルダー」という言葉があったからというのは間違いないでしょう。
他人事みたいなビジネス本によく書いてある「会社は誰のためにある？」という問いに「株主（ストックホルダー）」と答えた経営者に対して、「その考え方は古いですね。これからはストックホルダーだけでなく、ステークホルダー全てのことを考えた経営をしなくちゃいけません」と、いう、半分ダジャレじみたコンサル用語として広がったというのは、容易に想像がつきます。
さらに、有象無象の三流コンサルたちがクライアントを煙に巻くために、どんどん意味を曖昧にしていったというのもわかります。
ただ、会議で使うからには、「とにかく利害関係者ぜ～んぶ」みたいな曖昧な捉え方ではなく、「権利を主張する人たち」という視点で、その関係者が権利を主張するかしないかを意識しながら線引きをしていくべきでしょう。
2015年8月23日日曜日
ファビコン(favicon.ico)と、スマホのホーム画面用アイコンの作成
先日、Google App Engineのログを眺めていたら、Webブラウザからibbwatch.appspot.comにアクセスがあるたびに、"favicon.ico"を読もうとして失敗しているようでした。
もともと実験的に立ち上げたサービスだし、ファビコンでデコる必要もないかと思い、favicon.icoは設置していませんでした。
ただ、どうやら大抵のWebブラウザは、一度のアクセスでfavicon.icoを読めなかったら、もう一度トライする仕様になっているようです。
ログの中で、1回アクセスがあるたびにfavicon.icoの読み込みを2回ずつトライして2回とも404エラーになっているのです。
気にしなければいいのしょうけど、なんか気持ち悪いですよね。
そこで、ファビコンを設置すべく、いろいろ調べましたので備忘録も兼ねて少しまとめておきます。
[ファビコン]
もともと実験的に立ち上げたサービスだし、ファビコンでデコる必要もないかと思い、favicon.icoは設置していませんでした。
ただ、どうやら大抵のWebブラウザは、一度のアクセスでfavicon.icoを読めなかったら、もう一度トライする仕様になっているようです。
ログの中で、1回アクセスがあるたびにfavicon.icoの読み込みを2回ずつトライして2回とも404エラーになっているのです。
気にしなければいいのしょうけど、なんか気持ち悪いですよね。
そこで、ファビコンを設置すべく、いろいろ調べましたので備忘録も兼ねて少しまとめておきます。
[ファビコン]
- 基本は".ico"形式で作成し、"favicon.ico"というファイル名でルートに置く
はじめにIE5の機能拡張としてマイクロソフトが独自に設定したため、Windows用のアイコンフォーマットとして既に使われていた".ico"形式が採用された。 - 別の画像ファイル形式を使うことも可能。ファイル名等も変更可能
現在はIE以外にも多くのWebブラウザで採用されており、GIFやPNGなど、".ico"でない画像ファイル形式も使える。HTML内部に、<link>タグを使って、ファイル名、ファイルの格納場所などを指定できる。
もともとは、「お気に入り」にブックマークしたとき、たくさんあるブックマークの中から、目的のサイトを見つけやすくするための、IE5の独自機能だったのですね。
どうやら、マイクロソフトが独自に考えたものなので、HTMLを勝手に拡張するわけにいかず、格納場所とファイル名が固定されていたという経緯があった模様。
IE5というと、1999年に公開されているので、もはや前世紀の話ですが、iPhoneの登場により「アイコンでブックマークを目立たせる」という機能に新風が吹きます。
iPhoneの大ブームにより、一気にスマホが普及しますが、iPhoneはWebのブックマークをホーム画面に貼り付けることができます。このとき使われる「ウェブクリップアイコン」は、サーバーのルートに置かれた"apple-touch-icon.png"という名前のPNG形式の画像ファイルから取得しているんです。
一気に普及すると同じ事がやりたくなるんでしょうか？ 数を持っていると強気になるのかもしれません。20世紀のマイクロソフトと同じことを21世紀のアップルもやっているんですね。
「売れている者の勝ち」というと、資本主義的で差別的な感じですが、「沢山のお客様に支持されている者の勝ち」というと民主主義的です。
そういう気持ちはわからなくもないですね。
こちらも今は、HTMLの<link>タグから名前や置き場所を変えられるようになっているようで、Andoroidはこのタグを見に行っているようです。
[ウェブクリップアイコン]
- 基本は、PNG形式で作成し"apple-touch-icon.png"というファイル名でルートに置く
最初にアップルがiPhone用にそう決めた。 - ファイル名等変更可能
現在はHTMLの中に<link>タグを使ってパスを指定可能。
● 作業
ということで、まずはアイコンを作ります。
ICO形式のファイルを作るには、複数のPNGファイルから、ICOファイルを作ってくれるサイトがあります。今回はここを使わせていただきました。
16x16、32x32、64x64、180x180のアイコンをPNG形式で作りました。
これを先ほどのサイトでまとめて、"favicon.ico"というファイルに変換します。
そして、180x180は"apple-touch-icon.png"というファイル名にします。
これら2つのファイルをルートに置きます。
Webブラウザから見えるように、"app.yaml"の"handlers:"のところに、下記のように追記します。
- url: /favicon\.ico
static_files: favicon.ico
upload: favicon.ico
- url: /apple-touch-icon\.png
static_files: apple-touch-icon.png
upload: apple-touch-icon.png
そして、HTMLに<link>タグを追記します。
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
とりあえずこれでPC用のブラウザとiPhoneとAndroidのホーム画面にアイコンが表示できるようになりました。
[参考]
2015年8月17日月曜日
Twitter つぶやき機能追加
Bitcoin価格評価システムにTwitterへの投稿機能を付けました。価格が高いor安いと判断したら、その旨つぶやきます。
アカウントは @BTCcheck です。ぜひフォローしてみてください。
Google App Engine から、Twitterに投稿するのはちょっと面倒でした。
Pythonからツイートするといえば、requests-oauthlib が比較的有名で、python-twitter でも内部でrequests-oauthlibが呼ばれているようです。
requests-oauthlibの情報は検索すればたくさん出てくるのですが、Google App Engineからは使えませんでした。
でも、蛇の道はヘビといいますか、さすがインターネット、必ず先人がおられます。先人たちの残してくださった情報をもとに、どうにかツイート機能を実装することができました。
一番の決め手は AppEngine-OAuth-Library です。この中の"oauth.py"を使います。
使い方は、ここ「TwitterボットをOAuthに対応させてみた - Google App Engine(Python)」を参考にさせていただきました。
いろいろ調べて遠回りしてしまったので、簡単に作業内容をまとめておきます。
大きな流れとしては、以下の通りです。
アカウントは @BTCcheck です。ぜひフォローしてみてください。
Google App Engine から、Twitterに投稿するのはちょっと面倒でした。
Pythonからツイートするといえば、requests-oauthlib が比較的有名で、python-twitter でも内部でrequests-oauthlibが呼ばれているようです。
requests-oauthlibの情報は検索すればたくさん出てくるのですが、Google App Engineからは使えませんでした。
でも、蛇の道はヘビといいますか、さすがインターネット、必ず先人がおられます。先人たちの残してくださった情報をもとに、どうにかツイート機能を実装することができました。
一番の決め手は AppEngine-OAuth-Library です。この中の"oauth.py"を使います。
使い方は、ここ「TwitterボットをOAuthに対応させてみた - Google App Engine(Python)」を参考にさせていただきました。
いろいろ調べて遠回りしてしまったので、簡単に作業内容をまとめておきます。
大きな流れとしては、以下の通りです。
- AppEngine-OAuth-Library の中の"oauth.py"をコピーします。
ツイートするスクリプトが"tweet.py"だととすれば、"tweet.py"と同じ場所に置くのがわかりやすくていいでしょう。 - "oauth.py"の53行目あたり、"import json"をコメントアウトして、すぐ上の行にコメントアウトされている"#from django.utils import simplejson as json"の頭の"#"を外します。
もし、うまく動作しない場合は、djangoのライブラリ設定がうまくできていないと思われますが、いろいろ考えるのが面倒なら、ここ(https://pypi.python.org/pypi/simplejson)からsimplejsonをダウンロードして、"simplejson"というフォルダを"oauth.py"と同じディレクトリに置き、53行目を"import simplejson as json"と書き換えるという手もあります。 - 「TwitterボットをOAuthに対応させてみた - Google App Engine(Python)」に書かれているサンプルを参考に、ほぼほぼこのまま使わせていただきます。
ただし、Twitterに投稿のリクエストをするURL"http://twitter.com/statuses/update.json"は、少し古いようで、"https://api.twitter.com/1.1/statuses/update.json"に書き換える必要があります。
変数paramを書き換えてからTweetHandlerをwebapp.WSGIApplicationに渡してやれば、ツイート内容を変えることができます。
"TweetHandler.get.param = {'status' : u'新しくつぶやく内容'}"とすれば、ツイート内容を変更できるはずです。
現在運用中のBitcoin価格評価システムでは、いろいろいじくっていたので、paramはTweetHandlerの直下にあります。したがって、"TweetHandler.param = {'status' : u'新しくつぶやく内容'}"を実行してから、"application = webapp.WSGIApplication([('tweet.pyを呼ぶURL', TweetHandler)], debug=DEBUG)"を実行しています。
先人たちの残してくれたライブラリや各種情報のおかげで、なんとかツイート機能を追加できました。ありがとうございます！
ちなみにOAuth認証の「OAuth」ですが、「オー オース」と発音するそうです。(参照：Wikipedia)
2015年8月14日金曜日
Google App Engine の Cloud Datastore を とにかく簡単に使う
今回、Bitcoin価格評価システムを立ち上げるにあたり、定期的にcoincheck取引所の取引状況を取得するために、Google App Engine を使いました。
もともと、ローカルPC上にPythonで組み上げたシステムがあったので、これを年中動かしっぱなしにできるよう、Google App Engine に移植しました。
Google App Engine は、Java、PHP、Go言語などでも開発できるようですが、Pythonが使い慣れているので、とりあえずPython(バージョン2.7)を使うことにします。
ローカルPC上に作っていたシステムは、Pythonの標準ライブラリに含まれているSQLite3を使っていました。
SQLiteは使い慣れると大変便利で、まるで配列に保存するかのように使えます。取得したデータをとりあえずSQLiteデータベースに放り込んで、重複行を削除したり時間順に並び替えたりという作業のほとんどはSQLiteのコマンドを叩いていました。
App Engine上では、Pythonの標準ライブラリに含まれているSQLite3が使えないので、別の方法を考えなくてはいけません。
App Engineからは、Cloud SQLが使えます。しかし、これには無料枠がありません。それに対して、Cloud Datastoreは、App Engineサービス開始当初から標準でサポートされているデータベースで、無料枠があります。(結局、無料枠は一瞬で使い果たしますが……それについては別の機会に)
本格的なSQLが使いたいわけではなく、ちょっと配列代わりに使いたいだけなので、Cloud Datastoreを使うことにします。
もともと、ローカルPC上にPythonで組み上げたシステムがあったので、これを年中動かしっぱなしにできるよう、Google App Engine に移植しました。
Google App Engine は、Java、PHP、Go言語などでも開発できるようですが、Pythonが使い慣れているので、とりあえずPython(バージョン2.7)を使うことにします。
ローカルPC上に作っていたシステムは、Pythonの標準ライブラリに含まれているSQLite3を使っていました。
SQLiteは使い慣れると大変便利で、まるで配列に保存するかのように使えます。取得したデータをとりあえずSQLiteデータベースに放り込んで、重複行を削除したり時間順に並び替えたりという作業のほとんどはSQLiteのコマンドを叩いていました。
App Engine上では、Pythonの標準ライブラリに含まれているSQLite3が使えないので、別の方法を考えなくてはいけません。
App Engineからは、Cloud SQLが使えます。しかし、これには無料枠がありません。それに対して、Cloud Datastoreは、App Engineサービス開始当初から標準でサポートされているデータベースで、無料枠があります。(結局、無料枠は一瞬で使い果たしますが……それについては別の機会に)
本格的なSQLが使いたいわけではなく、ちょっと配列代わりに使いたいだけなので、Cloud Datastoreを使うことにします。
参考までに、今日時点のCloud Datastoreの1日あたりの無料割り当て枠は以下の通りです。
- 5 万回（読み取り/書き込み/小規模な操作）
この無料枠につられて、まんまとCloud Datastoreを使う羽目になってしまったのです……
- 1 GB ストレージ
さて、Cloud Datastoreですが、SQLなどのリレーショナルデータベースとはちょっとイメージが違います。同じ「種別」の「エンティティ」の塊をひとつのデータベースとして扱うという感じです。リレーショナルデータベースのイメージからすると、ひとつのデータベースというよりは、テーブルのイメージです。
そして、エンティティ一つ一つが行にあたり、エンティティの「プロパティ」が列(フィールド)にあたります。
Pythonの中では、種別がクラス、エンティティがそのクラスから生成されたオブジェクト、プロパティがそのオブジェクトのメンバー変数で表現されています。
ちょっとややこしくなったので表にまとめます。
とりあえずこんなイメージで、ざっくり理解しておきます。
| リレーショナルデータべース | テーブル | 行 | フィールド(列) |
|---|---|---|---|
| Cloud Datastore | 種別 | エンティティ | プロパティ |
| Python API での表現 | クラス | オブジェクト | メンバー変数 |
（詳しくは「プログラミング Google App Engine」(オライリー・ジャパン)が参考になります）
とにかくできるだけ簡単にCloud Datastoreを使い始めたいというのであれば、迷わずExpandoクラスを使えばいいでしょう。
# -*- coding: utf-8 -*-
import google.appengine.ext.db as gdb
class Mydb(gdb.Expando): # Expandoクラスを継承したクラスを作成
pass
BTCdb = Mydb() # オブジェクトを生成
BTCdb.data = 34000 # メンバー変数に値を代入
BTCdb.put() # put()でデータストアに保存
これだけで、テーブルを作って、フィールド(data=34000)を一つ持つ行を保存できました。
Pythonでは、クラス定義の中でオブジェクトのメンバー変数を定義する必要がなく、オブジェクトを生成した後からメンバー変数を作ってやれば、いくらでも増やすことができます。
また、取り出すだけならGQLというSQLによく似たコマンドがあり、これを叩くことで、リレーショナルデータベースと同じように扱うことができます。
こんな感じで、Cloud Datastoreは配列に保存する感覚でデータを永続的に保存でき、GQLを使ってリレーショナルデータベースのように扱うこともできます。
当初考えていたよりもずっと簡単に使うことができした。
Pythonでは、クラス定義の中でオブジェクトのメンバー変数を定義する必要がなく、オブジェクトを生成した後からメンバー変数を作ってやれば、いくらでも増やすことができます。
ですので、Cloud Datastoreのプロパティ(リレーショナルデータベースのフィールド)をメンバー変数を増やすことで、後からいくらでも増やすことができるのです。
データを蓄えるだけなら、一度、put()を実行してしまえば、メンバー変数の中身はデータストアに保存されているので、オブジェクト自体を保持しておく必要はありません。
BTCdb = Mydb()
BTCdb.data = 34000
BTCdb.put()
の部分をどんどん繰り返してやれば、オブジェクトBTCdbが上書きされていくのでどんどんCloud Datastoreにデータが蓄積されていきます。
データの取り出しも簡単で、
q = Mydb.all()と、するでけです。
for i in q:と、実行してやれば、先ほど保存したデータを表示することができます。
print i.data
また、取り出すだけならGQLというSQLによく似たコマンドがあり、これを叩くことで、リレーショナルデータベースと同じように扱うことができます。
こんな感じで、Cloud Datastoreは配列に保存する感覚でデータを永続的に保存でき、GQLを使ってリレーショナルデータベースのように扱うこともできます。
当初考えていたよりもずっと簡単に使うことができした。
2015年8月13日木曜日
ひとまず、Bitcoinの価格を評価するシステムを作ってみました。
Bitcoinの自動売買システムを作ろうと思っています。
Bitcoinに限らず、株でもFXでも、基本は安いときに買って高いときに売る。
それはわかっているのですが、いま、目の前に表示されている価格が高いのか安いのか、それがわかりません。
まずは、買うか買わないかを決断する決め手として、高いか安いかを判定するシステムを作ってみました。
こちらです。
市場はcoincheckを見ています。
ボリンジャーバンドの考え方を参考に、統計的に高いか安いかを判定しています。
ただ、手数料0円の市場を対象に、細かく何度も売買を繰り返すことを前提にしていますので、一度の統計で見る範囲は最長で60分、取り引きが多いと自動的に範囲を狭めて、より短時間の統計を取るようにしています。
ですので、人手で売買する場合はもうすこし大きな利ザヤを狙う必要があるかもしれません。
登録:
投稿 (Atom)