PPAP（ペンパイナッポーアッポーペン）の代数的構造(2)
の続きです。
左右の手
facebookで指摘を受けたのですが、歌詞の順番と右手と左手の順番は違うようです。歌詞に左右の手のどちらかを書いてみます。
PPAP
I have a pen (右手)
I have an apple (左手)
ah!
Apple pen!
I have a pen (左手)
I have a pineapple (右手)
ah!
Pineapple pen!
Apple pen (右手)
Pineapple pen (左手)
ah!
Pen-Pineapple-Apple-Pen!
Pen-Pineapple-Apple-Pen!
この左右の手を意識すると、前回とは違う式になります。右手は向かって左側、左手は向かって右側なので、演算の満たすべき条件を書いてみると、
ah!("✏", "🍎") = "🍎✏"
ah!("🍍", "✏") = "🍍✏" ←ここが変わる
ah!("🍎✏", "🍍✏") = "✏🍍🍎✏"
こんな風になります。なんとも一貫性がなくて困りますね。。。
ロングバージョン
2016/10/27 にロングバージョンというものが公開されていたようです。
ロングバージョンの中には今までにない演算結果も出てきています。
ah!("✏", "✏") = "✏✏"
（ペンとペンでロングペンだそうです）
ah!("🍍", "🍎") = "🍎🍍"
（アッポーとパイナッポーでアッポーパイナッポー）
ah!("✏✏", "🍎🍍") = "✏🍍🍎✏"
（ロングペンとアッポーパイナッポーでペンパイナッポーアッポーペン）
ここでロングペンは"✏✏"と表しています。ペンペンと呼びそうなものですが、呼び方だけはロングペンで実態はペンペンということにしておきます。
そしてもっと重要なことは、ペンがついていないときはアッポーが先の"🍎🍍"の順番だったのに、ペンがつくとアッポーがパイナッポーの後ろにいって"✏🍍🍎✏"になることです。どういうルールなのでしょう。もう少し考察してから答えを出します。
PPAP（ペンパイナッポーアッポーペン）の代数的構造
このエントリーではPPAP（ペンパイナッポーアッポーペン）の代数的な構造を明らかにする。
✏：ペン
🍎：アッポー
🍍：パイナッポー
として、これらのアイコンの有限列の集合をSとする。Sの元はわかりやすさのためにダブルクォーテーションで囲っておく。Sには例えば下記の様な元がある。
S ∋ "", "✏", "🍎", "🍍", "🍎✏", "🍍✏", "✏🍍🍎✏"
Sに演算 ah! : S✕S→S を定義する。
∀a, b∈S
ah!(a,b) := bを逆向きにした列にaをつなげた列
例えば以下のようになる。
ah!("✏", "🍎") = "🍎✏"
ah!("✏", "🍍") = "🍍✏"
ah!("🍎✏", "🍍✏") = "✏🍍🍎✏"
この演算でPPAPの歌詞における条件を満たしていることがわかる。
Sはこの演算でマグマである。単位元として""∈Sをもつ。結合則は満たさず、逆元も持たない。
したがって、PPAPは単位的マグマである。
ヒートマップ比べ（データ：プリキュア視聴率、ツール：PowerBI）
久しぶりのヒートマップ比べシリーズです。今回はちょっと触ってみたPowerBIです。PowerBIは初めて触って1時間程度なので間違いがあるかもしれません。
さて、PowerBIでヒートマップを書いてみるか、と思ったけど、そういう視覚化はありませんでした。でもPower BI custom visualsというところでカスタムビジュアルというのが公開されていたので、Table Heatmapというカスタムビジュアルをインポートして試してみました。
PowerBIというよりTable Heatmapの制約なのでしょうけど、TableauやRのときのようなRDBっぽいデータを入れるとヒートマップにできなかったので、Excelのときのような2次元の表のようなCSVファイルを作ってPowerBIに入れました。
あと、Excelで編集してShift-JISになっていたCSVファイルを入れると文字化けしたのでUTF-8に変更しました。
できた。一応。
やはりカスタムビジュアルの使いやすさの話なんだろうけど、縦横非が固定されているようで縦をもっと伸ばしたいのにできませんでした。色も変えられなさそう。
縦に並んだプリキュアシリーズの順番を変更できるようなUIになっているのですが、いまいち反映しなかったり。。。
PowerBIにとってはヒートマップは苦手分野だったということですかね。
それにしてもカスタムビジュアルというプラグイン形式のもので見た目を変えることができるというのは拡張性があっていいですね。
こういうのとか。ちなみに今(?)はPower MapじゃなくてGlobeMapという名前になっているようです。
書評：やり抜く力
やり抜く力――人生のあらゆる成功を決める「究極の能力」を身につける
- 作者: アンジェラ・ダックワース,神崎朗子
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2016/09/09
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
Amazonのアフィリエイトのお試しがしたくて、この前読んだ本を貼ってみた。
いい本でした。感想も書いておきます。
- 「才能」じゃなくて「やり抜く力」ですよ、という本です。
- 米国陸軍士官学校の最初の基礎訓練、通称「ビースト」で5人に1人はやめてしまう。やめてしまう人は成績とは関係がなかった。「やり抜く力」が強い人が残った。
- ↑「やり抜く力」が強い人がやり抜いた、って当たり前みたいだけど、もうちょっとちゃんと書いてあります。
- ↑成績とは関係なかった、というように書いてあるけど、それは統計学的な誤解かも。。。成績優秀者だけを集めたから成績との相関が低くなるだけかも。
- やり抜きゃいいってもんでもないでしょ、と最初の方を読んでて思いました。途中でそういう点もフォローされています。いろいろ試して、合うものが見つかったらそれをやり抜こう、と。
- なんか、ところどころにある図解がいまいちわかりにくい。なぜなんでしょうね。。。
- 「意図的な練習」が重要
- 「子どもはおとなの言うことを聞くのは得意じゃないが、まねをするのは抜群にうまい」
才能✕努力＝スキル
— Akiya Mizukoshi (@Akiyah) 2016年10月10日
スキル✕努力＝達成
GRITやり抜く力 より pic.twitter.com/hCH5JFaD30
↑努力と才能とスキルの図解がわかりにくかったから自分なりに書き直した。
「タイトルのみ入れます。サブタイトルは入れません」？ pic.twitter.com/zGrMVhbH87
— Akiya Mizukoshi (@Akiyah) 2016年10月5日
↑表紙の画像につけた文字がおかしいのかな。
スクラムの概要の画像をいらすとやで作りなおしてみた
スクラムのバックログの日本語訳を聞いたら色々意見が集まった
スクラムのバックログは日本語にするならなんなのだろう。作業とか機能とかじゃないと思う。価値はカタい気がしている。ひとまず「やりたいこと」にしておく。
— Akiya Mizukoshi (@Akiyah) 2016年10月6日
こういうことを書いたらTwitterから自動的に転送する設定にしているFacebookで色々意見をもらったので軽くまとめておきます。
【日本語訳の案】
- やりたいこと
- 実現したいこと
- 残
- 仕事
- 予定残
- リスト
日本語訳になってないじゃん、とかありますが、バックログの言い換えの言葉として理解してください。考えてくれた人に感謝して名前を書いておきたかったのですが、なんか私の責任放棄みたいな気もしたので、名前は書かない方針でいきます。
もともと、バックログという言葉を使いたくなかったのは、バックログというサービスがあって仕事で使っているからなんですよね。
というわけで、意見をもらってから言うのもなんですが、私の基準は「まぎらわしくないか」がまず一つ目です。何か他のことを連想しちゃうかどうかですね。
もう一つは、facebookの議論中に出てきたのですが、「全部やるという印象を与えるかどうか」という点です。全部やるっていうのは誤解なんですよね。バックログを作ってプロッジェクトが始まって、最後に成功だったね！という場合でもバックログって残っているものなんですよね。結果やらないこと、というのも当たり前にあるのです。
というわけで並べてみました。
。。。
うーん、並べてみたけど、自信を持ってこうだと言いにくい。。。言葉の印象っていうものがあいまいでふわふわしているのに、ロジカルに並べようとするとなかなか難しいのですね。
まだ自分の中でもこれでいこうというのが決まってないです。ご意見ある方は教えてください。
ちなみに、ここで私が書いたバックログとは、プロダクトバックログのことです。プロダクトバックログとスプリントバックログがあって区別されているのです。
インターネットにこどもの写真を載せる時のパターンの整理と質問と要望
ちょっと気になったことがあったので、インターネットにこどもの写真を載せる時のパターンを整理してみようと思いました。
画像はいらすとやさんからいただいて、GIMPとCSS*1で加工して使っています。
【こどもの写真の公開のしかたの分類】
| パターン | 例 |
|---|---|
|
1) 家族に送る |
|
|
2) 友達とかクラスの人にのみ公開 |
|
|
3) だれでも見られる |
【（こどもの）写真に写っているものの分類】
| パターン | イメージ |
|---|---|
|
a) 風景 人を写さない 場所とか雰囲気を写すのみ |
 |
