In a corner of this planet

ペッパーミルが欲しくなってきました！ 口上 前回、Dataを標準関数を用いて、読み込んでみました。他言語と同じように、csv的なものは追加libraryが潜んでいるもので、Juliaもご多分に漏れず存在しています。 では、何故最初から使用しないか？という疑問が湧きます。いずれ訪れるであろう大量(破壊)Dataを目の当たりにした時、太刀打ちできない可能性がでてくるかもしれません。 つまり、通常装備(標準関数)のみで凌がなければならないかもしれないのです。便利すぎるのは身体に毒です（笑） csvread関数 しかし、Juliaは標準だったりします。（笑）Pythonも今は標準なのかもしれません。（基本的に、いつも自家製関数なので…) 準備したDataは、csvread関数が想定している範囲内になっているので問題なく使用が可能となっているようです。 ただ、0.7以降は、関数名が変更されています。以下、説明致します。 では解説（Header無し編) 0.6.3での、お試しの実行方法は以下。 $ ./practice_01.jl ./data/elements.csv readfile()関数部分は以下のようになっています。 function readfile(filename) L = readcsv(filename, comments=true, comment_char='#') (rnum, cnum) = size(L) @printf("(row,col)=(%d,%d)\n\n",rnum,cnum) for i = 1:rnum println(L[i,:]) end end readcsv()関数では、コメントの有無とコメント示す開始文字を設定しています。 size()関数の返り値はタプルで、行数と列数を返しています。 @printfは 、format付きの出力を行う際に使用する関数になります。 諸々の処理がreadcsv()関数にて実現できているので、Code自体はスッキリです。 Codeは、 ここ にあります。 @printfは 、以下でも問題はありません。 @printf "(row,col)=(%d,%...

ツナパスタ。どうしても、ひと味足りない。どの調味料なのだろう。。。 前口上 前回の結果、Dataが準備できましたので、軽めの実践を行います。 Manualやあちこちをクロールしていますと、Juliaは、本当に、Peakyな機体だな、と（笑） Python界で言うところのpandas的なDataを準備するまでをPythonで、その後の実行をJuliaでなんていうのが、(個人的にはPythonに慣れている手前)一番効率がいいのかな、と思っていたりします。 実行環境 Fedora 28 Julia 0.6.3 Ubuntuでもなく、Macでもなく。慣れた機体っていうのはいいものです（笑） Juliaは標準ReposにてInstallしているものです。JuliaのSiteを見ると、coprにてのInstallが記載されていますが、1.00相当が見当たらなかった(2018-08初頭。つまり、1.0が出てすぐの頃)ので、ひとまず0.6.3で行こうかと思っています。 tarballからbuildしてもいいのだけど、本論ではないので。まあ、そのうちUpgradeされるだろう、と。 まずはHello World 鉄板ネタでHelloWorldであろう、と。 $ ./hello.jl Hello Wolrd on Julia!! と実行することで、標準出力に、Hello Worldが出力されます。 Pointと言うほどではないですが、Shellモードにて実行しています。そのため、Scriptの中身は以下のようになっています。 #!/usr/bin/env julia println("Hello Wolrd on Julia!!") 1行目は、言ってしまえばおまじないみたいなものですね。 Codeは、 ここ にあります。 すっぴんで読み込んでみる Fileを開いて、読み込ませて、必要なDataを、配列に格納してみる、ということを行ってみます。 Pythonで言うところのArgumentParserを探しきれなかったので、最低限の引数を制御できる 予約語ARGS を用いて、実装を行っています。 例えば、 $ ./hoge.jl abc.txt def.txt と実行すると仮定すると、 hoge.jl : ARGS...

