BeatsX買ってみた
BeatsXとはなんぞや
久しぶりの更新ですが、表題の通りAppleより本日発売のBeatsXを購入してきました。
BeatsXとは、と書くと長々なってしまうのでリンク先の説明を読んでみてください。
要は技術的にはBluetoothイヤホンの類なんだけど、Apple渾身のW1チップ搭載によりApple製品との親和性がむちゃくちゃよくって、なんならiPhoneに近づけるだけで接続まで終わって他の機器にはiCloud経由で設定が同期されますよっていう便利なワイヤレスイヤホンなのです。(早口)
現在、ホワイト、ブラックは６週間
まだ発売されていないブルー、グレイは2、3週間となっていますが本日17時頃まではホワイト、ブラックに関しては在庫があって運良く近くのApple Storeでの当日受取が可能でしたので発売当日に入手することができたというわけです。
開封の儀
私はたくさんのApple製品を持っていますが、Beats製品は初めてなのでちょっとわくわくしました。
最後に
さて、今回は写真もりもりで開封の儀をお送りしましたが、まだ使ってないのでしばらく使ってみてまたレビュー編をお届けできればと思います〜
最後までありがとうございました。
UncrustifyのMacへのインストール方法
タイトルの通りですがUncrustifyをMacへインストールする方法です。
Uncrustifyとはコマンドラインで動作するコードフォーマッターです。
それをMacにインストールするのですが、検索してみるとXcodeで利用する場合やbrewなどのパッケージ管理システムを利用した方法などはたくさん出てきますがなかなか手動でインストールする方法が見つからなかったので備忘録。
誰かの（未来の自分とか）の助けになればと思う。
まずはUncrustifyのダウンロード
公式サイトはこちら→http://uncrustify.sourceforge.net:Uncrustify
ただし公式サイトからダウンロードすることはできずGithubなどのプロジェクトページからダウンロードする。
Githubのリンクを貼っておく
github.com
次にビルド
ダウンロードしてきたUncrustifyはバイナリではなくソースなので自分でビルドする必要がある。
ターミナルを開きダウンロードしたUncrustifyへ移動しているものとして、
ビルドにはなんでもいいが今回はCMakeを使用する。
その理由としてUncrustify公式がCMakeでのビルドを推奨しているから。
$mkdir build $cd build $cmake .. $cmake --build .
これで作成したbuildフォルダへのビルドが完了する。
ちなみに"cmake --build ."を "make install"としてもいいと公式サイトにはあるがmacOS Sierraではビルドは成功するもののインストールに失敗してしまう。
その理由はインストール先である/usr/local/bin/へのアクセスが特権ユーザのみ許可されているためである。
なので自分の手でコピーしてしまう。
buildフォルダにできている"Uncrustify"をコピーしFinderで/usr/local/bin/を開き貼り付ける。
パスワードを聞かれるので入力しコピーされたのを確認する。
これでUncrustifyのダウンロード、ビルド、インストールがすべて完了した。
SSHの使い方いろいろ
SSH便利ですよね。
自宅のサーバや1階でノートPC触ってる時に2階のマックのファイルが必要になった時とかAWSなんかでも使いますよね。
私も使ってます。
これまでそんな大したものも無いしと思って自宅のサーバはパスワード認証だったのですが、AWSではデフォルトで公開鍵認証なので勉強してみました。
SSHとは
SSHとはSecure Shellの略です。
従来利用されてきたTelentなどの方法の弱点を克服するために開発されたプロトコルであり、その安全性には非常に重きが置かれています。
SSHの暗号通信は公開鍵暗号を用いて通信用の共通鍵を暗号化し鍵交換を行ったあと通信自体は高速な共通鍵暗号方式で行うハイブリッド仕様です。
バージョン1とバージョン2の2つのプロトコルがあるが、バージョン1には脆弱性が発見されているため現在ではバージョン1の使用は推奨されていません。
Secure Shell（セキュアシェル、SSH）は、暗号や認証の技術を利用して、安全にリモートコンピュータと通信するためのプロトコル。パスワードなどの認証部分を含むすべてのネットワーク上の通信が暗号化される。
from Wikipedia
らしいです。
OpenSSH
LinuxでSSHを利用する場合はOpenSSHというソフトがデファクトスタンダードとなっておりほぼすべてのディストリビューションでプリインストールされています。
認証の方法
OpenSSHではSSHの安全性を保つために数種類の認証方式が用意されている。
主なのは次の2つ
- パスワード認証
- 公開鍵認証
パスワード認証
文字通りパスワードを用いて認証する方式です。使い方はTelentなどと同様で上記コマンドで接続後パスワードを聞かれますので入力し認証後接続完了です。
この方法ではアカウント名とパスワードさえ知っていれば誰でも接続することができるので簡単である反面、暗号化されているとはいえパスワードがネットワーク上に流れますし、メリットを裏返すとパスワードが漏れると誰でも接続できてしまうということです。
公開鍵認証
これはローカル上で予めキーペアを生成し、公開鍵を安全な方法でサーバへ届ける必要があります。何かしら物理メディアを使うことが安全ですが、他にもsftpなどセキュアな方法で転送する必要があります。しかし、一度設定してしまうとパスワードや鍵がネットワーク上を流れることはありませんので非常に安全性が高いといえます。
また、OpenSSHでは明示的に設定しないかぎりパスワード認証を許可しています。
キーペアの生成方法
キーペアの生成にはSSHの「ssh-keygen」コマンドを使います。
まず、ローカルで以下を実行
$ ssh-keygen -t rsa
-tオプションで下記のタイプを指定しています。ここでは標準的なRSA鍵を生成します。
上記コマンドを実行すると対話式のキーペア生成モードに入ります。
$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/hoge/.ssh/id_rsa): ←※1 Enter passphrase (empty for no passphrase): ←※2 Enter same passphrase again: ←※3 Your identification has been saved in /home/hoge/.ssh/id_rsa. Your public key has been saved in /home/hoge/.ssh/id_rsa.pub. The key fingerprint is: 35:96:22:65:90:7e:39:82:01:2e:19:57:5a:bb:32:37 hoge@fuga.com The key's randomart image is: +--[ RSA 2048]----+ |. ooo .oo | | = o...o . | |o o .+. ..= | | . ..o.++ . | | o E oS. | | + . | | | | | | | +-----------------+
- ※１→キーペアを保存する場所を聞いています。そのままEnterで~/.ssh/に保存します
- ※２→パスコードを指定できます。ここでパスコードを設定すると接続のたびにパスコードが必要になります。そのままEnterでパスコード無しで鍵を生成できます。
- ※３→パスコードを確認のため再度聞いています。
以上でキーペアが~/.ssh/もしくは※１で指定した場所に生成されています。
$ ls authorized_keys id_rsa id_rsa.pub
となっているはずです。authorized_keysはない場合もあります。また、他に幾つかファイルがある場合がありますが、ここではキーペアである
があるかを確認します。id_rsa.pubのpubはpublicの略でこちらが公開鍵になります。
公開鍵の設置
id_rsa.pubを接続したいサーバの使用するユーザのカレントディレクトリ/.ssh/へ転送します。
※id_rsa.pubを転送したあとは不要ですので紛らわしくならないようにローカルでは削除して構いません。
その後接続したいサーバで以下を実行
$ cd ~/.ssh/ $ cat id_rsa.pub >> authorized_keys $ rm id_rsa.pub
これは既にauthorized_keysが存在している場合です。
authorized_keysとはリモートサーバにおける鍵束(キーチェーン)です。
今後は公開鍵が増えた場合はこのファイルへどんどん追記していく形です。
authorized_keysがまだ無い場合は今転送したid_rsa.pubをそのままauthorized_keysにしてしまいましょう。
$ mv id_rsa.pub authorized_keys $ chmod 600 authorized_keys
この時必ず安全のためauthorized_keysの権限を600へ変更してください。
既にファイルが有った場合も一度確認してみましょう。
秘密鍵の設定
秘密鍵はローカルのどこにおいていても構いませんが、管理などを考えると~/.ssh/へ置いておくのがベターだと思います。
こちらも先ほどと同様に
$ chmod 600 id_rsa
権限を600へ変更しておきましょう。
秘密鍵は権限がOpen過ぎるとOpenSSHで弾かれて接続できなくてエラーが出ます。
必ず変更してください。
接続テスト
これで接続が可能なはずなので
$ ssh -i ~/.ssh/id_rsa hoge@fuga.com
で接続可能か確認してください。
またid_rsaは今後またキーペアを生成するときにこのままでは上書きされてしまいますので任意の名前に変更するといいと思います。
鍵の形式について
SSHの鍵にはいくつか種類がありssh-keygenで生成される鍵はおおむねRFC4716の形式と同じだが、ヘッダは含まず改行もされていない。OpenSSH独自の形式らしい。
よく使用される形式にヘッダつきのPEM形式を使うことが多いと思います。
特にFTPソフトなどでSFTPで接続するときなんかは対応していないことが多いと思います。
こちらもOpenSSHで使用可能であり、また変換も可能なので方法を載せて置きます。
私は汎用性とかを考えてすべてpem形式で管理しています。
変換は以下のコマンドですることができます。
openssl rsa -in id_rsa -outform pem >id_rsa.pem
最後の部分で任意の名前.penで出力可能です。
※OpenSSLがインストールされていない場合はコマンドが実行できません。インストールしてください。
参考にさせていただいたサイト様やブログ様
ssh公開鍵認証を実装する - Qiita
Linuxコマンド【 ssh-keygen 】認証用の鍵を生成 - Linux入門 - Webkaru
Macでssh-keygenで作成した秘密鍵をPEM形式に変換する方法 | ゆるメモ
ありがとうございましたm(__)m
CentOS7でdigやhostを使う話
dig,hostが使えない....
AWSでCentOS7のAMIを使ってインスタンスを作成するとminimumインストールされているようで殆どのコマンドは使えないのだけど、
まさかdigやhostが使えないと思ってなくて
$ sudo yum install host
なんてしてみたけどdigも含めてパッケージ無しと出る。
色々調べてみると下記サイトでがっつりな情報を見つけました。
ありがとうございます。
dig, nslookup, hostのインストール [CentOS 7] - ex1-lab
Googleなんかで「Centos7 host コマンド」って調べるとなるほど悩んでる人が多いみたいでした。
とりあえず
bind-utils
というパッケージに全部含まれてるらしいので
$ sudo yum install bind-utils
でコマンドが使えるようになりました。
では〜
CentOS7 on AWSのホスト名を固定する話
再起動するとホスト名が戻ってしまう
AWS上のLinuxのホスト名は動的にその時のパブリックIPから設定されていて
題名の通りAWSのインスタンス上で実行しているCentOS7のホスト名を固定しようとしたらハマったので備忘録
自宅のサーバの設定のように
/etc/hostname
なんかを設定しても再起動すると戻ってしまう。
ホスト名の設定はcloud-initでやってるらしい
cloud-initで自動で設定してるっぽいらしいのでその設定ファイル"/etc/cloud/cloud.cfg"を開いてみると
"- update_hostname"とそれっぽい項目が
$sudo nano /etc/cloud/cloud.cfg cloud_init_modules: - migrator - bootcmd - write-files - growpart - resizefs - set_hostname #- update_hostname - update_etc_hosts - rsyslog - users-groups - ssh
と上のように良い感じにコメントアウトしてあげて
改めて/etc/hostnameにホスト名を設定して再起動してあげると
無事固定できましたとさ
めでたしめでたしということで。
JDBCでのClass.forNameについて知見を得た話
長年の疑問だったんですが、他に勉強することもあってなんだかんだそういうものだと思ってました。
ですが下記記事で知見を得ました。まじで。
こちら↓
Class.forName()とnewの違い（JDBCでClass.forNameを使う理由）｜あなたに送る独り言byはむばね
本当の本当にすっきりしました。
もう私の稚拙な文章で説明をすると余計にわからなくなると思うのでこの記事は上のブログ様を紹介する、そのためだけに書きました。
ちなみに調べていてはじめに見つかったブログ様↓
Class.forName で DB アクセスできるようになる理由 - すぱいだー日記。
始めは私がばかなせいでなにをいってるのかわからなかったのだけど1つ目のブログ様で知見を得たあとこちらを見直すと更に理解が進みましたので
ぜひ読んでみてください。
はあ、気になったことはすぐに調べるべきだな／(^o^)＼
public class html_parse { public static void main(String[] args) throws IOException{ Class.forName("com.mysql.jdbc.Driver"); Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/hoge", "hoge", "hoge"); Statement stmt = conn.createStatement(); } }
これがJDBCお馴染みのおまじないですね
はあすっきり。
W01を購入してみた
経緯、、、
普段は出先でのネット環境としてWimax2＋環境を使用している。
2年前に25ヶ月間はWimaxとWimax2+を使えるハイスピードモードでの通信において月間データ制限がない契約をしていた。
まあそんなことは記憶の彼方に飛び去っていたのだが、先日使っていると遅い。異常に遅い。
これは直近3日間で3GBの制限にかかったかな？と思いauお客様サポートのページを見ると
購入
EXが取れると同時に500円程度安くなっていたのだが、むしろ500円払うから無制限にしてくれという感じなので
時間があるときにauの窓口へ行ってみた。
私はHWD15というモバイルルータを使っており特に不満もなかったのでプランだけ変更してもらおうと考えていたのだが、まあタイトルで出落ちの通りW01を買いました。
ちなみにW01というのは機種名であり、ベンダーであるファーウェイでの型番は"HWD31"という。
プラン変更ではなく機種変更になった理由はなんと値段が変わらなかったからである。
機種変更したとしても毎月割で結局端末代分は0円になるのでプラン変更した時と値段が変わらないらしい。
なのでCAで220Mbpsにも対応していることだしということで機種変更をしたのでした。
ちなみに購入したW01もといHWD31↓
後日談
実は窓口に聞きに行った日に機種変更したのではなくとりあえず話を聞きに行っただけでまた後日に機種変更は行ったのだが
auのプラン詳細のページに恐ろしいというか意味不明な記述があったので記しておく。
注2）「WiMAX 2+ フラット for DATA」と比較すると、ご利用されるエリアの混雑状況により速度が低下する場合があります。
WiMAX 2+ フラット for DATA EX | 料金・割引：スマートフォン・携帯電話 | au
？？？？？？
プランによって速度に差があるの？？？
窓口で見ていたので店員さんに聞いてみると
店員さん「そんなはずはない」
わたし「じゃあこれは、、？」
店員さん「確認してみる。」
わたし「はい。お願いします。」
店員さん「やはり関係ないとのこと。安心して下さい。」
わたし「いやいや、安心もなにも、、これはうそですか？」
店員さん「嘘というわけでは、、ですがプランによって速度に差はない」
わたし「はあ」
という会話があり埒が明かなそうだったので退散してきました。
また時間があるときに直接サポートへ電話したいと思います。
なにかわかったら追記予定ということで！
