よしたく blog

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

【Project Euler】Largest prime factorをPythonで解く

この問題をPythonで解いた。

#3 Largest prime factor - Project Euler

日本語の問題文はこちら

13195 の素因数は 5, 7, 13, 29 である.

600851475143 の素因数のうち最大のものを求めよ.

Problem 3 - PukiWiki

N = 600851475143
i = 2
while i * i <= N:
  while N % i == 0:
    N //=  i
  i += 1
print(N)

【Project Euler】Even Fibonacci numbersをPythonで解く

この問題をPythonで解いた。

Problem 2 - Project Euler

日本語の問題文はこちら

フィボナッチ数列の項は前の2つの項の和である. 最初の2項を 1, 2 とすれば, 最初の10項は以下の通りである.

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ... 数列の項の値が400万以下のとき, 値が偶数の項の総和を求めよ.

Problem 2 - PukiWiki

sum,a,b, MAX = 0, 1, 2, 4000000
while b < MAX:
  if b % 2 == 0:
    sum += b
  a, b = b, a+b
print(sum)

【Project Euler】Multiples of 3 or 5をPythonで解く

この問題をPythonで解いた。

Problem 1 - Project Euler

日本語の問題文はこちら

10未満の自然数のうち, 3 もしくは 5 の倍数になっているものは 3, 5, 6, 9 の4つがあり, これらの合計は 23 になる. 同じようにして, 1000 未満の 3 か 5 の倍数になっている数字の合計を求めよ.

Problem 1 - PukiWiki

three_or_five = [i for i in range(1,1000) if i % 3 == 0 or i % 5 == 0]
ans = sum(three_or_five)
print(ans)

Azure Data Factory でデータレイクから最新日付のファイルを取得する

f:id:yoshitaku_jp:20210827174443p:plain Azureを使ってデータ分析基盤を構築すると、Azure Data Lake Storage Gen2にデータを溜めていく事が多いです。 この日々溜まっていくデータから最新日付のファイルのみを取り出したいときに使えるテクニックです。

前提条件

前提条件として、XXX_yyyyMMdd.csvZZZ_yyyyMMddHHmmss.csvといった、同じファイル名の末尾に日時の情報がくっついているデータを取得するケースとします。

準備

パイプライン

まずはパイプラインに変数を用意します。今回は最新日付のファイルだったので、latest_filename としました。

次にアクティビティを用意します。 今回使うのはGetMetadata変数の設定です。2つとも「全般」の中に存在しています。

変数とアクティビティの設定が終わると、画像のようになります。

f:id:yoshitaku_jp:20210827170605p:plain

データセット

ファイルが置いてあるディレクトリへのデータセットを作成します。

ファイルパスの部分には「ディレクトリ」を設定し、「ファイル」の設定はおこないません。

f:id:yoshitaku_jp:20210827171509p:plain

GetMetadataアクティビティに、データセットを設定し、フィールドリストに子項目を設定します。

f:id:yoshitaku_jp:20210827171654p:plain

変数の設定

変数の設定アクティビティの変数タブへ移動し、下記の設定をします。

  • 名前
    • latest_filename
    • @last(activity('get_files').output['childItems'])['name']

ここでは、latest_filenameという変数に @last(activity('get_files').output['childItems'])['name']の値を入れています。 分解していくと、activity('get_files')は一つ前のアクティビティです。activity('get_files').output['childItems']は一つ前のアクティビティの出力結果の子要素、今回はactivity('get_files')のデータセットに、フォルダを指定していたので複数のファイル群になります。 その複数のファイル群の中からlast関数の実行結果である最後のファイルの['name']latest_filenameという変数に格納していることになります。

実行

今回はフォルダ配下に、2ファイル配置しました。test_20210609110816.csvが取得できれば良さそうです。デバッグ実行してみます。

f:id:yoshitaku_jp:20210827173418p:plain

get_filesアクティビティの出力結果は2ファイル取れています。

f:id:yoshitaku_jp:20210827173534p:plain

set_filenameアクティビティの出力結果は1ファイル、そして最新のファイルの結果が取れています。

f:id:yoshitaku_jp:20210827173554p:plain

まとめ

Azure Data Factory でデータレイクから最新日付のファイルを取得してみました。 デフォルトの機能をうまく使いこなすことで、少し込み入ったことも出来るようになりそうです。

Reposでブランチを削除する方法

f:id:yoshitaku_jp:20210827153230p:plain

どこから削除ができるのか探してしまったのでメモ。

まずはReposの「Files」に、現在いるものとする。

f:id:yoshitaku_jp:20210827151938p:plain

左のReposメニューから「Branches」を選択する。

f:id:yoshitaku_jp:20210827152059p:plain

削除したいブランチの右に配置されている点から「Delete branch」を選択する。

