ChromeOSでvivobookが復活か！
2年前、2018年に22980円というスマホより安いASUSのノートパソコンvivobookを買ってしばらくご満悦だったんだけど、WINDOWS10の大型アップデートについていけず、ここ1年ほど鉄の箱状態。
ストレージが32Gしかないんでアップデートができなかったのだ。たぶん、だから激安だったんだなあ、と。
サイズといい、重量といい、使い勝手がよくてかなり気に入っていたのでめちゃくちゃ残念だった。
https://t2aki.doncha.net/?id=1545120465
家人がChromeOSが使えるらしい、というネタを仕入れてきたので、さっそく検索。
neverwareのCloudReadyというのにたどり着いた。
https://www.neverware.com/freedownload
・USBにインストールイメージを作成
・電源＋F2でBios画面を起動
・USBからChromeOSを起動
・本体にインストール
てことでトラブルもなくあっさりインストールできた。
設定画面からlinux（ベータ版）をONにしたら、ターミナルが立ち上がっていて、黒い画面の向こうに広がるlinuxの世界、だ。
当然ながらデフォルトでエディタのvimやスクリプト言語のperlが入っていて、aptでjavaもインストール。ついでにimagemagickなんかもインストール。
環境変数のlocaleもja.JP.UTF-8に設定したら、これで最低限の電書制作環境もできあがり、だ。
まだ使い込んでないけど、これなら十分だろなあ。
画像処理はWINやMacにまかせて、普段使いはChromeOSでやってくか。
ブラウザはChromeで問題ないし、WEB版のGmailはちょっと不便だけど使えないことはない。
使い勝手のいいvivobookが復活するならこれで全然OKだわ。
[12/25 10:33:06]
忘れないよう追記。
【apt installしたもの】
apache2
make
gcc
java(default-jre default-jdk)
fcitx-mozc(linux側で日本語入力)
fonts-ipafont fonts-ipaexfont
mate-terminal
imagemagick
【cpan installしたもの】
CGI
DBI
XML::Simple
Spreadsheet::ParseXLSX
【chrome webストアからインストールしたもの】
linuxではなくて、chrome側の拡張機能
ePub Reader
Text(エディタ)
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
ラムすき焼き
すき焼きにラムというのが我が家的に新しかった。いや、ラムである必要はあまりないんだけど。
関西・関東で味や調理方法がいろいろ違っている。わたしローカルは大阪。
出汁は、塩と昆布が好きで、東京に来て鰹と醤油は続くとちょっとアレな感じ。
すき焼きは、醤油と砂糖をドボドボと肉にかけて水分は白菜などの野菜からでる水分だけ。足りなければお湯とか日本酒を足す感じ。東京のすき焼きが最初から割り下と称するだし汁で煮るのには驚いた。すき「焼き」っていうんだ、煮ちゃいかんだろ。
んで、今日クリスマスはウチですき焼きwithラム肉。
醤油と砂糖で飴色になった肉が柔らかくて蕩ける。醤油と砂糖で飴色に透き通る白菜とネギが蕩ける。昼間からすき焼きを食いながらビールを飲む贅沢な時間だ。
すき焼きを外食するようなことはほとんどないんだけど、昔好きで行ってた新宿の伊吹というすき焼き屋さんが関西風の砂糖と醤油どぼどぼ。肉が柔らかくて美味だったなぁ。
残った具ですき焼き丼も。いや、すき焼きもそうだけど、鍋はうめーすなあ。年末年始は鍋で年越しするか。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
OAuth で twitter にアクセス
OAuthをごそごそやってたのは twitter がそのうち Basic認証じゃなくて OAuthをAPIのクチにする、というの読んだから。
OAuthのわかりやすい解説は他の有用なサイトにまかせるとして、素人のわたしの理解をメモる。
やろうとしているコト。
現状。
1)縦書きtwitter（わたしの作ったtwitterを利用するサイト）がある。
2)縦書きtwitterは現状ではユーザーにtwitterのIDとPASSを入力してもらって、そのユーザーのタイムラインを取得、表示している。
※入力してもらった情報はユーザーのクッキーに保存。twitterに対してはBasic認証で繋いでいる。
この（2）の部分を、今後twitterが推奨するという、OAuthでの認証にしてみたい。
ざっくり大雑把な理解で流すけど。
1)縦書きtwitterにユーザーがアクセスする。
2)縦書きtwitterは、twitter本体に対して、縦書きtwitterは登録してありますよ、とお伺いをたてる。
3)twitter本体が、おう、お前久しぶりやな、ということがわかれば、ユーザーをこっちに寄こしなさい、ということで、ユーザーを twitterにリダイレクトする。
4)ユーザーは twitter に飛ばされて、そこでIDとPASSを入力して「承認」すると、ふたたび縦書きtwitterに戻される。
5)ユーザーは、twitterからもらう アクセスのためのtoken （IDみたいなもんだ）と、tokenを含めたアクセスを正しく認識するためのtoken_secret（パスワードみたいなもんだ）を持って戻ってくることになる。
6)縦書きtwitterは、ユーザーのtokenとtoken_secret＝IDとパスワードをどこかに保存しておいて、ユーザーに縦書きtwitterを使ってもらう。
※保存するのはたぶんクッキー。DBに保存したら、今度はそのIDとPASSがだれのものか、というログインが必要になるしねえ。
一応、OAuthで TL を取得したり、つぶやきを投稿したりできるようにはしたけど。はたして、これ、本当に安心で便利なシロモノなのか、そこんとこがまるで理解できない。
Basic認証は、IDもパスワードも平文で流れるのでセキュリティに問題があるのはよくわかる、けど。Basic認証にしろ、OAuthにしろ、少なくともアクセスしている間は、IDとパスワードをどこかに保存しなきゃいけない。この穴はBasic認証だろうとOAuthだろうと同じじゃないのか。見えないIFrameに仕込まれる程度のチャチなクッキー引っこ抜きに引っかかって「なりすまし」被害に合うのは防げない、ような気がする。
ユーザーにしてみれば、yhooなりmixiなり、ひとつのIDとパスワードを使いまわしできるので管理がラク、ってだけだったら（セキュリティ的に画期的になにかが変わったわけでもなさそうな）OAuthなんてこんな「ややこしい」手順を踏まなきゃいけないメリットは感じないんだよなあ。
OAuthの良さを誰か教えてくだされ～。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
OAuthでハマったのでメモ
twitter の OAuth認証を、と思ってごそごそ調べては試行錯誤。OAuthの一次情報、仕様を見ながら、自分でサインを作ればこんなにハマらなかったと思うんだけど、ラクしようと思って、perl の Net::OAuth ver0.20に投げたのが始まりだ。
以下のページを参考にさせていただいて、CPANからOAuthをインストールすればラクショーっぽいぞ、と。
https://blog.photoble.net/archives/category/memo/oauthtwitter
https://sayama-yuki.cocolog-nifty.com/blog/2009/09/twitteroauth-d7.html
甘かった。
その１．最初のリクエストで oauth_callback_confirmed が返ってこない
その２．twitterから、リダイレクトされて戻ってきたときには 401。認証されず、 oauth_verifier も返ってこない。
なんじゃそりゃ、と。延々ググりまくって今朝未明まで。今日も天気だというのに早起きして、ググる。…ヒットしないんだけど、どうやら OAuthの 1.0 と 1.0a の違いが原因っぽい。oauth_callback_confirmed も oauth_verifier も 1.0a から導入されたパラメータ、てことだ。OAuthで作られるパラメータを確認してみると、指定しているにも関わらず、callbackが入っていない。
Net/OAuth/で grep してみて OAuth.pm を読んでようやく解決。
request パラメータを組み立てるところに
一行入れるだけ、だった。
↑これが正しいリクエストヘッダー
CPANは便利なんだけど、素人芸の、ブラックボックス、コピペ使いは限界があるんだよなあ。
ここが通ったら次はアクセストークン取得でそれの扱いをどうするのか、またググる、か。でも気力体力が尽きたので以下次号だ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
オリンパスPenEE3
てことで届いたオリンパスPenEE3だ。
まともに写るかどうかはまだわからないけど、外見はおおむねOKだし、光不足の時の赤ベロも出るのでセレンは反応してるっぽい。これがまともに使えるようなら、ほぼカメラは揃った、かも。トイカメラ、ピンホールカメラ、一眼レフに、コンパクトカメラ。キャラのかぶるものもなく満遍なく。強いてあげればレンジファインダーのカメラがないところだけど、値段も高いしそこまでして欲しいものでもない。
とりあえず、AGFAのISO100を入れて、撮りまくる、か。でないと、ハーフカメラなので、24枚撮りを入れても48枚撮らなきゃいけない。なんも考えずスナップ専用カメラとしてやってみよう。
しかし。今日は朝駅に向かうときは軽く汗ばむほどだったのに、夜は歯の根が合わないほど寒い、ってどういうこっちゃ、東京。こういういい加減なことされるとオッサンはついてけんぞ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
mod_perlに驚く
劇的に早い。
いや、世間はすっかりクリスマスだというのに、わたしは、今日も今日とてバナー作りに励んでたわけだが。息抜きにpostgresqlとdbiを調べて、mod_perlで動かすために行儀の良いスクリプトを書いてみた。
345行のデータベースからランダムに一行引っ張り出して表示する。
たったそんだけ。データ量も少ないので、純粋にperlを呼び出すところの負荷も見えようというもの。普通にcgiとして呼び出したのと、mod_perlのRegistryと比較してみて腰が抜けたのだ。早いとは聞いてたけどこんなに早いとは思わなかった。最初の一度はどちらも同じなのに、その次からがすげーのひとこと。ブラウザがキャッシュを表示してるだけかと思うほどだ。
自宅サーバーのLibretto50のMemory32Mだと、ほとんどなにもしない状態でSWAPしてる状態。cgiでperlが呼ばれるとそのたびに、確実に、新たにswapすることになる。mod_perlはいわばperlインタプリタ内蔵。一度はスクリプトをコンパイルするけどそれ以降はメモリに蓄える。そりゃ早くなるはず…といった理屈以上に早く感じたのはLibretto50の貧相なサーバーだからか。
うううむ。こりゃmod_perl用にcgiを書き換えてみないことには始まらないかも。当然データを丸読みしてメモリを食いそうなのは、またそこでSwapの心配・対策を考えなきゃいけないんだろうけど。
月間30億ページビューとやらの、mixiとかはてながmod_perlというのもわかるような気がする…ってLibretto50サーバーと比べるのは無茶、か。
mod_perlでこんなに早くなるのがわかったのは、ちょっと収穫だったなぁ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」
