cafegale(LeafCage備忘録)

LeafCage備忘録（はてなダイアリー）と統一しました。

単3、単4電池は充電式以外持たない方がいい

リモコンの中にはMAX電圧じゃないと効きが悪くなる、あるいは完全に効かなくなるものがあって、電池残量チェッカーでみるとグリーンなのに実際にはそのリモコンには使えないという中途半端な電池が出てくる。
表示上はグリーンなのだから他の機器に使えるかもしれないからと収納ケースに保存した電池が無数に生まれることになる。

結果、中途半端に残量がある電池大量地獄、アンチミニマリズム状態に陥る。
充電式なら受け付けなくなった電圧中途半端電池をすぐさま再利用可能な状態に戻すことができ、無駄なストックが生まれない。

そもそも電池はストックしているだけでも徐々に摩耗していく

大量にストックがあっても使わないままで置かれていたモノは結局だいぶ経ってからチェッカーで使えなくなっていることを確認されてから捨てられる運命だ。

アルカリ電池にもはや存在価値なし。充電式に置き換えよう

マンガン電池は液漏れしても液体の危険度はアルカリ電池ほどではない上に、休ませると出力が回復するのでまだリモコンに使うことができる。
一方、アルカリ電池は液漏れすると腐食性のある危険な液を放出し場合によっては機器をだめにしてしまう。液漏れは電池を入れたまま数年間しようしていない機械ではほぼ確実に起きる。私はこれでいくつもの機械をだめにしてしまった。
そんなわけでマンガン電池には利用価値がまだ残っているけれど、アルカリはもう速やかに充電式に置き換えるべきだ。

うちに中途半端な残量のアルカリ電池が大量に残っていたけど、これはリモコンに使うことができないから、消費電力の少ない電波式置き時計でちょびちょび消費していくことにする。こういうしんどい思いをしていくことで、もうアルカリ電池は買わないという決意をますます固めることができた。

iHerb系ブログリンクメモ

iHerbを初めて利用するにあたり、購入商品のリサーチを行った。
そのときに参考にしたブログを追記していきます。
※カッコ内はその人のiHerb紹介コード

#iHerb生活(アイハーブ生活)(AMU409)
フードに強い


#おすすめ記事 | パレオな男


#iHerbおすすめ商品紹介ブログ＆コンプレックス克服美容法 - kiko labo　*iHerb生活*　(アイハーブおすすめブログ)(GNB892)
コスメに強い
他個人輸入コスメ医薬品など
塩浴の人


#Shanti's Organic Life


#わたしらしく年齢を重ねる(TKR837)


#iHerb(アイハーブ)でおすすめのオーガニックサプリ・コスメのまとめ【クチコミ】 - がちゃのーと。(SUM4251)


#iHerb（アイハーブ）ナビ(tet397)

バックスラッシュでエスケープされていないスペースを表す正規表現

vim

いい加減どこに書いたのか忘れてその度に考えて作り直すのが面倒くさいのでメモ。

let list = split(str, '\%(\%(\%([^\\]\|^\)\%(\\\\\)*\)\@<=\\\)\@<! ')

後ろから読んでいった方が理解しやすい

'\\\@<! ' "前にバックスラッシュのない空白
'\%(\%([^\\]\|^\)\%(\\\\\)*\)\@<=\\' "『「バックスラッシュでない文字または行頭」の後の偶数個のバックスラッシュ』の後のバックスラッシュ
  "つまり、まだ完結していない、後ろに文字を取る、意味を持っている、単独のバックスラッシュ

合わせて前に【『「バックスラッシュでない文字または行頭」の後の偶数個のバックスラッシュ』の後のバックスラッシュ】のない空白。

スマートタグはまだ決定版と言える物がない

  • 電池の持ちはおおよそ半年程度。一年以上は長く持ってほしい。
  • コミュニティメンバーが通過するとGPS情報を利用できるとのことだが、乱立するスマートタグの規格が統一されていないのでコミュニティが拡散され勿体ない。
  • 防水製品が少ない
  • 忘れ物通知の距離を設定できない（探索範囲外になって初めて通知される）
  • スマホとのBluetooth接続前提。スマホ電池が消耗する。単独で動くか、またはスマホ以外の専用のGPS内蔵レシーバーと通信するなどの選択もほしい。

スマホ連携を絶対条件としないのなら、電池に拘らずにバッテリー充電式にしてもいいし、バッテリー充電式なのならいっそのことモバイルバッテリーとしても使えるようになってほしい。
またはどうせ電池がそんなに持たないのだから太陽電池を採用して少しでも稼働時間を延ばし、microUSBで充電するバッテリーで少しでも稼働時間を上げてほしい。


現時点では間に合わせで現行商品を購入するだけで、将来の決定版と言える商品がでるまでそれを使うしかない。
現時点の有効馬と思うのは
Qrio Smart Tag(キュリオスマートタグ​)
か
Chipolo -チポロ

他のは電池交換ができなかったり、不安定という報告が多く、イマイチ信用できない。

楽天カードの口座引き落としに間に合わなかったのでTELしてわかったこと

  • 楽天カードについては引き落とし日から翌月1日まで楽天銀行に毎日引き落とし処理が掛かる。
  • 信用機関には実際に支払われた日にちが情報として送られる。つまり支払いに何日遅れたのかが情報として残る。信用機関はその情報に基づいてカードを停止するかどうかを決める。

LibreOffice (OpenOffice) で python を使ってマクロを書く

