2019-08-01

AWS CLIでcreate-function時に「Cross-account pass role is not allowed」のエラー

普段、AWS Lambdaで関数を作成する際はブラウザ上のコンソール画面から操作していたが、AWS CLIで対応できるようにしたかったので試してみたところ、エラーが発生。

$ aws lambda create-function --function-name CreateThumbnail --zip-file fileb://function.zip --handler index.handler --runtime nodejs8.10 --timeout 10 --memory-size 1024 --role arn:aws:iam::123456789012:role/lambda-s3-role

An error occurred (AccessDeniedException) when calling the CreateFunction operation: Cross-account pass role is not allowed.
$

参考：チュートリアル: Amazon S3 で AWS Lambda を使用する - AWS Lambda

ちなみにクロスアカウントは使っていない。

よくよくコマンドを見ると、roleのAmazon Resource Name(arn)の指定に誤りがあった。自分で作成したroleのarnを見直して修正。

$ aws lambda create-function --function-name CreateThumbnail --zip-file fileb://function.zip --handler index.handler --runtime nodejs8.10 --timeout 10 --memory-size 1024 --role {正しいarn}

これで通った。別アカウントが作成したroleのarnを指定しまっていたため、Cross-accountに関するエラーが出たものと思われる。

2019-05-27

サービス作りにおける言語化の難しさ

基本的にTwitterで発信しているためブログには書いていないが、2019年の初め頃から個人でのWebサービス開発を進めており、2019年3月、英単語の記録状況を管理するためのWebアプリ「AwordZ」をリリースした。

a-word-z.com

英文を入力することで単語を抽出・原形化・翻訳を自動的に行うことができる。個人的に英語の多読学習を行っているのだが、分からなかった単語は全てGoogle スプレッドシートで管理しており、入力が面倒だったり覚えた・覚えていないの管理が難しい状態にあったため、この問題を解決するためにこのアプリを作成した。一言で表すと「英単語の暗記カード作成ツール」だ。

開発のモチベーションを維持するのが難しかったため、各々が三ヶ月でサービスリリースを目指すもくもく会「3monthsService」に参加させて頂いた。このイベントでは全員がサービス作りを行なっているので、自分のベースアイデアに対して様々な意見がもらえることがとてもよかった。また、Bug Bashというバグを洗い出すための手法で参加者がレビュアーとなってSlackからバグや改善意見を出して頂いたので、リリース前の思いもよらないバグも防ぐことができた。本当にお世話になりました。

shincyokudoudesuka.connpass.com

作りたいサービスの良さを言語化できない問題

ただ、制作途中から「これは本当に自分が思っているほど役に立つんだろうか」という不安感がよぎり始めた。不安を感じる度に機能を再考し、「この方向で仕様変更すれば良いサービスになるだろう」という気持ちは確かにあったのだが、機能が出来上がってくるとやはり自分の論理的な部分「本当にこれは面白いのか？」とささやいてくる。ただ、数か月かけて作っていたものなので、とにかく完成させなければ、という気持ちだけで無理やり開発を進めてきた。そして出来上がったものを見てようやく「何か良く分からないものを作ったな」という現実を受け入れることができた。

せっかく作ったので良いサービスにするため、できることはないか考えてみたものの、どうすれば良いサービスになるかが思いつかない。作っている本人が良さを理解できないようなサービスなので当然だ。自分で作ったものだが、「良いサービスにできず、生み出してしまってすまない」という気持ちがだけが残った。

それからというもの、他人のリアクションを狙ったアウトプットに対してひどく消極的になってしまった。いくつか新たにサービスを作ろうとしたものの、完成間近のところで「何が面白いのか分からない現象」が発生してしまい、結局リリースまで踏み切ることができなかった。作っている間は面白くなると感じているのだが、完成が近づくにつれ「つまらないサービスにしてしまったらどうしよう」とただただ不安が増すようになった。

納得できないサービスとなってしまった理由

