#実験動画 CodePipeline を試してみる / クライアント処理だけで Excel エクスポート機能を実現する

​

明けましておめでとうございます！

​

おかげ様で、ブログ開設から旧年までで通算30万アクセスを達成いたしました。

かなりニッチなテーマにも拘かかわらず、関心を寄せてくださった方がいらっしゃることを大変うれしく思います。

​

本年も、より一層のご愛顧のほど、よろしくお願いいたします。

---

AWS Codepipeline すごい

​

一年の計はなんとやらで、元日から「AWS Code Pipeline で Angular アプリを自動ビルド & デプロイする」という実験をしておりました。

​

元日くらい、だらだら過ごせばいいのに……

​

その様子を 10分くらいの動画にまとめましたので、ぜひご覧ください。

​

長いよ！ あと音楽が無駄にかっこいい。

​

極限までコンパクトにしたつもりなのだけど…… まぁお正月の長時間特別番組だと思えば……

---

GitHub Pages とは何が違う？

​

GitHub Pages にも似たような仕組みがあるよね？

Push した静的サイトをホスティングするようなやつ。

​

あれとはちょっと違うよ。

GitHub Pagesは、ビルド後の生成物をプッシュしないといけない。

つまり、
❶ ビルドのコマンドを自分で叩き、
❷ ビルドの完了を待ち、
❸ 生成物をコミット、
❹ プッシュする
── という手間が発生するんだよ。 特に、本来バージョン管理の対象でもないビルド後の生成物を Git にコミットする点が、ものすごく違和感が大きかった。

​

なるほど。

とりあえず放ったらかしでビルド & デプロイが完了するとは、随分と便利な時代に……

---

クライアントサイドの処理で Excel ファイルを作る

​

さっきのからくりにはまだ一つ課題があって、デプロイされるのはせいぜい HTML, CSS, JavaScript くらいで、動的な Web アプリをそのまま動かせるような代物じゃない。

まぁ、『静的サイトホスティング』だからね。

​

なるほど……

​

とはいえ、従来サーバサイドでしかできないかった処理が、今ではクライアントサイドでもできるようになったので、本当におもちゃみたいなミニアプリならコレで充分事こと足たりてしまう。

​

ふむ……

これ、サーバからダウンロードしているわけではなく、ブラウザ上で、その場で Excel ファイルが動的に作られているんだね。

​

うん。

今回の方式なら静的 Web サイトホスティングサービス上にデプロイしてもちゃんと動作するんだよ。

わざわざアプリケーションサーバを別で立てる必要がないんだ。

​

そうか、アプリケーションサーバを稼働させるためのお金が余計にかかるし、外部の人が勝手に API を叩けなくしようとすると、防御がより面倒になるんだね。

​

余計なラウンドトリップを減らすためにも、クライアント側のビジネスロジック層を厚くするのは一つの妙案だと思うのです。

---

​

そんなことをしているうちに、冬休みが終わっちゃったよ。

​

明日からまた元気に働くしかないね。

​

それでは皆様、よい一年を。

---

おまけ: 本日のおたより

見た人が擬似体験できる動画を目指していたので、これはありがたいお言葉。

今年もよい一年になりますように。

#雑談 システムの手触りとホスピタリティについて

先日、バスの運転手さんと話す機会があった。

実は彼と僕は同期の桜。 もともと同じ会社に勤めており、僕が一方的にライバル視していた優秀有能なインフラエンジニアだった。

やがて彼は様々な事情からIT業界を離れ、現職に就いて今に至る。

今日はそんな友人から聞いた、ある教訓めいたお話。

​

たーせるくんはいろんなところに一方的なライバルがいるんだね。

​

うるさい！

首都圏のバス業界はIT化が進んでおり、設備投資も惜しまないという。

しかしながら、システムを作る側から使う側に回って、色々気づいたことがあるという話を聞いた。

少し前、バスの料金機を更改したんだけど、現場の評判は非常に悪い。

基本機能は従来とあまり変わらないものの、UI が物理キーからソフトキーに変更され、これが非常に使いにくいんだ。

​

どゆこと？

​

