よしたく blog

ITエンジニアとして自分が知らなかったことをまとめています

【SQL】LAG関数・LEAD関数の動きを確認する

SQL の分析関数である LAG と LEAD を使うと、現在の行の値と前後の行の値を比較できる。 今回は LAG を使って、動きを確認していく。 LAG は前の行、LEAD は後ろの行という違いだけで、構文は 同じになるので、LEAD を知りたい場合は適宜置換してもらえると!

実行環境

テストの場所としては以前も使った、SQL Fiddleで試した。 ブラウザ上でサクサク試せるので便利!

sqlfiddle.com

yoshitaku-jp.hatenablog.com

エンジンのバージョンはPostgreSQL 9.6を使っている。

https://www.postgresql.jp/document/9.3/html/functions-window.html

まずは小さなデータを投入してシンプルな動きを確認する。 その後、少しずつパラメータを追加していき、さらに動きを確認する。

データ投入

id,money,date の列からなっていて、3 行分のデータが入っている。わかりやすくするため 1 ずつ数字を上がっていくものとした。

CREATE TABLE LAG_TEST
(id     CHAR(4) NOT NULL,
 money  INTEGER ,
 date      DATE ,
  PRIMARY KEY (id));

BEGIN TRANSACTION;
INSERT INTO LAG_TEST VALUES ('0001', 1000, '2021-01-01');
INSERT INTO LAG_TEST VALUES ('0002', 2000, '2021-02-01');
INSERT INTO LAG_TEST VALUES ('0003', 3000, '2021-03-01');
COMMIT;

シンプルな実行

SQL を組み立てて実行する。 LAG 関数は次の形で指定する。

LAG (scalar_expression [,offset] [,default])
    OVER ( [ partition_by_clause ] order_by_clause )

実際の SQL にすると次になる。 money の列を対象に、1 行ずつ前のものを参照している。 並び順は date に従っている。

SELECT
  id,
  money,
  date,
  LAG(money, 1) OVER (ORDER BY date)

FROM
  LAG_TEST

id: 0002id: 0001の money を参照していて、id: 0003id: 0002の money を参照している。 無事に 1 つ前の行の値を見ていることがわかる。

id money date lag
0001 1000 2021-01-01 (null)
0002 2000 2021-02-01 1000
0003 3000 2021-03-01 2000

offset を変更してみる

先程は offset1 にして、1 つ前の行を参照することとした。 offset の値を 2 に変えてみる。

SELECT
  id,
  money,
  date,
  LAG(money, 2) OVER (ORDER BY date)

FROM
  LAG_TEST

id0003の行が参照している値が変化した。

先程は、id: 0002id: 0001の money を参照していて、id: 0003id: 0002の money を参照していた。 今は、id: 0002nullとなりid: 0003id: 0001の money を参照している。 これは参照する行が 2 つ前の行の値を見ることとなったからである。

id money date lag
0001 1000 2021-01-01 (null)
0002 2000 2021-02-01 (null)
0003 3000 2021-03-01 1000

デフォルトを設定してみる

次にLag関数の引数を増やしてみる。 この部分はデフォルトを指定する部分になる。 offset2 のままにして、後ろに 0 を追加する。

LAG(money, 2, 0) OVER (ORDER BY date)

SELECT
  id,
  money,
  date,
  LAG(money, 2, 0) OVER (ORDER BY date)

FROM
  LAG_TEST

「offset を変更してみる」では、参照していない行nullとなっていたが、今回は 0 が入っている。 defaultを設定すればその値が、設定しなければnullを設定することがわかった。

id money date lag
0001 1000 2021-01-01 0
0002 2000 2021-02-01 0
0003 3000 2021-03-01 1000

OVER 句

次に OVER 句を見ていく。 OVER 句の中ではORDER BYPARTITON BYを指定できる。

ORDER BY

ORDER BYは通常の SQL と同様、並び替えができる。 ここではdescを末尾に設定し、並び順を逆転させている。

SELECT
  id,
  money,
  date,
  LAG(money, 2, 0) OVER (ORDER BY date desc)

FROM
  LAG_TEST

ここで注意するべきことは、LAG 関数で参照した後に並び替えるのではなく、並び替えてから LAG 関数が適用されていることである。

id money date lag
0003 3000 2021-03-01 0
0002 2000 2021-02-01 0
0001 1000 2021-01-01 3000
LAG関数を適用してから...

| id   | money | date       | lag  |
| ---- | ----- | ---------- | ---- |
| 0001 | 1000  | 2021-01-01 | 0    |
| 0002 | 2000  | 2021-02-01 | 0    |
| 0003 | 3000  | 2021-03-01 | 1000 |

dateで並び替えているわけではない。

| id   | money | date       | lag  |
| ---- | ----- | ---------- | ---- |
| 0003 | 3000  | 2021-03-01 | 1000 |
| 0002 | 2000  | 2021-02-01 | 0    |
| 0001 | 1000  | 2021-01-01 | 0    |

PARTITON BY