|
b) かおなし 顔を写さない （そういう風に写真を撮る） |
 |
|
c) スタンプ 顔に目線やスタンプをして隠す |
 |
|
d) 他人スタンプ 一部の子（自分の子）以外の顔に 目線やスタンプをして隠す |
 |
|
e) そのまま 顔が写っている |
 |
（えいやと分類しだだけなので、もっと細かくしたりとか、もっと大雑把にしたりとか、分類の種類を増やしたりとかしたほうが良い分類になるかもしれません。）
私の場合だと、 子供の写真をスマホでとって奥さんに facebook messenger で送るときは 1-e です。facebookに友達限定で載せるときはあんまり明確になってなくて、後ろからとったり手元だけをとったりして 2-b にしたり、場合によっては顔が写っていて 2-e になっていたり。twitterに載せるときは顔が写っていないようにして 3-a か 3-b です。スタンプとか目線とかは面倒だし、なんとなく好みじゃないのでやりません。加工をするとしたらトリミングで切り取るか、縮小とかぼかしてはっきり見えなくするようなものですね。
表にするとこうなります。
| a) 風景 | b) かおなし | c) スタンプ | d) 他人スタンプ | e) そのまま | |
|---|---|---|---|---|---|
| 1) 家族 | ○ | ○ | ○ | ||
| 2) 友達 | ○ | ○ | △ | ||
| 3) だれでも | ○ | ○ |
facebookの知り合いの写真を見ててもこういう方針はいろいろ違うようで、そのまま載せている人もいれば、他人のこどもだけスタンプで顔を隠している人もいれば、自分のこどもだけが写っている場合でも顔にスタンプをつけている人もいます。
で、なんでこういう整理をしたくなったかというと、保育園がとった写真を保育園のfacebookページやwebページに載せていたりするんですよ。その時に、上の基準では 3) だれでも で e) そのまま で公開していたりするんですよね。もちろん保育園から親へ許可を取っています。でもなんか親側の基準とずれているというか、親側のそれぞれが選択している基準のうちで保育園の選択がゆるい方によっているのが気になるんですよね。
私を含めて親側もリスクとかメリットを明確にして基準を選択しているのではなくて、なんとなくこれくらいかなという基準を自分で作っているだけなんですよね。たぶん。で、保育園から同意を求められて、まあ保育園に任せればいいかと思って同意している、と。一方で保育園側は同意が得られたからすべてオーケーということで、ゆるい基準を採用してしまっている、と。
そもそも、インターネットに写真を載せることのリスクってなんなんだろう。こういう議論を探すと一度でも写真を公開してしまったらアウトみたいな意見もありますが、だとしたらもう取り返せないわけで、だったらぎゃくに面倒なことはしたくないな、なんて思ったりもします。
【質問】
インターネットにこどもの写真を載せることのリスクってなに？
【要望】
保育園（or区、市、都、県）でこどもの写真をインターネットに載せることのリスクを明確にして、そのうえで保育園の採用する基準を示してほしい。その上で親に同意を得て、どうしても従えない人のこどもは写真に取らないとか、そういう風になってほしい。
このブログエントリーではリスクによったことを書いているけど、自分のこどもの写真を見せびらかしたいという気持ちはあるし、保育園での様子を写真で見せてもらえるのもうれしいので、できるだけリスクが少ない形で、公開して欲しいと思っています。
あと、保育園のことばかり書いているけど小学校も同様に思っています。小学校のほうが現状では少し厳し目にこどもの写真を扱っているようには感じています。
