忍んでいる肉球の足跡

プログラムに関連することを雑多に扱います

自分の壁の振り返り

面白い昼食だった。

壁

今の私の成長はどんな壁に当たって止まっているのかを友人に聞かれて答えることで、整理できた。

  • 人望・コミュ力の壁
    • （30分で専門家からアドバイスをもらえる人は、10時間かけて自力で答えにたどり着く人よりも能力が高くなりやすい）
  • 知識欲による経験値の壁
    • （８時間仕事で勉強する人よりも、１５時間それを楽しんでいる人が強い）
  • 地力の足りなさによる壁
    • （セキュリティーなど地力を求められる分野に対しての弱さ）

私自身はそれなりに基礎の能力（やプログラムセンス）があると思っている※1。
しかし、経験値が圧倒的に足りてない。
その経験値を補強をするための熱意はくすぶってる。

スキル振り返り

プログラマとしての技術分野を大別すると下記の４つ。
で、私の経験値はインフラサイドにとても偏っている。
この辺も少し見直したほうがいいだろうな。

  • UI/UXデザイン
  • フロントエンド
  • インフラ
  • ネイティブアプリ
煽り煽られ

また、畑の違うその友人から「
基礎の能力（やプログラムセンス）に自信があると言っているけど、
飄々と語るから、お前自身の本当にスペックがあるのかわからない。
だから、そういうサイトのスコアを出してみろよと言われた。（意訳）」
あとは企業のプログラムテストを受けてみてよ みたいな※２。

そういえば最近は競プロっぽいのをやってねぇな。

……スコアを上澄みと比べられてsageられて、見捨てられるのは不安だ。
とても不安。

…………でも、まあ。
たまにはそういうことをしてもいいかな。
という気分になったので時間が取れればするかも。

その他持論：

プログラマ基礎力の４つの壁。
これがわからないと辛くなるやつ※３。

  • 関数化
  • クラス
  • ポインタ操作
  • 再帰関数

※１ 自信過剰??? わかってる、大丈夫大丈夫。どーせフルボッコにされるやつ
※２ やらなくてもできないとわかる企業名を出されそうなのでスルーで
※３ 何が言いたいかって言うと「これができてる俺SUGEEE」（）

chrome(v66以降)でseleniumテストが動画の自動再生でハングする

条件

  • chrome(v66以上)
  • seleniumを利用した自動テストを行っている
  • 自動再生のEventを引っ掛けようとしている

解決法

  • --autoplay-policy=no-user-gesture-requiredを利用する。
具体的には
var webdriver = require('selenium-webdriver');
var chromeCapabilities = webdriver.Capabilities.chrome();
var chromeOptions = {
'args': ['--autoplay-policy=no-user-gesture-required']
};
chromeCapabilities.set('chromeOptions', chromeOptions);
var driver = new webdriver.Builder().withCapabilities(chromeCapabilities).build();

概要

かねてから噂されていたらしい、Chromeの自動再生拒否のバージョンがついにやってきた。 （実装はちょっと前からされてたみたい、デフォルトにされたのが今回のアプデ）

seleniumでの設定方法でもつまずいたが、ブラウザ経由で自動再生のフラグを変更したいなら chrome://flags/#autoplay-policyで操作する。

一応、以下の三種類が用意されている。

  • No user gesture is required.
  • User gesture is required for cross-origin iframes.
  • Document user activation is required.

一ユーザーとしてはありがたい限りの機能だが、テストが落とされるのは困ったので共有したい。

ちなみに、IMEとやらでサイトごとに自動再生を許可するドメインを確定する仕組みがあるみたい。 ただ、自分のchrome://media-engagementを見ても全部、拒否られてたのでよくわかんない。

f:id:nukisashineko:20180423225002p:plain

自動再生拒否を回避してどうしても自動再生で動画を流したい下の公式行けばいいと思います。 developers.google.com

Qiitaに日本語で書いてあるのもあるみたい。 qiita.com

休日が開けたら、テストがtimeoutしてて月曜日から憂鬱な気分に振り回される人が少なくなるように祈ります。