元々、個人開発については「サービスを作って収益化する」という根本的な目標があった。元々収益化に対する執着はなかったが、どうせやるなら数値としての成果を求めるのがモチベーションのためには健全だと考えた。

目標を達成するためには「収益化するための仕組みがある」、「人に利用してもらう」という項目をクリアする必要があったが、前者を重視することで後者が疎かになってしまったように思われる。サービスアイデアとして「人に利用してもらう」というのは技術的な部分を除けば案外簡単に出てくるが、それを収益化するとなると一気にハードルが上がる。今回作成したサービスは「人に利用してもらう」という条件を機能要件の時点で満たせておらず、「作ってみればきっといい感じになるのでは」という希望的観測から生み出してしまったことが今回の問題点のように思える。

Done is better than perfect. 完璧を目指すよりまず終わらせろ

上記はFacebookの創始者マーク・ザッカーバーグの言葉だ。そして私はこの言葉を都合の良いように解釈した。どんなものでも完成させることは美徳だと考えてしまった。

だが、実際はそうではない。利用されないサービスを作ったところで、なんの意味もなさない。もちろん、設計やプログラミングをした経験は自分の成長につながるが、それであれば個人開発でなくても構わない。自分が個人開発で成したかったことは、自分のアイデアで人が喜んでくれることだったはずだ。高すぎるハードルは無謀だが、ハードルが低すぎても誰にも見えない。

プログラミングで「モチベーションが」とか「気合が」って言ってる時って問題はそういう精神性じゃなくて、戦略であったり技術的な問題が横たわってるよね。

方法論が分からん、技術が追いつかない、戦略が出てこない、そういうのを「気合」って言葉で片付けてたら次のアクションが支離滅裂になるし
— ジャバ・ザ・ハットリ🇩🇪個人開発で海外生活 (@nodenodenode1) 2019年5月26日

自分がやってしまったのがまさに上記のツイートで言われていることで、竹槍で戦車に突っ込んだ感がある。出せばなんとかなる、出さないよりは良い、という考え方が、理論を放棄することに繋がってしまったように思う。ひとまず自己分析した結果、「収益化」と「良いサービス」の両立が自分にとってハードルが高いため、しばらくは収益化を考えず、とにかく自分が納得できるレベルのものを作るための方法論を練っていきたい。

良いサービス開発のための言語化能力

例えば私の場合、UIのデザインをしているとできあがったものに違和感を感じ修正を繰り返すことがある。おそらくデザインを言語化できていないのが原因だろう。厳密にいうと「良さ」の言語化ができていない。個人的に「問題点」は言語化できるが、「良さ」を言語化しようとするとなかなか難しい。しかし世の中のUI/UXデザイナーの記事を読むと、「なぜ自分が作ったものが素晴らしいのか」を言語化するための試みができていて、改めてプロフェッショナルというものを感じた。

ic-root.com

サービスもデザインと同様、言語化が大事だ。自分がプログラマーということもあるかもしれないが、プログラムというものは論理で構成されているので、サービス/デザインに比べて言語化しやすいものだと思っている。今の自分にとっては「サービスの良さ」の思考プロセスをルール化できるようになることが重要だろう。

今後は言語化の訓練もかねて、PDCAを回しながら試行錯誤していく。第一目標は自分を納得させるためのルールを言語化すること。他人を納得させることはできなくても自分さえ納得させられれば、少なくとも意味のあるサービスになると思っている。（逆に、個人開発においては言葉で他人を納得させる意味はあまりない気もする）

今後について

現在は転職活動をしておりなかなか時間が取れないが、空いた時間はReactでゲームを作っている。ゲームといっても物理エンジンを使うような激しいものではなく、状態遷移だけでシステムができるようなカードゲームや脱出ゲームのような類のもの。子供の頃からゲームを作ることは一つの夢だったので、Reactの学習がてら進めている。状態管理がそれなりに激しいため保守性を考慮するトレーニングになるし、アニメーションのチューニングも根本的な仕様の勉強になるのでなかなか良い。ただ今のところゲームとして面白くはならなさそう。面白さが言語化できるようになれば公開したい気持ちはあるが、とりあえずは気持ちだけ。

