pythonの配布可能なpackageの作り方(setuptoolsを使ってhelloコマンドを作ろう)

珍しく技術ネタです。
今日はpythonでsetuptoolsを用いて、配布可能なpackageを作りたいと思います。

やりたいこと

  • ”Hello, world!”と標準出力に表示するhelloというコマンドを作る。
  • 上記を、setuptoolsを用いてPythonの配布可能なpackageで実現する。

環境

構成

root/
 ├ hello/
 │ ├ __init__.py
 │ └ hello.py
 └ setup.py

コード



説明

説明するほどでもないですが、setup.pyの内容について少し付け加えます。
packagesについては、hello.pyのあるpackageであるhelloのみをpackageとして登録しています。
複雑になっていく場合はsetuptoolsのfind_packages()を使ったほうが楽に済ませられます。(参照:Building and Distributing Packages with Setuptools — setuptools 35.0.0 documentation
entry_pointsについては、command名helloをhello package内にあるhello.pyのhello functionと関連付けることで?、commandとしてhelloが実行可能になります。

動かしてみる

packageのbuild&install

> python3 setup.py install
> hello
Hello, world!

packageのbuildのみ

> python3 setup.py sdist
> ls dist
hello-0.0.1.tar.gz

最後に

以上で、helloコマンドが実現可能になりました。
次回はもうpypiにpackageを登録するところをやってみたいと思います。

SFでの最大の敵

サンフランシスコでの最大の敵。それは治安でもなく、食事でもなく、英語でもなく、乾燥

比較的過ごしやすい気候だとは思うのですが、とても乾燥が厳しくて、あまり喉が強くない自分はあっという間に喉がやられてしまいました。。

いつもカリフォルニアに出張で来るときは寝るときもマスクをして、喉に気を遣っているのですが、原因不明の鼻炎も重なってしまい、なかなか辛い状況です。

 

ということで、まさか買うことになることになるとは思っていませんでしたが、買いました。加湿器。英語ではhumidifierと言うんですね。

買ったのはこちら。

www.amazon.com

日本では聞いたことないブランドですけど、評価もまあまあだったのでこれにしました。(すぐ壊れるというレビューが散見されますが、まあSF滞在中だけの予定だったので、そこは目をつぶりました。。そして何より喉の状態が深刻だったので早く欲しかった 笑)

で、到着したのがこれ。大きさは小さめですが、愛らしいデザインの?かわいいやつです。さっそく大活躍してもらっています。

f:id:siro_uma:20170408094245j:plain

1週間程度使っていますが、音も静かですし、加湿具合も良好なようで、お陰様で夜も寝起きも、のどのイガイガなくなりすっきりです。

一時は濡れタオルを部屋に干したりしていましたが、結構面倒だったし湿度もあまり改善されなかったので、加湿器を導入して良かったと思っています。

もし乾燥でお悩みの方がいたらぜひ検討してみてください。

言葉を学ぶということ

SFに来て、言語交換のMeetupに参加するようになって、言語を学ぶ姿勢について考えさせられます。

今日も日本語・英語のLanguage ExchangeのMeetupに参加してきたのですが、自分を含む日本人はやはりなんとなく完璧でない英語に恥じらいを感じ、英語の喋る時間は口数も少なくなりがちです。(もちろん全日本人というわけではないです。)

一方で日本語を学びに来ている多くの外国人の方々は、恥じらうことなく、なんとか自分の話したいことを日本語で表現しようと、たどたどしい日本語でたくさんの言葉をアウトプットします。中にはめちゃくちゃな日本語を喋る方もいるのですが、間違えることを恐れず、積極的に会話に参加し、話題を提供します。その方は昨年の11月から1週間のうち30時間を日本語の勉強に費やしているそうです。

どちらが早くその言語を使えるようになるかは言うまでもありません。

同じ言語を学ぶ人間として、彼らを教師として、少し自分の学習姿勢を見直したいと思います。

SFでTech meetupに参加してきた

先日のLanguage ExchangeのMeetupに続き、今度はTech系のMeetupに参加してきました。

内容

参加したのはBuilding a Test Infrastructure using Dockerというもの。SeleniumのスポンサーでもあるSauceLabsがホストしているようです。

発表してくれたのはCollective Healthという Health planをconsultするweb serviceを提供している?(間違っていたらすみません・・)企業の方。

www.meetup.com

内容はDockerをバックエンドに、pepper(お父さん犬のところのpepperとは別)という独自のシステムを作って、テスト環境を簡単に共有できるようにしましたよ。というものでした。SeleniumのMeetupでしたが、Seleniumの話は出てきませんでした。。

Pepperはテストの実行環境をDockerのimageと合わせてprofileと言う形で、dockerによって提供されるそれぞれのサービスのもろもろの状態のsnapshotを保存し、開発者やテスター間と共有できるようにすることで、テストの実行環境のポータビリティを上げ、テスターが見つけたをバグを開発者にいち早く再現可能にし、早期に問題を解決することができるというもの。

技術的な部分を含め詳細はYouTubeにて公開されている動画をご覧ください。


SF Selenium Meetup 3.28.17

感想(技術観点)

品質を早期にフィードバックすることは、品質を上げるために重要なアプローチだと思うので、非常に良いアイディアだと思います。

また、テスターが問題を見つけたけど開発者の環境では再現しないというのは、私の職場でも散見される良くない事例だと思うので、環境の共有というアプローチも品質を上げるという観点でも、非常に有効だと思います。

残念ながらPepperは今のところCollective Healthの内部サービスなので、我々はPepperを利用することはできませんが、アイディアとしては社内に持ち込めるのかなと思いました。

感想(初Meetup参加観点)

初のSFでのTech系のMeetupの参加ということで、日本の勉強会と比較してのコメントとしては、

質問の多さは、こういう勉強会に限らず社内の会議でも感じることですが、わからないことは徹底的に明確にする。的な精神がひしひしと感じます。また、必ずといってウィットに富んだ質問が必ず出るのも、こちららしい文化だと思います。

食べ物の多さは、まあどうでもいい事と言えばそうですが、日本だとあっという間になくなってしまう程度の量しか出ないことが多い(私がそういう会にしか参加していない?)のに対し、こちらはかなりの量が出ます。飲み物も食べ物も。味は、、so so?

最後にオープンソースに関してですが、Meetup内のQAセッションである人が、「オープンソースじゃないの?がっかり。」みたいなコメントがあって、それに対して開発者も「今は社内で評価中で、じきにオープンソース化する予定」的な反応をしていて、やっぱりこっちは多くの人に使われてなんぼ的な考え方なんだなあと思いました。

もちろん日本でもそういう考え方はあるけど、まだどちらかというと外部公開はせずにそれを使ってお金を稼ぐ傾向が強いかなあと思っています。それが自身の製品に関わるクリティカルなものであるケースを除いて、オープンソース化して色んな人に使われて揉まれて、改善されたものを自身の製品開発に活かすほうがメリットが大きいと私は思っているので、個人的には見習いたい姿勢です。

 

プレゼンが始まる前の30分程度のネットワーキングタイムもそつなくこなし、終始楽しく参加できたMeetupでした。

最後に写真をぺたり。

f:id:siro_uma:20170328190316j:plain

初Meetup in SF

初めてMeetupと呼ばれるものに参加してきました。もともとSFで盛んにMeetupと呼ばれるものが行われているということは知っていましたが、一歩が踏み出せず、、でしたが、ついにデビューしました。

Meetupの内容

参加したのは、Nihongo Moriagariという日本語と英語のLanguange ExchangeのMeetupで、2時間の中で30分ずつ交互に日本語の時間と英語の時間を区切って、その言語で話すというもの。

今回は英語Native相当の人が3人と、日本語Native(当然日本人)3人の6人でした。

会話の内容は特に決まっていなくて、簡単な自己紹介から、どんなことをしているとか、バックグラウンドとか、なんで日本語を勉強しているかなど、その場の成り行きな感じです。

www.meetup.com

感想

自分は普段の会話の英語が苦手なので、なかなかすらっとフレーズが出てこないんですが、練習の場としては非常に有益で、今後も定期的に参加したいなと思いました。

自分の英語のレベルと気にして、こういう場に出ていきづらい気持ちもありますが、あまり気にしてもしょうがないし、来ている人はあまりそういうことは気にしている感じではないので、英語を上達させたいと思う人には良いと思います。

また、友達とか知り合いを見つけるにも、とても良い場所なので、そういう目的で参加しても良いように思います。

今回もピースボートにも乗ったことのあるAu Pairとして1年間こっちに滞在している女の子、大学を休学して1年間のアルバイト先を探しているSW Engineerの学生さん。というユニークな面々と知り合えました。

 

また面白そうなMeetupが見つかったら積極的に参加してみようと思います! 

しろうま in San Francisco

色々ありまして、仕事の関係で3ヶ月程サンフランシスコの開発拠点で修行することになりました。

#色々ありまして、と言いつつ自分の希望です。

 

こちらに来て1週間経ちまして、ブログを書く余裕が出てきたので記念投稿をしつつ、目標とやりたいことをつらつら書いて行きたいなと。

SFのエンジニアとの技術の力量の差を知る

いきなり定量的に測れなさそうな目標で、どちらかというとやりたいことになると思いますが、こっそり海外で働くことを夢見るいちエンジニアとして、世界の最高峰(と思われる場所)で働いているエンジニアはどれだけの技術力を持っているのか、またそことの自分の力量の差はどの程度なのかを知りたいと思います。

職場に限るとかなり偏りそうなので、meetupなんかを使いながら社外にも顔を出してみたいと思います。

英語を上達させる

これも定量的に達成を測るのは難しいですけど、感覚的には成長は感じれると思っています。

今は仕事の話であればリスニングはまあまあいけるんですが、仕事外の話のリスニングと、スピーキングが全体的に絶望的なので、ここをなんとかネイティブおよびネイティブ相当の人たちに揉まれて上達させたいと思います。

社外での英語を使う機会を増やすためにも、こちらもmeetupとか、あとは次の目標でもある友達を作ったりなんかして、英語漬けな環境を作って行こうと思います。

(社外で)友達を作る

せっかくSFに3ヶ月もいるので、こちらにローカルの友達を作りたいと思います。

英語の上達はもちろん、海外の文化を触れることが大好きな自分としては、現地の友達を作ることが現地の文化を知るのに一番だと思っていますし、人種のるつぼと言われるアメリカにはきっと面白い人がいると信じています!笑

シャイな性格が邪魔をしがちですが、どうせ3ヶ月でいなくなるので失うものもないし(特に社外なら)、積極的に行こうと思います。

目指せ、1ヶ月以内にフランクに飲みにいける友達をみつける。

ヨセミテ国立公園に行く

ヨセミテ国立公園は、旅行大好き&自然大好きマンの自分としては絶対行かねばならないところです。

残念ながらSF滞在中に祝日を入れた3連休は1度しかないようで、そこで行くしかないかなあと今はモヤッと計画中。と言いつつも、早めに宿を取らないとあっという間に埋まってしまうとか。。

ヨセミテ国立公園以外もどこか自然に溢れた場所に行けたらいいなと思います。

 

とりあえず以上が目標かなと思います。気づきや更新があったら適宜アップデートしていきます。

あ、もちろん、仕事もがんばります、仕事も。。

 

JaSST '17 Tokyoに参加してきた話

JaSSTことソフトウェアテストシンポジウム 2017 東京に参加してきました。

「次世代システムに求められるソフトウェア検証技術~静的解析の価値と有効性~」

MathWorks Japanさんの製品紹介でした。

静的解析の導入はバグの早期発見につながる。(フィードバックの前倒し)

という部分だけは納得しつつも、静的テストで見つかるバグって、どれだけ動的テストで問題になるバグに紐づくのだろう、というのは永遠の謎。

CIとも相性が良いですし、少ない工数でバグを防げるならやっとこうっていうノリでしょうか。

 

楽天トラベルの開発プロセスに関して」

楽天トラベルさんの開発プロセスを改善しましたよ。というお話。

かなりざっくり言うと、QAが開発に参加するタイミングを早めましたよ。という内容だったと思います。

要件定義の段階でQAも参加する。テスタビリティを担保する。(=QA観点で漏れている観点を早期にフィードバックできる。)というところは、すごいな、と思いました。自分のところは要件定義の段階では絡めていないので、見習いたいと思いました。

PdM、開発、QAの三権分立の体制もパワーバランスが取れているそうで、QA的にはやりやすいだろうなあと思いました。うちはなんとなくPdMの下請けとして開発とQAが働いているようなイメージです。

もう少し前衛的に働いて、開発に貢献することで、こういう良いパワーバランスで働けるのかなと思いました。

 

受け入れテストの自動化 ~ OpenCVの「眼」で捉え、Pythonの「脳」が思考し、Appiumの「指」で動かす」

 自動化ネタです。昨年のCEDECで一部発表されたネタで、CEDECで聴き逃した自分としてはかなり興味があったネタです。

Appiumが技術的な主軸なのかと思っていましたが、Image Recognitionが主軸な内容でした。確かに、ゲームのようなUnityとかGLなんかでゴリゴリ書かれるようなモバイルアプリは、 Appiumでelementは簡単に取れないので、そうならざるを得ないですね。

あとゲームというある程度の反応速度を求められる試験対象の性質上、モバイルの画面をMHL出力経由でHDMIキャプチャに入力し、そのストリームをリアルタイムに画像処理にかけるというようなことをしているようです。

大掛かりで力技な感じですけど、それを作っちゃうあたりはすごいなと思いました。

自分のところはゲームではないモバイルアプリの評価なので、素直にAppiumに頼るのが良いのかなと思っています。

詳しい内容は CygamesさんのTech blogを御覧ください。

【JaSST’17 Tokyo フォローアップ】受け入れテストの自動化 | Cygames Engineers' Blog

 

「教科書に載らないテストマネジメント」

テストマネージャとして活躍している方々をパネリストに迎え、あるお題に関して、本には載らないような生の声を聞けるセッションでした。

個人的にはこのセッションがベストセッションでした。

以下がお題と印象に残った言葉。

テストマネージャの役割と責任
  •  知ること・知らせること。何を知りたいかをステークホルダーに聞くこと。知りたくないことを報告していない?
  • ぶれない心。対等に渡り合う精神力。
  • これを実現するためには、これだけの努力が必要です。と言えるような準備。
1週間残業が続いたときに、メンバーに何を話すか
  • 可視化(残テスト数、バグ数)
  • スコアボードを作る。すべてのステークホルダーが対等に、すべての状況を正しく理解できるもの。例えば野球のスコアボード2アウト満塁の状況でフライがあったらそれぞれが何をするかは明確。
テストプロジェクトを成功に導くための秘訣
  • バグを出すことが仕事ではない。バグを直さないなら、直してもらうためには何ができるのか。
  • バグの修正率を健全な状態に保ちましょう。(一定かつ、高い数字)
  • 正直でいられるようにする。悪い嘘の上塗りをせずに、誠実に状況を伝えるような健全なプロジェクトを目指す。
テストマネージャとしてどんな努力をしてきたか・しているか
  • とりあえずやってみる。(興味を持つ・楽しむ)
  • 社外⇛社内への還元
  • JSTQBシラバスを読む。(Learning Object)
  • 知ったことを自分たちのやり方に適用する。
  • 多くの人と共同で仕事をする訓練。自分の事だけやればOKと思っていたら絶対にうまくいかない。

 

本当は他にも参加したセッションがあったんですが、あまり書くことがないので省略します。

JaSSTはテストの楽しさを再認識させてくれる場所で、テストに関するインスピレーションや気付き与えてくれます。

JaSSTで得られた知識を少しでも現場で役立てればと思います。