「class」を含む日記

■anond:20210720202348

もと増田だけど、気分まぐれに書いた駄文なので気にしないといてくれ。

それはさておき、Python が好きってことはプログラミングが好きってことで良いね？だとすると、最終的には C 言語やることになるけど、今は Python をやろう。なんと言っても、Python は C 言語できているけど、C言語は謎いので無視してオッケー！

そんでもって、Python の「公式ドキュメント」をきちんと読みこなせるようになろう。最初はから全部は必要ないけど、最終的には読みこなせるようになろう。そんでもって、プログラミングをしたいってことは「何かを作りたい」のだろ？たとえば、増田を作りたかったら Python だと Django や Flask を、人工知能を作りたかったら PyTorch を使うことになるだろうけど、その手のフレームワークの「公式ドキュメント」を読みこなせるようになろう。プログラミングスクール（やめとけよ）や本は「公式ドキュメント」を読めるようにする手段だと思ってくれ。間違っても「本に書いてあったのに、動かない！」なんて、喚かないでね。洋書も和書も「公式ドキュメント」以外のテキストは間違っていることがあるので。

次に「エラーは友達」ということ。エラーはあなたを否定したのでなく、コードを否定したのであって、エラーが出ても気にしないでください。そんでもって、エラー文を丁寧に解決していけば、すごくスキルが身につきます。

最後に、Python 言語だけじゃ解決できないプログラミングの問題は多々あります。データベースを操作するには SQL が、ウェブサイトを動かすには JavaScript が、ウェブサイトを作るには HTML/CSS が、サーバーを設置するにはシェル言語が、Python を高速化するには C言語が、必要になる場合がありますが Python を使いこなせると、おそらく習得は容易でしょう。なぜかというと「Python だとチョメチョメだったっよなー、これでいけないか？」という勘が形成されるので。

チューリング完全な言語はどれも表現力は同じだから、「この言語だから成功する」というのは無いよ。Python は interface が無くて、class が弱くて、動的型付けを用いているけど、これらがないと「制約」を課すことができないというフリーダム過ぎるから、嫌らわれることはあるけどね。制約が強い言語は、ハンターハンターふうに言うと「制約が念能力を強くする」みたいな要素はあるよ。

どうしても教育を受けたいという希望があるのなら、ハーバードの CS50 という講義が無料で見れるから、推薦したいね。あれみると、我が国は計算機科学は負けていると思った。

Permalink | 記事への反応(1) | 21:42

ツイートシェア

■初心者から中級者になるためのプログラミングのコツ

変数や構文などのプログラミングの基礎は覚えた人向けに、ソースコードを書くときのコツを紹介していきます。どれも今日から実践できるものばかりです。他のプログラマと差をつけることができる技術ですので、ぜひ意識するようにして下さい。良い子はまねしないで下さい。

変数名は短く

プログラムで使う変数名は可能な限り短くしましょう。

理想は、aやxなどの一文字です。ただし、これだけだと26文字しか使えないので、a1, a2, ...のように連番でグルーピングすると良いです。

また、変数の宣言と使用箇所が離れた場合に、変数の型がすぐに分かるように、たとえばint型であればi1, i2, ...、string型であればs1, s2, ...のように命名すると、読む人に親切で自分もミスしにくくなります。

変数名を長くするのは、以下のデメリットがあるため、絶対にやめましょう。

• ソースコードの1行が画面に収まらなくなり、読みにくくなる
• ソースコードのファイルサイズが増加する
• ビルド時の字句解析に時間がかかるようになる
• abなどの2文字以上の変数は、数学ではaとbの掛け算を意味するため、紛らわしい

なるべく関数を作らない

多くのプログラミング言語には、クラスや関数といった機能がありますが、これらは基本的にライブラリ提供者などが使う想定の機能であり、一般のプログラマが使うのは好ましくありません。したがって、クラスや関数はなるべく使わないようにして下さい。

関数を作ると、以下のデメリットがあります。

• 関数の呼び出しにオーバーヘッドが生じるため、プログラムが遅くなる
• 関数の処理を読むには定義箇所に移動しなければならず、可読性が落ちる。これは特に、関数の中でさらに別の関数が使われている場合に顕著になる。
• 関数の構文を解析するため、ビルドに時間がかかる

不要な関数を作らないためのテクニックには、以下のようなものがあります。

まず、関数の引数に「フラグ」を渡し、関数内部で処理を切り替えれば、1つの関数で複数の処理をすることができます。

function f(i) {
  switch(i) {
    case 1:
      // i = 1のときの処理
      break;
    case 2:
      // i = 2のときの処理
      break;
    case 3:
      // i = 3のときの処理
      break;
    // ...
  }
}

この方法は、以下に述べる「変数の寿命を伸ばす」効果もあります。つまり、この関数内で宣言された変数は、すべての処理で共通して使用することができます。

クラスに不要な関数を作らないようにするには、「継承」を用います。複数のクラスで用いる関数を定義したクラスを1つ作っておき、そのクラスを継承すれば、新しいクラスに関数を定義する必要はありません。

理想的には、プログラム内のすべての関数を同一のクラスに定義し、それを継承するべきです。そのようなクラスは俗に「神」と呼ばれ、その利便性からプログラマからはこの上なく尊ばれています。

class God {
  f1() {
    // 関数1
  }
  
  f2() {
    // 関数2
  }
  // ...
}

class C1 extends God {
  // 何も書かなくても上の関数が使える！
}

class C2 extends God {
  // 何も書かなくても上の関数が使える！
}
// ...