Webサービスの開発も久しぶりに始めたい。ユーザーがコンテンツを投稿するタイプのサービスをどうやって使ってもらうか、という課題が現状ではクリアできそうにないため、コンテンツは運営（自分）が提供する形式が良い。おそらくかなりニッチなサービスになるが、個人はニッチな分野で戦うべきだと思うのでよしとする。学習がてら利用経験のないElixirで作ろうと考えていたが、今は新規分野の学習よりもサービス開発に身を入れたいのでPHPかRuby、Reactで作る予定。

また、以前からではあるがUI/UXデザインやSVGアニメーションにも興味がある。単純に自分の趣味嗜好だが、デザインの言語化を行えるようになれば、サービスの言語化にもつながるのではないかと思っている。JSアニメーションの腕をあげれば先述のゲームにも活かせるので夢が広がる。Reactでのアニメーションを色々試してみたかったので、ポートフォリオをReactで書き直した（トップページ以外はデザインが考えつかず放置）。ソースコードはgithubで公開している。

defunty.dev

github.com

アイデアだけはどんどん湧いて出てきて、Evernoteを見返すと30個程アイデアが溜まっていた（面白いかどうかは別だけど）。アイデアが出る限り、個人開発はどんな娯楽よりも楽しい（難しい課題が出ると辛いけど）。常にアンテナを張る必要があるので、生活に張りが出る（疲れるけど）。

自分のセンスに自信を持つことは難しいけれど、今回考えを洗い出したおかげで今後にすべきことは見えてきた気がする。できないことがあるのなら、できるためにすべきことを書き出して、愚直に達成していく。今まで考え無しで動いてきたので、今後は色々と考えながら試行錯誤していきたいと思う所存です。

2018-12-29

平成以降に生き残るWebエンジニアについて考える

2018年が見せた発展と凶器

2018年を振り返ると、Web開発のマイクロサービス化が非常に発展した年に感じた。クラウドプラットフォームの観点ではAWSやGCPの各種サービスは益々の充実化を行い、フレームワーク・ライブラリ観点ではVue.jsアプリケーションの開発フレームワークNuxt.jsが特に日本で大きな賑わいを見せた。

これらの発展により、ある程度のレベルではWeb開発はエンジニアレイヤーではなくユーザーレイヤーで行われるようになった。つまりWebの知見を持っていない人でも自分の作りたいサービスが作れるようになったため、そのレベルで仕事をしていた人は今まで仕事を請けていた経営者や営業職と同じ開発レベルになり、一つ上の段階にステップアップしなければならなくなったのだ。

「Webサービスで起業したいから企画するわ。君、絵ができるからデザイナーね。君は......うん、まぁ開発でもやっといてくれればいいよ」みたいな図式になるのはそう遠くない未来だ。（最終的には素人バンドが各々の楽器を決めるかのように役職が決まっていくのではないかと考えている。）
実際、「3ヶ月プログラミング勉強してサービス開発して起業しました」という人は就職活動中のサークルリーダー程度にいるようなので（彼らが成功するかどうかは別として）、今までの「Webアプリ開発請負人」は実質既にお役御免となっている。

この先生き残るパターン例

まず第一に至極当たり前なのだが、技術力のある人は生き残る。ただ、当たり前のところを勘違いしている方がいくらかいるようなので注釈を入れると、複数のプログラミング言語を利用できることは技術力に直結しない。どうも求人サイトの多くに見られる「XXX（プログラミング言語）での実務経験N年以上」といった必要条件が原因のようで、多くのプログラミング言語を利用できるのは多くの国の言葉を理解できるようなもののように感じる人が多いらしい。

