潜伏バグからのロングフリーズ

Javaっぽいエンジニアの徒然草

憧れのQNAPを購入した

松竹梅に加えて特松の4構成の中から、

 ・初めての市販NAS

 ・用途を考えるととりあえず低スペックでOK

 ・いざとなったらHDD入替だけで上位NASへ移管可能

ということで最安のTS-220を購入しました。

 

購入内容一式

・QNAP TurboNAS TS-220

Western Digital Red 3TB * 2 (WD30EFRX [3TB SATA600])

・ミヨシ MCO カテゴリー6準拠フラットLAN ケーブル 15m (TWF-615W)

・ミヨシ LANヨウケーブルクリップ (CAT-FLP)

f:id:monokurotamago:20140622103902j:plain

タバコの箱は比較用です。

比較用に用いていますが、タバコは吸いません。

 

HDDは最後まで悩みました。

WD REDにするのは決定事項だったのですが、容量を2TB, 3TB, 4TBのどれにするか…

結局、購入時点で一番コストパフォーマンスが良かった3TBに決めました。

 

 

箱の中身

・本体

電源ケーブル

・HDD止めのネジ(2.5インチ用と3.5インチ用)

・LANケーブル

・説明書

f:id:monokurotamago:20140622104325j:plain

 

 

説明書は色んなブログで書かれていた通り、実に簡素な内容でした。

HDDを取り付けて、ネジで固定します。

f:id:monokurotamago:20140622104854j:plain

HDD装着後は、電源ケーブルを取り付けてNAS側の準備完了。

簡単!

 

続けてLAN線を配置します。

これが一番大変でした。

ルータのある部屋から洗濯機のところまでLAN線を引いていきます。

LAN線は要所要所でクリップ固定して、邪魔にならないようにします。

配線がようやく終わり、NASと接続すれば完了。

 

 

こうなります。

f:id:monokurotamago:20140622114321j:plain

洗濯機の上部に突っ張り棒でスペースを作ってNASを配置。

ここに置いた理由は、

 ・ルータのある部屋は寝室なのでNASを配置したくなかった

 ・そもそもルータのある部屋はコンセントが不足していた

 ・洗濯機のところはコンセントが余っていた

 ・突っ張り棒でスペースが確保出来た

から。

湿気が気になりますが、コンセントはどうしようもありません。

 

 

NASの管理インタフェースはWebブラウザからアクセスでき、

見ればどう使えば良いか大体分かる洗練されたインタフェースなので安心です。

分からないことがあったらWebマニュアルがあるのでそちらを調べます。

 

NASの初期設定をアレコレ(中略)して、

ミラーリングされていることを確認できたのでNASの設置は完了です。

 

いよいよアクセス…

というところで問題発生して、一つ前の記事にしたネットワーク関連でハマりました。

 

が、それも無事解決でき、GitBucketの導入(後日記事にするかも)まで終わりました。

あとは使いながらQNAPの機能を楽しみます。

 

 

……

………

 

 

先日購入した裸族のカプセルホテルですが、

とりあえずまだWindowsマシンに接続しています。

対応OSがWindowsMacだったのですが、

大抵の市販品はLinux対応とは書かれていません。

それでもLinux対応と書かれていないUSBメモリは大抵マウント可能なので、

NASに裸族のカプセルホテルをつなげてみようかと思っています。

うまく出来ればバックアップに使えそうです。

 

以上。

Wi-Fiルータがデバイス間のアクセスを防御していた

ネットワーク周りでハマったのでメモ。

 

■2014/06/29時点のネットワーク構成

有線ルータの下にマシン3台と無線ルータ、

無線ルータの下にマシン2台が紐づいている形。

どこにもつながっていないマシン2台はお休み中。

 

f:id:monokurotamago:20140629144453p:plain

 

 

■何が起きたか

MacからWindowsへのpingが通らない(WindowsからMacへのpingは通る)。

MacからNASへのpingが通らない(WindowsからNASへのpingは通る)。

Macからインターネットへのアクセスは出来ている。

 

 

■原因追究

WindowsのICMP受信設定 -> 今回は関係なかった。

WindowsMac双方のファイアウォール設定 -> 今回は関係なかった。

有線ルータの設定 -> 今回は関係なかった。

Wi-Fiルータの設定 -> こいつが犯人。

 

 

■対応

