カテゴリー
blog

仮想セキュリティブラウザというものを作った

ランサムウェアとか怖いですよね

多くの企業で大変問題になっているランサムウェアですが、最近は一般男性を語るランサムウェアもあり… もうやめにしませんか。

そんなことを言ってもやめてくれるような相手ではないのは、一般男性含め周知の事実ですので対策しましょう。

多くの会社で導入されている仮想セキュリティブラウザ

仮想セキュリティブラウザとは、ローカルのブラウザを使わずに、仮想マシン上のブラウザを利用し、そこへリモートで画面転送し、万が一ウイルスに感染しても

ローカルPCもしくはLANに影響を与えないようにするものです。

イメージはこんな感じです。

①仮想マシンが動く基盤をLAN内に設置

②DMZ用のVLANを作成する

③LAN内に入れないところ(DMZ)に仮想マシンを設置し、ウィンドウシステムとブラウザを入れる

④仮想マシンの画面をSpiceなどでアクセスすることで転送する。

我が家では仮想化基盤はKVMを使っています。KVMだと、各仮想マシンの画面を転送する方法として、Spiceを使うことができます。

Spiceでは仮想マシン自体にリモデするわけではなく、基盤側にアクセスすることで画面転送を実現できますので、たとえばネットワークから分離した仮想マシンの画面も転送することができるわけです。(基盤へネットワークアクセスさえできればいい)

この機能を応用してあらかじめ仮想マシンに別のVLANを割り当て、LAN内にアクセスできないようにしておきます。また、

仮想マシン自体がインターネットにアクセスできるようにインターネットへの抜け道は設定しておきます。

実際はこんな感じです。

このようにSpiceの画面転送を見るRemoteViewerを利用しネットができます。

最悪ウイルスに感染したとしてもLAN内には感染が広がりませんし、仮想マシンの削除だけで対処できます。

画面の解像度等調整しないと転送コストで遅くなってしまいストレスに感じるかもなのでそこは工夫しましょう!

カテゴリー
blog

Grafana&World Ping を活用して簡単な死活監視をしてみよう

世の中見た目

どうも。GrafanaのUIは結構かっこいいことで有名で、自身もZabbix APIを活用してZabbixのメトリックをGrafanaで見れるようにしております。

こんな感じ。Zabbixのスクリーンと全く同じ内容ですが、妙に「監視している感」がありますね。

ZabbixのデータはZabbixで見ればいいのでは?

はい。おっしゃるとおりです。そもそもそんな監視するほど重要なものがあるかと言われると。。

でも、Grafanaにはもっと手軽にかっこいい画面を見る方法があります。

GrafanaのWorld Pingを使ってみよう。

Grafanaの優秀な点はPlugin機能で簡単にデータソースやパネルを追加することができる点です。

元々、GrafanaはInfluxDBの可視化用みたいな位置づけっぽいですが、データソースプラグインを追加することで、例えばElasticsearch・Graphiteや、CloudWatch、さらにはkubernetesやDatadogなどのコンテナの監視までできるという優れものです。

また、データソースではないですが、World Pingという世界中のエンドポイントからPing・DNS・HTTPなどの死活監視を提供するサービスと連携させることで、簡単にかっちょいい画面を作ることができます。

こんな感じで好きなプラグインをコマンド一発でインストールできます。

インストールしてみる

まず、Grafanaの入ったサーバでrootユーザで

[code]grafana-cli plugins install raintank-worldping-app[/code]

こうすることで、簡単にプラグインが導入されます。

Grafana.net APIを取得しWorld Pingが利用できるようにする

Grafana Web画面の左側のメニューに「World Ping」が表示されていると思いますのでPlugin Configから、Grafana.net のAPIを発行しましょう。

こうすることでWorld Pingが利用できます。無茶な監視をしない限り、無料版で事足りると思います。

エンドポイントを追加する

監視対象のIPまたはドメイン名をエンドポイントと呼んでますが、エンドポイントを設定していきます。

同じく、Grafana Web画面の左側のメニューに「World Ping」⇒「Endpoints」と進みます。