PARTITON BYを使うとGROUP BYと似たようなことができる。 GROUP BYはグループでまとめた行を表示するが、PARTITON BYはグループ単位で仕切って行を表示するイメージになる。

PARTITION BY GROUP BY
グループ単位で仕切る グループ単位でまとめる

ここで少しデータを増やす。 4 月分のデータと、比較用の昨年度データを投入した。

CREATE TABLE LAG_TEST
(id     CHAR(4) NOT NULL,
 year  INTEGER ,
 month  INTEGER ,
 day  INTEGER ,
 money  INTEGER ,
 date      DATE ,
 PRIMARY KEY (id));

BEGIN TRANSACTION;
INSERT INTO LAG_TEST VALUES ('0001','2020','01','01', 100, '2020-01-01');
INSERT INTO LAG_TEST VALUES ('0002','2020','02','01', 200, '2020-02-01');
INSERT INTO LAG_TEST VALUES ('0003','2020','03','01', 300, '2020-03-01');
INSERT INTO LAG_TEST VALUES ('0004','2020','04','01', 400, '2020-04-01');
INSERT INTO LAG_TEST VALUES ('0005','2021','01','01', 500, '2021-01-01');
INSERT INTO LAG_TEST VALUES ('0006','2021','02','01', 600, '2021-02-01');
INSERT INTO LAG_TEST VALUES ('0007','2021','03','01', 700, '2021-03-01');
INSERT INTO LAG_TEST VALUES ('0008','2021','04','01', 800, '2021-04-01');
COMMIT;

PARTITION BYmonthを指定して、昨年との値を月ごとに比較する。

SELECT
  year,
  month,
  money,
  LAG(money, 1, 0) OVER (PARTITION BY month ORDER BY date) AS 昨年の値,
FROM
  LAG_TEST

PARTITON BYはグループ単位で仕切って行を表示するイメージ

と書いたが、1 月、2 月と月ごとにまとめられ、その中で比較がおこなわれているのがわかる。 3 行の| 2020 | 2 | 200 | 0 |は前の行の500を参照していないことからも理解できると思う。

year month money 昨年の値
2020 1 100 0
2021 1 500 100
2020 2 200 0
2021 2 600 200
2020 3 300 0
2021 3 700 300
2020 4 400 0
2021 4 800 400

まとめ

LAG 関数を使いながら動きを確認できた。 LEAD 関数は LAG と置き換えるだけと書いたが実際そのとおりになる。 試しに最後の SQL を LEAD 関数に置き換えてみる。列名も「翌年の値」と変更しておく。

SELECT
  year,
  month,
  money,
  LEAD(money, 1, 0) OVER (PARTITION BY month ORDER BY date) AS 翌年の値
FROM
  LAG_TEST
year month money 翌年の値
2020 1 100 500
2021 1 500 0
2020 2 200 600
2021 2 600 0
2020 3 300 700
2021 3 700 0
2020 4 400 800
2021 4 800 0

分析というと、現在から過去に向かっていくイメージを持つ人が多くいると思ったので、LEAD 関数ではなく LAG 関数で手を動かしてみた。 そのまま手を動かせるものにしたので、実行して確認してもらえれば👌

【Databricks】マネージドテーブルとアンマネージドテーブルの違い

Databricksで saveAsTable()関数を使うと、Spark SQL テーブルを作成できる。今回はsaveAsTable()関数を使って作成される「マネージドテーブル」「アンマネージドテーブル」の違いを見ていく。

マネージドテーブルとアンマネージドテーブルの違い

すべての Spark SQL テーブルには、スキーマとデータ自体を格納するメタデータ情報が含まれています。マネージテーブル は spark SQL テーブルで、spark はデータとメタデータの両方を管理します。 マネージテーブルの場合、Databricks はメタデータとデータをアカウントの DBFS に格納します。 Spark SQL はテーブルを管理するため、を実行する DROP TABLE example_data と、メタデータとデータの両方が 削除されます。

別の方法として、データの場所を制御しながら、Spark SQLメタデータを管理することもできます。 これを アンマネージテーブル と呼びます。 Spark SQL は関連するメタデータを管理するため、を実行すると DROP TABLE <example-table> 、データ自体ではなく、メタデータのみが削除されます。 指定したパスには、データがまだ存在しています。

マネージドテーブルはDatabricks上でデータとメタデータを持っている。アンマネージドテーブルはDatabricks上でメタデータは持っているが、データは外部のストレージに持っていることになる。整理すると次の表になる。

マネージドテーブル アンマネージドテーブル
メタデータ Databricks ファイル システム Databricks ファイル システム
データ Databricks ファイル システム 外部ストレージ

ここからは実際に手を動かして、データの投入、データの更新、テーブルの削除をおこない動きを見ていく。

データの準備

簡単なデータを用意する。SparkSessionのrange()関数を使ってID列に1から10の値が存在するDataFrameを用意した。

df = spark.range(10)
display(df)
#id
#0
#1
#2
#3
#4
#5
#6
#7
#8
#9

マネージドテーブルの作成

