fnwiya's quine

自分自身を出力するブログ

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は最高。

集合知プログラミングを読んだ

会社の同期で輪読会をしていて現在とりくんでいるのは集合知プログラミングです。

実は読むのは3回目だったりするのですが、
読むたびに学びのある本だなと思います。

学んだこと

  • 教師あり学習と教師なし学習
  • ランダムの使い所
  • 機械学習の発想

注意点

新年の抱負

あけましておめでとうございます。

昨年末から静岡の実家に帰省していましたが、
明日は仕事始めですので東京に戻ります。
(といっても明日は集会をして午前には終わるようです。小学校かw)

昨年はたくさんの方にお世話になり非常によい年となりました。
個人的には「苦手にチャレンジする」をテーマに掲げた一年でしたが、

  • 水泳
  • 食事をとる

などそこそこに達成できたのかなと思います。
2017年は歳男となりますが、
年相応となれるようにがんばっていきます。

簡単ですが今年の抱負を

テーマ: 自分の欲に正直に
わりと将来のために今は、、、みたいな思考になりがちなのですが、
そうなると狭い世界にとどまりがちになってしまいがちで良い偶然にも出会えず、
いつくるかわからないいつかのために消耗し続けても自分楽しそうじゃないなと。

  • 楽器の演奏
  • 英語
  • 哲学
  • ファッション

などなどずっと自分の「いつかやる」リストに入っていたものを、
とりあえずやってみるを大切に好き勝手やっていこうと思います。
BE A BEGINNER!

技術的なお話で言えば、

  • セキュリティ
  • 開発/デプロイプロセス
  • 監視

あたりを重点的にやっていきたいなと(インフラエンジニアっぽい)

去年は色々と手を伸ばしてきましたが今年はやりきることを大切に、
アウトプットまで一セットで深ぼっていければなと思います。

それでは本年もよろしくお願いいたします。
(高速空いてるといいな。。。)

youtubeをfzf/pecoでフィルタリングしながらコマンドラインで再生

コマンドラインに引きこもりたいけど音楽も聴きたかったので聴きたい曲をpecoって選べるようにしてみました。

再生用のツールをインストール

brew install youtube-dl mplayer

聴きたい曲候補を~/favoriteSongs.tsvに
一行目:検索する際のタイトル
二行目:URL
として用意します。

zshの設定(fzfの部分をpecoにしても動きます)

    function fzf-youtube () {
        local title=$(cat ~/favoriteSongs.tsv | cut -f1 | fzf)
        if [ -n "$title" ]; then
            url=$(grep ${title} ~/favoriteSongs.tsv | cut -f2)
            BUFFER="youtube-dl '${url}' -o - | mplayer - -novideo"
            zle accept-line
        fi
        zle clear-screen
    }
    zle -N fzf-youtube fzf-youtube
    bindkey '^x^v' fzf-youtube

これでC-x C-vを叩けばfzfでフィルタリングができ、
選択した曲が流れ始めます。

自分のplaylistから取ってこれたらもっと便利な気がする。

Hatena Engineer Seminar #7 @ Tokyoに行ってきた

Hatena Engineer Seminar #7 @ Tokyoに行ってきました。
はてな東京オフィスでしたが表参道近くのおしゃれな雰囲気漂う素敵なオフィスでした。

まとめとしては

  • 採用で自走できる人を採る。採用に妥協しなければあとは性善説で自由を与えれば大丈夫
  • はてなでも35歳定年説あるかも、、、という話は意外だった
  • 技術選定はコミュニティを重視する。自社のエンジニアをコミュニティに送り込めるか。情報を発信することで情報が集まってくる。
  • エンジニア->マネージャーという一方向キャリアパスだけでなく、再度マネージャー->エンジニアというジョブローテーションもいいよね。
  • 新しいポジションの仕事は自分で定義していい。
  • 個人の技術力の向上と組織の成長が結びついてることが学びのモチベーションとなる。うまくいってる感が大事
  • サービス、組織に対するオーナーシップ。指示は噛み砕きすぎずやんわり伝える。楽しくないなら楽しくしよう。

以下メモ。

はてなで一人前のエンジニアになる方法

@hakobe932
チーフエンジニア

