2017年の振り返り
2017年も終わるので振り返ろうと思います。
○お仕事
一年間をDjangoRestFrameworkに捧げました。
分からないから少し分かるになったような気がします。
awsのアソシエイトの資格が取れました。
資格を取るとawsのコンソールを触ることが怖くなくなってきました。
インフラはもう少し面倒見れるようになれればいいなぁと思います。
○健康面
何度か風邪を引いたり腰痛で休んだりしました。
田舎健康おじさんを目指して少し運動しようと思います。
○勉強
この1年ではっきりしましたが自分はファーストペンギンになって新しいものを追いかける力は全くありません。特に未知のものに対しては超苦手でした。
欲しい情報をググってコピペする才能しかありそうになりません。
どうも技術者として生きていく力はなさそうだなーということがはっきりしました。
とはいえ何とかして生きていかなければならないので、とにかく今やってることをきちんとまとめていったりよりよいコーディングをして行ければなぁと思います。
まぁ飛んできた玉を打ち返しつつ、なにか全然違うプログラミング以外のスキルを伸ばしていこうかなと思います。
はっきりいって僕は技術力が一番大事という言説を一切信じていませんがその話は割愛しようと思います。
それではみなさま良いお年を
How to start and stop EC2 with AWS lambda
sorry! my english slill is very low!
英語で書いた方がアクセス数稼げるんでね？って推測を基に怪しい日本語と英語で記事を書いてみようと思います。(en: i think tech blog what written by english can get more access, so I challenge to write blog in English.)
I write start/stop EC2 and set and register_instances_with_load_balancer/ deregister_instances_from_load_balancer.
EC2をlambdaで開始する方法(en:How to start EC2 with lambda?)
runtime: python3.6
import sys
import boto3
import os
client = boto3.client('ec2')
ec2 = boto3.resource('ec2')
elb_client= boto3.client('elb')
instance_id = os.environ['INSTANCEID']
elb_name = os.environ['ELBNAME']
def handler(event, context):
# start EC2
response = client.start_instances(InstanceIds=[instance_id,])
instance = ec2.Instance(id=instance_id)
instance.wait_until_running()
# add elb
response = elb_client.register_instances_with_load_balancer(
LoadBalancerName=elb_name,
Instances=[
{'InstanceId': instance_id},
]
)
we need set Environment variable like this
EC2をlambdaで終了する方法(en:How to stop EC2 with lambda?)
runtime: python3.6
import sys import boto3 import os from time import sleep client = boto3.client('ec2') elb_client= boto3.client('elb') instance_id = os.environ['INSTANCEID'] elb_name = os.environ['ELBNAME'] def handler(event, context): response = elb_client.deregister_instances_from_load_balancer( LoadBalancerName=elb_name, Instances=[ {'InstanceId': instance_id}, ] ) sleep(10) response = client.stop_instances(InstanceIds=[instance_id4,])
DjangoRest FrameWorkで違うSerializerのfieldを使い回す方法
タイトルが長いですね
何がやりたかったかというと簡単な話です
親のSerializer
fields =('項目A', '項目B', '項目B', '項目C')
子のSerializer
親のFields に加えて 項目D
継承使えば簡単でしょって思ってたんですが結果的には継承では上手くいかないことが分かったので
class BaseSerializer(serializers.ModelSerializer): class Meta: model = Mymodel fields = ('field_a', ) class ChildSerializer(BaseSerializer): field_b = serializers.CharField() class Meta: model = Mymodel def __init__(self, *args, **kwargs): self.Meta.fields = list(BaseSerializer.Meta.fields) self.Meta.fields.append('field_b') super(ChildSerializer, self).__init__(*args, **kwargs)
def init()で親のfieldsを読み込むなんて、これ継承の意味ないじゃんって気もします Childの方のfieldsに何かを書くと上書きされてしまうので意味がないし、Baseのfieldsに全部書いておいて不要項目を取り除きながら使う方法もありますが、それだとSerializer呼ぶところ全部に必要項目渡さなきゃ行けないしちょっとめんどい、childの方にfield_aとbを宣言する方法も採れますが、いまいち感満載。
なんか良い方法あるんだろうなぁと思いつつとりあえず自分なりの解決方法だけ残しておきます
pythonチュートリアル メモ 後半
pythonチュートリアル第3版を読んでみてのメモになります。
付箋紙を貼りながら読み進めるスタイルだとブログにまとめる際に楽なので今後もこのスタイルで読書していこうと思います。
自分が知らなかったこと、気になった部分だけどを抽出しているだけなのでpythonを学ぶ上での普遍的な重要ポイントを書き出してるわけではないことをご了承ください。
6章 モジュール
特になし
7章 入出力
ゼロパディングするとき
'12'.zfill(5) >>>'00012'
フォーマット関数にキーワード引数を取れる
"お賃金は{money}円です".format(money="5000兆")
8章 エラーと例外
tryにコードを追加せずにelseに後続処理を書いた方が、
後続処理で予期せず同じ例外をキャッチしてしまう問題を回避出来る。
→だいたいtryの後続にそのまま書いていたので、新鮮な書き方でした。
とはいえ０で割るエラーとかは割り算でしか起こりえないし、他の行で同じエラーが起こることってあんまりないような気もします。
個人的にはtry節にそのまま書いていってもいいんじゃないかなぁと
try: エラーを予見する処理 except: 例外処理 else: エラーにならなかった時の処理
9章 スコープと名前空間
説明が難しいけどこういうことができる。
外側のスコープの変数の値を更新出来る
def friends_test(): def nonlocal_friends(): nonlocal friend friend = "すっごーい" frined = "〜なフレンズなんだね" nonlocal_friends() print(friends) >>> "すっごーい"
10章 標準ライブラリめぐり
関数のコメントを実行出来る
def gacha_cost(cost) """ >>> print(gacha_cost(3000)) 0 """ return 0 import doctest doctest.testmod()
11章〜14章
特になし
付録 用語集
こういう表現をするんだってのを知ったものだけピックアップ
EAFP(ごめんなさいはお願いしますより楽)：try〜catchするような処理
LBYL(飛ぶ前に見ろ/転ばぬ先の杖)：キーがあるかどうか先に調べてif文なんかで先に聴いておくような書き方
pythonチュートリアル メモ 5章まで
とりあえず読んでて知らなかったこと、知らなかったけど便利そうな書き方や考え方を見つけ次第メモしていこうと思います いわゆるチラシの裏ってやつです
1章
特になし
2章
特になし
3章
・raw文字列を使うと正規表現を無視できる
r'c:\name'
\nの部分を改行として扱わなくなる
・文字列は変更不能体(immutable)
・リストは変更可能体(mutable)
・print関数にendを渡すと表示するたびの末尾に好きな文字を入れられる。
for i in range(100):
print(i, end=",")
>>0,1,2,3,4・・・
四章
・range()などを反復可能態(itarable)と呼ぶ
・ラムダを使って配列内のタプルのソート
>>>sphere = [(1, 'toyosaki'), (2, 'kotobuki'), (3, 'takagaki'), (4, 'tomatsu')] >>>sphere.sort(key=lamda member: member[1]) [(2, 'kotobuki'), (3, 'takagaki'), (4, 'tomatsu'), (1, 'toyosaki')]
関数名.docで関数の下のコメント行が呼び出せる
5章 リスト
・list名.pop()すると最後に追加された要素を取り出す
aqours= ["千歌", "曜"・・・]
aqours.append("黒澤ダイヤ")
aqours.pop()
黒沢ダイヤ
・辞書の作り方
tika_idle = dict(name="maison book girl ", rebel="tokuma", members=4)
個人的には下の書き方よりもクォーテーションを書かなくて済む分好きかもしれません。
{"name": "maison book girl",
"rebel": "tokuma",
"members": 4}
今回読書した分をブログにまとめるために改めて読み返しましたが、時間の無駄なので今後は読書のたび付箋紙とか貼り付けたほうがいいなぁと思いましたkindleとかって付箋紙的な機能あるのかな
オブジェクト指向設計実践ガイド 読書会 第二章のメモ
ギーラボで2週間に一回行っている読書会の第二章のまとめです
本書全体ですが具体例がギアがどうとかタイヤの直径を計算するクラスの実装で話が進むので自転車の仕組みに詳しい人のほうが読みやすいと思います。
自転車乗りでrubyに詳しい人なら一人で読みすすめられるんじゃないでしょうか。
第二章 単一責任のクラスを設計する
コードを書く上で重要なことはTrue
・見通しが良い(Transparent)
・合理的(Reasonable)
・利用性が高い(Usable)
・模範的(Exemplary)
自転車のコグ(cog)をギアの歯数(chainring)で割るとratio（車輪が何回転するか）が求められるので
ギアクラスを作ってcogとchainringを与えるとratioが帰ってくるクラスを作れば良いのですがそこにリムの直径とタイヤの厚みが入ってきて・・という話でどう書くかという話が進みます。
・class gear(歯数, コグ, リム, タイヤ)
def ギア比
return 歯数/コグ
def ギアインチ
return ギア比×(リム+ (タイヤ×2))
単純には引数を4つにすればいいんですけど、それだと従来の歯数とコグからratioを求める処理が落ちてしまう。
クラスが単一責任かどうか見極める
見極め方が乗っていました。今後参考にしてみたいと思います。
>クラスの役目を文章にしてみて、「それと」や「または」が入っていたら複数の責任を負っていることが分かる
クラスを分けるべきかどうか
本書ではクラスを分ける手間とコストによって分けてもわけなくても良いんじゃないか、決断を先延ばしでもいいじゃんという話が続きます。
別のクラスの作成
本書では最終的には他の要件がでてきたため、クラスをわけてwheelクラスを作ることになります。
まとめ
変更可能でメンテナンス性の高いオブジェクト指向ソフトウェアへの道のりは単一責任クラスから始まるということで、一つのクラスは一つの責任になるようにしましょうねということで締められていました。
（でも分けるかどうか悩ましい段階なら決断先送りでもいいよねとも）
感想
rubyの知識がないので有識者の方に随分助けられましたが、その一方でrubyの言語仕様に気になってしまいそちらに話が流れてしまったのでもっとちゃんとオブジェクト指向についてあまり考えられなかったなぁと。
クラスへの引数にクラスを渡すって発想はなかったのでこれは活かしていきたいなと思いました。
第三回の登録はこちらから！
PyCon JP 2017のブース出展の反省点
09/08〜09/09に早稲田大学の西早稲田キャンパスで行われた「PyCon JP 2017」にスポンサーブースとして参加したので反省点を書いていこうと思います。
hololensを展示したことについての反省点
弊社が清水の舞台から飛び降りるつもりで買ってしまったhololens、こいつを使わない手はないとhololensありきでイベント準備を進めましたが・・・結果的にはpyconのような手狭で時間も短いイベントでは使うべきではないという話になります。
(※hololens自体は神がかりガジェットですが何事も用途があります)
1.ユーザーに操作をさせるのは大変
正直言って始めてhololens掛ける人に操作説明するのはとても大変でした。
2日目からは3秒経ったらアクションを開始するように修正しました。
2.一回の体験に時間が掛かる
pyconの忙しいスケジュールを縫ってブースに訪れた人たちにhololens掛けてもらうのは貴重な時間を奪うことになります。
3.何をやってる会社か伝わらない
弊社はDjangoを中心としたwebの請負みたいな仕事をやっている会社なのですが、hololens+unityなんて展示物を出してしまったがために、何しにpyconに来てるのかよく分からない謎の会社になってしまったように思われてしまったのかも知れません。
一応、unityからDjango RestFrameworkで作ったレストフルなwebapiを呼んでるところがだったのですが、伝わりにくくなってしまいました。
ちなみに弊社は事業としてunityなどを扱ったことはありません。
自社サービスもなく、基本なんでも作るのでお仕事くださいってスタンスなので見せられる製品がないコンプレックスの裏返しでみんなが驚くモノを作ろうと熱意が暴走した結果でもあります。
偶然弊社ブースにお越し頂いて偶然上手くいったMR体験出来た方はおめでとうございます。
うまく見えなかった方には申し訳ございません。きちんとした体験会に行けば素晴らしい体験ができます！弊社の力不足です。
ブース出展よりもやるべき事があるのかも
弊社はこんなことできますよ〜ってアピールするならやっぱり講演するLTするなどでプログラミングやインフラの知識をきちんとアピールすることが大事なのかも知れません。
本来はそれを見せるためにDjango製のアプリを出していましたが、 hololensという飛び道具に飛びついた結果失敗してしまったように感じます。
ブースにいると講演を聞き逃す
ブースにいて話込んでいるとつい時間を忘れて自分が聴こうと思っていた講演を聞き逃してしまいます（自分はそれで二つ聞き逃しました）
エンジニア兼ブース担当兼営業的な動きというフルスタックな動きには限界を感じました。
良いことも言っておかないと辛い
とりあえず、hololensだしてた変な会社ということで認知が頂ければ弊社としてはいいのかなぁと思ったり思わなかったり
後は反省点は多くとも結構な熱量をpyconに注ぐことができたので来年リトライする機会に恵まれたらもっとシンプルで驚きのある物を作りたいなぁと
０から1へ、というラブライブ！サンシャイン!!のテーマを旨に来年のpyconではもう少し色々自己顕示欲を形にできればなぁと思います。
