へっぽこびんぼう野郎のnewbie日記

けろけーろ(´・ω・`)! #vZkt8fc6J

結婚の障壁としての結婚式について

先日籍を入れることにした。結婚式をあげる予定については棚上げにした。

それまで籍を入れるかどうか迷っていたのは、結婚式にかかる費用のことの一点だった。安くても数十万円となる費用に加えて結婚指輪などのこともあった。いろいろと考えた結果、まず籍を入れることにした。結婚式についてはひとまず考えないこととした。

「結婚式がそもそも結婚の障壁であってはならない」という論理がもっとも心を打った。

結婚式についてのメリット・デメリットを語ることへの禁忌

めでたいことなのだから金銭について四の五の言うなという風潮がまずある。

「デメリットが少しある」と言えば、あたかも結婚そのものに対して否定的であるとされることには疑問がある。

式をあげることのメリットは確かに大きくある。親族関係への一斉周知もそうだが、人生の節目の記念としてある。多くの女性にとっては結婚とは一つの夢であり、それを強く認識できる結婚式というのは魅力的なものとして映っていると思う。

最大のデメリットはなにかというとズバリお金である。おそらくそれ以外のデメリットは有象無象である。

親が費用を負担してくれるという風潮

結婚式の費用は、歴史的に親あるいは祖父母が出すものというようになっている。歴史的に見れば、家同士が結びつくということのために、家がお金を出すというのは当然のことのように思える。対外的な示威という外交的な側面もあったに違いない。

ただし親世代もそれほどお金を持っているわけではない。現在ばかりでなく過去もそうであって、過去盛大に結婚式をあげられたのは武家や皇家であった。

いま若者が結婚をするとき、親世代は定年間近であったり定年後であったりする。そして親世代も子と同様、今後も更に人生が続く。退職後悠々自適の生活を過ごせるとはいえない。退職金があるために一時的に大金があるように見えるものの、再雇用などによって収入は激減する。

そうした中、彼らからお金を自分たちの結婚式の費用のためにいただくというのに、若干の心苦しさを覚える。また、ぼくも成長するにしたがって、彼らの懐の底が見えるようになったわけであって、できれば老後のために貯金してほしいものと考えている。

それからあくまでぼく個人については、ぼくの父は母と離婚しており兄弟仲も微妙であって財産分与もあり、父の懐は最近まで冬のようだった。母とはもう7年ほど連絡をとっておらず、こうした中で父から平然とお金を受け取って結婚式に費やすことはできなかった。

結婚式業界に感じる不信感

どうも結婚式業界では「せっかくの節目なのに金をケチるのか?奥さんを大事に思っていないのではないか?」という脅迫じみた言葉がまかり通っているように思える。これが「お金を無限にブライダルの人に渡すことが奥さんへの愛情表現となる」という意味になっていると思う。実際には「せっかく人生に一度なのですから」といった脅しの欠片も見当たらない言葉だが、こうした言葉が刺さる。(ただし、こうした言説はぼくの偏見によるかもしれない)

こうした言葉に反論することは、めでたい式をあげようとしている中でことを荒立てるようなことにもなるし、あまりに強く否定すれば喧嘩に発展する可能性すらある。そうしたややこしい問題を「金で解決できるのであれば」という感覚で、札束を無造作に積んでしまうという結果になると思っている。そこに愛はあるのか。

ぼくとしては、結婚式にお金を積めば積むだけ強い愛情表現であるとは思えない。そうするのであればまず大きな冷蔵庫や綺麗なバッグを購入したり一緒に旅行に行きたいと思う。

相手との結婚と今後

結婚式をあげるあげない以前に、今後の相手との生活を第一に考えるべきであると思う。これはおそらく結婚をしようとする人にとっては大前提であると思う。

その上で結婚式をあげるかどうかはその人たちの問題であって、他人がとやかくものを言っていい類のものではないはずだ。何に大きく価値を見出すかはその人の生き方によって決まったものである。

だから「結婚式をあげないなんて可哀想・貧乏」「結婚式をあげるなんてバカ・経済観念が無さすぎる」のどちらも、単なる蔑みの心の表面化であり、おぞましく見え、笑止千万である。

ぼくとしては「結婚式がそもそも結婚の障壁であってはならない」という、どちらの害にもならない至極まっとうな意見を支持するものである。

実家に住む父がロマンス商法(デート商法的な)に引っかかりつつあってITリテラシーの格差に動揺した話

事の発端。父と英語とロマンス商法

最近父は英語を勉強している。もう3年ぐらいやっている。仕事で必要になったが周りに英語ができる人が全くいなかったために、定年間近というのに英語の勉強をしはじめて、世界が拓けたようだった。よいことである。

父の英語は相当なブロークンで、英語が全くできない人から見るとペラペラのように見えるのであるが、 You stolen wallet? だとか go hotel key get it. You. OK? Do you have insurance? とかいうものであって、素晴らしいものであるとは言えない。

ただし別にこれも問題ない。ぼくなんてむしろ喋らないのでそのアクティブさは見習いたい。

それに父も文法の大切さを最近痛感しはじめたらしく「とりあえずTOEIC受けてみたら」と勧めてみた。年齢の近い同僚には定年間近になって英語の勉強をしはじめた上に試験まで受けるなんて「気が狂った」と思われているらしい。別にこれもいい。

問題なのはその次だ。父はシリア人とやり取りをしていた。

父はその人とのやり取りを自慢げにぼくに見せてきた。「読める?」と。彼はぼくの英語能力を結構なめているので割とそういうことをする。

「読める?」と見せてきたのは長文のメールだった。読むと「シリアで私はthe boxにとらわれているので日本に行きたい。でもビザがない。○○(父)はとてもいい人だ。申請のためにできればあなたの個人情報が必要」という旨のことが書かれていた。ぼくは「これは詐欺だろ」と思った。

「これ怪しくない?」と言うと、父は「怪しいと思ったけど英語の勉強になるし」とか言うので「いやいや。やり取り見せてよ」というとFacebookを見せてきた。

プロフィールは「シリア生まれの女性」となっていた。プロフィールの写真もまぁまぁ綺麗な女性だった。ぼくは「これは詐欺だろ」と思った。

メッセンジャーでのやり取りを見ると彼女は最初から父に大変な好意をよせており I wish eat onigiri with you in Japan のようなことが書かれていた。ぼくは「これは詐欺だろ」と思った。どうも彼女の方から父にメッセージを送ってきたらしい。

ぼくは自分のPCを開いてFacebookで彼女のプロフィールを探し、Chromeで彼女の写真を画像検索した。どうせ流用したものだろうと。案の定、アメリカのAV女優の写真だった。ぼくはそれを父に見せた。

父は混乱していたようだった。「アメリカのAV女優…?」「アメリカ?このシリアの子がアメリカのAV女優になったということか?」「なんでこんなにこの人の写真が見つかるの?」と。

ぼくは父に懇切丁寧に説明した。

父とFacebook

父には「とりあえずPCを買って家でネットを使えるように契約するんだ」と言って、そこまでは前回の帰省によって達成し、父は家電量販店にある8万円の低スペックPCを入手していた。

なので、説明のためにとりあえず画像検索のやり方を教えてあげようと試みた。

まず父はFacebookにログインできなかった。「パスワードは?」と聞くと「???」という顔をしていた。どういうことだよ。

「パスワードどこかに書いてないの?」というと、Microsoft Officeのライセンスキーが書かれたカードを見せてきた。あぁOfficeつきのを買わされたんだなと思った。でもなんでそれを見せてきたんだと思った。

よく見るとそこにログインに必要な情報だと思われる、いろんな種類のパスワードが書かれていたようだった。しかもパスワードはでたらめに書かれていた。Gコード: 456781 のように書かれていてなんじゃこれはと思った。「Gコードって何?」と聞くと「わからん」と返ってきた。これが老いか。

たぶんGコードは、Googleが二段階認証のときに教えてくれる番号のことだろう。それをメモしていたらしい。昔のビデオの録画するときに使うGコードかと思ってビビった。

それで、他にも意味がよくわからないコードがたくさんあった。どのキーを試しても入れないので、とりあえずパスワードを再発行をすることにした。

再発行をすると、こういう画面が出てきた。(この画像はスマホのものだけど)

f:id:haruharu1:20181211202733j:plain

「最近のアクティビティにアカウントのセキュリティに影響する可能性がある不審なものがあるため、アカウントが一時的にロックされました」という文言を父に説明しようとしてぼくは驚愕した。父は読み飛ばしていた。そりゃ読み飛ばしたくもなるよ。

ぼくは「英語じゃねえか!!!」と思った。

「ActivityっていうのはFacebook上の行動のことで、アカウントっていうのは銀行でいう銀行口座でFacebookでいう個人情報のこと、セキュリティは安全という意味」みたいにざっくりと説明してから

「最近のFacebook上での行動について、Facebook上にある個人情報の安全を脅かす可能性がある不審なものがあったので、一時的に使えなくしました」というふうに説明を置き換えた。父も英語を勉強していたので、それなりに納得はしてくれたようだった。

新しく発行したパスワードは、結局Officeのライセンスキーが書いてある紙に書いてもらった。「覚えろ」とか「パスワードマネージャーを使え」とかいう話ができる様子ではなかった。まずこの紙をパスワードマネージャーとしようとぼくは思った。

とにかく父はログインできるようになった。画像検索を教えようとする。すると父は右クリックを理解してないようだった。Clickは英語でカチッていう音って意味だから、右側をカチッって押すのを右クリックって言うんだよと言うと、右クリックという概念を獲得したようだった。

ていうかコンピュータ関係の用語って英語多すぎだなと思った。全部英語じゃねえか。

それで父は画像検索を見て、革命的な発見をしたようだった。

とりあえず先のロマンス商法の女性の画像を検索してもらって、すぐにアメリカのAV女優の写真がバッと出てくる。そのうえでぼくは「ここにDating Scammerって書いてあるでしょ。これは日本語でロマンス商法っていってつまり詐欺らしい」というふうに言って、Wikipediaのロマンス商法の項を見せた。

父は、世の中にこんなものがあったのかという感じだった。いまこんなことやってんのという感じだった。彼女のFacebookのプロフィールを見ると、彼女の友達には世界各国の悲しい中年独身男性たちが勢揃いしており、父は愉快そうに騙されたと笑っていた。いやあんた笑っとるけどね……

父がその後も画像検索をいろいろ試そうとすると、右クリックしても検索できない画像があった。そう。 aタグ である。 aタグは検索できない。ぼくはまず説明を諦めた。「まぁそういうのもあるけどクリックした先を見ればなんとかなるよ」と言ってお茶をにごした🍵

そんな感じで画像検索に関する話は終わった。

他にも父の操作を見ると「冷静な目で見ると何に使うボタンなのかよくわからないアイコン」などを理解していないようだった。たとえばハンバーガーメニューなど。「わかりやすく綺麗なUI」とかいう以前に、アイコンが意味不という状況にわらってしまった。こういったものをひとつひとつ勉強しなければならないとしたら、なんて苦行だろうか。

父とコンピュータとゲーム

根本的な部分がわかってないのではないかと思って、父にコンピュータに関する理解度チェックをしたら、父はコンピュータが電卓の進化形であるとか、ワープロもコンピュータであるとか、冷蔵庫にコンピュータが内蔵されていることなどは理解していた。

なので「電卓のディスプレイ画面とパソコンを比較して、コンピュータに命令してその結果が出ているよ」というような概要を説明した。

そうして父に「PC-9801って知ってる?」と言って、そこからOSの概要を説明した。「いまこういうアプリケーションがあって触っているけど、昔はあの黒い画面だったじゃん」「こうやってマウスで触って色んなアプリケーションを管理できるやつがOSっていうやつ。昔使ってたWindows 3.1とかもさ」みたいな感じで説明した。ひとまず「GUI=OS」という概念で教えるのが便利だなと思った。

それからCPUとメモリについて軽く説明した。Central Processor UnitとMemoryという英単語で説明できるので、父が英語を勉強していて本当によかったと感じた。

あんまり踏み込んだ話をしてもつまらないだろうし、父の趣味にあった信長の野望というゲームを勧めてみた。はたして興味津々であった。

父は信長の野望というゲームは知らなかったが、戦国時代のことはかなりマニアックに調べていて、特にぼくの生まれ育った地域に関してはかなりの知識量だった。以前ぼくは戦国時代の歴史に全く興味がなかったので聞き流していたが、自分が勉強すると父の知識量が膨大であることに気付き、ITリテラシーの無さゆえに父の持つ別の知識をも侮っていたということを恥じた。

問題なのは父の持つPCのスペックがよくないことなので、Nintendo Switch信長の野望でもやってもらおうかと思っている。PCとSwitchは似て非なるものながら、様々なインターフェースに触れるということはよいことだと思うので、次に発売するものをおくるつもりでいる。

得られた知識

ことITに関する話に限り、父とぼくには大きな隔たりがある。それはぼくがプログラマだからというのもあるが、今回の件で、非専門的なIT知識とはどこまでを言うのかがよくわからなくなってしまった。

若者が若いうちからゲームやパソコンやスマホで慣れてきた操作を、若者でない人がいきなりすることはできない。同じように長い間訓練するか、勉強をすることでしか身につけることはできない。

そしてただ長い間触っていればわかるというものでもない。たとえばパソコンを毎日触っていたとしてもHTMLを知らない人は一生知らないように。

明らかに彼らがその人生で培ってきた知識は膨大かつ体系的であるのに、ネットをうまく使えないことによって情報を発信してくれないというのはもったいのないことだと思う。

とりあえず今後も父にそういった知識を少しずつ提供していきたい。

「高輪ゲートウェイ駅」という名前は叩かれるべきではない

高輪ゲートウェイ駅という名前を聞いて「ださすぎる……」という人が多くいるように思う。

こうした名前の響きだけを見てJR東日本は愚かだと嘆くのはいささか早計ではないだろうか。ややもすると名前に関する外見差別のようではないか。キラキラネーム的なものはいくらでも揶揄してもよいという、こうした風潮に対して、ぼくは強く異を唱えたい。

「高輪駅・芝浦駅など、もっとしっかりとした名前が他にもあるのに…ランキングも上位だったし……」というのはあくまで市民側から見た視点であり、市民側から見ればクソダサネーミングセンスであることは明白ながら、会社側から見ればまた景色が違って見えるはずである。

また、こうした人を唸らせる文言を応募した人たちが数十人いたことにも留意し、配慮の心も持つことも忘れないでおきたい。

この記事では世論に逆張りをして、可能な限り、JR東日本の意図を斟酌してみようと思う。

高輪ゲートウェイ駅周辺について

いきなり自分語りになるけど、ぼくは以前その高輪ゲートウェイ駅の周辺に住んでいた。

最寄り駅は泉岳寺駅で、泉岳寺駅田町駅にも品川駅にも徒歩15分ほどの距離の位置にある。泉岳寺駅は電車の終点になりがちで、よくここで降ろされては次の電車を待ちながら愚痴っている人を見かけていた。これがまたおもしろいのである。

高輪ゲートウェイ駅の開発地域は、はっきり言ってなにもない。泉岳寺駅もほとんど何もない。

泉岳寺駅は地下鉄であり、地上に出ると見えるのは第一京浜道路という名前がつく、広い国道15号である。道路沿いに居酒屋がほんの数件あり、北側の出口にはセブンイレブンとガソリンスタンドがあり、南側から出るとデイリーヤマザキというコンビニやアパホテルがある。それ以外は住宅地、あるいは寺である。

そこそこ歩けばコンビニはあるが、繁華街は品川駅か田町駅まで行かなければならず、ここ一帯は都会の中の田舎という様相を呈している。

土地や家賃は比較的高く、ボロいワンルームが月8万円程度、年季が入った2DKにしようとすれば月15万円ほどの予算は見ておかないといけない。スーパーもピーコックしかなく、ライフなどよりも価格が2割ほど高い。かなり歩けば白金に「プラチナドンキホーテ」なるドンキがあるが、普通のドンキよりもお値段がはっているのである。田町駅まで行けばマルエツ、品川駅に行けば紀伊国屋と、基本的に安いスーパーはない。

体感治安はかなり良く、変な人は稀に見かけるのみで、ヤンキーは皆無である。一年前に厚労省局長が殺された以外は平和な街である。金髪は外国人以外見かけることがない。そういう街だ。

有名なものは、高輪皇族邸と、高さが150cmほどしかない低いトンネル、そして泉岳寺という寺である。

泉岳寺駅とは反対の、JR山手線の線路をこえた向こう側はどうかというと、品川シーズンテラスというオフィスビルにいくつか店がくっついたものと、芝浦水再生センターしかなく、かなり歩いて港南地域まで行かないと住宅地にたどりつけない。

つまり有り体に言うならば、この地域は何もないのである。

だからこそネーミングが難しかったのであろう。公募に至った理由の1つにこれがあると思う。

そもそも大企業の偉い人の決め方はおかしくなりがちである

これが大前提としてある。

「ベスト&ブライテスト」という本があるが、この本は、

アメリカ合衆国のケネディとそれを継いだジョンソン政権において安全保障政策を担当した閣僚および大統領補佐官たちのような、いわばアメリカの「最良にして最も聡明な」人びとが、なぜ、ベトナム戦争という非道かつ愚かな泥沼へとアメリカを引きずりこんでいったかを、その権力深奥部の人間ドラマに重ね合わせて見事に描き出した

ものである。

賢くなって色々考えてしまうと、得てして人というものは考えすぎて変な方向に走ってしまいがちである。この本はそうしたことについて警鐘を鳴らしてくれるものである。名著なのでおすすめ。

こうしたことからも、JR東日本の人が「高輪ゲートウェイ」という名前をつけてしまったことに関しても、あながちおかしなことではないように見える。

ちなみにぼくはこの本を読んだことはない。

どうして高輪駅や芝浦駅または芝浜駅ではダメだったのか

投票で一番多かったのはこうした駅名だった。

しかし高輪駅では、近隣にある白金高輪駅高輪台駅と被りまぎらわしいように思える。芝浦駅は芝浦ふ頭駅と混ざってややこしく、しかも似た名前の駅を持っているのは別の鉄道会社だったためにこうしたものに配慮したと思われる。

それから芝浦や芝浜は、芝浦の話なので、高輪とは3kmほど離れており、もはや田町である。ジャムパンとクリームパンぐらい違うのである。

だから、JR東日本の人の言い分は「そんなのはもう考えた結果ボツにしたんだ。全然思いつかないから公募したんだよ」というものだろう。

でもそんなこと言ったら炎上するから言わないのだと思う。

また、こうした二字の漢字では的確に言い表すことのできない要素というものが存在しているように思う。それは以下に記す。

msb Tamachiと高輪ゲートウェイ

スローガン:
 田町の成長曲線は、東京で一番だと思う

田町駅では最近再開発が進んでいる。こちらも高輪ゲートウェイ駅にあわせて開発が進んだものだ。

そのあたりの地域を ムスブ田町(msb Tamachi) というふうに誰かが名付け、そのように再開発プロジェクトが進んでいる。こちらもなんというか、イマイチな命名である。あまりいい名前であると手放しで褒めることはできない。

ムスブ田町は愛称として「ブタマチ」と呼ばれることもあるが、基本的に周辺の人々は「最近できたビル」と呼んでいることが多いように思う。

ぼくの個人的な感想として、ゲートウェイとムスブは相性がいいように思える。どちらもその視点は海外との繋がりを求めていることから来ているようだ。国際的ビジネスの拠点としての開発が頭にあるように思う。

こうしたグローバル思想は、下記の「品川開発プロジェクト(第Ⅰ期)に係る都市計画について」にそう書いてあった。「グローバル ゲートウェイ 品川」というふうにこの開発を位置づけているようだ。「世界へ開く日本の玄関 品川」という意味だろうか。

https://www.jreast.co.jp/press/2018/20180923.pdf

また、この港区一帯は、オフィス街と旅行者、そして一部の地主と単なる金持ちが住む地域である。

こうしてみると、外国人にわかりやすい名前にしようというふうにもともと考えていたというのはそれなりに納得できるものである。

だから「高輪ゲートウェイ」を漢字にして「高輪門」や「高輪関」などのようにすることは言語道断だったのであろう(勝手な憶測)

外国人に駅を尋ねられた際、「高輪ゲートウェイ」とさえいえば通じるというのもこの言葉の魅力の1つだ。また彼らにも覚えやすい名前だ。

外国人「○×▲*(&@S+ Takanawa Gateway?」
日本「オー ゲートウェイ! アイ シー。 カモン」

のようになるというのは良いことだと思うし、そうした交流こそがJR東日本が望んでいる姿だと思う。

人は慣れる生き物である

よくよく考えれば「天王洲アイル」もおかしな話である。こちらはisleで島という意味を持っているようだ。また「東京テレポート駅」もしかり。「南セントレア市」もしかり。「新宿プロムナード」もしかりである。

また、奇をてらった名前は覚えやすいというのもあり、宣伝効果も見込めると踏んだのであろう。そうした点で見ると「高輪ゲートウェイ」もダサいとはいえ、こうしたダサさは一過性のものであると思われる。

「平成」という年号も、当時変わったばかりのころのインタビューを見ると「へぇ…変なの……」という困惑が生じていた。「さいたま市」もいつしか誰も「ダッサww」と声を大にしては言わなくなった。

そう見ると、「高輪ゲートウェイ」も、ダサいながら親近感がわくワードではないだろうか。

漢字カナ混じり文は今後増えるように思う

ダルビッシュ有」のように、人名で漢字とカナが混ざったものは、近年ではよく見かけるようになった。

こうしたものをダサいと言う人々はいないように思う。失礼であり侮辱であるということがわかっているからだ。

駅の名前が「デラウェアゲートウェイ」だったらどうだろうか。おそらく「おかしいwww」と言うような日本人はいないはずだ。そういうものかと思うのである。

カタカナ語はすでに日本語の10%を占めているという。もはや生活になくてはならないものだ。今後英語の重要性は高まり続け、漢語や古文に関する学習は比較的重要ではなくなるであろう。明治のころはせっせと外国語から輸入し、反訳していた和製漢語は、いまや翻訳の手間が惜しいとしてそのままカタカナとなって流通している。

だから漢字カナ混じり文は今後増えるように思う。

さいごに

ぼくたちはこのダサさに慣れる必要があるはずだ。多様性を考えた視点で物事を見極めるべきである。

JR東日本の人も、あえて130位のものを選んだ理由にはこうしたこともあるように思う。「そんなんでバカにするんじゃないよ」と。「もっと広く考えようぜ」と。

ぼくはそういう視点で今後高齢ゲートボール駅を使っていきたいと思っている。

ウェイ。

オブジェクト指向で書いてて思ったことについてだらだらと書いてみる

class Data:
    def __init__(self):
        self.a = 13
        self.b = 4
        self.c = 8
        self.d = 12


data = Data()

↑のようなデータがあるときに、↓のようなコードをたまに見かけるときがある。↑のコードは失敗とかじゃなくて、モックだと思ってください。

class Calculator0:
    def __init__(self, g):
        self.g = g

    def calc(self, data):
        a = data.a if data.a % 2 == 0 else 1

        added = a + data.b
        subtracted = data.c - data.d
        calced = added / subtracted
        multiplied = calced * self.g
        return multiplied + 1


calculator0 = Calculator0(g=2)
print('0', calculator0.calc(data))

実際にはこんな単純じゃなくて、 + とか - のとこはもっと複雑なロジックで、 calcメソッド は、もっと行数がずーーーっと長く続いているもんだと思ってください。

個人的にこう書いてしまうときは、最終形がどうなるのかあんまりわかってなくて、 AしてBしてCしたらDになる みたいな感じの思考のときが多い気がしている。オブジェクト指向じゃなくて、手続き型っぽい感じでコードを書いてるときにそうなりがち。

そういうときに下手にコードをオブジェクト指向っぽくしようとして、

class Calculator1:
    def __init__(self, g):
        self.g = g

    def add(self, a, data):
        self.added = a + data.b

    def subtract(self, data):
        self.subtracted = data.c - data.d

    def multiple(self, b):
        self.multiplied = b * self.g

    def calc(self, data):
        a = data.a if data.a % 2 == 0 else 1

        self.add(a, data)
        self.subtract(data)
        calced = self.added / self.subtracted
        self.multiple(calced)
        return self.multiplied + 1


calculator1 = Calculator1(g=2)
print('1', calculator1.calc(data))

こんな感じにしてしまったことが、昔たまにあった。これはさっきよりも最悪で、一見名前がついてわかりやすくなったふうに見えて、 オブジェクトが依存しているかもしれない度 がものすごく上がっている。要はローカル変数だったものを、クラス内全体に広げてしまったことで、コードを読むときに他から影響を受けてないか確認する手間が増えている。仮に addメソッド の中で self.added に代入してなかったとしても、 calcメソッド の中で self.add が使われているので、 addメソッド へselfの値が変わっているかどうかを確認しに行かなければいけなくて、恐怖心が増加する。いわゆる、なんちゃってオブジェクト指向

じゃあ関数型っぽく書けばいいのかと思って、↓みたいにすると、

def return_1_if_odd(n):
    return n if n % 2 == 0 else 1


def add(a, b):
    return a + b


def subtract(a, b):
    return a - b


def multiple(a, b):
    return a * b


def wrap(g):
    def calc(data):
        return (
            multiple(
                (
                    add(return_1_if_odd(data.a), data.b) /
                    subtract(data.c, data.d)
                ),
                g
            ) +
            1
        )
    return calc


print('Functional', wrap(2)(data))

別にこれはこれでいいんだけど、そうするとオブジェクト指向の利点が消滅する。Pythonでやる意味ないのではって感じがする。

そういうわけで、↓のように書き直してみると……

class Util:
    @staticmethod
    def return_1_if_odd(n):
        return n if n % 2 == 0 else 1

    @staticmethod
    def add(a, b):
        return a + b

    @staticmethod
    def subtract(a, b):
        return a - b

    @staticmethod
    def multiple(a, b):
        return a * b


class GConfig:
    def __init__(self, g):
        self.g = g


class EasyCalculatedData:
    def __init__(self, origin_data):
        self.origin_data = origin_data

    @property
    def data(self):
        a = Util.return_1_if_odd(self.origin_data.a)

        added = Util.add(a, self.origin_data.b)
        subtracted = Util.subtract(self.origin_data.c, self.origin_data.d)
        return added / subtracted


class CalculatedData:
    def __init__(self, origin_data, config):
        self.origin_data = origin_data
        self.config = config

    @property
    def data(self):
        easy_data = EasyCalculatedData(self.origin_data)
        multiplied = Util.multiple(easy_data.data, self.config.g)
        return multiplied + 1


config = GConfig(g=2)
calculated_data = CalculatedData(data, config=config)
print('2', calculated_data.data)

正直題材がびみょい気がするので利点が見えにくいけど、こうすると拡張もできて、あんまり脳を使わずにコードを読むことができて嬉しいなぁと思っている。もしコードをコピペされても害があんまりなくておすすめ。

ただコードが短いやつしかないときはここまでやるのはやりすぎ感がある。短いときは一番最初のやつでもいいし、単にUtilの関数群として切り出すだけなのが手っ取り早いけど、長くなってきたときにこうすると分離したり別のクラスをプラグイン的に使えたりモックでテストできてレゴ的嬉しさもある(´・ω・`)

