サラリーマンエンジニアブログ

大企業で働くなんちゃってITエンジニアのブログです。

【Python初心者必見】一歩上のパイソニスタになるために

pythonista
こんにちは、アホだけどITエンジニア コーシです。

「【Python初心者必見】一歩上のパイソニスタになるために」という題目で、Pythonのコードの書き方についてお教えできたらと思います。


目次

 では早速参りましょう

タイプヒントをつける

あまりプログラムを経験したことのない方は、関数を定義する時に下記のように書くでしょう。

>>> def test(a, b, c, d):
...     return a
...
>>> test('hellowworld', 1, [1,2,3], {'a': 'b'})
'hellowworld'

しかし、上記では関数定義時に a, b, c, dのデータの方がぱっと見わからないし、returnされるデータの型もかわかりませんね。
コードが読みづらく、複数人で開発していると非常に困ります。

それが、タイプヒントを使えばこのように書くことができます。

>>> def test(a: str, b: int, c: list, d: dict) -> str:
...     return a
...
>>> test('hellowworld', 1, [1,2,3], {'a': 'b'})
'hellowworld'

上記のように書くと、関数定義時にデータの型がわかるのでどんなデータが引数として入ってくるのか、そしてどんなデータ型がreturnされるのか予想ができ、コード理解の一助になります。

また、下記のように、 引数=デフォルト値 とすれば関数定義時に引数のデフォルト値を定義することもできます。

>>> # dのデフォルト値を{}と定義
... def test(a: str, b: int, c: list, d={}) -> (str, dict):
...     return a, d
...
>>> # dの引数を省略したら, dはデフォルト値のd={}
... test(a='hellowworld', b=1, c=[1,2,3])
('hellowworld', {})
>>> # cのデフォルト値を[]と定義
... def test(a: str, b: int, c=[], d={}) -> (str, list):
...     return a, c
...
>>> # cの引数を省略したら, cはデフォルト値のc=[]
... test(a='hellowworld', b=1, d={'a': 'b'})
('hellowworld', [])

ただ、下記のように関数定義時に「デフォルト値を宣言した変数」の後に「宣言していない変数」が入ってしまうと SyntaxError: non-default argument follows default argument というエラーが生じるので注意しましょう。

>>> # cはデフォルト値を[]と定義, dは定義していない
... def test(a: str, b: int, c=[], d: dict) -> (str, list):
...     return a, c
...
  File "<stdin>", line 2
SyntaxError: non-default argument follows default argument

参考

〇〇 in dict.keys() の書き方

みなさん一度は、

if 〇〇 in dict.keys():

みたいな書き方したことがあると思うのですが、key だけを参照するのであれば

if 〇〇 in dict:

だけでいいんです。

>>> test={
...     'test1': '1',
...     'test2': '2',
...     'test3': '3',
...     'test4': '4',
...     'test5': '5'
... }
>>>
>>> # 'test3' in test.keys() と 'test3' in test は同義
... 'test3' in test.keys()
True
>>> 'test3' in test
True
>>>
>>> # もちろん下記はエラー
... 'test3' in test.items()
False
>>> 'test3' in test.values()
False

PEP8に従おう

これは、いうまでもないですがPythonにはPEP8という規約があるので、それにしたがって書けば、標準的なPythonコードが書けます。
今はテキストエディタでもPEP8に従っていなければWarningもしくはErrorを出してくれるものもあります。
オススメするエディタはPycharmです。
vim等のCUIで開発している人は、flake8というパッケージでPEP8チェックできます。

何回も使う文は関数化しよう

何度も同じ文を書くのであれば、それは関数化しましょう。
何回も同じ文3 ,4行がでてくるのは見ていてとても鬱陶しいです。
関数化して一行にまとめましょう。

ハードコーディングはやめましょう

例えば、URL・パスワード・メールアドレス、ファイルパス、等ソースコードに直接埋め込むべきではない定数は、テンプレートやコンフファイル、環境変数などの外部ソースからから読み込むようにしましょう。
セキュリティなどのトラブルの原因となります。

「今」必要としないコードは書くな

もしかしたらいずれは使うかもしれないだろうと思って、必要以上の機能は作るなってことですね。
YAGNIKISSの原則です。プログラムはシンプルイズベストです。

参考

まとめ

上記を守っていただけたら、今よりも少しレベルの高いパイソニスタになれるのではないでしょうか。
プログラムを書くときは常にシンプルに書くことを1番に求めて書きましょう。
シンプルを求めていけば自然とわかりやすい文が書けます。
プログラムは同じ結果を得るために様々な書き方ができますが、正解はたった一つです。

【検証】チーズおやつは同時に何個食べられるのか

kensyou

こんにちは仔牛ちゃんねるのコーシです。

今回は「チーズおやつは同時に何個食べられるのかを検証」をしていきたいと思います。

こちらが10円で売られているチーズおやつです。 

チーズおやつ

チーズおやつ

目次

なぜ検証するのか

みなさんこういった経験を持ったことはありませんか?

一個じゃ満足せず

さらにもう一個...

さらにもう一個...

さらにもう一個...

永久不滅

 

みたいな経験をしたことありませんか?

私もチーズおやつ食っているうちに、何年か過ぎ、気がつけばもう大人です。

 

Q: なぜ一つでは満足しないか?

A: 量が少ないから。

では、一気に大量のチーズおやつを食べれば、満足感を得られるのではないかということでふと思いました。

単純に大量のチーズおやつを食べてもつまらないので、何個食べられるか?を検証していきたいと思います。

検証人ステータス

人のスペックは個人差があるので私のステータスを書きたいと思います。

ステータス

ただちょっと今の体温が38.3度と頑張って菌を殺してる最中です。ちょっと鼻が大きめですが、まぁ比較的一般的だと思います。

 

早速やってみましょう。

チーズおやつ同時に食べてみた

1個目

ひとつめは余裕ですね。

表情も余裕そうです。

チーズおやつ1本目

3個目

3個目も問題ないでしょう

チーズおやつ3本目

10個目

まだまだ余裕だったので、4~9つ目飛ばして10本にしましたが、

ちょっと、顔が気持ち悪くなってきましたね。

まぁでも全然余裕の伺える表情です。

チーズおやつ10本目

15個目

この口からチーズおやつ出すスタイルは、

15個目がマックスです。
これから口の大きさを聞かれたらチーズおやつ15個を縦に入れた時の大きさって答えるようにします。

15本目

20個目

あら、ハムスターちゃんみたいで可愛らしい。

って感じですね。

20本目

30個目

特に20本目と絵は変わりません。

お見苦しい映像失礼します。

30本目

36個目

もう入りません。

最後ギリギリまで口に詰めて詰めてたら、

チーズおやつが二本はみ出して前歯のようになり、

さらにハムスターのようになってしまいました。

36本目

検証結果

チーズおやつをマックスまで口の中に詰め込むと最終的にハムスターのようになれる。(インスタ映え)

チーズおやつはだいたい36個くらい同時に食べられるが、

チーズのにおいや喉にちょくちょく当たるのが原因で途中えずく。

食い終わってもちょっと気持ち悪さが残る。

まとめ

チーズおやつは一個ずつ食べましょう。

ごちそうさまでした。

ごちそう

 

平日、仕事と家の往復になっていませんか?

heijitsu

こんにちは、今日もエンジニアってますフナミズです。

私なりの「退勤後の過ごし方」について書こうと思います。

 

早速ですがここでひとつ質問です。

みなさん、平日は仕事と家の往復になっていませんか?

 

仕事と家の往復の毎日、そんな代わり映えのない日常って嫌気がさしませんか?

そんなあなたに、少しでもお役に立てたらと思い、私の退勤後のアクティビティを紹介できたらと思いこの記事を書きました。

 

私も以前まで、ずっと仕事と家の往復で、家に帰ってもこれといって何をするわけでもなくTVをみてぐうたらするという日常でした。

このままじゃもったいないと思い、このようなひとつのルールを作りました。

  • 仕事後21:30までには家に帰らない。

結婚している方だったらナンセンスだと思いますが w

私は26歳独身なので許されます。(ガーリーなフレンドゆる募)

 

じゃあ、21:30まで家に帰らず何をしているのか?

その時の気分によって、いろんなことをしています。

私が主にやっていることをご紹介したいと思います。

 

目次

日常系

温泉・銭湯

f:id:yarite_parker:20190208185127j:plain

Photo by Shopify Partners from Burst

「日常に心と身体のリラックスを」

温泉・銭湯は本当におすすめです。岩盤浴なんかにも行ってました。

私は特にサウナが好きで、サウナに入ってぼーっとしているときは本当に「無」になれて、頭を休めることができます。

使う必要のないときは頭を休める、このことが仕事のいいパフォーマンスへ繋がると私は思います。

 

余談ですが、日本人は長い時間働いて、本当に効率の悪い頭の使い方してますよね。

細く長く頭を使っているイメージ。個人差はありますが、集中できる時間って決まってますからね。生産性無さすぎる。

 

あえて違う人と飲みに行く

f:id:yarite_parker:20190208193442j:plain

Photo by Sarah Pflug from Burst

毎回同じ人だと、楽しいかもしれませんが。

情報が偏ってしまいます。

たまには違う人と飲みに行くとまた違ったInputができて新しいアイディアに繋がることがよくあります。

同じ人と飲むよりも刺激になりますしね。

(私はよく、中学・高校の時の友達と飲みに行きます。)

 

カフェでブログやSNSをやる

f:id:yarite_parker:20190208195410j:plain