f:id:yoshitaku_jp:20210827152410p:plain

確認画面が表示されるので削除したければ「Delete」をクリックする。

f:id:yoshitaku_jp:20210827152549p:plain

ブランチが削除される。

f:id:yoshitaku_jp:20210827152715p:plain

Azure Data FactoryのGit運用で困ったら取り入れてみること

Azure Data Factoryでは、パイプライン開発をバージョン管理するためにGit連携ができます。 GUIでの開発なのにバージョン管理できるのは、Data Factoryの実態がJSONファイルになっているからです。

Azure Data FactoryとAzure DevOpsなどを連携すると、デフォルトではmasterブランチとadf_publishブランチの2つが用意されます。 masterブランチは通常の開発として利用されるブランチになっていて、adf_publishブランチはAzure Data Factoryにおける本番リリース用となっています。

図解すると下記のようになります。 1人の開発者が1つのシステム連携を作成しているときは、シンプルで使いやすいものになります。

f:id:yoshitaku_jp:20210822180235p:plain

次に2人の開発者が2つのシステム連携を作成しているときは、どうでしょうか。 別々のシステム連携を作成しているとき、開発中は特に問題にはなりません。

f:id:yoshitaku_jp:20210822180650p:plain

しかし、adf_publishブランチへ本番リリースをしたいタイミングでは事情が変わってきます。 本番リリースをする際にはmasterブランチの作成物すべてが正常に動くか検証し、adf_publishブランチへマージします。 つまり、下記画像のように1人の開発者が作成物を本番リリースしたくても、もうひとりが開発中で中途半端な状態だとadf_publishブランチへマージすることができません。 最後まで完成させてもらうか、エラーが出ない切りのいい部分まで進めて貰う必要があります。 エラーが出ない切りのいい部分まで進めてもらったとしても、中途半端な成果物が本番リリースへと運ばれてしまいます。

f:id:yoshitaku_jp:20210822182415p:plain

この状態を回避するために、masterブランチから各システムごとのブランチを作成します。 この状態で開発をすすめることで、Bシステムでの開発が終わっていなくても、Aブランチの作業だけmasterに反映し、開発済みのキレイな作成物だけをadf_publishブランチへ持っていくことができます。

f:id:yoshitaku_jp:20210822183229p:plain

まとめ

Azure Data Factoryを使い始めた人は、Gitの部分よりもAzure Data Factoryになれるために、ひとまずGitを横へ置いてどんどん開発していくと思います。 自分も開発に慣れてきて、さらには新しい人も入ってきて開発のスピードを上げていこうとしたタイミングで起こりうる問題として、解決策を取り上げてみました。 まずは開発のスピードを落とさず、問題が起きないようにするための第一歩として、参考になれば幸いです。 ここからさらにGit-flowといったものへ目を移していけばいいと思っています。

リレーショナルデータベースにおけるカーディナリティについて

カーディナリティは、データベースのカラムに入っているデータの種類がどれぐらい存在しているかを表す。 もともとの英単語の訳としては濃度という訳が当てはまる。

例えば、genderカラムが存在していたとする。単純な話としたいので、このカラムに入ってくる値は男か女とする。

id gender
1
2

10人分のデータがあったとしても入っている種類は男か女で種類が2つしかない。

id gender
1
2
3
4
5
6
7
8
9
10

こういった場合はデータの種類が少ない、つまりカーディナリティが低いと言います。

もう一つ、カーディナリティが低い例として血液型がある。 bloodカラムがあったとして、ここに入ってくるデータは4種類。 つまり - A - B - O - AB

となる。

id blood
1 O
2 A
3 AB
4 AB
5 B
6 A
7 A
8 O
9 AB
10 B

逆にカーディナリティが高い状態はgenderカラムとbloodカラムの説明でつけたidカラムを言う。 idカラムは1から10の数値を示している。 このように1から順番に上がっていくサロゲートキーのような数値は、1から10まで種類があるのでカーディナリティが高い状態と言える。

ストレングスファインダーをやってみた

「さあ、才能(じぶん)に目覚めよう 新版 ストレングス・ファインダー2.0」を買って、実践してみた。

この本は自分の才能に気がつき、今後の人生をより良い方向へ進める指針となるものが分かる本になっている。 目次は次のようになっている。

  • 第I部 まず、あなたの強みを見つけよう
  • 第II部 あなたの強みを活用しよう――34の資質と行動アイデア

1部では、なぜ才能に気づかなければいけないかが端的に書いてある。この部分は30ページほどだが、すぐにストレングスファインダーを受けたくなるように駆り立てる感じがあった。 2部では、ストレングスファインダーを実施し自分の資質を把握したあとに読むものとなっている。全て読んでも良いものなのだろうが、自分の資質とは関係がないのでひとまずは読まなくても良さそう。 「この資質を持っている人との付き合い方」といったような項目もあるので、友人と結果をシェアした際に読むと盛り上がりそうだ。

