scrollIntoView が便利だった話

こんにちは、フロントエンドエンジニアの minamo です。

東京都でも緊急事態宣言が解除され、営業再開する施設が増えてきましたね。

今週はなんと2ヶ月ぶりに映画館に行きました（多い時は週3回は行っていたので、かなり久しぶり）！

公開延期作品が多い代わりに昔の名作が上映される映画館も多いので、2ヶ月通えなかったぶん、どんどん映画を見まくろうと思います。

2度目のブログはちょっとした内容ですが、 JavaScript で便利なメソッドがあったのでご紹介したいと思います。

scrollIntoView() メソッド

scrollIntoView() とは、対象の要素が ブラウザの表示範囲に入るまで スクロールする、というメソッドです。

developer.mozilla.org

事例紹介

これは私が scrollIntoView() メソッドを知るきっかけだったのですが、モーダルウィンドウの中でスクロール移動したい！というときに便利でした。

元のページはスクロールしないよう固定しています（字が汚くてすみません）

最初は安直に scrollTo() で移動すればいいや〜と思ってたんですが、モーダルウィンドウ表示のように overflow-y: scroll; している中ではこの方法は使えなかったんですね。

ウィンドウのスクロール位置は動かないわけですから、当然です。

そこで scrollIntoView() の出番です。

const element = document.querySelector(‘.title’); // 移動させたい要素を指定
element.scrollIntoView();

これで指定した要素が見える位置までスクロール移動してくれます！

オプション（引数）

alignToTop

デフォルトの true では表示させたい要素の上辺がブラウザの上辺に合わせて表示されますが

false を指定すると、表示させたい要素の下辺がブラウザの下辺に合わせて表示されます。

element.scrollIntoView(false);

scrollIntoViewOptions

behavior: 'smooth' でスムーススクロールができます。

element.scrollIntoView({  
    behavior: 'smooth'  
});

オプションでやってくれるなんて気がきいてますね。

注意事項

一部ブラウザ (IE, Safari) では smooth オプションが有効にならないそうです。

caniuse.com

astamuse ではいつでもエンジニア＆デザイナーを募集しています。

もちろんリモートでの面接にも対応していますので、お話だけでもお気軽にどうぞ！

Pipeline Jobから実行結果を簡単にSlackに通知する

こんにちは。宮崎からリモートしてます。開発部のyanagitaです。

新型コロナウィルスの影響の中、皆さんいかがお過ごしでしょうか。
全国的に緊急事態宣言が解除となりましたが、一足早く解除された宮崎では少しずつ緊急事態宣言前の生活に戻りつつあります。
先日、首都圏、北海道も解除宣言されてこともあり、一日も早く宣言前の生活に戻れることを願っております。

話を戻しまして、今回はすこし古いですがJenkinsのPileline JobからSlack通知について書きたいと思います。

今回確認したJenkinsとPluginのバージョン

• Jenkins ver.2.222.3
• Slack Notification Plugin v2.40

(問題)Pipelineプロジェクトでは、Slack Notificationsの設定項目がない

フリースタイル・プロジェクトやMavenプロジェクトでは、ビルド後の後処理に「Slack Notifications」が選択でき、ここでjobの実行結果に合わせてSlack通知の設定が可能になります。
しかし、Pipelineプロジェクトではビルド後の処理項目の表示がないので、Slack通知の設定はPipelineのScript内に記述する必要があります。

フリースタイル・プロジェクトの例

ビルド後の後処理に「Slack Notifications」が選択が可能になっています。

Pipelineプロジェクトの例

Pipelineプロジェクトではパイプラインの設定まででビルド後の処理が項目がないです。

Pipeline Script内にSlack通知を記述する

まず、Pipeline Scriptの記述は2つあって、pipeline記述にとnode記述が存在します。

• Pipeline記述

pipeline {
    agent any
    stages {
        stage("code") {
            steps {
                echo "pipeline."
            }
        }
    }
}

• Node記述

node {
    stage("code") {
        echo "node."
    }
}