参考：

seabornでhueを指定しながら、重ねてプロットしようとしたらハマった話

注意

【matplotlib v2.1.1以前】の時のエラーです。
【matplotlib v2.1.2以降】の方はあまり関係ないかもしれません。

経緯

雑にpythonのseabornを使ってグラフを書いていたら、
同じカテゴリカルデータを使って書いた２つのグラフを重ねて表示したくなった。

sns.pointplot(x="x", y="fitting_y", hue="y_limit", data=result, markers="")
sns.pointplot(x="x", y="y", hue="y_limit", data=result, join=False)

と書いたら、以下のようなエラーが出てきて処理が止まった。

File "${HOME}/anaconda3/lib/python3.6/site-packages/matplotlib/legend.py", line 1344, in _in_handles
     if f_h.get_facecolor() != h.get_facecolor():
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

上記のエラーを修正しようとした。

経緯（図解）

こういう２つのグラフがある
これらを……

くっつける前

↓　こうしたい

くっつけた後

解決法（正攻法）

@skotaro さんに Qiitaにてコメントでコードを教えてもらったため、記述させていただきます。
groupbyを利用して描画した後、legendを利用して凡例を記述するのが正攻法です。

fig, ax = plt.subplots()
grouped = result.groupby('y_limit')
for key, gr in grouped:
    gr.plot('x', 'fitting_y', ax=ax)
    color = ax.lines[-1].get_color()
    gr.plot.scatter('x', 'y', marker='o', ax=ax, color=color)

ax.legend(ax.collections, list(grouped.groups.keys()), loc='upper left', bbox_to_anchor=(1,1))

解決法(邪道)

どうしてもseabornを利用して、プロットしたい人向け

ax = sns.pointplot(x="x", y="fitting_y", hue="y_limit", data=result, markers="")
ax.collections.clear() # 「今回の肝」 コレが無いとエラーで落ちる。
sns.pointplot(x="x", y="y", hue="y_limit", data=result, join=False, ax=ax)

hueを連続して使いたいなら、ax.collectionsに溜まる色付きラベルPathCollectionを末尾以外で随時削除するべし。

原因【matplotlib v2.1.1以前】

seabornで hueを指定した際、legend（凡例設定）が自動的に作成され、hueから自動生成されたPathCollection（色付きラベル） [※１] が凡例表示用にaxに保存される。 連続してplotする際に、二度目の関数でもhueが指定されている場合、やはりlegendを自動生成・追記しようとする。 hueからPathCollectionが自動生成されるが、これは保存済みの※１と同じもの である。 ここで 問題となるのが、axの凡例表示用PathCollectionの保存時に重複チェックがある こと。 凡例に同じ色を保存しようとすると AttributeError（属性エラー）系で落ちてしまう 重複が取り除かれる予定だった コレが今回エラーで落ちた原因だったようだ。 （実際のエラーは上記にも書いたようにValueError）

追記

本当の原因はValueError。 np.repeat([[True,True,True, False]],19,axis=0) のような値を取るf_h.get_facecolor() != h.get_facecolor()について any() or all() してせずにif文にぶち込んでいること。 要するにライブラリーのバージョン固有のバグでした。

解決法の説明【matplotlib v2.1.1以前】

コレを防ぐためには、 直前のseabornのplotでaxに保存されている 凡例表示用のPathCollectionと衝突を回避する必要がある 。 今回は同じカテゴリカル変数を利用した描画のため、PathCollectionの削除を選択した。 凡例表示用のPathCollectionは ax.collections (type:list) に保存されているため削除関数clearを利用する

ax.collections.clear()

clear後は、その直後のseabornの関数でhue（とpalette）を指定して、グラフを重ねようとした場合にエラー落ちしなくなるようだ。

全部コードを読んだわけじゃないので推測も混じってます。 何か見識あればコメントでお願いします。

【matplotlib v2.1.2以降】のお話(追記)

    ax = sns.pointplot(x="x", y="fitting_y", hue="y_limit", data=result, markers="")
    sns.pointplot(x="x", y="y", hue="y_limit", data=result, join=False)