もちろん多くのプログラミング言語に通じていること自体は良いのだが、結果的には学習機会が分散しており「浅く広く」の図式に陥りやすい。Web系の場合、基本的にはタイプの異なる2種類の言語（例えば動的型付けと静的型付けなど）を深くまで抑えておけば、他のプログラミング言語をゆっくり始めても1ヶ月あればそれなりに使えるようになるのではないか。モダンな環境で掲示板が作れるとアピールする人よりも、レガシーなPHPで様々なアプリを構築した人の方が必要とされるシーンは多い。（レガシーが悪とされるのは大概エンジニアの肩書き都合によるものだ）
もちろんレガシー環境の仕事は今後減り続けて行くと思うが、そのときに得た深い知見は尖っだ武器になる。

数本のなまくらより一本の業物を磨けばひとまずは十分だろう。

次に、実務でしか得られないような経験を持っている人であれば、問題はない。ここでいう「実務でしか得られないような経験」というのは
・人と金のコストバランスを適切に捉えられる人
・コストバランスの整った技術選定ができる人
・大量アクセスを捌いてきた人
・特殊な状況下でしか起こらないような問題を解決してきた人
・運用環境を丸々移行してきた人
・複雑な希望要件に合わせて適切なシステム設計ができる人
などである。現状、各種開発サービスの特徴は札束で殴る形式のものなので、何も考えなければとにかく金がかかる。金をかけてどでかいコンテナを買うよりは、収納上手な家政婦さんを一人雇った方がいいケースもあるので、家政婦さんポジションをキープできる人はやはり強い。

他に例を挙げると、
・キャッチアップ・成長率が異常に早い
・サービスをグロースさせるセンスを持っている
・エンジニアリングとデザインの両方に長けている
などの様々な要素があるので、エンジニアリング以外にできる何かを確立しておくと、掛け算的に生存確率が上がるはずである。

経験の浅い人は核となる技術を探すべき

先述した通り、エンジニアにとって技術は刀のようなもので、いざというときに自分を守れる役割を持たせるべきである。最新のフレームワークやツールを追い続けるのもいいが、何も武器がない状態が続くと「顔が広いだけの素浪人」のまま一生を終える場合もあるのだ。まずは核となる技術を身につけて、その上で自分の生産力を最新の技術で倍増させるやり方をオススメしたい。

「Python・Rails・Laravel・Go・Angular・Vue・Reactを1年ずつ経験しました。得意なものは特にありません」というようなアラサーなど欲しがる人はいない。また、最新技術を追いかけるということは同じ時間を使って技術競争に打ち勝たなくてはならないので、自分が優秀だと自覚していない場合は今追いかけている最新技術の中から自分の核となるものを選び出す必要がある。なおフロントエンドのは場合はまた別で次々に技術が死んでいくので、フロント一本で行く場合はキャッチアップの素早さを磨いていく方が得策かもしれない。

また、快適と思えるような難易度に浸るのも危険だ。例えばProgateでは易しい課題を与えてユーザーのモチベーションを高めてくれるが、実際の案件はそうはいかない。発生している原因が分からない、解決できるかわからない、そもそも問題なのかどうかすら分からないなど、様々な壁にぶち当たると思う。その艱難辛苦を技術で解決する力こそエンジニアリングであり、Paizaのスキルチェックを解き続けたり、寿司打のお勧めコースを食い続けることで身につくようなconfortableなものではないのだ。

paiza.jp

typingx0.net

フレームワークは貴方の生産力を上げるためのものであり、できないことをしてくれるツールではない。貴方にとって不可能なことを可能にするのは貴方自身であるべきである。

ホームページビルダーが夢想した未来

今は昔、「ホームページビルダー」というソフトがあったらしい。私はこの時代のことをよく知らないので詳しくは分からないのだが、HTMLやCSSの知識がなくてもGUI上でホームページをデザインすることのできる、当時としては非常に画期的なソフトウェアのようだ。
ここでは敢えて「ホームページ」という表現を使わせて頂く。
ただ、細かいカスタマイズについては難しいようで、なかなか個人個人の要望に応える力はなかったように思える。

