するだけ、という形になります。Lambda関数に入力されたSlackのイベントペイロードに応じてオンデマンドで作る必要があります。取得、生成してみました。Lambda関数ハンドラは、以下のようになりました。9完成!そして今後の変更にむけて今回のアプリケーションの実装はこれで完了ですが、オニオンアーキテクチャでは、以後のコードの変更の際も、同じようなStepを辿ってコードの健康状態を維持していきます。ユースケース・ビジネスロジックに変更があった場合は、基本的に今回のStep全体をもう一度なぞる形になります。変更内容に応じて、ユースケース、モデルインターフェースとテストの修正を行います。等の契約が変更されると必要な変更点がコンパイルエラーとしてリストアップされるので、これに従って修正を実施できます。新たに追加する必要がある場合もあるかもしれません。インフラストラクチャに対する要求が変化した場合、まずは技術検証フェーズを経て、変更後の構成やデータ移行の構成を固める必要があるでしょう。実装を新しいインフラストラクチャの特性に合うよう書き換えるか、または丸ごと新しい実装に差し替えることができます。契約に対するそれなりの理解が求められます。これが望ましい性質かどうかは、プロジェクトの種類や規模、存続期間に依りますが、少なくとも品質に対する要求が高いソフトウェアでは、目的の達成に貢献してくれる可能性が高いと思います。実践上の補足をいくつか、追記します。比較すると、もちろん若干の追加時間を要し、体感では最大1.5倍程になるように思います。個々のStepで目的として設定された検証を確実に行い、前のStepに対するフィードバックが機能すれば、全体の手戻りはかなり少なくなるはずです。数週間〜数ヶ月で捨ててしまうようなソフトウェアの開発には向かないので、対象のプロジェクトや実践のスコープは適切なものを選ぶ必要があります。これはウォータフォールではないのか?巨大な開発プロジェクト全体でこれらのStepを進めていくようであれば、そうなってしまう可能性はあります。いったスコープの切り方はそもそも適切ではありません。単位で、局所的に整合性のあるモデルを作って開発に役立てるのがオニオンアーキテクチャの核となります。その後、モデルをどのくらい多くのユースケースで横断して利用できるものにするかは、マイクロサービス分割等と同じように、別途判断を要するものです。まとめここまでで、オニオンアーキテクチャを実際に始める際の手順を通して、この方法がどのように安心・安全で高品質な開発に貢献してくれるか見てきました。人による部分はあると思いますが、ソフトウェア開発の中で単純作業や流れ作業が続くような場合、個人的にはとてもやる気が削がれます。オニオンアーキテクチャでは、プロジェクトを始めるとあらゆるステップに設計とフィードバックループが含まれ、開発中は常に、ソフトウェアの向上に貢献する知的な作業に時間を費やすことができます。冒頭でも述べましたが、オニオンアーキテクチャは上手く使えばこういった意味でも、完成形だけでなくプロセスで大いに価値を発揮できるアーキテクチャだと思います。実際の開発では何よりもスピードを求められることの多い時代ですが、自分の「理想的な手順や形」のイメージがあると、日々の細かい作業の最適化やアーキテクチャの行き詰まりの問題に直面しても視界が保て、生産的でいられる助けになるように思います。それは自分にとって今の所、オニオンアーキテクチャや関数型です。感じ取ったのは、所謂「DDD実践本」だったかと思います。ちなみに、DDDと関わりが深いのは確かですが、少なくともDDDの文化的側面を抜きにしても実践できるアーキテクチャです。手順が重いようにも思えますが、もし「お試しコード」やプロトタイピングを作成する場合はこの段階の活動でプロジェクトを終え、以降のStepに進む必要もないと考えます。技術検証のことはいったん全て忘れます。インフラ構成が頭の片隅にありさえすれば、ここでどれほど自由に設計をしても、アプリケーションが破綻することはないように思います。インフラは蔑ろにされる訳ではなく、後に外部依存関係の分離をレビューするStepや、集中的な実装を行うStepがあります。次のStepで導入するDIためのコードが既に少し混入しています。↩とはいえ、例えばWebアプリケーションフレームワークのようなものに接続する場合、全てのメソッドを役割としてユースケースに注入するのはあまり現実的ではないでしょう。ようにしてメソッドハンドラ内で使い回すことができます。して注入されるべきものがユースケースの外に漏れ出ないよう、注意しておく必要があります。↩デプロイやその他、インフラストラクチャを整える作業がここで発生するはずですが、この部分はオニオンアーキテクチャのスコープ外なので省略します。Rekognitionの画像サイズ制限に対応するための修正を、別途実施してまとめてみたいところ。2015の22日目です。寝るまではまだ22日目なんだ...!って書いてからその認識さえ一日遅れていることに気づきました。僕は某フェスと某ステージのイベントがたまに被ったりして大忙しです。いったリズムゲームをやっていると、たまに以下のような不満を感じることがあります。好きな曲なのにリズムパターンやノートの置き方が気に食わなくていまいち盛り上がれないもう少し難しくてもいいのにと思う逆に難しすぎだろアホと思うざっくり言ってしまえば、「なんかリズムが気に入らないな」という話。リズムゲームのパターンの作り方はゲームによっても曲によっても様々で、分かりやすい所ではパターンがドラムスに寄っているか旋律に寄っているか、そのゲーム特有の特殊な打ち方(押し続けやフリックなど)をどの程度用いるかというような違いがあります。このパターンが自分の好みに合わない場合、とくに好きな曲をプレイしていると、とても残念な気持ちになってしまうことがあります。自分で作るもしそんな不満を抱えているあなたがエンジニアなら、気に入らないものは自分で作ってしまいましょう!この記事では、リズムゲームを作るのに必要そうな技術的課題以外の、準備の部分を中心に取り組んでみました。僕はリズムゲームを作るプロではないので、本場の方法と大きく異なる部分があるかもしれませんんが、一応そろえれば作れるよ、というものとして書いています。僕も知らないっす)こんな手順になります。音源にあわせてリズムパターンをつくり、最終的に音源の再生時間基準でどこをタップするか、みたいな情報を含んだデータに落としこむのが基本的な流れ。音源を用意する*DAW的なものを用意する曲のテンポを計測する*音源の位置合わせをする*リズムパターンを打ち込むMIDIファイルと音源(*)を吐き出すMIDIファイルの中身を変換する何かアプリケーションを作るところまでできれば良かったんですが、打ち込みに3時間くらいかかって力尽きました......ちなみにこのうち、*の付いている手順は、少なくともサービスとしてまっとうな方法でリズムゲームを作る場合必要のない手順です。音源を用意する何はなくとも、曲の音源です。今あるリズムゲームに不満がある方は、実際のリズムゲームから吸い出すのもよいかもしれません。(こうして吸いだした音源を他人に頒布したり自分で楽しむ以外の諸々の用途に供するのはいけないことなのでやめましょう!!あと曲を聞きたいなら買おう)自分で用意する場合も、1曲のプレイ時間として適当な(あと打ち込みで死なない)長さに気を付けます。Workstationです。実際のところ、MIDIと音声ファイル等を同時に読込み・編集・書出しできるものならなんでもOKですが、こういうのはDAWで検索するのが一番でてきやすいです。ちなみにMIDIは今のところ、いつどんな音が鳴るかを書き込める電子的な楽譜みたいなものと思っておけばとりあえずよいでしょう。今はフリーでもちゃんと使えるものがたくさん出ていて最高ですね...昔の無料シーケンサーなんて...うっ..頭が...今回はTracktionを使いました。4)が無償で提供されています。曲のテンポを計測する今どきの音楽でDAW的なものを介さずに制作されているものは恐らくないと思われ、その場合、打ち込みの部分と生演奏・録音の同期をとるために、必ず曲全体が精確なテンポに従ったタイムラインの上で管理されているはずです。今回のようにひとの曲を勝手に使ってどうこうしようという場合、自力でテンポを計測して知る必要があります。今回使ったのはこちら。minute)測定アプリで、テンポに従ってタップすることでタップ間隔の平均的なテンポを知ることができます。曲を聞きながら、ひたすら無心でタップしましょう。リズムゲームで培った精確なタップ力が試されますね。音源の位置合わせをするDAWを起動して新しいプロジェクトを作り、計測したテンポを設定したら、用意した曲の音源を適当なトラックにロードします。音源の内容がトラックにべーっと貼り付けられたら、音源の最初の表拍などをDAWのタイムラインの拍と合うように、音声トラック上を移動します。プロジェクト全体を再生しながら、録音用のシグナル音みたいなものがあればその音と、なければ適当な音をMIDIトラックに打ち込んで、DAWの拍と音楽の拍が合うようにします。当然ですが、テンポが合っていない場合は曲と他の音がだんだんズレてきます。ない場合は初めから終わりまで同じ時間のズレが維持されてかなり判定が難しいですが、頑張って心の耳で合わせます。リズムパターンを打ち込むいよいよリズムパターンの打ち込みです。自分の魂のビートを打ち込むことで、リズムゲームでしっくり来なかった鬱憤を存分に晴らします。この作業は恐ろしく時間がかかります...ピアノロール(画像)というのはおおよそ人間の使用に耐えるものではなく、プロの人は電子楽器等で演奏したものを自動補正することで打ち込むため、今後もまともな進化は期待できない[要出典]UIです。気に食わないリズムパターンを叩くよりここでよっぽどフラストレーションがたまっている気がしますが、まあ気にしないことにします。処理で参照して何かの目印に使うことができます。MIDIファイルと音源を吐き出す打ち込みが終わったら、打ち込んだリズムパターンの部分をMIDIファイルにして出力します。別に、打ち込んだパターンをミュートにして音源の部分も出力します。これによって、位置合わせした分の空白が反映された新しい音源を作ります。MIDIファイルの中身を変換するここに来てやっとエンジニアらしい作業です。MIDIファイルから情報を抜き出し、曲の音声ファイルの特定の再生時間でどこをタップしてください、みたいなデータを作ります。MIDIファイルを扱うためのライブラリはきっと言語ごとに一つくらいはあると思うので、そういうのを使います。今回はPython製の以下を使いました。github.comこんな感じでダイレクトにファイルを読むインターフェイスを用意してくれているので、すぐに本来の作業に取りかかれますね。iomidi.read('midifile.mid')MIDIの構造MIDIに変換をかますには、MIDIファイルの構造を知る必要があるでしょう。iomidiのオブジェクトのプロパティを参考にざっくり見てみると、以下のようになっています(もちろん実際はJSONではありません)。]}ファイル全体の情報が書かれたヘッダに、独立したトラックがいくつか含まれていることがわかります。ヘッダで重要なのはdivisionです。ファイルの中の時間は全てtickと呼ばれる単位の整数倍で表されていますが、このtickの分解能を表すのがこの値で、tickが1秒の何分の一かを示しています。ここでは960なので、おおよそ1tickは1msくらいになります。トラックは先に打ち込みで作った数+1だけ存在するはず(トラック0はなんかシステム的なやつが入っています)。トラックの中身を見てみます。]}うん、もっと中を見ろってことですね。eventの中身はこんな感じです。}}案外シンプル(?)ですね。理解しやすいものの定義はこんな感じです。打ち込みで入れた音の高さ。ドラムとかにもちゃんとついている。普通の音を鳴らすイベントは、基本的に音を鳴らし始めるNoteOnEventと鳴らし終えるNoteOffEventの合わせ技でできていて、同じkeyでNoteOffEventが発生すると前回のNoteOnEventの音が止まる感じになります。速さ...ではなく音の強さを言います。今回の処理には関係なし。MIDIのしくみ系の値。今回の処理には関係なし。deltaについてMIDIはそもそも、電子楽器などの演奏データを楽器や機器の間でリアルタイムに交換するための信号の規格で、MIDIファイルの中身も少し変わった形で記述されています。deltaはその事情を反映した値になっている気がします。deltaは、そのトラックの前回のイベントから自分までの時間差をtickで表した値です。今回欲しいのは音源のどの再生時刻にタップが入るかなので、トラックの最初のdeltaから順次足し合わせる必要があります。なんかこんな雰囲気ですね。time_ticks=accumulated_time_ticks)このdeltaさえなんとかすれば、いい感じのデータが作れそうな感じがします。必要に応じて、NoteOnEventだけを選出する必要はあるかもしれません。rev_seq_b.pop()なんかできた気がする!こちらがここまでで作ったものになります。github.com一応CLIが付いていて、なんか結果を吐いて音源と比較してみるとどうもtime_msの時間がおかしい気がするんですが、まあまだこの先を作っていないので仕方なし...とりあえずデータの作り方のコンセプトは合っているはずです。あとは、作りたいゲームの特性に応じて情報を作ってイベントにくっつけくっつけしていけば、データは完成するのではないでしょうか(適当)。さあ、ゲームらしきものを作る段には全然入ってませんが、ここまでのデータがそろっていれば、エンジニアならあとは何となく作れる気がして来たのではないでしょうか(自分も年末にやり切りたいです...いつかゲーム実装編が書かれる...かどうかはわからない)。音楽ゲーム系のアプリケーションは何となく難しそうなイメージがありますが、本当に難しいのは気持ちよくプレイするためのタイムラグとか処理落ちをなくすとかの部分で、DAWをさわれてMIDIの知識をつければ、案外その前までは作れてしまうものです。2015の15日目です。ASPの残念な話をネタで書こうと思っていたんですが、書いていたらあまりにつらくなってしまって無理だったので替わりのポエムです。酔って書いたわけではないので、逆にちゃんとポエムできていないかもしれませんが、ご容赦下さい。(文章が長くてわかりにくいのはデフォルトです)このコミュニティのターゲット、「(だいたい)新卒」な皆様の中には、きっとそろそろ自分がエンジニアと言う職種の暗闇の部分に片足を踏み入れているように感じている方がいるのではないかと思います。そんな人に向けてのお話です。病院へ)ソフトウェアエンジニアは、生きながらにして死んでしまうことがあるように思います。本当に命を削って仕事をされている方には申し訳のないことですが、ここで言っているのは、それなりの健康を維持できる環境で働いている中でも以下の様な状態に陥って、エンジニアとしてゆっくりと死んでいくという話です。開発することが楽しくなくなる仕事上の問題解決はソツなくできるので今のままで別にいいような気がする組織運用上の問題は無視するか、技術で力ずくの解決をしようとする誰しも疲労が蓄積すると好きなことも疎かになってしまうものですが、ゆっくり死んでいくタイプのエンジニアはたまにはちゃんとゆっくりできるのが普通なので、問題はむしろ別のところにあるように思います。良い仕事の成果を自然に目指していけるという希望を失うこと多くのエンジニアは、開発の仕事さえ与えておけばずっと生きている虫のような生きものとは違うので、エンジニアを目指した時の気持ちを再確認する機会が目減りしてしまったとき、誇りを失い、自分がエンジニアとしてできることが何なのか忘れてしまうものです。古代遺産を大人の事情で守らなければならない政治的な理由で選択できる技術が限られる実現する価値が会社のビジョンと関係ない説明はしませんが、きっとここまで読み進められた人には分かってもらえるでしょう。いった気持ちを奪われたエンジニアは、日を追う毎に受け身がちになり、開発する機械のような振舞いで身を守るようになります。外に目を向けるずっと前から何度も言われてきたことですが、会社や仕事の範囲にとどまらず、外に目を向けて客観的に自分の置かれている状況を見つめること。自分を取り巻く環境を変えるのは勿論ですが、その後自分の状況とどう向き合っていくべきか、意外とすぐに答えが出るものではありませんでした。老害についてこういった文脈でよく話題に上がる老害という単語があります。僕自身はあまり好んで使う言葉ではないですが、一方ソフトウェア開発の世界に限らず、どんな業界・ドメインでもかなり普遍的に見い出される概念のように思います。自分が今まで作り上げ、継続してきたやり方に誇りを持っているという特徴です。これは、ゆっくり死んでいく系エンジニアから見るとげに羨ましいことです。彼らは事実として、上で書いたような僕らの苦しみに関与してはいますが、実はある意味、僕らが渇望する幸せなエンジニアの一つの形を体現しています(いました)。一時代を築くにあたって、誇りを持ってエンジニアリングに対峙し、またその誇りを継承してきた彼らの姿勢にあります。これはある意味で、エンジニアとしての一つの理想像とも言えないでしょうか。彼らと同じ組織に所属し、同じビジョンを目指しているのならば、彼らが本当はどんな価値観をなぜ大切にしているのかよく知り、どのような視点で会社の目指すものを見つめており、僕らとの間の溝が一体何なのか理解すべきです。その上で組織を理解して変えていくためには、どの程度の時間と労力が必要でしょうか。自分にそれを支払うことはできるのか。他にこの作業を行うべき人は、今何をしているでしょうか。僕らと彼らの問題がクリアになって解決した時、その先に僕らの目指すものはあるでしょうか。彼らの視点は尊重するに値するものだったでしょうか。それらは、本当に今僕らの問題として取り組むべきことなのでしょうか。誘い@arataが最近言っているとおりDarkは雑なコミュニティですが、雑だからこそ誰にでも入り込める余地があるし(不審者のご入場はお断りしております)、色々な状況や考えの異なる人たちが集まれる場所になっているように思います。Darkのイベントに足を運んでみてください。いろいろな人の話を聞いて、他のひとが目指す価値と自分の目指す価値、他のひとの環境と自分の環境について比較してみてください。別々の誇りをもった二人がぶつかれば、トシに関わらずきっとそこにROUGAIが生まれます。一緒に考えていきましょう。こんなアドベントカレンダーを書いても(きっと)平気なコミュニティですので、気軽に遊びにきて下さい。運営のくせに恩恵を受けてばっかりで闇の話しかしないし、なんかちゃんとエンジニアとして活躍していてコミュニティの話題を作ってくれている人たちには申し訳なさが結構あるんですが、やっぱり今沈んでいるたくさんのエンジニアに、道をとりもどすきっかけをつかんで欲しくて、このコミュニティはそういう場としてもあり続けられるんじゃないかと思っているのです。老害を理解する云々はだいたいこちらの受け売りなので少しでもピンときた人は見てみると良いと思います。2015の11日目です。こんにちは、Darkでピザ注文職人[要出典]をやっている@ymatです。闇に飲まれている筆頭として何か書こうかと思ったんですがそれは16日目にして、今日は心癒される話題(?)です。ちなみに、エンジニアリングのえの字も出てきません。亜熱帯オフィス僕が毎日通っている弊社の6Fフロアは夏も冬も驚くほど暑く、室内の温度は常に25度に迫り、木枯らしが吹くような肌寒い日でも半袖で過ごせるのが特徴です。この特殊な環境は、とある一つの趣味を発生させます。いかがでしょうか、まさにジャングルです。あたたかい地域でこそ青々とした葉を伸ばす観葉植物たちにとって、うってつけの環境なのです。机上シルクジャスミンそんな訳で、僕もはじめてみました。シルクジャスミンという種で、和名をゲッキツ(月橘)といい、名前が醸し出す通りミカン科の植物です。詳しいバイオロジーが知りたい場合はWikiでも見て頂くとして。神聖な儀式祭具のようですらあります。そもそも、名前からして神々しさがあります。今、俺の机の上にはシルクジャスミンがあるんだというだけで、ふだん、開発する機械[要出典]のように働いているわたしたちに、何か忘れかけていた誇りのようなものを思い出させてくれる気がしませんか。「かんなぎ」という作品を読んだことがあるでしょうか。うれしかった(※若干の整形を施してあります)という一節がありますが、そんな感じです。苗木ケアこのシルクジャスミンですが、机の上に置く観葉植物としてはかなり変わり種のようです(そもそもミカンですし)。いうのも、いくつか普通の観葉植物にはあまり見られない特徴があります。(乾燥に弱い)大抵の観葉植物は水やりの過多に弱く、あげる周期は土の表面が乾いてから3,4日後、というのがセオリーです。このシルクジャスミン、土の表面が白く水分が飛んだ状態になると途端に目に見えて顔色が悪くなるため、土が乾ききったタイミングで間を空けずに水やりを行うくらいの気概が必要になります。葉も乾燥に弱く、特に空調の風が直接当たるようなロケーションで育成する場合は、定期的に霧吹き等で葉の表面を保湿しておく必要があります。基本的に日当たりの良い場所でないと花や果実を付けるのは難しいようで、室内はなかなかにハードな条件だったりします。あと日照って書いた時の日光東照宮感は異常。罹患すると白いうどんの粉のようなものが葉に付着し、草木の健康を奪います。カイガラムシがすぐつく僕の2年前の入社時に元気に葉を広げていた弊社6Fの2本の観葉植物は、今年の春ごろに揃って産業廃棄物として処分される憂き目に遭いました。その原因となったのがカイガラムシです。植木がファーを纏っているかのように毛で真っ白にしてしまうおっかないやつらです(もちろんその後枯死します)。発生実績のある弊社6Fオフィス(本当どっから入ってきたんだ)では特に注意して除去していきたいところです。うどんこ病とあわせて、とにかく白いヤツには気をつけろということですね。みずみずしい若葉を順調に伸ばしつつあります。いつでも目線をあげれば健気に育つシルクジャスミンのある生活は、想像以上に癒しの力を秘めています。皆さまも机の上に生命の輝きを導入してみてはいかがでしょうか。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。