とりあえずWi-Fiルータipアドレスを調べため、有線ルータの管理画面にログイン。

紐づいているIPからWindowsマシンなどを除外して、Wi-FiルータのIPを推測。

ブラウザにIPアドレスを入力してWi-Fiルータにログイン。

 

ちなみに使用Wi-Fiルータは[au HOME SPOT CUBE]。

外側へのアクセスは許可していたが、内側へのアクセスを止めていた(隔離設定)。

 ①上部メニュー(Wi-Fi設定)をクリック

 ②左部メニュー(隔離設定)をクリック

 ③該当のSSIDの隔離設定を無効化

これで解決。

 

f:id:monokurotamago:20140629143217p:plain

 

 

以上。

パスワードが破られたみたい

メールを整理していると、

大昔に利用していた某サービスから

 「普段と違うアクセスがあったよ」

という通知が来ていました。

 

普段と違うも何も、何年もアクセスしてません。

久々にログインを試みると、アカウントがロックされておりました。

どうやら破った犯人が何か悪さをしたようです。

 

パスワードに関する意識が皆無だった頃に登録したサービスなので、

パスワードは簡易であり、同時期に利用していたサービスで使いまわしていました。

ということで、使いまわしパスワードをランダムな英数字の羅列に変更しました。

(どれも今は使ってないサービスなので退会した方が良いかも)

 

最近利用しているサービスは複雑なパスワードにしていますが、

使いまわしが皆無かと聞かれるとそうではありません。

ですので、この機会に近々パスワード管理を一新しようかと思います。

 

クラウド上で管理するサービスが多数ありますが、

個人的に「パスワードをクラウド上で管理するのはナンセンス」なので避けます。

 

以前少し試したことのある「ID Manager」にはMac版はありません。

マルチプラットフォーム対応「KeePass」は少し見た感じでは良さそうな印象です。

セキュリティ甘々な管理ツールを自作して遊ぶのも面白そうです。