バスの運転手さんはね、実は停留所に到着する寸前から料金機を操作する準備をするんだ。

​

え、でも、目を離したら危険じゃない？

​

そうだね。 だけど物理キーなら、バスが完全に停まる前でも指先の感覚だけでボタンに指を掛けることができていた。

ソフトキーだとそれができない。

​

そうか……

それまで無意識にできていたオペレーションが奪われて、却かえって不便になったんだね。

​

不便どころか、交通事故のリスクも上昇したんだよ。

バスの運転手さんは、安全運転と定時運行が最優先業務。

たった数秒のロスとはいえ、停留所に止まるたびにそれが累積すれば定時運行に支障が出るおそれもあるそうだ（特に停留所が多い路線の場合）。

さらに、もう一つ大きな問題点を挙げている。

停留所に着いたあと、運賃を設定するため、乗客から申告のあった停留所のボタンを押すんだけど、文字のフォントサイズが非常に小さいんだ。

せめて拡大機能があれば……

ユーザは、余裕のある状態でシステムを使うとは限らない

​

けっこう厳しい意見だね。

​

会社を離れて、システムを使う側に立って初めて気付くことも多いのかも知れない。

僕が思うに ──

​

？

​

システムを作る側から見て、『使う側が、どういう状況でそのシステムを操作するのか』という想像力がいまいち足りていない気がする。

​

ふむ……。

​

当たり前だけど、机の前にじっくり座って、全神経を集中させてシステムを操作してもらえるとは限らない。

たいてい、何かをしながら、その片手間にシステムを操作することが多い。

​

なるほど、運転手さんなんて特に、時間的な制約の中で操作を完了させないといけないよね。

​

うん。

開発中はつい忘れがちだけど、「ユーザがシステムに使われる」というのは、こういう状況を指すのだと思うよ。

常にモニタを見ていられるわけでもなければ、入力に時間的猶予がないケースも多い。

況ましてや、物理キーのときにできていたオペレーションの直観性が、皮肉なことにプロダクトの進化によって損なわれてしまうことすらある。

​

残念だね。

​

アプリ屋の気持ちとしては、ソフトキー化によって画面が整理され、誤操作が減ると考えたんだと思う。

物理キーと違って、今押しちゃいけないボタンはそもそも画面に出てこなくなるからね。

​

うん。

​

でもその結果、触覚インタフェースが消えてしまった。

ユーザは触覚を頼りにシステムを直感操作できなくなってしまったんだ。

​

そうか！

この料金機を作った人たちは、バスの運転手さんが使うシステムから触覚インタフェースを取り除くことがどれほどの不便をもたらすか、想像力と配慮が足りなかったんだね。

​

誰が、どういう状況でそのシステムを使うのか ── という意識は本当に大事だね。

おしまい。

2020年買ってよかった本10選

​

2020年のたーせるくんの業務は、本日をもって終了しました。

お仕事おつかれさまでした！

​

やぁー……

本当にどうなることかと思いました。

今年は、突然の異動・夜通しの本番移行・慣れないテレワーク・炎上案件の救難・そして AWS ソリューションアーキテクト アソシエイトへの挑戦など、本当にいろいろありましたが、無事にお仕事も納まりました。

コロナ禍かとはいえ、いろんな人との出会いもあり、別れもあり。 楽しくてつらい一年でした。

​

ところで、今年はどんな本を読んだの？

​

マンガから技術書までいろいろ読んだものの、今回も敢えての10冊に絞って紹介していこうと思います。

#雑談 Appleシリコン搭載MacとかFinal Cut Proとか買った話

M1 搭載 Mac を買ってしまった件

​

なにやらたーせるくんは、Apple シリコン（M1）という、まったく新しいチップセットを搭載した記念すべき第一号 MacBook Pro を買っちゃったようです。

​

8年ぶりの MacBook Pro だね。

8年前のやつは、Retina ディスプレイという超高解像液晶が初めて搭載されたモデルで、まぁ本当にいろいろ思い入れがあったんだけど買い換えた。

​

8年も使えば十分だよ。

​

