AIKATSU GENERATIONで誰が一番登場するのか
「アイカツ！」シリーズの歌唱担当のグループ「STAR☆ANIS」と「AIKATSU☆STARS!」の合同楽曲「AIKATSU GENERATION」のMVが公開されてます！
初のMVだけど、これで最後の曲なんだなと思うと悲しい。
「アイカツ！」シリーズはこれからも続いていくという前向きな歌詞と、最後に画面から去っているメンバーの姿の相反する感じは、「アイカツ！」シリースを今まで見てきた人には寂寥感があるんじゃないかって思う。
最初で最後のMV（今のところ）なので、何かしたいと思って、MV中にメンバーがそれぞれ何秒映っていたのかをまとめることにする。
映っている時間の大小によってグループの中での地位とかそういうことはないです。念のため。
メンバー別のMV出演時間一覧
・MV中で衣装の端でも映っていれば映っているとカウントしてます。
・目で振り分けているのでおおよその値です。
全体のベスト3は歴代主人公
想像通り遠藤瑠香（るか）の登場時間が一番多く約192秒。3分程度。
るかは「STAR☆ANIS」と「AIKATSU☆STARS!」両方に所属しているので、両方のグループの集合にいるというのが大きい要素だと思う。
るかは『アイカツ！』で大空あかりの歌唱担当だったり、「AIKATSU☆STARS!」のリーダーでもあったので、このコンテンツの貢献度としてはトップで当然かなって。
4位までみると「アイカツ！」シリーズの歴代主人公に続いてレジェンドアイドル神崎美月が並んでいて納得感ある。
中間値と平均値
大体170秒程度なので、それよりも少ない人はあまり映っていない。フォーメーション的に一番外側だったりするのが要因かと。
個人は藤城リエが上位に食い込む
最初に見たときに藤城リエ（りえ）よく出てきてるなあって思ったんだけど、数値に出すと、るかに続く2位。
るかは上で書いたように個人でも1位なのは、予想できたんだけど、りえは予想外。
中間値と平均値
8秒よりも少ないと個人ではあまり出てない。天音みほ（みほ）と愛野えり（えり）はもうちょい出してもよかったのでは……。
MV中のメンバーのコメント
ぜひ見てほしいので、キャプチャを張っておく。怒られたら消す。霧島若歌
上花楓裏
ささかまリス子
美谷玲実
愛野えり
市倉有菜
遠藤瑠香
未来みき
天音みほ
松岡ななせ
星咲花那
堀越せな
藤城リエ
さいごに
これを算出するのにMVを1秒単位で確認していたんだけど、霧島若歌（わか）と市倉有菜（ゆな）がメンバーの中で背が高いほうで分かりやすかった半面、2人の後ろに隠れるメンバーは全くわからなくなるので、カウントできなかった。Redshift COPYで改行を含むデータをロードする
以下のようなRedshift COPYコマンドでロードしようとした際に、取り込もうとしたデータに改行が含まれていた場合「Delimited value missing end quote」エラーになってしまって困った。
COPY [table-name] FROM 's3://[bucket-name]/xxx/yyyy/' CREDENTIALS 'aws_access_key_id=[aws_access_key_id];aws_secret_access_key=[aws_secret_access_key]' DELIMITER '\t' TIMEFORMAT 'YYYYMMDDHH24MISS' EMPTYASNULL REMOVEQUOTES gzip;
DELIMITER：タブ区切り
TIMEFORMAT：時刻は'YYYYMMDDHH24MISS' 形式
EMPTYASNULL：空白はNULLとする
REMOVEQUOTES：クォーテーションは省く*1
gzip:gzip形式を読み込む
これってデータが
'改行ｺｺｶﾗ ｺｺﾏﾃﾞ',
みたいになっていて、ロードしようとした際REMOVEQUOTESオプションでクォーテーションを外そうとするけど、改行されているから最後のクォーテーションが読めなくてエラーになっているみたいな感じだと思っている。
だったら、単純にESCAPEオプションを追加したらいいんじゃない？って単純に思ってたんだけど「Delimited value missing end quote」エラーは変わらず。どうなってんじゃ
COPY [table-name] FROM 's3://[bucket-name]/xxx/yyyy/' CREDENTIALS 'aws_access_key_id=[aws_access_key_id];aws_secret_access_key=[aws_secret_access_key]' DELIMITER '\t' TIMEFORMAT 'YYYYMMDDHH24MISS' EMPTYASNULL REMOVEQUOTES ESCAPE gzip;
でもってよくよく調べてみるとESCAPEコマンドの対象になるのはバックスラッシュが事前に入っていないと駄目なのね。
こんな感じ。
\'改行ｺｺｶﾗ ｺｺﾏﾃﾞ',
www.slideshare.net
上記35ページ目
でもこれ、実際に業務で使用した際に他システムから連携されるデータに改行されたデータがあった場合、事前にエスケープを入れる（対向orこちら）しか方法がない。
数件とかならいいんだけど、数百万件データを一気にエスケープするのはちょっと大変だなーと。
パラメータだけで改行エスケープできる何かうまい方法あればいいんだけどねえ。
アイカツフレンズ！で解禁された情報で思ったこと
この動画の感慨深さがやばい。*1
アイカツ！シリーズ バトンタッチPV
『アイカツフレンズ！』のキャスト・スタッフ等の情報が解禁
情報が解禁されていよいよ『アイカツスターズ！』が終わるんだなあと。
キャスト・スタッフ情報自体は、ソレイユの中の人、諸星すみれさん、田所あずささん、大橋彩香さんの3人が続投して、いよいよ「アイカツ！」といえばこの人達！な感じになってきたなというくらいの印象。
それよりも『アイカツ！』、『アイカツスターズ！』の歌唱担当を務めていたSTAR☆ANISとAIKATSU☆STARS！のシリーズ卒業のほうが驚いた。
新メンバー追加して、遠藤瑠香さんあたりは抜けるのかなとは思っていたけどまさかの全員卒業とは。
卒業ということで、実質今年のライブ、「アイカツ！ミュージックフェスタ2018」の武道館公演がラストライブになるという。悲しみがすごい。
何故STAR☆ANISとAIKATSU☆STARS！が一律で卒業なのだろうかと邪推
以下何の根拠もないただの推論です。
彼女たちが所属するディアステージとの契約を継続しないのだなっていうのが、まあ当たり前の反応だと思う。
ただ前作の歌唱担当のAIKATSU☆STARS！まで卒業するというのは、契約のコストが高かったということなのだろうか。
そういう政治的・経済的な問題は自分には分かりかねるので、CD売上だけの面で見る。
今回大きく変わったなと思うのは、歌唱担当が声優になったということだと思っている
主題歌
オープニングテーマ「ありがと⇔大丈夫」
歌 - あいね・みお from BEST FRIENDS!［友希あいね（松永あかね）、湊みお（木戸衣吹）］
エンディングテーマ「Believe it」
歌 - カレン・ミライ from BEST FRIENDS!［神城カレン（田所あずさ）、明日香ミライ（大橋彩香）］
なぜわざわざ声優と歌唱担当を同じにしたのかって「中の人が歌も歌えばCDが売れるだろう」ということなんじゃないかと。
以前、「アイカツ！」シリーズと『プリパラ』のCD売上分析をやったときに『プリパラ』の売上を見たときに特徴的だなっていうのがあった。
それは売上枚数トップ10がほぼi☆Risで占められていて、i☆Ris名義とそれ以外でかなり売上差があるように見えたということ。
その状態を見るに、低迷していたCD売上の打開策として歌唱担当と声を統一するということなんじゃないかと思う。
これについてはただの妄想なので、『アイカツフレンズ！』のCD売上は注視して、本当にこの仮説が立証されているのかは見る必要がある。
まあ中の人が歌ってればな的な発言をネットで散見されていたし、今までの歌唱担当と中の人が違うスタイルは珍しかったと思うので、オーソドックスになったという感じなのか。
歌唱担当と声優が違うスタイルの利点は、ライブ会場ではない子供を対象としたステージでも（いろいろな意味で）問題なかったというのもあるし、スケジュール的やクオリティ的にもある程度専門性を持たせたほうが安定するだろうという感じなのかもしれない。*2
未来向きの今をちゃんと見届けよう
ともかくラストライブになるアイカツ！ミュージックフェスタ2018の武道館公演はお通夜ではなく、STAR☆ANISとAIKATSU☆STARS！の未来向きの今をちゃんと見届けるということなんだと思う。俺も武道館2daysは有給とって北海道から行きます！2日共参加します！
ANACONDAでpython実装環境を構築しよう
PCを買い替えたので、環境整備ついでにANACONDAの導入方法をまとめておく。 これをやっておくと、とりあえずJupyter Notebookでpython実装できるようになる。 pythonを始めたい人ファーストステップがANCONDAの導入だと思うので、極力丁寧に書きたい。*1 目次
そもそもANACONDAとは
まあこの辺に書いてあることではある。 programming-study.com ざっくりいうとpython用の環境を構築できるディシュトリビューションのひとつ。
ANACONDAをインストール～Jupyter Notebookで実装できるまで
ANACONDAをダウンロード
以下からダウンロードする。
Downloads - Anaconda
このときpythonのバージョンが3.X(3以降)と2.7があるけど、基本的には3.Xをダウンロードする。
近々2.7系はサポートしなくなるので、どうしても必要でない限りは選ばないほうが良いかと。
ANACONDAをインストール
ダウンロードしたexeファイルを実行。
基本的にはダイアログに合わせていけばOK。
ボタン「Next」をクリック
ボタン「I Agree」をクリック
特に何もなければrecommendedにチェックしてボタン「Next」をクリック
インストールしたい場所を選んでボタン「Next」をクリック
インストールされるの待つ。
jupyter notebookを起動
スタートからAnaconda3 > Jupyter notebookをクリック
コンソールが立ち上がって、それからちょっとするとウェブサイトに新しい画面が表示される。これがJupyter notebook。
Newから「Python3」をクリックする。
実装しましょう。
ライブラリをインストールする
ANACONDAは大体必要なライブラリはすでに入っているんだけど、使いたいなってライブラリがない場合もある。
その場合は、installする必要がある。
それも基本的にはよしなにやってくれるので、よしなにやってくれる手順を書いておく。
スタートからAnaconda3 > Anaconda Navigatorをクリック
画面が表示されたら左メニューの「Environments」を選択
今回はAWS系のライブラリのboto3をinstallしたいと思う。
boto3を検索するとチェックボックスにチェックがないので、installしていないことがわかる。
installしたいライブラリ（今回はboto3）のチェックボックスにチェックを入れて、ボタン「Apply」をクリックする。
ライブラリのinstallが終わると、関連してinstallしたライブラリと各バージョンが表示される。
installが終わったので、ライブラリにチェックがついている。
別のpythonバージョンの環境を構築する
もしpython2.7環境を作りたいとなったときに、ANACONDAの2.7バージョンを再度ダウンロードしなきゃとかしなくてもいい。
python2.7用の環境を作ってしまえばよい。
スタートからAnaconda3 > Anaconda Navigatorをクリック
画面が表示されたら左メニューの「Environments」を選択
ボタン「Create」を押下する。
（rootは最初に作成したpython3.Xバージョン）
pythonのパッケージで2.7を選択してボタン「Create」を押下する。
しばらくすると完了する。
作成した環境の「▼」からコマンドプロンプトを起動して以下コマンドをたたいてpythonのバージョンを確認する。
python -V*2
「index "pg_toast_16408_index" is not a btree」というエラーが出力する。
RedshiftにCOPYコマンドでデータを投入するとたまーに発生する「index "pg_toast_16408_index" is not a btree」というエラー。
調査
テーブルにレコードがない状態でCOPYコマンドを実行した際、ANALYZE実行されると発生するAWSのバグらしい。 *1
[COPY from s3 to redshift fails]
AWSからの回答
今回お客様環境で発生したエラーとなりますが、同様の報告は確認出来るものの、明確な再現手順が存在しないため、原因は特定出来ておりません。 しかしながら、お客様環境及びその他の事例でも再起動で解消する為、一時的なメモリ上の問題である可能性が高い状況でございます。 もし、事象が再現した場合には、先ずは再起動による対処をご検討ください。 また、もし事象の再現を明示的に行うことが可能であれば、原因追及のために調査を行うことが可能でございますので、手順等含めてご連絡頂ければ幸いでございます。
こんな感じ。レアケース系のやつ。
回避方法
とりあえず以下2パターンのうちどれかをやればよいっぽい。 1. クラスタ再起動 2. COPYコマンド実行時にオプションに[STATUPDATE off]を明示的に設定 AWSの回答的にもとりあえず１をやればよいみたいな感じ。 俺が遭遇した時もとりあえずそれでうまくいった。 ただ、これだと毎度、発生するかもしれないっていうのがリスクとして挙がるし、運用中にRedshift止めるの？って問題もある。 でも2パターンでANALYZEコマンドを実行しないようにすると、最適化が行われないのでレコード件数が増大していくと共にSQLの実行結果が返ってこない。 パフォーマンス犠牲にするぐらいならたまたま発生パターンは目をつぶるかーみたいなやつ。
www.slideshare.net
*1:COPYコマンドのオプションで何も設定していないと、初回だけANALYZEが実行される
2018年4月から『アイカツフレンズ！』がスタート
今日「アイカツ！」シリーズの最新作『アイカツフレンズ！』が発表されたので、取り急ぎ。
http://www.aikatsu.com/friends/teaser/www.aikatsu.com
プレスリリースを見る限り、ユニットがテーマみたい。
「友達と一緒にアイカツ！」をコンセプト
に、シリーズ初となる 2 人のアイドルがユニットを組んでトップアイドルを目指すストーリーです。
http://bandai-a.akamaihd.net/corp/press/100000663522818.pdf
『アイカツスターズ！』ではわりと個が強くて、ユニット要素が薄かったので、そこが強化されたのかなー。
DCDだけをみると今までいまいち薄かったフレンドのカードと一緒にユニットを組めるというところを前面に押そうとしている感じか。
バンダイの中ではおもちゃ売上というよりも完全にアパレル売上がメインにシフトしてるよなあとプレス見てやっぱり感じる。
ゲーム内で初めてルージュやチークなどのコスメア
イテムを使った演出を導入し、実際の女児用化粧品としても 2018 年 6 月より「アイカツ！」シリーズのアパレル
ショップ「アイカツ！スタイル」（http://p-bandai.jp/aikatsu-style/）で発売予定です。
http://bandai-a.akamaihd.net/corp/press/100000663522818.pdf
aikatsu! for Ledyやaikatsu! for Gentlemanみたいな大人向けも増えているし、そちら方面に舵切っている感は感じていたけど、コスメもだしてくるのかー。
強く押される要素だと思うので、アニメやゲームとどうかかわってくるのか。
CD売上だけのファクターでみると売り上げが下がっていたので、実はもうシリーズ終わりなんじゃ……と思っていたのでうれしい限り。
プリティシリーズも4月から新シリーズだし、ここから売り上げがどう変わってくるのか楽しみではある。
アジャイル開発のバッドパターン
podchastを聴いていたら、アジャイルでもなんでもバッドパターンはあまり書かれないみたいな話があったので、俺が遭遇したバッドパターンを書いておく。 speakerdeck.com podcastでこの人の話聞くとホントどうかしているわこの人って思う(褒めてる)。 ちなみにそのとき俺がやっていたのは、データレイク基盤実装のプロジェクトで、連携元との結合部のフレームワークを作っていた。 毎日チーム朝会をやっていたので、スクラム型になるのかな？ そのときに俺が思っていたことをメモしておく。
チーム間での認識齟齬と技術不足で足並みがそろわない
根本的な原因はとにかくここ。 とにかくチーム間、チーム内の連携が取れておらず、 +チーム間で個別で話し合ったことが共有されない +チーム間で話し合った内容と結果が違う、それに気づけない +チーム間の細かい状況がブラックボックス 実装だけの話ではなく、そもそもこのプロジェクト自体の根本的な問題もここのような気がする。
チーム間で個別で話し合ったことが共有されない
当人同士の秘密になってしまうやつ。 チーム間で個別で話した内容が共有されず、話した当人の個人チャットや会話で完結してしまうのでなぜそうなったのか当人しかわからない。 当人しかわからないことが正だと周りは認識して作業を進めていくので、ずれが大きくなる。 実際あったのは中のpropaty設定の実装が異なるときに、「個別でチャットしたときに認識合わせたんですけど、向こう忘れてしまったのかな」みたいな。 それってチャットの中で完結してよかったの？ 相手方チームと自分が他チームと共有しなくてよかったの？ 短いスパンで小さく作っていくというアジャイルの特性上、スピード感もって作業するというのは正しい動きだと思っている。 ただ自分の作業タイミングと相手の作業タイミングは必ずしも一致しない。 なので相手が振り返られるようにしてあげるというのは意識してやらないと、認識のずれがおきてしまうんじゃないかなあと。 俺は手間だけど必ずみんなの目につくところに書くようにしていて、ウォーターフォール型でも開発手法関係なく認識はあわないし、認識あっていてもダメ押しておいたほうが幸せになれるという今までの経験から。 口頭で話して実際に文字や絵で伝えると、実は認識ずれているパターンもあるので。
チーム間で話し合った内容と結果が違う、それに気づけない
技術的な都合による修正が勝手に行われているやつ。 この時も当然最初にこういうルールにしましょうね、なミーティングをやっていたんだけど、いざ実装し始めると技術的に難しいという面がある。 そのときに勝手にやってしまうということが大きく実装内容が乖離するきっかけになったと思う。 具体例としては、既存のOSSを使って今回のプロジェクトのフレームワークを作ろうとしていたんだけど、OSS側の理解度からOSS全く使用しないチームがではじめてきて同じフレームワークなのに全く違うものが完成してしまった。 めちゃめちゃ素振りして理解した人に質問したらよかったのに、しなかったばっかりに発生した事象。 逆にめちゃくちゃ素振りしていた人も知ってますアピールをしてなかったので、確認できなかったというのもある。
チーム間の細かい状況がブラックボックス
なんかよくわからないけどなにかやってるやつ。 同じフレームワーク作ろうねって言っているのに、始まるとチームごとの独自文化が形成されてしまっているパターン。 互いに知っているのは各チームごとの大きいスケジュールで、実装のものすごい詳細な観点までは見れていない。 独自文化が形成されるのは、なんというか仕方のないことではあると思っている。経験上、独自文化形成しちゃうし。 それをどう回避するって横断的に立つようにすることを心掛けるしかない。 俺はプロジェクトで他チーム間横断していることが多いので、経験上あれ？って思うことも多いんだけど、まあそういうもんかで握りつぶすところもあって後々あれって思ったところで揉めるパターンが多いような気がする。 互いに気軽にどんな感じなのかちらっとソース眺めたり、雑談で話しやすい関係性であったり、そういう小さいレベルで防げるやつなのかもしれない。
修正タイミングが結合テスト中でデグレ障害が頻発
この話の一番やばいところ。修正タイミングがすごい悪かった。 そもそも発見が結合テストがスタートする前の作業的には谷から山に差し掛かろうかというところ。 設計見直しから入らざるを得ないものの、もう日程的に修正するタイミングがほぼない。 だがやるしかない、な逃げられない状態で修正したからかテストユニットを回してなかったとかで、結合テストで開発起因のバグが出て地獄。 また設計見直しでリファクタリングもってなったけど、ここ修正する意味ある？みたいなのもあった。 リファクタリングでこれ実装難易度が高いし期間的に難しくない？てかそもそもそれやって誰が幸せになるんだろう。みたいなやつ。 技術的負債はなくならないのでどこかでつぶさなきゃいけないけど、タイミングと粒度を見誤ると技術的負債から生まれた新しい負債につぶされる。 早めに負債に気付けることが重要だけど、突然の死！を迎えるまで気づかないのも事実だよなあと。 上記の細かい気付きをやっていけば防げていたのかもしれない。
俺が感じたこと
俺が思ったのは実際、開発手法がどうこうってあまり関係ないんだよなあってこと。 絵なり文字なりで事前に認識をしっかり合わせて足並みそろえたり、状況はしっかり共有したり、雑談で進捗どうですかな話をしとくとか、ごくごく当たり前のことで詰まっていた気がする。