セキュリティそっちのけであんな機能やこんな機能を…(*´Д`)

 

閑話休題

 

この記事を読まれた方で、

パスワード管理が甘い認識がある方が居ましたら、

手遅れになる前になんらかの手を打つことをお勧めします。

リブセンスの新卒研修から生まれた「Pacirii」から見えたもの~シェアで体験できること・できないこと

リブセンスの新卒研修から生まれた「Pacirii」から見えたもの~シェアで体験できること・できないこと

http://gihyo.jp/news/interview/2014/05/2301

 

新卒研修でwebサービスをリリースするというのは面白い試みだと思います。

立案〜設計〜実装〜テスト〜リリースの一連の流れを実際に経験したことは、研修後の実務で必ず役に立つでしょう。

 

何よりも「研修のための研修」ではなく「成果物が実際に利用される」というのは大きいと感じます。

一般に研修というと「試しに何か作る」ことはするものの、その作成物が「実際に利用される」ことは前提とされていないことが多いです。

つまり、

  コードを書いた ▶︎ 動いた良かったね ▶︎ おしまい ▶︎ (コードなんて動けばええんや!)

となりがちです。

そうではなく、

  コードを書いた ▶︎ 動いた ▶︎ 利用者からフィードバック(があるかも) ▶︎ 改修(が発生するかも)

という可能性を作ることで、コードのその後を意識させることが出来ます。

 

コードのその後を意識すれば、意識しない時と比較して、自然と奇麗なコードを書こうという考えに至る可能性が高まります。

仮にその発想に至らなかったとしても、実際に改修が発生した際に「つい最近自分が書いたはずのコードなのに何書いてるか分からない...」という経験をすれば、その後は奇麗なコードを意識するはずです。

もちろん、コードのその後を意識せずに改修も発生しなければ、研修のための研修と同じ結果になってしまいますが、それはそれで仕方がありません。

 

頭ごなしに奇麗なコードを書けと言われただけでは本質は理解出来ず、動けば良いという発想が定着しかねません。

最初が肝心です。

どうせ時間とお金をかけて研修を行うのであれば「動いたOK」で終わらない内容にすることで、より内容の濃い研修とすることが出来るかも知れません。

 

FEARLESS CHANGE 第三章部分抜粋

FEARLESS CHANGE

アジャイルに効くアイデアを組織に広めるための48のパターン

第三章の内容を部分抜粋したメモです。

 

書評タグをつけていますが、書評ではなく単なるメモの位置づけです。

独断と偏見で意訳した理解を記載しているため、著者の言っている内容とは異なります。

 

 

コネクタ

組織内になにかを広めたいならば、多くの人とつながりを持つコネクターを通すと楽。

信頼関係のある人からの情報は、興味を持たせやすい。

 monokurotamagoが誘う ▶︎ 何言ってんだこいつ

 コネクターが誘う ▶︎ あの人が言うんだからやってみるか

 

組織に100人居たとすると、100人全員に話を通すのは大変。

全体宛に何か出しても大抵スルーされる。

個別に誘う必要がある(後述する個人的な接触)が、一人で100人に声かけするのは無理。

例えば野球部のコネクター、飲み部長のコネクターなどに話せば、業務時間外にも広める事ができる。

 

 

■やってみる

誰かに承認してもらってから始める ▶︎ 失敗したときに責任を負うのは承認者

そうなると承認してくれる人なんていない。

自分からやらないと始まらない。

経験があれば押せるが、経験がないうちは水面下でやってみる。

経験積んでから実績を供えて提案すれば説得力がある。

 

 

■次のアクション

学んだことをどう活かすかを参加者に確認する。

学んだだけではそれをどのように利用するか分からないため、結局何も出来ない。

 

 

■個人的な接触

全体宛▶︎流される

個人的な接触でその人にとってどれだけ有用であるかを話すと聞いてもらえる。

 

 

■経営層の支持者

何かを行うためにはなんらかのリソースが必要になる。

本とか人とか、つまりは金とか。

これらのリソースを動かすには経営層の支持が必要になる。

それに、上から言われたら大抵下まで通る。

でも上からのごり押しは反発招くのでそこは巧くやる必要あり。

 

 

■みんなを巻き込む

あいつらなんかやっているみたいね、と思われているだけだと協力されない。

自分に関係する事と思う事で円滑に進む。

伽藍とバザールにもあるように、作業者が増えれば自分の作業は楽になる。

それに、成果物の品質も上がる。

 

 

■ちょうど十分

いきなりあれこれ叩き込むと理解しきれない。

初めは基本的なことだけにする。

発展的なことはこんなこともあるんだよ〜程度にとどめ、参考文献を提示しておく。

興味があったら見てみて。質問あったら受けるよ。これでOK。

はじめはこんな感じにとどめないとついてこれない。

 

 

■お試し期間

新しいアイデアに懐疑的な人は必ず現れる。

延々と異議を唱えられるような状況になったら

「○ヶ月だけ試験的にやらせてもらえないか」と話をもっていく。

試験期間でダメなことが明らかになれば即辞める。

試験は自分が中心で執り行う。

ここまで言えば承認される可能性が高い。

そしてお試し期間で結果を出せば、それが正式に採用される道に繋がる。

 

以上。

Java Day Tokyo 2014

2014/5/22(木) に品川プリンスホテルで行われたJava Day Tokyo 2014に行ってきました。

Java Day Tokyoは、2013年から初まって今年で2回目の開催となるイベントです。

 

品川駅から2分の距離であり、建物自体も大きくて迷うはずは無いところですが、

案の定30分程迷いました('A`)

 

会場は基本的に全席テーブル+座り心地の良い椅子でした。

人気セッションでは即席で追加されたと思われるパイプ椅子や、

立ち見の出るセッションもありました。

電源なし、wifiなしの環境だったので、苦労された方が多数出たようです。

この辺りの環境は事前に告知していただけると参加者としては助かります。

 

教育用レゴロボットMindstormsが会場で販売されていたり、書籍が10%割引で販売されていました。 

Mindstormsと言えば大学の授業で扱った事があり懐かしいものです。

 

全体を通してのキーワード

IoT(Internet of Things)

 

それでは個別に記載していきます。

以下継承略させていただきます。

 

 

■基調講演

#jdt2014_K1

 

会場入口には電子パネルが。

f:id:monokurotamago:20140522094954j:plain

 

基調講演会場。 流石は品川プリンスホテル! 豪華です。

f:id:monokurotamago:20140522095418j:plain

 

オープニング画面。 この後オープニングムービーが流されました。

f:id:monokurotamago:20140522100233j:plain

 

基調講演は基本的に英語のセッションなので内容はあまり理解できていません。