Photo by Shopify Partners from Burst

まず、基本的に「カフェ」の空間が好きです。

「ブログ」や「SNS」は趣味です。

好きな空間で趣味をできているということは素晴らしい。

 

カフェで本を読む

f:id:yarite_parker:20190208205558j:plain

Photo by Sarah Pflug from Burst

私は普段あまり本を読まないので、あえて時間をとって「本を読む」ってのをしています。

本は自己投影でき、没頭できます。

仕事とは別の思考回路で、本を読むと色々と考えさせられます。

 

美味しそうな店を探していく

f:id:yarite_parker:20190208200649j:plain

Photo by Matthew Henry from Burst

「飯には妥協しない」っていうのが私のモットーです。

美味しいご飯を食べるために働いてるんです。w

美味しい飯を食べることは心もハッピーになりますね。

「病は気から」、心の健康は身体の健康に繋がります。

平日に美味しい飯屋を巡るってとても幸せです。

 

マッサージ・スパ

f:id:yarite_parker:20190208201538j:plain

Photo by Nicole De Khors from Burst

これを常日頃やるのは難しいですが、自分の中の「プチ贅沢」としてたまにはいいのではないでしょうか?

私はたまに疲れが取れない時とかは「てもみん」に行ってちょっとしたマッサージを受けたりします。

 

勉強系

英会話教室

f:id:yarite_parker:20190208194346j:plain

Photo by Samantha Hurley from Burst

エンジニアにとって英会話は必須ですね。

できる人がすごいというよりも、できて当たり前の世界になってきています。

英語の文献読めるだけでエンジニアとしての幅が広がります。「最新」は常に海外からなので。。。

私の場合は、「勉強」って感じではなく英会話が楽しいからいってるし、尚且つ英語が学べているので、一石二鳥ですね。

セミナーに参加

f:id:yarite_parker:20190208194841j:plain

Photo by Sarah Pflug from Burst

私の場合、趣味がエンジニアリングなので平日の仕事後もセミナー行ったりしてますね。

セミナー後の懇親会がとても有意義で、セミナー参加者と話すことで他社の状況とかも取り入れられるので非常に勉強になります。

 

 

運動系 

平日に人を集めるのは少々難しいので「一人でできる」っていうのがポイントですね。

バッティングセンター

f:id:yarite_parker:20190208190554j:plain

Photo by Jp Valery from Burst

昔から野球をやっていたということもあり、バッティングセンターによく行きます。

めちゃくちゃストレス発散します!

普段運動しないので、清々しい。

しかもこのくらいの運動なら疲れも残らないので、平日には丁度いいです。 

 

ボルダリング

f:id:yarite_parker:20190208200303j:plain

Photo by Brodie Vissers from Burst

誰でもできる」という点ではおすすめです。

ただ、意外と疲れます。

ちょっと変わったことをやってみるのは刺激になります。

一時はとてもハマって毎日行ってましたが、最近はあまり行けていない。。。

 

 

遊び

ダーツ・ビリアード・ボーリング

f:id:yarite_parker:20190208205353j:plain

Photo by Shopify Partners from Burst

ザ・遊びって感じですね。

ザ・遊びを日常でやるっていう開放感に結構ハマってしまったこともある。

一時はダーツ・ビリアードを平日土日ほぼ毎日やってたときもありました。

ハマりにはご注意をです。w

 

映画

f:id:yarite_parker:20190208211822j:plain

Photo by Matthew Henry from Burst

映画は昔から好きで、21:30まで帰ってはいけないルールで、さらにいく機会が増えましたね。平日退勤後2時間くらい映画見て帰るってちょうどいいんですよね。

特に私はauユーザでauスマートパスに入っているので、月曜日1,100円でみることができるんですよね。なので月曜日は隔週くらいで映画見てます。w

 
ドライブ

f:id:yarite_parker:20190208210329j:plain

Photo by Dan Gold from Burst

なんのあてもなく、仕事後ただただ東京をドライブしていたことがありました w

これは本当に日常で非日常を味わえます!w

半年に一回はやってもいい!本当に楽しい!

 

 

私がよくやっているランキング

私がこの中で退勤後よくやることは、上から

  1. 銭湯
  2. 美味しい店を探していく
  3. カフェでブログ・SNS
  4. カフェで本を読む
  5. セミナー参加
  6. 英会話に行く

です。

やっぱりこう振り返ってみると、ずっと続いているのは有名どころですね。w

上記で紹介した以外にも色々、トライアンドエラーでやってます。

 

 

よかったこと

インプットが増える

家に帰ってTVを見るの一辺倒よりも、何か行動するとインプットが増え、その分アイディアになます。

頭が切り替えられる

休日で頭を切り替える人が多いと思いますが、毎日頭が切り替えられ仕事時のパフォーマンスもよくなる。

充実する

なんでもやってみることは刺激のある毎日をもたらすでしょう。

健康的になる

運動しにいかないにせよ、目的地まで歩くので、家と会社の往復よりは健康的です。(飲みに行く以外)

 

 

まとめ

ちょっと一般的な感じになってしまいましたが、

最初は一般的なものから初めて、慣れてきたら変わったものにも挑戦してみて、自分なりの「退勤後」を作っていけたらいいのではないでしょうか!

 

ただちょっとお金はかかります、が人生一度きり、毎日を充実させましょう!

 

 

画像のライセンスは全てCCO、「Burst」を利用

Free Stock Photos: High-Res Images for Websites & Commercial Use

 

 

口下手の転職面接術

「口下手の転職面接術」

私はものすごく口下手です、その私が転職の面接時に使用した「術」をお伝えしたいと思います。

目次

About me

ちょっと軽く自己紹介をさせてください。

年齢:26 歳(2019年1月時点)

職業:ITエンジニア

役割:データエンジニア・データサイエンティスト

現職:SONY株式会社

 詳しくはこちらに書いてあります。

www.yariteparker-blog.com

自身の転職経験

私の転職経験は

株式会社LIXIL(2015/4/1 ~ 2018/7/31)

⬇︎

SONY株式会社(2018/8/1 ~ )

という感じで、

新卒で株式会社LIXILに入社し、

LIXILで約3年間働き、

現在所属しているSONY株式会社に転職しました。

転職活動

転職活動は 2018/1/1 ~ 2018/3/31の3ヶ月くらいしました。

大体、10社くらい受けて4社くらい受かりました。

口下手の面接術

ある程度の準備はしたし、技術力に自信はあったものの、口下手の私は面接官に伝えたいことをうまく伝えられず、最初に面接をしていただいた3社は面接で玉砕し、このままじゃいけないと思い、自分なりに工夫したことを記載します。

工夫したこと

面接でパワポを使用

やっている分野が少々難しいということもあり言葉だけで面接官に、正確に・わかりやすく・詳細に説明するのは無理だ。という判断に至りました。

従って、「自分の今までやってきたこと・仕事において工夫した点・自分のできること」等を7枚くらいのスライドにまとめて、それを用いて面接に臨みました。

そして面接時に、

「詳細に今までやってきたことを説明したいので、PCを使用して説明していいですか?」と一言断りを入れて、PCを開いて説明をしました。

転職の面接の目的は、「その人の技術力」・「今まで何をやってきたか」・「何を工夫して仕事してきたか」を知ることなので、それを伝える手段ってのはあまり問わないのではないかと思います。

詳しく説明できれば面接官も自分もWin-Winですしね。

 

「PCなんかも使わせてもらえない寛容じゃない企業なんて行かないわ」と思いながら、面接にPC持ち込んでましたが、実際にPCを使って説明させてもらえなかった企業は0でした。

 

スライドを用いて説明してから、落ちた企業はないですね。

自分でも面接終了時に言い残したことやうまく言えなかった点などがほぼ無くなったので、すごい手応え有りましたし。

面接官の話を聴く

なぜ、企業は中途採用の募集をするか?

それは、「企業がやりたいこと・やっていること・やろうとしていること」に人が足りないから、もしくはやりたいことを実現できる人材がいないからなんですよね。

じゃあ、その企業がやりたいこと、やっていること、やろうとしていることを聞き出して、過去の経験から自分はそれにどう貢献できるかを示すってのが1番のアピールだと思います。

なので、自分ばっかりが喋るのではなく、面接官の話も聞きながら、うまく面接官が求めている人材像にアプローチしていくってのが大事だと思います。

なかなか面接官の求める人材像が見えてこなかった時、私は直接聞きました、

「なぜ今中途採用募集しているのですか?」と。

そしたら、何々がしたいからこうゆう人材を探しているんだよねと返ってくることが多く、私だったらそれに対して何々できます!というようなことを答えていました。

面接官から質問されたことをまとめる

面接時に面接官から質問されます。

その場で上手い答えが出せたとしても出せなかったとしても、

面接が終わった後に、質問されたことを洗い出して、その質問されたことに対していろいろ調べて自分なりの答えをまとめるということをしていました。

転職時の面接は結構似通った質問をされる場合が多く、質問に対しての答えをあらかじめまとめておくことで、口下手な私でもすらすら答えることができました。

ちょっとめんどくさいですが、これには非常に助けられました。
(質問に対しての答えをまとめておいたEvernoteを見ながら答えていたこともあった...w)

まとめ

口下手な人はまずはとにかく「準備」を大事にするべき。
私は下記の三つの手法で口下手ですがうまく面接を乗り越えることができました。

  1. 面接でパワポを使用

  2. 面接官の話を聴く

  3. 面接官から質問されたことをまとめる