とりあえず試運転も兼ねて、新しい Mac で VSCode と Xcode を使ってみたよ。

youtu.be

​

なんだこの唐突に始まって唐突に終わる動画は……。

​

いや、ちょっと Mac に合わせて動画作成ソフトも新調したので、そっちも試運転してみたくなったんだよ。

Final Cut Pro っていうやつ。 3万6千円くらいした。

​

たっか……！

無料の iMovie でいいじゃん……。

​

iMovie だと、字幕とかの表現に凝れないんだよ。

ホント細かいことだけど、自分がやりたいと思った演出ができないんだ……。

​

まぁ確かに今までの動画より少しだけテクニックが上達（？）したように思ったけど、それは道具が変わったからだったんだね。

​

まだ勉強中だよー。

慣れてきたらまた動画を作るかも。

​

がんばがんば。

音源分離とラッスンゴレライ

​

ここでこの話をしようかどうしようか迷ったんだけど、音源分離っていう技術があるんだ。

​

あの、既存の音源からボーカルとそれ以外にバラしてカラオケを作ったりするやつ？

​

そうそれ。

今はディープラーニングによって、かなり精度よく分離できるんだ。

​

ふむ……。

​

これを使えば、ある楽曲のボーカルに別の楽曲の伴奏を重ねる遊びができてしまう。

マッシュアップっていうんだけど。

youtu.be

​

これは……。

​

DOVA-SYNDROME のフリー音源とラッスンゴレライのマッシュアップです……。

あ、映像はたーせるくんが春先に遊んでいたどうぶつの森のプレイ動画をシンクロさせました。

​

パリピ感やばいな……。

Angular × FullCalendar でドラッグ & ドロップできるスケジューラを作る

そういえばかなり昔に、@angular/cdk を利用してスケジューラみたいなものを作る記事を投稿しました。

tercel-tech.hatenablog.com

あれから1年ちょっと経ち、FullCalendar という面白そうなおもちゃを見つけたので、Premium ライセンスを買ってこんなものを作りました。

youtu.be

なかなか直感的な操作性を実現できて、作ったものを触ると我ながらかなり楽しい。

もう少し触って手ごたえを摑んだら、簡単な使い方をここで紹介したいと思います。

ではでは。

AWS の Diagram Maker を Angular に組み込んでみる

​

先日、AWS が Diagram Maker という画期的な UI ライブラリを公開しました。

ダイアグラムエディタ機能を簡単にアプリケーションに組み込むことができるらしいです。

​

でも残念ながらリリースされたばかりで、チュートリアルや解説記事がまだまだ少ない状況なんだよね。

​

そんなわけで、ちょっと触ってみて、できたところまでチュートリアルにしようと思いました。

それがこの記事です。

はじめに

先日、フロントエンド界隈でGigazine さんの記事が俄にわかにバズった。 あの AWS が、ダイアグラムエディタを実装するライブラリ「Diagram Maker」を公開したという。

gigazine.net

ライブラリの紹介については当該記事に譲るとして、さっそく中身を触ってみることにした。 それもよりによって、React や Vue ではなく Angular と合わせて使ってみようと考えた。

つい先日 #AWS がリリースして話題になった Diagram Maker をためしてる。
ひねくれものなので、React ではなく #Angular ( #TypeScript ) と組み合わせている。

公式ドキュメントがあまり親切ではなく、ソースを読解しながらちょっとずつ進んでいて進捗わるい……。とりあえずここまで。 pic.twitter.com/J53vhP8sr8

— たーせる (@tercel_s) 2020年10月10日

完成（予定）図

今日は長なが丁ちょう場ばになることが予想されるので、モチベーションを上げるため先にゴールを示しておこう。

静止画でお伝えできないのが残念だが、ドラッグ & ドロップでいろんなところがぐりぐり動かせる。

こんなインタラクティブなコンポーネントがアプリケーションに組み込めたら、よりユーザフレンドリーなシステムが実現できるかもしれない。

ペーパーマリオのバトル（パズル）をアルゴリズムで解く

