+ 「自在化身体論」の読書感想文
+ https://future-architect.github.io/articles/20231109a/
+ 2023-11-08T15:00:00.000Z
+ 2023-11-09T00:34:46.466Z
+
+ はじめに こんにちは、2022年4月新卒入社、金融グループ所属の森です。
秋のブログ週間2023 2週目の記事として、自在化身体論 の感想文を掲載します。
私はフロントエンドやアルゴリズム関連の書籍を読むことが多いのですが、読書の秋！ということで、思い切って普段は読まないような分野の本を手に取ってみました。
本の概要 「自在化身体」という概念や、それに関する研究、技術についての本です。
「 機械によって拡張された能力を、人が自在に扱えること」
想像しやすいところで言えば、人間の筋力を増強する「パワードスーツ」などが「自在化身体」の一つと言えるでしょう。
しかし、ロボットによる人体の拡張に限らず、バーチャル世界での身体、ひとりで複数の身体を扱うこと、逆に複数人でひとつの身体を制御することなど、「自在化身体」の様々な在り方が紹介されていきます。
章立てです。
各章で「自在化身体」の各研究グループのリーダーが自身の経歴や研究の内容、将来像について紹介していく形式になっています。
第1章 変身・分身・合体まで ― 自在化身体が作る人類の未来 第2章 身体の束縛から人を開放したい ― コミュニケーションの変革も 第3章 拡張身体の内部表現を通して脳に潜む謎を暴きたい 第4章 自在化身体は第4世代ロボット ― 神経科学で境界を超える 第5章 今役立つロボットで自在化を促す ― 飛び込んでみないと自分はわからない 第6章 バーチャル環境を活用した身体自在化とその限界を探る 第7章 柔軟な人間と機械との融合 第8章 情報的身体変工としての自在化技術 ― 美的価値と社会的倫理観の醸成に向けて 感想 「パワードスーツ」のような、ロボット工学の話題を中心に構成されていると思っていましたが、バーチャル空間上での身体についての研究や、心理学、脳科学の知見を利用した自在化身体の応用、自在化身体と美的感覚、倫理観の関係など非常に幅広い話題があり驚かされました。
興味深く感じた話題について紹介します。
自在と自動 「自在化」において大切なことは、あくまで人間に新しい能力を授けることだとされています。
書籍では自動運転技術とドラえもんのタケコプターを比較して説明しています。どちらの技術でもユーザーは移動という目的を達成できますが、自在化で目指すのはタケコプターのように人間に移動能力を付加することです。
あくまで主体は人間であるという点と、行動の結果のみを重要視しているわけではない点に、単に利便性のための技術にとどまらない可能性を感じて好印象でした。
第3の腕 ロボットハンドを体に装着し自由自在に扱えるようにする研究や、ロボットハンドを自身の体から離れたところに設置し動かす研究が紹介されていました。
ロボットハンドを遠隔操作する場合、操作している腕の位置や角度に応じて操作者の背中に刺激を与えると作業効率が上がる実験結果が得られているそうです。
ロボットハンドという本来自分の体にないパーツからのフィードバックに脳が対応できる点が非常に興味深かったです。
この他にも人間の適応能力の高さを利用した研究や、逆に脳がどれだけの身体拡張を許容できるのか調べる研究についても紹介されていました。
身体感覚の編集 モーションキャプチャでユーザーの全身の動きを取得し、VR空間上のアバターの動きに反映させるシステムを用いた実験が紹介されていました。
ユーザーはヘッドマウントディスプレイを通してVR空間上で自身の動きをリアルタイムに観測します。ここで、アバターの表示に遅延を入れる、もしくはアバターの次の動きを予測し、数フレーム先の動作を表示すると、ユーザーは「体が重い」もしくは「体が軽い」という感覚を得るそうです。
アバターという拡張された身体を経由することで人間の感覚の制御ができる、という話を聞くと、いずれ自身の思い通りに感覚を制御しながら生活ができるのでは？と夢が広がりますね！
さいごに 自分にとって初めての概念が多く登場する本でしたが、具体的な研究内容の紹介や図表による説明が十分にあったため、あまり困ることなく読み進めることができました。
子供の頃に夢見たSFの世界がすぐそこに迫っている事実にワクワクが止まりません。（書籍の内容ではありませんが、自在化身体研究プロジェクトで作成された自在肢 がカッコイイ…）
SFが好きな方、VR、ロボット工学、心理学、脳科学に興味がある方など様々な人にオススメできる本です。
]]><a href="https://www.amazon.co.jp//dp/4860436857">
+<img src="/images/20231109a/jisai.jpg" alt="" width="499" height="543">
+</a>
+
+<h1
+
+
+
+
+
+
+
土地勘に頼らずに地の利がある場所をみつける方法
https://future-architect.github.io/articles/20231108a/
2023-11-07T15:00:00.000Z
- 2023-11-08T00:26:31.452Z
+ 2023-11-09T00:35:47.375Z
- 本記事は「秋のブログ週間2023 」2週目の記事です。
はじめに 旅行をするときや引っ越しをするとき、周辺の商業地域や、観光地にアクセスのよい「地の利」のある場所を探したいですよね？
「地の利」がある場所を探すには、インターネットで調べるか、長らくその地域に住んでいて土地勘のある人に聞くのが一般的ではないでしょうか。
今回は、数理的なアプローチで「地の利」の良い場所を見つける方法 を紹介します。
本記事は都市と地域を数理的に分析する楽しさ を伝えたいという気持ちと、共著『スマートモビリティ時代の地域とクルマ 』を手にとってくれる方が一人でも増えるといいなという邪な気持ちで書いております。
地利値とは アクセシビリティは、電車などのモビリティの発達や、山や川などの自然環境に左右されますが、今回は汎用的な議論を可能にするため、シンプルに地域と地域の隣接関係 のみに着目します。
例えば、下図のような３つの隣り合うまちがあるときを考えます。
「この３つのまちから住む場所を選んでください」と命令された場合、真ん中のＢ市がなんとなく「地の利」がある気がしませんか？
この「なんとなく地の利あるが気がする感覚」を定量化するために「地利値」という概念を用います。詳細は省きますが、下図のような基礎的なグラフ理論 で算出できます。
例で示した３つの隣り合うまちの場合、B市の地利値が「1.0」で最も高く、地の利のある場所であることが分かります。
参考として、他の単純な例も示します。
このように、あるまち（＝交通の結節点）を頂点、まちをつなぐ道を辺としたグラフの隣接行列の最大固有値に属する固有ベクトルを地利値といいます。 今回は難しいことは考えずに、いろいろな地域の地利値を算出して遊んでみましょう。
地利値で遊んでみる それでは実際の地域に地利値を当てはめてみます。例えば、私の卒業した大学がある茨城県の市町村 で考えると、地利値の高い市はどこになるでしょうか？県庁所在地の水戸市でしょうか？
上図のように茨城県で地利値がもっとも高い市はつくば市 となりました。
つくば市は2023年の調査では人口増加率が全国トップの2.30%という数字でした1
地利値を算出するのに鉄道網や経済指標などは加味していませんが、土地勘のある人にとってもある程度納得できる結果なのではないでしょうか？
他の地域でも地利値を見てみます。例えば私の地元、岩手県。
県庁所在地である盛岡市 の地利値がもっとも大きくなります。盛岡市は県央に位置しており、周辺市町村からたくさんの人が働きにくる都市です。
秋田県と並べてみても盛岡市 の地利値が一番大きいです。西側が海に面している秋田市と比べて地の利があるのは盛岡市なのかもしれません。
九州に飛んで長崎県ではどうでしょう？
佐世保市 です。Googleで検索すると、県庁所在地である長崎市との対決をあおる記事2
九州地方で地利値がもっとも高い場所は福岡県飯塚市 です。これだけだと少し感覚と外れるかもしれませんが、九州全体でみると地利値が高い地域は福岡県に集中 しており、政令指定都市2市が位置する福岡県の地の利が読み取れます。
最後に、全国の市町村で比べてみた時、最も地利値が大きい場所はどこでしょうか？
ぐちゃっとしていて分かりづらいですが、長野県松本市 です。松本市と言えば、松本城がありますが、日本で最も地の利がある市と言われてもピンと来ないかもしれません。
気になる方は松本市の地利値が最も高くなる理由を考えてみてください（投げっぱなし）。
まとめ 本記事では、土地勘に頼らずに地の利がある場所をみつけられる「地利値 」という概念を紹介しました。
グラフの中心性を図る尺度は他にも様々ありますし3
地図は眺めたり、分析したりすることで、いつも新しい発見を得られます。本記事を読んで興味を持った方はぜひ探求してみてください。
共著『スマートモビリティ時代の地域とクルマ 』では、（地利値は出てきませんが）都市と地域の課題を数理的アプローチで分析/解決しています。秋の読書候補におすすめです。
また、本記事冒頭のイラストはBingのImage Creatorによって生成したものです。
参考 野田 洋:街路網の形態的特性に基づく定量的地利値の導入とその基礎的考察化 大澤 義明, 林 利充:隣接グラフと地利値最大化 R.J. ウィルソン:グラフ理論入門
]]>本記事は「秋のブログ週間2023 」2週目の記事です。
はじめに 旅行をするときや引っ越しをするとき、周辺の商業地域や、観光地にアクセスのよい「地の利」のある場所を探したいですよね？
「地の利」がある場所を探すには、インターネットで調べるか、長らくその地域に住んでいて土地勘のある人に聞くのが一般的ではないでしょうか。
今回は、数理的なアプローチで「地の利」の良い場所を見つける方法 を紹介します。
本記事は都市と地域を数理的に分析する楽しさ を伝えたいという気持ちと、共著『スマートモビリティ時代の地域とクルマ 』を手にとってくれる方が一人でも増えるといいなという邪な気持ちで書いております。
地利値とは アクセシビリティは、電車などのモビリティの発達や、山や川などの自然環境に左右されますが、今回は汎用的な議論を可能にするため、シンプルに地域と地域の隣接関係 のみに着目します。
例えば、下図のような３つの隣り合うまちがあるときを考えます。
「この３つのまちから住む場所を選んでください」と命令された場合、真ん中のＢ市がなんとなく「地の利」がある気がしませんか？
この「なんとなく地の利あるが気がする感覚」を定量化するために「地利値」という概念を用います。詳細は省きますが、下図のような基礎的なグラフ理論 で算出できます。
例で示した３つの隣り合うまちの場合、B市の地利値が「1.0」で最も高く、地の利のある場所であることが分かります。
参考として、他の単純な例も示します。
このように、あるまち（＝交通の結節点）を頂点、まちをつなぐ道を辺としたグラフの隣接行列の最大固有値に属する固有ベクトルを地利値といいます。 今回は難しいことは考えずに、いろいろな地域の地利値を算出して遊んでみましょう。
地利値で遊んでみる それでは実際の地域に地利値を当てはめてみます。例えば、私の卒業した大学がある茨城県の市町村 で考えると、地利値の高い市はどこになるでしょうか？県庁所在地の水戸市でしょうか？
上図のように茨城県で地利値がもっとも高い市はつくば市 となりました。
つくば市は2023年の調査では人口増加率が全国トップの2.30%という数字でした1
地利値を算出するのに鉄道網や経済指標などは加味していませんが、土地勘のある人にとってもある程度納得できる結果なのではないでしょうか？
他の地域でも地利値を見てみます。例えば私の地元、岩手県。
県庁所在地である盛岡市 の地利値がもっとも大きくなります。盛岡市は県央に位置しており、周辺市町村からたくさんの人が働きにくる都市です。
秋田県と並べてみても盛岡市 の地利値が一番大きいです。西側が海に面している秋田市と比べて地の利があるのは盛岡市なのかもしれません。
九州に飛んで長崎県ではどうでしょう？
佐世保市 です。Googleで検索すると、県庁所在地である長崎市との対決をあおる記事2
九州地方で地利値がもっとも高い場所は福岡県飯塚市 です。これだけだと少し感覚と外れるかもしれませんが、九州全体でみると地利値が高い地域は福岡県に集中 しており、政令指定都市2市が位置する福岡県の地の利が読み取れます。
最後に、全国の市町村で比べてみた時、最も地利値が大きい場所はどこでしょうか？
ぐちゃっとしていて分かりづらいですが、長野県松本市 です。松本市と言えば、松本城がありますが、日本で最も地の利がある市と言われてもピンと来ないかもしれません。
気になる方は松本市の地利値が最も高くなる理由を考えてみてください（投げっぱなし）。
まとめ 本記事では、土地勘に頼らずに地の利がある場所をみつけられる「地利値 」という概念を紹介しました。
グラフの中心性を図る尺度は他にも様々ありますし3
地図は眺めたり、分析したりすることで、いつも新しい発見を得られます。本記事を読んで興味を持った方はぜひ探求してみてください。
共著『スマートモビリティ時代の地域とクルマ 』では、（地利値は出てきませんが）都市と地域の課題を数理的アプローチで分析/解決しています。秋の読書候補におすすめです。
また、本記事冒頭のイラストはBingのImage Creatorによって生成したものです。
次は森さんの「自在化身体論」の読書感想文 です。
参考 野田 洋:街路網の形態的特性に基づく定量的地利値の導入とその基礎的考察化 大澤 義明, 林 利充:隣接グラフと地利値最大化 R.J. ウィルソン:グラフ理論入門
]]>https://future-architect.github.io/articles/20231030a/
2023-10-29T15:00:00.000Z
- 2023-11-08T00:24:07.460Z
+ 2023-11-09T00:35:36.434Z
- はじめに TIG 真野です。
10/31より秋のブログ週間というブログリレーを始めます。この記事はそのインデックスです。
秋のブログ週間とは 2020年から始まったブログリレーの企画です。元ネタは、秋の読書週間（文化の日を中心とした10/27〜11/9の2週間）です。これに合わせて、平日にブログ記事を投稿していこうというブログリレーなイベントです。
「春の入門祭り」、「夏の自由研究」、「秋のブログ週間」、「冬のアドベントカレンダー」と四季の名を冠に持つ、フューチャー技術ブログ4大ブログリレーの1つと言われています。
テーマは秋の読書週間のイメージで、普段のソースコードがでてくる技術記事ではなく、ソファーでゆっくり読めるような、読み物（エッセー）よりの記事を書いていこう、としています。元ネタが読書週間ですし、積読消化を進めるための書評記事もOKとしています。気になるタイトルの記事を読んで読書欲を刺激していきましょう。
12月にはお馴染みQiitaさんのアドベントカレンダーにも参加したいと思いますので、秋のブログ週間はちょうどその中間のまったりとした、秋の夜長を楽しむためにも読み物成分を中心として楽しんでいただければです。
過去のインデックスのリンクはこちらです。
スケジュール 2023年は曜日の区切り的に、10/30（月）から開始することになりました。例年になく活況で参加者が多いです。
さいごに いつもはコードが本文に書かれていることも多いフューチャー技術ブログですが、この連載はスマホ片手で読めるような記事成分を高めたいと思います。約3週間+αですがどうぞお付き合いください。
アイキャッチ画像はS. Hermann / F. Richter from Pixabay を利用させていただきました。
]]>はじめに TIG 真野です。
10/31より秋のブログ週間というブログリレーを始めます。この記事はそのインデックスです。
秋のブログ週間とは 2020年から始まったブログリレーの企画です。元ネタは、秋の読書週間（文化の日を中心とした10/27〜11/9の2週間）です。これに合わせて、平日にブログ記事を投稿していこうというブログリレーなイベントです。
「春の入門祭り」、「夏の自由研究」、「秋のブログ週間」、「冬のアドベントカレンダー」と四季の名を冠に持つ、フューチャー技術ブログ4大ブログリレーの1つと言われています。
テーマは秋の読書週間のイメージで、普段のソースコードがでてくる技術記事ではなく、ソファーでゆっくり読めるような、読み物（エッセー）よりの記事を書いていこう、としています。元ネタが読書週間ですし、積読消化を進めるための書評記事もOKとしています。気になるタイトルの記事を読んで読書欲を刺激していきましょう。
12月にはお馴染みQiitaさんのアドベントカレンダーにも参加したいと思いますので、秋のブログ週間はちょうどその中間のまったりとした、秋の夜長を楽しむためにも読み物成分を中心として楽しんでいただければです。
過去のインデックスのリンクはこちらです。
スケジュール 2023年は曜日の区切り的に、10/30（月）から開始することになりました。例年になく活況で参加者が多いです。
さいごに いつもはコードが本文に書かれていることも多いフューチャー技術ブログですが、この連載はスマホ片手で読めるような記事成分を高めたいと思います。約3週間+αですがどうぞお付き合いください。
アイキャッチ画像はS. Hermann / F. Richter from Pixabay を利用させていただきました。
]]>
-
- ChatGPTでE2Eテストコード自動作成
- https://future-architect.github.io/articles/20230925a/
- 2023-09-24T15:00:00.000Z
- 2023-10-16T06:33:02.876Z
-
- 9/7に行われた技育CAMPアカデミアというイベントでPlaywrightについて話をしてきました。テストというと、設計手法であるところのテスト駆動開発は別としてちょっと業務っぽい感じがして学生さんにはちょっと響かないかな、というのも心配でしたが、アンケートを見る限り、わかりやすかったという声も多くてほっとしました。
次のスライドが今回の資料です。スライドの内容の多くはPlaywright連載始まります に掲載されている記事にもぼつぼつある内容も多い（APIテストはないですが）のですが、本エントリーでは発表の最後に触れたChatGPTなどの生成AIを使ったE2Eテストの生成について説明していきます。
ChatGPTが話題を席巻してしばらく経ちます。とはいえ、内製開発での利用以外はソースコード開発にばりばり使う、みたいな宣言はあまり聞かない気がします。利用を制限している会社も数多くあります。
生成AIを使うかどうか判断の分かれ目になりそうな問題としては大きく３つあるように思います。これ以外にも書かれた内容の品質担保もありますが、利用側の努力だけでは厳しい内容がこの3つかな、と。このあたり、業界団体か法律の専門家がバシッと白黒つけてくれれば利用は進みそうな気がしますが、もうちょっと待ちですかね。
生成した著作物の著作権 生成の過程で機密情報をアップロードする問題 生成したものが既存の著作物に似てしまって問題になる可能性 現在の著作権法では、生成AIの成果物には著作権が及ばないため、納品物として出して対価をもらうものに対して使うのは厳しいですね。自分の著作物じゃないものですからね。OSSの開発も基本的にソースコードの著作権が自分にある前提でその利用の自由を決めるものなのでOSS開発にも使えなそうです。そうなると内製開発ぐらいしか残らないのかな、と。
2つめは学習データに使うオプションのオプトアウトとかAPI利用とかでだいぶ緩和された感じがありますが、無料版のChatGPTとかBing Chatを使うと問題がありそうなので企業のガイドライン整備みたいな話でまとまりそうな気はします。
3つめに関しては、GitHubは損害が発生したら保証するというライセンスになっていますが、しかし実際に訴訟が起きてどれぐらいで保証されるのかなど、実際に裁判が起こってみないとこには、どれぐらい裁判に時間がかかるのかなどビジネスのダメージわからないことが多いですよね。
プログラム以外だと特化AIの学習素材の権利侵害とか、他者著作物をアップロードする問題とかありますがプログラムにはあまりない気がします。このあたりは素人判断は危ないので、専門家が書いてくれたブログとかが参考になります。
そんなこんなで、生成AIの利用としては、現状は成果物を作るためのアドバイスをもらう用途が無難と言えます。そうなると、テストコードなら良さそうです。ソフトウェアの品質はテストコードに宿るのではなく、あくまでもコードに宿るものであり、テストは品質の悪化を見つけるための手段です。実際の成果物のソースコードには生成結果は含まれません。
まあテストのうち、設計ドキュメントも兼ねているようなアジャイル開発のユニットテストコードは使わない方が良いかもしれません。火事になったら製品コードではなくテストコードを持って逃げろ、というぐらいテストコードそのものが大事という文化なので。
生成されたものは自分の著作物ではないので、テストコードには「ChatGPTで生成しました」みたいな引用元を書いて引用として扱うとさらに安全なのではないかと思います。他者著作物の利用の手段として。
PlaywrightのE2Eテストを生成してみる 本ブログでもすでにCypressの記事が何本かあったり、Software DesignでCypress連載 をしたり、Playwright連載 をおこなったり、E2Eテストについてはかなり触れています。
E2EテストはEnd to Endの意味です。まあAPIで提供するサービスであればEはAPIになるとは思いますが、ここでは最終的にできあがったウェブアプリケーションをブラウザで操作するテストのことをE2Eと呼んでいます。早速やってみましょう。pageオブジェクトについての文がないとテストコード形式ではないものが出てくるので追加しました。
次のHTMLに対してPlaywrightでフォームを埋めて送信ボタンを押すテストコードを書いてください。pageオブジェクトはtestの第二引数から取得してください。 ``` <form action="login.php" method="post"> <label for="username">Username:</label> <input type="text" id="username" name="username" required> <label for="password">Password:</label> <input type="password" id="password" name="password" required> <input type="submit" value="Login"> </form> ```
このHTMLは実際の本物のフォームである必要はなく、セマンティック要素(aタグ、buttonタグ、formタグ、labelタグ、mainタグ、navタグ、articleタグ)ぐらいだけに整理して、id属性とかCSSとか全部とっぱらったシンプルなHTMLを作って入力にする方が良いでしょう。
生成されたコードは以下の通りです。
const { test, expect } = require ('@playwright/test' );test ('フォーム送信テスト' , async ({ page }) => { await page.goto ('URLをここに入力' ); await page.fill ('input[name="username"]' , 'ユーザー名をここに入力' ); await page.fill ('input[name="password"]' , 'パスワードをここに入力' ); await page.click ('input[type="submit"]' ); await expect (page).toHaveText ('ログイン成功のメッセージをここに入力' ); });
CSSセレクターを使ってしまっているのがいまいちですね。
「ブラウザを操作」といっても、ある程度HTMLを理解した上でテストコードを書く必要があります。Playwrightは標準で、getByLabel()とかgetByRole()というAPIを持っています。Cypressは@testing-library/cypress という追加ライブラリがあります。過去のブログで書いたように、これらを使うとHTMLのセレクターではなく、「ユーザーから見た見た目」に近いテストコードが書けるようになり、より抽象度が高くなって壊れにくくなります。
とはいうものの、 “要素選択はCSSセレクタを使わずにgetByRole、getByLabelなどをなるべく使って書き換えてください” というのを書いても、5回に1回ぐらいしかなかなか書いてくれないですね。うまく行った時のコードはこんな感じです。
const usernameInput = await page.getByLabel ('Username:' );await usernameInput.fill ('your_username' ); const passwordInput = await page.getByLabel ('Password:' );await passwordInput.fill ('your_password' ); const submitButton = await page.getByRole ('button' , { name : 'Login' });await submitButton.click ()
ここは手修正する必要がありそうです。BardとかBing Chatを使ってもだいたい同じでしたが、Bing Chatは「getByRole、getByLabelを使って書き換えてください」というと、そこそこの打率で書き換えてくれましたが、たまに公式の1.27から提供されたAPIではなく@testing-library/playwright ベースのコードを出力することもありました。独創的、バランス、安定問わず。
Cypress向けはどうか？ 実はCypress向けだとばっちり決まります。
次のHTMLに対してCypressでフォームを埋めて送信ボタンを押すテストコードを書いてください。testing-library/cypressを使ってください
import '@testing-library/cypress/add-commands' ;describe ('Login Form' , () => { it ('should fill out the form and submit' , () => { cy.visit ('/' ); cy.findByLabelText ('Username:' ).type ('your-username' ); cy.findByLabelText ('Password:' ).type ('your-password' ); cy.findByText ('Login' ).click (); }); });
いい感じですね。このまま使えそうな勢い。Cypressはずっと安定したAPIを提供し、Playwrightはアクティブに機能追加したりしている印象がありますが、これが生成AI経由に使い勝手に影響を与えるというのはなかなか興味深い結果です。
まとめ Playwrightの方がちょっとイマイチでしたが、将来性は感じる結果は得られました。HTMLを渡すだけでそれを操作するコードを書いてくれました。Cypressはばっちりでしたので、いっそのことPlaywrightでテストを書く場合に、Cypress向けに生成したコードを何かしらのスクリプトで書き換えて使う方が良いかもしれません。
今回はログインフォームだけですが、より複雑なフォームやメニュー選択なども作ってくれるでしょうし、入力パラメータをテーブルにしておいて、複数のケースをまとめて生成とかもやってくれそうです。「こうしたい」という自然言語で書かれた仕様書とHTMLを渡せばある程度作ってくれる見込みはありそうなので、うまく使えばテストコードを量産する手間は少し減らせそうです。
もちろん、知識ゼロでいきなりできるかというと、やはりある程度知識がある人じゃないと使いこなせない感じはありました。
]]><img src="/images/20230925a/mv_logo.png" alt="" width="510"
-
-
-
-
-
-
-
diff --git a/authors/MaineK00n/index.html b/authors/MaineK00n/index.html
index 50632eb6f58e..42b15874c1d3 100644
--- a/authors/MaineK00n/index.html
+++ b/authors/MaineK00n/index.html
@@ -231,21 +231,21 @@ 
+
+
+
.png)
.png)
.png)