xyzzy の日付と時刻の挿入の新年号対応メモ

1. lisp/timestmp.l の 56 行目以降を下記に書き換える。

;; 元号と西暦の対応表(たぶん合ってる)
(defconstant *japanese-era-list*
    '(("令和" "R" 2019 5 1)
        ("平成" "H" 1989 1 8)
        ("昭和" "S" 1926 12 25)
        ("大正" "T" 1912 7 30)
        ;; Common LispではGMT1900年より前は存在しない
        ;; ("明治" "M" 1868 5 9)
      ))

2. ダンプファイルを削除する。(xyzzy.wxp 等)
3. xyzzy を起動する。

ニュースアプリ「グノシー」赤字13億9300万円　強気の拡大戦略、成功と失敗の分岐点にある

底辺の広告屋からみれば、若者が海千山千の広告代理店にまんまと増資額を吸われたように見える。
TVCMを扱えるような代理店からみれば、ベンチャーは一回（もしくは数回）広告費を吸い取れれば良くて、その結果その企業がどうなろうと意に介すことはない。
成功すれば広告のおかげ（さぁもっと広告打とう）、失敗すれば切るだけだからね。

会社のメンバーは若いし頭は良さそうなんで、将来はなんとでもなるでしょう。

といってもOSの話ではないよ。
某マグカップを愛用していたのだが、完全な過失にてロスト。
2005年から約9年、よく耐えてきたとも言えるが喪失感がハンパ無い。
困ったことにあらゆる飲み物をそれで淹れていたために、ソリュブルコーヒーや味噌(!)の量の感覚がそれに最適化されていること。
代わりのマグカップ探さな…。

どこぞのBBAブロガーが、富岡製糸場が元祖ブラック企業などと呟いているとか。
長い歴史のある企業の場合、年代の選択によって評価は異なる上での話。
自分の母親は昭和30から34年までそこで工員として働いており、その時の話を聞いてみた。

当時は寮へ住みこみ、月から土曜までA班05-13、B班13-22時を１週間シフトで働いていた。
食事の時間の前にチャイム代わりに島倉千代子の“この世の花”がかかっていたそうだ。ファンの子はこの曲がかかると嬌声を上げていたという。
みんな中卒であったためか、工場内に講堂があり、和裁洋裁、その他勉強を専任の先生が教えていたそうだ。
医務室もあり、ケアをきちんと行なっていたようだ。
みんなが自由に使える休憩所には長いこたつがあり、32年ごろにはテレビも設置され、相撲などを観戦していた。
社員旅行も何回か行っており、草津や鬼怒川温泉の写真が残っている。
寮生と家族が談話できる面会室があったり、家の近い子は週末に家に帰ったり。
辛かったことは、慣れない時の朝４時半に起きること、寮には給湯設備がなく真冬でも洗顔や歯磨きが冷水だったこと。ただし工場内はスチームで冬は暖かく、仕事そのものは辛くはなかった。
寮の食事も十分な量があり、おやつは近くの店でコッペパンや壺焼き芋を買っていたそうだ。B班の就業時間の終わりにはあんぱんの夜食が支給されていた。

話を聞く限り、当時としては厚生も良く、写真を見ても皆明るい雰囲気でよい環境であったと思われる。
まぁ母は女工哀歌の話はピンとこないようだけどね。

最近はガジェット系というかArduino系というか、いわゆる評価ボード系マイコンに興味がある。

Raspberry pi, Auduino UNO R3 から GR-SAKURA と来て、FPGAスパコンっていいかも…などと考えている今日このごろ、その手のイベントである Maker Faireに行ってきた。

今回の注目点は２つ、ロボット農家のnao氏のプレゼンテーションと、Intelが今月中に販売を開始すると言われているGalileoである。
今回はGalileoについて記載する。

Arduinoと、その互換品や派生品（いわゆるArduino系ボード）は、基本的にOSを持たない。
だが、Galileoは400MHzのPentium互換SoC(Intel Quark SoC X1000)、256MBのRAMを持つIA系コンピューターであり、フルスペックのLinuxが動作する。
Linuxが動くだけならRpiやBBBでも良かろう。だがGalileoの強みはArduinoのシールド互換であることだ。
まぁそのためにGPIO PWMを載せる必要があるなど、IA系らしいゴテっとした構成ではあるが。
軽くデモ機に触ってbusyboxのシェルからdmesgをざっと見たところ、一般的なIA32と大きな違いは無いようだった。
デフォルトの I/O Sceduler が cfq だった辺り、本当にそのまま載せた感があった。
11月下旬には発売されるそうなので、やや期待して待つこととする。
ちなみに価格は\7k～8k位とのこと。評価ボードと見るかArduino系と見るかで、価格の評価は変わりそうだな。

