肉は野菜と別に焼く方が良いという当たり前の事実を知る

今日は，肉はあってもなくても良いので，鶏もも肉だけを焼いておいて，気が向いたら一部を食べようということで焼き始めた。

例のごとくヘルシオのまかせて焼きで適当に鶏肉を焼く。鶏肉を食べた！という感じにしたかったのと，切り分けるのがめんどかったので，鶏肉を400gを200と100と100ぐらいの3分割ぐらいで切り分けて焼いた。鶏肉はキッチンばさみで切るだけなので簡単簡単てある。

これをただ焼くだけ。塩の計量なども考えたくなかったので，塩は後がけで焼いた。で食べたらものすごくおいしく仕上がっててびびる。どう考えても，肉はあまり切りすぎない方が良いし，野菜とも別々に焼いた方が良いという当たり前の事実がわかる。

最近，動画でヘルシオで網焼きチキンは最高であると宣伝されていた。確かに気持ちはわかる。久しぶりにこの形で食べたけど，これはおいしい。

ただ，節約になるかというと微妙であるが。自分で焼くとおいしいさのあまり，ついつい食べ過ぎてしまう。2割引のスーパーで焼いてあるチキンより食べ過ぎてしまってお値段的にはそのチキンよりオーバーしすぎてしまうのである。どうしたことか。

サンプル問題が普通に解けない

Pythonのサンプル問題をついに解いた。以下，正しさは一切保証しません。そしてキーワードにひっかけないため試験名は一切書かないけど何のことかわかりますよねと。

設問1

まず，この試験お得意の「問題文読めてますか？」である。五角形の問題は，ここのとこの小学校プログラミングで外角で考える必要があって，その角度は 2\pi/nであることを知っているからあっさり行ける。しらなかったらどうなんでしょう。これはPythonというか算数か数学プラス読解の問題ですよね。。。

設問2

c

まず，cはリスト内包記法と[:]の文法で知ってるかどうか。ここはプログラミングの問題と言ってもよさそう。

d, e

d1とd2はこんなのお絵かきでdxとdyという記法から常識で進む方向を決めようとして，だったら進む方向は r\cos (x)とr\sin(y)に決まってるで終わり。これ算数か数学か物理では？

eは下のコメントからして，こんなの今いるところから方向なんだから自分自身の現在の居場所以外ありえない。これはPythonの文法のselfの問題ともいえるけど，これも算数か数学か物理では？もちろん，コンピュータでお絵かきしたことあれば常識だろうけど。。。。

f

fはまあ関数の仕様読めますか？だけど，関数の意味を考えたらあてはまるものはほとんどない。なんとなくはまる。Pythonを何も知らない私は，二変数なのになんで一個なんだと思ってしまうが，まあクラス内のメソッド定義（関数というのか？わからん）のselfは書くけど呼ぶときは省略というPythonの文法的お作法でもたぶんあるんでしょう，後のハッシュのとこ考えてもこれしかうまる選択肢はないしで埋まる。

最後のスタックの部分(g,h,i)

私の能力では，何書いてるかがさっぱりとわからない。わからないけど，この問題は出力をつけてくれるという親切なヒント付き。というか，そうしないと基本の範囲の難易度ではないということでしょう。

まず，出力の最後の要素を眺めていると，２つ目の要素がある条件を満たしたときに消えている。ということは，iは末尾の要素の消去と考えるのが自然。スタックなんだから，後から積んだ要素が先に消えないとおかしい。また，ifのtrueのときにrestが1ずつ減っていっていて，出力もそんな感じで減っていってて，減り終わったところで末尾の要素が姿を消しているのでこれで良いでしょうと。

gの条件判定はrestが1になって0には行かずに消えるとなってる。となると，そこの判定条件は1かそれより大きいかになる。

あとは全体を見る。whileがopnoの条件で消えてるのにopnoがどこで変化されてるかわからない。だいたい，繰り返し命令かからなかったらopnoが永久に変化しないで終わりってこと？と思って良く見返したら末尾にopnp+=1がある。で，もし繰り返し命令が一回も呼ばれなければ命令が元の命令列の長さだけ呼ばれて終了ということになる。ということは，逆に言えば繰り返しが入ったときにはopnpを操作してあげないと，途中で終了という悲しい目に合う。よって，opnpを書き換える選択肢が正しい答え。