python libreoffice

マクロのファイルは次のディレクトリ以下に.pyファイルを用意する(windows)。

C:\Users\ユーザ名\AppData\Roaming\LibreOffice\4\user\Scripts\python

ポータブル版では

Data/settings/user/Scripts/python

基本的に、勝手に定義されるグローバル変数 XSCRIPTCONTEXT から getDesktop() や getDocument() を呼び出して色々やってりゃいい感じ。
uno についてはよくわからない。
関数が1つのマクロの単位なので、公開するマクロ（関数）を制限したいときにはスクリプトの最後に g_exportedScripts 変数を定義して、公開する関数名をタプルで列挙する。

設定など

JavaなしでLibreOfficeを使う方法: 山賀正人のブログ
Javaがないとメッセージがいちいちうるさいので、ポータブル版は App\libreoffice\share\extensions 以下の nlpsolver と wiki-publisher をどこかにでも待避させておこう。

オプションのセキュリティからマクロセキュリティを「中」にしておく。これをしなくてもpythonマクロは使えるが、シート埋め込みのマクロを使いたいため。

参考資料
参考資料（テクニックについて）


以下の記事を参考にセルアクセスを、配列にして効率化した。

TODO


http://d.hatena.ne.jp/kakurasan/20121227/p1

python触り初めて嫌に感じたところ

python

私はほとんど vimscript しか触ってこなかったのだけど、最近必要に応じて他の言語にも手を出すようになった。
それでちょっと触り初めて気持ち悪く感じたところ。
なんかあったら追記する。

三項演算子が汚いこと

三項演算子を使うと行を減らせるし、うまく使えば論理が理解しやすくなる。（下手くそな使い方をすると暗号になってしまうが）
vimscriptでは特に代入時に三項演算子を多用していた。そうすれば最終的にやりたいことは代入であるということをはじめに示せる。
それで一般的な三項演算子は先に条件を書いて、?と:で結果を区切る。ところがpythonの三項演算子はなんと先にTrueの値を書いてその後にifで条件を書き、elseの後にFalse時の値を書く。

一般的な三項演算子

条件 ? True時の値 : False時の値

pythonの三項演算子

True時の値 if 条件 else False時の値

前から読み下す場合、True時の値を先に見てこの値だと認識したところでifが来た時点でその認識を修正しなければいけない思考の流れが不自然だし、三項演算子を連結させると更に理解しにくくなる。

一般的な三項演算子の連結

条件1 ? 値1 : 条件2 ? 値2 : どちらも満たさないときの値

pythonの三項演算子の連結

値1 if 条件1 else 値2 if 条件2 else どちらも満たさないときの値

あと、これは一般的なことだが、式に使うキーワードはなるべく英単語(ifやelseなど)でなく記号にしてほしい。それもできるだけ短いものを。
短い記号が式の構成要素だと値の変数名が明瞭に目に入って認識しやすいが、英単語が式の構成要素だとそうはいかない。

リスト内包記法

Haskellのリスト内包と違って汚く感じるのは無理矢理 for in を使ってるからだよ。三項演算子のところでも行ったけど、まず式の構成要素に英単語をなるべく使わないでほしい。特にいくらでも複雑になり得るものについては。

空のブロックはpassというキーワードを入れねばならないこと

私は冗長な表現を嫌うので、ブロック区切り記号の代わりにインデントを区切りにしたことはとても歓迎していた。
空のブロックにpassと入れなければいけないと知るまでは。

コードの構造を軽く下書きするときには関数の中身まで書かないってことあるけど、そのカラッポの関数にいちいち全てpassを書けというのか？
そして実際に実装するときにはpassを消して中身を書くって？
冗談じゃない。というか、まずpassとだけ書かれた関数の汚いこと。
せめてpassじゃなくて:とかならまだ許せたかもしれない。タイプ数一文字だし。まだ見た目に感じる汚さがマシだし。:はシェルスクリプトでも何もしないコマンドだから論理的統一感があるし。

ifやwhileやdefなど制御構文の末尾に:を付けなければいけないこと

この:、絶対、冗長だろう。明らかな制御構文なんだからわざわざ末に:を付けなくても改行したらそこから先は処理ブロックでしょう。わざわざ:を付けなければいけないのが冗長で嫌だ。そもそも私はC言語やJavaでの、文末尾の;も毛嫌いしている。本当にせっかく基本の文の区切りが改行で、基本のブロック区切りがインデントなのに、こういうところで冗長な表現を使って台無しにしてるのが勿体ない。

変数名として使うと不都合なワード

pythonは予約後が少ないとされているけれど、変数名に使える単語の自由度がまだ足りない。
例えばグローバルな関数名（lenやstrやdictなど、またdirは使えなくはないけれど標準関数名と被る。）を変数名に使うと不都合が生じる。
こういう一般的なワードを使えないのは、変数と関数の区別が曖昧だからだ。これは利点でもあるのだろうけれど、そのせいで中間結果を一時保存する変数名の自由度を著しく下げている。

オブジェクト指向

オブジェクト指向を導入すると必ずどこかで汚いものが生まれるものだ。オブジェクトを操作する手段をメソッドとしてオブジェクト自身が持っているか、外部から操作するかの方針がどこかで必ず不一致になるからだ。特にイミュータブルなものの操作について。
そういう不一致を見つける度に気持ち悪くなる。いっそHaskellみたいに全部外側から関数で操作するなど統一してほしい。