両方とも同じ内容のJobになっていて、node構文のほうが記述量が少なく、プログラム形式に記述することができるので細かい制御が可能になりますが、ビルド失敗時のケアもプログラミング同様に記述する必要がでてきます。
複雑なJob実行を求められていないのであれば次で説明するpipeline記述のpost構文と組み合わせるとこで、Slack Notificationsの設定同様にビルド結果に合わせて通知内容を簡単に制御できます。

piepline記述のpost構文は、Jobの実行結果ごとに追加処理を記述することができるようになっています。

pipeline {
    agent any
    stages {
        // job処理
    }

    // ここからがpostの記述
    post {
        success { /* Job正常終了時 */ }
        failure { /* Job失敗時 */ }
    }
}

post直下のsuccess、failureがJob実行結果の条件になっており、該当する条件内の処理が実行されます。
success、failure以外はこちらをご確認ください。

post構文でビルド後の後処理と同様の設定が可能になったので、次に各実行結果の中でSlack通知を記述していきます。
Slack通知はSlack Notification Pluginに含まれるslackSendコマンドを利用します。

post {
    success {
        slackSend  color: 'good',
                           message: "build success."
        }
    }
    failure {
        slackSend  color: 'danger',
                           message: "build failure."
        }
    }
}

Slack通知イメージ

slackSendは、メッセージ以外にチャンネルの指定やBot名も設定できます。(オプションはこちら)
指定しない場合は、Jenkinsの管理 > システムの設定 > Slack設定の内容がデフォルトの通知設定になります。
※ オフシャルのサイトではmessageオプションは省略可能になっていますが、私が環境ではmessageオプションを付けないとビルドエラーになってしまいJobの実行ができませんでした。
※ node記述でもslackSendは利用可能です。

以上、pipeline記述のpost構文とslackSendの組み合わせで、pipeline jobからSlack Notifications設定同様のSlack通知設定が簡単に行えるようになりました。

さいごに

アスタミューゼではたくさんのエンジニア＆デザイナをまだまだまだ募集しています。 気になる方は下からご応募ください！新しい出会いをメンバー一同お待ちしてます！

PostgreSQLのベンチマークを pgbench でバージョン毎に取得してみた

こんにちは。並河(@namikawa)です。

新型コロナウイルスが終息していくことを祈り、弊社もリモートワーク体制に移行しておりまして、私自身もほぼ自宅で過ごしている日々です。弊社では、従前よりフルリモートワークを遂行しているメンバーが数名いますので、各人のリモートワークへの移行も割とすんなり出来たのではないかと感じています。(細かい課題意識はもちろんありますが)

さて、閑話休題。

このブログでも散々話題に出ているかと思うのですが、弊社では技術や投資にまつわるデータを大量に保有しておりまして、それぞれのデータの特性や用途によって、データストアを使い分けています。

その中でも、RDB には PostgreSQL が以前より活用されていまして、今日のエントリの趣旨は、この PostgreSQL の基礎ベンチマーク数値をバージョン毎に差異があるかを確認してみた記録となります。

ベンチマークの取得環境について

ベンチマークを取得した環境について記載しておきます。

• ベンチマークに使用したソフトウェアは "pgbench" です。
  • "pgbench" は PostgreSQL のソフトウェアに標準で同梱されているツール。
• 対象の PostgreSQL のバージョンは、 9.5, 9.6, 10, 11, 12 です。
• PostgreSQL を稼働させたサーバは、Google Compute Engine (GCE) の下記2インスタンスです。
  • n1-standard-1 (1vCPU, 3.75GB)
  • n1-standard-4 (4vCPU, 15GB)
• サーバで稼働させた OS は Ubuntu 20.04 LTS です。
• PostgreSQLのデータを置いたディスクは、SSD で容量は 100GB となります。ファイルシステムは ext4 です。

PostgreSQL の設定については、下記の2パターンを用意して試してみました。

• デフォルトの設定 (インストール時の状態)
• PGTune で生成した設定

環境のセットアップ