この方法を使うか使わないかはあなた次第ですが、転職時の面接はシビアなので自分なりに工夫して臨みましょう。

まだ東京で消耗しています。

mada

「まだ東京で消耗しています」けど何か?

 

某有名ブロガーが以前ブログのタイトルにしてましたね。

「まだ東京で消耗しているの?」って。

 ついさっきも、こんなこと書いてましたね。

考え方は人それぞれですから、いいと思いますけど。

都会で働くこと、田舎で働くことにはそれぞれメリット・デメリットがあって、そのメリットデメリットを個々人の価値観に照らし合わせて、都会で働くか田舎で働くかを選択すればいいだけだと思います。

 

田舎で働かない人は愚民だ、みたいなことひたすら馬鹿の一つ覚えみたいに言っているのはちょっと私には理解できないですね。

まぁそうゆうブランディングでやっているのでもう逃れられないんでしょうね。

ちょっとあの人は宗教臭しますよね。w

 

私自身品川で働いていて、ある程度の給料もらって好きなように生きているので、特に不満はなく楽しい都会生活を送れているので、このまま都会で働いて行こうと思っています。

また、イケハヤさんは景気が悪くなった時のことを危惧していますが、それは田舎の会社員だって一緒ですよね。

 

家賃に関しては都会の方が家賃高い分、平均給料も都会の方が高いから家賃/給料で言ったらトントンなんじゃないですか?田舎は車も持たないといけないし。

無益な飲み会に関しては「無益」かどうかは個人が決めるものなので、第三者が無益な飲み会というのは、はっきり言ってキモい。

 

イケハヤさんは「サラリーマン」も完全否定していましたが、「安定」という面で言ったら、ブロガーとかYoutuberよりもサラリーマンの方がしていると思うし、ブロガーやYoutuberなどの個人事業にやりがいを感じない人も当然いるだろうから、そこも個人の価値観ですよね。

 

ただサラリーマンとして、言いたいことはみんな個人事業をやり始めたら日本社会は崩れるし、個人事業でやれることの限界もあるだろうし、今の生活があるのは企業があるからなわけで、日本人の生活を支えているサラリーマンには敬意を払うべき。

 

Work with Respect」ってのは私の座右の銘で、イケハヤさんは敬意を持っていない言葉が目立つので、正直彼のそうゆうところは私はあまり好きじゃないですね。

 

また「サラリーマン=やりたくない仕事」をしていると思われがちですが、そんなことありません。

私自身やりたくないことをやるのは人生無駄にしていると感じるたちなので、サラリーマンですがやりたい仕事をやらせてもらってますし、ちゃんと自分でも仕事は選んでやっています。

やりたくない仕事を担当させられたら、転職してやりたい仕事をできる企業にいけばいいっていう考えです。

そのためにも技術力の向上は常に考えています。

サラリーマンにしろ、ブログやYoutubeなどの個人事業にしろやりたい仕事をするためにはそれなりの努力が必要であることは間違いありません。

 

都会に住んで働くメリット

  • 技術セミナー・勉強会が多く開催される
  • 「新しいもの」はまず東京に入ってくる
  • 遊び場所が多い
  • お店が多い
  • イベントが多い
  • 平均給料が高い
  • 出会いが多い
  • 働き方改革が進んでいてある程度自由な働き方ができる
  • 車を所有しなくてもいい
  • やりたいことがすぐできる環境

都会に住んで働くデメリット

  • 家賃が高い
  • 満員電車
  • 自然に触れ合う機会が少ない
  • 人が多い (メリットにもなりうる)

田舎に住んで働くメリット

  • 食べ物が新鮮
  • 空気が綺麗
  • 星が綺麗
  • 家賃が安い
  • 子供をノビノビ育てられる
  • 土地代が安い
  • 自然に触れられて生きていける
  • 人が少ない (デメリットにもなりうる)

田舎に住んで働くデメリット

  • 物流スピードが遅い
  • 車の維持費が高い
  • お店が少ない
  • 遊び場が少ない
  • 平均給料が安い
  • 虫が多い
  • 悪しき昔の文化が残っている企業が多い

私の中で「機会損失」ってのが一番嫌いなので、そう言った意味では田舎より都会の方が、行きたいセミナーにいけなかったとかやりたいことができる環境がなかったなどの「機会損失」がないので、そこに都会で生活する1番のメリットを感じています

言い換えれば都会の方が「選択肢が多い」ってことですね。

まとめ

田舎と都会どっちがいいなんて、それは個々人の価値観次第だと思います

イケハヤさんは自身のブランド戦略的にあんなに強い言葉を使って「都会」を批判していますが、要は都会に住んでいても自分自身がなんの不満もなければ耳を傾けなければいいってことです。(都会民としてはちょっと腹がたちますが。。。)

上記のように私の中でメリット・デメリットを並べて考えた結果、田舎に住むより都会に住む方が全然メリットがあるので、都会に住むまでです。

 

一応私は田舎育ちなので、田舎と都会両方経験しています。

一番いいいのは実際に田舎と都会の両方を経験してみて、どっちが自分の性に合っているかを選べばいいと思います。(なかなか難しいですけど)

キャッシュレスにした結果人生変わった。

cache

「キャッシュレスにした結果人生変わった。」

重い財布が嫌い。

小銭でかさばる財布が邪魔臭い。

レジでバタバタするのがダサい。

という理由で半年間くらい、(ほぼ)現金を使わない生活をしました。

これが素晴らしかった。

目次

 

用意するもの

  • Edy付き楽天カード - オートチャージ付き (master)
    • Edyの残金3000円以下になったら25,000円チャージするように設定
  • 定期Suica - オートチャージ付き (visa)
    • 1,000円以下になったら、5,000円チャージするように設定
  • いざという時のための現金20,000円

 

定期Suicaのオートチャージ方法

www.saisoncard.co.jp

ルール

ルールは基本は下記の4つだけです。

  1. 10,000円未満はEdy
  2. 10,000円以上は楽天カード
  3. 移動はオートチャージ付きの定期Suica
  4. 「カードが使えない店」でのみ現金使用 (なるべく使わない)

メリット

  • 財布の軽量化
  • 決済の高速化
  • 楽天カード支払いによるポイントの付与 (Edy決済でもポイントが付与される)
  • 楽天カードアプリによる自動家計簿
  • クレジットカード使用は信用に繋がる

感想

非常に快適な決済生活でした。

決済でゴタゴタしないってのは心地いいものです。

良かったのが、楽天カードアプリによる自動家計簿です。

何に使ったか・どのくらい使っているかが見える化されているので、意識改革にもなり結果「節約」できました。

また、案外すぐにポイントがたまりこの半年で楽天ポイントが20,000ポイントくらい溜まりました。もちろんランクはダイヤモンドです。

クレジットカードを使ってランクを上げればランク特典をもらえるっていうのもメリットですね。

 

用意するものに「いざという時の20,000円」と書いてありましたが、本当に飲み会の割り勘などを合わせて、現金は月で20,000円くらいしか使っていないと思います。

現金が手元にないのは少々不安なので20,000円くらいは持っておいたほうがいいと思います。

ただ現金を使った日に余った小銭は毎回貯金箱に入れて、なるべく小銭を持ち歩かないようにしてました。

課題

  • 飲み会時の割り勘
  • カードが使用できない店

特に割り勘は課題ですね。

最近はカードが使用できない店も少なくなってきたので、「カードが使用できない店」っていうのはあまり気になりませんでした。半年間でカードが使用できなくて現金で支払ってしまったってことは、10回もなかったと思います。(私がファストフードが好きなのもありますが。。。)

注意

楽天カードアプリでは簡単に「リボ払い」に変更できるので、そこは注意しましょう。

「リボ払い地獄」にハマってしまう人をよく耳にします。

せっかく楽天カードアプリで使用状況を管理できるので、「あー今月予算オーバーで使いすぎたー」ってのは無くしていきましょう。

まとめ

皆さんもキャッシュレスでスマートに生きてみましょう。

決済でゴタゴタするのは他人の迷惑にもなるのでやめましょう。

何よりモテないです。

現金払いでのメリットってあるのかな?私が考える限りではないです。

クレジットは「信用」に繋がるので、クレジット決済は銀行へのいいアピールでもあります。

PythonのPandasにおけるdatetime型(datetime64[ns])の年月日制限

seigen
PythonのPandasは機械学習などのデータ分析をする場合の必須ライブラリですね。
そのPandasに関する「不満」です。

PandasのDateTime型(datetime64[ns])は1677年 ~ 2262年までしか対応していない

PandasのDateTime型で使用できる日付は1677年 ~ 2262年という制限があります。

ソースコードを見てみても書かれていますね。
f:id:yarite_parker:20190131215824p:plain
github.com

実際に動かしてみ他結果がこちらです。

>>> import pandas as pd
>>> from datetime import datetime as dt
>>>
>>> d = {'dt': ['2019-1-31 01:01:01', '1678-01-01 01:01:01','1677-01-01 01:01:01', '2262-01-01 01:01:01', '2263-01-01 01:01:01']}
>>> df = pd.DataFrame(data=d)
>>> pd.to_datetime(df['dt'], format='%Y-%m-%d %H:%M:%S', errors='coerce')
0   2019-01-31 01:01:01
1   1678-01-01 01:01:01
2                   NaT
3   2262-01-01 01:01:01
4                   NaT
Name: dt, dtype: datetime64[ns]
>>>

やはり 1677年 ~ 2262年という制限がありますね。


下記のようにPythonのDataframeではちゃんと処理することができます。