これから今までカロリー管理をしてみた結果、およそ食事と必要カロリー数値の感覚が掴めたので、一旦記録を停止してみる。しっかり記録していくことはそれなりに労力だからね。
アタリマエのことかもしれないが、
　・運動をしないと体重が増える
　・体重維持の目標摂取カロリー内であっても腹は出るｗ
というのを実感できた。

それとイートスマートとは関係ないけど運動後のマルトデキストリン（高GI）とプロティン摂取で確かに体を大きくできるね（筋肉と体重＋＋）。

上司がS3のファイルを勝手にGlacierへ移していたとか想定しとらんよ…

前回までのS3への読み書きは、もちろん他のツールで実現できるので、それほど boto ライブラリを使用する意義はありませんね。では他のツールでは見かけたことが無い、rsync のような帯域制限を行ってみましょう。
大量のログなどを自身のネットワークからからS3へ転送する際、転送そのものの帯域占有が問題になることがあります。ログ転送の帯域を絞り、他への影響を軽減します。
余談ですが、東京リージョンのサービスが始まる前の2011年3月以前、シンガポールやUSへの転送は、そのままでは遅かったため並列数を上げるなど工夫をしていたものです。東京リージョンの開設によって解決したのですが、最近とある件でS3への転送帯域を制限したいとの要望があり、たった1年半で隔世の感を味わうことになったのでした。

さて、前回書き込みに用いた set_contents_from_filename() には、callback関数を与えることができるので、今回はこれを用います。

callback関係で使用する引数は以下の二つです。
    - cb : callback関数名 (default: None)
    - num_cb : callback回数 (default: 10)

また、今回は利用しませんがcallback関数への引数は以下の二つです。
    - (転送済みバイト数, ファイルバイト数)

帯域制御の方法についてはいくつか方法がありますが、ここでは単純に
・ファイルサイズを秒間転送量で案分し、callback回数を算出
・1秒以内に指定バイトを送信したら残り秒数を待つ
・指定バイトの送信に1秒以上使用した場合は待たずに次の指定バイト数を送信する
という戦略を取ることにします。

1秒経過をどう取得するかですが、単純に考えて前回の終了時間を保存し、一定バイト数転送後の時間と比較し1秒未満なら残時間を time.sleep() で待つなどが考えられます。しかしそれはスマートでないのでパス、今回はタイマースレッドとEventを組み合わせて実装します。

以下、ローカルの foo_bar.txt ファイルを s3://foobar/abc/foo_bar.txt へ 200kb/sec で転送するサンプルコードです。

# coding: utf-8

import os
import sys
import time
from threading import Thread, Event

import boto

def wait_cb(dummy1, dummy2):
        ev_wait.wait()
        ev_wait.clear()

def wait_th_run(sleep_sec=1.0):
        while not ev_terminate.isSet():
                time.sleep(sleep_sec)
                ev_wait.set()

if __name__ == '__main__':
        ev_wait = Event() # 転送制御用イベント
        ev_terminate = Event() # 転送制御用スレッド終了用イベント
        wait_th = Thread(target=wait_th_run) # 転送制御用スレッド作成
        wait_th.start()

        fname = './foo_bar.txt'
        filesize = os.stat(fname).st_size # ファイルサイズの取得
        cb_count = int(filesize / (200 * 1024)) # callback回数算出

        conn = boto.connect_s3('accceskey', 'secretkey')
        bucket = conn.get_bucket('foobar')
        s3key = boto.s3.key.Key(bucket)
        s3key.key = 'abc/foo_bar.txt'
        s3key.set_contents_from_filename(fname, cb=wait_cb, num_cb=cb_count)

        ev_terminate.set() # 転送制御用スレッド終了イベントset
        wait_th.join() # 転送制御用スレッド終了を待つ

Event オブジェクトによってどのような挙動となるか、ソースを追ってみてください。

次回はElastic MapReduceを実行する方法について紹介します。

EC2と並ぶAWSの提供するサービスの双璧はS3ではないでしょうか。

botoでは、bucket と key という概念で扱っています。
Management console やファイラー感覚で扱うツールではあたかもファイルシステムのように見えますが、S3 はディレクトリよりもKVSに近く、bucket/key のの組み合わせで URI を表現します。処理の流れとしては
・bucketの取得
・keyの取得または生成
・keyへ入出力
となります。

プログラム上から新規にbucketを作成することはあまり多くないと思うので、ここでは既に作成されたbucketに対する入出力を解説します。

>>> import boto
>>> conn = boto.connect_s3(AWS_ACCCESS_KEY, AWS_SECRET_KEY)
まずはモジュールのインポートと接続です。

EC2と異なり、regionの指定はありません。
これは bucket がグローバルでユニークである為、作成時のリージョンに向け接続を行っているからです。