saveAsTable() 関数を実行するとマネージドテーブルが作成される。Dataのタブからmanaged_tableと名付けられたテーブルが作成されている。1~10の値も確認ができる。

df.write.saveAsTable("managed_table")

f:id:yoshitaku_jp:20210526145701p:plain

f:id:yoshitaku_jp:20210526145737p:plain

アンマネージドテーブルの作成

saveAsTable() 関数の前にoption('path', "<YOUR_PATH>")を実行するとアンマネージドテーブルが作成される。 その前の準備段階として、DBFS上の<YOUR_PATH>に外部のストレージをマウントをおこなう必要がある。 今回保存先にはAzure Data Lake Storage Gen2を選択した。 ADLSの作成手順は割愛する。

保存先のマウント

まずはセル上で変数の定義をおこなう。

storageaccount=""#<ストレージアカウント名>
storageaccountkey= ""#<ストレージアカウントのキー>
containername="" #<container名>

次に、mount()関数を使い、ADLSのURL、マウントするDBFSのパス、ストレージアカウントのキーを設定し実行する。 これでDBFSの/mnt/unmanaged_tableにADLSがマウントされる。

dbutils.fs.mount(
  source = "wasbs://" + containername + "@" + storageaccount + ".blob.core.windows.net/",
  mount_point = "/mnt/unmanaged_table",
  extra_configs = {"fs.azure.account.key."+storageaccount+".blob.core.windows.net":storageaccountkey})

option('path', "<YOUR_PATH>")を付けたsaveAsTable() 関数を実行するとアンマネージドテーブルが作成される。 今回は/mnt/unmanaged_tableにマウントしたので、こちらを指定する。

df.write.option('path', "/mnt/unmanaged_table").saveAsTable("unmanaged_table")

f:id:yoshitaku_jp:20210526212501p:plain f:id:yoshitaku_jp:20210526212524p:plain

マウント先のAzure Data Lake Storage Gen2のコンテナにもデータが保存されていることがわかる。

f:id:yoshitaku_jp:20210526212432p:plain

テーブルの更新

テーブルの内容を更新することもできる。 マネージドテーブルもアンマネージドテーブルもmode("overwrite")を付けて実行するだけになる。

マネージドテーブル

df = spark.range(20)
df.write.mode("overwrite").saveAsTable("managed_table") 

f:id:yoshitaku_jp:20210526212807p:plain

アンマネージドテーブル

df.write.mode("overwrite").option("path","/mnt/unmanaged_table").saveAsTable("unmanaged_table") 

f:id:yoshitaku_jp:20210526212859p:plain

ADLS上のデータも増えている。

f:id:yoshitaku_jp:20210526212938p:plain

テーブルの削除

テーブルの削除はSQLでおこなう。 ここまでPythonで作業してきたのでマジックコマンドの%sqlを付けて、DROP TABLEを実行する。 dataタブからテーブルが両方とも削除されていることを確認する。

%sql
DROP TABLE  managed_table
#OK
%sql
DROP TABLE  unmanaged_table
#OK

Databricks上からはmanaged_tableとunmanaged_tableが削除されている。

f:id:yoshitaku_jp:20210526214444p:plain

アンマネージドテーブルで作成したデータはストレージから削除されていないことが確認できる。

f:id:yoshitaku_jp:20210527091505p:plain

運用上の注意点

AzureDatabricksBestPracticesでは、本番データをDBFSフォルダに置かないよう注意している。

  • デフォルトのDBFSのライフサイクルは、ワークスペースに関連付けられています。ワークスペースを削除すると、デフォルトのDBFSも削除され、その内容が完全に削除されます。
  • このデフォルトフォルダとその内容へのアクセスを制限することはできません。

ワークスペースを削除するとDBFSも自動的に削除されてしまうことと、DBFS上のデータに対してセキュリティ的に制限をかけることが出来ないのでやめておいたほうがいいといった内容になる。

一番最初に登場した表で再度整理すると次のようになる。

マネージドテーブル アンマネージドテーブル
メタデータ Databricks ファイル システム Databricks ファイル システム
データ Databricks ファイル システム 外部ストレージ
本番データ 非推奨 推奨

まとめ

Databricks上で作成されるマネージドテーブルとアンマネージドを作成し動きを確認した。運用上の注意ドキュメントを見つけて改めて違いを確認したが、頭の中を整理できてよかった👌動くコードを提示できたので誰かの役に立てれば🙏

Scroll Reverserを使ってマウスのスクロール方向を反転させる

今回は Mac のアプリ「Scroll Reverser」を紹介する。 「Scroll Reverser」を使うと、マウスのスクロールを反転させることができる。

普段の仕事は Windows 機でマウスは「Logicool M575GR」を使っている。 使い慣れたマウスをプライベート機の mac でも使いたかったが、マウスのスクロールの方向は逆になっていて慣れなかった。 「トラックパッド/マウスでの操作」からスクロール設定を変更し反転されていたが、トラックパッドのスクロール変更も同時におこなわれてしまっていて、使いたびにスクロール方向を切り替えることも大変だった。

