ひさしぶりにPCを自作 / Coffee Lake + Geforce GPUを導入

個人の開発で機械学習やCUDAを利用するために機材を揃えた。

量販店やPCショップで販売されているものは、価格の安いCoffee Lake世代のCPUとGeforceの組み合わせを選べるものが皆無なので、久しぶりにPCを自作した。過去のCore i5相当のスペックがCeleron or Pentiumで代替できるのでPentium+Geforce1050Tiの構成とした。

電源とケース、ビデオカードのファンに気をつけて騒音が少ないものを選択、以下の構成でフルサイズのGeforceビデオカード対応かつ、標準のCPUクーラーでほぼ無音のPCが完成、これで合計金額は82,779円。


・マザーボード:Coffee Lake対応で小さなPCに組み込めるmini-ITX規格。ASUSかASrockで台湾製を探したけど最近はベトナム製造らしい。

・電源:SFX電源でファンが静かなものを選択。80Plus GOLD以上の高効率のものが希望だったが、実績あるSilverStoneなので80Plus Bronzeで妥協した。

・CPU:Geforce1050のベンチマークを基準にCPUは2コア4スレッドで妥協、スペック不足があればアップグレードする予定。

・メモリ:DockerでCUDAの開発環境を組みたいので16GB必須、コスパのよいCrucialチップのCFD販売のもの。

・PCケース:ITXで組めて無難なデザインのもの。自作PC屋が乱立していた頃よりも安くて良質なものが増えていて驚いた。

・グラフィックカード:TDPの低いGeforce1050TiでGPUクーラーが静かなものを選択。ネットの表版をあてにするしかなかったのだが、高負荷でなければほぼ無音、サスペンド等の省電力も正常に動作している。

・SSD/HDD:480GBのSandiskが1万円を割っていたので起動ドライブ用に購入。中華SSDでも気にしないのだけどメモリチップのリマーク品や粗悪品の噂が絶えないので選択から外した。データ用には3.5インチのHDDがあまっているので足りなくなったらマウントする予定。

メーカー製品を買ったほうが面倒が少ないけど、省電力PC・静音PC・機械学習対応・デザイン良好・ゲーミングPCの条件をクリアして8万円台前半で揃えたので、コストパフォーマンスには満足している。

高円寺のジーンズ専門店「Nakaiya」が年内で閉店(2017年12月まで)

高円寺のジーンズ専門店「Nakaiya」(ナカイヤ)が年内で閉店するそうです。

こちらのお店はブーツカットやベルボトムのジーンズに強いお店で、希少な生産終了しているモデルや、店舗オリジナルのベルボトムを販売しているのですが、今のオーナーは3代目で創業80年以上、高円寺のお店は商店街でも最古参の1つなのだそうです。

高円寺 Nakaiya

店舗を閉店したあともネットショップの営業は続けるそうですが、ジーンズの製造会社はLevies, Edwin, Lee, Wrangler, どれも経営不振で生産が縮小されているため、ブーツカットやベルボのような少量デザインの品は特に入手困難で、店舗を閉めた後は、オリジナルのボトムしか販売できないだろうということでした。

http://home.u06.itscom.net/nakaiya/

(Nakaiya ネットショップ)

こちらのブログでは創業昭和9年と紹介、ベルボトムの聖地と呼んでいますね。。。

https://blogs.yahoo.co.jp/sukegawa_sukezoh/17602441.html

営業は12月末までやっているそうなので、閉店セール中で1万円以上するベルボトムが20%~30%引きになっている物もあるので、お店を知る人、知らなくてもジーンズが好きな人は、訪ねてみるのも良いかと思います。

最新版のAndroid対応のためにUnityのアプリをUnity5.6でリビルド⇒ParticleSystemのエミッタにバグでリリースできず・・・

Unityで作成した個人アプリを、Unity5.6対応とUnityAds2.1対応のためにアップデートしてみたところ、細かな仕様の変更点やらバグがあって土日の休日が潰れてしまった。。。

解決できなかった不具合は下記のエラー。

Sub-emitters must be children of the system that spawns them

根本的な問題は下記の投稿と同じだったのだけど、

Parenting of particle sub emitter in 5.6
https://forum.unity3d.com/threads/parenting-of-particle-sub-emitter-in-5-6.462180/

肝心の修正パッチがまだリリースされていないようだった。。。

richardkettlewell said:
This issue is fixed in the upcoming 5.6.0p4 patch.

s3のバケットでWebホスティングしたドメインをCloudFrontのACMでhttps化するときの注意点

Amazon s3に登録したドメインをCloudFrontのACMでhttps化する設定で、小さなハマりどころがあったので、備忘録としてブログに残します。

■目的
・s3で配信しているWebページがある
・s3の配信をhttps化して、かつCloudFrontで高速に配信したい