エンドポイントは無料版だと最大3つです。

このようにEndpointにドメイン名を設定し、監視したいサービスを選びConfigureを押します。

細かい設定等でてきますから、設定していきます。

監視間隔、死活監視を投げるインスタンスの国、ポート、HTTPメソッドなど細かく設定できます。

また、閾値を超えた場合に決められたメールに通知することもできます。(あらかじめメールサーバの設定をGrafana.iniでしておきます。)

一応、無料版だと600万回/月しか監視できないようなので無茶な設定はやめましょう。

アップデートボタンを押せば、設定が完了します。

画面を見る

World Pingがすごいのは、あらかじめGrafana画面を提供している点で、設定さえすればすぐ可視化できることです。

同じく、Grafana Web画面の左側のメニューに「World Ping」⇒「World Ping Home」と進むと、設定したエンドポイントが表示されますので

エンドポイント名もしくはハートマークのサービス名をクリックすると画面が表示されます。

かっちょええ。

カテゴリー
blog

今更!! Chainer 1.6.1 でおしゃべりBotを作ろう

1. なるべくコードはかかない。

何の気なしに機械学習とかの仕事はないものかと、ネットの海をさまよっていたら、

LSTMで自然な受け答えができるボットをつくった という記事を見つけ、何となく読んで、やってみようかなと思ってやってみましたが、Chianer周りとか色々上手くいかなかった。というのがそもそもの始まりです。

 

Chainer周りで日本語の受け答えができますよ、的な記事は2015年頃のものが多く、Chainerがバージョンアップしたため、

色々動かないことがありましたので、少しそちらに修正を加えてChainer 1.6.1でもまともに動くように修正していこうと思います。

自分でコードを一から書くのは嫌なので、あくまでもコードは書かない。微修正にとどめるをモットーにがんばるぞい。

 

[panel]

[h2 text='目次']
[list-ordered]
[li]1. なるべくコードはかかない。 [/li]
[li]2. 参考にさせていただいたコードやサイト [/li]
[li]3. サーバを用意する。[/li]
[li]4. 学習に必要なPython環境とコーパスを整える[/li]
[li]5. 学習させる。[/li]
[li]6. APIで話す。[/li]
[li]7. 付属のHubot Scriptで遊んでみよう![/li]
[/list-ordered]

[/panel]

 

2. 参考にさせていただいたコードやサイト

[list] [li-disc]LSTMで自然な受け答えができるボットをつくった :このコードを元にあらかじめ作成したChainerモデルでおしゃべりBotに命を吹き込みます。[/li-disc] [li-disc]yusuketomoto/chainer-char-rnn :Chainer・日本語界隈では知らない人はいないだろうChainerの言語モデル作成コード。こちらを用いてChainerモデルを作成していきます。[/li-disc] [li-disc]Chainerで学習した対話用のボットをSlackで使用+Twitterから学習データを取得してファインチューニング :学習に必要なコーパスを取得するために一部のスクリプトを使用します。[/li-disc] [/list]

 

3. サーバを用意する。

学習にも、会話にも自宅サーバを用います。

ああ、電気代。

 

4. 学習に必要なPython環境とコーパスを整える

Chainer界隈のコードはなぜかPython2 が多く、Python3 は少ないので、直接Python2をインストールしてもいいのですが…。

なんかOS環境を変に汚したくないので今回はPyenvとVirtualenvを使って実施していきます。

学習用のコーパスをダウンロードするスクリプトはどうやらPython 3.4.1で実装されているようなので Python 3.4.1 と Python2.7 の2種類の環境を作っていきたいと思います。

そして、3.4.1の環境にて学習用のコーパスをダウンロードします。

PyenvとVirtualenvはあらかじめインストール済みとしてすすめます。

