fnwiyaBlog

EmacsとかLispとか可視化とか

J.M.WESTON 180 SIGNATURE LOAFERを買った

基本スニーカーかサンダルな自分ですが、
社会人も2年目になり、誕生日も迫ってきたのでせっかくなら良い靴をということで購入しました。

f:id:fnwiya:20170528212851j:plain f:id:fnwiya:20170528212900j:plain

青山の店舗で購入し

  • サイズは4/ C
  • カラーはブラックカーフ

いわゆるウェストンフィッテイングというやつでお店で履くのも一苦労でした。

やはり質がよく履いているとシュッとしますが、
ローファーらしく堅くなり過ぎない雰囲気が好きです。
今はまだ近所への買い物などで慣らし中ですが、
早くローテーションに入れたいなと思います。

「暗号解読[上]」を読んだ

Amazon CAPTCHA

ざっくりまとめ

いくつかの暗号の仕組みと解読法、
暗号が歴史上果たしてきた役割にかんする書籍。
暗号そのものよりは人にフォーカスを当てて、
政治や軍事が暗号を発展させてきた様子を描いている。

感想・学び

  • 秘密にしなければいけない仕組みと公開して良い仕組みの区別
  • ソーシャルハックも手段の内
  • 複雑な問題は関心を分離する
  • 引退後はすきな探求を続ける生活良さそう
  • 規則あるものは見破られる

「ハッカーと画家」を読んだ

Amazon CAPTCHA

自称見習いLisperにも関わらず読んだことがなかったのですがGWを利用してようやく読めました。

memo

  • プログラミングは油絵。なんども上書きして直す前提で作る。
  • 創造的なことをしよう。退屈なら自動化の余地あり
  • 場によったルール、モラル、プロトコルがある。従うとは言ってない。
  • Lisp最高

ThinkPad X1 Carbon(Gen5)開封&使用感レビュー

3年前に買ったMBA11インチモデルのバッテリーが壊れたようで起動しなくなってしまったため、
ThinkPad X1 Carbonの2017年モデル(第5世代)を購入しました。

http://shopap.lenovo.com/jp/notebooks/thinkpad/x-series/x1-carbon/

他にも候補として

などがありましたが、

  • キーボードが英字配列
  • メモリが16GB以上
  • SSD256以上
  • キーボードのうちやすさ重視
  • 画面は非光沢でFHDあれば十分
  • タッチパネルいらない
  • プレゼンするときこまらない
  • 重量1.3kg以下
  • 一日イベントでも充電なしでメモとれるだけのバッテリー
  • 色はマットブラックが好き
  • 予算は30までなら出す

等々の条件からthinkpadにしました。
(本当は「王様達のヴァイキング」の是枝くんの使用PCがthinkpadだったのに影響されたのが一番大きいです。あれはIBM時代のものですが)

comic-soon.shogakukan.co.jp

外観レビュー

箱の外観

f:id:fnwiya:20170226123005j:plain

箱の中

化粧箱があり、
開くと自然とせり上がってくるようになっています。本体はさらに袋の中。 f:id:fnwiya:20170226125007j:plain

MBA11インチとの大きさ比較

さすがに大きいですがそれでも14インチあるとはおもえないコンパクトさ
マットな質感は高級感があります。ちょっと埃が気にならないでもない。 f:id:fnwiya:20170226123028j:plain

使用感

  • キーボードは電気屋で触った限り今までと同様で素晴らしい。ややクリッキーになっている気もする。
  • VMを動かすのにBIOS画面にはいる必要があった。
  • 音は基本的に静か。ときどき「ウォーン」となるのがちょっと怖い
  • 熱は多少もつが気にならない程度
  • 画面は視野角も広くちょうどいい
  • 軽い。そしてボディに剛性があるので端を持って持ち上げるのも全然大丈夫
  • 充電器はコード周り安心感あって軽い。(3年で3個壊しました。)

ずっとVM内(Ubuntu on VirtualBox)にこもっているので、デュアルブートかwinは消してしまうつもりです(手元にUSBがなかった)。
お値段も以下のスペックで20いかなかったのでお得でした。
さっそくスタバでドやってきます笑。

スペック

プロセッサー    
 
インテル Core i7-7500U プロセッサー (最大3.5GHz, 4MB)    
 
初期導入OS        Windows 10 Home 64bit    
 
導入OS言語        Windows 10 Home 64bit - 英語版    
 
ディスプレイ        14.0型FHD液晶 (1920x1080 IPS 300nit 光沢なし)    
 