多くの人が入れ替わり登壇する形で執り行われました。

 

 

Nandini Ramani

javaは900万人以上の開発者がいる。

java8ではラムダ式が取り入れられた。

java se8の日本語ドキュメントがJava Day Tokyo 2014の開かれた当日に公開された。

 http://docs.oracle.com/javase/jp/8/

java9 open jdkに貢献してもらえると助かる。

既に総人口よりも接続デバイス数の方が多く、今後は更に差が開いていくはず。

 

 

NECの事例紹介

 papero(ロボット) Java SEで動いている。

   f:id:monokurotamago:20140522103916j:plain

 

 

パナソニックの事例紹介

 Java MEで電子マネー決済システム。

 

 

Cameron Purdy

Java EE 7のお話からのJava EE 8のお話。

Java EE 8 のテーマ

 HTTP2.0, JSON Binding, Server-Sent Events(SSE), JAX-RS MVC

JAX-RS 2.0で唯一廃案になったMVCJava EE 8新機能の上位に入ったらしい。

Java EE8リリースは2016年のQ3になるとのこと。

 

 

Stephon Chin

 Lego Mindstorms, DUkePad, ChessRobot

 

Legoで作られたDukeの登場。

f:id:monokurotamago:20140522111422j:plain

 

レゴのDukeSSHで接続して。セグウェイ

Duke, 大地に立つ!!

プルプルしながらバランスをとるデモ。

f:id:monokurotamago:20140522111851j:plain

 

内部の説明のために首をもがれるDuke.

説明が進むにつれて分解されていき、最後は影も形もない状態に。

TwitterではDuke公開処刑と盛り上がり。

※残忍であるため画像はありません

 

DukePadの説明

構成部品としてRasBerryPIが組み込まれていました。

Padにしては分厚い印象です。

 

ChessRobotの説明

DukePad -> JavaFX on DeskTop -> RealRobo 一連の流れでチェスのデモがありました。

CGは美しく、チェスの駒になったDukeがかわいいw

 

 

Simon Ritter

Oracleがリーダーシップをとって、コミュニティと連携とってますとのこと。

 

 

Yusuke Suzuki

日本Javaユーザグループ(JJUG)について。

2014年5月現在で会員数2290名、Javaに関するイベントやってます。

情報の入手法

 ML

 http://www.java-users.jp/

 twitter @JJUG

 Facebook?

会員数はML登録者数でカウントしているとのこと。

 

 

情報少なくて申し訳ないですが、基調講演に関しては以上です。

 

 

JavaScript Running On JavaVM: Nashorn (新JavaScriptエンジン)

#jdt2014_d1

西川 彰広 (江草家の人々の江草ロジ子さん)

 http://orablogs-jp.blogspot.jp/p/blog-page.html

 

f:id:monokurotamago:20140522132902j:plain

 

agenda

 Nashorn

 Server Side JavaScript

 Nashornの今後

 

Nashorn

JavaScript Engineの一つ。

Rhinoの置き換えで作られた。

JavaJavaScript間での相互呼び出しが可能。

ドイツ語読みで「なすほん」

 

JavaからNashornの呼び出し例

ScriptEngineManager manager = new ScriptEngineManager();

ScriptEngine engine = manager.getEngineByName("nashorn");

~~

~~

 

JavaScriptで「こんにちは」と表示するプログラムを、

Java側でJavaScriptを2秒ごとに呼ぶプログラムを書くと、

2秒ごとに文字が出る。

実行中にJavaScriptに変更を加える。

「こんばんわ」

そうすると、少し時間がかかるが、実行中に変更を検知して表示される文字が「こんばんわ」に変更される。

 

当然、Nashornからjavaも呼び出せる。(相互呼び出し)

 

Nashornならではの拡張は?

java typeの参照が取得出来る

  Rhinoと同じ方法でも取得出来るが、こちらの方法を推奨。

  var HashMap = java.type('java.util.HashMap')

 何が違うの?

  ▶︎ エラー場所が適切に表示されるようになった。

    以前の書き方だと、離れた場所でエラーを検知してしまうことがある。

 

Script functionをLambdaオブジェクトやSAMインタフェースを実装するオブジェクトに自動変換してくれる。

 

Scope and Context

変数の衝突を避けるために、新しいグローバルスコープを作ってそちら側にロードする、といったことができる。

 