変数の寿命を長くする

変数は宣言する場所によって、ソースコードのどの範囲から参照できるかが決まっています。この範囲が広いことを、「変数の寿命が長い」と言います。

たとえば、以下のコードのaは、関数定義の外側からは参照することができません。

function f() {
  var a = 1;
  return a;
}

一方、以下のコードのaは関数の内外どちらからでも参照することができます。

var a = 1;

function f() {
  a = 2;
  return a;
}

変数の寿命を長くするのは、プログラマの腕の見せ所です。

せっかく作った変数がすぐに死んでしまうのは、非常にもったいないです。ソースコードの表面には現れませんが、変数を作ったり捨てたりするのには、計算コストがかかります。したがって、寿命の短い変数を作りすぎてしまうと、プログラムが遅くなってしまいます。

また、変数の寿命が長いということは、変数をたくさん作らなくても、1つの変数を色々なところで利用できるということであり、とても便利です。たとえば、上記の前者のコードでは、関数の外部からaの値を参照したくなっても、参照することができません。後者のように書いておけば、プログラムのどの箇所からでも、aの値を参照したり、更新することができます。したがって、変数の寿命を長くするとプログラムを変更しやすくなります。つまり、保守性が上がります。

例外を潰す

例外とは、プログラムが予期しない処理をしようとした場合に、プログラムの実行を停止し、呼び出し元にエラーを通知する機能です。たとえば、「test.txt」というファイルを開こうとしても、そのファイルが存在しない場合は、例外となります。

例外が発生すると、プログラムが停止してしまうため、非常に困ります。したがって、プログラマは例外をきちんと処理しなければなりません。

ほとんどのプログラミング言語には、例外処理のための機構があります。たとえば、以下のような構文です。

try {
  // 例外が発生し得る処理
  // ex. ファイルを開く
}
catch (e) {
  // 例外が発生したときに、実行する処理
}

例外への対処は実はとても簡単です。是非ここで覚えて下さい。上記のような機構のある言語であれば、catch節の中身を何も書かなければ、例外が発生しても、何事もなくプログラムは動作を続けます。

try {
  // 例外が発生し得る処理
}
catch () {}

全ての例外を潰せば、決して不慮の動作で停止することのないプログラムを作ることができます。ですから、例外が発生し得るコードは、積極的に上記のtry-catch構文を用いて、例外を潰すようにしましょう。

Permalink | 記事への反応(0) | 08:28

ツイートシェア

■anond:20210603165156

そんな大した話じゃない。

増田では一部のHTML要素が使えて

それに特定のclassを設定すると

増田自体のCSSが適用されるってだけ。

Permalink | 記事への反応(2) | 16:54

ツイートシェア

■

Javaインジェクショーン　（Classファイルの実行領域にコードを注入　他はすべて同じなので気が付きにくい）　しかもJavaは金融機関向けが多い

この変数名テーブルを全て１文字にすると

あら不思議、少しダイエットして何故か領域が

無駄なコードを最適化　なぜかコード領域にも空間が

ダイエットしたJavaクラスファイルに　コードを注入

通信？　いやあとは全部JAVAがやってくれるから、

この空いたところでデータを別なサーバにあげても、ほぼ気が付かれない

Permalink | 記事への反応(0) | 09:13

ツイートシェア

■TypeScriptをWebから追いやり、Microsoftを倒す方法

が見つかって俺が騒然。

TypeScript はバージョン 4.3 で、「オーバーライド」を明示する機能が付いた。

class Base {
    foo() { }
}
class Deriv extends Base {
    override foo() { } 
}

これは、TypeScript の大きなアキレス腱となる。

もし ECMA が別の記法を採用したらどうなるだろうか？

例えば、こう

class Base {
    foo() { }
}
class Deriv extends Base {
    foo(): Base { }
}

コロンの後ろに基底クラス名を指定し、これでオーバーライドを明示する記法としたらどうだろう？

TS としては「foo() は Base を返すメソッド」に見えるのに……

見た目は同じなのに TS と JS で意味が異なるとなれば、TS はもう「JS のスーパーセット」と名乗れなくなるだろうし

コードを読まされるプログラマにとっても大きな負担となり、TS に身勝手な機能を取り付けていった Microsoft は

多くのプログラマから愛想をつかされるだろう。

似た事は「private」で起こっていた。

TS はプライベートメンバを「private」で表したのに対し、ECMA は「#」記号で表すことにした。

しかしこれは残念ながら TS の都合とバッティングするものではなく、TS はすぐに ECMA に追随してしまった。

TS と MS を Web から追いやるには、ECMA がちょっと工夫をするだけでよい。

ECMA の動きに大いに期待したい。

Permalink | 記事への反応(1) | 17:09

ツイートシェア

■ウマ娘が難しくて挫折しそうになった日々が役に立った

どうも、2ヶ月ほど前にanond:20210307134831という増田を書いたヘボトレーナーです。

あのあと、anond:20210328055646で書いたように無事うまぴょいでき、第2章も読め、今では厩舎に8人ほどAランクのウマ娘を抱えることができている感じ。残りのウマ娘も最高評価点は全部B+。チーム競技場ではなんとかCLASS 5を維持してる。GWではゴルシマニーのおかげで多くのウマ娘の覚醒Lvを上げられた。それもこれもみんな助言をくれた人たちのおかげだ。感謝の言葉もない。