と連続して記述してもエラー落ちはしなくなりました。 ごっそり重複チェックの部分のコードが消去されたためです(_in_handles関数)。 しかし、凡例は壊れますので、groupbyを利用した正攻法を利用したほうが良いでしょう。

※一応、ax.collection.clear()を挟むことで解決することができます。しかし、今後安定した動作であるかの保証は無いです。詳細はQiitaのコメント欄にて。

壊れる凡例の例

壊れる凡例の例

_in_handles関数が消去でなくエラー修正であったらならの妄想

ちなみにmatplotlib v2.1.1のlegend.py内にある_in_handles関数をおいてall()関数を利用してエラー部分を修正していたとしたら、PathCollectionの指定時にax.collections.clear()を使用せずとも、連続で書かれたseaborn.pointplotにて、壊れずに凡例の表示ができそうであった。

その他雑記(alpha値の扱いとか)

ax.collections[0].get_facecolor() != ax.collections[1].get_facecolor() が
np.repeat([[True,True,True, False]],19,axis=0) と
ほぼ等しくなっていた原因は、get_facecolor()関数とseaborn.pointplotの色の管理の方法に問題があった。 get_facecolor()ではalpha値まで管理されているが、seaborn.pointplot内の色の管理はseaborn.color_paletteで行われる。 そのため、palette=の指定を行った場合は、必ずalpha値が1に統一されてしまう。 どういうことかというと、内部でseaborn.color_paletteに変換されるが、seaborn.color_paletteはRGB変換処理によりalpha値の情報が削ぎ落とされてしまう。そのため、同じラベルに違う色を付けたところでalpha値の部分で常にTrueが出てしまう。 現在,seaborn.pointplotではalpha値を制御して描画する機能はついていないようだ。（たぶん）

ただしseaborn.regplotなどをみる限りalpha値を関数描画時にscatter_kws等の引数を用いて指定できるようになっているようだ。

seaborn.pointplotもそのうち機能がつくかも……しれないこともないかもしれない。

解決法の見つけ方

探し方が悪かったのかどこにも載ってなかったので、 pycharmでbreakpoint debugしながら、いじいじしてた。

ソースコード

詳細なソースコードは以下のgistのURLに置いておきますので気になった方は参照ください。 seabornでhueを使いながら、複数のグラフを重ねたかった

その他の解法とか？

  • hueを使わずgroup_byしてfor文で回して、legendを自作する（上記記載済み）
  • jupter-notebook（web brower）では、一部エラーが出てもそのまま描画処理をしてくれるため、実用途に足るなら利用する

250x250以下の動画をgoogle photosにuploadするために変換した話

モチベ

ガラケーの頃の動画ファイルを発掘してgoogle photosに突っ込んで置きたくなった。
ところが「アップロードできません」と弾かれてしまう。
これを直してuploadしたかった。

原因

google photosでは動画ファイルは以下の条件で弾かれてしまうようだ。

  • 250x250 未満の画素数
  • 1GBを超えるファイル

今回の動画ファイルは

  • 画素数が 320x240
  • ファイルサイズは問題ない

という極めて惜しいところで弾かれていたようだ。

スクリプトを書く必然性

320x240 → 640x480 の変換しただけだと、ファイルの作成日時が変わってしまい、
google photosに入れた後に手作業で撮影時間を合わせる必要があり、非常に面倒である。
またexiftoolやffprobe、mediainfoから動画内部の撮影日を覗くことができる。
撮影日はなぜか世界時(+00:00)で記憶されていたため、時差を合わせる変換が必要だった。

そのため、ffmpegで動画の撮影日時を保ったまま画素数を増やすスクリプトを書いた

コードと説明

  • ３行目でffprobeを利用して作成時間を取得している
  • ４行目で時差を含めた日本標準時時間に直す
  • ５行目でffmpegを利用した動画変換を行っている
    • metadataでcreation_timeを利用するのは、元の動画を処分した際でも撮影日がわかるようにするため。
  • ６行目で作成、更新時間を撮影日に直している。
    • この作業をすることでgoogle photosへアップロードした際に撮影日を認識してくれるようになる。