Server Side JavaScript

Node.js on JVMをやろう!

 ▶︎ Avater.jsを作った。

  Node.jsで使えるモジュールはそのまま使える。

  Avater.js = Node + Java

    ※Threadも含めたjavaテクノロジが活用できる

 

Avater EE

  Avaterは死んでない!

  Avater is not dead!!

 

Nashornの今後

 スクリプトコンパイルしてバイトコードするときに、今はスレッドしか持てない。

 他のスレッドは前のスレッドのバイトコードが利用出来ない。

 これを解決したい。

 Java 8のupdateの中で対応される予定。

 

 

Javaを活用するユーザー企業の最新事例ご紹介

#jdt2014_d2

製品紹介の印象が強かったので細かい記載は省略します。

f:id:monokurotamago:20140522143412j:plain

 

 

Javaアプリケーション開発におけるテストとTDDの実践

#jdt2014_C3

f:id:monokurotamago:20140522154128j:plain

 

渡辺 修司(Junit実践入門の著者)

自動化テストの成熟度

レベル0 自動化テストしていない。

1 一部テストのみ

2 主要部分はやってる。CIはじめた

3 アーキテクチャレベルでやってる

4 開発プロセスにテストをはじめとした「自動化」が組み込まれている

5 4+さらに改善を続けている。

UTは基本スキル。やったらやっただけレベルが上がる。

社内でテストの勉強会やると良い。

 

CIとUTは手作業したら負け。Jenkinsしましょう。

 

自動化のメリット

・コスト削減

・手作業のミス

・コンピューティングリソースを有効活用

・繰り返し何度もテスト出来る  ◀︎ これ大事

・楽しい

 

UTの特徴

・自動的に実行可能なプログラム

・実行コスト < 実装コスト / 手動テスト

・変更の影響がなければ継続利用出来る

早い段階でテストを行うことで、テストの実行回数が増える、間違いに気づきやすくなる。

リグレッションを防止するのではなく、起きた場合に即座に修正できる。

EC2でJenkinsするとリソース確保が簡単。

 

DB連携

DAO, Repository, EntitiyManagerあたりを使うことが多い。

永続化層のUT戦略は2つある。

 外部システムに依存する部分はモックとする方法。

 RDBは実質的にシステム内部とみなす方法。

  ▶今回はこっちの説明。

 

4 Phase Test

初期化

 DBデータの初期化

  あるべき状態にリセットする。

  関連テーブルの削除。

  シーケンス

  システム時間

  初期化にかかる処理時間

実行

 1テストケースで1SQL相当にする。

検証

 selectはそうでもないが、update やdeleteは検証が難しい。

後処理

 次のテストの初期化に任せて何もしない。

 こうすると、失敗したテストのデータが残るので、失敗発生時に役立つ。

 

DbUnit

 Junit3のころに作られたライブラリ。

 

cmtest-db

 DbUnitをJunit4対応したラッパー。

 

その他のポイント

 なるべくローカル実行

 システム時間に依存しない

 

 

木村 貴由

統合テストの自動化

http://nekop.github.io/slides/Arq.html#/

 

自動化されていない統合テストをすると...

 ▶︎ 死んだ魚のような目でスクリーンショットを取り続ける人

 

arquillian(あーきゅりあん)

 統合テストのフレームワーク

 モックするな!本物に近いテストをしよう!!というコンセプト。

 本物の実行環境へデプロイしてテストすることが主機能。

 IDE連携も出来る。

 Reporterという機能でデスクトップをビデオ撮影できる。

  ▶︎ 大量のキャプチャ画像より映像化した方が便利かも?

 

 

和田 卓人 (TDDの話)

テスト駆動開発入門の書き出し「動作するきれいなコード」

 

TDDのサイクル

 いつものサイクル。Red - Green - Refactor

 

TDDと黄金の回転

 いつもの図。

 リファクタリングやらなくなると回転が壊れる。

 日々の作業にリファクタリングを埋め込むことが大事。

  ▶︎ 後回しにすると、リファクタリングするために許可を得る必要が出る。そうなると許可は出ない。

 

TDD導入効果(MS, IBM)

 TDD導入によって、2社ともコード実装時間は増えるが、欠陥も減った。

 実装時間が2割増えて、欠陥が7〜8割減るといった感じのデータ

 