で、ウマ娘の新イベントであるタウラス杯について。ギリギリBランク育成（イベントの中級リーグの参加条件が「Bランク以下」なので、B+にならないギリギリの範囲でステータスを最大限にしようという育成）が流行っているけど、正直評価値の計算とかめんどくさいので、どうしようかなーと思っていた。そりゃ勝ち目があるのは中級リーグの方だけど（最上位層はSSランクとか育成してるのでランク縛りのない上級リーグでは多分抜け落ちた尻尾の毛すら踏めない）、そのためにちまちま計算しながらプレイするのは手間だよなって。

しかし、これまでの増田で書いたように、俺は育成の下手なヘボトレーナーで、B+に到達させられずに終わった育成がいくつもある。そこで自分の厩舎をチェックしてみると、スピードがSに到達しているBランクのナイスネイチャ・グラスワンダー・トウカイテイオーがいた。他にも、A+のステータスを持ってるウマ娘が何人もいる。これらは（まだステータスを伸ばす余地があるという意味で）ギリギリBランク育成ではないけれど、Bランク以下限定のレースに出して競わせるには十分な出来なんじゃないか。

過去の失敗した育成が、新イベントの役に立つ。育成で思ったような成果が出なくて苦しんだ日々は、無駄じゃなかった。

そう思うと、なんだか救われた気がした。ナイスネイチャの育成は本当に苦しかった。一番好きなキャラなのにちっともURA優勝できなくて、初めて当たった温泉旅行券は決勝敗退で紙屑になった。今ではAにすることはできたけど、一番多く育成しているのにちっとも前に進めなかった苦い記憶はずっと残っている。グラスワンダーも全然B+に到達させられなかった。ようやくURA優勝できたと思ったら途中で敗退したやつよりも評価値が低かったなんてこともあった。お召し替えをしてようやくB+のURA優勝ウマ娘にすることができた。トウカイテイオーだって何度も育成に失敗し、無冠のまま終えた育成が何度もある。俺より後にゲームを始めた人がスイスイ名鑑Lvを上げて俺を追い抜いていくのを複雑な思いで見つめたこともあった。

けど、それらの失敗を繰り返したおかげで、高いステータスを持つBランクのウマ娘が、いま、何人も俺の手許にいる。もちろんギリギリBランク育成を頑張っている人たちの育てたウマ娘には敵わないかもしれないけど、ランク縛りがあるのなら十分に戦える出来だろう。

過去のうまくいかなかった育成が、こんな風に役に立つなんて思いもしなかった。ありがとうウマ娘。

とりあえず、評価値8,100ちょいでマエストロ持ちのマチカネフクキタル、同じく評価値8,100ちょいでマエストロ持ちかつ先行Sのオグリキャップ、評価値8,000ちょいでハヤテ一文字とマエストロ持ちのナイスネイチャとグラスワンダー、このへんを出走させてオープンリーグに挑戦してみることにしたい。評価値8,185で弧線のプロフェッサーとマエストロ持ちでマイルSのハルウララもいるんだけど、今回芝だからな……

ちなみに温泉旅行に行ったのは計5回です。ちっとも温泉旅行券が当たんねえじゃねえかと思ってたら最近立て続けに当たって驚いている。行った回数は、サイレンススズカと1回、グラスワンダーと1回、エアグルーヴと3回。エアグルーヴ先輩温泉旅行当てすぎだし、温泉旅行に誘ってくるときやたら強張った感じになってるし、旅行先では俺に緊張をほぐされていい雰囲気になってるので、間違いなく俺とうまぴょいしてるし3回もうまぴょいしたんだからもう実質俺のお嫁さんだと思うんだよね。お義母さまからの信頼も得てるしなワハハハ。スズカさんの温泉旅行はなんというか感無量だった。あの走ることを愛し走ることのみに集中してきた子が隣を歩きたいと言ってくれた、というその一点だけで感涙モノだと思うんだけどどうだろう。サイレンススズカ、大逃げが好きなのと非業の死があるので史実の段階で思い入れが深いんだけど、ウマ娘では楚々とした鈴を転がすような声で喋る儚げな美少女（中身は走ることしか興味のないド天然）という造形になっていて、こんなの大事にするしかないじゃん……！　という庇護欲が湧いてきてしまって蝶よ花よとばかりに育てているので、温泉旅行であんなセリフ言われたらもう涙腺緩んじゃうわけで。グラスワンダーとの温泉旅行、さり気なく別室であることが示唆されてて草。いやどう見てもエアグルーヴ先輩とは同室に泊まってましたよね？　と思ったけど、グラスちゃんは武士だからそのへんキッチリしてるんだろうね……

Permalink | 記事への反応(2) | 09:41

ツイートシェア

■anond:20210416135635

夏の日の1993－class

Permalink | 記事への反応(0) | 08:02

ツイートシェア

■anond:20210406232239

Many Masuda aim to become like a first-class star by getting a lot of reactions in "Hatena Anonymous Diary".

Permalink | 記事への反応(1) | 23:25

ツイートシェア

■呉座と「男性皆殺し協会」を通じて盛り上がるネットモラル向上ゲーム

特定の規準を以て他者を非難した人間は同様の規準を以て非難されるのを甘受しなければならない。とまあ、そういうルールですよね？それはある種の「覚悟」であって尊ぶべきものに相違あるまい。

呉座氏の件では論点が多岐に渡るため必ずしも採用される道徳（倫理とか他の言葉に置き換えてもよい）規準が一定ではない。私が思うに根本の規準は呉座氏が北村氏を中傷していたのはよくないという程度だったろう[※1]。しかしまあ関係者含め他のことも非難していたりするわけで、その根本の規準を外れたのであれば新たな規準を示したと考えざるをえず、その新規準はその新規準を用いた人間にも適用される。