>>> import datetime
>>>
>>> print(datetime.datetime.strptime('2019-1-31 01:01:01', '%Y-%m-%d %H:%M:%S'))
2019-01-31 01:01:01
>>> print(datetime.datetime.strptime('1678-01-01 01:01:01', '%Y-%m-%d %H:%M:%S'))
1678-01-01 01:01:01
>>> print(datetime.datetime.strptime('1677-01-01 01:01:01', '%Y-%m-%d %H:%M:%S'))
1677-01-01 01:01:01
>>> print(datetime.datetime.strptime('1678-01-01 01:01:01', '%Y-%m-%d %H:%M:%S'))
1678-01-01 01:01:01
>>> print(datetime.datetime.strptime('2262-01-01 01:01:01', '%Y-%m-%d %H:%M:%S'))
2262-01-01 01:01:01
>>> print(datetime.datetime.strptime('2263-01-01 01:01:01', '%Y-%m-%d %H:%M:%S'))
2263-01-01 01:01:01
>>> print(datetime.datetime.strptime('0001-01-01 01:01:01', '%Y-%m-%d %H:%M:%S'))
0001-01-01 01:01:01


私の会社でのルールとして

  • 0001-01-01は入力不正なデータ
  • 0002-01-01はネットーワークに繋がってなくて日付が取れなかったデータ

など、日付に意味を持たせています。
それらをDatetime型に変換をすればエラーになるし、
errors='coerce' というオプションをつければ一律Noneになってしまうし....、
制限を外すオプションがあれば便利なのですが、今は無いですね。
従ってDatetime型に変換する前にもうひと処理を加えなければなりません。

非常にめんどくさい。
なんのためにこんな制限つけてるのかな...


まとめ

Pandasのdatetme型で使用できる、年月日は1677年 ~ 2262年

インフルエンザになった時のベストアイテム5選

fulu

みなさんこんにちは、いつも流行には乗り遅れる派の人なのですが、こんな時に流行りに乗っかってインフルエンザなうです。

f:id:yarite_parker:20190123162300j:plain

今はだいぶ落ち着きましたがインフルエンザが発症した初日には40.2度以上の高熱という結構なスコアを出させていただきました。w

これからインフルになる人たちに向けて、現在私がとても助けてもらっているモノを紹介するべく、インフルエンザになった時のベストアイテム5つを個人的に選ばせていただきました。

目次

ゾフルーザ(インフルエンザウイルス薬)

f:id:yarite_parker:20190123164917j:plain

2018年に塩野義製薬から出された「ゾフルーザ」という薬です。

私感ですが、この薬は本当に魔法かと思うくらいの効能でした。

インフルエンザが発覚した初日に1回飲んだだけなんですが、みるみるうちに症状が改善され、3日目の朝にはもう体調は悪くない状態まで回復することができました

経口で1回飲めばいい」ってのが非常に心強く、薬の副作用の心配もほとんど考える必要がありません。

 

経口薬で言ったら有名な「タミフル」という薬もあるのですが、色々事件がありましたよね。そんな中、この新薬である「ゾフルーザ」という薬の販売が広まってきた事は少し安心に繋がるのではないでしょうか。

もし病院で「タミフル」を処方されそうになったら「ゾフルーザ」を処方して欲しいということをいうべきだと思います。

そう思うくらい今回はこの薬に助けられました

 

※この記事を書いた後に耐性ウイルスが検出されました。
ウイルスの進化早すぎ!

ゾフルーザの効能・副作用について詳しくは下記参照してください。

www.kegg.jp

 

 

ポカリスエット

 

体調悪い時には定番の清涼飲料水なのですが、ポカリスエットを出荷している大塚製薬さんが、「飲む点滴」と言っているので間違い無いですね。
成分的にもポカリと点滴はほぼ変わらないらしいですしね。
小さいことに、「アクエリアス」じゃダメなのか?と何回か思ったことあって、調べました。
その結果、

  • アクエリアスには「スクラロース」という免疫に悪影響を及ぼすと言われている成分が含まれている
  • 高熱時には大量を汗をかき、ナトリウム・カリウム・マグネシウム・カルシウムなどが汗によって失われます。ポカリスエットの方がアクエリアスよりも塩分金属イオンが多く含まれており、高熱時の水分と塩分補給にはアクエリアスよりもポカリスエットの方が適している

ということで、熱を出したらアクエリよりもポカリの方がいいということです。

 

まぁ日本全国が風邪の時には「ポカリスエット」と言っていてて、子供の頃から風邪の時にはポカリスエットを飲んでいて「風邪(高熱)⇨ ポカリスエット」っていう脳になってるため、ポカリスエットを飲むと安心するし、効いてるという感じしますよね。

そうゆう安心感・信頼感ってのも弱ってる時には大事ですよね w

(成分的に本当に良いってのいうも知ってはいるが)

 

guitar-song-day.net

www.recomtank.com

 

「味の素KK おかゆ」玉子がゆ

f:id:yarite_parker:20190123173651p:plain

おかゆですね。特に玉子がゆが私は好きです。

値段も安く、味も悪く無い、調理も不要。

湯煎や電子レンジで温めるだけでいいので、非常に簡単に栄養補給できる流動食商品です。
おかゆは消化にもいいですしね。
玉子がゆ以外にも

  • 白がゆ
  • 玄米がゆ
  • スーパー大麦がゆ
  • 紅鮭がゆ
  • 梅がゆ
  • 小豆がゆ

ってのもあるので、飽きないです。

オススメの食べ方は、それだけでは味が薄いので、醤油や煎り酒をかけて食べると美味しいです。

 

ゼナ ジンジャー

f:id:yarite_parker:20190123185925p:plain

生姜メインの栄養ドリンクです。

かぜ・ねつなどの時の栄養補給に

  • ゼナ ジンジャーは、かぜなどの発熱性消耗性疾患や病中病後などの栄養補給に優れた効果を発揮するミニドリンク剤です。
  • 生姜ショウキョウ、甘草カンゾウ、桂皮ケイヒ、大棗タイソウをはじめ、ブラジルの強壮生薬ムイラプアマなど計14種の生薬(原生薬として計4320mg相当)とタウリン、ビタミンを配合しています。
  • カフェインを配合していませんので、眠りを妨げません。

引用:https://www.catalog-taisho.com/02662.php

大正製薬の飲料は、私的に信頼度はかなり高いです。
ポカリスエットといい、飲料系に関しては大正製薬で揃えたら間違い無いと思います。

またカフェインを使用していないので、薬との併用による「カフェインの過剰摂取」となることは無いと思います。

 

近くに住むまたはすぐ駆けつけてくれる友人・恋人・家族

これは超高熱を出してしまったら、悪寒や目まいで本当に動けなくなります。

病院にすらいけなくなる時もあるので、そんな時にタクシーを呼んでくれたり、買い出しに行ってくれたり、看病してくれる人がいるととても、ありがたいです。

そういう人がいてくれるだけで安心します。

病気の時に安心するってことはめちゃくちゃ大事で、本当に「病は気から」なので心配や不安を抱えてしまうと治るものも治りません。

私は会社の同期が心配してくれて色々買ってきてくれて、とても助かりました。
感謝しか無いですね。

二度と病気になりたくは無いですが、周りの人のありがたさを再度認識できたので、まぁ今回は悪くなかったインフルエンザなのかなと思います。w

 

まとめ

ここ最近、食事はコンビニ弁当やマック、運動も全くしない、睡眠不足、という状況が続いていて、自分の中で体調悪いなーと感じる機会が多くなっていた時にかかったインフルエンザでした。
やはり免疫力ってとても大切だと感じました。

  • バランスのとれた食事
  • 適度な運動
  • 適度な睡眠

っていうものの大切さを改めて実感しました。

2019年この三つも気をつけて、仕事を頑張りたいと思います。

アジャイル開発手法のうちの1つであるスクラム開発を実際にやってみて

scrum

今回はアジャイルソフトウェア開発手法の一つであるスクラム(scrum)について書きたいと思います。

目次

 

最初にスクラムを実際にやってみた感想を述べてたいと思います。

「アジャイル」や「スクラム」がわからない人は下を見て勉強していただければと思います。

 

スクラムを実際にやってみて

私が感じたメリット

1. チームやスクラムメンバーの状況を把握しやすい

カンバンボードを使って、毎日15分間のデイリースクラムを開催しているので、スクラムメンバーやチーム全体の進捗が把握でき、開発者間でのタスクの調整をしやすい。チームとしてタスク調整をうまくやるためにも属人化している仕事はなるべくなくさなければならない。

 

2. スクラムのチーム感がモチベーションへとつながる

スクラムメンバーでスプリントごとに決められたストーリーを完了させることが目標で、メンバーが皆同じ方向を向けるので、「チーム」で開発しているという感覚があり、一人で開発しているよりもモチベーションが上がる。スクラムメンバーで一つのプロジェクトを終えた時の達成感はハンパない!w

 

3. 開発の安心感がある

アジャイル開発では早くに「動くもの」がきでるし、不具合が発覚した時の出戻りが少ないので開発者としては安心感が持てる。

ウォーターフォールでは不具合時の出戻りリスクが大きいので、最初に考えられるリスクを全て網羅してそのリスクを防ぐ設計を机上で考えなければいけないので、頭でっかちな設計になりがち。その上、ソフトウェア開発は実際に動かしてみないとわからないことが多いので、経験上どんだけ考えてもエラーが出るものはでる!