TDD

 開発工数は増える。が、デバッグ工数が減る。

 デバッグ工数減る方が大きいので、全体的な工数は減る。

 

テストは品質を上げない。

体重計のように、どのぐらいの品質か把握するためのもの。

把握した後にどういう行動をとるかが大事。

 

カバレッジ

 カバレッジも計器の一つ。

 カバレッジを上げる、100を目指すということにはあまり意味がない。

 カバレッジに使われるのではなく、自分たちでカバレッジを使いこなす。

 

TDDは死んだ By DHH  2014/4/24

 タイムリーな話題。

 結論は...IS TDD DEAD? というサイトで現在進行形で議論されてる。

  f:id:monokurotamago:20140522163523j:plain

 

こだわるなかれ

 テスト駆動にこだわるな

 テストファーストにこだわるな

 ユニットテストにこだわるな

 テストの速さにこだわるな

 テストの網羅性にこだわるな

  ▶︎ 自らが品質に安心できればそれでよい

 

テスト駆動開発とは、あなたとコードの間の話。

自分で手を動かして考えよう。

 

 

J2EE世代からJava EE世代へ移行せよ

#jdt2014_C4

岩崎 浩文

f:id:monokurotamago:20140522164632j:plain

 

1999 -> 2014の15年間で何が変わった?

J2EEが出た1999はISDNの時代。携帯も折りたたみの前のPHSみたいな形。

javaも当時はEnter priseでは使えないという烙印を押されていた。

 

EE7, SE8に対応したwebServerは公式のものしかない。

他はβ版なら動くものがちらほらあるぐらい。

 

昔の構成Struts ▶︎ 今の構成 JSF, JavaFX

JavaServer Faces (JSF)

 

開発環境

今はNetBeans or IntelliJ Idea

多くの人はeclipseで止まっている。

 ▶︎ 企業もStrutsで止まっている

 

2014年にキャッチアップしないと死んじゃうよー。

つい最近、Strutsゼロデイ脆弱性出たよね。

windows XP, Office2003死にました。

来年Windows Server2008も死ぬ。

 

Struts -> JSFに移管するには?

EJBを使うところは変更なし。

JSF1系はヒドい。使うならJSF2系にしましょう。JSF1系ダメ、絶対。

Java EE7の標準はJSF2.2 これで作れば安心。

JSFではJSP使わない。

文字書き換えてリロードするだけで画面が更新される(やっと)

やっぱり移管するには書き換え多い。

 

 

 

【オマケ】

イベントのショップが出ていたので、JavaのTシャツとペンスタンドを購入。

帰り際にアンケートを提出して手帳をいただきました。

昨年度は帰り際にメモ帳をいただきましたが、こちらにはJava Day Tokyo 2013 と記載されていました。

今年もらった手帳には Oracle Java としか書かれておらず、少し残念ですが、質感は昨年のものより高級です。

入場先着200名のアイテムは、先述した通り迷いに迷ったため入手できませんでした。

 

 

以上。

musicデータの整備メモ

いろいろと環境が新しくなったので、

少しずつ所持CDをリッピングしなおして整備しようと思います。

そのためのメモ書きです。

 

これまでやっていた方法

 ①Windows Media Playerで取り込み(mp3, 128kbps)

 ②Mp3TagでAmazon.comのデータでタグ付け

  (適当にやったため、誤ったタグがちらほらある状態)

 

今回採用した方法

 ①CDex + Lameで取り込み(mp3, 320kbps)

 ②Mp3TagでAmazon.comのデータでタグ付け

 

フォルダ構成 (CDexのデフォルト設定)

 第一階層:アーティスト名

 第二階層:CD名

 第三階層:曲ファイル

 

ファイル命名規約 (CDexのデフォルト設定)

 トラック番号-曲名.拡張子

 (ex) 01-モノクロ卵.mp3

 

環境整備とか言っておいて、基本デフォルト設定でこだわりは無いです。。。

 

MP3を採用した理由

 ・高ビットレートではAACより良い

 ・汎用性最強

 

320kbpsを採用した理由

 ・聞き分けなんて出来ないので正直128kbpsでも充分、とは言え大は小を兼ねる

 ・ストレージが大量に余っている

 ・メイン端末がipod classicなのでファイルサイズ大きくて平気

 

以上。