(^p^)ブログ

いろいろ書いていくとおもうよ

(^p^)のーと:2/2 music21を使って楽譜を分析する

28日チャレンジ2日目は楽譜の分析について書きます。

 

 

1日目にちらっと出したmusic21

music21 Documentation — music21 Documentation

 

を使って楽譜のMIDIデータをいじり楽曲分析します。

 

このライブラリは、Python音楽学をするためのもので、

音楽構造の抽出、変換、編集などができ、それを可視化することで

各種の音楽の分析を行うのに役に立つものです。

 

入力できるフォーマットはMIDIMusicXMLなどの音楽データで、

WAVやMP3などの音響データを扱うことはできません。

 

折角なので、このライブラリを使いつつ

皆さんにもなじみ深い曲をいろいろ分析してみたいと思います。

 

なお今回、題材とする曲は、Musescoreのサイト内でダウンロードできるものから用いました。

 

musescore.com

 

 

Music21をつかおう

・楽譜の読み込み

 

まずは、モジュールに同封されているコーパスから楽譜を読み込みます。

コーパス中の適当な曲を読みだしてみます。

import music21 as m21

#コーパスの利用
piece = m21.corpus.parse("mozart/k545/movement1_exposition.xml")

# 楽譜表示(musescoreやFinaleなどがインストールされていないと動かない、)
piece.show()

f:id:yamatch:20180202015657p:plain

このようにバックエンドとなっている楽譜表示ソフトで楽譜を可視化できます。

 

例として、モーツァルトピアノソナタ16番を読み込んでみました。

さて、この曲に関するいろんな情報をだしてみましょう。

 

・調を調べる

piece.analyze("key")

 <music21.key.Key of C major>

ハ長調のようですね

 

・ピアノロール形式で表示

piece.plot('pianoroll')

f:id:yamatch:20180202022233p:plain

 

こんなかんじでだいたいどんな感じの曲かを俯瞰できます

 

・音高の統計情報

piece.plot('histogram')

f:id:yamatch:20180202022617p:plain

どの音が多いのか楽譜から調べることができます。

 

 

また、ひとつのパートを取り出して分析することもできます。

pieceはそれぞれのパートの演奏情報をリストにしてまとめたオブジェクトだと思ってください。

左手パートの情報を調べてみます。

・左手パート、音のピッチクラス(ドレミの音名が同じものをまとめて集計したもの、高いドも低いドも同じとみなす)の統計情報

piece[2].plot('histogram','pitchclass')

f:id:yamatch:20180202023422p:plain

ファ#が一個だけあるのみで、ほかはほとんどハ長調の音である。

ファ#があるのはどこかさがしてみる。

for m in piece[2].getElementsByClass('Measure'):
    for p in m.pitches:
        if p.name == 'F#':

            print(m.measureNumber)

 12

12小節目のようですね。

表示しましょう。

piece[2][12].show() 

 

f:id:yamatch:20180202220442p:plain

と、こんな感じで取り出しもできます。

 

こんな感じでmusic21を使えばいろいろな音楽分析ができてしまいます。

 

 

いろんなJPOPの楽譜を分析しよう

 

ここで実践、普段聞いている曲の良さの秘密に迫ろう、ということでmusic21を使ってJPOPの楽譜を解析していきます。

 

・JPOPのよさの秘訣は「ヨナ抜き音階」「ニロ抜き音階」

他の国のポピュラーソングにはない傾向として、JPOPは「ヨナ抜き音階」「ニロ抜き音階」と呼ばれる音階で構成されている曲が数多く見られます。

 

ヨナ抜き音階とは、ハ長調(ドレミファソラシド)のうち、「ヨ」4番目のファ、「ナ」7番目のシを抜いた音階です。

ニロ抜き音階はヨナ抜き音階の短調バージョンで、イ短調(ラシドレミファソラ)の「ニ」2番目のシ、「ロ」6番目のファをぬいた短音階です。

 

7音使って作るメロディよりも、ノスタルジックさを出しやすい音階です。

 

実際見てみましょう。

・千本桜

サビが特に顕著でした。

