よしたく blog

ほぼ週刊で記事を書いています

【Project Euler】Problem 5 Smallest multipleをPythonで解く

この問題をPythonで解いた。

#5 Smallest multiple - Project Euler

日本語の問題文はこちら

2520 は 1 から 10 の数字の全ての整数で割り切れる数字であり, そのような数字の中では最小の値である.

では, 1 から 20 までの整数全てで割り切れる数字の中で最小の正の数はいくらになるか.

Problem 5 - PukiWiki

from math import gcd
from functools import reduce

def lcm(a,b):
    return a*b//gcd(a,b)

print(reduce(lcm, range(1,21)))

【Project Euler】Problem 4 Largest palindrome productをPythonで解く

この問題をPythonで解いた。

#4 Largest palindrome product - Project Euler

日本語の問題文はこちら

左右どちらから読んでも同じ値になる数を回文数という. 2桁の数の積で表される回文数のうち, 最大のものは 9009 = 91 × 99 である.

では, 3桁の数の積で表される回文数の最大値を求めよ.

Problem 4 - PukiWiki

ans = []

for a in range(999, 99, -1):
    for b in range(999, 99, -1):
        result = str(a * b)
        if result == result[::-1]:
            ans.append(int(result))

print((max(ans)))

【Project Euler】Problem 3 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】Problem 2 Even Fibonacci numbersをPythonで解く

この問題をPythonで解いた。

#2 Even Fibonacci numbers - 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】Problem 1 Multiples of 3 or 5をPythonで解く

この問題をPythonで解いた。

#1 Multiples of 3 or 5 - 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技術で課題を解決していくということでとてもあっていると感じた。 逆に言うと、問題解決が伴わない単純に作業などは苦手であることを再認識できた。できればそういうことからは離れていこうと思った。 今後、進んでいくべき方向としては、知識を高めてスキルをどうやって高めていくか、それをどうやって問題解決能力に転換していくのかが、人生単位では必要になっていくんじゃないかと思った。

まとめ

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