メモリー        16GB LPDDR3 1866MHz (オンボード)    
 
グラフィックス        インテル® HD グラフィックス 620    
 
Body Color        ブラック    
 
キーボード        英語キーボード (バックライト、指紋センサー、Cカバー付) ブラック    
 
指紋センサー        内蔵指紋センサー    
 
TPMセッティング        TPMあり(ハードウェアチップ搭載)    
 
内蔵 カメラ        カメラ(HD 720p対応)あり、マイクロフォンあり    
 
セキュリティーチップ        TPMあり    
 
ハード・ディスク・ドライブ        256GB ソリッドステートドライブ PCIe-NVMe (OPAL対応)    
 
ポインティングデバイス        ThinkPadクリックパッド    
 
バッテリー        3セル リチウムイオンバッテリー (57Wh)    
 
電源アダプター        USB C 45W ACアダプター    
 
ワイヤレス        インテル Dual Band Wireless-AC 8260(2x2) Bluetooth 4.1    
 
Integrated Wireless Antenna        WLANアンテナ    
 
ディスプレイタイプ        14.0型FHD液晶 (1920x1080 IPS 300nit 光沢なし) 720pカメラ付、マイクロフォンあり ブラック

pre-commitでeslintを走らせてコードを綺麗にしていく

linterがあるとコーディングスタイルが統一され無駄なdiffやバグの防止ができますが、 既存のアプリにあとから導入しようと思うといきなり大量のエラーがでてきて萎えてしまいます。 そこで自分が編集したファイルだけlintを実行して少しずつ直していくというのはどうでしょう。

www.npmjs.com

下記の例のようなpackage.jsonをプロジェクトルートに作り、

$ npm install

をするだけで設定は完了です。

設定をした上でgitでcommitしようとすると、 変更があったファイルに対してのみlintが実行され、 lintに失敗するとcommitがコケるようになります。 (どうしてもlinterを無視してコミットしたい場合はgit commit --no-verifyとします。)

ちなみにコミットする前に手動でlinterを走らせたい場合は

$ npm run lint:commit

とします。

Boy Scout Ruleで少しずつコードを綺麗にしていきましょう!

package.jsonの例

{
  "name": "sample",
  "version": "1.0.0",
  "description": "sample",
  "repository": {
    "type": "git",
    "url": "http://gitlab.fdev/sample/sample.git"
  },
  "pre-commit": [
    "precommit-msg",
    "lint:commit"
  ],
  "scripts": {
    "lint:commit": "git diff --cached --name-only | grep .js$ | xargs eslint",
    "precommit-msg": "echo 'Pre-commit checks...' && exit 0"
  },
  "devDependencies": {
    "eslint": "^3.14.1",
    "pre-commit": "^1.2.2"
  }
}

COMPのある生活

「完全食」で界隈には有名なCOMPですが、
人気のあまり現在は配送遅延中のようですね。

www.comp.jp

年明けから毎日の生活に取り入れ始めたので感想です。

買い方

買ったのは1袋90gの96パックセット。
おそらく1袋925gのほうがコスパは良いのかもしれませんが、
分量を計るのが面倒だったり一部持ち歩くのが大変だったりするのでこちらに。
シェイカーは非常に飲むのが楽になるので買って正解でした。

届いたときは想像の倍ぐらいの大きさのダンボールに12個セットの箱が8つ入っていました。

飲み方

最初は水で飲んでいました。
それでも特に不満はなく、味はプレーンな豆乳で飲みやすいです。
最近はもっぱらポーション型のコーヒーで豆乳ラテにして飲んでいます。
会社では他にお茶で飲んでいる人もいます。

感想

腹持ちはするのかと言われるとある程度はしますが、
さすがに普通に一食食べたときよりは早く夕飯が食べたくなる気がします。
味には満足で、栄養に関してはまだ実感はありませんが成分を見る限りはそこは心配なさそうです。
三食COMPは人間を捧げ過ぎだと思いますが、
朝や昼など時間を節約したいときには便利だと思います。
96パックも3ヶ月程度でなくなるので、
これが終わってもリピートしていくつもりです。

第34回 PostgreSQL 勉強会に行ってきた

connpass.com

に行ってきましたので参加メモです。
ツイッターでのハッシュタグ
https://twitter.com/hashtag/jpug_study?src=hash


PostgreSQL9.6 パラレルクエリの本当のところ

自己紹介

  • ユーザー会理事/EDB Postgresの技術支援担当
  • 普及頑張る
    • 初心者向け
    • 地方需要
    • エコシステム拡大