参考

Linuxコマンド集 - 【 touch 】 ファイルのタイム・スタンプを変更する：ITpro
Linuxコマンド集 - 【 date 】 日付や時刻を表示，設定する：ITpro

ffmpegでサイズやアスペクト比を指定 - opamp_sando's blog
html5 video - FFMPEG - Get creation and/or modification date - Stack Overflow
Insert Encoded & Taged Date • FFmpeg Support Forum

Google+/Google フォト ヘルプ フォーラム 大量にある動画の日時編集について

gmailのスターをinboxに移行する方法

記事のモチベ

「inbox使いやすいよー」って宣伝してたら、
「gmailのスターを使い込んでるから、
スター付きが検索でしか取り出せないinboxはちょっと……」
と言われたので、スター付き管理している人への布教記事を作ろうって決意。

対象者

  • スター付き管理している人。

  • inboxで過去のメールを作ったフォルダに入れたい人

こっちはinboxの新規受信トレイに過去メールが入れられなくて困っている人向け。
手順自体は同じ。

inboxの良さ

移行する前にinbox特有の良さを少しだけ紹介する
gmailと変わらないからいいやって言う前に機能を数日利用してみてください。
私はメールボックスのグチャグチャ感から解放されました。

  • メールの差出人がわかりやすくアイコン表示される
  • 添付ファイルや配送時間はカード表示され、ワンタッチで開ける
  • 今日、昨日、今週、今月、先月のメールをワンタッチでアーカイブ
  • 内部で複数のメールボックスにメール振り分けできる、ワンタッチ
  • 数日後まで必要のないメールをスヌーズ出来る。
  • 重要なメールはピンすれば、アーカイブに巻き込まれない

方法

文字による手順説明

  1. inboxで「新規受信トレイ」を作る
  2. gmailで「スター付き」を検索する
  3. 検索したメールを選択する
  4. 「ラベルを付ける」から「新規受信トレイ」のラベルを適応する

画像を踏まえた説明

inboxでの操作

まず「inbox」にアクセスする。
（まだ使ったことのない人はinboxを有効化してください）

そして、左側の「新規作成」をクリックします。
名前はなんでもいいですが、「is_starred」としておきます。

① 新規作成をクリック
② 「is_starred」と入力、保存

f:id:nukisashineko:20170923231510p:plain

そうすると何もはいっていない新しい受信トレイができあがります。

f:id:nukisashineko:20170923231520p:plain

inboxでは受信済みメールを選択して別の受信トレイに移動させることは出来ます。
ただし、「選択範囲：全て」がないので数が多くなると大変です。
そこでgmailから操作を行います。

gmailでの操作

gmail を開いてください。

内部的には「inboxの新しい受信ボックス」==「gmailのラベル」です。

ですから、 「スター付き」を検索してHitした全てに作成した「is_starred」のラベルをつければ完成です。

③ “is:starred"と検索
④ 「全て」を選択する

f:id:nukisashineko:20170923231530p:plain

⑤ ラベル「is_starred」を選択
⑥ 適用する

f:id:nukisashineko:20170923231540p:plain

inboxでの確認

先程作ったフォルダにスター付きが入っていることを確認して終了です。
お疲れ様でした。

f:id:nukisashineko:20170923231552p:plain

補足

過去のメールを全て作成した受信トレイに置く

① 新規作成をクリック
② 「new_email_inbox_name」と入力、保存
＊ 「フィルター条件」を作成する　
③ 上記の「フィルター条件」で検索
④ gmailで「全て」を選択する
⑤ ラベル「new_email_inbox_name」を選択
⑥ 適用する

上記手順を利用すると過去メールをさかのぼって振り分けることができます。

振り分け受信トレイの使い方

私が利用する「フィルター条件」の例も置いておきますね。

  • 学校から届くお知らせスパム
  • 楽天銀行のスパム
  • qiitaのお知らせメール
  • rescuetime, moneyforwardの日報、週報メール

