「index "pg_toast_16408_index" is not a btree」というエラーが出力する。
RedshiftにCOPYコマンドでデータを投入するとたまーに発生する「index "pg_toast_16408_index" is not a btree」というエラー。
調査
テーブルにレコードがない状態でCOPYコマンドを実行した際、ANALYZE実行されると発生するAWSのバグらしい。 *1
[COPY from s3 to redshift fails]
AWSからの回答
今回お客様環境で発生したエラーとなりますが、同様の報告は確認出来るものの、明確な再現手順が存在しないため、原因は特定出来ておりません。 しかしながら、お客様環境及びその他の事例でも再起動で解消する為、一時的なメモリ上の問題である可能性が高い状況でございます。 もし、事象が再現した場合には、先ずは再起動による対処をご検討ください。 また、もし事象の再現を明示的に行うことが可能であれば、原因追及のために調査を行うことが可能でございますので、手順等含めてご連絡頂ければ幸いでございます。
こんな感じ。レアケース系のやつ。
回避方法
とりあえず以下2パターンのうちどれかをやればよいっぽい。 1. クラスタ再起動 2. COPYコマンド実行時にオプションに[STATUPDATE off]を明示的に設定 AWSの回答的にもとりあえず1をやればよいみたいな感じ。 俺が遭遇した時もとりあえずそれでうまくいった。 ただ、これだと毎度、発生するかもしれないっていうのがリスクとして挙がるし、運用中にRedshift止めるの?って問題もある。 でも2パターンでANALYZEコマンドを実行しないようにすると、最適化が行われないのでレコード件数が増大していくと共にSQLの実行結果が返ってこない。 パフォーマンス犠牲にするぐらいならたまたま発生パターンは目をつぶるかーみたいなやつ。
www.slideshare.net
*1:COPYコマンドのオプションで何も設定していないと、初回だけANALYZEが実行される
2018年4月から『アイカツフレンズ!』がスタート
今日「アイカツ!」シリーズの最新作『アイカツフレンズ!』が発表されたので、取り急ぎ。
http://www.aikatsu.com/friends/teaser/www.aikatsu.com
プレスリリースを見る限り、ユニットがテーマみたい。
「友達と一緒にアイカツ!」をコンセプト
に、シリーズ初となる 2 人のアイドルがユニットを組んでトップアイドルを目指すストーリーです。
http://bandai-a.akamaihd.net/corp/press/100000663522818.pdf
『アイカツスターズ!』ではわりと個が強くて、ユニット要素が薄かったので、そこが強化されたのかなー。
DCDだけをみると今までいまいち薄かったフレンドのカードと一緒にユニットを組めるというところを前面に押そうとしている感じか。
バンダイの中ではおもちゃ売上というよりも完全にアパレル売上がメインにシフトしてるよなあとプレス見てやっぱり感じる。
ゲーム内で初めてルージュやチークなどのコスメア
イテムを使った演出を導入し、実際の女児用化粧品としても 2018 年 6 月より「アイカツ!」シリーズのアパレル
ショップ「アイカツ!スタイル」(http://p-bandai.jp/aikatsu-style/)で発売予定です。
http://bandai-a.akamaihd.net/corp/press/100000663522818.pdf
aikatsu! for Ledyやaikatsu! for Gentlemanみたいな大人向けも増えているし、そちら方面に舵切っている感は感じていたけど、コスメもだしてくるのかー。
強く押される要素だと思うので、アニメやゲームとどうかかわってくるのか。
CD売上だけのファクターでみると売り上げが下がっていたので、実はもうシリーズ終わりなんじゃ……と思っていたのでうれしい限り。
プリティシリーズも4月から新シリーズだし、ここから売り上げがどう変わってくるのか楽しみではある。
アジャイル開発のバッドパターン
podchastを聴いていたら、アジャイルでもなんでもバッドパターンはあまり書かれないみたいな話があったので、俺が遭遇したバッドパターンを書いておく。 speakerdeck.com podcastでこの人の話聞くとホントどうかしているわこの人って思う(褒めてる)。 ちなみにそのとき俺がやっていたのは、データレイク基盤実装のプロジェクトで、連携元との結合部のフレームワークを作っていた。 毎日チーム朝会をやっていたので、スクラム型になるのかな? そのときに俺が思っていたことをメモしておく。
チーム間での認識齟齬と技術不足で足並みがそろわない
根本的な原因はとにかくここ。 とにかくチーム間、チーム内の連携が取れておらず、 +チーム間で個別で話し合ったことが共有されない +チーム間で話し合った内容と結果が違う、それに気づけない +チーム間の細かい状況がブラックボックス 実装だけの話ではなく、そもそもこのプロジェクト自体の根本的な問題もここのような気がする。
チーム間で個別で話し合ったことが共有されない
当人同士の秘密になってしまうやつ。 チーム間で個別で話した内容が共有されず、話した当人の個人チャットや会話で完結してしまうのでなぜそうなったのか当人しかわからない。 当人しかわからないことが正だと周りは認識して作業を進めていくので、ずれが大きくなる。 実際あったのは中のpropaty設定の実装が異なるときに、「個別でチャットしたときに認識合わせたんですけど、向こう忘れてしまったのかな」みたいな。 それってチャットの中で完結してよかったの? 相手方チームと自分が他チームと共有しなくてよかったの? 短いスパンで小さく作っていくというアジャイルの特性上、スピード感もって作業するというのは正しい動きだと思っている。 ただ自分の作業タイミングと相手の作業タイミングは必ずしも一致しない。 なので相手が振り返られるようにしてあげるというのは意識してやらないと、認識のずれがおきてしまうんじゃないかなあと。 俺は手間だけど必ずみんなの目につくところに書くようにしていて、ウォーターフォール型でも開発手法関係なく認識はあわないし、認識あっていてもダメ押しておいたほうが幸せになれるという今までの経験から。 口頭で話して実際に文字や絵で伝えると、実は認識ずれているパターンもあるので。
チーム間で話し合った内容と結果が違う、それに気づけない
技術的な都合による修正が勝手に行われているやつ。 この時も当然最初にこういうルールにしましょうね、なミーティングをやっていたんだけど、いざ実装し始めると技術的に難しいという面がある。 そのときに勝手にやってしまうということが大きく実装内容が乖離するきっかけになったと思う。 具体例としては、既存のOSSを使って今回のプロジェクトのフレームワークを作ろうとしていたんだけど、OSS側の理解度からOSS全く使用しないチームがではじめてきて同じフレームワークなのに全く違うものが完成してしまった。 めちゃめちゃ素振りして理解した人に質問したらよかったのに、しなかったばっかりに発生した事象。 逆にめちゃくちゃ素振りしていた人も知ってますアピールをしてなかったので、確認できなかったというのもある。
チーム間の細かい状況がブラックボックス
なんかよくわからないけどなにかやってるやつ。 同じフレームワーク作ろうねって言っているのに、始まるとチームごとの独自文化が形成されてしまっているパターン。 互いに知っているのは各チームごとの大きいスケジュールで、実装のものすごい詳細な観点までは見れていない。 独自文化が形成されるのは、なんというか仕方のないことではあると思っている。経験上、独自文化形成しちゃうし。 それをどう回避するって横断的に立つようにすることを心掛けるしかない。 俺はプロジェクトで他チーム間横断していることが多いので、経験上あれ?って思うことも多いんだけど、まあそういうもんかで握りつぶすところもあって後々あれって思ったところで揉めるパターンが多いような気がする。 互いに気軽にどんな感じなのかちらっとソース眺めたり、雑談で話しやすい関係性であったり、そういう小さいレベルで防げるやつなのかもしれない。
修正タイミングが結合テスト中でデグレ障害が頻発
この話の一番やばいところ。修正タイミングがすごい悪かった。 そもそも発見が結合テストがスタートする前の作業的には谷から山に差し掛かろうかというところ。 設計見直しから入らざるを得ないものの、もう日程的に修正するタイミングがほぼない。 だがやるしかない、な逃げられない状態で修正したからかテストユニットを回してなかったとかで、結合テストで開発起因のバグが出て地獄。 また設計見直しでリファクタリングもってなったけど、ここ修正する意味ある?みたいなのもあった。 リファクタリングでこれ実装難易度が高いし期間的に難しくない?てかそもそもそれやって誰が幸せになるんだろう。みたいなやつ。 技術的負債はなくならないのでどこかでつぶさなきゃいけないけど、タイミングと粒度を見誤ると技術的負債から生まれた新しい負債につぶされる。 早めに負債に気付けることが重要だけど、突然の死!を迎えるまで気づかないのも事実だよなあと。 上記の細かい気付きをやっていけば防げていたのかもしれない。
俺が感じたこと
俺が思ったのは実際、開発手法がどうこうってあまり関係ないんだよなあってこと。 絵なり文字なりで事前に認識をしっかり合わせて足並みそろえたり、状況はしっかり共有したり、雑談で進捗どうですかな話をしとくとか、ごくごく当たり前のことで詰まっていた気がする。
2017年の振り返りと2018年の目標
2017年の振り返り
全体的な話をまずすると、体調面や仕事面であまりいい年ではなかった。大きな出来事だと、家を建てたことかなー。家族も増え住んでいたマンションでは手狭になってきたので。
仕事
昇進しなかった
個人的に頑張ったという認識だったし、プロジェクト評価も良かったので、この結果はかなりショックだった。もはや愚痴しかない。
理由が業務的には問題ないが、採用活動等の社内イベントのお手伝いをしなかったからという、もはやプロジェクト活動外のことがボトルネックになっていて呆気に取られたというか、何言ってるのかよく分からなかった。
そもそもで昇進するかジャッジ決めのメンバーの中で俺のことを良く思っていない人もいるそうで、なんと言うか絶望感凄い。
もうこの会社も抜け時かなって思ったが、懇意にしている上司にもう1年やろうと説得されたので頑張ることにする。
基礎力を鍛える
基礎力が足りてないって思うことが最近増えてきて、それに起因する考慮ミスも出始めてきた。今まで何となくかわしてきたことのツケを支払わなければならないと数年前から思っていて、思っていただけだったがやっと今年から着手するようになった。
やっぱ俺の今の年で基礎的な、CPU、メモリ、OSっていうハードからって大分恥ずかしいんだけど、知らなかったんだからしょうがない。
応用情報のシラバスに沿うのが一番体系的だったので、取得を目指しながら応用情報よりももう少し深く理解していくように勉強していた。
試験はまあ落ちたんだけど、これで落ちたらしゃーないかなーって思っていたので、次頑張ることにする。
アルハラで揉めた
クソ面倒くさい案件。まさか自分が被害者になるとは思っていなかったので、親しき仲にも礼儀ありやぞと。そのプロジェクトはちょっと前に離任していて、再オファーもあったんだけどそりゃあ断るよね。
プライベート
「アイカツ!」関連のイベントに参加できた
タイミングよく出張が重なってイベントに参加できることが多かった。- 3月25日「アイカツ!ミュージックフェスタ2017」(神奈川)
- 7月23日『オールアイカツスターズ!DJ LIVE JAPAN TOUR』(東京)
- 9月30日『オールアイカツスターズ!DJ LIVE JAPAN TOUR』(北海道)
これ以外ではディアステージのイベントにも行ったりして、「アイカツ!」から広がって、面白いこと見つけたなあという感じ。
リターンが乏しいだろう北海道ではなかなかイベントやらないのが悲しい。参加するのでやって!
「アイカツ!」系の分析がやれた
ラジオ番組とCD売り上げの分析だけど6本上げられた。http://snofra.hatenablog.com/entry/2017/04/15/144333
ラジカツスターズ!のコーナーのメンバー別正解数を図で確認する - すのふら
アイカツ!シリーズのCD売上から見えてくるもの - すのふら
本当に『アイカツ!』は『プリパラ』に負けたのか? - すのふら
python普段使っているけど、俺がやっている仕事とは全然違う分析系なので斬新で面白かった。
分析観点持ってないなーと思うことがやっぱり多いので書籍や他の人の分析手法真似してパターン増やしていく必要がある。
体調が悪かった
1年を通してどこか具合が悪かったり、骨折したりして体調が悪い年だった。併せて家族の体調も良くなく、子供が入院したり、年の瀬の12月30日に傷が残る程度の怪我をしたりと散々だった。
2018年の抱負
ぶっちゃけ社内評価は絶望的なので、自身の市場評価を確認して、どこに立っているのかを見定めたい。得た知見は(できれば「アイカツ!」に絡ませて)アウトプットしていきたい。
そのためにはまずPCを買おう。スマホポチポチは結構きつい。
仕事
基礎力を鍛える
これは2017年から引き続きやっていきたい。応用情報に落ちたというのもあるけど、勉強していることと業務をもっと関連性を持たせながら理解していくことで成長余地を探したい。
また、直近でSQL周りでパフォーマンス等求められたりするので、そこもベースの知識をしっかりとつけるために再入門したい。
資格を4つ取得する
これは自分の価値を高めるために必要かなと思っている。転職する予定もあるので。とりあえず、以下2つは確定なんだけど、他は何にするべきか。
一応バックエンドエンジニアを目指そうとしているので、できればネットワーク系の資格が欲しい。
- 応用情報
- AWS 認定ソリューションアーキテクト – アソシエイト
新しい言語を勉強する
直近で書籍を持っていて、業務の幅が広がりそうなscalaかなー。java未経験者なので、そこのビハインドをどれだけカバーできるかってのがあるかもしれないけどやるだけやってみようかなと。
勉強会に参加する
これも自分の価値をはかるという要素に近いんだけど、自分の会社以外ではどういうことをやっているのか、自分はどの程度の立ち居地にいるのか見ておきたいなあと。服屋に行く服を探すじゃないけど、まずはPC買うところからっていうね。
プライベート
「アイカツ!」好きの知り合いを増やす
基本ぼっちなんですわ。イベント開始終了で楽しそうに話しているのを見ていると、まあ悲しいこと。
共有できる人を探したいなあと。
そういうのってどうやって探すもんなんですかね?
体力をつける
体重が増えてきたってのもそうなんだけど、運動していないので体力が凄い落ちてきているのをひしひしと感じる。仕事していてもここ山場だから頑張ろうって時に頑張れなかったりするので、水泳なりジムなり行って体力をつけたい。
とりあえず最寄のプールに行くところから始める。
「アイカツ!」系の分析をもっとやる
俺が「アイカツ!」にできることはイベントやゲーム、グッズで金を落とすことと、分析して公開していくことなので引き続きやっていきたい。あまりバズることのないブログだけど、何本かバズるのを目標にする。
ブログへのアウトプット
月1本やればよい、くらいだったので月2本くらいのペースでやっていきたい。そのためには技術よりの内容とブログ分けないほうがいいのかなって思うし、分析じゃなきゃダメだという観点も変えるべきかなと。
シシララTVの『センチメンタルグラフティ』実況からの懐かしさよ
人には自身の人生を語る上で必ず言わなきゃいけないゲームがある(と思う)。
それが神ゲーだったり、クソゲーや奇ゲーだったりするんだけど、大体そんな外的なカテゴライズなんて全然どうでもいいわけ。
俺にとってはそれが『センチメンタルグラフティ』だったりする。
これがなければ俺はきっと元気系が好きということがDNAに刻まれることはなかっただろうし*1、
クリスマスに『シスター・プリンセス RePure』の最終回をひとりで見ることもなかっただろうし、
「アイマス」「ラブライブ」「プリキュア」「アイカツ」といい感じなおっさんになることもなかったはず。多分。
結果的に自分の子供に『センチメンタルグラフティ』のキャラ名をつけていた、なんてこともなかったはずなんや!
そんな無意識的に刷り込まれているゲームではあるんだけど、つい最近『センチメンタルグラフティ』の実況が最終回を迎えた。
動画
シシララTVというゲーム系のサイトの実況動画。ニコ生とAbema freshとであるんだが、見てたのがAbema freshだったのでそっち版。
freshlive.tv
最終回はゲームライターのカワチさんのアドリブのキモさを堪能する回。
『センチメンタルグラフティ』をざっくり
『センチメンタルグラフティ』は1998年1月22日に発売。今年で20周年。ざっくり内容を説明すると、幼少の頃から転向を繰り返していた主人公。
全国に散らばっている12人のヒロインの誰かから手紙を貰ったので、過去を振り返りながら女の子に会いに行くギャルゲー。
今考えるとぶっ飛んだ設定だよなー。*2
実況のざっくり
この実況は20周年ということで七瀬優役の西口有香さんとプレイする番組なんだけど、生アフレコが聞けるのがかなりレア。当時の話が聞けたりしてリアルタイムでやっていた俺にとってはかなり感慨深い。
6回目放送では全キャラのアフレコもしてくれるので、ホントありがてえ。
実況は一応七瀬優のベストエンディングを目指すのが目的。
ミステリアスキャラ。主人公と過ごした時間が一番短い。
唯一水着イベントがない!
だけど、この実況には2人の刺客がいて、
1人目が青森の安達妙子。
MCのゲームライター、タタツグさん一押しキャラ。
とても家庭的。「だぞっ」って言うところ、いいよね。
最後の最後まで、優とどちらにするのかネタで揺れに揺れたりそんなやり取りが終始する。
そして2人目。
このゲームといえばというキャラ、仙台の永倉えみる*3。
これだけで大体どんなキャラか分かるとは思うけど、彼女が高エンカウントで、あらゆるタイミングで出没。
正直攻略対象の七瀬優よりも登場回数が多い*4。
監視されているんじゃないか?
実況を見て
俺もほぼ20年ぶりに見たんだが、あのころから変わらず大阪の森井夏穂推しは変わらなかったので、DNAに完全に刷り込まれていると言っていい。そして20年経って、ようやく福岡の松岡千恵の魅力に気づきました。
このちょいちょい見せる女の子感すごいいです。
ラジカツスターズ!のコーナー正解率を分析する
これはアイカツ! Advent Calendar 2017の8日目の記事です。
『アイカツスターズ!』の歌唱担当であるAIKATSU☆STARS!の歌い手さんたちがやっているラジオ『ラジカツスターズ!』について書きます。
『ラジカツスターズ!』はメンバーの中から2~7人(だいたい2人)が交代でパーソナリティをしている番組。
2016年4月からスタートしてもうかれこれ1年8か月。結構長く続いている。
その中でもパーソナルなところが見えるというか、主にるかのポンコツさを見ることができるのが『私達、AIKATSU☆STARS!です!!スターズ!!!』というコーナー。
このコーナーはひとつの質問に対してメンバーが回答を合わせてるという趣旨のもの。
正解すると「スターズポイント」を1ポイントゲットでき、それが貯まると何かご褒美と交換してもらえる。
今回はこの『私達、AIKATSU☆STARS!です!!スターズ!!!』の回答率について分析していこうと思う。
条件
- 問題数及び正解数は、2017年12月4日放送分の第87回までとする
- 第64回放送(2017年6月26日)は欠損しているため、問題数正解数0として計算*1
- コーナー自体やっていない場合(初回やゲスト回など)は問題数正解数0とする
- この分析は「スターズポイント」ではなく「正解数」の分析とする。(スターズポイントだと第54回(2017年4月17日)でボーナス+2ポイントゲットしている)
全体
100問正解まであともう少し
まず累計正解数が100になるのはいつなのかというところを見てみる。<放送回数と累計正解数>○が累計の正解数。☆が100問正解だろうと思われる放送回。
見てみようと思ったらと既に第87回で97問正解してた。ちょっと微妙な予測に……。
線形回帰で多分このくらいには100問できるんじゃないかっていうのを見ると第89回なので、来週か再来週で達成可能だと思う。
欠損している第64回を考慮しても、最低でも2017年中に達成できるんじゃないかと。
今年の残3回がすべて珍回答でメンバーとリスナーの度肝を抜く、るかだった場合は、来年まで持ち越しになるだろうなあ。
累計正解率は30パーセントを維持
次にこのコーナー自体の1回ごとの問題数と正解数、累計正解率を見る。
<累計正解率と各放送回毎問題/正解数>
縦棒グラフの青が問題数。オレンジが正解数。
折れ線が累計正解率。
まずは1回ごとの問題数と正解数。
縦棒グラフで設定がされていないように見えるのはそもそもこのコーナーをやっていない(欠損している第64回)ため。
これをみると0問正解で終了するのが30回までに多いという点。
これは序盤のパーソナリティが3人以上だったからだと思われる。
第23回放送(2016年9月12日)から2人体制になったので、安定――あんましてないっすねw
30回までで正解数0のときのパーソナリティをみると、るかが一番多いのでそれが原因か?
また、正解数の最高が4回なので、簡単な問題または、パーソナリティの周波数があったとしても正解が合うのは4問までということが分かる。
次に累計正解率。
これをみると大体30パーセントあたりを維持していて、直近回の第87回までを見てもこの正解率が大きく変わることはないのかなと。
だいたい1回の放送で問題数が3問程度なので、最低1問は必ず正解できているということが分かる。
これも、るか連投で平気で下がるので、連投した結果どのくらい低下するのかは気になるところw
メンバー別
メンバー別の累計問題数と正解数、正解率を見てみる。
<メンバー別累計問題数/正解数/正解率>
縦棒グラフの青が問題数。オレンジが正解数。
折れ線グラフが正解率。
正解率を見ると圧倒的るかが低いってわかるんだが、ランキングにしてみる。
計算方法は各メンバー別の正解数/問題数。
ランキングトップはみほ。
ラジオではみほの正解率が低い判断されていたりしてたんだけど、俺が見る限り、みほは常に安定して正解できている印象が強いので想定通りの結果。
続いてほぼ同正解率でせなりえが続く。
せなは正解数はメンバーの中でトップなんだけど、問題数もトップなので結果みほより正解率を上げることはできなかった。
最下位はるか
まあこれは約束されてますよねw
るかの回答はちょっとずれているというか、ちょっとどうかしているものが多い。
直近だと「ハロウィンの仮装といえば」という質問に「蜂」と答えたり(第82回)、
「お味噌汁の具の定番といえば」という質問に「味噌」と答えたり(第85回)、
よくある回答にしようと自分から言っておいて「猫によく付ける名前といえば」に「ねこ子」と自分が付けるとしたらという回答をしたりとホントとうかしてるw*2
メンバー個別
るかみき
かな
みほ
ななせ
せな
りえ
メンバー別問題数/正解数
最後に
pythonでグラフを作成しているんだけど、ソース部分は別のところで書いてます。snofra-tech.hatenablog.com
dir(cls)は何をしているんだ
Luigiという公式に某配管工の弟なフロー制御フレームワークの実装を読む日々。つらみ。
そもそもLuigiとはなんぞや?の場合、以下を読むとなんとなくイメージつくかもです。 https://qiita.com/colspan/items/453aeec7f4f420b91241qiita.com
読んでいくときにこれ何やってるんだろ?と思うことしかないんだが、 1点、dir(cls)はなにやってるんだ?ってところを調べたのでメモしておく。
端的に言うと、dir(cls)で対象モジュール内の変数とか関数とかの名前(メンバ)を返すことができる。
指定したモジュールやクラス、インスタンスなどの名前空間の名前一覧を返す関数である。
もし引数を省略した場合は現在のスコープの名前一覧を返す。
これを使用すれば、モジュールに含まれたクラスの名前や、クラス内のメンバの名前を調べることができる。
魔術師見習いのノート
上記サイトの例だと
import sys dir(sys)
['__displayhook__', '__doc__', '__excepthook__', '__interactivehook__', '__loader__', '__name__', '__package__', '__spec__', '__stderr__', '__stdin__', '__stdout__', '_clear_type_cache', '_current_frames', '_debugmallocstats', '_getframe', '_home', '_mercurial', '_xoptions', 'api_version', 'argv', 'base_exec_prefix', 'base_prefix', 'builtin_module_names', 'byteorder', 'call_tracing', 'callstats', 'copyright', 'displayhook', 'dllhandle', 'dont_write_bytecode', 'exc_info', 'excepthook', 'exec_prefix', 'executable', 'exit', 'flags', 'float_info', 'float_repr_style', 'get_coroutine_wrapper', 'getallocatedblocks', 'getcheckinterval', 'getdefaultencoding', 'getfilesystemencoding', 'getprofile', 'getrecursionlimit', 'getrefcount', 'getsizeof', 'getswitchinterval', 'gettrace', 'getwindowsversion', 'hash_info', 'hexversion', 'implementation', 'int_info', 'intern', 'is_finalizing', 'last_traceback', 'last_type', 'last_value', 'maxsize', 'maxunicode', 'meta_path', 'modules', 'path', 'path_hooks', 'path_importer_cache', 'platform', 'prefix', 'ps1', 'ps2', 'ps3', 'set_coroutine_wrapper', 'setcheckinterval', 'setprofile', 'setrecursionlimit', 'setswitchinterval', 'settrace', 'stderr', 'stdin', 'stdout', 'thread_info', 'version', 'version_info', 'warnoptions', 'winver']
こんな感じでsysの中に存在している名前を見ることができる。
でもって、Luigiの中の該当処理はっていうと、
task.py
from luigi import parameter from luigi.task_register import Register ・ ・ ・ Parameter = parameter.Parameter @classmethod def get_params(cls): """ Returns all of the Parameters for this Task. """ # We want to do this here and not at class instantiation, or else there is no room to extend classes dynamically params = [] for param_name in dir(cls): param_obj = getattr(cls, param_name) if not isinstance(param_obj, Parameter): continue params.append((param_name, param_obj)) # The order the parameters are created matters. See Parameter class params.sort(key=lambda t: t[1]._counter) return params
for param_name in dir(cls):
でcls内のメンバ分ループを実行する。
param_obj = getattr(cls, param_name)
でparam_nameの属性を代入する。
f not isinstance(param_obj, Parameter):
で属性が、Luigi.Parameter
ではない場合次行。
ってな感じ。