そんなときに見つけたのが「Scroll Reverser」だった。 すぐに導入して使えるようになるのでおすすめ。

導入方法とオンオフ

https://pilotmoon.com/scrollreverser/ にアクセスして、自分のバージョンにあったものをダウンロードする。

「Scroll Reverser」は常駐アプリで、メニューバーのところで動作中か確認できる。

f:id:yoshitaku_jp:20210523120539p:plain

右クリックをすると色がグレーになり、オフの状態できる。

f:id:yoshitaku_jp:20210523120552p:plain

設定方法

クリックをするとメニューが広がり、「設定」に移動できる。

f:id:yoshitaku_jp:20210523120604p:plain

スクロール方向とスクロール設定するデバイスが分かれていて、それぞれ設定を変えることができる。 横の方向を逆にしたいユースケースはあまり想像がつかないが左右を入れ替えることができる。

f:id:yoshitaku_jp:20210523120616p:plain

キャプチャの画像は今現在の自分の設定で、整理すると次のようになる。

アプリ自体の設定

PC へログインしたときに「Scroll Reverser」を自動起動するかと、メニューバーに表示するかを選べる。

f:id:yoshitaku_jp:20210523120629p:plain これで設定が完了となる。

SQLで勘定科目内訳書を作成する

SQL で家計簿のような科目別で集計した表を作成するテクニックを見て驚いたのでブログに残しておく。

環境を用意しないで SQL を試せる場所として SQL Fiddleが良かったので、使ってみてほしい。

画面構成

SQL Fiddleについて説明しておく。 アクセスすると次のような画面になる。 真ん中に左右大きく枠があり、下部に横長の枠がある。

f:id:yoshitaku_jp:20210516100150p:plain

まずは左右の左側だが、こちらにはテーブルの情報やデータの挿入などを実施する部分になる。 次に左右の右側で、こちらはテーブルから情報を取得する SELECT 文を書く場所になる。 最後に下の横長になるが、こちらは実行結果が表示される部分になる。

細かい部分としては左上のSQL Fiddleの右側でデータベースエンジンを切り替えることができる。 今回は SQLite(WebSQL) を使ったので、この先の SQL を実施する場合は切り替えてほしい。

サンプル構成

テーブルは次のものになる。

テーブル

  • id
  • type
    • 家計簿の科目
  • stuff
    • 具体的なもの
  • money
    • 金額

サンプル説明

DDL

テーブルを作成しデータを投入する SQL 文は次のものになる。

-- this version is using your browser's built-in SQLite
CREATE TABLE HouseholdAccountBook
    (
     id integer primary key,
     type varchar(20),
      stuff varchar(20),
     money varchar(30)
    );

INSERT INTO HouseholdAccountBook
(id, type,stuff, money)
VALUES
(1, 'Food expenses','lunch', '1000');

INSERT INTO HouseholdAccountBook
(id, type,stuff, money)
VALUES
(2, 'Food expenses','dinner', '1500');

INSERT INTO HouseholdAccountBook
(id, type,stuff, money)
VALUES
(3, 'Communication expenses','Mobile phone bill','5000');

INSERT INTO HouseholdAccountBook
(id, type,stuff, money)
VALUES
(4, 'Communication expenses','Internet fee','6000');

投入した具体的なデータ

SQL 文の中に記述されている投入したデータもこちらにまとめておく。

  • Food expenses
    • lunch(ランチ)
    • dinner(夜ご飯)
  • Communication expenses
    • Mobile phone bill(携帯代)
    • Internet fee(インターネット料金)

まずはそのまま取得する

select
  id
  ,type
  ,stuff
  ,money
  from HouseholdAccountBook
id type stuff money
1 Food expenses lunch 1000
2 Food expenses dinner 1500
3 Communication expenses Mobile phone bill 5000
4 Communication expenses Internet fee 6000

各科目の合計が知りたい

ここで Food expenses ごと、Communication expenses ごとの合計が知りたいとする。 次のような SQL になる。

select
  type
  ,SUM(money)
from HouseholdAccountBook
GROUP BY type
type SUM(money)
Communication expenses 11000
Food expenses 2500

2 つの結果をくっつけたい

この結果をくっつけて Food expenses の合計と Communication expenses の合計も一緒に表示したいときは UNION ALL を使う。 各科目の合計を取得した SQL を少し変えて、次のようにする。

select
  id
  ,type
  ,stuff
  ,money
from HouseholdAccountBook

UNION ALL

select
  MAX(id)
  ,type || ' - total'
  ,'' as stuff
  ,SUM(money)
from HouseholdAccountBook
  GROUP BY type

ORDER BY id

合計の行を MAX(id)で取得し、order by することで科目毎の最下部に位置できる。

  • Food expenses
    • 1000 + 1500 = 2500
  • Communication expenses

    • 5000 + 5000 = 11000

    で計算結果もあっている。

id type stuff money
1 Food expenses lunch 1000
2 Food expenses dinner 1500
2 Food expenses - total 2500
3 Communication expenses Mobile phone bill 5000
4 Communication expenses Internet fee 6000
4 Communication expenses - total 11000