などです。 用途としては、

  • スパム報告するほどでもないor諸事情で出来ない
  • たまに見る必要はあるけど定期的に飛んできて邪魔
  • 重要なメールと混ざらないでほしい
  • プロモーション以外のやつ

に主に利用しています。

注意点

手順①、②の部分はgmailでは操作できません
※ 「inboxの新しい受信ボックス」は「gmailのラベル」を作成するけど、
※ 「gmailのラベル」は「inboxの新しい受信ボックス」を作成しません

検証・掘り下げしたいなって思っていること

これなに？

なんか上手く時間を取れないので
現時点の興味の方向とやりたいと思っていることを羅列する。

就活中に、こういうの大事だと思うようになってきたから、ブツは何もできてないけど書いておく。
記事や知識が溜まりきるまで吐き出さないって言うスタイルをやめておきたい。 絵師じゃないけど、こういうことだよね。たぶん。

検証・掘り下げしたい事

  • sony の深層学習GUIソフトの吐き出しデータを他で（keras等）で利用できるかどうか

書きたい記事

  • 自身のBDDについての捉え方と「FizzBuzzを例にBDDとは？」を実演し、布教

優先度が低いやりたいこと

  • 一人用のSlackの中身を日誌としてEvernoteに吐き出すBotの作成
  • sonyの深層学習GUIソフトのチュートリアルを終える。
  • テンプレートCSSを利用した画面作りの練習

後で調べること

Kuinのドキュメントの感想

Kuinとは？

くいなちゃんが作成したプログラミング言語。

twitter.com

Kuinのダウンロードと紹介 - プログラミング言語「Kuin」 - Kuina-chan

曰く、”簡単で高速な実用プログラミング言語”
詳細は上記ページで読める。
近代のプログラミング手法の合理をどう設計に取り込んでいったのか。
それを「設計の理由」で読めるのでとてもわかり易いドキュメントで、
何を狙いにしているかがめちゃくちゃわかりやすかった。

Kuinのドキュメントを読もう！！

私がドキュメントを読む気になったのは、TLで流れてきたのとかなり手放しで褒められていたから気になったっていうのがある。 実際に読んでみると、初学者向けの言語として私も褒めたくなってしまった。

Kuinは「日本人のプログラミング初心者用の言語」として、とてもいい言語だと思う。 CやBASICのような旧来的な部分を取り除いて、近代的なプログラミングを学ぶことが出来る。 つまらない部分（下手なハマり方、環境構築、アルゴリズム・外部ライブラリ調べ等）を言語設計の方で、かなり潰しているのが伝わってくる。

逆算して

  • くいなちゃんが初心者がつまずくポイントをどう捉えているのか
  • 他の初心者言語と比べてどこが改良されているのか

等を考えていたから、文字起こししてみたのが今回の記事。

目次

Kuinのいいなって思った部分の紹介

Kuinの言語設計でいいな思った部分について深掘りしてく。
「設計の理由」を読めば、わかることばかりだけど前提としての補足とかを書く。

Kuinの言語設計の方針（の推測）

ドキュメントを読んでいて気づいたのは一貫していること。

  • 日本人のプログラミング初心者に混乱させない
    • テキストエディタでもコーディングできる短さを重視する
    • 近代的プログラミングの基礎を学べるように設計する
    • ゲームを作るための道筋でプログラミング以外のつまずく要素を排除する

ていう設計意思を感じ取った。

コーディング規則に関する部分の一覧

ドキュメントの中でコーディング規約の部分についてもかなり言及や改良がされていることに気がつく。

主に、

  • 近代的なコーディングに矯正（強制）する部分
  • コードの短さを保つための部分

に分かれている。

可読性に関して矯正・強制する部分
  • タブによるブロック記法の採用
  • switch case文の改良
  • const,varで定数と変数を分けること
  • 返り値がないならdoで明示する
  • 演算子関連
    • a :: b （代入）
    • a ?(b, c) （条件演算子）
    • |,& (bool演算)
    • バイト列演算を関数化
  • \srcFile@globalVariable(外部ソースからの読み込み)
  • 待ち行列関連
    • 待ち行列の充実(stack, queue, list, array, dict)
    • 配列操作関数の充実