※ この記事は、ゲーム進行が（任天堂の意図しない形で）不正に有利になる遊び方を推奨するものではありません。 また、本記事の内容を実践したことによって生じたいかなる損害も保証しかねます。

ペーパーマリオ オリガミキングが面白そうな件

​

今年の夏休みはコロナ禍で帰省もできなくて暇だなぁ……。

​

こんなときはゲームで遊ぼう。

ペーパーマリオが面白いらしいよ。

​

え、、

もしかして、買ったの？

​

いや、人が遊んでいるのを見ているだけなんだけど、バトルがパズルなんだよねこれ。

www.youtube.com

​

どういうルールなの？

​

敵をスライドさせて、どちらかのパターンを作る。

❶ 敵4体の塊を1列に整列させる

❷ ステージの内周に2行2列に整列させる

​

ふむ。

​

きちんと揃えないと、マリオの攻撃が届かないんだよ。

​

子供向けのゲームだろうし、じっくり考えればいけそうだね。

​

ところが、時間制限と回数制限があって、熟考もできなければ試行錯誤もできない。

ロジカルな思考力だけじゃなく、ひらめきも大事。

これを30秒以内に閃いて解けといわれたら、解けない自信がある。

時間制限があると、「既に出来上がっているものを壊したくない心理」が勝ってしまうのだ。

納期ギリギリで、品質はクソだけどせっかくここまでプログラムができてるからなんとか既存部を生かそうとして、結局死ぬパターンに似ている。

— たーせる (@tercel_s) August 8, 2020

​

なにこれむずいじゃん。

​

むずかしいよ。

ザコ戦のバトルが毎回コレなので、なんとかコンピュータにパズルを解かせることはできないかなと思って、ちょっと考えてみたんだ。

ペーパーマリオ オリガミキング ザコ戦パズル解法アルゴリズム（草案）

​

なにこれ……やば。

​

やばくないよ。

基本情報技術者試験によく出る探索アルゴリズムを応用したものだよ。

​

こういう探索アルゴリズムってどうやって実装するの？

for ループだとネストがどんどん深くなりそう。

​

こういうのは for 文で書いちゃダメで、再帰処理を使って実装するんだよ。

プログラミング言語の入門書にはあまり載っていないテクニックで、どちらかというとアルゴリズムとデータ構造の本によく出てくるね。

​

再帰処理かー……。

あれって鬼門だよね。 苦手な学生も多かったし……。

​

機会があれば、実装例も載せて再帰処理の勘所を紹介したいのだけど、あいにく身に付けたところで使いどころが限られているからね、、、

再帰的データ構造と Composite パターン

​

再帰処理と相性のよいデータ構造には、木やグラフといったデータ構造があるよ。

​

あるね。

配列やリストは、データ同士の繋がりも分かりやすいし、多くのプログラム言語がサポートしているけど、木構造のデータってどう表現するの？

​

それについては昔、すごい雑な記事を書いた気がする……。

tercel-tech.hatenablog.com

​

構文として木構造をサポートしている言語は無いの？

​

Lisp とかはサポートしてた気がする……。

そういえば、Common Lisp では、実行時のパフォーマンスを上げるために、再帰呼び出しが関数の末尾にくるように最適化したりするけど、まぁその話は今関係ないからいいや。

​

もっとメジャーな言語でお願いします。

​

それでいうと、C++とかJavaとか、その派生言語であれば「再帰的なデータ構造はこうやってクラス設計しましょう」という方法論は確立されているよ。

Composite パターンって言うんだ。

​

なるほど。

​

このへんをしっかり学びたければ、デザインパターンの本を読んでみよう。

最近は拡大解釈され過ぎて、「インフラデザインパターン」とか「クラウドデザインパターン」とかネコも杓子もデザインパターンという用語が濫用されがちだけど、ここでは「オブジェクト指向における再利用のためのデザインパターン」だよ。

​

ソフトウェア工学の分野のデザインパターンだね。

​

というか、マリオの話をしていたはずなのにどうしてここまで脱線したのか。

​

いつもの事だね。

おまけ

​

ペーパーマリオ、ストーリーが素晴らしくて、ラストでうるっときました。

危うく泣くところでした。