まず、解決方法の概要から、
s3で配信するために登録したDNS(Route53)設定のままでは、CloudFrontを経由した配信にならずhttpsの通信ができない。
CloudFront用のドメインをRoute53に登録すれる事で解決した。
それだけの設定なのですが、CloudFront用のドメインに気付くまで時間が掛かってしまった。。。

※CloudFrontのドメインが表示される画面
“CloudFrontリソースグループ “の “General”を設定すると該当のドメインが割り当てられて表示される。

※Route53設定の注意点

・前提条件として、s3でのWeb配信は設定済みとする。
・s3をCloudFrontで参照するためには、赤枠で囲ったドメイン(xxxx.cloudfront.net)を、Route53の配信対象のドメインへcnameとして設定する必要がある

※CloudFrontのOrigin設定
・s3で独自ドメインを割り当てたバケットはhttpsが使えないので、”Origin Protocol Policy”には”http only”を指定する
・”Origin Domain Name”が設定済みだと、プロトコル選択(http, https)が表示されない場合がある
・”Origin Domain Name”に適当なドメイン(test.comとか)を入力すると、プロトコル選択(http,https)が表示される

※CloudFrontのBehavior設定
・”http and https”
・その他はキャッシュ範囲、キャッシュ時間等を目的にあわせて設定する

AWS RDSのparameter_groupを初期化する方法

課題と問題点

AWSのRDSサービスでMySQLを利用しているのだが、MySQL5.6系から5.7系へアップグレードした際に、アップグレード後もパラメータグループは引き継がれるのだけど、デフォルトオプションの制約が多数追加されたので、5.6と同じテーブル定義では変換できない場合がある。
特にDateTimeのNULL定義が許可されなくなっているので、パラメータグループを初期化することにした。

具体的施策

まず、RDSのパラメータグループをデフォルトのポリシーで動作するように初期化する。
すべての項目を見直すのは時間がかかるので、AWS-CLIで設定を初期化する。

参考記事

Qiitaのエントリーを参考に設定しようと試したのだけれど、サンプルの書式ではコマンドがエラーになって反映されなかった。

http://qiita.com/web_se/items/3f789f70873b88720b0e

$ aws rds reset-db-parameter-group --db-parameter-group-name dbpg-prod-test --no-reset-all-parameters --parameters ParameterName=bulk_insert_buffer_size,ApplyMethod=pending-reboot --region ap-northeast-1

コマンドの修正

下記のようにパラメータを全てリセットする指定だと正常に反映された。

$ aws rds reset-db-parameter-group --db-parameter-group-name rdsparam-group --region ap-northeast-1 --reset-all-parameters

原因はわからないけど備忘録として残します。

YoutubeのRSSフィードが6月12日あたりから信頼できない証明書エラーに

YoutubeのRSSフィードが6月12日あたりから信頼できない証明書エラーに

課題・問題点

表題の通り、YoutubeのRSSフィードが6月12日あたりから信頼できない証明書と判別されるようになっていた。

アプリケーションの証明書チェックを無視するように組みなおせばいいのだけど、
突然切り替わったので暫く把握できず。個人的に収集していたデータフィードが暫く停止していた。

具体的対策

curlによるテスト

信頼できない証明書を無視するオプション例

  • curlだと -k
  • wgetだと –no-check-certificate

自前のアプリケーションで処理している場合は、SSL判定のコールバックを強制的に無視するようなロジックを追加すれば良い。

対策後のブラウザでの証明書判定状況

  • Chrome系のブラウザで参照
    - 信頼できる証明書と判別される
  • FireFox
    - 検証され信頼できる運営者情報はありません
  • IEで参照
    - 信頼できる証明書と判別される

nginxのWebサイトでletsencryptのacme認証を疎通させる

nginxを利用しているWebサーバでletsencryptを導入するときに、アプリケーションの固有の設定等でacme認証に失敗する場合がある。

対策として、nginxの公式を参考に下記のように該当するlocationを疎通させれば正常に認証ができた。

location ~ /.well-known {
location ~ /.well-known/acme-challenge/(.*) {
add_header Content-Type application/jose+json;
}
}

※参考
http://nginx.org/en/docs/http/request_processing.html

Redmine3.2がすごく便利。だけどアップグレードには注意

Redmineといえば、BTSやプロジェクト管理に重宝するミドルウェアですが、
個人でもやナレッジをRedmineへ保存するようにしている。

Redmine3.2以降だと標準でスマホ対応(レスポンシブ表示)になったので、外出先でも利用しやすくなるのでアップグレードしたかったのですが。
パッケージの依存関係でアップグレードに失敗した時に面倒が多いため、注意が必要です。

今回はUbuntu14.04LTSから16.04LTSへアップグレードすることで、Redmineと関連するパッケージを更新しました。