コードの短さを保つための部分
  • キャメルケースの推奨
  • 演算子関連の充実
    • a :$ b（スワップ演算子）
    • ^t（length）
    • #t（new）
    • ##a（ディープコピー）
    • a $> t(バイナリ符号化)
    • a $< t(バイナリ復号化)
    • +,* (private, overwrite)

代入::

例えば、Kuinだと代入は::。 これは他の言語だと珍しい。

珍しい理由は一番流行ったC言語とその派生が

  • = ←代入
  • == ←比較

だったから。

Cの派生では代入は慣習を壊さないように=が多い。
疑問に思わなかったけど、代入で=を利用するのは初学者に優しくないのかもね。

  • =と==はタイポし易いこと、
  • 数学で等しいと意味が違うことで混乱する

今ではIDEで気がつけるけど、テキストエディタで条件式に=ってタイポして無限ループを発生させるのはあるあるだよね。 そう考えると、::はとてもわかり易いし、混乱させにくい設計になっていることがわかる。

switch case文の改良

  • break文を廃止していること
  • 一つのcaseで複数の条件をまとめて処理できるようになっていること

switch内のbreak文はcase文を手動最適化するためなので、通常用途では要らない。 だから高級言語だとbreak制御は少なめ。 switch caseというC言語の部分を引き継ぎながら範囲や複数の判定を許容して、コードが変わらないのはわかりやすい。

以下に見るように多くの言語でbreak文が廃止されている。
不自然だもんね。仕方ない。

あと、switch caseに関する豆知識。

  • Pythonのようにswitchは廃止されてて、if elseオンリーな言語もある
  • Rubyのようにcase whenだったり、ブロック自体が値持ったりするから書く人によって形がかわる言語もある
  • goやswiftのように、fallthrough（breakしないで次のcase文を読む）で対応する言語も有る

日本語エラー

地味にいいなって思った部分。
エラーが母国語で表示できることはアド。
エラーが母国語以外だと前提に語学力が必要になる。
機械翻訳はそれなりに仕事するけど、結構足りてないことが多い。

ゲームを作りたい時に必要な機能の網羅

ゲームやツールを作りたいって考えた時に必要な部分が標準機能として揃っているのがとてもいい

  • セーブデータのためのバイナリ符号復号化
  • リリースのためのデバックデータを排除してビルドできるようになっているし、
  • GUIメニューやボタンの作成と利用
  • グラフィックの描画機能を標準機能として実装済み
  • 複数の待ち行列の利用（stack, queue, hash, list）

これらの要素は他の人にソフトを配布出来るソフトや機能を実装したいと思った時に、 だいたい調べる機能では有るけれど、言語の標準機能としてはまとめられていない気がする。

これらのことをするためには以下の手順を繰り返しながらやらなきゃいけない。

（

  1. どうやるか一つ一つ調べる
  2. アルゴリズムやどう動作するのかを理解する
  3. ライブラリを選択する
  4. ライブラリを取得して正しい場所に配置する。
  5. 利用方法やリファレンスをキチンと読んで利用する

）× n回

検索→理解→選択→構築→利用
と複数の種類の違う挫折ポイントが内包されている。

これらは環境構築に近く、非常に退屈で飽きてしまう作業である。 その部分を排除するために、標準のドキュメントや環境に含まれていることで参照する場所がわかりやすく プログラミングの難しさ以外の部分で折れてしまうことを防ごうとしているように見えた。

初心者言語と呼ばれる言語について私見

BASIC

メリット：
  • 高校の教科書に載る古典。
デメリット：
  • 古典であること
  • 標準で利用できる描画関数ことはすごいが応用が聞きにくい
  • コーディング作法の悪習を強要される
総評：
  • 日本のカリキュラムで教えている理由が謎。

C

メリット：
  • 現代のプログラミングの基礎、構造化プログラミングの走り。
  • いろんな言語でこの言語の片鱗を感じることが出来る。
  • なんでも作成できる。
