をDVI接続で使っています.通常に使うのには問題ないのですが,macbook proがスリープから復帰した後外部ディスプレイが表示されなくなってしまいます.ググってみたところ,このへんの人たちと同じ症状のようでした.
どうやったら直るのかな…
http://twitter.com/#/list/niku_name/consadole を作るのに書きました.
# -*- coding: utf-8 -*-
require 'uri'
require 'net/http'
require 'nokogiri'
require 'oauth'
require 'rubytter'
USER = 'niku_name'
PASS = ''
#CONSUMER_KEY = ''
#CONSUMER_SECRET = ''
#ACCESS_TOKEN = ''
#ACCESS_SECRET = ''
#PIN = ''
LIMIT = 500 # 500 は list 登録人数の上限値
SEARCH_WORDS = ['コンサドーレ', 'consadole']
LIST_NAME = 'consadole'
def get_members search_word
(0..(1/0.0)).inject([]) do |base, num|
uri = URI.parse("http://tps.lefthandle.net/search/#{num}/?s=#{URI.encode search_word}&sort=follower")
doc = Nokogiri::HTML(Net::HTTP::get(uri))
result = doc.search('div.tweetuser').map{|e| e['id']}
if result.empty? || base.size > LIMIT
break base
else
base.concat result
end
end
end
members = SEARCH_WORDS.map{ |search_word| get_members(search_word) }.flatten.uniq
oauth = Rubytter::OAuth.new(CONSUMER_KEY, CONSUMER_SECRET)
#access_token = OAuth::AccessToken.new(oauth.create_consumer, ACCESS_TOKEN, ACCESS_SECRET)
#client = OAuthRubytter.new(access_token) # 2010/05/16現在 OAuth だと list 操作が 404 Not Found になる
client = Rubytter.new(USER, PASS)
begin
client.list(USER, LIST_NAME)
rescue Rubytter::APIError
client.create_list(LIST_NAME) # リストが無ければ作成する
end
# リストに登録
members.each do |member|
p member
begin
client.add_member_to_list(LIST_NAME, member)
rescue => ex
p ex
sleep 10
retry
end
end
少額で自由に募るからどれに対する寄付なのかわからなくて面倒なことになるのではないかと思いました.
逆に機能を入札してもらえるようにしたらどうだろう.ある機能を金銭で請け負う.作者は生活と主義主張と技術的課題と保守リスクを請負金額に乗せて良い.きっと滅茶苦茶高くなるけど,モンスターユーザーからの防波堤になるかもしれない.
何故かというと、「金払ってるんだから言う事を聞けよ」って言われるストレスに晒されたくないからだ。「いい物にはお金を払いたい、だから寄付したいんだ」と言われたらそれはそれで嬉しい。でも、金と一緒に「そしてお金を払ったんだからこっちの言う事を聞いて欲しい」という要求がくっついてくるんだったら(「寄付」のためのシステムを「対価を払うため」に使われるんだったら)、金は受け取りたくない。受け取らない代わりに自由でいさせて欲しい。
[Latest topics > フリーソフト作者の自衛のための手段としてのオープンソース化と、自衛のための「寄付は受け付けないよ」 - outsider reflexより引用]
フリーソフトの作者は ITS を用意して,Issue が登録されたら金銭を見積って,見積った金額が集ったら実装するとかどうだろう.実装がめんどうとかやりたくないのは目茶苦茶高く見積っておく.当然金銭が集まらなくても勝手に実装しても良い
ruby1.9.1 で動作確認しました.ruby1.8.7だと動きません.数十冊になると手でDLするのはつらいですよね…
# -*- coding: utf-8 -*-
require 'logger'
require 'uri'
require 'mechanize'
EMAIL = '' # for@example.com
PASSWORD = '' # yourpassword
FILE_BASE_PATH = '' # /Users/niku/Downloads とか
log = Logger.new(STDOUT)
agent = Mechanize.new
# ログイン
agent.get('http://system.bookscan.co.jp/mypage.php')
agent.page.form_with(action:'http://system.bookscan.co.jp/login.php'){ |f|
f.field_with(name:'email').value = EMAIL
f.field_with(name:'password').value = PASSWORD
f.click_button
}
# マイページ
agent.get('http://system.bookscan.co.jp/history.php')
# 書籍一覧
agent.page.links_with(href:/bookdetail\.php/)[0].click # 今の所1回しか注文してないからこれでいいや
pdf_links = agent.page.links_with(text:'PDFダウンロード')
pdf_links.each { |link|
# なんか2回エンコードされてた
filename = URI.decode(URI.decode(/&f=(.+)$/.match(link.uri.to_s)[1])).force_encoding('UTF-8')
begin
log.info "downloading #{filename} ..."
link.click.save_as("#{FILE_BASE_PATH}/#{filename}")
rescue => ex
log.warn ex
sleep 300 # サーバー過負荷によるエラーを想定
retry
end
}
のQCDですね.「どのくらいやるか」「幾らかけてやるか」「いつまでにやるか」です. この3つを全部同時に満たすことはできないため,2つの要素をどうするか決めてしまうと自動的に3つめが決まってしまいます. ほとんどの議論はこの3つの要素のバランスをどう取るかという話になっているので,意識すると面白いです.
冒頭の写真はバイクやさんのものみたいです.僕が一番初めにQCDを意識した内容だったかもしれません.
我々は3種類のサービスを用意しています. 『良い』『安い』『早い』 あなたはどれか2つを選ぶことができます. 良いサービスを安くすると,早くありません 良いサービスを早くすると,安くありません 早いサービスを安くすると,良くありません
といった感じでしょうかね.
TODO:あとで角谷さんのQCDについて書かれたスライドを見直す
hiroyukikojimaのblogで告知されてたので講義を聞きに行きました. 序盤〜中盤はとてもおもしろかったですが,終盤は全然わからなかったw
告知には「場所・東京大学本郷キャンパス法文2号館215番教室」って書かれてましたが,2号館には215番教室がありせんでした…
1号館215番教室でした.twitterで教えてくれた@Consanekoありがとう.行くのが遅かったせいもあって50分くらい遅れました.ううっ…
人物AとBがいたとして
といったようなのが相互推論だそうです.ゲーム理論で相互推論(読み合い)を使った場合,どのようになるかってのをやってました.この辺は具体的で馴染みやすかったです.
こんななぞなぞを思い出しました.これ相互推論を使っていますかね
問題
死刑囚が4人いる.それぞれA,B,C,Dとする. いま,A,B,Cを上から階段へ立たせ,Dは別の部屋へ隔離する. 赤白の帽子を2つずつ用意し,A->赤,B->白,C->赤,D->白の帽子をかぶせる.囚人は帽子が赤白2つずつ用意されているのは知っているが,自分が被っている帽子の色はわからない. AはB,Cの帽子の色がわかる BはCの帽子の色がわかる この状態で最初に自分の帽子の色をその理由も含め言い当てられた死刑囚が無罪になるとすると,無罪になる死刑囚はどれか.
答え
Bである. 仮にB,Cが同じ色の帽子をしていたとすると,Aはすぐに自分の帽子の色がB,Cと異なることがわかる.つまりAはすぐに解答するはずである. そうしないのはB,Cが異なる帽子をかぶっているからである. つまり,BはCの帽子と異なる色の帽子をかぶっていると推察できる.
ここは涙目になりながら聞いていました.時間をかければわかるんだろうけど30分くらいでパパッとやっちゃうと厳しいですね.集合とか論理に対する基礎がないとついていけない感じでした…オーマンの共有知識モデルはおもしろそうなので本で読みたい.
大手SIerの利益悪化がとどまることを知らない件 - GoTheDistanceの表が数字だけだと良くわからないのでgoogle spreadsheetでグラフにしてみました.グラフの元はhttp://spreadsheets.google.com/pub?key=0AqzdHGtPEkZmdFdNNXRBeW14VURoTHBZN0dWX3RrS3cに置いてあります.
売上高が変わらないのに,営業利益が落ちてるってことは,売上を得るための費用が増えているってことですよね.何の費用なんだろう.
営業利益/売上高で売上高営業利益率が出ます.一般に企業の競争力を表す指標とされているようです.落ちている傾向が強いですね.
講師@jksoft913,講師補助@kwappaが教えてくれました.
仮に僕がドラクエ3の勇者だとしたら,@jksoft913は僕にとってアリアハンの王様にあたるのではないか.
今週末のMake:Tokyo Meeting 05でArduinoのワークショップが開催されます。まだ若干空きがあるので、興味がある方は急げ! => ●「Arduinoを使ったtwitter連携ガジェット工作入門」 http://atnd.org/events/4564
[Twitter / phyzz.bz: 今週末のMake:Tokyo Meeting 05で ...より引用]
をtwitterのTLで見て知りました.元々フィジカルコンピューティングには興味があったのですが,導入部で挫折してました.どれ買えばいいか,どのソフトを揃えたらいいかわからないし,それを調べるだけのやる気がなかったためです…
動作する環境構築について,ソフトウェアのみであればネットで完結しますが,ハードウェアはネットのみだと環境が揃えられないのも原因かもしれません.
まぁその程度のフィジカルコンピューティングへの熱意と言えますが,僕みたいな人は他にもいるんじゃないかな…
@jksoft913が必要と思う情報だけ絞って伝えてくれたのがとても良かった.ドラクエ3でいうところの最初の王様みたいなものかもしれません.必要な道具を渡してくれて,「最初にルイーダの酒場へ行け」と教えてくれるアレです.
さしあたって僕が次に何をすればいいかは何となくわかりました.
僕はmacbook pro 15インチ (2010 mid corei5) を持って行ったのですが,arduinoを認識しませんでした…ハードウェアの差異によるトラブルはちょっと切り分けが面倒ですね…
ただ,ここで良かったのは,同じarduinoとUSBケーブルで@kwappaの環境では動作した点です.他の人の環境でちゃんと動くから,きっと部品の故障ではないってのは問題の切り分けとしてとても助かります.何人かで作業するとこういう所はカバーできていいですね.
講師をしてくれた@jksoft913,トラブルシューティングしてくれた@kwappa.どうもありがとう.
「オレはようやく登りはじめたばかりだからな。このはてしなく遠いフィジカルコンピューティング坂をよ…」
順次追記していきます.認識できましたー.何が原因だったのかは不明のまま…何も変えてはいないのですが…
arduinoをUSBケーブルにてmacbook proに繋いでもモデムとして認識しません.
以上によりハードウェアの故障ではないと推察されます.
vmware fusionを起動すると,右下にmacbook proに差さっているUSBの内容が表示されます.そこに「Future Devices FT232R USB UARTをこの仮想マシンに接続」とありました.
リンゴマーク→MacOSXソフトウェア を選択するとこんな感じです
ネットワークはこんな感じです
ターミナルで
ls /dev/cu.* /dev/tty.* | grep usbserial
した結果はこんな感じです
ネットワークはこんな感じです
ターミナルで
ls /dev/cu.* /dev/tty.* | grep usbserial
した結果はこんな感じです
…ターミナルでは認識しているようですね.この状態でarduino.appを起動してserialportを見ると
と,シリアルポートが見えました.
今日の朝の通勤電車です.1回目の電車は暖房が入っていて,2回目の電車は冷房が入っていました.なんだか不思議ですね.あれどうやって決めてるんだろう…運転手さんの裁量なのかな.
@bookscan_jpにスキャンを依頼したのですが,そのうち「Rubyベストプラクティス」のスキャン結果にページ抜けがあることに気づきました.
応援していますし,安い値段でやっている以上仕方ないのかなとは思いますが,ほぼ新刊の状態の本でこれだけ抜けられると,今後お願いするのには躊躇してしまいますね…
題にかもしれないと記述したのは,本の落丁の可能性は否定できないためです.あるいは元々こういうページ構成だったとか.この本をお持ちの方,まえがきの辺りの正しいページ構成はどのようになっているでしょうか?
連続したスクリーンショットは以下のような感じです