もちろん，画面上で解いたのもあって気付くまでものすごく時間かかったが・・・・

解き終えて

全般的にPythonを読んだ気は全くしない。座標平面状でのお絵かき常識と，全体の意図をなんとなくとらえるカンと誘導をうまく使える力を聞いている問題。

どうせこんなのは座標でやってるんだから，長さに方向でやってて，そんなの当然rcos(x)にrsin(y)とか，それはいわゆるプログラミングの知識やスキルか？と言われると？？？なのである。

応用のアルゴリズム問題がそんな傾向で，個人的には基本よりやりやすいと思っているけどそれに似ている感じ。

情報系以外の大学理系の人でもノー勉ていける選択肢が増えたのかな？というイメージ。あと，なんとなくかしこな大学生有利な感じな気もする。でも，こういうのがかしこな層は，そもそもこの資格試験に対して意義を見出してなさそうので意味ないような。いったいこの試験，どこに向かっているのだろうか。

あと，こういうのはいくら本で勉強していても，暗黙の数学っぽさを随所にからめられて，その素養がない人はどれだけ勉強してもだめですよみたいな。そういう問題は無限にパターンが作れるので，専門系の対策は難しそう。

c++を手元で実行した経験が少ないので出力形式に気が回らない・・・

ABC154のD問題をやっていてはまった。

coutで桁数によっては突然指数表記になるとか知らないし・・・

D問題を見て，スクリプト言語だと真面目解法は間に合わないかもしれない，と思って，c++で書き出す。紆余曲折の末，解説放送と同じ発想に行き着く。

途中，何回も挫折しながら書く。まあ，AtCoderの初心者マニュアルみながら書いてレベルだし，関数はラムダ式で代用で問題ないという初心者本に頼ってたりもする。

やっと一時間ぐらいかけて書いたところで提出。だいたいのケースで通っているのだけど，なぜか一部のケースで落ちてる。小数計算を割けずに書いてるので誤差累積？でもこの程度でそんなのあるわけないだろとなって，時間を終える。

やけくそで最後で同じ解法でスクリプト言語で出したらきっちりとTLE。ところが同じ言語で通ってるのが多数あったりしてショック。。。

あと，書きながらk個分のインデックス真面目に考えるのだるいし，キューに考えてる部分の要素を入れておいて自然に最初に入れたの取り出すとかが使える人ならすっきり書けるんだろうなとか思って書いてたら，解説放送そうしてて参考になったりとか。

しかし，この問題できないと茶色すらでないという昨今の情勢は厳しすぎのような。。。問題文が読めてifとforがわかれば茶色という世界を信じてたので，まあたいして勉強せずに茶色にしておいてから，後からがんばって緑にしますかと思ってたあてがとことん外れてる。

せめてもの救いは，c++のさわりのさわりの部分は思ったより時間かけずに理解できたことだけど。

液晶追加で買った（32インチ）

家に帰って作業するときに，PCのディスプレイをみていると目がちらついてくるようになった。

目がちらつく対策でディスプレイを買うのだから，EIZO一択である。

買い足す前も，EIZOの27インチのWQHDだけど，それでも文字を拡大しないと見えにくくなってきた。Windowsのフォントレンダリングが私に会っていないのか私の目が悪くなり続けてるのかのどっちかはわからないけど。しかし，拡大をしてから見ると27インチだと情報量が少なくなりすぎてどうしようもない。

近年はiPadでごろ寝でブラウズが中心だから，PCのディスプレイは書くときに眺めるものだった。書く場合は，編集のときの文字の大きさやフォントはわりと自分で選べるので，文字が見えにくいという問題はあまり感じなかった。しかし，読む場合はなかなかそうはいかない。

ここのところ疲労が抜けない要因やPCに向かえない原因をずっと考えていて，それでたどりついたのが，ごろ寝のときの姿勢がたぶん相当悪くて，疲労を蓄積させている可能性。これをやめることを真剣に考えようというのがそもそもの始まりである。

ディスプレイから極力離れることが一番良いのだけど，次善の策としてPCディプレイ以外で画面を見る時間を極力減らす，ということでやってみうかといった感じ。お金は飛んでいくけどね。。。。