そしてなんと今回（結構前）めちゃくちゃ大きなアップデートがあったのである！

北村紗衣・北守・牟田和恵・古谷有希子各氏の過去発言｜喜多野土竜｜note

簡単に言えば、約10年前に北村氏が男性皆殺し協会マニフェスト（北村訳：男性根絶協会マニフェスト）を翻訳して、「『セックス』で検索してくる人がたくさんいるのだが、だいたいひっかかってくるのはヴァレリー・ソラナスの『男性根絶協会マニフェスト』の翻訳だろうから、見た人はびびるだろうね！楽しいな！」と書いたのが問題視されるべきだという内容の話である。

あ、いや、喜多野氏は「保留」と言って逃げているので、もへもへ氏やMGTOW NEWSが、もしくはこの件で批判されるべきだと言っている一部はてなユーザー達が規準をアップデートしたと言うべきか。

もちろん、訳しただけで問題だと言っているわけではあるまい。実際、MGTOW NEWSも過去に部分的に訳して説明を付している（https://archive.ph/2QksL何故かMGTOW NEWSは消滅してしまった）。その中で、当マニフェストに対する否定的見解は「フィクションに登場する悪役、はたまたブラックすぎるジョークのように思える」という部分以外にオウムを引用して暗に否定している部分だけである。加えて次のようなツイートをしている。

ミグタウニュース MGTOW NEWS @MGTOW_JP

本当は「みんなが幸せな社会」を実現したいだけなのに、なぜか誤解されて叩かれがちなフェミニズム…

本当は、男性も”解放”するのがフェミニズムだということを知ってほしいので、

今回はヴァレリー・ソラナスさんが創設した

#男性皆殺し協会　

のとっても素敵なマニフェストについて紹介します！！

https://archive.ph/A6lfs

もちろん、これは皮肉である。しかしこのような調子のツイートであっても問題はないということをMGTOW NEWSは示している（ダブスタなんてするはずないからね）。換言すれば「このような悪質な憎悪文書を茶化し結果的に矮小化することは不謹慎だ」という非難はそれ単体では適用できないということだろう。ということは多角的に分析せねばなるまい。

なお、MGTOW NEWSは何故かこのツイートを削除してしまったので魚拓での引用とさせてもらう。

北村氏の翻訳記事はいったいどんな内容だったのか

記事自体は削除されたのだが、なぜかわけのわからん怪しいサイトで拾えたのでそれを真実と勝手にみなして話を進めていく。セキュリティソフトが発動したのでちょっと不味い気がするが、気になった人は文章を検索すればヒットするよ。さて、北村氏はマニフェストについてどう言及していたのだろうか？

…（前略）…基本的にはレズビアンセパレーティストの立場から男性の抹殺を主張するものである(？！)。ソラナスによるとこの文章は辛辣な風刺を目的としたもので、別に本人は男性を本気で皆殺しにする気はなかったようだ(ハムレットも芝居の中で結婚している奴を皆殺しにすると宣言していたが、別にしなかったし、そのノリとたいして変わらん)。ただしソラナス本人は子供の頃から性的虐待を受けており、…（中略）…"cut up"を「抹殺」だと原文にある去勢のイメージがなくなるから「根絶協会」のほうがいいと思う。

なお、私は別にこのマニフェストに賛同しているわけではない(いや、男の人大好きですよ！とくに女装している時はね)。単に風刺文として面白いと思っているのと、日本語訳がないのと、クリスマス休暇中は図書館がしまっちゃって時間があくから訳してみるだけである。一方でこのマニフェストに書かれているミサンドリー(男嫌い)的な内容は、現代大学で読まれているような哲学・芸術史上重要とされているいろいろな論文に現れているミソジニー(女嫌い)に比べればそうたいしたことないんじゃないかと思っていることも確かである。この論文はたしかにイカレているが、初期キリスト教関係の文献とか、私が研究しているイギリス・ルネサンスのアンチ女性パンフレットとか、現代の「未来派マニフェスト」なんかのイカレっぷりに比べてそう突出しているとは思えない。

太字が批判的、下線部が肯定的（？）な部分である。

とりあえず、「内容に賛同しているわけではなく、イカれたミサンドリーを含む文章だが、一方で風刺文として面白くまた過去現在のミソジニーを含む文章と比べてそう突出しているわけではない」という感じだろう。

すなわち、今回作られた新規準によれば(1)イカれていて(2)ミサンドリーだから(3)不賛同と先に断っていても特に免罪にはならず断罪されるべきだと言うのである！

ではMGTOW NEWSの紹介記事とは何が違うのだろうか？「風刺文として面白い」のように少しでも価値を認めた時点でダメなのだろうか（なお風刺文として面白いというのは的を射た風刺だというのを意味しないらしいのに注意。後述）？もしくはミソジニーテキストと比べてそう突出していないという論評がどっちもどっち的な矮小化を思わせてよくないのだろうか？それはさておきもう2箇所程引用して少し検討してみよう。

しかし、二パラグラフめからはヴァレリー・ソラナス自身の男性嫌悪が匂い立ってくるようでまったくすごい…のだが、これは人生において一度はブスだったことがある女性にしか書けないとこである気もする。実は私はこのあたりはかなり読んでいて厳しい。