結局どうするのが正解なのかはよくわからない。

とりあえず2番目のやつは最悪なのでやってはいけないと思う(´・ω・`)

ブックマークに入っているいろいろなサイトについて細かく分類してみた

はじめに

基本的には、未分類 TODO リンク アーカイブ の細分化になっていると思います。

目次

  • Inbox
  • Read It Later
  • Deal It Later
  • Links
  • Digested

Group Of Inbox

New

  • 新しく入ってきたブックマークのこと。とりあえず有用だと思われたすべてのサイトへのリンク。

Stray Dog

  • 別の分類に入ってしまっている謎のリンクのこと。通常本来の分類が存在する。

例:数学フォルダに入っている「ショートケーキの作り方」

Group Of Read It Later

Read It Later Repeatedly

  • 常習的にその後何度も読むべきタイプだと判断したものへのリンク。そんなに多くは存在しない。

例:自分の好きな作家の詩

Read It Later

  • あとで読もうと思って、未着手のまま放置している記事へのリンク。基本的にその記事の中でほとんど起承転結している。

例:長文のブログ記事

Waiting For Update

  • 更新されたときに限り読みに行く記事へのリンク。そもそもブックマークで管理するべき類のものではなく、更新されたときに通知が行くようにRSSなどであらかじめ設定しておくべきタイプのもの。

例:お気に入りのユーザーのブログ記事

Abandoned

  • 途中まで読んだが、何かの理由ですべて読むことが放棄され、それでも「まだ有用」だと思われて投げ出されている記事へのリンク。

例:難しい記事

Tsundoku

  • 有用だと判断してブックマークはしたが、量が膨大なために読むことを放置しているサイトへのリンク。いつ読むのかを決めないと永遠に読まれることはない。Read It LaterやAbandonedとの明確な違いは、それを読むために勇気が必要なところ。

例:「C言語を30日で学ぼう!」のようなサイト

Group Of Deal It Later

Deal It Later

  • その後のプロセスを保留しているサイトへのリンク。プロセスというのは「読む・視る・聴く」こと以外が入る。誰かに紹介するためにブックマークしたとか、あとで見ながら作業をするためにとりあえずブックマークしたとかいうもの。

例: Amazonでほしいものリストに入れようとしたらエラーになった商品

Curated Site

  • 「有用である」と思ったものが集められた一覧へのリンク。全く読んでないものも、一部は読んだがその後のプロセスが全部完了していないものも指す。そこで示されているものが、まだ血肉となっていないもの。キュレーション記事に単なるキュレーション以上の情報が多く載っている場合は、Read It LaterやAbandonedに分類される。

例:「都内にあるオススメのパン屋ベスト100!」のような記事

Group of Links

Sugar Link

  • 情報が蓄えられているというよりも、無くてもたどり着くことはできるが、より早くたどり着くためのリンク。

例:Github

Archived Sugar Link

  • Sugar Linkのうち、あまり使わないリンクのこと。

例:国立国会図書館

Group of Digested

Archived

  • 情報は消化し終わったが、依然として有用であると判断し、いつかのときのために保存しており、かつ未分類のリンク。あまり読むことはない。

例:「部首の成り立ちとは」のようなサイト

Categorized

  • 情報が消化し終わり、あとで引き出しやすいように分類されたもの。情報が多くなればなるほどカテゴリが小分類化される。ある意味、記事化されていないCurated Siteのこと。

例:英語→「英語の文法はなぜ大事か」「語彙を増やすには」などの記事群

おわりに

誰かの何かの参考になれば幸いです。GTDをたたき台にして自分で考えてみました。不備があれば教えてくださるとありがたいです。

しばらく使ってないタブを閉じてくれるTabWranglerというプラグインが便利な件

タブが増えすぎたときに、しばらく使ってないタブを自動で閉じてくれるやつ

「タブが5個以上のときに限り、20分間使ってないタブは閉じる。ただしGitHubYoutubeは閉じない」というようなことができて便利。数値など自分でカスタマイズできる。

Firefoxでも使えるらしい。

chrome.google.com

一点不満なところがあって、新しくタブが開いたときに時間のカウントがスタートするのが嫌だった。

ぼくは新規タブを開くときに「とりあえず開いておいてあとで読む」癖があるので、「はじめてタブに移動したときにカウントスタート」というふうにしたかった。

なので、プラグインの中の app/background.jschrome.tabs.onCreated.addListener(onNewTab); のところをコメントアウトして、 const onNewTab = の定義のところもコメントアウトしてビルドし直したものを使っている。

ビルド方法は package.json に書いてあるとおり、普通に npm i して npm run build

ハック的な変え方なので、 NaN:NaNpopup.html の画面に出るけど気にしてはいけない。

github.com

Vimのjedi-vimでpythonのGoToDefinitionのためにctagsでいろいろ定義のIndexを集めるためにやること

まず exuberant-ctags をインストールする。

Macなら

Exuberant Ctags

からダウンロードして、↓のようにインストール。将来バージョンが変わるかもしれないのでそのへんは脳内補完でお願いします。

$ tar -xzvf ctags-5.8.tar.gz 
$ cd ctags-5.8
$ make
$ sudo make install

これで /usr/local/bin/ に置かれるので、そのctagsを使って

$ ctags -R --fields=+l --languages=python --python-kinds=-iv -f ./tags /path/to/your-project-file
$ ctags -R --fields=+l --languages=python --python-kinds=-iv -f ./tags $(python -c "import os, sys; print(' '.join('{}'.format(d) for d in sys.path if os.path.isdir(d)))")

Done.

Ctrl + ] (定義へ) / Ctrl + o (1つ前に戻る) / CTRL-^ (1つ前のファイルに戻る) で幸せになれます。

Navigating your Django project with Vim and ctags | Fusionbox