おそらくホームページビルダーが実現したかった未来というのは、誰でも、専門知識がなく、自分のWebサイトを構築することができるものだったのだろう。そして今、それをPaaSやFaaSで世界の名だたる大企業たちが実現しようとしている。ホームページビルダーが出た当時、もしかすると「このソフトはWebサイト製作者を殺す」と噂になったのではないだろうか。ホームページビルダーがどれほどの猛威を奮ったかは不明だが、クラウドの技術が半端なWebエンジニアを殺し始めているのは明確である。

ホームページビルダーのifが今、形を変えてやってきたのだ。

2018-06-30

Bootstrapでborder持ち要素の余白を調整する方法

Bootstrapでborderを持った要素を並べようとすると要素同士のborderがぴったりとくっついて面倒なことになったので、解決手段をメモ。結論としては、「並べる要素の直下に囲い込むための要素を追加して囲い込む要素にborderを持たせる」のが今回対応した方法。
Bootstrap3でも4でも問題なく対応できるはず。
以下詳細。

普通に並べると隣接要素のborderがくっつく（失敗例）

Bootstrapのグリッドレイアウトを利用する基本ルールとして、「並べる要素」を「.container（もしくは.container-fluid）」と「.row」で囲むものとなる。今回の説明ではborderを持つ「li」を並べると仮定して以下のようなHTMLコードをを基に話を進める。

<style>
li{
  border: 1px solid black;
}
</style>

<div class="container">
  <ul class="row">
    <li class="col-xs-12">aaa</li>
    <li class="col-xs-12">bbb</li>
    ...
    <li class="col-xs-12">zzz</li>
  </ul>
</div>

並べる要素に直接marginを加えるのはNG

Bootstrapでは「.col-*」の左右にpaddingを持たせることで要素同士の余白を取る。つまり、「li」同士にmarginがないため、このままではborderがぴったりとくっついた形になる。
さらに、「.container」が左右にpaddingを持ち、「.row」がそのpaddingを打ち消す形でネガティブmarginを持っているので、「li」同士の余白を持ちながらも、左右端の「li」は「ul」の左右端に張り付くレイアウトを可能にしている。

そのため、「li」の左右にmarginをかけるとBootstrapで左端・右端にぴったりとくっつけるための機構を壊してしまう形になる。「li」marginをかけずに余白をとるために、「li」の直下要素にborderを持たせる必要がある。

borderを持った「li」に余白を持たせる場合、上記コードを変更すると以下のようになる。

隣接要素のborderがくっつかないように修正

<style>
.original-ul.row{
  margin-left: -20px; /* 「rowがデフォルトで持つネガティブmargin（-15px）」 - 「liに持たせたいpadding 」*/
  margin-right: -20px; /* 「rowがデフォルトで持つネガティブmargin（-15px）」 - 「liに持たせたいpadding 」*/
}
.original-ul > li{
  padding: 0 5px; /* 隣り合うborder同士の余白 */
}
li div{
  border: 1px solid black;
}
</style>

<div class="container">
  <ul class="row original-ul">
    <li class="col-xs-12"><div>aaa</div></li>
    <li class="col-xs-12"><div>bbb</div></li>
    ...
    <li class="col-xs-12"><div>zzz</div></li>
  </ul>
</div>

今回は隣り合うborder同士のpaddingを5pxとしたので、「.row」が持つネガティブmarginもその分加える（marginを減らす）必要がある。
全ての「.row」に変更後のスタイルが当たらないように、別途class（.original-ul）を追加してスタイルを当てた。

ある程度きっちりとしたデザインを作るのにBootstrapは適していないが、どうしてもborderを持った要素を並べたい場合は、上記のように対応するのがいいかと思われる。

2018-05-18

読書感想文「コインロッカー・ベイビーズ（村上龍）」

いやぁ〜、ダチュラダチュラ。村上龍のコインロッカー・ベイビーズ読みました。あらすじとしては、赤ん坊のときにコインロッカーに捨てられた二人の少年達の生き様を書いた物語です。村上龍は初めて読みましたが、生卵ぶちまけたような世界観がすごかったです。

ネットリ・ジクジクとした世界観