ディスプレイが来て一週間だけどAbemaの動画を27インチで見ながら右のPCで作業できるようになって幸福度は上がったがどうなることやら・・・・

今年買ったもの(2019)

１年の振り返りを書きたいが何も思いつかない。とりあえず今年買ったものをだらだらと列挙してみることにした。

  • Asusのmini PC x2(i5, i7)
  • 液晶ディスプレイ（4枚）
  • 食洗器
  • ホットクック
  • ヘルシオ

商品名でひっかかると嫌なのでぼかしてるのがいくつか。

Asusのmini PC

6月頃になぜか変な価格の動きをしていた（異常に価格が下がっていた）ので，思い切って2台買った。i7が乗っているのを1台・i5が乗っているものを1台。

このPC・mini PCなんだけど，35WのCPUが乗っているというのが最大の素晴らしい点。普段使いでは完璧。m.2 SSDの換装が難しいことだけが欠点かな。ノートPCはCPUが非力なのかファンが回りまくるのが頭にきてたので。

このPC・Type Cの端子もついているも良い。手持ちのType C対応ディスプレイに対してType Cをつないで，ディスプレイ側にキーボードとマウスをつないでおくと，ノートPCとこのPCでディスプレイ・マウスを共用するのに便利。できればPC側からも映像信号をType-Cで送れるようになってくれると良いんだけどな。。。後Type-Cがディスプレイ側に2系統付くようになってくれる未来とか来たら最高なんたけどね。。。。

微妙な欠点としては，ディスプレイが4Kのマルチディスプレイになってからは悲鳴を上げることが多くなったことぐらい（これは私の使い方が悪い）。

DellのType C付23インチ（2枚)

とにかく普通に使う分には優秀の一言につきるディスプレイ。セールで2万前半で買ったような気がする。

デイジーチェーンでマルチディスプレイがいけるのもありがたい。

PC-Dell(sub)-Eizo(main)

と使うのが，普通の人にとっては良い構成だと思う。今年前半を乗り切れたのはひとえにこのディスプレイのおかげにつきる。ただし，4Kの世界を知ってしまった今，この構成ですらいらっときてしまう自分がいる。。。たまに23インチFHD使うとストレスが。。。

mini PCのところにも書いたけど，type-Cでつなで，ディスプレイ側にキーボードとマウスを置けるのは本当に大きい。Type-B - Type-Aでも同じことはできるが，Type-Aは指すのが面倒なので嫌なんですよ。とにかく。

4Kディスプレイ（27インチ1枚・32インチ1枚）

このブログでも取り上げた。

最初からケチらず32インチを買っておけば良かったの一言につきる。

マルチディスプレイの解像度は合わせておくにつきる。ほんと。

食洗器

一人暮らしのときにこれ買っておけばたぶん落ちこぼれずに済んだんだろうな・・・というぐらい素晴らしい機械。

自炊しなくてもあると良い。とにかく，コップと皿を贅沢に使えるというのは素晴らしい。

コップを洗うのが面倒で水をボトルからそのまま飲むとか，コップ洗うのが面倒でボトルから水を飲まないといけないけど2lボトルが重いので飲むまでの決断するまで時間がかかるとか，コップ洗いたくないから紅茶やコーヒー淹れるまでのふんぎりがつかずにだらたらするとか，して溶けた時間がこれまでの人生でどれだけあったことか。

皿洗いたくないからあっためずに容器のまま食べるとか，そういう食べ方してるとついつい食べ過ぎになりがちになるとかそういうのも防げるわけですよ。これ。

まあ，これ私がありえないレベルでダメ人間だから素晴らしい機械だと感じてる可能性もあるが。

ホットクック

今年の前半はこれで生命をつないだといっても過言ではない。

  • はかり・ 包丁・まな板がおけるスペース
  • 作ったものを展開するスペースや容器

がそろっていれば使いやすいマシンです。自炊するならあたりまえだろ？と言いたいがこれができれば苦労しない。ヘルシオを入れて以来，スペースが狭まった極度に使いにくくなった。