GCE でインスタンスを起動させて、以下のコマンドで PostgrSQL が稼働する環境を作ります。

# apt-get install curl ca-certificates gnupg

# curl https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -

# sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'

# apt-get update

# apt-get install postgresql-${バージョン番号}

これで、PostgreSQL サービスが稼働しているのと、pgbench も実行できる状態になっているはずです。

続いて、ベンチマークで使うデータセットを pgbench を使って実行します。

# su - postgres

$ createdb test

$ pgbench -i -s 10 test

pgbench コマンドは "-i" オプションが初期化モード、 "-s" オプションが生成されるデータの桁数を示します。デフォルトは 1 で、1 だと10万行となります。↑の例だと100万レコードでデータセットが生成された感じです。

ベンチマークの取得

次に、実際にベンチマークを取得してみます。 今回は、以下のコマンドで取得を行いました。

$ pgbench -c 16 -t 1000 test

"-c" はクライアント数なので、↑の例だと同時に 16 コネクションで同時実行していることになります。 "-t" オプションは、各クライアントが実行するトランザクション数です。

ベンチマークは、下記のそれぞれの条件において、上記のコマンドを5回実行し、その中央値を結果として記載しています。

ベンチマーク結果

今回とったベンチマークの結果が以下の表となります。

縦軸が PostgreSQL のバージョン。横軸の項目は、1つ目の表記がサーバのコア数で、2つ目の表記が PostgreSQL の設定です。で、結果の数値は TPS (excluding connections establishing) となります。

横軸の補足説明ですが、例えば、1つ目の "1core, default" だと、1コアのインスタンスで、デフォルトの PostgreSQL の設定を使った結果となります。4つ目の "4core, PGTune" は、4コアのインスタンスで、PostgreSQL の設定をPGTuneの推奨値に書き換えた結果となります。

グラフにすると以下。

こちらの結果から、概ね、バージョンを上げていくことで、TPSレベルでの基本的なパフォーマンスは伸びていっているように思います。またデフォルトの設定ではなく、PGTune の推奨値を使った方が、よりパフォーマンスが上がる結果になりました。

シングルコアのサーバ（今時あまり使わないかもしれませんが）だと、その結果は顕著です。

一方で、4コアのサーバを使った結果は、バージョンごとにさほど大きな差はつきませんでした。ひょっとしたらデータセットのサイズ、メモリサイズとその割り当て量が影響しているのかなとも思いますが、I/Oの状況等、あまり細かく見れていないので、もう少しレコード数を増やした検証も、後日行ってみたいなと考えています。

とりあえず、この数値だけみていると、バージョン 12 には上げていきたいなーと思ったので、「PostgreSQL の バグ修正状況を調べてみた。」を参考に、下半期以降とかでアップグレードしていきたいな、と思ったのでした。

・・・と、若干中途半端感は否めないのですが、今日はこの辺で。 本当は、もうちょいコア数をスケールさせたらどうなる？とか、データセットのサイズ変えたらどうなる？とか、クライアントのコネクション数やトランザクション数変えたらどうなる？とか、時間があれば色々やってみたいと思うので、また追試したら、結果報告したいと思いますー！

それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

（@namikawa が書いた過去記事）

• 社内無線LAN環境改善のためにやったこと (2019/Summer)
• Linuxでユーザアカウントを無効化するエトセトラ
• /etc/hosts で同じホスト名に違うIPアドレスを設定したらどうなるか
• 何気に便利に使えるかもしれない authorized_keys のオプション
• Linuxでinodeが枯渇した場合にどうやって調査するか
• アスタミューゼの開発組織と採用に関するQAアレコレ
• Linuxでディスクキャッシュとして使える「bcache」を試してみた
• Google Compute Engine のディスク(SSD)ベンチマークを取ってみた
• nginx + ngx_mruby でSSL証明書の動的読み込みを実現して、作業がとても楽になった話
• クラウドにあるステージング環境のシステムコスト大幅削減を進めている話
• 企業向けエンジニアブログの作り方