前口上 何故かビット演算の話からということになっていますけれども。読んでいて、ナカナカ面白そうだったというのが大きくて。 そろそろ新しい言語を、ということを考えてもいたので、Julia。 Pythonっぽい（後に違うとわかる）ので、少しいじってみたら、これは、と思ったので。不定期で書いていこうかと思っている次第です。 Benchmarkを見ると、演算に関しては、速いのですよ。Fortranよりは遅いのだけど、Cよりちょいと遅いって感じで。（少し誇張） Pythonが全方位で汎用的なのに対して、Juliaは赤いカラーリングが施された専用機（演算特化型）という違いなのかな、と。そんな感じがしています。 下準備（データどうしよう編） いつも悩むところなのです。お試しデータをどうするか？というところで。 以下に、注意を払っていて、 100行から500行ぐらいまでの適量なData（列方向は20列程度まで) csv的なFormatで、Data欠損がない Data自体は中立的 というものです。国や地域になるべく依存してないDataを、ということです。 これを考えていくと、植物や動物のData（図や写真無し）がよいのでしょうか、と、OpenでFreeなものを日々探しているのですが、これは！というものをナカナカ見つけられずにいて、その時点で、作業が始まらないというジレンマに陥ってるということになっています。（本末転倒という） jsonだと、階層的でもあり、いいのですが、初歩においては、限りなくcsvに近いものを扱うのがよいと考えて、準備を開始します。 下準備（データこうしよう編） 先にも書きましたが、Formatは以下のようなものを準備します。 csv的なFormatベース header行の有無は適宜 各要素にData欠損無し デリミタはカンマ 各要素にカンマは含まない、スペースは含んでよい 任意行の1文字目がシャープの場合、コメント行 これを網羅したDataをどうするか。現時点で用意したのは、元素周期表のDataとなりました。 各元素の全Dataではないのですが、ひとまずこれで進めてみようということにしました。 読み込ませてみるっていうもので、ガツガツと演算をというものではないですが、読み込んで、配列等に格納するという意味では...