そう言った意味でもウォーターフロー型開発よりはエラーや変化に柔軟に対応できる開発するアジャイル型開発の方が安心感がある。

 

難しいと思った点

1. 属人化しているタスクを手助けできない

属人化しているタスクは手助けできないので、できるだけ属人化を防ぎタスクの調整をしやすいようにするべき。我々は属人化しない工夫として、月に一度はチームで勉強会を開くようにして、情報共有やスクラム全体のレベルアップを図っている。

 

2.見積もりが難しい

スクラムはプランニング時にそのスプリントでやるストーリーを決定する。スプリント期間中にバックログからストリーを足すことは原則としてしてはいけない。余裕を持った見積もりをしてしまえば、後半やるタスクがなくなり無駄な時間が生まれてしまう可能性があるし、きつめにタスクを積めばストーリーを完了できず、目標に対する達成率が下がってしまう。

現在私の企業はスプリントが2週間で2週間ごとにプランニングを行なっているが、2週間でさえ調度よくプランニングをするのは難しいと感じてる。

ここはもっと経験や勉強が必要な部分である。

 

3. どこまでリファクタリングをするかが難しい

アジャイル開発では、計画段階で厳密な仕様を決めていないため、「もうちょっと改善したい」を繰り返し、リファクタリングをしているうちに当初の計画からズレてしまうことが多い。やっていきある程度仕様が見えたところで、区切りポイントを設けてやらないと永遠とプログラム改善が続いてしまう。

 

4. チームワークを悪化させてはいけない

スクラムはチームワークを重視した開発手法なので、メンバー間の関係が悪化した場合は仕事に支障がでることは覚悟しなければならない。まずはスクラムメンバーの性格を知るってのが非常に大事である思う。ITエンジニアは曲者が多いので、特に気をつけなければいけない点である。。。

 

 所感

スクラムについて、私個人の感想としてはやはり「楽しい」というのが一番です。

スクラムメンバーみんなが同じ方向を向いてプロジェクトを進めて行くという感覚があり、課題をチームみんなで解決したり、意見を出し合いながら共同開発したりするのはとても楽しいと感じております。勉強にもなります。(一人で黙々と開発するのも嫌いではないですが)という感ですね。

 

それでは「アジャイル開発」や「スクラム」についてわからない方のために説明していきたいと思います。

アジャイルとは

ソフトウェア開発手法は大きく分けて4つあります。
そのうちの1つです。

  • ウォーターフォール型開発
  • アジャイル型開発
  • プロトタイプ型開発
  • スパイラルモデル開発

では一体どうゆう開発手法なのかと言いますと、
1 ~ 4週間くらいの短い単位で設計、実装、テストの1セットを何度も繰り返して完成形に持っていく開発方法です。

アジャイル開発のメリット・デメリット

メリット
  • 仕様変更などの「変化」に柔軟に対応できる
  • 早い段階で「実際に動く画面や機能」を顧客が試せるので、仕様や機能の抜け漏れを事前に防げる
  • 開発者としてもドキュメントにこだわらずに開発できるので、開発に集中できる
デメリット
  • ユーザからの追加要求を飲みすぎるあまりに収束しなくなる可能性がある
  • その場、その場的な開発になってしまい、プロジェクトの計画からずれる可能性がある
  • 日本でアジャイル開発経験者が少ないために、何かしらの問題が生じたときに対応が困難になる可能性がある

 

メリット・デメリットについて詳しくはこちらで

codelab.website

アジャイル開発誕生きっかけ

アジャイル開発誕生のきっかけはの2001年にソフトウェア開発の分野において専門性の高い人たちが集まり「アジャイルソフトウェア開発宣言」という宣言をしたのがきっかけです。

内容は

私たちは、ソフトウェア開発の実践

あるいは実践の手助けをする活躍を通じて、

より良い開発方法を見つけ出そうとしている。

この活動を通じで、私たちは以下のような価値に至った。

"プロセスやツール"よりも個人と対話を、

"包括的なドキュメント"よりも動くソフトウェアを、

"契約交渉"よりも顧客との協調を、

"計画に従う"ことよりも変化への対応を価値とする。

すなわち左記の事柄に価値があることを認めながらも、私たちは右記の事柄により価値を置く。

 

アジャイル開発についてはこんな感じです。
それではその開発手法の1つであるスクラムについて書いていきたいと思います。

 

スクラムとは

アジャイル開発手法の一つで最もアジャイル開発で使用されている手法。

大雑把に言えば下記の4つの特徴を持っています。

  • スプリントという一定の期間(1~4週間)ごとに動くソフトウェアを作る
  • ストーリー(タスク)を優先順位付けしてバックログに保管しておく
  • 各スプリントにおいて、バックログの優先順位を基に、そのスプリントでやるストーリーを決定する
  • スプリントごとにバックログへのストーリーの追加や優先順位の見直し、開発チームが開発したソフトウェアの評価をプロダクトオーナーという役割の人が行う

引用: スクラム (ソフトウェア開発) - Wikipedia

スクラムガイド

スクラムについてのガイドです。

https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf

 

スクラムってどんな感じ

 一言で言えば「チームのコミュニケーションを重視した手法」です。

  • あたかもラグビーのスクラムを組むように、チームで肩を組み、ゲーム中に適切なボールのパスワークを行うように、スピーディーにチームワークで仕事をこなしていく。
  • 変化には対応しながらもスプリントにおいてはゴールを明確にし、全員で"完了"を目指す。(スプリント:1〜4週間単位の決められた開発期間。個人的には2週間が一般的だと感じている)
  • スプリントごとに出荷可能で動くものをアウトプットする。またこのフィードバックを得る。
  • Continuous Integration/Continuous Developmentで動的な開発ができるようにする。(絶えず動く状況にあるので、開発時の安心感がある)
  • 自己組織チーム
  • モチベーションを持って仕事ができるように!(ビジョンや状況の共有、Work with Respectを忘れない)

 

スクラムチームの構成メンバー

構成メンバー

  • プロダクトオーナー(1名)
    • チームがリリースするプロダクトに責任を持つ
  • スクラムマスター(1名)
    • スクラムに精通している献身的なリーダー(スクラムの掛け持ち可)
  • 開発チーム(5−9名)
    • 開発メンバー/QAメンバー、チームの主人公
禁止事項
  • プロダクトオーナーとスクラムマスターは兼任してはいけない。

  

開発者の中からテックリーダー(1−2名)という役を作り、開発の責任者としている企業もある。

 

スクラムの流れ

  • スプリントごとに目標を立てて成果をアウトプットします。(ピリオディックであることよりもリズムを掴む)
  • 以下の会議体を持つ
    • デイリースクラム
      • 毎日15分くらい各々のタスク状況を報告し合う。
    • プロダクトオーナー主導のプロダクトバックログの見直し(グルーミング)
      • バックログストーリーの作成や修正、また見積りや優先順位を付ける。
    • スプリントプランニング
      • これから開始するスプリントの計画を立て全員で同意する。
    • スプリントレビュー
      • スプリントで開発した成果が動く状態であることを示す。ステークホルダーからフィードバックをもらう。
    • スプリント振り返り(レトロスペクティブ)
      • スプリント終了時に、スプリント実行において伸ばす点、改善する点をチームメンバーで考える。

 

  •  スプリントの終わりには出荷可能なインクリメントができる

プランニングポーカーとは

  • 開発メンバーで各ユーザーストーリーを見積もること。
  • スプリントプランニング時に実行可能なユーザーストーリーをプロダクトオーナーと協議する。

プランニングポーカーのルール

  1. 「0」,「1/2」,「1」,「2」,「3」,「5」,「8」,「13」,「20」,「40」,「100」,「?」,「∞」のポイント(人日)が書かれた見積もりカードをスクラムメンバーに配る。
  2. スクラムメンバー全員がそのストーリーについてどのくらい工数が必要かを考え、ポイントが書かれた見積もりカードを提示する。
  3. 話し合いをして、全員一致でそのストーリーのポイントを決定する。

注意する点

  • 多数決ではない。
  • 見積もりカードに書かれている数字以外のポイントにはできない。
  • 20日以上要する場合はストーリーを分割した方が良い。

 

スクラムに使うべきツール

私的にはスクラムで使用するカンバンボードは「JIRA」一択な気がします。

非常に使いやすい!Atlassian製品は優秀です!

他にAtlassianが出しているサービスのうちの一つに「Confuluence」というものもあり、情報共有・情報公開などにはとても便利なサービスです。

fullvirtue.com

 

スプリント実施の重要ポイント

  • スプリント計画において、プロダクトオーナーと開発メンバーは以下をコミットする。
    • プロダクトオーナーはたかが数週間の計画を途中で変更しない。
    • チームはそのスプリントにおいて、「選択したストーリーを全力でDoneにしようとする」ことをコミットする。
  • 全員がチームの目標と現状を理解し取り組む。
  • 持続可能なペースで、あらゆる効率的な手法を取り入れながら、目標を達成する。

 

スクラムにおいて大事なこと

お偉いさんが「やれっ!」といっているからやるんだ!ではなく....

  • チェンジマインド
  1. みんながゴールを理解する
  2. その結果を理解する
  3. 計画する
  4. 納得する
  5. チームワーク
  6. 実行する
  7. 評価する
  8. 修正する

 

まとめ

スクラム開発で一番大事なことはチームワーク!

私の会社も「チームで楽しく仕事をする」がモットーです。

スクラムは非常に理にかなったソフトウェア開発で、最近は様々な企業がスクラムを導入しているという情報を得ています。