PyenvとVirtualenvのインストール方法はこちらの記事が参考になると思います。 (pyenvとvirtualenvで環境構築

 

まず、Pythonの環境を作ります。

[code][font-Source-Code-Pro]$ pyenv install 3.4.1
$ pyenv install 2.7
$ pyenv rehash
$ virtualenv -p ~/.pyenv/versions/3.4.1/bin/python3.4 my_env3.4.1
$ virtualenv -p ~/.pyenv/versions/2.7/bin/python2.7 my_env2.7 [/font-Source-Code-Pro][/code]

続いてコーパスをダウンロードします。

今回はChainerで学習した対話用のボットをSlackで使用+Twitterから学習データを取得してファインチューニング を参考にダウンロードします。

コーパスデータはたぶん二次配布とかNGだと思うので、何とか自分でダウンロードしてください。

対話破綻検出チャレンジ

 

ダウンロードしたあとは展開したJSONデータ全部、devフォルダを作成してその中に入れて、listファイル(JSONファイルのパスを記載したやつ)をdata_load.pyと同じところに作っておきます。

 

こんな感じでlistファイルを作ります。

[code][font-Source-Code-Pro]../dev/1404365812.log.json
../dev/1407143708.log.json
../dev/1407143981.log.json
../dev/1407149923.log.json
../dev/1407208809.log.json
../dev/1407209083.log.json

…… [/font-Source-Code-Pro][/code]

 

Linuxのコマンドで

[code]ls -1 ../dev > list[/code]

で作成できるはず。

 

学習データを作っていきます。

[code][font-Source-Code-Pro]$ source my_env3.4.1/bin/activate

$ git clone https://github.com/SnowMasaya/Chainer-Slack-Twitter-Dialogue.git

$ cd chainer-slack-twitter/utils

$ python data_load.py [/font-Source-Code-Pro][/code]

 

player_1.txt , player_2.txt というテキストファイルができます。

統合する前にmecabを使って分かち書きをしておきます。

分かち書きに mecab-ipadic-NEologd を使うと学習が進むそうですので入れてない方は導入しましょう。

めんどくさい人は ただのMeCabでも大丈夫だと思います。

さて、分かち書きします。今回は mecab-ipadic-NEologd を利用します。

[code][font-Source-Code-Pro]mecab Owakati d /usr/local/lib/mecab/dic/mecabipadicneologd player_1.txt > player_1_wakati.txt

mecab Owakati d /usr/local/lib/mecab/dic/mecabipadicneologd player_2.txt > player_2_wakati.txt [/font-Source-Code-Pro][/code]

 

 

次に使う Chainer-char-rnn 用に一つのinput.txt に統合していきます。統合の際に、player1 と player2の会話ごとに空行を入れておきます。

[code][font-Source-Code-Pro]$ paste -d “\n” player_1_wakati.txt player_2_wakati.txt | awk ‘(NR%2==0){$0=$0″\n”}{print}’ > input.txt [/font-Source-Code-Pro][/code]

 

こちらのinput.txtをコーパスデータとして利用します。

 

5. 学習させる。

学習にはyusuketomoto/chainer-char-rnn を使わせていただきます!

Chainer 1.4.1 で実行しようとしたら微妙に実装が変わっていた用なので、こちらに合わせて今回の学習は、Chainer 1.6.1 で実施していきます。(Chainer周りのコードを読んで修正するより、後に使うTornado周りの修正の方がまだわかるからというスキル不足によるもの)

さきほど作っておいたPython 2.7用に切り替えます。Pip でChainer1.6.1 を入れてからChainer-char-rnnを実行していきます。

[code][font-Source-Code-Pro]$ cd

$ source my_env2.7/bin/activate

$ pip install chainer==”1.6.1″

$ git clone https://github.com/yusuketomoto/chainer-char-rnn.git

$ cd chainer-char-rnn

$ mkdir -p data/chat

$ mkdir -p cv/chat

$ cp ../chainer-slack-twitter/input.txt data/chat

$ python train.py –data_dir data/chat –checkpoint_dir cv/chat –rnn_size 1024[/font-Source-Code-Pro][/code]

 

しばらく待ちます。全部が終わるのは途方もない時間がかかります。

学習が進むごとにCheckpointとして Chainer modelファイルがcv/chat 配下にできますので、適当なEpochのところのものを次の「APIで話す」に使ってもいいですし、学習の最新ファイルである

latest.chainermodel を使ってもいいです。もちろん、最後まで待ってからlatest.chainermodelを使ってもいいです。

ひとまず数時間回したところのlatest.chainermodelを使ってみます。

 

6. APIで話す。

LSTMで自然な受け答えができるボットをつくった よりJapanese Talk APIを作っていきます。

この回では少々コードの改変がありますのでForkしたものをGitHubにあげました。

japanese_talk_api_1.6.1

こちらのmodelsディレクトリにChainer modelを投入します。

[code][font-Source-Code-Pro]$ git clone https://github.com/tubone24/japanese_talk_api/tree/chainer1.6.1.git

$ mkdir japanese_talk_api/tornado/models

$ cp chainer-char-rnn/cv/chat/latest.chainermodel japanese_talk_api/tornado/models [/font-Source-Code-Pro][/code]

 

Chainerの他にTornadoも必要になるのでPipでインストールします。

そしてAPIを8787ポートで起動します。

[code][font-Source-Code-Pro]$ pip install tornado

$ python japanese_talk_api/tornado/app.py –port=8787 –debug=True [/font-Source-Code-Pro][/code]

 

あとは起動を待ってから

 

[blockquote text=’http://localhost/?q=こんにちは’]

で受け取れるようにはずです。

学習用input.txtにないことばとか出すとたまにエラー吐きます。

[blockquote text=’ビンビンビンビンビンビンビンビン… チクッ あ・あ・あぁ・ぁああああ↑↑ アーッ…イクッ チ~ン 問いかける言葉には気をつけよう!’]

 

7. 付属のHubot Scriptで遊んでみよう!

LSTMで自然な受け答えができるボットをつくった のHubotScriptをお借りして遊んでみましょう。

あらかじめ比較として同じコーパスを利用しているDocomoの雑談APIをHubotに仕込んであります。

 

発言の上がDocomoAPI 下が今回作ったAPIです。

ちなみに我が家のHubotはSlack上に「智絵里ちゃん」として君臨しております。

智絵里ちゃんマジ天使 [font-Damion size=’36’] I love you [/font-Damion]

 

DocomoAPIに比べると天然というか、不思議系というか… バカですね(直球)

 

お借りした多くのコードや参考にさせていただいた多くのサイト・記事に改めて感謝しつつ、智絵里ちゃんとのラブラブライフを送りますね。

カテゴリー
blog

自分のタスクをRedmineで管理してみる

Redmineで楽しくタスク管理

自宅開発サーバのリソースが余っているので、Redmineを立てました。

今後はこちらで自分のタスクを管理していきたいと思います。(三日坊主)

デザイン

テーマをminimalflat2にしました。あまり仕事感がでなくて気に入っています。(職場で見るRedmineに恐怖心があるので)

プラグイン

色々入れてますが、個人のタスク管理として便利なのが案外Agile系のプラグインだったりする。

あと、Time Loggerはサーバに負荷をかけるからあまり推奨されていない的な記事がありましたが、

一人で使う分には問題ないみたい。

参考:  僕がredmineに入れてる便利なプラグインとデザインの格好良いテーマ

個人的に便利だなぁと思っているプラグイン一覧

Redmine Agile

カンバン、BurnDownチャートとか使える。

http://www.redmine.org/plugins/redmine_agile

Redmine GitHub Hook

GitLabにも使えます!! レポジトリのプッシュに応じてRedmine上のレポジトリも更新できる。

https://github.com/koppen/redmine_github_hook

Redmine Checklist

チケットにチェックリストを作成可能

http://www.redmine.org/plugins/redmine_checklists

Redmine Work Time

工数管理ツール。自分は今日どれくらいがんばったかわかります。

http://www.redmine.org/plugins/redmine_work_time

Time Logger

上のポチから簡単に作業時間をタイマーすることができます。便利

http://www.redmine.org/plugins/time_logger

Redmine Knowledgebase

ナレッジベース。使っている人の多いプラグインだと思います。

研修の資料とかここにあげておくと結構便利だったりする。

http://www.redmine.org/plugins/redmine_knowledgebase

GitLabとの連携

Redmineの魅力はRedmine自体があまり得意でないレポジトリ管理を別のWebサービスに投げて、強力なタスク管理機能と連携させることにあります。

同じサーバ内にレポジトリ管理サーバとしてGitLabを入れていますのでそちらと連携させています。連携にはGitLabのRedmineプラグインと、RedmineのRedmine GitHub Hookを

活用しています。

普段どうやって利用するのか。

あまりまだ運用方針が固まっていないのですが、自分の勉強スケジュールとかをとりあえず入れて、

タスク管理していけばいいと思います。(適当)

カテゴリー
blog

大障害再び

安定稼働しないtuboneのサーバ周り

どうも。可用性に自身ニキのAWS S3の障害が話題ですが、我が家でも障害。

我が家にある録画サーバですが、かなり長い時間、障害でサービスが提供できない、という

AWSもびっくりな障害がありました。

障害検知-ALM発生

ALM発生は25~26夜にかけて、0バイトファイルが作成されるというALMがZABBIXから上がりました。

仕組みは、録画サーバの先にNFSで接続されているNASに0バイトファイルが一定時間以上作成されたままになると

loggerコマンドでエラーログをはく、というcronで検知するものですが、そちらのALMが発生したのですね。

とりあえず、時間がなかったということと疲れていたということで録画サーバの系切り替えを実施し、その場をしのぎました。

(系切り替え自体はうまく行きました。リソースの兼ね合い上、バックアップ側での録画はワンセグ形式になるので画質は良くないです)

さて、次の土日まで、どうにも直す気力がなくて、そのままにしておりました。(NAS側の障害の可能性を当初疑っていましたが、ファイルの作成自体は

問題なくできているので本格的に原因を調査する必要があり、稼働も気力も間に合いませんでした)

障害原因調査-復旧

さて、本格的に本問題を解決する日が来ました。

まずは再起動。

とりあえず録画サーバのプロセス(サービス)を再起動しました。

録画サーバでは2つのプロセスが動いています。

WEB-UIを提供する chinachu-wuiと

録画や録画予約処理をするchinachu-operator

それぞれ再起動しましたが事象は解決せず。

次にサーバ(録画サーバはKVM上に立てられた仮想マシンです)の再起動。

とりあえずrebootコマンド。

解決せず。

次にNASの再起動

解決せず。 NASを再起動したので、NASを利用している別サーバにも念のためログインして使えているか

確認。(ここが時間かかる。)

ならばハイパーバイザから仮想マシンの停止・起動だ。

解決せず。

ここで飯を食う。(のんきなものです)

物理デバイスと仮想マシンの相性の悪さ

飯を食い終わったとき、ふと気になったことが。

実はALMが発生した日、別の併発ALMが出ていました。

録画サーバで録画したファイルはとても大きいので順次圧縮しています。

それは別ノード(余ったノートPC)で実行しているのですが、そちらが完全に

機能停止するALMが上がっていました。

原因は簡単で、勝手に親が部屋に入り電源周りをいじったか何かで電源が落ちたこと。

もしかして、チューナ周りもいじったのでは??

監視サーバ経由でハイパーバイザの仮想マシンマネージャを確認し、USBのアタッチ状況を確認。

我が家の仮想基盤サーバはKVM+QEMU+libvirt と仮想マシンマネージャというオーソドックスな

Linuxの仮想基盤となっています。

仮想マシンの設定を見る限り、USBで確実にアタッチされているみたい。仮想基盤サーバ上の

USB監視も問題なし。

まさか。

実際に録画サーバに入り、lsusb。

あ。

認識されていない。

原因判明。すぐさま、仮想マシンマネージャ経由でサーバをシャットダウン。

設定を入れ直し再度起動。

録画できた。お疲れ様でした。

振り返り。

KVM での物理デバイスの管理はほぼほぼQEMUが行っている(という認識ですが間違っているかもしれません。たしかKVMのメインのお仕事はCPUリソースの払い出しだったと思います。)

のですが、そちらの方の設定はUSBリダイレクションではなく、ホストPCのUSBのパススルーで設定しております。

そちらで一時的にUSBが切り離された場合、仮想基盤側では再組み込みと再割り当てが行われますが、どうやら仮想マシンにまで再割り当てはされないもようです。

リソースの割り当ては起動前、という原則に則れば、当たり前なのですが…。

なので、一度切り離されたUSBは(一瞬でも)仮想マシンには戻らない、ということになります。なるほど。

実はこれだけ原因の切り分けに時間がかかっていましたが、灯台もと暗し。アプリログには以下の文面が。

[code]

5 Mar 02:04:02 – RECORD: 2017-03-05T02:00:00+0900 [TOKYO MX2] ヒーリン
グタイム&ヘッドラインニュース
5 Mar 02:04:02 – LOCK: PX-S1UD (n=0)
5 Mar 02:04:02 – SPAWN: recdvb –dev 0 –b25 –strip –sid 23610 20 – – (pid=147
6)
5 Mar 02:04:02 – WRITE: /home/tubone/chinachu/data/recording.json
5 Mar 02:04:02 – STREAM: /media/tv/[170305-0200][20]ヒーリングタイム&ヘッドライ
ンニュース.m2ts
5 Mar 02:04:02 – #recdvb: using device: /dev/dvb/adapter0  pid = 1476 cannot open frontend device
5 Mar 02:04:02 – UNLOCK: PX-S1UD (n=0)

[/code]

そうです。frontend deviceがopenできないという。(Linux特有の表現ですが、デバイスファイルが開けない=使えないということです。)

ちなみに、正常時は

[code]

5 Mar 22:26:55 – STREAM: /media/tv/[170305-2227][20]にゃんこデイズ.m2ts
5 Mar 22:26:55 – #recdvb: using device: /dev/dvb/adapter0 using pid = 10294 device = /dev/dvb/adapter0/frontend0 Using DVB card “Siano M
obile Digital MDTV Receiver” tuning to 515143 kHz polling..

[/code]

と、デバイスファイルが開ける。

こんな簡単なログを見落としてたのか。失格ですね。

対策

今後、このような障害を起こさないように以下の対策をします。

まず、lsusb監視を仮想サーバ側にもつけるようにします。(今週中)

アプリログについて、監視文言にcannot open frontend deviceを加えます。

また、それ以外にも明示的にErrorと表記されないものについて見直しをし、

Zabbixに挙げられるようにします。(3月中)

さらに、監視サーバ上のVNCの解像度が低く、仮想マシンマネージャの操作に難があり、

一部virshコマンド等でオペレーションをしておりました。画面解像度の見直しをします。(対策済み)

サービスを守る。という使命感が乏しかったので、今後はサーバ優先の生活をするように担当者(自分)に言い聞かせました。

以上。

カテゴリー
blog Music

New my gear…

New my gear….

どうも。

今のメインギターですが、とても満足してます。 使用機材はこちらを見て下さい。

満足すぎて頭おかしなるくらい満足です。音は。

 

唯一あかんところがあるとしたらフロイドローズってところです。

こいつのせいで、チューニングがおっくうになり、気軽にチューニングドロップさせた

曲を弾こうとも思わなくなってしまったわけです。

さらに、今のギターは弦高をレギュラーチューニングでべたべたにしてますから、

そこら辺の調整とかも面倒なわけですわ。

そこで思ったわけです。

[fontsize class=’l’] 2下げまで許容できるギターを買おうと [/fontsize]

 

基本コンセプト

こんなギターがほしい。

[list] [li-disc]チューニングが安定しているもの[/li-disc]

[li-disc]2下げまで許容できるタイプ[/li-disc]

[li-disc]メタル系かアニソンしか弾かないので、歪ませても粒がたつもの[/li-disc]

[li-disc]今のメインギターと趣向が異なるもの[/li-disc] [/list]

 

探しました。ありました。

というよりは、偶然の出会いでした。

憧れのDellinger持ちになりました。

youtube、ニコ動で「まくまく」さんって方が昔演奏していて、

見事なテクニックとかわいさで当時の僕をくぎ付けにしていました。

もう本当にかわいくて、はっきり言ってドタイプなんですが、(性別の話はNG)

ギターサウンドも大好きでした。

この人です。かわいいでしょ。

 

憧れの人を見つけると人間は不思議なものです。その人の身に着けているものが

ほしくなったりします。

当時の僕は、大金を叩いてまくまくさん使用機材を買いあさります。参考文献は彼女(?)のブログ

今考えると機材にハマりだしたのもこの頃からだと思います。

また、まくまくさんのおかげでマティアス・エルクンドにはまるということも経験しました。

 

 

プラグインのギターアンプシミュレータである「Guitar Rig5 pro」

ギターシンセの「GR-55」とか、とにかく買いまくりました。

Guitar rig5 proはいまだに使い続けてますし、「GR-55」もたまにライブで使うので、

買って正解だったと思いますが、肝心の「まくまく」さん使用ギターである

Caparison Dellinger 」の購入については、金が底をつきたことで諦めてしまいました。

当時は若くてお金が必要でした。

 

そのうちに、今のメインギターとの出会いや、萌え豚化などの影響で、

その夢はすっかり忘れてしまいました。

 

買ってしまったよ、Dellingerを

何と言いますか。憧れの、大好きなあの子と街で偶然会って

その瞬間なぜか、街の雑音が消え、二人だけに焦点が合い、

冬のソナタ的なBGMが流れる… あの感じです。

 

あ、まくまくさん。好きでした!ずっと好きでした!!

 

 

買ってしまいました。Dellinger

[fontsize class=’l’] Caparison Dellinger Ⅱ FX-BKM CL-ML50 Natural Matt [/fontsize]

あこがれのCustom Line です!吸うと有毒らしい材を使っているとか使っていないとか。(そこら辺はパドゥーク材でググってみよう)

材とかそこら辺のうんちくは嫌われるのでここまでにしておいて

まくまくさんが我が家にやってきたと言うわけです。(やってきてはいない)

ただまくまくさんが利用しているDellingerに比べ、音のこしは少ない気がします。(材の影響)

Dellingerがメタラー向けギターと形容されるならその特徴をよく表したギターですが、

まくまくさんのそれとは少し違う気がします。まぁ材が違うので当たり前なのですが。

その代わりに、音の粒立ちが異常なくらいよくて、ハイゲインにも耐えられるというよりメタラー向けな

構造となっています。

 

また、Dellingerらしい、まくまくさん曰くトンガリヘッドもかわいらしいですね。

キャパリソン、カスタムラインと入ってますね。

採点

[list] [li-disc]チューニングが安定しているもの[/li-disc]

⇒◎ がっちりロック!アームなんてものはなかった。

[li-disc]2下げまで許容できるタイプ[/li-disc]

⇒◎ 基本2下げで使う設計らしい。あと低音もパコーンと出るので音の輪郭がはっきり聞こえるのでドロップ向け

[li-disc]メタル系かアニソンしか弾かないので、歪ませても粒がたつもの[/li-disc]

⇒○ 粒立ちが最大の魅力。 一方トラディショナルな音はかなり苦手っぽい。

[li-disc]今のメインギターと趣向が異なるもの[/li-disc] [/list]

⇒○ メインギターは基本同じような歪みに対して輪郭が出るタイプだけど、中音域の粘りが特徴

一方これは中音域の粘りを犠牲にして粒立ちを優先したようなコンセプト。

 

弱点もあります。

それはソロに弱いと言うこと。(中音域に粘りが全くない)

まぁそこはメインギターが得意なところなので気にしていませんが。

ライブでは工夫が必要かも知れないな。

終わりに

まくまくさん、動画あげてください