最終的な SQL

今の考え方を使えば、Food expenses と Communication expenses を合計したものも取得できる。 SQL は長くなるのでまずは結果から載せる。最終行に全ての合計が存在している。

id type stuff money
1 Food expenses lunch 1000
2 Food expenses dinner 1500
2 Food expenses - total 2500
3 Communication expenses Mobile phone bill 5000
4 Communication expenses Internet fee 6000
4 Communication expenses - total 11000
4 total 13500
select
id
,type
,stuff
,money
from HouseholdAccountBook

UNION ALL

select
MAX(id)
,type || ' - total'
,'' as stuff
,SUM(money)
from HouseholdAccountBook
GROUP BY type

UNION ALL

select
MAX(id)
,'total'
,'' as stuff
,SUM(money)
from HouseholdAccountBook

ORDER BY id

まとめ

SQL で勘定科目内訳書のようなものを作成する Tips を投稿した。 テーブルを縦に結合する UNION ALL はもちろん知っていたが、なかなか使う機会がなかったので具体的な方法が知れてよかった。

アジャイルなチームをつくる ふりかえりガイドブックを読んだ

以前、「スクラム」をテーマにしている SCRUM BOOT CAMP THE BOOK を読んだところ、ふりかえりにあたる「レトルスペクティブ」に対する言及が少なかったので、この本を手にとった。

yoshitaku-jp.hatenablog.com

内容

これから始める人を対象にしていることが SCRUM BOOT CAMP THE BOOK と同じで、優しく手ほどきをするように書かれていた。 さらに SCRUM BOOT CAMP THE BOOK で少なかった「レトロスペクティブ」を補う目的で書かれたのか、本の表紙から中身まで似たような構成で作られていた。 例えば、内容がストーリー仕立てで書いてあったりマンガも多く差し込まれていた。 続編のような形で本作りが似ていたため、読み手としてはスムーズに内容に入っていけた気がする。

内容としては 4 部構成になっていて、「基礎編」「実践編」「手法編」「TIPS 編」となっている。 SCRUM BOOT CAMP THE BOOK と違う部分で言えば、基礎編実践編でのストーリーは本の半分ぐらいで、手法編で「ふりかえりの型 手法」が多く載っていた。

個人的に良かったところ

手法がまとめられていた

このあたりはよく耳にする KPT や Fun/Done/Learn をはじめ、耳にしたことがないようなものも含めて 20 個挙げられていた。 個別での形で手法は名前をよく耳にしていたが、他のものと対比できるような形でまとめてあるのはありがたいと感じた。 他にもふりかえりで使うタイミングなども明記されているのが、自分たちの現在地と照らし合わせて手法を選べるような気がしてよかった。

行動と気持ちの振り返り

ふりかえりというと実際に行動したことを中心におこないそうだが、気持ちの面もふりかえろうと書いてあったのが良かった。人間は感情な生き物でもあるので、この時この場面でどう感じたかを自分で認知し周りと共有することもとても大切だと思った。

すべての問題を解決する銀の弾丸ではない

ふりかえりをはじめるときには「ふりかえりが問題を全部解決してくれる」と過度な期待を抱きがちです。問題を明らかにしたり、次のアクションをみんなで考えたりすることはできますが、アクションを実行して問題を解決するのはあくまでチーム自身の力によるものです。

P62 より引用

この言葉は自分の中に気づきを与えてくれた。

例えば、なにか一区切りついたときに「ふりかえりをしましょう」と言う誰かの発言から、一連の流れをふりかえることがある。 しかし、せっかく長い時間賭けてふりかえった後に、そのふりかえりを活かせていないことが多かった。 その結果、自分の中でふりかえりは「やる人たちの満足感を得るためだけのものになっていて、正直やる意味はないんじゃないか」という思いになっていった。

ここでわかったことは、ふりかえりの責務は問題の可視化であったり、次のアクションを決める場を提供するだけということだった。 あくまでもやるのは自分達自身だし、またそのための仕組み作りも大切であることを得ることができた。

まとめ

ふりかえりガイドブックを読んだ。 チームとしてふりかえりの場を設けることは現時点でなさそうだが、個人としてのふりかえりはできるので少しずつ実践していく気持ちになれた。 ふりかえりの真価はふりかえり以外の部分での変化を促進するという言葉もあり、ふりかえりの時間を設けて日々の生活をアップデートしていこうと気持ちを新たにできた。

さっそくふりかえりの良い作用が出てきていて、タスクツールを使ってタスクを管理しようとしていたが、アプリを起動しないと見ない現状をふりかえってみた。 いつもその問題点に気が付かず、色々なアプリを巡っていたが、今回は問題点を書き出して対応した。 今は常に見えるものとして小さいホワイトボードを購入し卓上で管理している。

ITエンジニア向け図書館読書法

以前「メルカリ読書法」が話題になったが、自分には合わなかったので図書館にアレンジして実践してみた。 メルカリ読書法の詳細は下記に書いてある。

note.com