サビの1フレーズ目は38~45小節目なのでそこのメロディパートを抜き出すと、

piece = m21.converter.parse("#千本桜のファイルの場所")

sabi_piece = piece[0].measures(38,45)
sabi_piece.plot("histogram","pitchclass")

f:id:yamatch:20180202225047p:plain

E,B♭の音のみ頻度が少なくなっているのが見てわかると思います。

 

キーを調べると、

print(sabi_piece.analyze("key"))

d minor 

ニ短調(レミファソラシ♭ドレ)の2番目と6番目にあたるこの2音の頻度が明らかに低い、ニロ抜き短音階だ!

 

という感じです。

 

 

中途半端になりましたが、時間オーバーになりそうなので今日はここまで

 

 

 

(^p^)のーと:2/1 pythonで音関連ファイルをあれこれするまとめ

28日チャレンジ1日目は音データの扱いについて書きます。

何番煎じかはわかりませんが、これから音データを処理するにあたり、そもそもファイルを扱えるようにしないといけないな、と思って書いてみます。

 

ほとんどそれぞれのモジュールの基本的なところしか触っていませんが、まあ最初だし、ネタがまだ思いついてないし、今後よく使うだろうねってことで備忘録もかねてやっておきます。

 

音声ファイル

まず、音を音波そのものとして記録する音声ファイルの扱いから。

wav,mp3,aacといったファイルをいろいろやる方法についてまとめてみる。

 

・古くからの方法

自分はこれまでこの方法しか知らなかったので、書きます。

これは古くから伝わる(?)wavファイルの入出力方法です。

wavファイルの取り扱いは、python標準ライブラリのwaveモジュールを使います。

また、そのデータを再生したり録音したりするには、pyaudioというモジュールを使います。

people.csail.mit.edu

 

 

さっそくやってみましょう。

・音声ファイルの読み込み&再生

import wave
import pyaudio

# 音声ファイルを読み込み再生する
CHUNK = 1024
# test.wavを読み込みモードで開く
with wave.open("test.wav","rb") as wf:

# test.wavを再生
p = pyaudio.PyAudio()
stream = p.open(format=p.get_format_from_width(wf.getsampwidth()),#ストリームを読み書きするときのデータ型
channels = wf.getnchannels(),#モノラルかステレオか 1でモノラル2でステレオ
rate = wf.getframerate(),#サンプリング周波数
output=True)#出力モード

data = wf.readframes(CHUNK)

while data != '':
stream.write(data)#ストリームに書き込み
data = wf.readframes(CHUNK)#次のデータを読み込む

stream.stop_stream()
stream.close()
p.terminate()

このプログラムを実行するとtest.wavが再生されます。

 

・音声を録音してwavファイルへ書き込む

import pyaudio
import wave

CHUNK = 1024

#int16型
FORMAT = pyaudio.paInt16

#ステレオ
CHANNELS = 2

#サンプリング周波数44100Hz
RATE = 44100

#5秒間録音
RECORD_SECONDS = 5
WAVE_OUTPUT_FILENAME = "hogehoge.wav"

p = pyaudio.PyAudio()

stream = p.open(format=FORMAT,
channels=CHANNELS,
rate=RATE,
input=True,
frames_per_buffer=CHUNK)

print("* recording")

frames = []

for i in range(0, int(RATE / CHUNK * RECORD_SECONDS)):
data = stream.read(CHUNK)
frames.append(data)

print("* done recording")

stream.stop_stream()
stream.close()
p.terminate()

wf = wave.open(WAVE_OUTPUT_FILENAME, 'wb')
wf.setnchannels(CHANNELS)
wf.setsampwidth(p.get_sample_size(FORMAT))
wf.setframerate(RATE)
wf.writeframes(b''.join(frames))
wf.close()

これでhogehoge.wavという名前の音声ファイルとして5秒間の録音ができます。

 

pyaudioはリアルタイム性に優れたところがあり、スペクトルアナライザとか作れるみたいなので、いつの日か試してみたいですね。

 

ただ、この長さを書くのは正直めんどくせー・・・