とりあえずポトフで適当に野菜炊いておいて野菜補給を一品分作っておく，という使い方で前半をしのいだ。シチューも良く作った。

最近は豚汁専用マシンと化している。

ヘルシオ

ホットクックよりさらに簡単なマシンでびびった。

最初はソフト蒸し目的で買ったが，そんな面倒なものは使うことはなかった・・・

取っ手なしフライパンを使う，というのがわかってから使えるようになったマシンともいえる。

肉を切って野菜をきって入れてまかせて焼きするという使い方。

ヘルシオもホットクックもこれで全部を賄うのはつらいが，とりあえずこれで何品か作っておけば野菜が補給できてかつ買ってくる総菜が減って良しという考えの自炊。

フォルダの結合のヘルパークエリを理解にかかることにした（１）

今年に入って，PowerQueryでフォルダ内部を結合しまくってる。

1つのシートの中に4つぐらいのフォルダを結合したものが別々に入ってくると，うっとおしくて仕方がない。特にこの補助クエリというやつのせいでクエリがかさんで仕方がない。

f:id:baruku07:20191215144700p:plain

フォルダを結合するときは相対パスを使う関係で，クエリ中の絶対パスを消しにかかるのだが，この書き換えをするときに元クエリだけでなく補助クエリまも書き換えが必要である（しかもそれに気付くのに相当かかった）。1個ならいいけど，4つあると2*4=8である。さらに，この補助クエリのせいでクエリのコピーで似た処理を複製することもままならない。

ということで，フォルダの結合のクエリをまじめに理解することにした。

まずヘルパークエリ以外のクエリはこんな感じである。

f:id:baruku07:20191215145346p:plain

ヘルパークエリが絡んでるのは囲んだ２か所である。キャプチャのソース全体。