要するに実践していくと、メルカリに出品することで本を読み終えるプレッシャーをかけ、積ん読の解消ができるような感じである。

合わなかった点

読む本の種類

自分が読む本が偏っていて「IT系の技術書が多い」というのがある。 このブログを読んでいるメインの人にも共通すると思う。

本の内容として難しかったりもするし、手を動かして理解をする場合もある。 そうなったときにメルカリ読書法だと、出品直後に売れたりすると明らかに間に合わない。 逆に読み終わりそうになってから出品する方針とすると、途中で読むのをやめてしまい結局積んでしまって、そもそもメルカリ読書法のメリットを得ることができない。

メルカリ読書法はビジネス書だったり、自己啓発系があっていると感じたので、こちらでは実践していこうと思う。

技術書は高い

IT系の技術書は最初に手を出す金額が高い問題がある。 ビジネス書や自己啓発系は1500円前後で手に入るし、過去に有名になった本は文庫化されていたりしてより安くなっている。 一方、技術書は3000円あたりが普通だし5000円なんてものもある。

値段のあたりは仕方がないが、読み終わったら売ればいい思考がありつつも、初手に出す値段が高いために失敗したくない思いが働いて、そもそも手を出さないという悪循環になってしまった。

図書館に変えてよかった点

図書館に変えてよかった点を上げていくが、あくまでも自分が住んでいる市区町村の話であり、自分が住んでいる場所のことは調べて対応してほしい。

借りれる期間が決まっている

これはメルカリ読書法の「売れるまでに読み切る」をうまく置き換えられたと思う。 自分が住んでいる場所では通常2週間借りられるので2週間の間に読み終えればいいという思考になれた。 終わりが決まっているので分量が多いものもペースを作って読むことができた。 場所によっては借りる期間の延長もできるので活用してもらうと良さそう。

費用がかからない

費用がかからないので少し値段が高い本も気軽に読むことができた。 また、近い図書館に本がなくても、同じ市区町村内、または近隣の市区町村から取り寄せてくれたりする。

自分の場合は

  • 同じ市区町村内
    • 2,3日前後
  • 近隣の市区町村
    • 2週間前後

で、本が最寄りの図書館に届いた。 急ぎのものは買うしか無いが、気になっていた系なら頼んでおいてまったり待つのが良さそう。

費用がかからないと書いたが、手元においておきたいと思ったものは改めて購入するようにしている。 このあたりは自分の気持ちの面もあるので、無理に強要するものではない。 少し後ろめたい人は、感想ツイートだったり、ブログなどでアウトプットすると良さそう。

まとめ

在宅で家にいることが多くなった人にはとても有効だと思うのでぜひやってみてほしい。

Dockerにssh公開鍵認証でログインする

Dockerでsshでログインしようとしたら思ったよりハマったのでメモをしておく。

まずはDockerでdebianを起動する。

docker run --name ssh_sample -it -p 127.0.0.1:2022:2022 debian:stable

設定ファイルなど必要なものをインストールする

apt -y update 
apt install -y sudo ssh vim
vim /etc/ssh/sshd_config
  • Port
    • 2022
  • PasswordAuthentication
    • yes
  • PermitRootLogin yes
    • yes

編集が終わったらservice ssh restartsshを再起動する。

ローカルPCに戻って、鍵を作成する。 さらに、鍵をDockerの中へ送る。

ssh-keygen -f ssh_sample
ssh-copy-id -p 2022 -i ~/.ssh/ssh_sample.pub root@localhost
ssh-add -K ~/.ssh/ssh_sample

公開鍵認証にするために再度設定を変更する。

vim /etc/ssh/sshd_config
  • PubkeyAuthentication
    • yes
  • PasswordAuthentication
    • no

編集が終わったらservice ssh restartsshを再起動する。

これで公開鍵でログインすることができる ssh -p 2022 root@localhost

自分なり勉強時間捻出法

資格試験を3月末までに合格しなければいけなかったため、どうしても勉強時間を捻出する必要があった。 結論から言うとSNSに滞留する時間を削った。 無事に資格試験にも合格して、その後もいい勉強のサイクルが生まれているので現時点での記録としてメモをしておく。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

スマホからアプリを消す

まずスマホにアプリが入っている場合はスマホから削除する。 いきなり一番難しそうだけど、これが一番効果がある。 手に届く場所から消えるので起動する回数が減った。

何を消して何を残したかは次になる。

LINEはSNSというより連絡手段のツールなので仕方がないし、常駐して楽しむものでもないのでこのままにした。 Instagramをそのままにした理由は2つある。

  • そもそもフォローしている人数が少ない
  • 基本的には写真をつけないと投稿できない制約

という面から情報が流れるスピードが遅いと判断できたからになる。 情報が少なければ、すぐにInstagramから現実世界に戻ってくることができる。

Twitterはこの理由の逆になり、フォローしている人が多いし、テキストで気軽につぶやかれる。つまり情報が流れてくるスピードが早いため削除の対象になった。 スピードが早いと貯まる情報の量も多くなり、それを消費するために時間も使い…と悪循環になる。 コミュニケーションのツールとしては素晴らしいので、アカウントを削除したり、フォロー整理をすることは考えなかった。