これからも続いていく開発手法だと思いますし、まだやったことのない方は試しに会社でやってみたいと提案してみてはいかがでしょうか。

 

参考

codelab.website

geechs-magazine.com

 

Python userの私が最近よく使うおすすめPythonライブラリ

reco
本日は最近私がよく使うPythonのおすすめライブラリを紹介したいと思います。
Pythonエンジニアがよく使う関数であることは間違いないし、Pythonエンジニアには必需品なライブラリです。
覚えておいて損はないです。

urlparse

URL を部分文字列に分割できるライブラリですね。
実際に使用すると、下記のような感じでURLを分割できます。

>>> from urllib.parse import urlparse
>>> urlparse('http://netloc/path;parameters?query=argument#fragment')
ParseResult(scheme='http', netloc='netloc', path='/path', params='parameters', query='query=argument', fragment='fragment')
>>> urlparse('http://netloc/path;parameters?query=argument#fragment').scheme
'http'
>>> urlparse('http://netloc/path;parameters?query=argument#fragment').netloc
'netloc'
>>> urlparse('http://netloc/path;parameters?query=argument#fragment').path
'/path'
>>> urlparse('http://netloc/path;parameters?query=argument#fragment').params
'parameters'
>>> urlparse('http://netloc/path;parameters?query=argument#fragment').query
'query=argument'
>>> urlparse('http://netloc/path;parameters?query=argument#fragment').fragment
'fragment'

最近私、boto3でs3の操作コードをよく書き、バケット名とプレフィックスを分ける時にはとても便利です。
下記のような感じでs3のバケット名とプレフィックスを取得できます。

>>> urlparse('s3://test/path/to/file_name.csv')
ParseResult(scheme='s3', netloc='test', path='/path/to/file_name.csv', params='', query='', fragment='')
>>> urlparse('s3://test/path/to/file_name.csv').netloc # バケット名
'test'
>>> urlparse('s3://test/path/to/file_name.csv').path.lstrip('/') # プレフィックス
'path/to/file_name.csv'

ちなみにもう一つ、そういったファイル操作の類で役に立つ関数が
os.path.basename()
ですね。これはファイル名のみを取得できる関数です。

>>> import os
>>> os.path.basename('s3://test/path/to/file_name.csv')
'file_name.csv'

urlparseとos.path.basename()を使えば、url分割やファイルパス分割がより綺麗にかけるのではないでしょうか。

boto3

Boto3はAWS SDK for Pythonライブラリです。
要するにpythonでawsサービスを動かすことのできるライブラリです。
boto3はawsを使用するPythonユーザにはなくてはならないものですね。
boto3について書いた記事がちょくちょくあるので参考にしてください。
www.yariteparker-blog.com
https://www.yariteparker-blog.com/entry/2018/12/28/Athena%E3%81%ABBoto3%E3%81%8B%E3%82%89%E3%82%AF%E3%82%A8%E3%83%AA%E3%82%92%E6%8A%95%E3%81%92Pandas%E3%81%AB%E6%A0%BC%E7%B4%8Dwww.yariteparker-blog.com


concurrent.futures

concurrent.futuresこれはマルチスレッド, マルチプロセスを実現できるpythonユーザには欠かせないライブラリです。
特にThreadPoolExecutorProcessPoolExecutorです。
マルチスレッドとマルチプロセスについては下記ページを参考にしてください。
qiita.com

基本的にmap関数と併用することが多いです。

  • マルチスレッド
>>> import logging
>>> from concurrent.futures import ThreadPoolExecutor
>>>
>>> def test(i: str):
...     logging.debug(i)
...     return None
...
>>> logging.basicConfig(level=logging.DEBUG, format='%(relativeCreated)6d %(threadName)s %(message)s')
>>> with ThreadPoolExecutor(max_workers=5, thread_name_prefix="thread") as executor:
...     res = executor.map(test, [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20])
...
280540 thread_0 1
280540 thread_0 2
280540 thread_2 3
280541 thread_0 4
280541 thread_2 5
280541 thread_3 6
280541 thread_3 7
280541 thread_3 8
280542 thread_4 9
280542 thread_4 14
280542 thread_1 11
280542 thread_2 12
280542 thread_3 13
280542 thread_4 15
280542 thread_4 19
280543 thread_4 20
280542 thread_0 10
280542 thread_3 18
280542 thread_1 16
280542 thread_2 17
  • マルチプロセス

ThreadPoolExecutorをProcessPoolExecutorに変えるだけです。
2系までは multiprocessing.Pool というライブラリが定番でしたが、3系からは新たなインタフェースとして concurrent.futures が出来たので私は
concurrent.futures をよく使ってます。
基本的にシングルコアでしか動かないpythonのパフォーマンスをあげようとしたら、マルチプロセスやマルチスレッドは欠かせないですね。

tempfile

一時ファイルの作成だとか一時ディレクトリの作成にはこれが便利ですね。
どうしても、ダウンロードをしてほったらかしにしておくとゴミが溜まるので、リソースを無駄にしないという意味では、一時ファイルや一時ディレクトリはとても大事です。

>>> import tempfile
>>> import os
>>>
>>> s = 'new file'
>>>
>>> with tempfile.TemporaryDirectory() as dname:
...     print(dname)
...     print(os.path.exists(dname)) # True (一時ディレクトリが作成されていることがわかる)
...     path = os.path.join(dname, "test.txt")
...     with open(path, "w") as f:
...         f.write(s)
...     with open(path) as f:
...         print(f.read())
...
/tmp/tmp58caqygi
True
8
new file
>>> print(os.path.exists(dname))     # False (一時ディレクトリが削除されていることがわかる)
False

まとめ

今回は私が最近よく使う4つのpythonライブラリを紹介しました。
Pythonユーザがよく使うライブラリだと思うので覚えておいて損はないです。
このようにどんどん使えるライブラリを今後も紹介できたらと思います。

  • urlparse (os.path.basename)
  • boto3
  • concurrent.futures
  • tempfile

boto3でAWS Lambda関数を呼び出す(invokeする)

boto3
やぁどうもフナミズです

boto3でAWS Lambda関数を呼び出す(invokeする)

本日はBoto3からAWS Lambdaの関数を呼び出してみたいと思います。

前提条件

  • python3.6以上がインストールされていること (フォーマットつき文字列リテラルを使用しているので)
  • boto3がインストールされていること

python3のインストール方法 (EC2 Amazon Linux2)

sudo yum install python3 # ver python3.7

boto3のインストール方法 (EC2 Amazon Linux2)

sudo yum install pip3
pip3 install boto3

Lambda Invoke コード

import boto3
import json

lambda_client = boto3.client('lambda')

# 関数名
function_name = 'test_function'

# Lambdaのeventに代入される値
event_dict = {
  "key1": "value1",
  "key2": "value2",
  "key3": "value3"
  }

invoke_lambda_function(function_name, event_dict)

# Lambda Invoke関数
def invoke_lambda_function(function_name, event_dict):
	response = lambda_client.invoke(
            FunctionName=function_name,
            InvocationType='RequestResponse',
            LogType='Tail',
            Payload=json.dumps(event_dict)
        )

用途

私はこのBoto3 Lambda Invoke 結構使うんですよね。
何に使うかというと、

s3にある複数のcsvファイルを全てjsonにしたい時とかにLambda関数でcsvからjsonにする処理を書いて、
csvファイルのs3のパスをevent_dictに代入して、このInvoke関数を使ってLambdaに投げまくって、一気にcsv to jsonにするとか。
まぁ複数ファイルをちょっとした処理で一気にETLしたい時に便利ですね。

まとめ

今回はBoto3を使ってLambdaをinvokeさせる関数を書きました。
面白いので、よかったら使ってみてください。

クロスアカウントにおけるs3へのオブジェクトの書き込み方のベストプラクティス

cross

クロスアカウントにおけるs3へのオブジェクトの書き込み方のベストプラクティスをお教えしたいと思います。Netflixもこのやり方です。

特にアカウントを3つ以上している場合は参考になるかと思います。

下記のようにAccount1からAccount2 s3にPut Objectをし、Account3からGet Objectをしたい場合みなさんどうします?

 

f:id:yarite_parker:20190102001248p:plain

やりたいこと

Account1からAccount2 s3にオブジェクトを書き込んで、Account3からget Objectする。

前提条件

  • Account2のバケットポリシーは適切に設定されている。

ベストプラクティス

まずはベストプラクティスを書きたいと思います。

ベストプラクティスはAccount1からAssume roleでAccount2のロールに一時的に切り替えてAccount2のロールでAccount2のs3に書き込む。

これがベストプラクティスです。

 

なぜこれがベストプラクティスなのかと言うのは下記に記載します。

ベストプラクティスではないやり方

 

まず私が最初にやろうとしたことは、Account1から --acl bucket-owner-full-control と言うオプションをつけてAccount2のs3書き込みました。

「--acl bucket-owner-full-control」はオブジェクトにフルコントロール権限をつけて書き込むオプションです。

Account2のs3バケットポリシーもちゃんと設定しているので、これでいけるだろうと思い、Account3からAccount2のs3オブジェクトに対してGet Objectした結果、エラーが生じてしまいました。

2つのアカウントだけのやりとり場合は、s3書き込み時に「--acl bucket-owner-full-control」のオプションを追加すれば問題は起こらないのですが、なぜ3つ以上のアカウントではエラーが生じてしまうかと言うと...。

  1. バケットポリシーでAccount3のアクセスを許可してもオブジェクトのowner(Account1)とバケットのowner(Account2)が一致しないためバケットポリシーは適用されない。
  2. --acl bucket-owner-full-controlはAccount 2に対してのフルコントロール権限なのでAccount3には適用されない。