いくか注意点があったので備忘録としてブログに残します

■ハマリ要素

  1. Ubuntu server版では、do-release-upgradeが日本語環境非対応になった
    アップグレード前にrootの言語設定をen_USにしないといけない
  2. MySQL5.7の設定が5.5と互換性がない部分あり
    うまくアップグレードできないと初期化しようとするので、
    警告文を注意深く読むか、予めMySQLをバックアップしておいて、あとからリストアする必要がある
  3. rubyバージョンの情報が少ない
    Ubuntu16.04はRedmine3.2を公式にサポートしている
    しかし、Ubuntu16.04はRuby2.3がデフォルト、Redmine3.2の公式ではruby2.2で導入を説明している
    結論としては、Ruby2.3でも問題なくインストールできた

Redmine単体のインストールは新規の手順と大きな違いはないので、
こちらのブログあたりが参考になると思います。

スマホ「実質ゼロ円」1ヶ月でまさかの復活

東洋経済2016/03/26号より

「スマホの端末代金実質ゼロ円がわずか1ヶ月で復活」の記事。

今年1月、総務省が市場の健全化と消費者トラブルの防止のため、実質ゼロ円で購入が可能となる販売方式を規制する「スマートフォンの端末購入補助の適正化に関するガイドライン(案)」が公開され、
それに伴いケータイキャリア主要3社が「2月から実質ゼロ円の販売をやめる」と表明していたのだ。

しかし、総務省案の規制に穴があり、表題のように脱法まがいの商法で実質ゼロ円商法が復活したらしい。
その手法はシンプルで、端末の買い取りは規制されていないため、顧客が持っている古いスマートフォンを高く買い取り、端末代金を穴埋め。実質ゼロ円で加入させることができる。
このような規制の抜け穴を利用し、既にソフトバンクとauが実質ゼロ円を開始、ドコモは、実質ゼロ円に抵触しないように、学割や2人以上家族で加入した場合のみ、下取りによる値引きをしているそうだ。
結局、このような商売で損害を被るのは、騙されて契約した顧客や、ネットを頻繁に利用しない低リテラシーの顧客、長期契約で利用している上客である。

(規制の)「穴は絶対埋める」総務省関係者

ガイドラインが適用される4月1日移行、販売方法がさらに限定されるのは必至。また、端末値引きの原資となる販売奨励金の削減や、長期ユーザーを優遇する取り組みがなされているか報告する義務も、携帯会社に課せられる見込みだ。(同記事より)
このように総務省が厳しい態度に出るのも当然で、2014年集計の消費者調査では通信回線や関連するデジタルコンテンツの契約による相談件数が吐出しており相応の被害者が潜在する。

※消費者庁資料を引用
http://www.caa.go.jp/information/hakusyo/2015/honbun_1_3_1_1.html#m04
2014年度の消費生活相談を、相談件数と実際に支払った相談1件当たりの金額(平均既支払額)の関係で見たところ、デジタルコンテンツやインターネット接続回線等の「運輸・通信サービス」が27万件を超えて最も相談件数が多く、2番目の「金融・保険サービス」を3倍近く上回り、他の商品・サービスの相談と比べ突出しています

消費者庁調査2014年

価格・サービスに不満のある顧客はMVNOの利用を検討してほしい

被害にあわないためには自衛するしかない。
大手キャリア最安値のデータ通信プランは最も安い月額費用で2980円(月1GB)だが、MVNOだと1000円未満で3GB程度利用可能なので、回線の契約自体を見直すことで通信費用を払う必要がなくなる。オプション商法も回避することができる。電波利権と揶揄される業界ではあるが、大幅に規制緩和された現在は消費者自身が自衛することができる。

letsencryptの設定メモ

セットアップ

githubからソースをcloneして取得する

$su
#mkdir letsencrypt
#cd letsencrypt
#yum install git
#git clone https://github.com/letsencrypt/letsencrypt.git

鍵の生成(新規)

letsencryptのSSLを新規作成する場合は下記のような書式で実行する

#新規
#sudo ./letsencrypt-auto certonly  --webroot --webroot-path (nginxのルートフォルダ) -d (ドメイン名)

鍵の生成(更新)

既にletsencryptのSSLを作成済みで更新する場合

# 更新
#sudo ./letsencrypt-auto --renew certonly --webroot --webroot-path (nginxのルートフォルダ) -d (ドメイン名)

nginxのconfファイル設定

nginxのconfファイルのSSLを下記のように指定すればOK

ssl_certificate /etc/letsencrypt/live/(ドメイン名)/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/(ドメイン名)/privkey.pem;

nginx サービスを再起動

#systemctl restart nginx.service

サービス再起動後にhttpsを確認、letsencryptによって信頼された証明書になっていればOK

just simple dialy

モバイルバージョンを終了