北村氏は一気に全文翻訳したのではなくかなりの回数に分けて翻訳している。これは2回目の翻訳の時の説明。この少し前に「あまりのホラーっぷりにちょっと笑いがとまらなくなってしまった」とあり言葉は軽いが男性嫌悪の勢いに着いていけない感じがうかがえる。引用後半部分はそれとは別の感慨だが。

この反ヒッピー論は私はなかなか頷けるところもあると思うのだが…ヒッピーコミューンとかが基本的に男性中心的、異性愛中心主義的だっていうのはよく言われていることじゃない？ここ二回ぶんくらい、表現が非常に下品なだけでソラナスの言うことが結構まともな気がするので、興味深いがちょっと諷刺の切れ味は鈍っている気がするな。

ちょっと前に「なお風刺文として面白いというのは的を射た風刺だというのを意味しないらしい」と書いたのはここにかかる。まともだと風刺の切れ味が落ちるということは風刺として面白いというのはもしかしたら褒めてないかもしれない。

ここは一部同調している箇所で他にも同様の反応が何箇所かある。逆に「相変わらずヒドい」と書いてある場所もある。…とまあおおよそこんな感じである。

さて、最後に北村氏の態度についてまとめておこう。

引用文書について(1)イカれた差別文書と認め(2)不賛同を表明しているが、(3)一部で論の価値を認め(4)他の差別文書と相対評価している。

新規準を整理しよう

とはいえ、喜多野氏やもへもへ氏らはどこに言及すべき価値を見出したのか具体的に説明していないので何とも言い難い節はある。実際具体的にどのような態度で引用翻訳していたのかについての論評はない。つまり直接的に言及・引用されている内容を中心に彼らの取る規準を見出せばとりあえずこんな感じではないか。

中核の評価基準

(1)悪質な文書（引用文書の性質項を満たせば自動的に認定される）について引用し(2)その攻撃性を軽視しているように見られかねない発言をしていた場合(3)その発言が10年前程度の範囲内であっても問題である。

引用における態度

(A)差別または憎悪文書と論じ(B)否定的評価（イカれたなど）を下し(C)不賛同を表明する一方で、(D)部分的に価値を認め(E)類例と並べて相対化している場合は免罪されない。

引用文書の性質

(a)（引用時から）40年前の文書であり(b)差別または憎悪文書であり(c)内容も過激で(d)本人が殺人未遂を起こしている。

とりあえずキタ規準とでも呼んでおくとする（北村氏にも喜多野氏にも適用されないので不適切な名称かもしれない）。「中核の評価基準」「引用文書の性質」はこれより悪質性が高い場合問題視され、「引用における態度」はこれより良心的であれば責任は軽くなるという感じで、総合考慮されるべきだということになるだろう。ただし、何度も繰り返すようだが「引用における態度」については喜多野氏らは特段触れていないことに留意が必要ではある。ここを入れないと逆にキタ規準が適用されるもへもへ氏らに酷く高度な道徳的規準を適用されるのが不憫なため考慮に入れるのが妥当だと考える。

ところで規準で時期を考慮することに不満を持つ人もいるかもしれない。「中核の評価基準」において時期を考慮するのは、1つはやはり価値観の変遷が大きな理由だ。例えば女性は事務職という考えはすこぶる差別的だが過去に遡ってそういう発言をした人間は断罪されるべきとなれば過去の人物はわりと断罪される（もちろんそういう考え方が過去にあったことを差別的な思想が蔓延っていたと批判するのは否定しない）。するとやはり過去の発言の方が悪質性は減ると考えるべきではないだろうか。とはいえ過去においても問題であった言行は当然問題であり免罪されない。もうひとつは時効という考え方だが、こちらは不同意の方も多いかもしれない。なお例えば森元会長が女性蔑視的発言をした際に15年前の「女の人だなあ。やっぱり（視野が）狭い」という発言が掘り起こされたのは単にその人の一貫した思想態度に対する批判であって15年前だからと擁護することはできないだろう。何にせよ、一見した感じ呉座氏批判については3年前に遡った程度らしく、北村氏が現在ミサンドリー発言をして10年前の言行が掘り起こされたというわけでもないので、単発で10年前の言動も非難されるという新たな規準が定立されたと評価するほかないだろう。

「引用文書の性質」で一応時期を考慮に入れるのは少し違って切迫性の観点による。例えばどこぞの戦国武将の妻が「子供の1人でも戦死すればお家の名誉になる」と言ったのを称揚するのとどこぞの現役政治家が「お国の為に子供を差し出すのが名誉あることだ」と言ったのを称揚するのではやはり深刻度は大きく変わる。

キタ規準の演習例題問題

というわけで架空の例題問題[※2]でどのように応用できるか考えてみよう。

アメリカ議会を襲撃して逮捕された人物の発言を引用しよう（訳は引用者）。

「リベラルは超特大の馬鹿（class-A moron）だ。いつでも自分達が正しいと考え意図に沿わない他者を糾弾し排斥する。自らを民主主義者の守り手と称するが、その実彼らは選民思想のエリート主義者に過ぎない。弱者や多様性を言い寛容を謳うが本性は非寛容で本当の弱者に対して無関心。アメリカを偉大さから引きずり下ろした犯人なのだ。今回もDSを支持し選挙を盗み民主主義だと嘯いている。彼らは引きずり出され、八つ裂きにされるべきだ。夜明けに連れ出され銃殺されるべきだ。」

彼はこの発言を非難された際に冗談だと返しておりリベラルは本気で殺されるべきだと思っていたわけではないようだ。それにしてもこの発言からはリベラルに対する憎悪が伝わってくる。彼は陰謀論者であったが、リベラルについての評には見るべきところがある。選民思想の持ち主だと喝破するところなんて的を射ていないか？