再生するのにいちいちチャンネルとかチャンク数とかこっちが書くのかよ。

 

っておもってたら、こんなモジュールを発見しました。

jiaaro/pydub @ GitHub

pydubという最近(といっても4年前)リリースされた、音声ファイルを楽にpythonで再生できるモジュールです。

音声ファイルを再生するなら・・・

import pydub
from pydub import AudioSegment
from pydub.playback import play

song = AudioSegment.from_wav("test.wav")

play(song)

らくちん。ストリームどうこうしなくても楽に書けます。

このpydub、公式ドキュメントを読みつくしてないのですが、

どうやら音声を合成したり、ファイルフォーマットの変換もできるみたいです。

 

楽譜ファイル

音の中でも、構造化された音楽を楽譜として保存する形式。

MIDIが特に有名ですが、MusicXmlなんていうXml形式のフォーマットもあります。

https://ja.wikipedia.org/wiki/MusicXML

タグが音の高さだったり長さだったりする形式のXMLです。

 

Midiファイルを扱うモジュールとしてはmidoかpretty-midiが有名ですかね。

Mido - MIDI Objects for Python — Mido 1.2.8 documentation

pretty_midi — pretty_midi 0.2.8 documentation

 

私は春の実験の最終課題として自動作曲*1をやったのですが、その際に使ったのはpretty-midiなので、今回そっちをつかってやってみます。

 

Midiファイルを読み込み、いじる

import pretty_midi

#Midiファイルの読み込み
midi_data = pretty_midi.PrettyMIDI('test.mid')

#ドラム以外の楽器の音を半音上げる
for instrument in midi_data.instruments:
if not instrument.is_drum:
for note in instrument.notes:
note.pitch += 1
#このデータを新たなmidiファイルに書き込み
midi_data.write("pitch_up_test.mid")

・任意の音でMIDIをつくる

#midiファイルの生成
cello_c_chord = pretty_midi.PrettyMIDI()
#チェロの音色で
cello_program = pretty_midi.instrument_name_to_program('Cello')
cello = pretty_midi.Instrument(program=cello_program)
# ド・ミ・ソの和音
for note_name in ['C5', 'E5', 'G5']:
note_number = pretty_midi.note_name_to_number(note_name)
#ヴェロシティ(音量)を100、0.5秒間鳴らす
note = pretty_midi.Note(
velocity=100, pitch=note_number, start=0, end=.5)
cello.notes.append(note)
cello_c_chord.instruments.append(cello)
#cello-C-chord.midというファイルを生成
cello_c_chord.write('cello-C-chord.mid')

こんな感じでMIDIファイルを自由自在に扱うことができます。

 

midiの再生もpythonでやりてえよ、って人はこのリンク先のコードを試してみればいいんじゃないかと思います(筆者は未検討))

www.daniweb.com

また、midiを分析するmusic21というモジュールもあります。

music21: a Toolkit for Computer-Aided Musicology

使用例については、2月の第1週のどこかで、

僕の春の実験でやったことをもう一回再現しながらやりたいと思います。

 

 

今回は音関連ファイルを処理するpythonのモジュールを紹介してきました。

こんな感じでゆるゆる~っと音処理について毎日いろいろ書いてこうと思います。

 

 

次はなにかものを実際に作ってみようかな。

 

とりあえず溜まってるネタ

  • 沖縄風JPOPを解析しよう(music21、実験でやった)
  • リアルタイムサウンドスペクトルアナライザ
  • 鼻歌認識
  • 音源分離
  • 音関連APIをたたいてみよう
  • 自動作曲再チャレンジ

などなど・・・

 

・・・忙しい2月になりそうだ(|||^p^)

 

 

*1:遺伝的アルゴリズムを使った。曲ではないなにかが生成された

28日チャレンジ

1月は人生で一番進歩がない月だった

 

だから2月に毎日やること

 

・なんらかの技術的記事をブログに書く

Twitterでバズった腹筋

・n-back5分

どこまで続くかわからんけどやってみる

 

音処理やpythonに関する橋にも棒にも引っかからん記事が生成される予定

