【コード進行分析】 Fighting of the Spirits (テイルズオブシンフォニア)
なお今回は、テイルズオブシンフォニア版で耳コピしています。
Fighting of the Spirits（テイルズオブシンフォニア）
===================================
BPM：176
key（調）：Am（イ短調）
作曲者：田村信二
BGMのかかる場所：戦闘曲（精霊戦）
===================================
[Aメロ]
- コード
| Am | F7 | G | Am |
| Am | F7 | G | Am |
- 度数表記
| I | VI7 | VII | I |
| I | VI7 | VII | I |
同じコード進行が2度繰り返されます。
ちなみにこのコード、私が持っている本『思いどおりに作曲ができる本』にも紹介されていてポップスなどでよく使われるようです。
-----------------------
[Bメロ]
- コード
| VI | VII | VI | VII |
| VI | VII | VI | V |
- 度数表記
| F | G | F | G |
| F | G | F | E |
メロディも1度ずつ上下に音程を変えて繰り返されるので、コードも1度ずつ上下に動いています。
-----------------------
[Aメロ]
（繰り返しのため省略）
-----------------------
[Cメロ]
（Aメロと同様のため省略）
メロディがAメロと似ているので、コードも同じですね。
-----------------------
田村氏には申し訳ないのですが、私自身もつい最近まで桜庭氏が作曲されているものと思っていました。
コード進行の観点から見てみると非常に単純な曲です。
ただコードに乗っかるメロディがかっこいいのと、何度も似たようなメロディが繰り返されるので印象に残りやすい曲となっています。
印象に残りやすくするために、メロディを繰り返すことの重要性を教えてくれる良い曲でした。
最後に、先ほど紹介した本『思いどおりに作曲ができる本』について簡単に。
作曲初心者向けの本で、簡単な音楽理論が紹介されています。
分かりやすく書かれているので、これから作曲する人にとって最適な本です。
特に5章のコード進行パターン集は、楽曲分析する時にはいつもお世話になっています。
思いどおりに作曲ができる本 Q&A方式で音楽制作の実践テクニックをピンポイント解説!(CD2枚付き)
- 作者: 川村ケン
- 出版社/メーカー: リットーミュージック
- 発売日: 2010/02/25
- メディア: 単行本
- 購入: 21人 クリック: 179回
- この商品を含むブログ (6件) を見る
Qiita投稿アプリ開発(19) Appleからリジェクトを受けてしまいました
次のQiitaアプリに関する投稿は、アプリリリースのお知らせとしたかったのですが、なかなかうまくいかないものですね。Appleからリジェクトを受けてしまいました。
iOSアプリとして今まで2個のアプリを公開していますが、運よくもこれらはリジェクト無しで公開できたため、今回が初となります。
今回受けたリジェクトの内容はこんな感じでした。
- 22.2 - Apps that contain false, fraudulent or misleading representations or use names or icons similar to other Apps will be rejected
22.2 Details
Your app or its metadata contains misleading content. Specifically, the app name includes Qiita.
このメッセージを簡単にまとめると以下のようになります。
アプリ名やアイコンに誤解を招くような表現がある場合はリジェクトするよ。
今回の場合、Qiitaって文字列を含んでいるからQiita本体のサービスを想定しちゃうからだめだよ。
要はアプリ名に既存のサービス名を入れるなってことらしいです。
しかしQiitaを入れないとよくわからないアプリになるよな、と思っていたのですが続くメッセージには以下のようなメッセージが書かれていました。
Next Steps
Please remove or revise any misleading content in your app or its metadata.
In addition, we recommend adjusting your app name so that the misleading element is used as a descriptor, not as part of the product name. For example, the following styles are acceptable formats for names:
GreatApp - with tagline "for Qiita"
GreatApp - with tagline "Qiita edition"
GreatApp - with tagline "Qiita version"
既存のサービスや製品名を入れたいのなら、〜 for サービス名にしてくれれば問題ないですとのこと。厳しいことで有名なAppleのレビューですが、意外にも対応の仕方まで親切に教えていただきました。
反論しても仕方ないのでここは素直に従い、『どこでもQiita - 記事編集・投稿アプリ for Qiita』にアプリ名を変更しました。
ところで以下のメッセージの通り、今回はタイトルに問題があっただけですので、バイナリの再提出は不要らしいです。
Since your iTunes Connect Application State is Metadata Rejected, we do NOT require a new binary. To revise the metadata, visit iTunes Connect to select your app and revise the desired metadata values. Once you’ve completed all changes, click the “Submit for Review” button at the top of the App Details page.
NOTE: Please be sure to make any metadata changes to all App Localizations by selecting each specific localization and making appropriate changes.
しかし折角の機会なので、前々から気になっていた以下の記事に書かれていることにも対応しました。
AppStoreの審査で14.3項を理由にリジェクトされました。そしてその対応方法 | feedtailor Inc. スタッフブログ
具体的にはこんな感じで、記事に不適切な内容が含まれているかどうかを指定できるようにします。
この状態で投稿すると、記事の先頭に以下の文が挿入されます。
※この投稿は不適切な内容を含みます。
果たしてこんな対応で良いのかまではわからなかったのですが、何もしないよりは良いはずです。
まさかアプリ名でリジェクトされるとは思わなかったのですが、無事再審査への申請が完了しました。
今回レビューの結果が出るまでに約1週間かかってしまったので、再レビューも同じくらいかかると考えると、結果はおそらく日曜日くらい出てくるのではないかと思います。
今度はレビューが無事に通るといいですね〜。
ジャンル別にブログを分けるべきか考えてみた
長い間ブログを運営したことのある人であれば、様々なジャンルの記事を1つのブログとして扱うか、ジャンル別に分けるかについて考えたことがあると思います。
実際、本ブログについても例外ではありませんね。
私は主にソフト開発やアプリ開発が趣味ですが、音楽関係にも非常に興味を持っているしデザインにも興味があり、プログラミングやソフト開発の記事に加えてDTMや作曲、デザインの記事も書きたいと考えています。
そこで問題となってくるのが、ジャンル別にブログを分けるかどうかというところです。
全ての読者が、DTMとかデザインとかに興味あるとは限らないですよね。
しかし！ここで安易にいろんな記事を投稿したいから、ブログを分けるという判断をしてしまうのは少し早い気がします。
複数ブログを分けて両方とも管理できるでしょうか？片方だけ更新が止まったリしないでしょうか？
この他にも複数ブログを持つことによる欠点は色々とあると思います。
せっかくの機会ですので、それぞれの場合についてメリット・デメリットをまとめてみることにしました。
1つのブログで複数ジャンルを扱う
メリット
- 1つのブログを管理すればよく、管理が楽である
- ブログ全体として更新頻度があがる
- 関係ないジャンルでも見てもらえる可能性がある
デメリット
- 購読している人に対して、希望しない記事もブログ更新時に通知される
- 内容がバラバラのため、取り扱っているジャンルに対してコアな読者がつきにくい
- アクセス集計がブログ全体で行われるため、どのジャンルに興味を持つ人からのアクセスが多いか分かりづらい
ジャンル別にブログを分ける
メリット
- 読者の興味をブログごとに分けやすい
- 記事の内容が一貫しているため、関係の無い投稿をすることによる、購読者離れを防げる
- ブログタイトルにジャンルに関する話題を入れることで、そのジャンルに興味を持った人を集めやすい
- ジャンルに興味ない人のことを意識して書く必要がない
デメリット
- 複数のブログを持つことで、管理が面倒になる
- 1つ1つを別のブログとして見た場合、更新頻度が低く見えてしまう
- ブログ間の連携を密にしないと、ブログごとに別の人が運営していると思われてしまう
購読者のことを考えれば、ジャンル別に分けた方が良い気がします。
しかし上でまとめたことと合わせて、私の過去のブログ運営について考えてみるとそうとも言えません。
実際私は過去に複数ブログを持っていたことがありました。
この時は技術系（本ブログ）とその他日記とで分けていたのですが、最終的に本ブログだけの更新だけになってしまい、他のブログは完全に放置状態となってしまいました。
やはり両方のブログを運営するというのは管理するのが面倒ですし、なにより記事を投稿しても片方にしか反映されないので、モチベーションの観点でも長続きしませんでした。
1つのブログでさえも毎日更新できない私にとって、複数のブログを運営することは無理があったのでしょう。
というわけで昔の失敗と同じ道を辿らないよう、今後もジャンルごとに分けずに本ブログ一本で続けていきたいと思います。
プログラミングやソフト開発以外の話題もそれなりに投稿していきたいと思いますので、興味のある方はぜひ目を通していただければ幸いです。
こんな弱小ブログですが、これからも細々とブログ運営していきたいと思いますので、どうぞよろしくお願いします。
Qiita投稿アプリ開発(18) アプリからQiitaへ投稿してみた
アプリの課題点が無くなったところで、実際にアプリからQiitaへ記事を投稿してみました。
結論から言うと、紐付けされたTwitterアカウントから投稿出来なかったことを除き、問題なくQiitaへ記事を投稿できました。
その記事というのがこちら。
Twitterに投稿出来なかった問題ありましたが、この原因についてもアプリの問題ではありませんでした。
Gistへの投稿でも同様の現象があり、少し調べてみると、
ということがわかりました。
すると3時間足らずで回答がきて、Qiita自体の不具合であることを教えてもらいました。
以前も丁寧な対応でQiitaのサポートに対しては良いイメージはあったのですが、今回の件についても非常に迅速に対応いただいたので、Qiitaのサポートに対する評価がさらに上がりました。
さて、アプリからQiitaへ投稿するテストも問題なく、もうこれで公開に向けて気にすることは無くなりました！
これからは公開に向けた面倒な作業が待っているだけです。
Qiita投稿アプリ開発(17) 課題解決完了
アプリリリースに向けて、実機で出てきた問題をただ解決するだけの簡単なお仕事です。
と言いたいところですが、そう簡単ではありませんでした。
自分で作った部分の修正だけならよかったのですが、使っているライブラリにも修正が必要でした。
洗い出した問題点について、それぞれどのように解決したか書いてみたいと思います。
① 投稿・下書きの一覧で表示される各項目の表示部分が狭く、見づらい
この問題の解決は非常に楽ですね。
ただ単にcssのheightの値を変えるだけです。
はてなブログのアプリを参考にして各項目のリストの高さを変更しました。
② コピーやペースト・キーボードなど、iOSが提供している機能について、英語表記となっている部分がある
これはググるだけのお仕事でした。
まだ試せていませんが、ここに書いてある方法で、英語表記から日本語表記へ変更ができそうです。
ビルド毎に変更するのも面倒なので、最終ビルド時に試そうと思います。
③ エディタ画面でプレビューと削除のボタンが縦並びになっている
buttonタグのclassにbutton--largeが設定されていたことが原因でした。
button--largeを使った場合は一列使って表示することが前提のため、縦並びになってしまうようです。
④ エディタ画面で記事本文が長くなると、プレビューと削除のボタンが画面外に出てしまう
プレビューと削除ボタンの描画順序を一番最後にすることで解決できると思っていました。
つまり、昔の個人のホームページで良く使われていたフレームをcssで実現しようという感じです。
z-index: 999
bottom: 0
position: fixed
結果から言うと、これはうまくいきませんでした。
画面をスクロールした時に最初の位置から移動してしまいました。
しかし少し調べてみると、ons-bottom-toolbarという、画面下にツールバーを作るものがOnsen UIで用意されていて、欲しかった機能そのものでしたので、こちらを使ってなんとか解決です。
⑤ 画面におさまっているページにも関わらず、スワイプした時に画面全体が動いてしまう
ググると以下のような記事が出てきました。
この記事に書かれている通りの作業で、画面全体がスクロールする現象が起こらなくなりました。
⑥ プレビュー画面で横に長いソースコードを貼り付けると画面に収まらず、はみ出してしまう
これもcss編集で。
自分で作ったcssだけでは対応出来なかったので、highlight.jsが利用しているgithub.cssを以下のように修正しました。
Javascript Fix bug: output source code from high ...
修正は簡単で、収まりきらない分を単語単位で改行するように指定しただけです。
⑦ 全体の色のデザインが青であり、Qiitaのテーマ色である緑色になっていない
Onsen UIの色を変更できるサイトがあるので、ポチポチやりながら期待している色にしました。
⑧ エディタの記事本文を編集中、タップした時にカーソルが消える(文章の最後にカーソルが移動する)ことがある
今回洗い出した問題点の中で、最も難易度が高いものでした。
何と言っても、Onsen UIのバグのようなものでしたので。
まず切り分けとして、カーソルがどういった時に消えるのか調べてみると、長押しタップでは問題が発生しないことがわかりました。
またカーソルが消えるという現象は、文章の最後にカーソルが移動して画面外にカーソルが移動してしまったためであることもわかりました。
この情報でググってみると、こんなものを発見しました。
どうやらOnsen UIが利用している、FastClickに問題があるようです。
とりあえずここに書いてある修正を行うことで、textareaについてはタップした場所にカーソルが移動することを確認できました。
しかし、タイトルに利用しているinputのtypeがtextであるものについてはまだ同じ問題が残っています。
そこで、基本的なロジックはtextareaと同じはずなので、onsenui.jsを以下のように編集しました。
Onsen UI Fix bug: Focus on input (filled with te ...
今のところこの修正で、inputのtextタイプについても問題は無さそうです。
色々と課題がありましたが、やや強引な手段を使いつつもなんとか修正が終わりました。
nendの広告も貼れたし、アイコンの作成も終わったので、次はいよいよ公開に向けた手続きですね！
Qiita投稿アプリ開発(16) 改善すべき点の洗い出し
実機にどこでもQiitaをインストールし、Qiitaへ投稿するための記事を作成してみました。
記事が完成する前に色々と問題が出てきているので、ここでアプリの問題点を洗い出してみます。
ここに挙げた課題については、アプリの使用感に与える影響が大きいので、最初のアプリのリリース時までには解決しておきたいと思います。
また、使っていくうちにこんなのがあると良いなと感じた点についても洗い出してみました。
これらについてはすぐに対応しなくても問題なさそうですので、次のバージョンでの対応を予定しています。
少しだけ使ってみただけでも、シミュレータでは問題なかったことがどんどん出てきます。
リリース前にある程度アプリを使い倒して問題点を全て解決しておきたいですね。
Qiita投稿アプリ開発(15) スクリーンショット（iPhone 5S 実機）
前回の予告通り、手持ちのiPhone 5Sでアプリを動作させてみました。
iPhoneのデバイス登録が失効していて再登録することを除いては、特別に躓くことなくスムーズに動作確認まで行えました。
非常に簡単なため、手順というほどの作業は無いのですが、手順を簡単に説明します。
最初に以下のコマンドを実行します。
$ cordova build ios
後は、platform/ios/****.xcodeproj（****はアプリ名）からXcodeプロジェクトを開いた後にターゲットデバイスを選択して実行すれば、実機確認できます。
何も難しいことはありませんね。
非常に簡単に終わってしまったので、実機のスクリーンショットを載せておきます。
エディタ
プレビュー
投稿一覧
メニュー画面
非常に短いですが、本日の記事はここまでです。
次はnend広告あたりを取り付けましょうかね。