次に難しそうなものがSlackになる。 自分は在宅な上に業務でSlackを使っていないのでスマホから排除することができたが、そうでない人は会社のSlack以外はサインアウトしておくといったことで対応できるかなと思った。 これも情報が溜まる場所を少なくしていく考え方に近い気がする。

削除することへの弊害にどう対処するか

削除をすると情報が得られない可能性があるので難しいという話があるかもしれない。 だが、少し悲しい話になるが、そんなに急ぎで重要な話が飛んでくることは少ない現実がある。 業務用Slackの話は置いておくが、突然Twitterで可及的速やかに知らせないといけないという理由でメンションされることがあっただろうか、コミュニティSlackで今すぐにも知らせたいと話題を振られることがあっただろうか。 たぶんほとんどの人がないんじゃないかと思う。 自分も最初は心配だったので、TwitterのDMが来たらメールアドレスに通知する設定したりして対処した。 今ではこれで全く問題なく回っている。

SNSでアクティブに行動しない

主にTwitterの話になる。スマホからアプリを削除した結果ある程度快適な環境が完成した。 次に実行したことは、より勉強の時間を捻出するために自分からSNSでアクティブに行動する時間を減らした。 Twitterでいうとつぶやく回数を減らした。

iPadやPCのブラウザからTwitterにアクセスして気分転換することはあったが、そこでつぶやくことを控えた形になる。 自分からつぶやかないことによって、「なにかリアクション来ているかな?」の確認を減らすことができた。 そもそも、このご時世なのでなかなかつぶやけることも少ないので、それも相まった。

まとめ

3月末までに合格しなければいけないプレッシャーもあったが、もう一つプレッシャーを感じていて、それはコロナに対する慣れだった。 生活様式がガラリと変わって1年経つが、ある意味で慣れてきたこともあり、そんな中でこのままだともう一年同じように過ごすのではないかというプレッシャーが自分の中に掛かってきた。 ここで大きく何かを変えようと思ったら、SNSから離れることだった。

ここにメモ書きしたように今のところうまくいっていて、仕事について落ち着いて考える時間だったり、勉強する時間だったり、それ以外のことだったり自分の時間を取り戻すことができたように感じている。 時間を投資する方向を少しずつだけど修正できていて、何よりその時間が楽しい。次は、投資した結果がいい方向に向いてくれることを祈っている。

SCRUM BOOT CAMP THE BOOKを読んだ

社内でアジャイル開発研修を受けたので、そのままいくつか深堀りしたくなり、「スクラム」をテーマにしている SCRUM BOOT CAMP THE BOOK を読んだ。

はじめて「スクラム」をやることになったら読む本

と表紙に書いてあるように、内容がストーリー仕立てで書いてあったりマンガが差し込まれていたり、とてもわかりやすかった。

内容

本の内容は、スクラムマスターを任されることになった「ボク」を中心に話が進んでいき、その中でスクラムを実践していくというもの。 ページ数としては 250 ページほどになり、前にも書いたが挿絵が豊富だったりもするのでサクサク読める。 集中して読めば 1 日で、もしくは土日で読み終えることができそう。

最初の 20 ページは基礎編としてスクラムを聞いたことない人のための用語解説があり、今スクラムという単語を聞いた人にもわかりやすいようになっている。 残りは実践編として、ストーリーに沿ってスクラムをおこなっていく姿を見ていくもので、なんとなく概要を知っている人はこちらから入っても良さそう。

あえて書かれなかった「ふりかえり」から見るこだわり

この本にはふりかえり(スクラムとしては、スプリントレトロスペクティブ)については書かれていなかった。 終盤に差し掛かったとき「ふりかえりついては解説が無いのかな?」と読み進めていたが、なぜ振り返りについては書かなかったかがきちんと記されていて納得した。

けれど、最初の頃のスプリントレトロスペクティブは、スプリントで起きた問題に対処しようとして、問題解決のイベントになりがちになる。ボクくんたちも、そうなっていただろう。それだと本来のスプリントレトロスペクティブの姿を誤解させてしまうので、実践編では伝えなかったんだ。

本書256ページより引用

スクラムについてアレコレ詰めるのではなく、対象読者を絞った上で内容から外したあたりからも、この本がしっかり考えられた上で書かれたんだなということが実感できた。

個人的に良かったところ

活きたコラム

個人的に良かったところは 8 本のコラムだった。

  • 遠慮がちなプロダクトオーナー
  • インセプションデッキでチーム共通の言葉を作ろう
  • 少しずつ前に進もう
  • リリースレゴで「達成の積み重ね」を可視化しよう!!
  • 楽しくふりかえりをするためのテクニック
  • なぜこの機能を作るのか?
  • コミュニティイベントを利用してチームビルディング
  • タスクをみんなで寄ってたかって終わらせるスウォーミング