話の主軸となる二人の主人公ハシとキク二人は過去のトラウマから屈折したような考えを持っているんですが、名もなき登場人物の狂いっぷりがヤバイ。主要人物をとっ捕まえて蛙の卵を突っ込むだのホームレスに咥えさせただの生々しい話を聞いてもないのに数ページに渡って一人で喋り続けます。この空気感がなんともきつくて、苦手な人は多そう。正直「早く終わんねぇかな」と思いながら読んでいたけども、今思うと、この抜け出したくなるような閉塞感やネットリした熱帯感は子宮+コインロッカー的なワールド世界を感じられる。

人は救いに包まれているのか、救いを内包しているのか

ハシとキクは過去の経験と出来事をきっかけに謎の「心音」が聞こえるようになります。ここでいう「心音」は誰のものなのでしょうか。自分の心音か？それとも母親の心音か？強烈に頭からこびりついて離れない心音の答えを求めて二人は模索するのですが、ここで探す道が違えることで、生き方にも隔たりが生じてきます。外に答えを探した少年と自分の中に答えを探した少年。それぞれはどんな道を辿り、どんな答えを探すのか。

まとめ

かなり重厚感のある物語ですが一気読みするのがオススメです。サウナで我慢して汗をダラダラ流してようやく出たときに口にするキンッキンに冷えた水のような爽快感を味わってください。村上龍は初めて読んだけど、一つの話の世界観が巨大に感じられて凄い。カフカの「城」的なシステム世界を感じる。ただまた読むかっていうと辛い。刺激が欲しくなったときにまた読もう。

2018-01-28

誰も言わないのでAlexaの不満点だけを叫びたい

その他

去年の年末に申し込んだAlexaがようやく届いた。EchoとEcho Dotを同時に申し込んで先に注文確定できるものを買おうという算段で、Echoの招待が先に来たので迷わずEchoを購入。スマートスピーカーには全く興味なかったがGoogle Homeが3000円台で買えるってのを聞いて、意外とリーズナブルだなーと思って何ができるか調べていくうちに気づいたら買ってしまっていた。
Amazon PrimeサービスのヘビーユーザーなのでEcho一択だなと衝動的に買ってしまったのだが、しっかりと下調べをしないまま購入したので結構な思い違いや不満点が出たため、今後購入を検討する人のために諸々の感想を述べておこうと思う。

また、Alexa（人工知能名）とEcho（商品名）で分けるのが煩わしいので、以下、呼称を「Alexa」で統一することとする。

「Skill」のレーティングが機能していない

まず、Alexaには「Skill」という特徴があることを説明しよう。 Skillは砕いていうとプラグインのようなもので、Alexa自体が持っていない機能を別途インストールすることができる。日本で利用出来るスキルの数は、2018年1月現在、500以上とされている。ニュースを読み上げてくれる実用的なものからピカチュウとおしゃべり（という名の一方的な文字列の殴り合い）ができるユニークなものなど、その色は多岐にわたる。

しかし、現在Alexaの管理ページからSkillを確認すると評価がついているものが見当たらず、レーティング機能がほぼ機能していないように思われる。ふざけたジョークSkillも多いので、役立つSkillを発掘しようとすると、黎明期感のあるカオスな空気に辟易してしまう。ちなみにニュースSkillをおすすめ順で並び替えると
「大宮経済新聞」
「船場経済新聞」
「梅田経済新聞」
がTOP3に連なっていた。

特定メディアのニュースSkillをピックできない

まだSkillとして進出していないWeb媒体のメディアも今後はどんどん増えていくことだろう。それ自体は喜ばしいことだが、AlexaのニュースSkillを起動する仕様自体に問題が残っている。例えば、経済情報にアンテナを張りたい方であれば、大宮経済新聞・船場経済新聞・梅田経済新聞を真っ先にインストールするものだと思われる。

さて、大宮経済新聞のSkillを起動したい場合はどうするか？答えは「ニュースを教えて」である。そうするとインストールされているニュースSkillが順々に流れていくのだが、特定のニュースSkillを聞きたい場合はそれが流れるまで待つか、一つずつ飛ばすしかなく非常に面倒なのだ。