AWSでミスって45万の請求が来た話

この記事はmast Advent calendar

adventar.org

の24日目の記事です。

この聖なる日の前夜に,(追記:この日予定が入ったので記事の公開を前倒ししました)mast3編でもっともキラキラしてない男が記事を書きます。

 

 

 

 

自己紹介

名前:やまち

所属:mast15・3編、zeyo17、元某東京の私大生、機械・材料系専攻出身

特技:デスボイス

特徴:9mmのボーカルに似ている、これまで痛風を5回患っている、よわい(3編最弱

趣味:昼寝

将来仕事にしたいこと:昼寝

 

 

普段はPythonで自分の興味のある諸々をかたかたしたり、変態力の高い友人の妄想を形にするようなクソゲーゲーム作りを細々やってるヒキニートです。

 

今回のお話はタイトルの通り素人がAWSでミスを犯して身に覚えのない45万相当の請求を食らい、1週間ほど食事が喉を通らなかった話です。

*1

 

先に申し上げておきますが、

 

本記事でお話しする不幸は自分が馬鹿を幾つも重ねた結果であって、AWS 自体は怖くない、素晴らしいサービスだということは言っておきたいです。

 

本文中には多少ふざけた言葉選びが散見されるかもしれませんが、私は全力で AWSさんに感謝 をしております。

 

本記事をご覧になったmastのみなさんが今後クラウドサービスを使ったサービス開発をするときに、筆者と同じ轍を踏まないことを切に願っております。

 

また、筆者は極度のバカで豆腐メンタルのIT初心者です。

知識のある方にとっては「初心者ってここまで無知なもんか」と気分が悪くなる記事です。ご容赦ください。

 

AWSとは

aws.amazon.com

もうすでに知ってる人はたくさんいるかと思われますが、

AWSとは世界最大手のクラウドサービスであり、仮想マシン(EC2)やストレージ(S3)、データベース(AmazonRDS)をはじめとした幅広いサービスを提供しています。

 

AWSを使うことになった経緯

事の始まりは「なんかアプリつくろーぜ」的な流れに参加し、iosアプリケーションを開発することになったのがきっかけでした。

私はWinユーザーであるうえに、Swiftのことはさっぱりわからなかったので、

もっぱらサーバーサイドの開発に従事していました。(pythonです)

 

このアプリケーションは音声認識を必要としていて、

録音の機能が必須でした。

サーバーはherokuを使っていましたが、heroku単体では音ファイルのアップロードはできないということが判明し、

S3にクライアントからファイルを一回アップロードしてからそれを今度はheroku側で処理する、という方式をとっていました。

 

開発が行き詰まっていたところに、S3という救世主が現れたことによって

実装したい機能が実現し、喜んでいたのもつかの間、悲劇が起こりました。

 

 

AWSからの通知

朝起きたらこんなメールが届いていました。

f:id:yamatch:20171219220159p:plain

 

なんだこれ・・・英語できない私でも不幸のお知らせってことはわかるぞ・・・

要するに「おまえの垢、のっとられとるで」的な内容だろ。

 

 

 

「ま、またまたぁ~ご冗談を~(笑)」

とか笑い飛ばしながら、震える手で請求画面を見ると・・・

 

 

 

 

 

 

f:id:yamatch:20171219221012p:plain

 

 

 

 

いやいやいや、これ450円だろ?.5fとかいれてんだろ?とか思いつつも、点がふたつある小数なんて存在しないことに気づく。ああ・・・45万円か・・・

 

 

f:id:yamatch:20171219221012p:plain

しばし真顔の後、どうしてこうなったのかすぐに原因を究明すべく各所に回りました。

 

おかしいところを探した結果、今回のアプリケーションに必要のないEC2が、インスタンスを全リージョン全力で回されていたことがわかりました。*2

おそらく流行りのビットコインマイニングにでも使われたのでしょう。

 

どうやら起こったミスとしては

・クライアント側のメンバーのgithubにシークレットキーをそのままのっけたswiftコードをうpしてしまっていた(githubに誤ってうpされたシークレットキーをクローリングする悪い奴らがたくさんいます。うpしたら最期です。)

 

・シークレットキーが管理者権限アクセス可能なものとなっていた(外したつもりが外せてなかったっぽい)

 

 

その後の対処

まず、クライアント側のメンバーのGitHubリポジトリごと削除してもらいました。
そして、公開してしまったアクセスキーとシークレットキーを削除、

また、身に覚えのないEC2インスタンスの削除と、すべてのやるべきことを済ませ、

あとは全力でAWSサポートに返金要求という名の命乞い(もはや比喩ではない)をしました。

 

Let's 命乞い

すべての作業を済ませ、AWSサポート側にメールをします。

 

メールから抜粋

 Hello, AWS support

Thank you for giving me information. These work is already completed. (deleteing key, stopping EC2 instances,and so on.) And now,I've got $3,828 payment request, but I didn't use so much AWS resources. I'm so confused, Please contact me as soon as you find out about it.

 

(^p^)「なんか身に覚えのないものごっつい請求来て困っています、どうにかできませんか?」

 

AWSサポート「・・・」

 

(^p^)「おーいこの件どうなりました?」

 

AWSサポート「・・・」

 

(;^p^)「あの返事・・・」

 

AWSサポート「・・・」

 

こんな感じですぐに返信が来ず、非常に胃の痛い時間を過ごしました。

 

 

このままではらちが明かなかったので、サポートのプランをBasic($0、現地時間の営業時間のみしか対応できない)→Developer(月$30,24時間対応可)のプランにしました。

45万の請求来てるからこのくらいの課金なんていまさらどうってことありません。

 

 

そうしてすぐにサポートから返事をもらい、「基本的にこのようなケースでは支払い義務は発生するが、今回に限り特別に対処することも検討する」とのことで返信を頂きました。

 

すべての行程を終えたあとは支払い免除されることを祈るのみです。

このときのメンタルはまるでパトラッシュです。

 

 

「免除されなかったら情報系の仕事やるのやめてふつうのサラリーマンになろう」

「免除されなかったらどうやって金の当てをつけよう?友人に土下座して回るかな、いっそ闇金かな」

みたいな今思えばしょうもないことを考えていました。

 

そしてついに・・・

 

 

 

f:id:yamatch:20171220225714p:plain

「支払い免除リクエストを出しました。請求チームが動きます。」

請求書をみると・・・

f:id:yamatch:20171220231412p:plain

6593円、つまり・・・

 

無事45万円の支払いを免除していただきました。

 

もうAmazonに一生頭があがらないです。

安堵で思わず泣きました。

お忙しい中対応してくださったAWSサポートの担当者には本当に本当に感謝の気持ちでいっぱいです。

 

そして迷惑をかけたチームのメンバーには申し訳ない事をしたと思っております。

そんななかでも彼らは解決策を探してくれたりして、感謝感謝です。 

 

今後の対策

これからAWSを使うときは、同じ失敗をしないようにしなければいけません。

今回のようなミスを今後防ぐには

  • アクセスキーを発行するときは、AWSアカウントではなく、操作権限を絞ったIAMアカウントのものを発行する(要するに、特定のサービスのみを使えるようにする)、管理者権限は絶対につけない
  • Githubにシークレットキーをハードコーディングしたコードは絶対にうpしない、やむを得ずどうしてもうpしたいときはprivateリポジトリにあげる(awsが用意したgit-secretsなるプライベートキーをcommitさせないツールなんてものもあるらしいです)*3
  • AWSの請求アラート(ある金額になったり、無料枠を超えそうになったらメールで警告してくれる機能)は必ずつける
  • チームで開発するとき、何かアクションを起こすときはすぐに報告、まずそうなことがあったらまずチームメンバーに相談、そして解決策をとにかくググって調べる

 ということを徹底していきたいです。

 

今は無事S3を使って音声認識のシステムを無事使える状態にしてあります。

今後こういったことを守り、アプリケーションを使っていきたいです。

 

 終わりに

この記事を通して皆さんに何を伝えたいかというと、

「無知と油断は身を滅ぼす」ということです。

アクセスキーペアの重要性の話はコンピュータリテラシーやネットワーク、セキュリティの講義で耳にたこができるほど説明されます。

それにもかかわらず、アクセスキーがいかに大切なものなのかを知らずにいた「無知」、

そして「こうしとけば大丈夫やろ~」「まさか自分がそんな不正利用に遭うわけがない」という「油断」、

こうしたある種の傲りがあったからこそ、今回のような事件は起きてしまったのだと思います。

 

このようなしくじりを

起こしようがないようにする「知識の習得」、

起きそうなときにも踏みとどまってしくじりを防ぐ「細心さ」

が必要なのかな、と思いました。

 

今回運よくAWSサポートさんに助けていただきましたが、何度も同じ対応をしてくれることはありません。

次同じことを起こしたらおそらく自腹です。

 

失敗は起きたとしても1度に納めなければいけません。

2度同じ失敗を繰り返せばその時こそ身を滅ぼします。

 

と自戒も込めて皆さんには伝えたいです。

 

 

(;ω;)

ほかのmastの人がすごくためになる記事だったり、なにかに全力で取り組みその裏を見せる素晴らしい記事を書いている中、私はこういうクソみたいなしくじりしか書けないことが本当悔しいし、力不足を感じます。

 

自分は音の信号処理だったり音楽データに関するプログラミングだったりのことを勉強中なので、今後このようなmastの皆で記事を書くような機会があれば、音処理沼に引き込めるようなファビュラスな記事を書ければ、と思います。

 

では。

 

p.s

痛風の話はまたどこかでしたいと思います。

 

 

 

 

 

*1:このような話は何番煎じかわかりませんが書きます

*2:CPU64個、メモリ256GBのインスタンス(一番サイズが大きいやつ)が全リージョン合計200個ぐらい回ってて大草原だった

*3:ほかに何か対策があったら教えてほしいです。

グローバルビレッジのお話

今回はグローバルビレッジのお話でもしようかなと思います。
筑波の宿舎についての記事はたくさんあるんですが、

 

グローバルビレッジの記事はだれかが書いてそうで書いてない気がする。ってことでグローバルビレッジについて書いていこうと思います。

 

住居で迷っている筑波大生の人に参考となれば幸いです。

 

 

基本データ

家賃は月36,000円くらい+光熱費水道代(宿舎価格、だいたい毎月平均800円くらい?)

5人1組でひとつの部屋に住む(これをユニットと呼んでいます)、リビング、トイレシャワールームは共用、個室ありエアコンあり、Wifiあり

ユニット内の一人がユニットリーダーというユニットのまとめ役をする

オートロック、ユニットのドアと個室のドアはカードキータイプ(失くしやすく、不評です)

宅配ボックス、コインランドリーなど

コミュニティステーションというラウンジ的なものがある

 

 

という感じですね。やはり新築だけあってきれいですし、施設も素晴らしいです。

 

 

グローバルビレッジにしてよかった点

きれい

光熱費が安い

宅配ボックスあり

コミュニティステーションが便利で課題をみんなでやりたい時などは集まってやることができる

いつゴミ出ししてもよい(らしい?)

コンビニが近い

留学生と話すことで英語のスキルや国際感覚?が磨かれる

 

 

グローバルビレッジにして悪かった点

コインランドリーの混雑(洗濯機がせいぜい10台くらいしかないので週末になると混雑して洗濯できなくなることも)

同居人と仲が悪くなると最悪

同居人への注意など(マナーが悪い人と一緒になると本当に最悪です。)

 

居心地は基本的に同居人との関係によるのかなと思います。

 

僕は割と一人の時間が好きな人間なうえ、同居人と物の使用や掃除のことや騒音でもめたこともあって、

あまり快適なグローバルビレッジでの生活を過ごせていません。正直はやく引っ越してえ

 

共同生活をすることによりコミュニケーション能力は磨かれるのは間違いないですが、同居人と仲が悪いと居心地が悪くなってしまいます。

 

そこのところをうまくやれるような人だったら楽しいのかな、と思います。

基本的にユニット内にはだれかしらいることが多く、寂しさを感じないと思うので。

 

こんなところでしょうか。何かあればコメントまで。

なつやすみ

記事を書くのは7月ぶりだろうか

長い長い夏休みが終わり、気づけば入学から半年経っていましたね、っていう

夏休みいろんなことをしたのでそれをつらつら書こうっていう

いちおう、自分のやってきたことの備忘録的に

 

アプリケーション開発をした

 

情報系という分野に突っ込んで半年、改めて思ったのは、「過酷な世界だな」ということです。

 

というのは、日々コンピューターを取り巻く技術は劇的に進化していて、

「今日使えた技術が明日になって使えるとは限らない」というぐらいの技術の進歩ぶりです。

そのくせ、ときに古典的な学問(数学・物理など)を知ってなくてはならないため、

「新しい技術を常にキャッチアップすべき、でも流行りばかりを追いかけていてもダメ、地に足をつけた学習も同時にすべき」という、非常に広くのことを学ぶ必要のある厳しい世界なのだな、と実感しました。

 

そして、情報系で生きていくうえで大事なのは手を動かすことなのだということを耳にタコが出るほど聞きました。

 

実際にものをつくったりいろいろ試行錯誤することで勉強にもなるし

座学で学んだことを生かすうえでも重要である、と

 

インターンをやるにしても、実際にものをつくっていないとまず通りません。

 

 

一回ぐらいはチーム組んでなにか作る必要があるなと考え、

授業でろくなものを作ってないレベルの初心者ながら友達を無理やり誘ってアプリケーション開発をやりました。

 

 

開発期間はだいたい2か月、4人のチームを組むこととなりました。

作ったのはiOSのアプリケーションです。

僕はWindowsユーザーでSwiftの知識もなかったため、もっぱらサーバーサイドの開発に携わっていました。

言語はpythonです。

 

 

僕の役割はAPIを使ったプログラミングをすることだったのですが、

APIってなに?JSONってなに?」みたいなその程度の知識から始まったので

かなり苦労しました。

(後半の方はサーバーサイドを担当していたもう一人にだいぶ助けてもらいました・・・)

 

で、締め切り1週間前には外部のストレージを使う必要があることがわかり、慣れないAWSを触っていました。

最終的にはなんとか形に仕上がっているものができ、締め切り日の23時59分に提出を完了し、この日は死んだように寝ました。

 

今回手を動かすことで

かなり多くの知見を得ることができました。

 

が、課題は山積みです。

技術的にも、行動的にも、かなり多くの反省点があります。

 

そうした面を1歩ずつ確実に改善していくことが今後の使命なのだと、

思い知らされました。

 

さわったもの:

Python

Bottle

楽曲認識API

TwitterAPI

WATSON音声認識

heroku (gitも)

AWS

などなど 

 

技術以外でついた能力:

企業とのやりとり・交渉

片付けてない雑務をつぶす能力

企画力

かな、報告連絡相談のうち、相談の部分が弱いためにうまくいかなかったことが多かったのでそこを直したい。

 

 

 

 

車の運転を久々にした

前の大学で所属していたサークルの合宿にOB枠として参加するために東京から新潟まで車で運転しました。

自分は2016年の4月に免許を取って以来、公道で自動車を運転する機会が全くありませんでしたが、今回長い距離のドライブとなったため僕も運転する羽目になりました。

高速で降りるICを間違えたり、峠道で後ろに乗った友人を酔わすなどのさんざんな運転スキルでしたが、大きな事故もなく無事に帰ってこれてよかったです。

f:id:yamatch:20171004052906j:plain

 滝に行ったり…

f:id:yamatch:20171004052959j:plain

キノコがたくさん入ったおそばを食べたり

f:id:yamatch:20171004053107j:plain

牧場にいったり

f:id:yamatch:20171004053226j:plain

高原にいったり


いろんなところに行ったりいろんなものを食べたりしました。

 


車っていいですね。

運転自体は楽しいし、車でしか行けない場所って多いですから。



つくばで車が運転できる機会がくればうれしいな、と思っています。

 

 

と、ブログで書くようなことと言えばこれくらいですかね・・・

ほぼ寝夏休みだったような気がします。

秋学期も始まりスパルタ生活に戻ることとなるので、気を引き締めて生活したいと思います。

では(^p^)

 

 

 

 

筑波にきて3か月くらいが経ったので

今回の記事は自己の振り返りなので特に情報を提供しているわけではありません。

 

ご了承ください。

 

 

筑波にきてもうすぐ3か月、

都会でわちゃわちゃやっていたり、実家で家族と当たり前のように澄んでいたのがもう遠い昔のように感じている。

 

 

編入した目的は「機械系の勉強から逃げたい」とか「なんとなく編入っていうイレギュラーな道も面白いと思った」とかそういう些細な事だった。

 

 

でも入学して、ちょっと興味があるなっていう程度のことを積極的に詰めてやっていったら、

いつの間にか自分がどういう道に行きたいのかっていう方向性も少しだけ見えて、

それに向かって突き進んでいくことがすこしだけできるようになった気がする。

少しだけだけど。

 

 

いままでは、

「こうあるべき」とか、「あっちはいやだからこっち」とか「やりたくないけど負けるのは嫌だから」といった負のモチベーション(と言っていいのかどうかわからないが)から始めることはあれど、

 

何をやりたいっていう

それらとは真逆の、正のモチベーションから物事を推し進めるなんて経験はほとんどなかった。

 

 

それを編入してからは、「こんなの作れたらたのしいよな」っていうモチベーションから徹夜をするまでのめりこむものができた。

 

 

徹夜をする是非についてはわからないけど、

前の自分だったら徹夜なんてせずに適当に途中で終わらせて、

最小限の努力で単位をとろうっていうスタンスで、適度に課題を出さずに

過ごすだろう。

 

 

そういった意味で自分は前と比べて成長することができたのかな、と

 

勉強がいやでいやでたまらなくて、

やるべきことから逃げるしかなかったあのころと比べると成長できたのかなって

 

 

まあ、自分で成長したっていうよりは周りに影響されてっていう部分が強いんだろうが。

流されやすい人間だからな。

 

 

まとめておこうか

 

・これまでやってきたことで筑波にきても役に立ったこと

 調理
 バイトで培ったこまめに掃除する習慣(ただ、共用スペースのみ)

 情報収集能力

 音楽に関する知識

 ストレスをなくすちょっとした工夫

 

 

・筑波にきてついたスキル

 文章の要約力

 論文を読むことに抵抗感がなくなる

 PHP,Pythonのコーディング能力(ぜんぜんできない から ちょっとできる   くらいにはなったかな?)

 データベース系の知識

 虫への耐性

 筋肉(こっちにきて毎日筋トレしてる)

 

 

・筑波にきて失われたスキル(自分がさぼってただけなのだが)

 

満員電車への耐性

 

世の中の動きを知る(TVねえから自分で新聞読むなりしなきゃいけないけど、してない)

 

英語(ちょっとさぼったら全くできなくなってた、グローバルビレッジにいるが全く英語をつかう機会はない)

 

・これからつけたいスキル

 

・計画にそって物事を行う力

   物事の実行が場当たり的。長期的なことをやるとかならずぼろがでるだろう。

 

・集中力

   作業中、注意散漫になりがち。もっと作業効率を高めたい。

 

・安易な道に理由をつけて逃げないこと

   さぼる理由を作らない。少しでも楽しく考える。そうじゃないと自分の場合続かないから。

 

・発信力

   自分の場合、ことの詳細まで全部伝えようとしすぎて発言がよくわからなくなることがある。せっかく要約力を鍛えられたのだから、それを生かして自分の意見を素早く要約してコンパクトに伝えることができるようになる

 

 

 

こんなところかな。

 

もうすぐテストだから、気を引き締めよう。

 

 

もう自分が怠けることで痛い目をみるのはたくさんだ。

かといって気を張りすぎずに、

 

淡々と何をやればいいのか見極めて。