この二つの理由でエラーが生じました。

 

オブジェクトの権限をAccount3にすればいいのではないか?と最初は考えました。技術的には可能です。

しかし、下記のようにアカウントがもっと増えた場合、いちいちオブジェクト一個一個のオーナーを変える必要があります。それはめんどくさいですよね。

f:id:yarite_parker:20190102005951p:plain

 

従って、「バケットのオーナーとオブジェクトのオーナーを揃えることによってバケットポリシーで権限を管理しましょう」と言うのがベストプラクティスです。

そのため、Account1からAssume roleでAccount2のロールを使用し、Account2のs3に書き込むことでバケットポリシーを適用させるって言うのが権限の管理も簡単で、ベストプラクティスと言うことです。  

まとめ

複数のアカウントを使用している場合は、Assume roleでs3 Bucket Ownerのアカウントのロールに切り替えてオブジェクトを書き込み、Bucket OwerとObject Ownerを揃えバケットポリシーで権限を管理しよう。

参考文献

qiita.com

AWS Glue 概要 (Data Catalog・Glue Crawlers・Glue ETLについて)

glue

2018/08/01 時点での記事になります。

目次

AWS Glue 概要

AWS Glueとは

「ETL処理の支援とデータカタログの管理をしてくれるフレームワークサービス」

◾️ポイント

  1. ETLツールではなく、あくまでもETL支援サービス
  2. そのため、Glueからの操作だけでは複雑なデータ変形はできない
  3. 複雑なデータ変形をするためには、Glueの機能によって自動生成されたコードをカスタマイズ(コーディング)しなければならない

主な機能

AWS Glueには主にData Catalog・Crawlers・ETLという3つの機能が存在する

Glue ETL

Spark Jobの作成、実行と管理をするサービス

  1. Python, ScalaのSpark scriptをジョブ登録して、実行、及び実行の管理。
  2. ジョブの実行はトリガー、オンデマンド、スケジュールを指定でき、 実行されたジョブのモニタリング、アラートを飛ばすことも可能
  3. Glue上でScriptの生成、編集可能
Glue Data Catalog

カタログ情報の管理・登録するサービス

  1. AWSサービス上に保存されたデータに対してのメタデータテーブルの管理・登録
  2. 扱えるカタログ情報はAurora、RDS、Redshift、S3、Athena、EMR、Redshift Spectrum、Hive Metastore
  3. スキーマ変更のバージョン管理可能
Glue Crawlers

Glue Catalogへカタログ情報自動登録サービス

  1. スケジュール設定に従って、指定したデータストアに接続し、データのスキーマを自動判断し、Data Catalogにメタデータテーブルを作成

 

Glue Data Catalog について

Glue Data Catalogについて説明する。

Glue Data Catalogが保持しているメタデータ

テーブルのメタデータをHive メタストアで管理。

  • プロパティ
  • データ型
  • データロケーション
  • 更新情報

 等を管理している。

メタデータのバージョンも保持しているので過去のものと比較できる。

メタデータの編集も可能。f:id:yarite_parker:20181231154149p:plain

Glue Catalogの活用例

AWS上のメタデータをGlue Catalogで集中管理

RedshiftやS3, RDS, DB on EC2のカタログ情報をGlue Data Catalogで一元管理することが可能。f:id:yarite_parker:20181231145437p:plain

 

Glue Crawlers について

Glue Crawlersについて説明する。

Glue Crawlersの概要図

f:id:yarite_parker:20181231155346p:plain

Crawlers ファイルの判別

分類子タイプ

分類文字列

コメント

Apache Avro

avro

ファイルの先頭から読み取って形式を判断します。

Apache ORC

orc

ファイルのメタデータを読み取って形式を判断します。

Apache Parquet

parquet

ファイルの先頭から読み取って形式を判断します。

JSON

json

ファイルの先頭から読み取って形式を判断します。

バイナリ JSON

bson

ファイルの先頭から読み取って形式を判断します。

XML

xml

ファイルの先頭から読み取って形式を判断します。AWS Glue は、ドキュメントの XML タグに基づいてテーブルスキーマを判定します。

Ion ログ

ion

ファイルの先頭から読み取って形式を判断します。

Combined Apache ログ

combined_apache

grok パターンを通じてログ形式を判断します。

Apache ログ

apache

grok パターンを通じてログ形式を判断します。

Linux カーネルログ

linux_kernel

grok パターンを通じてログ形式を判断します。

Microsoft ログ

microsoft_log

grok パターンを通じてログ形式を判断します。

Ruby ログ

ruby_logger

ファイルの先頭から読み取って形式を判断します。

Squid 3.x ログ

squid

ファイルの先頭から読み取って形式を判断します。

Redis 監視ログ

redismonlog

ファイルの先頭から読み取って形式を判断します。

Redis ログ

redislog

ファイルの先頭から読み取って形式を判断します。

CSV

csv

次の区切り記号をチェックします。カンマ (,)、パイプ (|)、タブ (\t)、セミコロン (;)、および Ctrl-A (\u0001)

Amazon Redshift

redshift

JDBC 接続を使用してメタデータをインポートします。

MySQL

mysql

JDBC 接続を使用してメタデータをインポートします。

PostgreSQL

postgresql

JDBC 接続を使用してメタデータをインポートします。

Oracle データベース

oracle

JDBC 接続を使用してメタデータをインポートします。

Microsoft SQL Server

sqlserver

JDBC 接続を使用してメタデータをインポートします。

Amazon DynamoDB

dynamodb

DynamoDB テーブルからデータを読み取ります。

※Zip, BZIP, GZIP, LZ4, Snappyといった圧縮形式でも分類可能

Crawlersによるカタログ情報自動更新

  • クローラーが自動的にスキーマを推測しカタログへ登録する

(クローラーがファイルタイプを識別し、どのような内容が含まれるのかを分類し、スキーマ、ファイルタイプ、パーティションを自動抽出しカタログへ登録する)

  • クローラーをスケジュール実行することで新しいデータやスキーマの変更を発見
  • クローラーを使わず手動で登録も可能
  • ログはCloudWatch Logsに出力される

Crawkersのスケジューリングについて

  • 毎日
  • 毎時
  • 曜日設定
  • 毎週
  • 月別
  • カスタム (Cronで設定)

ができる

f:id:yarite_parker:20181231154924p:plain

 

Glue ETL について

Glue ETLについて説明する。

Glue ETL ジョブ開発プロセス

下記のようなプロセスでジョブを開発する

  1. データソース選択 (ETL したいテーブルの選択)
  2. データターゲット選択 (データストア・形式・圧縮タイプ・ターゲットパス)
  3. マッピング  (列をどうするかを編集)
  4. コーディング (1 ~ 3によって自動生成されたコードの編集)
  • 1 ~ 3 でGUIでデータソース、ターゲット、列のマッピングを設定することでひな形が生成される。
  • csv ⇒ Parquetのフォーマット変換だけといった処理であればPythonコードの編集なしで実現可能。
  • サポートされている言語はPython2.7 or Scala

  • 自動生成されたコードはGlueの独自ライブラリを使用して書かれている。

Glue ETL ジョブスクリプトの基本 

f:id:yarite_parker:20181231160746p:plain

f:id:yarite_parker:20181231160909p:plain

DynamicFrameとDataFrameの違い

DynamicFrameとは

 DynamicFrameはAWS Glueで独自に定義されたデータ構造

特徴
  • Sparkで使われているDataFrameのようなテーブル形式でデータ
  • DataFrameと異なり、同一列内に複数のデータ型の混在が可能

※不正なデータが含まれてしまっているのを検知できるので非常に役立つ時がある。

DataFrameとの互換性
  • fromDF・toDFメソッドでDynamicFrame ⇔ dataFrameの変換が容易に可能
  • 同一列に複数の型が共存している場合は、toDFを使ってSparkのDataFrameには変換できない。修正してから変換する必要あり。
DataFrameとの使い分け

私は基本的にSparkDataFrameの方が慣れているので、最初にDynamicFrameからSparkDataFrameに変換して、その後の処理を書いている。

DynamicFrameの変換クラス・メソッド

DynamicFrameには変換のためのメソッドが用意されている。

AWS Glue PySpark 変換リファレンス - AWS Glue

Glue ETLにおけるライブラリの利用制約

ジョブ作成・編集時にs3からライブラリをインポート可能

  • Python 2.7 ライブラリ (v3はサポートされていない)

S3にライブラリファイルを置いてジョブ作成時に指定

S3のURLはカンマ区切りで複数設定可能

Pure Pythonのコードであるということ(Pandasの様なC言語拡張に依存するライブラリは利用不可)

  • Java ライブラリ
  • S3にJarファイルを置いてジョブ作成時に指定
  • Pure Javaもしくは Scala 2.11ベースのコードのみ

Glue ETL Jobのトリガー・実行状況

◾️ジョブ開始のタイミング

        – 先行ジョブ完了時

        – スケジュール

        – オンデマンド

ETL ジョブの実行状況

  • ETLジョブの状況は管理コンソールに表示される
  • ログはCloudWatch Logsに出力される

 