事始め JuliaのOnline Manualを読んでおりまして。その流れで、いろいろと書いておくのもよいかもしれないと思いまして。 つらつらと始めようか、と。ゴールは定めていないので、それなりに（笑） で、読んでいて、急に、気になったのが「ビット演算子」というお話。 Julia Version on Fedora 28 今後、何度も記載することになるのでしょうが、 Fedora 28 に標準搭載されているのは、 0.6.3 というVersionです。 Fedora 29 (2018-10-30 Release予定)には、 0.7.0 か 1.0.0 のどちらかが搭載されると思います。ちなみに、Juliaの最新Stableは1.0.0です。（1.1.0は開発版） 従って、以降のお話は、しばらく、0.6.3でのお話になります。 ビット演算子とは？ まずは、気になったビット演算の例をば。（結果的には、勘違いきっかけ。恋のようなもの） julia> 1 & 1 1 julia> 1 & 0 0 julia> 10 & 10 10 julia> 11 & 11 11 julia> 11 & 12 8 Interpreterモードにて、お試しをしてみました。へぇーなるほど、と。 ただ、我々は普段10進数の世界にて生存していることから、 11 と 12 の積である 8 に疑問が湧きます。 というか、湧いてしまったのですね。「ビット演算子」という項目なのに。 すわ、ビット演算 つまるところ、ビット演算とは、10進数の世界ではなく、非常にコンピュータに優しい2進数の世界の演算ということになります。 例えば、10進数にて、29という数字は、 29 = 2 * 10^1 + 9 * 10^0 ではありますが、2進数では、 > 29 = (1 * 2^4) + (1 * 2^3) + (1 * 2^2) + (1 * 2^0) ということになります。括弧は見やすくするための措置なので、意味はありません。 もう少し詳しく書くなら、 29 = (1 * 2^4) + (1 * 2^3) + (1 * 2^2) + (0 * 2^1) + (1 * 2^...

竹輪って、何気に、万能選手だと思うのですよね。 ダンダンダダン IMEに何を使ってるかと言いますと、その昔は、 Anthy で、今は、 Mozc だったりします。 辞書は鍛えたりしてなくて、ほぼスッピンで使用しています。普段使用する文字入力においては、ほぼ不満もなく使用できています。 特殊文字 キートップ（キーボード）を眺めていると、「M」の右隣のキーに、「ダッシュ」があります。ただ、キートップ上は、右上にありますので、通常入力ではなく、Num等を使用して入力することになるのでしょうが、考えてみるに、使ったことないな、と。 果たして、どのように入力するのだろうか？と頭をよぎりました。 ダッシュ 日本語的には、「ダッシュ」。英語的には、「プライム」。仏語的には、「アクサン・テギュ」。 数学的には、「一次微分」。これが一番わかりやすい（笑） 画面的には、「シングルクォート」との相違がわかりにくいってのも問題っちゃ問題なのですけどね。 入力方法（ダメ） いつも助かってますググる先生によると、 B4と入力して、文字をMarkした状態で、Alt+X かな入力にして、SHIFTを押しながら、Mの右隣キーを打鍵 これらは、Fedora上のTerminalでは、なんら効果のない入力方法でした。 ただ、「B4」は、Unicode的に、「U+00B4」であり、 Unicode入力 ができれば、表記可能を示しています。 入力方法（よっしゃ） その方法とは、 Ctrl+SHIFTを同時に押しながら、uを押すことで、入力モードにする Unicodeのコード「b4」を入力し、RET Fedoraでは、「u」が表示されつつ、入力待ちの状態になっています。「b4」を10進数化すると、「180」なのですが、先の失敗と同様に、「180」と入力すれば、というところもあるのですが、「U+0180」のことになりますので、全く別の文字が出力されることになりますので、注意が必要です。 例 表示 コード 読み ´ U+00b4 シングルプライム Σ U+03a3 シグマ π U+03c0 パイ ∞ U+221e 無限大 「シグマ」は「U+2211」にも存在するのですが、どちらがよいのでしょうかねぇー...

あんドーナツ。和洋のセッションが素晴らしい！ 時々、気まぐれ ほぼ修飾をせずに、諸々使用しているんですが、それでも、ちょっと変えてみたい気になることがあります。ほぼ気分。 今回の気分は、Code部分の 行数表示 に関してです。 まだ、Bloggerの使い方がよく分かってないので、できるのかもしれないですが・・・。 記事を修正すると、修正日時で公開されるので、過去日も修正日になってしまうので、過去分は 行数表示無し で行こうかと思っています。（仮に、できるとしても、あれこれ修正するので、いささか・・・） pandoc変換 Markdown での記述が、 Test Test のようになっていると、 pandoc 後は、 <pre class="lang-python"><code>Test Test</code></pre> と出力されます。pandocでは、何もせず、単に、markdownを変換しただけの状態です。 ただ、諸々のCode HighlightをsupportできるJavascriptでは、以下のような記述にする／なるようになっています。 <pre><code id="lang-python">Test Test</code></pre> 上記の「id」部分の記述は、 Prism.js でのもので、「lang-xx」もしくは「language-xx」がHighlightをさせるAttributeになります。 Code Highlight on Prism.js 使用している Prism.js で、行数表示を行うには、HTML上で、 <pre class="line-numbers"><code id="lang-python">Test Test</code></pre> のように、 <pre> に、「class」属性を記述すれば、可能となっています。 諸々変換 pandoc変換後HTMLからBlogger用HTMLにするための、諸々変換その1を上記仕様に合わせる形でUpdate。 ...

レピシを見ると、牛乳！ほう！ マヨ！ほう！となってたけど、結局、塩コショウに落ち着きました（笑） ある日の出来事 Upgger した後、 Preview で、全体確認をやっています。Upload後は、公開制御ぐらいになってるわけなんですが、ある時、Titleが変なことに気づきました。 例えば、今日のタイトルをベースにお話すると、Previewでは、「やっぱりawk」となっていたのです。はて？ デフォルトはスペース Markdown での記述は、 % Title: やっぱりawk 〜Title編〜 なっていて、正しくは、「やっぱりawk 〜Title編〜」となるはずなのです。Title部分の処理には、 awk を使っていて、何も指定をしないと、デリミタはスペースなわけです。つまり、 第一フィールド：　% 第二フィールド：　Title: 第三フィールド：　やっぱりawk 第四フィールド：　〜Title編〜 となっていて、本処理部分のCodeは、 TITILE=`awk '/Title:/{print $3}' ${DIR}/head.txt` これじゃ、出力されません。そりゃそうだ。 第三フィールドのみ となっているのですから。 考えてみれば、スペース無しでタイトルをつけていましたし、Label側で問題が発生しないのは、LabelはAPI上、「 カンマ 」がデリミタですので、 第三フィールド を指定すること自体に矛盾が発生しなかったというのが一つの原因でした。まあ、独自ルールなので、注意が必要ってことになります。 いったんawkったら、最後までawk その昔は、awkでも長い記述をしたものですが、複雑処理は、 Python などにお願いにすることなるので、awkでの処理は、「限りなくワンライナー」にしておこう、否、おきたい、というのが、どうでもよいポリシーです。（笑） すると、ここでのawkは、「 第三から最終フィールドまでを取得する 」ということなります。 TITLE=`awk '/Title:/{print substr($0,10);}' ${DIR}/head.txt` 独自ルール（またか！）上、「Title:」の後ろは、「半角スペース」の後、「タイトル」を記述するということにしています...

豆板醤もよく使いますよ（笑） お試ししてみる たまに、お試しをしたくなることがあって。今回は、Scikit-LearnでRandom Forestをやろう、と。使用Dataは（有名な）Irisを用いてやってみます。いろいろとはまるわけです。（笑） Anaconda 「データサイエンス・機械学習向けのPython+RのDistribution」とあります。確かに、いつものように、Google先生でも、Anacondaというのがよくでてくるなぁ、と。pipじゃダメなの？というよりも、「RedHat系のOS Installer」の名称じゃないの？っていうのが、まずよぎります。個人的に、いつも混乱をきたすのです。（笑） Anacondaは 特化型 （カプールみたいなもの）だけど、VirtualEnvだと 汎用型 （ザクです）なので、後者を選択。 各種Version on VirtualEnv Python 3.6.6 Numpy 1.15.1 Pandas 0.23.4 Scikit-Learn 0.19.2 VirtualEnv上に、pipでInstallしたものです。こちらも個人的には、自家製はv3ベースのみになったので、venvでもいいのだけど、諸々v2じゃないとダメなこともありそうなので、VirtualEnvを使ってるという感じです。 DeprecationWarning from sklearn.ensemble import RandomForestClassifier sklearn.ensembleをimportすると、 DeprecationWarning: numpy.core.umath_tests is an internal NumPy module and should not be imported. It will be removed in a future NumPy release. from numpy.core.umath_tests import inner1d という警告がでます。Errorじゃないので、動かくなくはないのだけど、モヤっとします。 StackOverflow先生に聞いてみたりしますと、Numpyとscikit-learnのversionが問題で、scikit-learnを...

どちらかと言うと「つぶあん」派かもしれない、と思うのですけどね。 現時点での総括 バタバタって感じできましたけど、とりあえず、今の時点でのまとめを作っておこうかと。 Phase 1. どこにどう記述するか？という選択。 投稿先を決める Blogger を選択 Formatを決める Markdown形式 を選択 pandoc にて、HTMLへ変換 Google Accountを作成 Blogger を立ち上げる Onlineで試し投稿 UploadはHTMLね、というのもありました。が、Blogger選択時に、Google先生は、Markdown云々という結果も得ていました。そこからの逆算で、Markdownの選択は、DataはLocalに持ちたいという希望にも叶うものでしたので、ほぼ一択に近い形での選択になりました。ただ、Upload前後での手間がそれなりにかかることが分かったので、その解消を考えました。それが次のPhaseです。 Phase 2. どういう流れなのか？を把握するお話。 Google Developer Consoleに登録 Blogger API v3 を有効化 Secret ID 等を取得 Python追加ModuleをInstall google-api-python-client oauth2client exampleを試す 試し投稿 のUp/Down Upload用Script（ Upgger ）作りつつ、改善したい点がでてきました。 Tagの属性に関すること id属性 class属性 Tagの不足に関すること カラーリング センタリング Data(not HTML)の置き場 JS text Code Highlight 用のLibraryであるJSの置き場を確保するための(3)。置き場は、 Github Pages 。 Libraryは、 Prism.js を選択しましたので、 <code> に属性を必要があり、pandoc変換で得られる場所からの置き換えを行う必要が出てきました。 Phase 3. どう効率してゆくかというお話。 HTMLのTag ID変換及び削除用Python Script HTMLのTag追加用...

無印さんの「グリーンカレー」青唐辛子が好みかも。。。 HTML5 <center> は、HTML5では、廃止されている。 CSS にて対応するよろし、ということになっています。ってことは、現行の変換だとダメというお話に。ほぼ作り直しに近いですやん。 追加仕様 変換ルールを以下のように変更しました。 変換前 変換後 (1) +++{x}string+++ +++{x}string+++ (2) +++{ss}(ta:center)string+++ <span style="text-align:center;> string </span> (3) +++{ss}(c:#ff0)string+++ <span style="color:#ff0;"> string </span> (4) +++{sc}(hoge)string+++ <span class="hoge"> string </span> (5) +++{dc}(moge)string+++ <div class="moge"> string </div> (1)は、何もせず、そのまま出力 (2)は、文字(string)をセンタリング (3)は、styleにて、色・サイズ等を指定 (4)は、class属性の定義が可能 (5)は、class属性の定義が可能 「{ss}」や「{dc}」などは、(Script上)限りなく予約語っぽいものになっています。 上記だと少し不親切ですが、「{ss}(c:#ff0,b:lime)」のように、「style」内は複数定義が可能ですし、「{sc}(aaa bbb)」のように「class」も複数定義が可能になっています。 限りなく完了形 ほぼ所望のことは可能になりました。 シメ！ 春 は花 夏 ほととぎす 秋 は月 冬 雪さえて すずしかりけり Awesome!!

流石に、同じネタが続くと枯渇してくると申しますか。否、すでに、投稿する文書を書くことに集中すればいいという状況が作られつつ、あるということで。 最初のタブレット 何時、購入したかは覚えてはいないのだけど、800☓600クラスでした。中華パットで、量販店だと、タブレットはまだほとんど店頭に並んでいない頃だったと思います。近場のPCショップのワゴンで買ったのが最初だったかな、という記憶があります。 動画を観るのには、CPU性能が不足でしたが、これまた当時だと、mp3プレーヤと文書閲覧のために、軽いものを、というのに、見合うハードがタブレットという選択肢だったのですね。（スマートフォンもない頃か。。。） こだわりの機能 その初期から今まで一度も方針を変えたことはないのが、 SDカード が使用できるかどうか。これは、本体側は標準SDであればいいって話で、その分の本体価格が低くなるのと、手持ちのSDが流用できるというのが大きかったですね。 困り事 まあ、致し方ない部分はあるのですが、CPUの性能不足というのが数年経つと出てきます。まあ、これは、ハードなので仕方がないのですが、それ以上に、問題なのは、OS更新がされないというのがあります。ある意味、OS好き（というカテゴライス）からしてみると、最新は入れたい・使いたい、というのが本音のところで、その部分が、いつも、悶々とするところだったりします。 KernelをBuildするのはいいのだけど、rootまでとって云々というのはやりたくない、というか（笑） 今使ってるのがどういう状況かは調べてないので、調べてみないとダメですね（笑） 最近のタブレット 考えてみると、歴代ずぅっと中華系パッド。国産やリンゴは使ったことがないし、多分、これからもそうな気がします。初期の頃に比べると、安かろう・怪しかろう、というものでしたけど、今は、価格以上に高性能。今使ってるのは、4コアで2K画面（笑） 解像度が高すぎて、アプリ側の方が挙動不審（笑）

仕事って生まれてきちゃうものだしな、というのが持論だけど、他視点だと、「忙しくしてる風」になっちゃうのが難点です（笑） Markdown拡張 前回、「色付き」や「センタリング」ができない、っていうお話で。やっぱ、たまに、なんとかしたいよね、と思うことが必ずでてくると思われる案件だと思っています。少し拡張してみることにした（笑） 自分用だからいいだろう、という。 文字に色をつけたい 文字をセンタリングしたい 今の要望はこの２つです。上は、 <center> タグ。下は、 <span> タグを用いればいけると考えました。 問題は、Markdown上、どうするか？というお話です。 決めたこと 変換ルールを設定しました。 変換前 変換後 (1) +++string+++ +++string+++ (2) +++()string+++ <center> string </center> (3) +++(c:#ff0)string+++ <span style="color:#ff0;"> string </span> (1)は、何もせず、そのまま出力 (2)は、文字(string)をセンタリング (3)は、styleにて、色・サイズ等を指定 (2)が奇妙に見えます。ただ、Markdown的に、特殊ルールを複数作るのは、大変だな、と思ったので、「+++」だけで対応しようと考えました。現状、二択なので、現行(考えてる)仕様やれる話なのですが、もっと増やすことを考えると、仕様拡張が必要になってきます。(こう書いた時点で、どうしようかと思案し始めるのであった) 本質的に、こういった拡張部分に、入力手間を増やしたくない（それが数文字であったとしても）ので、color表現なども、なるべく少ない文字数で表現しようとしています。 ちなみに、この「c」に相当する部分は、PythonにおけるKey（辞書）相当なので、出力時には、Valueを使用するようにしているので、実際のところ、対応は自由！（笑）今は、「fs」が「font-size」と「fs」が「font-style」になっています。 +++(c:#ff0,fs...

同じテーマで、いつまでやってるんだって、話なんですが、もうちょいで、終わりかな、と思ってるところです。もう少しお付き合いくださいませ。 作業手順 現状の作業手順は以下のようになってます 投稿するMarkdownをEditorにて記述 pandocにて、HTMLに変換する HTMLを少し修正（Upload後でもOK） Upggerにて、タイトルやラベルを決め、Upload Blogger上にて、編集＆公開 という流れです。 ただ、項目だけ記載すると、まあ、そんな感じよね、と思うのだけど、実際は。 作業時の問題点 各Scriptと記事の格納場所が異なるため、出入りが面倒 フルパスでええやん（深いと大変。いっぱいあるし、毎回だし） Terminalを準備すればええやん（画面が狭くなる） 手入力多い（どんだけ省力） 素と仮想の出入りが面倒 System側に影響がでないように、追加Moduleで特殊なものは仮想 今回の大半は仮想側にInstall タイトルとラベルの入力が面倒 TerminalのCLIで日本語をあまり扱いたくない（わがまま（笑）） HTMLの微調整の量がそこそこある こだわらないと、別にいい部分も多分にある HTMLの微調整に関しては、部分的には、Scriptで逃げることにしました。それ以外は、フロー上の問題なので。 最近の言葉で言うなら、RPA案件ですかね？ 一括処理 できうることなら、記事を作成しているDirectoryから、Uploadまでを一括で行いたいので、Bashやawkの出番と相成りました。 今は、 $ go 20180903.md と行えば、Uploadまで終わります。Blogger上では、手元ではできない処理だけを行えばよいところまで、ほぼ持っていけたのではないかという状況になりした。個人的には、超絶楽になった、というのが正直な気持ち。 検討項目 色付け センター化 HTML上で上記のようなことをしたいので、そちらを調べようかと思っております。 Offset問題 今、ReleaseしているUpggerは、Dateutilを使用しているが、どうやら問題あり。 当初、tzlocalを使用していたが、Upload時間に差が発生するので、Dateutil.tzに...

何も考えずに、あっさりと終わってしまうのもさみしいものではありますが、細々とした問題が発生し続ける状況 は、それはそれで辛いものではあります。 格納場所 認証用Fileを直下においていたんだけど、それはあまり綺麗ではないな、ということで、隠しFolderにおくことにした。 flagの問題 flags=Noneとでもして、対応しないとダメ、ということを書きましたが、なくても動作している状況になってて、ただ、無いよりはあったほうが確実性が高い(信憑性があれだけど)と思うので、その部分はそのままにしておくことに。(今のところ) fetchImagesの問題 insert()関数の引数に、fetchImagesがある。引数そのものは受け付けているようだけど、実際の画像Dataそのものは、どうやってもbodyに返ってこない、という状況になっています。StackOver Flowなんかで、「画像のUploadは許容してないぜ！」なんていうのも見受けられるので、そうなのかもしれない。 borderの問題 Bloggerではなく、pandocの問題。単純にMarkdownを変換すると、表のborderはない状態で出力されます。出力されたHTMLに 以下のような記述を追加すれば、表示はできるので、まあいいか、と。（頻度の問題） <table border="1"> classの問題 一番の問題は、Markdownとpandocをちゃんと理解していないってことなんでしょうけどね。 <pre class="language-python"><code> ではなく、 <pre><code class="language-python"> であった欲しいというお話です。Code Highlightは、Prism.jsを使用予定なんですけどね。 idの問題 これは、どちらかというと生理的な問題で（笑） <h2 id="ほげ">ほげ</h2> 総括すると Markdownと、それに伴うpandocをきちんと把握して、対処すればよいのでないか、というお話です。 Markdownの記述そのもの ...

大枠での方向性は決めたものの、詳細を詰めてゆく必要があります。 いろいろ試していると見えてくるものもあるもので。解釈の間違いも諸々（笑） ホトトギス 家康的に、良いEditorが出現するまで待つ、というのも、信長的に、面倒くさいからBloggerやめちゃう、というのも、答えにはならず、結果的に、秀吉的に、じゃあ、作りますか、ということに。 先生、ありがとう 先生と言えば、Google。BloggerもGoogle。Google Developers Consoleには、GoogleのService向けのAPIが準備されていて、当然、BloggerにもAPIが準備されています。Blogger API v3。 いくつかの言語が対象となっているが、当然のように、Pythonを選択。 Sample Code Python用のSampleがあり、Client IDを取得して、実行。ContentsのStatusがLIVE（公開）のものを取得して、表示するScriptになっているようであった。JSON形式で取得している。ふむふむ。 insert()関数のisDraft引数の話 現状の必須と考えている機能を実装するにあたって、2つほど悩んだ部分があった。その内の1つが、insert()関数のisDraftという引数。これは、StackEditでPublishedやStatusとなっていたもので、Contentsの状態を決める引数です。 Developers Consoleにある実行検証用のMenuには、isDraftはtrueとfalseの2値が扱えるとなっていて、つまるところ、前者がDRAFT（下書き）、後者がLIVE（公開）だろうと推測できる。 設定値 結果 true LIVE(公開) false DRAFT(下書き) ところが、実情は異なっていた。 設定値 結果 - LIVE(公開) None LIVE(公開) Integer DRAFT(下書き) String DRAFT(下書き) 試した結果だと、上表の結果となっており、Noneかそれ以外で、所望の結果を得ることが可能であった。(正しいのだろうか？) Boolean値には間違いないが、それはPythonでは...