はてなにおけるエンジニア制度

  • アプリケーションエンジニア
    • Serviceチームに所属してアプリケーションを開発
  • ウェブオペレーションエンジニア
    • Serviceを支えるインフラ =>領域はグラデーションでかぶってる
  • チーム横断の組織: 技術グループ
    • シニアエンジニア
    • チームエンジニア

キャリア

  • 専門性
  • 技術グループ
  • チーム運用・企画力=>ディレクター

kakobe932の場合

  • インターン
  • 新卒
    • 技術研修なし(今はある)
  • 2~3年目: チームを渡り歩いて修行
    • チーム移動がしやすい
    • 互いに学び合う文化: 社内勉強会
  • 4~6年目:
  • チーフエンジニア

一人前のエンジニアになれる組織

  • 学び続けられる
    • 環境
    • メンバー
  • 基礎を大事にする
    • 寿命の長い基礎技術を
    • 10年後も使える知識を。フレームワークだけでなく思想や理論
  • 技術の成果を原動力に
    • 成功体験(うまくいっている感)
    • 技術の向上が利益につながる
  • モチベーションを大事にする
    • モチベーションは有限
    • 個々人のモチベーションをみる

Q&A

  • シニアエンジニアの成長支援とは?
    • 1on1

エンジニアがはてなでマネージャーをやるということ

@Songmu
チーフエンジニア&mackerelマネージャー

これまでの経歴

  • 情報系大学で中国語->営業->SI->カヤック->はてな

    心がけていること

  • はてなは一回落ちてる
  • エンジニアのディレクター(まだ少ない)
    • ディレクターはえらかった<-偉くなりたくない。。。
    • Mackerelだから引き受けた。オーナーシップ。仕事は断らない。
  • 自戒
    • 人間は愚かである(スタンフォード監獄実験)
    • マネージャーは偉くない
    • 「マネージャーは南ちゃんだ」
  • マネージャー像
  • オーナーシップ中心マネージメント
    • ×やらされてる感
    • オープン、フラット、遊びを持たせる
    • ブレークダウンしすぎない。やんわりと伝える。
    • 属人化が課題
  • 規則だから守る=>自分から規律を作る
  • マネジャーは評価する人ではなくて成果を代わりにアピールしてくれる人
  • ディレクター<->エンジニアをローテーションしていく。仕組み化していきたい。
  • 我慢しているは自分への言い訳。どうやったら楽しくなるか。

    Q&A

  • メンバーが良くない方向に進んだらどうする?
    • 早めに方向修正する

ウェブオペレーションエンジニアになるまでの思い出

@y_uuki

ウェブオペレーションは技芸であり科学ではない

ぼくがセールスエンジニアというキャリアを選んだ理由(わけ)

@a-know http://www.slideshare.net/aknow3373/ss-69866334

結論

  • エンジニアとしてもっと成長したかった
    • まわりのエンジニア
    • 質問に答える
    • アウトプット
  • 初めてやることは自分で定義していい

パネルディスカッション

@kiyosick

組織の成長/個人の成長

  • 朝会
  • 2週間に1回会議デーがある(5時間会議)。あとは開発
  • 毎日(金曜以外)リリースする。botが教えてくれる。
    • 夜、金曜はリリースしない。定時で帰る。
  • リモートの働き方
    • テレビ会議のSystemが整備されている
    • いけるなら直接会う
    • 京都側にサブディレクターを置いた
    • 雑談大事
  • エンジニアがマネジメントってどう?
    • 35歳定年説はあるかもしれない。。。(あんまりいない)
    • ジョブローテーションをやっていきたい。
  • はてなのエンジニア文化
    • アウトプット。ブログ
    • 技術が好き
    • ランチタイムに勉強会
    • 新しい技術はなかなか導入しづらい(プロダクトの息が長い)。コミュニティが大切。
    • コミュニティに人を送り込めるか。情報を発信して情報を集める。
  • エンジニアの育て方
    • チーム開発は型があるのでそこから
    • 中途の人のギャップははじめは苦労してるっぽい。方法論よりはチームに馴染むことが大切
    • ペアプロ
    • 採用基準で担保してはてな特有の部分を教える
    • 社内の知見はドキュメントに。一般的なことは自分で調べられる人を採る。