所感

  • Glue ETL,DataCatalog, Crawlersは全体的に使いやすいサービス
  • Glue DataCatalogはAthenaやEMRなど他サービスでも共有して使えるので非常に便利
  • DataCatalogは使うべきサービス
  • Crawlersはどこまで正確にテーブル定義してくれているかが未知数
  • Crawlersは探索にどのくらい時間がかかるのかも未知数で費用感が読めない
  • Glue ETLはコンセプトとしてはいいがPython3がサポートされていないのが難点
  • ETL ジョブは起動が遅く、ジョブが走るまでに5~10分くらいかかる。
  • DynamicFrameは気持ち悪いと思ったが、Spark DataFrameに容易に変換できるのであまり気にせずにコーディングできる。

結局...

  • Glue ETLはPython3がサポートされていないっていう時点で使用対象外 (コンセプトとしてはいい)
  • Data CatalogはDataLakeを管理する上で使用すべきサービス
  • Crawlersは未知数な部分が多いが、パーティションを自動的に切ってくれたり、試してみたいサービス。テーブル定義が間違ってたとしても手動で直せばいいので。

 

その他

EMRAWS Glue ETLの違い/使い分け

 

EMR

Glue

用途

汎用Hadoop/Spark環境

ETL処理に特化 Spark ベース

(Spark2.2.1をサポート)

スケールアウト

可能(ユーザ設計)

可能(パラメータ指定)

サーバ管理

数クリックで指定した環境が準備される

不要 (サーバレス)

S3へのアクセス

可能

可能

プログラミング環境

Hadoopエコシステム上の多様なアプリケーション

PySparkでETL処理を作成

コスト

Glueと比べて高い

EMRより安い

Python version

基本はv2.7

オプション設定でv3も可能

v2.7のみ

ライブラリ

インストールすればなんでも使用可能

Pure Python コードのライブラリのみ使用可能

EMRとの使い分け 

  • ビッグデータのETLはすべてGlueに集約してもいいかもしれない (Jobやメタデータの管理がEMRよりしやすい)
  • Spark以外のアプリケーションを使いた場合やアドホックな分析をしたい場合はEMR

使用可能リージョン

  • パリ
  • サンパウロ

以外全てのリージョンで使用可能

デフォルトのアカウント制限事項

デフォルトの制限はAWSサポートに連絡すれば、上限を引き上げてもらえる

リソース デフォルトの制限
アカウントあたりのデータベース数 10,000
データベースあたりのテーブル数 100,000
テーブルあたりのパーティションの数 100 万回
テーブルあたりのテーブルバージョンの数 100,000
アカウントあたりのテーブル数 100 万回
アカウントあたりのパーティションの数 10,000,000
アカウントあたりのテーブルバージョンの数 100 万回
アカウントあたりの接続数 1,000
アカウントあたりのクローラ数 25
アカウントあたりのジョブ数 25
アカウントあたりのトリガー数 25
アカウントあたりの同時ジョブの実行数 30
ジョブあたりの同時ジョブの実行数 3
トリガーあたりのジョブ数 10
アカウントごとの開発エンドポイントの数 5
アカウントあたりのセキュリティ設定の数 10
一度に開発エンドポイントによって使用される最大 DPU 数 5
一度にロールによって使用される最大 DPU 数 100

コスト

 1DPU : 4 vCPU,16GB of memory

ETL ジョブの料金体系

  • DPU 時間あたり 0.44 ドルが 1 秒単位で課金
  • デフォルト10 DPU (最低 2 DPU)

開発エンドポイントの料金体系

  • DPU 時間あたり 0.44 ドルが 1 秒単位で課金
  • デフォルト5 DPU (最低 2 DPU)

データカタログの料金体系

  • 最初の 100 万個のオブジェクトの保存は無料
  • 100 万個を超えて保存された場合、100,000 個のオブジェクトごとに毎月 1 ドル

クローラの料金体系

  • DPU 時間 あたり 0.44 ドルが 1 秒単位で課金され、クローラの実行ごとに最低 10 分

参考

dev.classmethod.jp

python 誕生日計算プログラム with Python

生年月日から、年齢と〇〇歳代を計算して出力するプログラムです。

誕生日計算プログラム with python
仕事の案件で生年月日から誕生日を計算し、x0歳代に変形するプログラムを書いた時に使用したプログラムを少し改良して作りました。

誕生日計算するアルゴリズムは下記のようになります。

  1. 今年から誕生年を引く
  2. 今年の誕生日を迎えていなければ、-1


例えば、 today = 2018/12/30, birthday = 2017/12/31 とすると、

  1. 2018(今年) - 2017(誕生年) = 1
  2. 今日は12/30で誕生日は12/31なので今年の誕生日はまだむかえていないので 1 - 1 = 0

と言うことで0歳になりますね。

さらに、 today = 2018/12/31, birthday = 2017/12/30 とすると、

  1. 2018(今年) - 2017(誕生年) = 1
  2. 今日は12/31で誕生日は12/30なので今年の誕生日は昨日でむかえているので 1 - 0 = 1

と言うことで1 歳になりますね。


っていう感じことです。

前提条件

  • python3.6以上がインストールされていること (フォーマットつき文字列リテラルを使用しているので)

Python コード

  • calculate_age.py
import sys
import re
import datetime as dt

def calculate_age(day_of_birth: str):
    # 区切り文字削除
    day_of_birth = re.sub(r'[^0-9]+', "", day_of_birth)

    # 8桁未満の入力は'入力エラーを出力'
    if len(day_of_birth) < 8:
        return "入力エラー"
    
    class birthday:
    	year = int(day_of_birth[:4])
    	month_day = int(day_of_birth[4:8])

    class today:
    	today = dt.date.today().strftime("%Y%m%d")
    	year = int(today[:4])
    	month_day = int(today[4:8])

    # 1. 今年から誕生年を引く
    age = today.year - birthday.year

    # 2. 今年の誕生日を迎えていなければ、-1
    if (today.month_day - birthday.month_day) < 0:
    	age = age - 1
    
    # 〇〇代出力
    if  int(age) < 10: # 10歳以上
    	generation = '10代未満'
    elif int(age) > 100: #100歳以上
        generation = '100歳以上'
    else: #0 < age < 100
        generation = f'{str(age)[:1]}0代'

    return age, generation

実行結果

>>> from calculate_age import calculate_age
>>> age = calculate_age('1992!06!03')
>>> print(age)
(26, '20代')

pythonのかっこいいprint文の書き方ランキング

print
Print文は基礎中の基礎。
python print文の構文何パターンかあるがどうせ書くならかっこいい方がいい。
ということで、独断と偏見による「変数と文字列の混じったかっこいいprint文の書き方ランキング」
を決定したいと思います。
文字列に変数を代入する時にも使えますね。

print文とは

print関数は文字列を出力する関数。

  • 基本構文

下記サイトがよくまとまっていたので、

  • 基本構文
  • オプション

などはこのサイトを参考にしてください
www.lifewithpython.com

変数と文字列の混じったかっこいいprint文の書き方ランキング

フォーマットつき文字列リテラル

Python 3.6 以降に使用可能な構文ですが、 f '文字列{変数}' という形式で記述する書き方です。
基本的にはこれが現段階では一番直感的かつ綺麗な書き方だと感じております。

>>> naka = 'ひねもすのたり'
>>> print(f'春の海{naka}のたりかな')
春の海ひねもすのたりのたりかな

※Python3を使用するなら基本的に3.6以降を使用することをお勧めします。

str.format()

これは、'文字列{}'.format(変数) という形式で記述する書き方です。
Python 3.6がリリースされる前は基本的にはこれでした。
しかもこれはフォーマットつき文字列リテラルよりも凝った書き方ができるので、
まだ使うときもあります。

>>> naka = '月は東に'
>>> print('菜の花{}日は西に'.format(naka))
菜の花月は東に日は西に

同じ引数を何度も利用することもできます。

>>> naka = '月は東に'
>>> print('菜の花{}日は西に'.format(naka))
菜の花月は東に日は西に

複数個を変数に入れることも

>>> ue = '菜の花'
>>> naka = '月は東に'
>>> print('{0}{1}日は西に'.format(ue,naka))
菜の花月は東に日は西に

キーワードを引数にもできます

>>> ue = '菜の花'
>>> naka = '月は東に'
>>> print('{first}{second}日は西に'.format(first=ue,second=naka))
菜の花月は東に日は西に

応用: 中央寄せ

>>> ue = '菜の花'
>>> naka = '月は東に'
>>> print('{first}{second}日は西に'.format(first=ue,second=naka))
菜の花月は東に日は西に
>>> # '菜の花や   月は東に   日は西に' ( 10 文字の中で中央寄せされた '月は東に' )

「+」で繋ぐ

'文字列' + 変数 + '文字列'のように「+」でつないでいくパターンですね。
はっきり言って私は見づらいです。あまり使いませんね、これは。

>>> naka = 'あつめて早し'
>>> print('五月雨を' + naka + '最上川')
五月雨をあつめて早し最上川

まとめ

最近ではAWS Cloudwathなどでログを見るために、ログ用にprint文を仕込むことが多々ありますね。
ダサい書き方をしてしまうと「こいつ初心者か」と思われてしまうことがあるので、
細かいことですが、print文一文でも少しこだわって書くようにしましょう。
そうゆう細かいところで綺麗にコードを書くことで、一歩上のエンジニアになりましょう。

私はPython PEP20 「The Zen of Python(禅・オブ・パイソン)」の There should be one-- and preferably only one --obvious way to do it.
「誰が見ても明らかな、たったひとつのやり方があるはずだ。」を常に意識してコードを書いています。

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
  • 日本語訳

www.lifewithpython.com