自分は本のコラムを結構飛ばしてしまうことが多いのだが、「リリースレゴで「達成の積み重ね」を可視化しよう!!」がとても面白く、そのまますべてのコラムに目を通した。 先人たちの知恵や工夫が載っており、片面 1 ページの内容ではあるのだが、スクラムを上手に回していく潤滑油のようなものを感じた。

参考文献が豊富

「理解を深めるために読んでほしい文献」として 14 冊の本が紹介されていた。 この本の先にある本として、テスト駆動開発など有名な本が並んでいて参考になった。 スクラムを実践の中で使える機会はまだなさそうだが、ふりかえりの項目が気になるので紹介されているものの中から手にとってより深く入ってみようと思う。

まとめ

スクラムについてはもちろん、スクラムを通してアジャイル開発に踏み出していく最初の一冊としておすすめできる本だと思った。

Azure: DP-201: Designing an Azure Data Solutionに合格した

2021/03/30 に Azure の資格試験、「DP-201: Designing an Azure Data Solution」に合格した。

この試験の受験者は、Azure データ サービスを使用するデータ ソリューションを設計するためのデータ要件を、ビジネス関係者と協力して特定および満たす Microsoft Azure データ エンジニアです。Azure データ エンジニアは、リレーショナル データ ストアとノンリレーショナル データ ストアを使用する Azure データ記憶域ソリューション、バッチおよびリアルタイムのデータ処理ソリューション、データ セキュリティとコンプライアンス ソリューションの設計など、データ関連のタスクを担当します。本試験の受験生は、次の Azure サービスを使用するデータ ソリューションを設計できなければなりません。Azure Cosmos DB、Azure Synapse Analytics、 Azure Data Lake Storage、Azure Data Factory、Azure Stream Analytics、Azure Databricks、および Azure Blob ストレージ。

https://docs.microsoft.com/ja-jp/learn/certifications/exams/dp-201 概要より引用

とあるように、Azure 上で提供されているリソースでデータ分析基盤の設計が中心に問題が出題される。

DP-200も同じ日の午前に受けて合格し、2枚抜きしてきた。 はっきり言って疲れるのでおすすめはしない。

yoshitaku-jp.hatenablog.com

問題の範囲

公式サイトによると、次のような範囲と割合で出題される。

問題の範囲 出題の割合
Azure データソリューションのデザイン 40-45%
データ処理ソリューションのデザイン 25-30%
データ セキュリティとコンプライアンスの設計 25-30%

英語にはなるが、より詳しい出題範囲が乗っている PDF が提供されているのでこちらも目を通すのが良さそう。

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE3VRMb

問題の形式

問題の形式に関してはDP-200とほぼ同じなので、引用する。

ベンダーの試験を受けたのが、数年前の Oracle Bronze と半年ほど前の Microsoft AZ-104 のみで問題の形式に慣れなかった。 AZ-104 が Microsoft 試験の初回だったけど記憶にないので、同じような感じだったか明言ができない。

問題数としては 40-50 問ほどになる。 すべての問題に共通しているのが選択問題ということがある。記述はなかった。 しかし問題の出され方に特徴があり、あとから見直せる問題と、見直せない問題がある。 見直せる問題は単発の問題になり、見直せない問題は要件定義があるケーススタディ問題だった。 ケーススタディ問題は 2 つあり、その中で 4,5 問ほど問われた。つまりケーススタディ全体の問題数としては 10 問ほどになる。 そこに単発の問題が 30-40 問で、「問題数としては 40-50 問ほどになる。」が構成される。

見直せない問題は、問題文も読めなくなるのでとても不安になるが自信を持って答えよう。 単発問題はあとから見直せるので、わからないところもササッと答えて、他の問題を見た結果思い出されたら戻ってこれるようにしておこう。

勉強教材

MS Learn

ゼロから始める人は MS Learn で概要を把握するのがいいと思う。 なかなか知られていないが Microsoft の勉強教材は結構良いのが揃っている。 下記ページの下部に、対象の勉強資材が乗っている。

docs.microsoft.com

mstep

mstep も Microsoft の勉強教材となる。こちらは少し試験に特化されている。

partner.microsoft.com

Udemy

より試験勉強の問題に特化したい場合は外部のサービスもある。

www.udemy.com

設計を問われるので、時間がある人は「図解即戦力 ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書」を読むのもいい。この本は、ビッグデータを扱うに当たり、どういう経緯でデータ分析処理基盤が生まれたのかとか、それを実現するためにどういうアーキテクチャを組めばいいかとかが載っている。ラムダアーキテクチャが何を言っているかとか、それを実現するためにどういうアプリケーションを使えばいいかとかの概要がつかめればいいと思う。

まとめ

とここまで紹介しておいて、この試験と DP-200 は 2021/06/30 に終了となる。 少し期間を開けて DP-203 を受けるのが良いかも知れない。

この試験の最新版 DP-203 は 2021 年 2 月 23 日に可能となります。2021 年 6 月 30 日に終了となるまでこの試験を受けることができます。注:試験は中部標準時の23時 59 分に終了致します。

yoshitaku-jp.hatenablog.com