実際のストレングスファインダーは巻末にあるアクセスコードを使ってWebサイトから実施する。実施の時間は40分目安と書いてあり、テンポよく実施したつもりだったが自分は35分ほどかかった。深く考えないように1問20秒の制限もあるが、深く考えすぎる進めていくほうが良さそう。

結果

自分の5つの項目は以下となった。

  1. 原点思考
  2. 回復思考
  3. 社交性
  4. 慎重さ
  5. 学習欲

この結果にはあまり驚いておらず、普段自分自身に対して思っていることと同じで安堵する気持ちがあった。

原点思考は過去をふりかえる資質になる。過去を振り返ることで計画段階の原型だったり、その中から意図を知ることができる。 今の段階の現状を知らされたときに、まず最初に聞くことは「なぜ」「どうして」といった言葉が多いことに改めて気がついた。 何事にも軌跡があり、過去と現在があるからこそ、未来を描けていけるようなイメージを自分は持っている。 ソフトウェア開発においても、「昔はこうだったが、今はこうなっている、理由はこういうことだからである」と言われたほうがすんなり入っていくし、頭にも残っていることが多い。 こういった特性を改めて認識できると、例えば本を読んで学習する際にも歴史的な流れが記されているものを手にとったほうが良さそうといったことが自分の中でわかってくる。

回復思考は、要は問題解決することが好きという資質になる。 現在もエンジニアとして仕事をしているが、IT技術で課題を解決していくということでとてもあっていると感じた。 逆に言うと、問題解決が伴わない単純に作業などは苦手であることを再認識できた。できればそういうことからは離れていこうと思った。 今後、進んでいくべき方向としては、知識を高めてスキルをどうやって高めていくか、それをどうやって問題解決能力に転換していくのかが、人生単位では必要になっていくんじゃないかと思った。

まとめ

ストレングスファインダーの紹介と、想像がつかない「原点思考」と「回復思考」についてどんな事が書かれており、それを受けて自分がどう感じたかを書いてみた。 自己分析だったり、今後の人生の指針に悩んでいる人がいたら参考になると思うのでぜひやってほしいと思った。

Azure SQL Databaseの監査ログを取得する

Azure SQL Databaseでは監査ログをかんたんに取得することができる。文字通り監査のタイミングで必要になるので、基本的には取得しておいたほうがいいものになる。Azure SQL Databaseではデータベースのイベントを追跡し、Blobストレージに監査ログを書き込む。

SQL Databaseにアクセスし、「セキュリティ」の「監査」へアクセスする。 「Azure SQL 監査を有効にする」をオンにする。

f:id:yoshitaku_jp:20210730220615p:plain

その後、出力先の「ストレージ」にチェックを入れ、対象のBlobストレージがある「サブスクリプション」と「Blobストレージ」を選択する。

f:id:yoshitaku_jp:20210730220420p:plain

設定が完了するとBlobストレージに専用のコンテナが作成されている。

f:id:yoshitaku_jp:20210730221344p:plain

Apache AirflowのDAGファイルの最小設定

Apache Airflowで自作ファイルを作成しようとしたが、設定できる項目多く迷うことが多かった。そこでチュートリアルで用意されているものから最低限必要なものを抜き出してみた。 それが以下になる。

from datetime import timedelta

from airflow import DAG
from airflow.operators.bash import BashOperator
from airflow.utils.dates import days_ago

with DAG(
    "hello_airflow",
    schedule_interval=timedelta(days=1),
    start_date=days_ago(2),
) as dag:

    t1 = BashOperator(
        task_id="hello_world",
        bash_command="date",
    )

t1

DAGの中の設定値

with DAGの中には次のものがないと、正しく設定ファイルを読み取ってくれなかったり、エラーなる。エラーはAirflowの管理画面に表示されるので認識しやすい。しかし、値を正しく読み取ってくれないパターンはわかりやすく表示してくれるわけではないので注意が必要ということがわかった。

  • DAGの名称
  • 実行する間隔
  • 最初の実行日

これらはDAG Detailsの中に表示される。

f:id:yoshitaku_jp:20210725225025p:plain

DAGの後

as dagのあとにコロンが付いていて、そのまま実際におこなう処理を記述する。直列で処理をつなげることもできるし、並列で動かすこともできる。今回の例ではわかりやすくするために1つとしている。また、処理の中に記述するものも最低限のものに絞った。

まとめ

まずは感嘆なDAGファイルを作成した。このあと、後続に処理をつなげたり、並列実行してみたり、また様々なデータソースへもつないでいってみようと思う。