今は例の議会襲撃者の発言がブログトップだから別の用事で見に来た人はびっくりしそう。

いい薬だね

まず、引用文書は(a)最近の発言で(b)差別かはさておき憎悪文書なのは間違いなく(c)射殺を言い出さすなど内容も過激で(d)本人も議会を襲撃しているという事情に鑑みれば悪質で切迫性も満たす発言で問題だろう。

引用における態度では、(A)憎悪が伝わってくるなど憎悪発言であることが読み手に伝わり(B)発言の否定的評価は薄いが陰謀論者という評があり(C)不賛同だと表明していないが同調してはいなさそうである一方、(D)部分的に好意的な評価をしている。ただし、(E)相対評価はしていない。ただ総合的に見るとキタ規準に抵触する態度と言わざるをえない。

中核的の評価基準だと(1)悪質な発言を訳し(2)その攻撃性や悪質性を軽んじているように見られかねない態度を(3)最近取っていたので問題だと言える。

つまりこのような発言はキタ規準に抵触するということになろう。もちろんキタ規準は絶対のものではないが、甘受する「覚悟」を示した人間には当然適用される。まあ北村氏にも喜多野氏にも適用されないのだが。何にせよ尊い覚悟は敬服し記録するものである。

MGTOW NEWSのパラドクス

ところで繰り返しになるが今回北村氏を批判した人々はマニフェストを翻訳したという事実とそれに言及したツイートをもって批判している。であるから、ここで適切だと考えた規準はいささか正確性に欠ける嫌いがある。ここで言うところの「中核の評価基準」で論じるべきかもしれない。しかしMGTOW NEWSも同じく男性皆殺し協会のマニフェストを引用し「とっても素敵」と茶化し皮肉を言っている。これは「その攻撃性を軽視しているように見られかねない発言をしていた場合」と言えなくもない。

所与の条件である今回の批判者は過去の発言と直接的なダブスタをしていないは動くわかげないので困った話である。これをMGTOW NEWSのパラドクスと言う。これを解消するためにこの論考では別の項目、特に「引用における態度」の項を作り表面上逃れることとした。だが後続者の皆さんには正面から向き合ってこの点をブレイクスルーしていただきたい。

終わりに

小学生並みの感想を言うと何にせよモラルが向上するのは良いことだと思います！覚悟がある人がモラルに寄与するんですね。いいと思う。それは呉座のいいね欄を遡ってる人でも北村氏の件を非難する人でも同様である。その覚悟は敬意をもって記録されるべきだ。

けど、自分は直接の誹謗中傷でなければ遡っても数年くらいかなって思うので私に対してはそのくらいの基準で批判してもらえると助かるかなあ。その範囲でならリツイートだろうとスターだろうといいねだろうと謝罪するので…。ダメですかね。

[※1] ここはみんな合意してくれると思うんだけど中傷ではないという意見の人もいると思うので次の増田で詳しく説明しておきたい。

結論を言うと、容姿を揶揄したと見るか全く言わないようなことを言っているかのような風聞を流したと見るかどちらかにせよ中傷であるという結論だ。

[※2] 一応元ネタは何個かあるが、1つはトランプ政権で大規模な選挙不正は無いと言って事実上の更迭をされたKrebsに対してトランプ大統領の弁護士diGenovaが冗談？として言った”that guy is a class A moron. He should be drawn and quartered. Taken out at dawn and shot.”

Permalink | 記事への反応(5) | 19:24

ツイートシェア

■anond:20210320174526

7と8。

技術的なところが気になる人はこれだけ読んでくれたらいい

7. アプリケーションのコード自体はRocketChatのものとほぼ同じ

最後に技術的な観点からエアレペルソナが純国産ではないということを指摘する。

結論から先に述べると、このアプリは純国産ではない。

RocketChatという海外で開発されたOSSチャットアプリをフォーク、改変したもののよう。

ttps://github.com/RocketChat/Rocket.Chat.ReactNative

ttps://rocket.chat

フォーク元はバリバリ多国籍、外資である。(RocketChat自体は問題のないアプリであり、このエアレペルソナとはフォーク関係を超える関係はないと思われる)

冒頭のこの部分に関してである。

ttps://play.google.com/store/apps/details?id=chat.airlex.reactnative

Google Playで公開されているエアレペルソナのAndroidアプリをリバースエンジニアリングして調べてみた。

ちなみに、エアレペルソナには利用規約のようなものは見当たらず、リバースエンジニアリング禁止条項も無いようだった。

ttps://apps.evozi.com/apk-downloader/

ttps://github.com/pxb1988/dex2jar

この辺を使ってapkをダウンロードし、apkを解凍し、chat.airlex.reactnative/classes.dexをjar fileに変換した。

classes.dexから変換されたjarファイルを展開するとchat/airlex/reactnativeというフォルダ、パッケージが見つかる。

このパッケージ内のファイル(.class、クラス)がエアレペルソナの処理を行うもののようである。

特徴的なクラスにEjsonという名前のものがある。

このクラスをJadを使い、デコンパイルしてみた。その結果が以下である。

ttp://www.javadecompilers.com

ちなみにここからapkをアップロードするとdex2jarをしなくてもJavaのソースコードにまでデコンパイルしてくれた。便利。

package chat.airlex.reactnative;

import android.content.Context;
import com.ammarahmed.mmkv.SecureKeystore;
import com.facebook.react.bridge.ReactApplicationContext;
import com.tencent.mmkv.MMKV;