・bucketの取得

明示的にbucket名を指定する場合は get_bucket(bucket名)、一覧の取得は all_buckets() です。
>>> bucket = conn.get_bucket('foobar')

>>> buckets = conn.get_all_buckets()
>>> buckets
[＜Bucket: foobar＞, ＜Bucket: bazz＞]

これらは boto.s3.bucket オブジェクトです。

・keyの一覧
>>> keys = bucket.get_all_keys(prefix)
prefix を含む key のリストを取得します。
得られるリストの中身は boto.s3.key オブジェクトです。

・既存のkeyの取得
>>> key = bucket.get_key(key_name)
key_name に一致したkey を取得します。

・keyの内容をファイルへ書き出す
>>> key.get_contents_to_filename('foobar.txt')

・新規keyの作成
>>> new_key = boto.s3.key.Key(bucket)
>>> new_key.key = 'bazz/foobar.txt'

・keyへファイルを書き込む
>>> new_key.set_contents_from_filename('local_file.txt')

次回は応用編として、帯域制限の実装を紹介します。

AWSのサービスで最初に思い浮かべるのは何でしょうか。
やはりEC2ではないかと思います。

今回はbotoによるEC2インスタンスにの操作について解説します。
事前に Key pair やセキュリティグループを作成しておきましょう。

>>> import boto
>>> from boto.ec2.regioninfo import RegionInfo
まずはモジュールのインポートです。

>>> AWS_ACCCESS_KEY = 'your access key'
>>> AWS_SECRET_KEY = 'your secret key id'
おなじみのアクセスキー、シークレットキーを用意します。

>>> REGION_ENDPOINT = 'ec2.ap-northeast-1.amazonaws.com'
ここで Endpoint を指定しています。下記のURLから使用するリージョンのエンドポイントを参照します。
http://docs.amazonwebservices.com/general/latest/gr/rande.html
今回は日本リージョンを使用します。

>>> region = RegionInfo(endpoint=REGION_ENDPOINT)
>>> ec2 = boto.connect_ec2(AWS_ACCCESS_KEY, AWS_SECRET_KEY,region=region)
Retion オブジェクトを作成し、access key, secret key, region を指定し ec2 へ接続します。
リージョンを指定して ec2 へ接続する場合、boto.ec2.connect_to_region() も使用できますが、他のサービスでは類似のメソッドが無いので、共通の方法を使用します。

>>> resv = ec2.run_instances(image_id='ami-2819aa29',key_name='your key',security_groups=['your sg name'],instance_type='t1.micro')
AMI を amazon linux(x64)、インスタンスタイプを ti.micro、キーペア、セキュリティグループのリストを指定します。
resv は Reservation オブジェクトです。これはインスタンス作成毎に生成され、同時に作成したインスタンスのコレクションです。

>>> i = resv.instances[0]
>>> i.add_tag(key='Name', value='test-boto')
Reservation からinstanceを取得し、Nameタグを設定しています。

常にインスタンスを必要としないのであれば、必要な場合のみインスタンスを起動し、それ以外では停止させてランニングコストを抑えます。

・インスタンスの開始
>>> i.start()

・インスタンスの停止
>>> i.stop()

・インスタンス情報の再取得(返り値はインスタンスのstate文字列)
>>> i.update()
u'running'

i.state でも取得できそうですが、これは最新の状態を表していません。update() にて常に最新の状態を取得する方が良いですね。時々インスタンスの起動・停止に失敗することがあるので、update()による状態取得は自動処理では必要になります。

・public dns の取得
>>> i.public_dns_name
u'ec2-xxx-xxx-xx-xx.ap-northeast-1.compute.amazonaws.com'
elastic IP を利用していない場合、インスタンス起動毎に外部DNS名（とIPアドレス）が変化するため、このプロパティから取得します。

・Tagの取得
>>> i.tags.get('Name')
u'test-boto'
インスタンスを特定する一つの方法として、特定のタグに一意の値を設定しておき、それを参照します。

またReservationはインスタンス作成毎に生成されるため、インスタンスを都度作成していると、別々のReservation作成され個々の instance オブジェクトの取得が面倒になりがちです。
下記のように内包表記を使用すれば、全てのinstanceオブジェクトのリストを取得できます。
>>> [i for r in ec2.get_all_instances() for i in r.instances]

タグの Name の部分一致で取得するなら下記のようになるでしょう。
>>> [i for r in ec2.get_all_instances() for i in r.instances if 'test' in i.tags.get('Name')]
上記は Name に test を含むインスタンスのリストを取得します。

get_all_instances()にfilter条件を設定してリストを絞れるようですが、タグの部分一致と完全一致を使い分けるなどの柔軟性で内包表記をよく使います。

次回はbotoからS3を操作する方法について紹介します。