EDB

オープンソースではない?
→postgres本体へのフィードバックをしている。 - オラクル互換 - 周辺ツール

パラレルクエリに期待される効果

他のDBだと昔からあった。
大規模データをデータベース・サーバー内(In-Database)で処理する。

ポストグレスの進化

  • 大規模サーバーを使いこなす
  • データ分析基盤
  • 多様なデータを扱う ->9.6である意味達成

パラレルクエリの動作

  • 並列度のパラメータを設定すれば使える。(EDBならヒントを書ける)
  • 自動的にworkerが立ち上がりgatherで集約する。
  • その他細かいパラメータあり(テーブルサイズや初動コストなど)
  • パラレルクエリを使う以上INDEXスキャンはできない(Seq-Scanのみ)
  • 実行計画的には
    • 並列に集計: Parallel Seq Scan (loops=7)&Partial Aggreagate(rows=7)
    • 結果を集めて: Gather(rows=1)
    • 全体を集計: Finalize Aggregate (rows=1)
  • パーティショニングした場合は起動済みのワーカーが各子表をみにいく

パラレルクエリの課題

  • 思いどおりにならない並列度

    • 並列度はテーブルサイズで決定されるがそれだけではない?
      • EDBならヒントでパラレる→けど遅くなる
      • Gatherでみる行数が大きくなるとだめ
      • postgresでもパラレルの上限を決められるためALTER TABELで0にすればパラレルを抑止できる
    • ディスクソートをメモリソートにしたらパラれなくなった。。。
      • EDBならヒントでパラレる→効果はあんまり
      • まだ解決策はない
  • 期待通りになれば効果はある。しかし期待通りにはなかなかならない。

  • 制限事項
    • Mビュー更新で使えない
      • psqlで結果をファイルに吐く
      • プログラム側で配列に保存する

(おまけ)EDBはコア課金でだいたい100万ぐらい?


DBAサバイバルガイド~「pg_stats_reporterで性能トラブルを洗い出せ」

pg_stats_reporterの良さ

みんなで幸せになろうよ

  • 技術内閣制度で事業部横断
  • ログが増えすぎ問題→冗長なログを切り捨てる。
  • オレオレ設定
log_min_duration_statement = 10
log_statement = 'none'
pg_statsinfo.snapshot_interval = 5min
pg_statsinfo.stat_statements_exclude_users = ‘postgres'
pg_statsinfo.stat_statements_max = 1000
CREATE EXTENSION pg_stat_statements;

みんなで幸せになろうよ

  • pg_stats_reporterがあると実測コード読まなくても問題点がわかる
  • DB読影
    • みんなでレポートの画面をみる
    • 職人技の伝承もできる
  • オレオレ分析優先順位
別サービスからSOSで、pg_stats_reporterを診た。読影会でも、Qiitaでも共有したけど、Long Transactions - Statements - Heavily Accessed Tables - Indexの順でみてけば、大概わかるよ。

— masuda kaz (@masudakz) 2016年9月22日
pg_stats_reporterのLong Transactions/Statements でクエリ特定して、H.A.TでSeq.ScanになってるTABLE特定して、結合条件列がIndexになかったら、Gotcha! 簡単だよー

— masuda kaz (@masudakz) 2016年9月22日

PostgreSQL 10: What to look for?

  • 講演者:Amit Langote 氏(NTT OSSセンタ)
  • 講演資料:

  • バージョンのナンバリング方式が変わります。2017年は10.0、2018年は11.0

  • 新機能
    • ロジカルレプリケーション(http://qiita.com/bwtakacy/items/d8461518a1770524e0d6)がコアに追加
    • パラレルクエリの適用範囲が広がる
      • Merge Join
      • Hash
      • Bitmap Index Scan
      • ...etc
    • 宣言的パーティショニング(疑似でない)
    • 統計情報の改善
      • CREATE STATISTICS
    • UPDATE時にINDEXの更新をしなくて良いようにする

    • プロセッサの改善

      • recursive->pipeline
    • replicationとbackupのデフォルト設定変わります

Q&A


感想

パラレルクエリに関して現状だと使い所が難しいなと思っていましたが、
気をつけるべき点などがわかりさらに10.0で利用可能範囲が広がるとのことで期待大です。
読影会はぜひ会社でもやってみたいですね。
全体としては知らなかった概念にたくさんぶつかれたので知識が広がって楽しかったです。
運営&発表者のみなさんありがとうございました。
控えめに言ってJPUGは最高。