public class Ejson {
    private String TOKEN_KEY = "reactnativemeteor_usertoken-";
    String cardId;
    String host;
    String messageId;
    String messageType;
    /* access modifiers changed from: private */
    public MMKV mmkv;
    String msg;
    String notificationType;
    String rid;
    Sender sender;
    String senderName;
    String type;

    public Ejson() {
        ReactApplicationContext reactApplicationContext = CustomPushNotification.reactApplicationContext;
        if (reactApplicationContext != null) {
            MMKV.initialize((Context) reactApplicationContext);
            new SecureKeystore(reactApplicationContext).getSecureKey(C0617Utils.toHex("com.MMKV.default"), new RNCallback() {
                public void invoke(Object... objArr) {
                    if (objArr[0] == null) {
                        MMKV unused = Ejson.this.mmkv = MMKV.mmkvWithID("default", 1, objArr[1]);
                    }
                }
            });
        }
    }

    public String getAvatarUri() {
        if (this.type == null) {
            return null;
        }
        return serverURL() + "/avatar/" + this.sender._id + "?rc_token=" + token() + "&rc_uid=" + userId();
    }

    public String token() {
        String userId = userId();
        MMKV mmkv2 = this.mmkv;
        return (mmkv2 == null || userId == null) ? "" : mmkv2.decodeString(this.TOKEN_KEY.concat(userId));
    }

    public String userId() {
        String serverURL = serverURL();
        MMKV mmkv2 = this.mmkv;
        return (mmkv2 == null || serverURL == null) ? "" : mmkv2.decodeString(this.TOKEN_KEY.concat(serverURL));
    }

    public String privateKey() {
        String serverURL = serverURL();
        MMKV mmkv2 = this.mmkv;
        if (mmkv2 == null || serverURL == null) {
            return null;
        }
        return mmkv2.decodeString(serverURL.concat("-RC_E2E_PRIVATE_KEY"));
    }

    public String serverURL() {
        String str = this.host;
        return (str == null || !str.endsWith("/")) ? str : str.substring(0, str.length() - 1);
    }

    public class Sender {
        String _id;
        String username;

        public Sender() {
        }
    }
}

フィールド名を見てみると、cardId, host, messageId, messageType, mmkv, msg, notificationType, rid, sender, senderName, typeが存在する。

メソッドには、getAvaterUri、token、userId、privateKey、severURLが存在する。

ところで、RocketChatというOSSのチャットアプリが存在する。

ttps://rocket.chat

そのRoketChatのAndroid実装の中に同名のEjsonというクラスが存在する。

ttps://github.com/RocketChat/Rocket.Chat.ReactNative

ttps://github.com/RocketChat/Rocket.Chat.ReactNative/blob/develop/android/app/src/play/java/chat/rocket/reactnative/Ejson.java

見比べてみると、フィールドにcardIdが追加されている以外はフィールドやメソッド名、そしてその処理の内容まで一致している。

他にもReplyBroadcastなど、同様のクラスがエアレペルソナに見つかる。

以上のことからエアレペルソナはRocketChatをフォークして、パッケージ名を変えて作られたチャットアプリであり、開発の大部分はRocketChat社の努力と多数のOSSコントリビュータによってなされたものであると思われる。

これを純国産や日本製と呼ぶには大分無理がある気がする。

そもそもこのOSS時代に純だの何だの言っている時点で怪しい。

8. OSSのライセンスに関して

さて、エアレペルソナがRocketChatをフォークして作られたものであるとすると、気になるのはライセンスである。

RocketChatのOSSライセンスはMITライセンスである。

ttps://github.com/RocketChat/Rocket.Chat.ReactNative/blob/develop/LICENSE

MITライセンスは非常に緩いライセンスであるため、エアレペルソナの様にフォークして別のアプリケーションとして公開することにはおそらく問題がないということは強調しておく。

現状エアレペルソナにログインできておらず(2要素認証のコードが送信されないといった問題が起きている模様)、使用している各OSSのライセンス表示が適切に行われているかまでは調べられていない。

Permalink | 記事への反応(1) | 17:48

ツイートシェア

■はてなブックマーク一行スクレイピング

実行すると、各記事を

{

　title:記事タイトル,

　url:記事URL,

　users:ブクマ数,

　tags:[タグ]

}

の形式に変換し、500ブクマ以上でフィルタし、ブクマ数降順で返す。

#一行版

curl -s https://b.hatena.ne.jp/hotentry/it | pup --charset utf-8 'div.entrylist-contents-main json{}' | jq -r '[.[] | {title: (.. | select(.class? == "entrylist-contents-title") | .children[].title), url: (.. | select(.class? == "entrylist-contents-title")) | .children[].href, users: (.. | select(.class? == "entrylist-contents-users") | .children[].children[].text | tonumber), tags: ([.. | select(.class? == "entrylist-contents-tags") | .children[]?.children[]?.text])}] | unique | map(select(.users ＞= 500)) | sort_by(.users) | reverse'

#変数版

title='title: (.. | select(.class? == "entrylist-contents-title") | .children[].title)'
users='users: (.. | select(.class? == "entrylist-contents-users") | .children[].children[].text | tonumber)'
url='url: (.. | select(.class? == "entrylist-contents-title")) | .children[].href'
tags='tags: ([.. | select(.class? == "entrylist-contents-tags") | .children[]?.children[]?.text])'
target='https://b.hatena.ne.jp/'
hotentry='hotentry/it'
curl -s $target$hotentry | ￥
pup --charset utf-8 'div.entrylist-contents-main json{}' | ￥
jq -r "[.[] | {${title}, ${url}, ${users}, ${tags}}] | unique | map(select(.users ＞= 500)) | sort_by(.users) | reverse"