おそらく、これは起動コードの仕組みによるものだと思われる。Alexaでは「"Skill名"を開いて」という言葉がSkillの起動コードとなる。つまりシステム上、Skill名は一意の文字列でなければならない。このシステムのために、似たようなSkill名が増えると任意のSkillが起動できないという可能性が高まるため、Amazon側としてはできるだけコード名で起動するSkillを増やしたくないのではないかと勝手に考えている。このシステムはあまりにも刹那的すぎるでしょと感じるが、さすがにずっとこのままでは問題なのは明らかなので、Amazonが今後のアップデートで対応してくれることを期待するしかない。

再生したい曲を再生できない（Amazon Music）

そもそもの利用想定がファジーな感じなので、「明るい曲」とか「静かな曲」とかいうと適当にプレイリスト名からピックアップしてくれる。（「暗い曲」や「静かな曲」はないけどね！）
普段聞かない曲が流れるので自分の行動では知ることはなかったであろう音楽などに触れる機会も増えるので、この即席マッチングな感じは非常に好きなのだが、ライブラリに入っている曲はなぜか絶対にシャッフル再生から始まる。

「ライブラリに入れるくらいだから何回も聞いてんだろ？」と気を聞かせてシャッフルにしているのかもしれないが、私はアルバムに関しては曲順は変えたくないし、ライブラリに入れる場合は自分的ベストな曲順を設定しているのでそれをシャッフル再生されるのは、作った料理に調味料をシャバシャバかけられる事案に似た哀しみを感じる。また、短いアルバム名（アーティスト名）だと意図しないものがヒットするので、結局はスマホとBluetooth接続して流すのが早い、というのが使ってみた所感。Amazon MusicライブラリのセクションごとにAlexa用のコードを設定できれば、普段使いとしてはAlexa単一で完結できるようになるんだがなぁ。あまりスマートでないけど。

そんなこんなで、音楽再生に関してはかゆいところに手が届かないのが非常に悩ましい。Alexaには帯にもタスキにも使えるような万能さを持って欲しいと思うのは欲深いだろうか。

「二度とこんなことすんじゃねーぞ」機能がない

Alexaでは音量調整も声で行える。非常に便利なのだが、私の滑舌が悪いのか「音量を小さくして」というと音量をMAXにされて深夜の1時に爆音ミュージックを流してしまうという事案があった。それ以来、夜中に音量調整命令をするのは控えている。
「Alexa、ほんと今のはね、ダメなやつよ？」
「スミマセンナンダカウマクイカナイミタイデス」
と定型文を返されるので、本当にわかってんのかこいつはと心配になる。

ただし、Alexaの管理画面にいくと音声フィードバック機能というものがある。この機能を使えば、こちらが出したメッセージをAlexaが上手く聞き取れたかどうかをレポートすることができる。しかし、この機能、「正しく反応したかどうか Yes / No」という形式でしかレポートできない。いやもうね、YesとかNoとかじゃないんですよ。もう二度とこんな過ちはおかして欲しくないんです。俺の出したい「No」は知りたい天気の場所が違ったとかいう「No」とは全然違うの。AbsolutelyにNeverな「NO!!!!」なの。
そういう形で強くフィードバックができればいいんだけど、親元にメールを送るしかないんだろうか。

タイマーをセットしたいのにスリープタイマーがセットされる

「〜〜のタイマーをセット」というと五分五分でスリープタイマーがセットされてしまう。音楽流してないのに何をスリープしようとしているのだ君は。正しいコマンドが分からないのでそのあたり試行錯誤しているのだがアフィブログの「Alexaこんなことができます、便利！」というポジティブキャンペーンが多すぎて欲しい記事が検索しづらくなっている罠。皆さんもっとネガキャンしてください！

--- 追記 ---
「〜〜分経ったら教えて」というとタイマーを起動してくれることが分かった。
学習しました。

