の作業記録

ゆっくりする日曜日

9:00

おはようございます。昨日はわりと疲れたので、今日は早めにゆっくりしたいところ。あと、本も探しにいきたいです。

買った本:

来週の確認:

まずは予定の確認から。

＊　＊　＊

予定の確認と、タスクの宣言を行いました。今週は未達成タスクが２つあったので、新規は２つだけです。

週報作成:

今週は、妻が昼間出かけるリハビリをしたいというので、基本的に昼間は妻につきあっておりました。だいたいは元気に出かけられていたようなので安心です。でもって、来週から仕事への復帰となります。こちらはどうなるかはまだ不明ですが、今の調子なら大丈夫ではないかという感じです。

その反面倉下の作業時間が思うようにとれず、一日の過ごし方のリズムも狂ってしまったこともあったので、進捗自体は低速でした。でも、優先順位的には仕方がない結果です。徐々にならしながら、仕事を進められるようになりましょう。

で、とにかく忙しいです。

もっか、これだけを抱え込んでいます。でもって、日々の読書やら読書日記やら読書メモなどもあります。そりゃパンクしますね。

とりあえず、メルマガの運営は破綻なく続いています。とりあえず月曜日から金曜日の間に本編を書きあげ、土曜日はそれを読み返してまとめる、というスケジュールにできれば問題なし。土曜日までに原稿が書き上がっていないと、えらく大変な思いをします。ここは守っていきたいところ。

で、project-ptはまったく問題なく毎週原稿を送信できています。「完成稿」とまではいえないもののfirst draftと呼べる原稿になっているので、これは十分な進捗でしょう。やはりこの「編集者さんだけが読む連載を書いているつもりで書く」というメソッド(like a series for only editor）は倉下には効果的な用です。少なくとも「一章書き上がったら送信します」というタイプよりは進捗が生まれやすいのは間違いありません。

project-lmでもこのやり方を踏襲する予定です。

で、問題はproject-thです。

project-lmは編集者さんとの初回の調整で今回はまだ原稿送信のレベルに至りませんでしたが、たぶんこのまま続けることはできるでしょう。若干停滞気味なproject-thが問題です。

で、これも別に原稿が書けていないのではなく、書くための十分な時間が確保できていないのが問題なのでしょう。きっとこのままいくと、来週の原稿送信予定日の木曜日に慌てて書いて送信する、という感じになりそう。

で、おそらくそれでいいのでしょう。二週間のスパンで毎日少しずつ原稿を書いていき、まとまったものを木曜日に送信する、というやり方の場合、他にやることがたくさんありすぎて、うまくそのための時間を確保できないのだと思います。「あれもやらないと、これもやらないと」モードになる、ということですね。送信日になったら四の五の言っていられないので一気に書き上がれる、という寸法。

一つの章は5000字〜8000字なので二日あれば書きあげることは可能です。だから一週目の木曜日に半分書いて、次の木曜日に残りを書きあげて送信、という形でも問題なさそう。とりあえず、その感じでいきましょう（というかそういう実態になっているので、計画もそれに合わせるという感じです）。

最後にもう一つ、BCBの仕上げに向かって進んでいるわけですが、これもリベロ的というか着手するポジションがうまく定まっていません。「気が向いたらやる」はほぼ「やらない」とイコールなのですが、どこかの曜日にコミットさせるのがよいのでしょう。

とりあえず、4月中に読んでもらえるfistdraft(pdf/epub)を仕上げることを目標とします。

getbookfeedの修正:

以前に修正した影響なのか、bookwalkerで買った本が多重に登録されてしまっています。これを修正。

Image from Gyazo

単純に推測すれば、feedを取得して返ってきた結果と、jsonのデータを比較してそれが新しいものであったら登録するという流れの「新しいものであったら」の判定がズレているのでしょう。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

    for word in templist:#探す本のタイトルを一つひとつ取り出す
        checkWord = "『" + word[2]+"』"#探す本のタイトル
        for item in fb[:30]:#対象の配列から書誌情報を一つひとつ取り出す
            if (checkWord == unicodedata.normalize('NFKC',item["title"])):
                #取り出した配列の一つの中に探す本のタイトルが含まれていたら、その本は見つかったことにして、次のキーワードに進む
                break
        else:
            updetalist.append(word) 
    print(updetalist)

コードの出力を見ると、片方は"ダンジョンに出会いを求めるのは間違っているだろうか18"で、もう片方は"ダンジョンに出会いを求めるのは間違っているだろうか１８ (GA文庫)“になっていて、これが一致しない結果をもたらしている。

つまり、どういういことだ？

ブクログのフィードは「ダンジョンに出会いを求めるのは間違っているだろうか１８」であり、これはbookwalkerのもの。で、そのタイトルでAmazonで検索して見つかる本は、「ダンジョンに出会いを求めるのは間違っているだろうか18 (GA文庫) 」。この差異が問題なわけだ。であれば、どうするか。

＊　＊　＊

アルゴリズムを整理する。

bookwalkerで買ったライトノベルは、フィードがISBNではなくbookwalkerの独自IDになっている。これではamazonのapiを叩けないので、そのかわりにタイトルを使って検索して書誌情報を取得するように処理を切り分けた。これはこれでいいのだが、検索に使ったタイトルと検索結果がずれていることによって、上記の問題が起きている。

その場合、タイトルを二パターンjsonに保存しておくか、あるいはjsonに保存するタイトルをbooklogのものに合わせておくか、という判断がある。今後すべてのライトノベルをbookwalkerではなくkindleのものとして登録するルールを守るなら、これは無視しても構わない。

＊　＊　＊

できました。登録したプラットフォームに合わせてフィードの中身を差し替えるようにしてなんとか。

1
2
3
4
5
6
7
8
9

def makeJSONData(isbn="",platformclass="amazon"):
    print(isbn)
    print(platformclass)
    temp = search_items(isbn)
    if platformclass == "bookwalker":
        temp.item_info.title.display_value  = isbn
    tempdics = parseFeed(temp)
    return tempdics

isbnは、amazonであればisbn番号が、bookwalkerならタイトルのテキストが入っています。で、bookwalkerの場合は、amazonのapiの結果から返ってきたフィードのタイトルをその検索に使ったタイトルに差し替える、という（やや強引な）やり方です。

isbnが数字だけで構成されているのかどうかで切り分けた方がコードがスムーズですが、上記のように書けば少なくとも何をやろうとしているのかは自明です。ただisbnという変数はいただけませんね。keywordとかの方がいいでしょうか。

とりあえず、isbnはkeyにしておきましょう。

で、これで修正はOKです。

10:00

レシート入力

14:00

KW+4月の注目本:

これはKWのサポーター用コンテンツとして公開予定です。

トンネルChannel:

書きます。

publish:便利なツールは言葉に乗りにくい - by 倉下忠憲@rashita2 - トンネルChannel