  |
はてなキーワード: defとは
抽象に依存するってことなんだよね。発想が抽象的でむずかしい。
以下に示すbeforeコードの欠点は、IOに関係する部分とビジネスロジック(誇張)が密結合していることで、このメソッドを変更する理由が複数存在している点である。(単一責任の原則に違反)
変更理由は、IOにnullが入ってくることを考慮するとか、暗号化アルゴリズムを変更するあたりがぱっと浮かんだ。
afterのコードは、readerとwriterを引数から受け取れるようになっていて、インターフェースに依存するようになって、単一責任の原則を守るようになった。
```
# before
def encrypt
end
end
# after
end
end
```
まとめ
「パートIII.Dで、当財団は、ダイムラーが使用した違法操作機器の運用にかかる委託研究について説明する。 ••••••（以下：••••••）が実施したこの調査では、これまで他の利益団体や当局が使用していない根本的に異なる方法論を採用した。端的にいえば、当財団が購入したEuro 6 Test Vehicleでテスト走行を行い、エンジンと排気ガス管理を制御するECU（Electronical Control Unit）から走行中の情報を読み取ったのである。これにより当財団は、試験車両の違法操作機器の根本的なメカニズムと機能を初めて洞察する者となった。本調査により当財団が同定できる限り、少なくとも8つの違法（SCRおよびEGR）操作機器が配備された、驚異的に複雑で洗練された排出詐欺が明らかになった。これらの違法操作機器はそれぞれ、実際の運転条件でシステム全体の効率を大幅に低下させる。ダイムラーのトリックの結果として、これらの違法操作機器はNEDCテストサイクル外でのみ動作する。」
「III.B.1. 序文
255. このセクションでは、当財団は、排出規制および適用される判例法に基づいて、違法操作機器の特性について説明する。 前述のとおり、当財団はとりわけ、2020年4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見※に特に注意を払っている。（図14を参照）。」
※「2020年4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見」はこちら。↓
"Court of Justice of the European Union PRESS RELEASE No 52/20
Luxembourg, 30 April 2020
Advocate General’s Opinion in Case C-693/18CLCV and Others (defeat device on a diesel engine)
According to Advocate General Sharpston, a device that adjusts upwards the operation of the emission control system of diesel engine vehicles during the approval testing of those vehicles is a ‘defeat device’prohibited by EU law
The objective of slowing down the aging or the clogging-up of the enginedoes not justify the use of such a device"
https://curia.europa.eu/jcms/upload/docs/application/pdf/2020-04/cp200052en.pdf
III.D.1. イントロダクション、研究の関連性、および主要な調査結果
295. このセクションでは、当財団の研究結果について論ずる。 この研究は、その方法論によって、上で説明した研究※とは区別される。 前述のように、この研究は、入力値（周囲温度や車速など）と出力値（PEMSで測定された排出量）を測定するのみならず、ECU自体の内部機能を測定することを目的とする。 テスト中にECUから直接情報を読み取ることにより、ECUの設計と操作を再構築可能である。」
※直前のIII.C で、第三者が公表した調査結果を挙げている。
「296.このアプローチは、概ねメーカーのソースコードがなければ違法操作機器の動作を検出および分析することは不可能であると考えられていることから、これまでどの型式承認当局・関連団体にも採用されていない。間違いなく可能であるとはいえ、費用と時間がかかり、専門知識を用いねばならない。この理由もあって、当財団はこれまでのところ、この研究を単一のテスト車両（本テスト車両）に限定している。本テスト車両は、第306項でさらに指定されているユーロ6対応型メルセデスE350である。モダンなユーロ6車両を選択する理由は、この車両タイプに、EGR（排気ガス再循環）とSCR（選択的触媒反応）の組み合わせからなる高度で複雑な排出制御システムが装備されているためである。このような複合システムでは、SCRシステムが処理の大半を引き継ぐため、EGRシステムはNOx排気負荷を減らすために「ハード」に動作しなくてもよくなる。 Euro 6モデルのECUソフトウェアはEuro 5ソフトウェアの拡張バージョンであるため、以前のバージョンの多くの機能がまだソフトウェアに存在している。調査が示すように、本テスト車両のECUには、機能しているEGR操作機器も多数含まれている。この点で、本研究結果は、EGR装置のみが装備されていた古いメルセデスベンツモデルにも関連している。
297. 要するに、この調査により、SCRとEGRの違法操作機器の範囲が特定された。これらはそれぞれ、特定の条件下でシステムの全体的な効率を大幅に低下させ、これによりSCR触媒コンバーターはほとんどの条件で動作容量のうち最大で60％に制限されることとなる。」
「300. 本調査の結果、違法なSCRおよびEGR操作機器は、NEDC検査下の状況では動作せず、通常の使用状況でのみ動作するようにプログラムされていることが判明した。 違法操作機器は、条件がNEDC検査条件から少しでも逸脱している場合にアクティブになることがわかっている。 さらに、SCR関連のいくつかの違法操作機器には、車両が数か月間使用された後にのみ違法操作機器を操作するように設定されたタイマー機能があり、NEDC検査を確実に通るようになっている。」
「302. 本調査はまた、これらの違法操作ツールのほとんどがソフトウェアの更新後にテスト車両から削除されたことを示している。これは、エンジンの損傷を防止したり、車両の安全な動作を確保したりするために違法操作ツールが必要ないことを意味している。このソフトウェアの更新によって、テスト車両のすべての違法操作機器が実際に削除されたかどうかは明らかではない。……」
III.D.2.a）はじめに
305. 本調査で使用されるメソドロジーは、データ収集、ソフトウェア分析、およびテスト車両から生れたテスト結果の解釈とを、組み合わせることである。306. 前述のように、本テスト車両は、メルセデスベンツ E 350 BlueTEC 4 MATIC Tであり、OM 642型 190 Kw、2987 ccm、6気筒エンジンを搭載している。本テスト車両の検査文書のコピーを別紙57に提示した。……
307. ECUの情報チャネルは複雑で量が多いため（ECUは内部で10,000を超える信号を処理）、イテラティブなプロセスを用いた。 最初のフェーズでは、通常使用中に車両のECUのプロファイルを作成するために、広範なデータ収集が行われた。 排出制御に関連するソフトウェアとデータは、ソフトウェア分析を使用して特定した。 その後、データ収集プロセスをさらに洗練し、より詳細なデータを得た。」
308. 調査中のデータ収集は、OBD-2ポートを使用して実行した。……」
「310.前述のように、ECUソフトウェアのソースコードや完全なドキュメントについては、ダイムラーがその情報を慎重に管理しているために、本調査者はこれらを得ていない。 ただし、ドキュメントやソースコードが利用できないソフトウェアの分析については多くの研究があり、そのような分析はIT業界で定期的に行われている。研究者は、「逆アセンブル」（ソフトウェアが人間が読める形式に変換される）やソフトウェアシミュレーションなどのいわゆるリバースエンジニアリング手法を使用している。 これらの手法により、ソースコードが利用できない文書化されていないソフトウェアの分析が可能になり、本テスト車両のECUソフトウェアの分析にも使用されている。」
315. 本SCRシステムでは、主な制御変数の1つはAdBlueまたはDEF（ディーゼル排気流体）の投与量である。本テスト車両のECU、Bosch EDC17CP57 は、システムに投与されたAdBlueの量を計算する。 SCR触媒コンバーター内で、AdBlueはアンモニアに変換され、次にアンモニアがNOxと酸素と反応して窒素と水に変換される。
316.有効性の尺度は、「SCR除去効率」または「変換効率」である。 SCRの潜在的な効率は、以下を含む多くの物理的条件によって制限される場合がある。
317. 以上のリストは完全なものではないが、適切に機能しているSCRシステムが物理的な制限を受けていることを示している。 これらの制限に対処するために、本ECUソフトウェアには、2つの異なる動作モードが含まれている。
318.最初のモードは、以下「アンモニア負荷モデル」と呼ぶもので、SCRシステムが完全に機能するモードである。 このモードは公的にアクセス可能なメディアでは説明されておらず、この用語自体は文献で使用されている標準ではないことに注意されたい。
319. 2番目のモードは「代替モデル」である。 これは、不正な操作ツールによってアクティブ化されるモードである。 代替モデルがいずれかの操作ツールによってアクティブ化されると、通常SCRは最大60％となる。 特にいくつかの違法操作ツールが同時にアクティブ化されている場合は、効率が大幅に低下する可能性もある。……」
330. 本調査による観察結果の要点は、代替モデルでは、実際の運転条件のほとんどで、SCRシステムのターゲット効率が比較的低い値に保たれるが、これは物理的な制限に基づいていない要因やポリシーの選択によって生じているため、 違法だということである。 言い換えると、SCR触媒でのNOxの還元に直接影響を与えることがない入力に応じて、効率目標が意図的に低い値に低減される。 したがって、これらの要素とポリシーの選択、およびそれらが有効にするメカニズムは、違法な操作手段と見なすことができる。
331. これらの違法なSCR関連の操作ツールは、以下の機能を共有する：
（i）それらは、温度、排気ガスの質量流量といった、極端な条件下で一般的に制御する必要がある物理的特性に応答する。
（ii）ただしそれらは、通常の「実際の」運転条件では、システマティックにアクティべートされる。
（iii）それらは、たとえば、正当化されないヒステリシスを使用することにより、アクティベート後に、ある効果が出るように設計されている。
簡単に言えば、ヒステリシスという用語は、新しい状態への切り替えを引き起こす値と元の状態への戻りを引き起こす値との間に特定の「範囲」がある状態を表す。一般的な例は、特定の温度で加熱がオンになるサーモスタットで、温度が初期値よりも数度低い場合にのみオフになることで、システムのオンとオフが連続して行われないようになっている。今回のケースでいうと、ヒステリシスは、元の状態（この場合は「アンモニア負荷モデル」）に切り替えるしきい値が「代替モデル」が動き出す状態に切り替えるレベルよりもかなり低い（または高い）場合に発生する; そして
（iv）それらはSCRシステムの目標効率を大幅に低下させ、AdBlueの投与を大幅に削減する。これにより、NOx排出量が大幅かつ大幅に増加する。
332. 本調査の結果、8個以上の違法操作機器が発見されたが、そのうち6個はSCRシステム（およびAdBlueの投与量）に関連している。……」
「III.D.4.a）SCR操作ツール1：排気ガスの質量流量
335. 最初の違法SCR操作機器は、SCR触媒コンバーターを通過する排気ガスの体積（排気ガスの質量流量）を参照する。
336. 上述したように、排気ガスの質量流量がSCR触媒の処理能力よりも大きい場合、排気ガスはSCR触媒から逃げることができ、NOxチャージを減らす機会が与えられないこととなる。 これに対処しないと、SCR効率の過大評価につながり、AdBlueのオーバードーズにつながる可能性がある。 このことで、SCR触媒がアンモニアでオーバーフィルされ、アンモニアのスリップが発生する可能性がある。 したがって、質量流量を監視し、過剰なマスフローが通知されたときにSCRのターゲット効率の推定値を下げることは、原則として、有効なストラテジーになる可能性がある。
337. ただし、テスト車両では、フィルタ後の排気ガスの質量流量の制限は、時速170 kgに設定されており、これは、実際の運転状況では約100 km / hに相当する。 このしきい値は、技術的な観点から見て、言い訳けができないほど低くなっている。 このしきい値を超えるとすぐに、ECUは代替モデルに切り替える。 さらに、（-80 kg / hの）強いヒステリシスが適用されるため、負荷モデルに切り替える場合、質量流量は90 kg / h未満でなければならない。 60 km / h程度の低速でも、このしきい値は日常的に超過している。 さらに、エンジンが一定している場合、短時間では負荷モデルに戻らない。
338. この制限は、正確には、SCRシステムの「エージングファクター」によって決まることに注意せよ。この機能に関連して、ECUはSCR触媒コンバーターがその耐用期間中にさらされた温度を記録し、これに基づいて経年変化の影響をモデル化する。ただし、以下のグラフに示すように、この違法操作機器のエージングファクターは、完全な100％（完全に新しい状態）が1％～99％（すなわち実質的に新しい）まで減少するとすぐにアクティブになるように設定されている。すでにその時点で、上限は時速200 kgから時速170 kg へ削減され、下限（ヒステリシス）は時速120 kg / hから時速80 kg / hに削減されている。 NEDC検査は完全に新しい車両で行われるため、輸入検査でこの違法操作デバイスを検出できないと推定できるのである。これに対し、本テスト車両はこれらの観測の時点で70,000マイル走行しており、ソフトウェアは69％のSCRエージングファクターを示していた。」
PS4の『The Last of Us 2』が事前のメタスコア大絶賛一色とは一転していざ発売されると前作ユーザーから賛否両論となりユーザースコアが激低で結果的に主要サイトの中でほぼ唯一批判的に評価していた日本のIGN Japanのレビューが海外ユーザーから再評価される怪現象が起きている。
2020年6月19日に発売されたPS4用ゲーム『The Last of Us Part II』。日本では「ラスアス2」、海外では「TLOU2」と略されることが多い。ソニー・インタラクティブエンタテインメント (SIE) のファーストパーティー（傘下スタジオ）であるノーティドッグ (Naughty Dog) が開発を担当し、SIEより発売された。アメリカのヴァージニア州に本拠地を置くノーティドッグは、『クラッシュバンディクー』シリーズや『ジャック×ダクスター』シリーズ、そして近年では『アンチャーテッド』シリーズによって知られている開発会社であり、2001年よりSIEの傘下スタジオとなっている。
前作『The Last of Us』は2013年にPS3で発売され、2014年にはPS4でリマスター版が発売された。PS3版とPS4版を合わせると現在までに約2000万本以上を売り上げている。メタスコアでは95点を獲得し、数え切れないほどのメディアによって表彰された（ https://en.wikipedia.org/wiki/List_of_accolades_received_by_The_Last_of_Us ）。
ゲームのジャンルとしては三人称視点のアクションアドベンチャーであり、サバイバル、ホラー、ステルス、シューターといった要素を含む。プレイヤーは成人男性のジョエルと少女のエリーを操作し、ゾンビがはびこる終末的世界を生き延びるために冒険を繰り広げる。オープンワールドではなくリニア（一本道）ではあるが、開発チームが「ワイドリニア」と呼ぶ自由度の高いリニアな空間は、開発者の企図した凝ったゲーム体験とプレイヤーの自由な探索という相反するゲーム性をバランス良く両立させるものである。
Metacritic（メタクリティック）というレビュー収集サイトによって、主要ゲームサイトのゲームレビューの点数を収集、平均したもの、それが「メタスコア」であり、それとは別にユーザーが投稿した点数を平均したものが「ユーザースコア」である。
Metacriticは1999年に映画レビューサイトとして始まり、その後サイトの評価収集対象にビデオゲームを加えた。メタスコアは現在では世界で最も重要視されるゲームの評価基準のひとつとなっている。単純にいえば、あるゲームに100点をつけたレビューサイトと60点をつけたレビューサイトがあれば、それらを平均した80点がそのゲームのメタスコアとなる（実際にはメディアごとに重要度というものが設定されており、その重み付けを反映してスコアが計算されるため、もう少しややこしい）。
『The Last of Us Part II』は世界各国のメディアによるレビューで絶賛され、2020年6月20日10時（JST）時点では94件のレビューを平均して95点という非常な高評価を受けた。過半数を越える実に50件ものレビューが同作に100点満点を与えている。
このメタスコアは2020年に発売されたゲームのなかで最高評価であり、その下には同じく95点の『ペルソナ5 ザ・ロイヤル』、93点の『Half-Life: Alyx』、91点の『あつまれ どうぶつの森』などが続く。なお日本のユーザーに馴染みが深いタイトルで言うと、『ファイナルファンタジーVII リメイク』は87点、『仁王2』は85点、『バイオハザード RE:3』は84点である。（ https://www.metacritic.com/browse/games/score/metascore/year/all/filtered ）
PS4タイトル全体の中では、97点の『Red Dead Redemption 2』（2018年）と『グランド・セフト・オートV』（2014年）に次ぐ順位である。（ https://www.metacritic.com/browse/games/score/metascore/all/ps4/filtered?sort=desc&view=detailed ）
しかしその中にあって、日本のIGN Japanは10点満点で7点とやや厳しめの点数をつけている（ 過去との決別で残された物語『The Last of Us Part II』レビュー https://jp.ign.com/the-last-of-us-2/44388/review/the-last-of-us-part-ii ）。レビュアーの福山幸司は前作が「ビデオゲーム史上に残る、マスターピースであることが疑いようがない」とした上で、「残念ながら『The Last of Us Part II』は、前作を超えるどころか、共に並び立つことすら許されないほど、いびつな出来栄えとなってしまった。」と評した。福山が同作に批判的な評価を下している原因は、主にそのストーリー面についてのものだ。Metacriticに収集された94件のレビューのうち、ラスアス2にIGN Japanと同程度またはそれ以下の評価を与えているメディアは、ほかにGAMINGbibleとGame Revolutionだけである。
IGN Japanは6月13日に福山によるレビューを発表し、さらにその翌日には同編集部のクラベ・エスラによる同作のレビューをめぐる分析記事が掲載された（ 世界各国のメディアが『The Last of Us Part II』を大絶賛！ IGN JAPANの評価が激しく異なる理由を紐解く https://jp.ign.com/the-last-of-us-2/44460/news/the-last-of-us-part-ii-ign-japan ）。相反する評価を受けるビッグタイトルは時々あるが、それを分析した記事が投稿されるのは頻繁にあることではなく、それだけラスアス2が注目を集めるタイトルであること、IGN Japanのレビューが異色であったことを示していると言えるだろう。
2020年6月19日にいざゲームが発売されると、ユーザーからはたちまち賛否両論が巻き起こった。議論の的となるのはやはり主にストーリー面についてであり、前作のファンからの批判が多くを占めた。Metacriticのユーザーレビューは、2020年6月20日10時（JST）時点では17984件のレビューを平均して3.3という酷評としか言いようのないスコアになっている。
そして、このような酷評を与えられるにつれ、IGN Japanのレビューが再評価されつつある。興味深いのは、海外のゲーマーの多くが（日本のゲーマーが『ファミ通』のクロスレビューに対して揶揄するのと同様に）多くのメディアの絶賛レビューはメーカーから受け取った金銭によって操作されており信用に値しないと信じ込んでいる点だろう。以下、ツイッターでひっかかった意見の一部。
まおんも@nagineco
MichiruBOSS @N6Gi7
I think one of the best review about Tlou2 is from IGN Japan. If you are interestes, go check it out.
Sublem @DarthSublem
Whooo boy, friend is pissed off at TLOU2, he says it's a PoS because the fucked the story so hard. IGN Japan was right. Gameplay and graphics are great, but the story is complete ass. He told me about the story and ending, and I have to agree. It's basically a big FU to TLOU1
（友人がラスアス2に立腹している。ストーリーがとても酷くて凹んでいるらしい。IGN Japanは正しかった。ゲーム性とグラフィックは素晴らしい、しかしストーリーは本当に最低。彼はストーリーとエンディングについて語ってくれて、私も同意した。今作は基本的に前作に対するFU (Fuck You) だ）
The Last Of Us Part IIを5時間程度プレイしてみたが、IGN Japanのレビューで言いたいことが序盤をプレイしただけで、非常によく伝わってきた。7/10という点数になるかはともかく、賛否両論になるのがほぼ確実なゲーム。クリア時に今の感想を塗りつぶすほどの展開になっていると嬉しいな。
Mashiro@li__xunhuan
#TLOU2
高真剣@scaa315
Rich Price@richprice16
I’m only 3 hours in, but the IGN Japan review of game resonates the most so far. They basically said it’s a good game, but not 10/10. The gameplay is virtually identical to the original, which is 7 years old.
（まだ3時間プレイしただけだが、いまのところIGN Japanのレビューが最も共感できる。基本的には良いゲームだと言えるが、10点満点はない。ゲーム性は7年前のオリジナルとほぼ同じだ。）
Metacritic needs to make it that the Critic Reviews are based on actual critics and not paid off journalists. The only legitimate review on there is from IGN Japan. Even THEY were generous.
（Metacriticは、そのCritic Reviewsが実際の批評家に基づいたものであって報酬を受け取ったジャーナリストによるものではないことを明らかにする必要がある。唯一の正当なレビューはIGN Japanによるものだった。それですらまだ手ぬるい。）
IGN Japan did a better job review this game.
This game is not a masterpiece, is not a 10/10 or 9/10.
I don't care about gay or bi characters, i think that is amazing but the story of this game is a 6/10.
Yes the graphics are amazing but that alone is not what makes a great game.
（IGN Japanはこのゲームレビューで最も良い仕事をした。このゲームはマスターピースではないし、10点満点でも9点でもない。私はゲイやバイのキャラクターは気にしない、それは素晴らしいことだと思うけれど、でもこのストーリーは10点満点で6点だ。）
Sublem @DarthSublem
Friend has, he says the story is dog shit and just takes a shit on TLOU 1.
From what I can tell, IGN Japan was right, and everyone who gave a 10/10 was obviously paid off
（友人は今作のストーリーはラスアス1の上にひりだした犬の糞だと言った。私の知る限りではIGN Japanは正しかったし、10点満点を付けたやつは明らかに金をもらっている）
ラスアス2
まだ半分だけど、俺は苦手
IGNJのレビューも納得だわ...
話が重くて辛いとかじゃなくて単純に話がつまらなくて辛い
#ラスアス2
Ivanhoe20@Ivanhoe20
It means IGN Japan is less biased than IGN USA in terms of criticism
Let me tell you this IGN gave the game a 10/10 and most def is sucking up to ND and sony but IGN japan gave the game a 7/10 and said the story is bad and did not follow the same route as the first one so i wouldn't trust any gaming journalists or company on an honest review
（IGNは10点満点で10点を与え、Naughty Dogとソニーにおもねっているが、IGN Japanは同作に7点を与え、ストーリーは良くなく、前作のようにはなれなかったと言う。だから私はゲームジャーナリストや企業が誠実なレビューをするとは信用できない）
I don't believe to the 100% ratings, I don't believe to 0% ratings either...
IGN Japan gave the game a 70% score, probably what it really deserves.
（私は100点の評価は信じていないし、0点の評価も信じていない……。IGN Japanは本作に70点を付けたが、おそらくそれが実情に近い。）
vεr†rø@DaytimeCurfew
The thing with IGN is that you can pay them for a review. Like almost any "credible" reviewer. IGN Japan tho, thats a realistic review
（IGNについて重要なのは、レビューのために彼らに金銭を支払うことができるということです。ほとんどの「信頼できる」レビュアーと同様に。ING Japanは現実的なレビューだったけれども）
Nemui@Gelzoniansuss
IGN Japan summed that up pretty good there.
Graphics are out of this world. Its beautiful.
But well... new characters only to throw them away.
It seems like they couldn't buy IGN Japan in the end haha
（IGN Japanはかなり上手くまとめている。グラフィックはこの世のものとは思えない。美しい。でも、、、新キャラはそれらを投げ捨ててしまった。結局のところ彼らはIGN Japanを買収できなかったようだ。笑）
わからん。
考えられうる要因としては、ゲーマーの「ポリコレ疲れ」やTroll（荒らし）がある。
前作から引き続き主人公を務める女性主人公エリーは、本作ではレズビアンであることが明らかになり、新キャラクターでバイセクシャルのディーナと接近する。新キャラクターのレブはトランスジェンダーの少年である。今作でメインキャラクターの一人となるアビーは、発売前に誤って噂されていたようなトランスジェンダーの女性ではなく、単に「女性らしさ」がないだけの筋肉質な女性である。ラスアス2のシナリオを手掛けたNaughty Dogのイスラエル系アメリカ人のライターNeil Druckmann（ニール・ドラックマン）は、自身はシスジェンダーの男性であるものの、フェミニスト評論家Anita Sarkeesian（アニータ・サーキシアン）からの影響を公言しており、ジェンダーイコーリティや多様性に配慮したゲーム作りを心がけている。2004年よりNaughty Dogで働く彼は、前作『The Last of Us』や『アンチャーテッド 海賊王と最後の秘宝』のクリエイティブディレクターおよびライターを務めた。
ユーザースコアの世界には、Troll（荒らし）によるreview bomb（レビュー爆弾、レビュー爆撃）というものがある。『Death Stranding』のケースでは、1万8000件以上のユーザーレビューから約6000件以上が削除され、それにより「5.1」だったスコアは「7.3」まで上昇した。有名作の発売の際には、このようなreview bombの存在もまたよくある光景となっている（ レビューサイトが「デス・ストランディング」への「疑わしいユーザー評価」を大量削除してスコアが一気に急上昇 - GIGAZINE https://gigazine.net/news/20191210-removed-death-stranding-suspicious-ratings/ ）。おそらく今回のラスアス2でも、後日いくらかのレビューが削除され、揺り戻しが起こるだろう。
しかしツイッターでの評判などを見る限り、この低評価の原因はTrollによるいたずらだけとは思えない。結局のところ不満を集めるのは、新メインキャラクターのアビーが男性に媚びたところのない政治的に正しい女性キャラクターだったからではなく、前作で辛い旅をともにしてプレイヤーがさんざん感情移入した主人公ジョエルがポッと出のアビーによく確認もされずあっさり射殺され、ジョエルの代わりにそのアビーを長時間にわたってプレイアブルキャラとして操作しなくてはならないというゲームの構造によるもの、それにとっちらかって焦点の定まらないストイーリーラインによるものだろう。
ぼく「こんにちは、ベン。ぼくはWashlet2000。便意はどう？」
面「超いい感じだよ。きみは？」
ぼ「ぼくも超いい感じさ」
面「それはよかった。わたしは部署AのToiletエンジニアで3年目なんだ。社内ツールを作ってるよ。Benki関係のツールで、超クールでExcitingなやつなんだ」
ぼ「それはクールだね」
ぼ「うん。ぼくは経験豊富な自宅警備員で…〇〇で貢献して…リーダー経験が……」
面「Cool（たぶん聴いてない）。じゃ、問題に入ろうか。わたしからの問題はね…」
ぼ「あ、はい」
ぼ「Unkの管理…」
面「そう。Unkってさ、知的生命体でしょ？あれを実現するの。『分裂』もあるから注意して」
ぼ「なるほど。えーと、それはHankeyみたいな普通のUnkだよね。えーとえーと」
面「…」
ぼ「えーと、そうだ、Unicodeとか決まってる？」
面「決まってるよ。U+1F4A9」
ぼ「うーん。じゃあUnkって何を保持したらいい？種類、個数？」
面「いい匂いだね。ここでは簡単のため、そうだね、個数だけにしようか」
ぼ「ならUnkの個数を持つ感じかな」
面「多分そうだね」
ぼ「えーと、そして、『分裂』のときに増える個数、『消滅』したかどうかを返すAPIが要る」
面「うん。あと新しいUnkが産声を上げたときも」
ぼ「そうだね。じゃあ内部的には、分裂した時の増殖個数を計算して、unkで現在の個数を管理する感じかな…」
面「それで行けそう？」
ぼ「待って。それで、APIはdivision()、roar()、isDead()でいい？」
面「うん、そうだね。とりあえずAPIはそれで良いよ」
ぼ「OK。あ、division()でもうそれ以上増えれないときには、どうする？」
面「それもいい匂いだ。そうだね、今の個数を返すようにしようか」
ぼ「あと何かあるかな…」
面「…」
ぼ「Unkだと、大腸菌を表示したり、そこからBenkiにジャンプしたりできるけど…」
面「あとで必要になるかもね」
ぼ「だよね。速度は…当然すべてO(1)でやらないといけない」
面「速いほうがいいね」
ぼ「あとは、えーと、Benkiクリアもあとで付けそうだな。まあこれは簡単か」
面「そうだね」
ぼ「まとめると、Unkの個数を整数のIntで持ち、unkで管理する。division()が呼ばれたら、分裂して、isDead()が呼ばれたら、生存の真偽を返す。分裂時にはroar()を呼び出して、Unkoooooooooo!×(増殖個数分)産声をあげる」
面「それで良さそう？」
ぼ「うーん、多分…なにかあるかな…」
面「『消滅』を何度かしたあと、『分裂』をしたらどうなる？」
ぼ「ん？……あ、だめだ！そうか、『消滅』『消滅』『分裂』で過去の個数うんこに増えてしまう！つまり、isDead()が真なら、その時のunkを初期化しないと！」
面「そう！ならどうする？」
ぼ「うーん。変数maxUnkを足せばいいかな。isDead()はmaxUnkより大きな場合は真。そのときはunkを初期化する」
面「なるほど。大丈夫そうだね」
ぼ「あとはOKかな？…よし、じゃあコード書いてみるよ（マーカーを手に取る）」
ぼ「まずクラス外観はこんな感じかな…（カキカキ）」
class Unk: def __init__(self): pass def division(self): pass def roar(self): pass def isDead(self): pass
面「ん？これ何の言語？」
ぼ「pyてょnだよ。ぼくはpyてょn使いなんだ（自己紹介で言ったけど…）」
面「Cool」
ぼ「そして、Unkの個数を整数で持つよ。名前はunkでいいか」
面「OK」
ぼ「それと有効な最大unk数を保持するmaxUnkが要るね」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): pass def roar(self): pass def isDead(self): pass
面「なんでunkを1で初期化したの？」
ぼ「これは『いまの個数』だから。初めは１つのUnkが存在するのを想定してる」
面「なるほど」
class Unk: def __init__(self): self.unk = 1 self.maxUnk = 1024 def division(self): self.unk = self.unk*2 def roar(self): print("Unkoooooooo! ×", self.unk//2) def isDead(self): return self.unk > self.maxUnk
ぼ「division()、roar()、isDead()も書くとこんな感じかな…」
面「増殖の計算は２倍したんだね」
ぼ「そう。ちょっと手動テストしてみるね…。えーとunkが無いときのdivision()、roar()は大丈夫そうかな…。初回のdivision()でunkのサイズが1になって…そのあとroar()したら…isDead()は……」
unk = Unk() while True: if not unk.isDead(): unk.division() unk.roar() else: break --- Unkoooooooo! × 1 Unkoooooooo! × 2 Unkoooooooo! × 4 Unkoooooooo! × 8 Unkoooooooo! × 16 Unkoooooooo! × 32 Unkoooooooo! × 64 Unkoooooooo! × 128 Unkoooooooo! × 256 Unkoooooooo! × 512 Unkoooooooo! × 1024
面「大丈夫そう？」
ぼ「うん…たぶん…」
面「じゃいくつか聞くよ」
def myfunc(arr): if len(arr) ＜= 1: return arr left = [] right = [] ref = arr[0] ref_count = 0 for e in arr: if e ＜ ref: left.append(e) elif e ＞ ref: right.append(e) else: ref_count += 1 left = myfunc(left) right = myfunc(right) return left + [ref] * ref_count + right
どもども。
わたしは「なにか作ってみろ」系の言説にはまったく同意しません。
わたし自身、会社に3ヶ月間みっちり導入教育をしてもらい（COBOL85とPL/I。時代がわかる……）、基本的なアルゴリズム（コントロールブレーク、マッチング、マスタ－トランザクション、ソート、マージ、etc.いよいよ時代がわかる……）の演習を（給料をもらいながら）やって、その後もプログラムとつかず離れずでフラフラと生きてきました。
こういう経験は新卒カードがあるから有効なもので、では1から始めるとしたら……、というときに、プログラミングスクール（専門学校）というのは悪くない選択肢ではないかと思います。が、行ったことないので正直わかりません。
実際自分が1から始めるという立場になったら、まったくオロオロして元増田さんのように世のなか（の気にいらないヤツら）に呪詛を吐いて満足するだけだったと思います（当然ながらそれをいくらやってもプログラミングは上達しません）。
話をプログラミングだけに限っていえば、一番大事なのはやりかたじゃなくて動機だろうと思います。
「なにか作ってみよう」というのは、なにか作ってみようと思ってない人にはまったく心に響かないでしょう。
動機ドリブンで「なにか作ってみた」人といえば思いだすのは、MikuMikuDanceの樋口優さん（ミクを簡単に踊らせたい！）とhinadanの若宮正子さん（高齢者にも遊べるゲームが欲しい！）でしょうか。
ただかれらはわたしから見れば（モチベーションを維持しそれを行動に移す）天才で、あんまり参考にならないのも確かです。
あと、元増田さんの動機は「プログラミングを生業にしたい」ということなので、野良プログラマでは履歴書上でのアピール力が弱いかも、と思います。
ビジネスで使われるアルゴリズムにはそれなりのルールがあります。安全な（バグの出にくい）コードの書きかた、「車輪の再発明」はぜず、枯れた（将棋で言えば定跡のような）アルゴリズムを使う、ほかの人に使ってもらえるための工夫（可読性の向上など）、etc.です。
「なにか作ってみよう」を繰りかえしても、そういった作法的なものが身につくかどうか、それは才能に関わってくる問題だと思います。才能だのみの手法を推奨するのは無責任だと思いますね。
また、たとえば「例をコピーして解析する」というのもある意味有効なプログラミング学習法ですが、「下手に習うと下手が伝染る」ともいいます。どれがお手本として優れているか、それを見る目はある程度ビジネス用途のプログラムに関わっていないと持てないというジレンマがあります。
野生のプログラマで就職に有効なくらいの力を見せるとしたら、なにかのコミッター（なにする人かよく知りませんが）とかになって「××ならこの人」となったり、プログラミングコンテストで上位の成績を残したりしなければいけないのかもしれません。
どうしたものでしょうね。ブクマカのみなさんの反応を見ると、専門学校でもあまり就職に有利にならない（ホントか？専門学校の意味あるのか？）という話ですが、目的が就職ならば、一番の近道のような気がします。
そこらへんからは、元増田さんがなにをしたいか、あるいは聞いてみたいだけだったのかによります。仕事には適性とやる気が大事です。あとは年齢と必要性かな。進路はオーダーメイド以外にはありえないので、提示された案を自分で選んでそれに賭けるしかないのかな、と思います。
さて、この文章は実はこの一文に反応してのものです。（↑のは前書き）
GWあたりからトシも考えずにRubyの再入門をしていまして、手始めに「首相動静」の整形ツールを作ってみました。
初心者で（Rubyに関しては仕事で使ったことないので）なにか作ってみよう、というとこの程度ですね。
これで就職に有利になるかというと、あんまりそうは思えないなあ。Excelのマクロが組めるとかのほうがどこかの事務所に潜りこめそうですよ（でもそれも最近はインフレ気味かもしれませんね）。
朝日新聞の首相動静は詳細ですが、改行が入っておらず、大変読みにくいものです。こんな感じです。
【午前】９時３１分、自民党本部。３３分、同党役員会。１０時２分、官邸。５分、閣議。２１分、宇宙開発戦略本部。３４分、柴山昌彦文部科学相。３８分、岩屋毅防衛相。４１分、山下貴司法相。１１時３分、安全保障と防衛力に関する懇談会。
【午後】０時１１分、政府・与党連絡会議。４４分、山口那津男公明党代表。１時２７分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。２時２０分、行政改革推進会議。５２分、兼原信克官房副長官補、秋葉剛男外務事務次官。３時３６分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。４時７分、太田氏出る。可部哲生理財局長加わる。１５分、全員出る。２５分、黒川弘務法務事務次官。３４分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。４１分、谷内、宮川両氏出る。５時３分、北村氏出る。１０分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立３０周年記念式典に出席し、あいさつ。２０分、官邸。６時１８分、ガーナのアクフォアド大統領を出迎え。記念撮影。１９分、儀仗（ぎじょう）隊による栄誉礼、儀仗。２７分、アクフォアド大統領と会談。７時１２分、署名式、共同記者発表。３２分、公邸。首相主催の夕食会。８時４３分、アクフォアド大統領を見送り。９時、ヨルダンのアブドラ国王と電話協議。
ただ、これはフォーマットがはっきりしており、
と、例を見るかぎりキッチリとしたルールに則っているようです。
なので、「これだったら整形できるかも」と思い、再び学びはじめたRubyで整形ツールを作ってみることにしました。
【午前】
１０時０２分、官邸。
１０時０５分、閣議。
１０時２１分、宇宙開発戦略本部。
【午後】
０１時２７分、日韓議員連盟の額賀福志郎会長、河村建夫幹事長。
０２時２０分、行政改革推進会議。
０３時３６分、麻生太郎財務相、財務省の岡本薫明事務次官、太田充主計局長。
０４時１５分、全員出る。
０４時３４分、谷内正太郎国家安全保障局長、北村滋内閣情報官、宮川正内閣衛星情報センター所長。
０４時４１分、谷内、宮川両氏出る。
０５時１０分、東京・永田町のザ・キャピトルホテル東急。宴会場「鳳凰」で中曽根康弘世界平和研究所設立３０周年記念式典に出席し、あいさつ。
０５時２０分、官邸。
０６時１８分、ガーナのアクフォアド大統領を出迎え。記念撮影。
０６時１９分、儀仗（ぎじょう）隊による栄誉礼、儀仗。
あと、午後の時刻を24時間制にしたいな、とも思いますが、それは今後の課題（つぎに首相動静が話題になったとき）とします。全角数字の計算ってどうやるんだろう？
たぶんRubyistにいろいろ突っこまれると思うけど、こんな感じです。
プログラマは玉石混淆ですが、これは石のほうの例だと思っていただければさいわいです。
※ はてな記法にはシンタックスハイライトあるけど、増田だとInternal Server Errorになるのではずしました。見にくくてスマソ。
# encoding: utf-8 # 漢字コンバータのライブラリを取りこむ（Stringに漢字変換メソッドを付けてくれる。神） require 'kconv' # 正規表現パターン # 時刻をｈ時ｍ分形式からｈｈ時ｍｍ分形式にする # 否定後読みを使用する # 時は行頭にある OneDigitHour = /^((?<![０-１])[０-９]時)/ # 分は時のあとにある。このパターンとマッチすると、\1が時、\2が分になる。 OneDigitMinute = /^([０-９]{1,2}時)(?<![１-５])([０-９]分)/ # 分のない、時だけの行のパターン。否定先読みを使用 HourWithoutMinute = /^([０-９]{1,2}時)(?![０-５]?[０-９]分)/ # 行頭のｈ時ｍ分をｈｈ時ｍｍ分にするサブ処理（これは関数といっていいの？） def convTopHourMinute2TwoDigits(oneLine) # 時を変換 oneLine.sub!(OneDigitHour, "０\\1") # 分を変換 oneLine.sub!(OneDigitMinute, "\\1０\\2") # 分がない場合"００分"を追加 oneLine.sub!(HourWithoutMinute, "\\1００分") # 戻り値 oneLine end # 入力ファイルの名前 InputFilename = "首相動静2018年12月11日.txt" # 出力ファイルの名前 OutputFilename = "首相動静2018年12月11日_編集済.txt" # 入力ファイルをオープン inFile = File.open(InputFilename, "r") # 出力ファイルをオープン outFile = File.open(OutputFilename, "w") # 時刻パターンはシンプルに、ｈ時、ｍ分、ｈ時ｍ分、という3パターンを結合する # 1つのパターンで全部カバーするよりこちらのほうが見やすい。というか、脳の容量の問題で1文に書ききれなかった jikokuPattern = /[０-９]{1,2}時[０-９]{1,2}分、|[０-９]{1,2}時、|[０-９]{1,2}分、/ # 午前/午後 ampm = /(【午前】|【午後】)/ # 午前/午後、あるいは時刻の前で改行するためのパターン kaigyouSign = Regexp.union(ampm, jikokuPattern) # ファイル一括読み込み # 昔は1行ずつ読みこんでました。メインメモリが3MByteとかだったので contents = inFile.read.toutf8 # 入力終了。閉じておきます inFile.close # スコープの関係から、ここでローカル変数に代入 # ※ Rubyのスコープと暗黙の型には泣かされました。これに慣れるのがRubyのコツかしら # 明示的な型宣言はあったほうがいいと思うなあ。エラー出力の理由がわからなかったりするので。 hour = "" # デバッグ行はコメント化しています # 時刻パターンチェックのため、コンテンツを出力してみる # p jikokuPattern.match(contents) # エントリを改行サインで行に分ける contents.gsub!(kaigyouSign, "\n\\&amp;") # "\\&amp;"はマッチした文字列そのもの。2重のエスケープ"\\"が必要 # 改行チェックのため出力 # p contents # 入力を行で分割して各行ごとに処理 contents.split("\n") do |oneLine| # 午前/午後を示す開きカッコ"【"があるか if (oneLine =~ /^【/) then # そのまま出力 outFile.write(oneLine + "\n") # p "午前午後：" + oneLine next # 空白行は無視（スキップする） elsif (oneLine =~ /^[\s ]*$/) then # 出力しない # p " 空白行：<skip>" next # 行頭に「時」があるか elsif (oneLine =~ /^[０-９]{1,2}時/) then # あったら時間表示を抜きだしておく hour = oneLine.match(/^([０-９]{1,2}時)/)[0] # p " 時：" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "\n") next else # 「時」がなければつけて出力 oneLine = hour + oneLine # p "普通の行：" + oneLine outFile.write(convTopHourMinute2TwoDigits(oneLine) + "\n") end end
手でやったほうが早いね。
以上
携帯電話のテンキーを用いた文字入力方式の一種。少ないストローク数で文字入力が可能。テジック・コミュニケーションズ社によって開発された。日本ではデンソーJ-DN31が初採用。NECが積極的に搭載機種を開発した。スマホではクラゲ日本語入力を利用することで実現可能らしい。
日本語を入力する場合は子音のみを指定する。そうするとソフトウェアが母音を推測して変換候補を提示してくるのでその中から選択する。
「にほんごにゅうりょく」と入力したい場合は「なはんかなやあらやか」つまりは「5602581982」と打てば候補として「にほんごにゅうりょく」が出てくるらしい。改良版のT9ダイレクトでは直接漢字が変換候補として挙げられる。
ローマ字アルファベットの場合、abcなら2をdefなら3をghiなら4を1回押すことで可能性のある3文字から最も単語として成立しそうな文字が選ばれて単語が出てくる。
import pprint class Value: def __init__(self, x, y): self.x = x self.y = y def __repr__(self): return f'{type(self).__name__}({self.x}, {self.y})' def create_2D_list(a, b): _2D_list = [] for i in range(a): _1D_list = [] _2D_list.append(_1D_list) for j in range(b): _1D_list.append(Value(i, j)) return _2D_list pprint.pprint(create_2D_list(2, 3)) # [[Value(0, 0), Value(0, 1), Value(0, 2)], # [Value(1, 0), Value(1, 1), Value(1, 2)]]
1. こんな感じで使います。
$ python parser.py sample.py
import parser code = ''' a = 1 + 1 print(a) ''' graph = parser.create_graph(code) graph.render("sample")
import ast import sys import graphviz def create_graph(lines): graph = graphviz.Graph(format='png') root = ast.parse(lines) node_list = [root] _setup(graph, node_list) return graph def _setup(graph, node_list): # node node = node_list[-1] node_identity = str(len(node_list)) node_name = type(node).__name__ graph.node(node_identity, node_name) # children for child in ast.iter_child_nodes(node): node_list.append(child) child_identity = str(len(node_list)) graph.edge(node_identity, child_identity) _setup(graph, node_list) if __name__ == '__main__': file_name = sys.argv[1] with open(file_name) as file: lines = file.read() graph = create_graph(lines) graph.render(file_name)
Wikiに“キャラ評価一覧”なるものができたので読んでみたら書きたくなった
現状だとクエストに関してはどのレアリティのどのキャラでも鍛えれば回れる
サポートも呼べるから周回性能なんか重要じゃないだろ、高難易度レイドの評価が重要なのでは？と思ったので所感を書いてみる
50レイドでは発見時死にかけでもなければ30ターン殴れることが多い気がするので30ターン前提で評価
傑出
旧凛子：火力文句なし
天音：硬いので落ちる心配がない 軽いSP消費のATKデバフでヒール回るまでを安定させることもできるし、ATKバフとDEFデバフ同時掛けを一人で出来る（バフのみ、デバフのみのキャラと違って迅刹が連続しても腐らない）迅刹OPな今の仕様では相当強い イベカゼとの相性は悪い
ガチャユキカゼ：与ダメ減る属性がいないのでどの単色構成にも混ぜて使える。火力文句ないが、一番ダメージが出る属性相手に一方的に有利が取れない スキル１はロボ、オーガ、ファウストで使うと危ない
優秀
旧アスカ：アタッカーが迅刹を使わない無双６でスキル１連打構成なら相当強い ワイトで代替可能とは言えないレベルでステータスが違う
リリム：硬いので落ちる心配がない ２種デバフで迅刹が連続しても腐らない（演出長いけど）。ATKデバフのSPが重いのでヒーラーの出足が遅い時の安定化要員にし辛いと思う。（２ターン目までにリリムとヒーラーの迅刹がどちらも発動しない確率は４０％くらいある）
あやめ：常にボコボコに殴ってくる相手には相当強い。無双以外にATK上げる系の装備来たら評価上がるはず LSも良い ピンチならスキル１使えばいいし優秀だと思う
まあまあ
イベカゼ：ステ低いが他にない三色大バフは魅力。代替不可なので厳選装備支給対象。迅刹がないと遅いが迅刹発動が連続しても演出時間の問題で嬉しさ半減
紅：スキル１連打以外に使いみちはないが、基礎ステ優秀
５０レイドには連れて行かない
＝＝＝＝＝＝＝＝＝＝以下使ったことない＝＝＝＝＝＝＝＝＝＝＝＝
新アスカ：迅刹がないと遅いが迅刹が連続しても以下略。無双以外にATK上げる系の装備来たら評価上がるはず
蛍、スネークレディ：火力SRは強いよ。スネークさんは奥義で殴るからもしかしたら不遇かも
そこそこ強い気がするけど持ってない（育ってない）からわからない
イングリッド：アタッカーなのにATKバフ中持ってるのはいいと思う。迅刹ないとバフするだけになって攻撃性能活きないけど
プログラミングを教えててよく分かるのは、ちゃんと論理的な思考が出来ているかどうかを計る道具として非常に有用だということ
口先だけで乗り切ってきた人はプログラミングを教えてもちゃんと理解してくれない
知識化するときに表面上だけを理解することに慣れきってしまっていて
だからプログラミングを教えて新しい物を作らせようとすると全然作れない
例えば
def hoge(a, b): c = a + b return c def gaga(a, b): print("Hello ", a, b)
っていうソースがあったとして、gagaっていうメソッドをhogeの演算結果が表示されるように変更してみよう、っていうことをさせると
def gaga(a, b): print("Hello ", a, b, c)
って答える。
もちろんスコープとか名前空間とか、そもそもそれが生まれてきた経緯とかメソッドの意味とかはちゃんと教えてるんだけど
それでも理解してくれない
この問題に関して正解を教えると、この問題は解けるようになるが、しばらくすると似たようなミスを連発する
一方で論理的な思考が出来る子は全然分野違いから来てる子でもそんな間違いはしない
頭の中を整理して理解しているからなのか、とんでもない間違いはほぼない
入試とか面接だと両者の区別は付かないし、下手したら普段の業務でも顕在化しなかったりするんだけど
しばらく一緒に仕事をしたりすると
「あ、なんかそもそもを分かってない」
っていう子はプログラミングができない
from typing import Sequence class ReverseSequence(object): def __init__(self, sequence: Sequence): self.sequence = sequence # reference to container self.index = len(sequence) # current index # Step 1. define __iter__ method whitch returns self. def __iter__(self): return self # Step 2. define __next__ method # rasing StopIteration at the end of iteration. def __next__(self): if self.index > 0: self.index = self.index - 1 # next index return self.sequence[self.index] else: raise StopIteration class ReverseSequenceGenerator(object): def __init__(self, sequence: Sequence): self.sequence = sequence self.index = len(sequence) def __iter__(self): while self.index > 0: self.index = self.index - 1 yield self.sequence[self.index] raise StopIteration assert list.__eq__( [element for element in ReverseSequence('spam')], [element for element in ReverseSequenceGenerator('spam')] )
class Reverse: def __init__(self, data): self.data = data self.index = len(data) def __iter__(self): return self def __next__(self): if self.index == 0: raise StopIteration self.index = self.index - 1 return self.data[self.index] class ReverseGenerator: def __init__(self, data): self.data = data self.index = len(data) def __iter__(self): while True: if self.index == 0: raise StopIteration self.index = self.index - 1 yield self.data[self.index] assert [s for s in Reverse('spam')] == [s for s in ReverseGenerator('spam')]
def _stub_rectangle_list(rectangle_list, query_rectangle): """Pop rectangles overlapped by query_rectangle from rectangle_list.""" new_rectangle_list = [] stubbed_rectangle_list = [] while rectangle_list: rectangle = rectangle_list.pop() if rectangle ＆ query_rectangle: stubbed_rectangle_list.append(rectangle) else: new_rectangle_list.append(rectangle) rectangle_list.extend(new_rectangle_list) return stubbed_rectangle_list def _stub_rectangle_list(rectangle_list, query_rectangle): ###another implementation using list comprehension. ###It's slower than the above code, but more readable. new_rectangle_list = [rec for rec in rectangle_list if not (rec ＆ query_rectangle)] stubbded_rectangle_list = [rec for rec in rectangle_list if rec ＆ query_rectangle] # rectangle_list ← new_rectangle_list rectangle_list.clear() rectangle_list.extend(new_rectangle_list) return stubbded_rectangle_list