言語翻訳ができない

Alexaには翻訳機能がない。まぁそれは元々分かっていたことなのだが、これだけSkillがある中で翻訳用のSkillも無いのである。これについては完全に自分の勘違いなのだが、翻訳用のSkillがあるものだと勝手に思い込んでしまっていた。というのも日本でのAlexaの発売当初より、オンライン辞書データベース「英辞郎」を運営しているアルクから各種Skillが提供されるという情報があったからだ。

アレクからは「キクタン」・「英語クイズ」など、教育系に有用なSkillがあるので、もちろん翻訳用のSkillもあるだろうと勝手に思い込んでいたところ、アルクからはおろか他企業からも翻訳用のSkillは出ていない。

今後アルクからの開発を期待したいところではあるが、アルクの英語学習Skillは非常に音質が悪い。AMラジオを聞いているかのような音質なので私のような低級英語レベルでは基礎レベルの問題でも太刀打ちできない。（まともに英語ができる人であれば気にならないのかもしれない）
音源の悪さについては開発の問題ではなく、このSkillは商品の試用版みたいなもので、ちゃんと聞きたい人はお金を払ってCDを買ってくれということだと思う。アルクのSkillはあくまで商品のプロモーションだと考えられるが、商品を知ってもらうために質を落とした商品を渡すのはどうなのかと疑問に思うところはある。なので、今後の翻訳Skillの開発に個人的には期待していないし、開発されたとしてもそれはやはり試用版にとどまると思う。（いちおう言葉として出しておくけどそれは全く悪いことではない。有用なものにお金がかかるのは当然である。）

終わりに

つらつらと不満を書いたけどAlexaを買うなと言っているわけではなく、これらはあくまで注意点であり、正しくスマートスピーカーを選択するための情報として利用してもらえれば幸いです。
今後のAlexaの発展とSkillの充実を願って🙏

2018-01-07

Canvasの諸々概念についてメモ

JavaScript HTML

最近趣味でCanvasを使ったお絵描きにはまっている。とはいっても線を曲げたり円を描いたりするレベルの静的な描画だけど。絵は描きたくないけど絵を作りたいのでCodepenで悠々と遊んでいる。あまりCodepenに投稿されているのは大概アニメーション処理が入っているので、静的画像を描画するための参考にするには難しいけど、色々と刺激になります。

Canvasのリファレンスを読んでよくわからなかったのがPath（パス）の概念について。描画ツールではポピュラーな用語のようだけど、そういうのに疎い自分としてはPathがどういったものなのかイメージしづらかったので、諸々の。ついでにがてらメモ。

PathとはCanvasにおけるPathは描画を行うための情報（点座標・線色・背景色など）の集合体。描画状態とは異なる。

Contextとは描画APIを利用するためのオブジェクト。

Pathは一つのContextに対して一つしか存在できない。複数のPathから描画したい場合、

Pathの作成・描画
↓
Pathのリセット  
↓
新たなPathの作成・描画
↓
...繰り返し...

という流れで処理を行う必要がある。

Pathのリセットを行うためにはbeginPathを呼ぶ。

線や弧などの2つ以上の点を持ったパス情報の一種をSubpathと呼ぶ。例えば、(0, 0) (10, 10)で閉じたPathは(0, 0)から(10, 10)のsubPathを持っているの場合と同様の描画になる。ただし、上記二つの情報自体は異なるので同一の情報ではない。値として「解が算出可能な式」を持っているような状態に近いような感覚だと思われる。

Path ∈ Subpath

closePathを呼ぶことで現在の開始パスと最終パスをつなげ、終点を新たな最終パスとして追加する。

三次曲線を使うようになると途端に面倒になってきた。Processingは動的なクリエイティブコーディングに適していると思うが静的でも問題ないんだろうか。そもそも絵を描くのにCanvasを利用するっていうのが時代錯誤的ではあるんだけど。静的な描画に適したプログラミング言語があれば教えて頂けると幸いです。

今夜がλ

夜だけプログラマー