デメリット：
  • 非常に学習コストや環境構築コストが重い。
  • 特に、ポインタやヘッダファイル、メモリ管理は直感的でない。
  • （includeを利用しないで利用できる）標準関数が少なすぎる。
  • アセンブリや低層レイヤーを触るなら非常に有用だが、簡易なソフトでは利用しない知識。
  • ライブラリがWeb上に散乱して居ること
  • 教育用にC89の作法が常態化しているという個人的な私怨。
  • 制限のきつい分、アルゴリズムの勉強を強制しやすいという意見が嫌い。
総評：
  • BASICよりはまし。
  • 初学者用じゃない言語。
  • 低レイヤーを勉強する人用

Python

メリット：
  • 海外で人気で、文献が非常に多い。
  • ライブラリはかなり揃っていること。
  • pipなどのライブラリ管理ツールがあること。
  • 標準関数が充実していること。
  • 読みやすいコーディング規則を強制される
デメリット：
  • 日本語文献が少なめであること。
  • バージョンで２，３で別れているので、検索のコツが必要
  • 静的型付けにハードル
総評：
  • 英語ができるなら、とても良い言語ではある。
  • 低レイヤー以外をかなり書きやすくコーディングできる。

Scratch

メリット
  • 画像を動かしやすい
  • マウスでプログラミング出来る。
  • 直感的にわかりやすい。
  • 一応、電子回路工作も出来る。
デメリット：
  • コーディング規則が学べない。
  • 書いたコードを管理しにくい。
  • CUIのアクセスが辛い。
総評：
  • 直感的に劇をプログラミング出来る。
  • ゲームやプログラミングをする体験が出来るツール。
  • コーディングや環境構築について深い知識があれば、ゲームや電子回路工作なども作成できるが正直微妙。

Kuin

メリット：
  • 日本語が中心であること。
  • 標準関数が充実していること。
  • よみやすいコーディング規則を強制すること。
  • 初心者の混乱しずらい言語設計で出来ている。
  • 日本語エラーが標準で出る。
  • 環境構築が容易。
  • 言語、ソフト作成～配布までのドキュメントが分散していないこと。
  • ゲームパッドなどに対応している
  • DLLをサポート
デメリット：
  • 日本語が中心であること。
  • リリースしたばっかりなので、外部ライブラリ・文献が少ない
  • ライブラリ管理ツールはわからない。
  • 通信周りがまだ貧弱？
総評：
  • 作品を作りながら学びたいというプログラミング初学者によさげ。

比較のまとめ：

上記の５言語のおすすめ度を独断と偏見で選ぶ。 他言語（Ruby,lisp,java等）を含めば最適はあるだろうけど、今回は上記５つの言語で比較。

学校の教育カリキュラムとするなら？

小学生　→　重要：直感的＋わかりやすさ

Scratch >>> Kuin > Python >>>>>>> BASIC >>> C

中学生 →　重要：日本語＋わかりやすさ

Scratch > Kuin >>> Python >>>>>>> BASIC >>> C

高校生　→　重要：汎用性＋学習コスト＋わかりやすさ

Python > Kuin >>>>>>> Scratch >>>>>> C >>>>>> BASIC

大学生　→　重要：汎用性＋応用性＋研究分野のライブラリ

Python>>> C >>>>>> Kuin >>>>>>> Scratch >>>>>> BASIC

初学者に「XXXXXXX」って訊かれたときに薦めるとしたら？

「作りたいものはないけど、プログラミングの基礎を知りたい」

Python >>> Kuin >>>>>>> C >>> Scratch >>> BASIC

「近代プログラミングを日本語で教えたい」
「GUIを触ってみたい」

Kuin >>> Python >>>>>>> C >>> Scratch >>> BASIC

「通信したい、ウェブサイトを作りたい」

Python >>>>>>> C > Kuin > Scratch, BASIC

「〇〇なゲームを作りたいから言語のオススメを教えて」

Kuin >>>>>>> Python >>>> C > Scratch >>>>>>> BASIC

※ドキュメントを読んだだけで、Kuinを利用したわけじゃないので間違いがあるかも