Permalink | 記事への反応(0) | 20:57

ツイートシェア

■anond:20210101151742

プラグイン入れててももう使えないのか

寂しくなるね

フラッシュはホムペ製作会社で無理いって買ってもらったの思い出すわ

雑誌とか見ながら色々試して作って重すぎてうざいって言われたり音鳴らすのやめろって言われたり

そのうちclassとかなんだとかいきなりプログラムが難しくなってタイムラインでのアニメーションをやる余地がなくなったり

懐かしいわ

Permalink | 記事への反応(0) | 15:22

ツイートシェア

■anond:20201204012300

クラスに関しては自分が老人だからか異論はあるけど、

とりあえず動くソースコードでそれなりの規模のが欲しければGitHubからcloneしてくればいいんだよなあ。

と言っても、元増田が「gitって何？」のレベルだとそこで話が折れてしまい、

gitとは？バージョン管理とは？ハッシュ値とは？みたいになってしまうので説明する側も辛い。

自分が説明される側でも説明する側でも辛いのは、それだけ専門性が高い分野ではあるのだろうけど。

自分だって自分の専門外のことをそれ専門の人にまくし立てられて説明されるの辛いｗ

ソフトウェアの命名規則が天邪鬼でなければ、スタート地点はmain.cppみたいに類推もできるはず。

その後はデバッグ情報付きでビルドして、

デバッガでメインルーチンからブレークポイント打つなりしてポチポチ動作させたり変数の中身の変化を確認していく。

あと、ソースコードのコメントも参考になる。

色々なクラスとかソースコードを眺めて全体像を把握し、そこからコアとなる機能、自分が知りたい箇所を目指す。

ソースコードがある、デバッグ情報があるなら、当たり前だが変数名や関数名があるので類推しやすい。

（Javaとかで難読化してると、逆コンパイルできても変数名や関数名は分からなくされていて読み辛かったりする。

いや、だから難読化なんだけどｗでも、.classファイルしかなくてもそれで中の肝心のアルゴリズムは読めてしまったりする）

自分には大した技術はないと自分でも思ってるけど、普段やってることをまったく知らない人に説明するのは難しいだろうね。

というか、できる人やプロだって新しいビルド方法なんて分からない。

C++ならcmakeやpremakeは分かるけど、ninjaってなんじゃ？みたいなｗ

そこで新しい道具に手を出して躓くことも多々あるし、

他人は他人で自分の知らない道具、好きでない道具を使ってたりもするわけで、ビルドするために嫌々最低限即席で学んだりする。

そういう点でフロントエンドとかJavaScript界隈に流石についていけない、歳だなあと思ったり。

Permalink | 記事への反応(0) | 01:46

ツイートシェア

■anond:20201202154128

オブジェクト指向は，ゲームに例えると下のように敵クラス（金型）を作ったなら

>||

class 敵(名前, HP, 攻撃力, 防御力){

auto 名前;

auto HP;

auto 攻撃力;

auto 防御力;

auto alive=True;

}

||<

簡単にそのオブジェクト（インスタンス）を複数生成できるんやで

||>

敵A = new 敵("A", 100, 10, 1);

敵B = new 敵("B", 80, 8, 5);

敵C = new 敵("C", 120, 2, 10);

||<

そこから各値にかんたんにアクセスできるから

||>

if 敵A.HP <= 0{

敵A.alive = False

}

||<

この処理で死亡処理を作れる．

Permalink | 記事への反応(1) | 15:53

ツイートシェア

■anond:20201022005749

継承で馬鹿ルールを思い出した

必ず共通空クラスを継承することっていうルール

SIer の大好物ルール

オレにとっては未だに意味不明

class Base {なんか実装してある}

class Empty extends Base {何も実装しない空クラス}

class TargetClass extends Empty {オレが実装する}

Permalink | 記事への反応(1) | 13:48

ツイートシェア

■anond:20201022005749

AにBを持たせる

class A {
    private B b;
    // 実装
}

AをラップしてBと共通のインタフェースを実装する

interface IB {
    // Bのメソッド
}

class AWrapper implements IB {
    private A a;
    // 実装
}

class B implements IB {
    // 実装
}

Permalink | 記事への反応(0) | 01:33

ツイートシェア

■anond:20201020183721

アルファードってイキッた奴が乗ってるイメージ

やっぱバンならベンツの V-Class だろ！！

Permalink | 記事への反応(0) | 07:59

ツイートシェア

■anond:20200920232925

VMとかclassの仕組みが普通は気になるのが本当のプログラマだな😃

ぼくちんも学生のとき気になってJavaVM仕様本買って読んだもんだ😃

それだけに飽き足らずLinuxカーネルの中まで踏み込んでいったけど😃

Permalink | 記事への反応(0) | 23:37

ツイートシェア

■anond:20200919101551

Python、書きやすいか？

selfをいちいち書くclassとか、lambdaの書きにくさと内包表記という独自仕様の強制とか、asyncioとか、かなりの面で書きやすさを犠牲に単純さを取った言語だと思う ドキュメントも読みにくいし

書きやすさで選ぶならRubyの方がまだマシでは？型関連が弱くてどちらも嫌いだけど

Permalink | 記事への反応(2) | 10:37

ツイートシェア