let
    ソース = Folder.Files("（フォルダの絶対パスが入ってる）"),
    #"フィルター選択された非表示の File1" = Table.SelectRows(ソース, each [Attributes]?[Hidden]? <> true),
    カスタム関数の呼び出し1 = Table.AddColumn(#"フィルター選択された非表示の File1", "ファイルの変換", each ファイルの変換([Content])),
    #"名前が変更された列 1" = Table.RenameColumns(カスタム関数の呼び出し1, {"Name", "Source.Name"}),
    削除された他の列1 = Table.SelectColumns(#"名前が変更された列 1", {"Source.Name", "ファイルの変換"}),
    展開されたテーブル列1 = Table.ExpandTableColumn(削除された他の列1, "ファイルの変換", Table.ColumnNames(ファイルの変換(#"サンプル ファイル"))),
    変更された型 = Table.TransformColumnTypes(展開されたテーブル列1,{{"Source.Name", type text}, {"a", Int64.Type}, {"b", Int64.Type}, {"c", Int64.Type}, {"d", Int64.Type}, {"e", Int64.Type}, {"f", Int64.Type}, {"g", Int64.Type}, {"h", Int64.Type}})
in
    変更された型

結局は

  1. ファイルの変換([Content]))　
  2. #"サンプル ファイル"

の2つがヘルパークエリーに絡んでいることがわかった。

結論を先にまとめとくと，

  1. ファイルの変換([Content]))
    各行のテーブルの実態を得るために使っている。Table.AddColumnの各行にこの関数を適用して，ほしいテーブルの実際を各行に対してくっつけていくために使っている。
  2. #"サンプル ファイル"
    1.でくっつけたテーブルの実態をTable.ExpandTableColumnで展開するときに，引数として展開したい列を指定することが必要になる。それを得るために使っている。

ということがわかった。以下，１つずつ見ていく。

1. ファイルの変換

関数ファイルの変換の実態は次のようになっている。

let
    ソース = (パラメーター1) => let
        ソース = Excel.Workbook(パラメーター1, null, true),
        テーブル1_Table = ソース{[Item="テーブル1",Kind="Table"]}[Data]
    in
        テーブル1_Table
in
    ソース

1行目はExcel.Workbookにパラメーターを渡している。元のクエリの関数呼び出しを見ると，これはファイルのContentの行，すなわちファイルのバイナリを渡していることがわかる。

Folder.Files(絶対パス)で呼び出したテーブルの実態はこんな感じである。

f:id:baruku07:20191215150419p:plain

Excel.Workbookはバイナリを渡すと（ファイル名でない），その中身がExcelだった場合は，全部のシート・テーブル・範囲など使えそうなもの一覧で返してくれる関数である。レコードが返ると書いてあるがテーブルが返ってくるようである（見た目や後のアクセスの記法から推察して）

f:id:baruku07:20191215150938p:plain

PQを使い始めた最初，セルの中にバイナリの実態があるという考え方になじめずに戸惑ったのだがそういうものらしい。

で，そこから

ソース{[Item="テーブル1",Kind="Table"]}[Data]

として，得られたテーブルの中から指定したテーブル名と一致する（この場合はテーブル名「テーブル1」のものを引っ張ってきた）行を取り出して（{[Item="テーブル1",Kind="Table"]}），"[Data]"で実態を取り出すということになっている。

すなわちこの関数はExcelファイルの実態を与えて，指定したテーブルの中身を返す関数となっている。ただし，中身の指定は生の値で書かれていることに注意である。

この関数の呼ばれ方

ここで定義した関数はこんな感じで呼ばれている。

    カスタム関数の呼び出し1 = Table.AddColumn(#"フィルター選択された非表示の File1", "ファイルの変換", each ファイルの変換([Content])),

要は，Folder.Files()で読み込んだテーブルの各行に対して，ファイルの実態を渡してテーブルを返して，それを一列くっつけるということをやっているのである。関数適用後のテーブルを見ればこれはわかる。

f:id:baruku07:20191215151753p:plain

2.#"サンプル ファイル"

各ファイルに対して中身くっつければそれでほぼ目的は達成のはずである。なぜわざわざ特定のファイルを持ち出してるのかがわからない。

このファイルを呼ばれている部分を見てみる。

   展開されたテーブル列1 = Table.ExpandTableColumn(削除された他の列1, "ファイルの変換", Table.ColumnNames(ファイルの変換(#"サンプル ファイル"))),

Table.ExpandTableColumnなんで，どうやら中身を展開していることはわかる。その関数の引数に" Table.ColumnNames(ファイルの変換(#"サンプル ファイル")"がある，ということは自然に考えて展開する列名を取得していることがわかる。リファレンスをみても手動で展開してみてもそれで間違いなさそうである。

しかし，なんで全部の列名を展開するだけなのにわざわざ列名を取得する必要があるのか。よくわからないけど，これはそういうものらしい。全部を一気に展開するというのがみつからない（そんなのはないとまで書かれてるのもみかけた。ここは真偽はまだ確かめてない）。

プログラミング的思考について周囲を見てて思うこと（１）

（以下は全て何の根拠もない私見。言いたいことを正しさ関係なく自由に主張している。いちおう裏にソースとかないこともないけど面倒なので略。推敲もあまりしてない。文字にするとなんか正しいこと言わなければならないとか，勝手に信じ込む人がいたりする界隈なので最初に注意。）

小学校プログラミングはプログラミング的思考と言って入れは全てが許される感が出ている。とりあえず（１）にしてみただけで、（２）以降があるかはわからない。言いたいことをざっと書いてるのでツイートして並べてるのと論理構成のレベルは大差ない。

プログラミング的思考については、半径3m以内でおおまかに２つの問題が観察されていて

  1. プログラミング的思考以外に文科か言ってる重要ポイントを全部落としてる
  2. プログラミング的思考そのものを誤解している

というのがある。基本的にこれらを言葉で説得して解くのはだめだと思ってて、まずプログラミング体験して！って言うようにしてる。

だいたい、お上で議論するには言葉が必要で仕方がなく言葉になっている、それも本質を切り取っているか怪しい言葉なんだから、そんなものをはいそうですかと素人がいきなり信じて良いわけがない。体を生まれてから１回も動かしたことない人が（プログラミングは世の多くとここが違うのがポイント）スポーツの極意を言葉だけで議論してたら、まず体動かせって思うでしょ？

制御構造 = プログラミング的思考と思う人たち

プログラミング的思考に戻る。わけのわからない人たちは、順次・反復・分岐がプログラミング的思考だとして、あろうことか低学年からそういうのを計画的にやっていくことが大事だといってる人々がいる。（私の周りにはいないが）

しかし、指導要領・解説・手引きを何度読んでも、小学校で順次・反復・分岐の概念をきっちり習得させろとは読めない。

手引きを熟読した限りでは、今回小学校に求められているレベルは、何かのやりたいことをコンピュータにやらせるために、人間感覚でなくちょっとだけコンピュータ感覚に合わせて手順を明示化してみて、実際にコンピュータで動かしてみてうまくいったりうまくいかなかったりしたプロセスやプロセスから得る学びがメインだと読める。そして、余裕があればそこで得た知見を少しふりかえったり抽象化して日常のいろんなとこで意識してみましょうね、で十分である。その範囲内において、制御構造の学習（特にこれを言語化して抽象化して学習すること）は必ずしも必要とされていない。

もちろん、コンピュータに何かやらせたいという意図があったときに、それを実現したいとなったときに、制御構造必要だよね、となったときに制御構造が登場するのが自然。それも最初は制御構造の用語は必要ない。問題にあわせて「こういうときとこういうときでわけて考えないといけないよね」「くりかえさないとね」といえば十分。用語とか概念は、そういう体験が積み重なってきたときに、で、そういうの良く出てきてるよね、実は名前がついてて・・・と体験を抽象化する形で制御構造の話を出したければ出せば済むだけの話である。

多角形の例を考えてみればよい。ねらいを達成するためにはループは必須ではない。分岐も登場しない。

小学校でフローチャートを万能としてる人々はね・・・

だいたい、フローチャートはできの悪い疑似言語として使われていることもあるぐらいである。フローチャートが素晴らしいのであれば、世のプロクラミング言語は全て フローチャートに置き換えられているはずである。そうなっていないということは、フローチャートが微妙なものだからということだと思わない？そういう人たちは技術の解説でUMLが出てきた話なんかもしらない。

Scratchのほうがフローチャートよりわかりやすいと思わない？だいたいScratch使ってる人がみんなフローチャート使ってる？使ってないでしょ。Scratch使いこなしてもの作ってる人がプロクラミング的思考できてないと思う？

良く読めば、要はやりたいことを機械に落とし込むのがプログラミングで、そのために必要な思考がプログラミング的思考ということは手引きからちゃんと読める。それに照らし合わせると、Scratchでもの作ってる人たちは、フローチャートは描けないけどプロクラミング的思考はできてますよ。だって、その思考なかったらコンピュータ動いてくれいし。そんなScratchでちゃんと作れてる人たちに、変なペーパーテストと評価基準でプログラミング的思考ができてる人に、あなたはプログラミング的思考ができてません、とか評価するの（プログラミング的思考そのものは本来は評価する必要ないが、各教科の評価規準の作り方がへたくそで実質的にそうなった場合。）、おかしさにもほどがある。

だいたい、まともな人が書いてることにフローチャートの話はほとんどでてこない。だいたいフローチャートの話ばっかしてるのは、ろくにプログラミングもしたことはないけどプログラミング教育と言ってる人々である。しかし、素人がそんな著者の属性判断してそれがまともかどうか判断できるかわからないから、それを信じる人が増える。有害極まりない。

プログラミング的思考の説明に「論理的」という言葉を充てたことが個人的には大失敗だと思ってて、一般人はそれにひきずられてると思ってる。

順次・反復・分岐そのものにフォーカスを充てるのは、アルゴリズムにつなげるという主張もある。しかし、それは高校段階の話である。中・高の内容そのものが理解もできてない小学校の人々が考えた、自分なりのつながるなんて有害無益になる可能性がある。

もちろん、情報の科学手理解の教育の一部として、アルゴリズムのような情報科学入門みたいなことをやることはありえる。情報の科学的理解は立派に情報活用能力の一部である。でも、ITあやしい小学校教員がそんな教育やってる余裕あるの？というかコンピュータ関連、それよりもっと教育してきてほしいことあるし。文字操作とファイル操作をできずに中・高に送り出してる人たちどんなにいる？プログラミング的思考だけじゃなくて、それちゃんと小学校で終わらせとけって指導要領や指導要領解説で書かれてますが？そんなにお上のこと持ち出してがーがーいうなら、都合の良いとこだけ読むなと言いたい。