「catch」を含む日記 RSS

はてなキーワード: catchとは

2021-09-19

女子中高生ら装いSNS交流相手募ったらの話

女子中高生ら装いSNS交流相手募ったら…9時間で160人返信、性的要求が大半

https://news.yahoo.co.jp/articles/b8a19d3749989c993e2730e4f95e285f66617a65

これさあ、実態を把握するのは意味があるし、ゲスアプローチ地獄絵図なのも気持ち悪いけど、

学術的な裏付けにもとづく安全管理法的根拠倫理性に細心の注意が必要なので

地方NPO法人がやることじゃないとも思う。

記事中でも、2020年チェコドキュメンタリー映画SNS少女たちの10日間―」を参考にしたと書いてあるが

それであれば当然2007年アメリカリアリティショー「To Catch a Predator」も念頭に置くべきで、

こちらは番組がおとりの少年少女を用意して接触してきた大人カメラクルー突撃するという番組

最終的に、13歳の少年を装ったおとりにひっかかった検事突撃したらその場で自殺したという事件があって放送打ち切りになった。

接触してきた相手個人情報をどう扱うのかとか

そもそも借金抱えている人の前に大金の入った財布を落としておくような、

ギリギリ犯罪を犯さないように耐えている人の背中を押すような行為はどうなのかとか

いろいろ論点があるのをわかったうえでやっているのかこの報道だけでは疑問が残る。

こういうこと言うと犯罪者や予備軍の擁護と言われるんだろうけど

クズ人間からといってそのすべての人権無視していいわけではない、と思うだけ。

犯罪を罰するのに必要かつ適切な人権制限を「公権力が」行使するなら何も言わない。

2021-08-16

【未経験から1ヶ月で】現役エンジニアが教える最良のプログラミング勉強法

プログラマーに憧れる皆さん!こんばんは。

自分文系から」「未経験から」と諦めていませんか?大丈夫です!プログラミングセンス不要です。正しい手順で学べば、文系や未経験でも、誰でも一流のプログラマとして活躍することができます

今日は、未経験から最短でWeb企業就職するための勉強法をご紹介します!

オススメ方法

もっとオススメ方法は、顕正会セミナーに参加することです。

顕正会は、日本で最大のエンジニアコミュニティであり、非常に良質なテキストを用いて、プログラミング初心者向けのセミナーをしていることで有名です。顕正会に入ることで、未経験からでも一流エンジニアノウハウを学ぶことができます

また、意外と知られていませんが、日本エンジニアの8割は顕正会出身です。実はあのひろゆきビル・ゲイツ顕正会出身です。ですので、顕正会ネットワークを介して就職先を斡旋してくれたりしますし、自分顕正会員だと、面接時にも非常に有利になります

顕正会セミナーは、インターネットからも応募することができますし、秋葉原などで声をかけられることもありますので、誰でも簡単に参加できます。会員もフレンドリーな方ばかりですので、是非、お気軽に応募してみて下さい!無料体験もできますよ。

準備

プログラミング勉強を始める前に、まず、必要ものを準備しましょう。必ず必要ものと、できればあると良いものは以下の通りです。

必ず必要もの

まず、プログラムを書いて実行するためにパソコン必須です。

可能な限りスペックの高いものを買いましょう。2021年現在であれば、CPUは18コア、36スレッドRAMは128GBくらいはあると良いでしょう。ストレージSSDであれば1TBもあれば十分です。

OSは、Windowsで開発するならWindowsが、Macで開発するならMac必要です。よく分からなければMacを買っておく方が良いでしょう。基本的MacにできてWindowsにできないことはありません。

インターネットは、この記事を見ている人は既に持っているでしょう。ただし、モバイル回線で見ている人は、自宅に有線のインターネット環境を用意した方が良いです。

顕正会に入会すれば、上記スペックPC無料で貸し出ししてくれます。また、法人向けの専用線無料で取付工事を行ってくれる上に、通信費を全て負担してくれます

できればあると良いもの

まず、他の会員と連絡を取るために、SNSアカウントを持っていると良いでしょう。

最近は完全にPC上での学習もできますが、やはり、勉強の基本は紙のノートに直接書くことです。医学的にも、手指の動きと脳の記憶回路が関連していることは証明されており、手を動かすことで効率的ものを覚えることができます

Kindleなどの電子書籍リーダーは持っておいた方が良いです。紙の本は時代遅れです。いやしくもITプロを目指そうという人間が、このような最先端デバイスを使っていないのは恥だと思うべきです。紙の本を買わないことは、環境を守ることにも繋がります現金も持つのはやめましょう。

自宅での学習

せっかくセミナーに参加しても、受身聴くだけでは、プログラミング習得することは難しいです。ここでは、自宅でどのような勉強をすればよいのか、ご紹介します。

教科書写経する

まずは、教科書参考書写経することから始めましょう。教科書参考書の本文を一字一句正確に書き写すのです。

よく、「写経理屈を学べないからだめだ」と批判されますが、まずは正しい「型」を体に覚え込ませるのが先です。野球水泳などでも、細かい理屈よりも先にフォームを固めるのと同じです。書き写している内に理屈自然と身に付きます

また、写経メリットは「飛ばし読み」を防げるところです。一字一句正確に写経をすれば、細かい部分を「分かったつもり」になって飛ばししまうことを防げます。たとえば、比較演算子の等号は=ではなくて、==です。プログラミングはこういうところに注意して学ばなければいけません。

ソースコードフローチャートUML)に変換する

教科書サンプルコードノートに書き写したら、それを今度は自力フローチャートUML)に変換してみましょう。そうすることで、自分が本当にそのコード理解しているのか、確かめることができます

フローチャートUMLが素早く正確に描けることは、プログラマーとして働く上で非常に重要スキルです。それらはソフトウェア設計の基礎となりますし、ソースコードを読めない営業顧客にとっては貴重な資料となるからです。プロエンジニアは、COBOLソースコード10万行を1週間でフローチャートにして、Excel転載することができます

ここで一つ注意すべきことがありますフローチャートを描くときは、必ず専用の定規を用いて描いて下さい。フリーハンドで描いたもの業務ではフローチャートとは認められません。これはまともな企業就職すれば研修などで必ず習うことですから、今の内に覚えておきましょう。

Excel勉強する

エンジニアを目指すのであれば、プログラミングだけではなく、Excelの使い方も学びましょう。Excelエンジニアにとっての万能プラットフォームです。エンジニアはあらゆる作業Excelで行いますセル結合や罫線を用いて、見栄えの良い資料を作る技術は、エンジニアにとって必須です。

プログラミング学習中であれば、たとえば以下のような題材の資料を作ってみると良いでしょう。

尤も、以上の資料は、ツールを使うことで自動作成することもできます。たとえば、ソースコード更新履歴Gitなどのバージョン管理システムを使うことでも管理できますしかし、それらの資料としてのクオリティは非常に低いため、アマチュアしか使うことはありません。プロを目指す皆さんは、必ずExcelを使いこなせるようになりましょう!VBA習得必須です。

プログラミングのコツ

以上、プログラミング勉強法について解説しました。ここからは、実際にソースコードを書くときのコツを紹介していきます。他のプログラマと差をつけることができる技術ですので、意識するようにして下さい。

変数名は短く

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

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

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

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


なるべく関数を作らない

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

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

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

まず、関数引数に「フラグ」を渡し、関数内部で処理を切り替えれば、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構文を用いて、例外を潰すようにしましょう。

おわりに

全体的に専門用語盛りだくさんの記事になってしまいましたが、

部分的にでも理解すればプログラミングを見る目が変わるはずです。

うさんくさい記事インターネットには多いですが、

そういう情報に惑わされずに本物の技術を身につけてもらえればと思います

2021-07-02

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

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

変数名は短く

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

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

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

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


なるべく関数を作らない

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

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

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

まず、関数引数に「フラグ」を渡し、関数内部で処理を切り替えれば、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構文を用いて、例外を潰すようにしましょう。

2021-04-20

最近ディスコ調・ファンク調の曲によくある「ポロン~♪ポロォン~♪ポロロロォォンン~~♪」ってハープをかき鳴らす90年代っぽい終わり方の曲が好きなんだけど、

昔の曲それに該当するような曲がパッと思い浮かない。

ぱっと思いついたのがCCさくらの「Catch You Catch Me」なんだけど、聞き返してみるとあんまりハープ鳴ってなかった。

乃木坂46Out of the blue」、セーラームーンCrystal「君の瞳のMoonrise」みたいな曲なんだけど。

モヤモヤするなぁ。

2020-12-13

新人にはgotoを使わなければいけないようなコードは渡さないかgotoを使うな

中堅以降はgotoがないとだめなようなコードも出てくるが自己判断 try catchgotoの違いがわかって初めて 中堅以降だ

2020-11-26

anond:20201126192709

あくま自分感想だけど、

Javaはそんな間違ってないんでないの?

プログラマー思想とか宗教問題になりそうだけど

Goエラーは返り値でちゃんと処理してね、

というのを初めて知ったときちょっとショックだったんだけど理由はなんでなんだろう

なんか文法的ミニマム言語作りたいんだなあ、という意思は伝わってくるんだよなあ

goroutineは凄いんだけど、なんか削りすぎてない?という気がした

Rustと違ってGoは一通り勉強したけど結局使ってないという

まあ例外あっても、それこそ全体をtry-catchで囲んで握りつぶすことは大抵どんな言語でもできそうだよなあ

node.jsとか敢えてそう書いてたときもあったし

もちろん、とりあえず動作が狂っても例外で落ちないようにしたいときだけだけどね

go言語アプローチだとerror関数戻り値なので、戻り値を受け取らない関数呼び出しという

一見何の問題もなさそうに見えるコードが、error握りつぶすというよくない挙動を引き起こす。

 

throw-catchアプローチならばerror握りつぶすには意図的にそれを行うためのコードを書かないといけない。

かといってerror戻り値を必ず受け取らねばならないよう言語仕様制限を入れると、

かつてJavaが犯してしまったように例外処理がめんどくさすぎることになる。

 

もしgo++言語を作るとしたら、これはどのようにするのが正解なんだろうか。

2020-11-22

新人が書いたコード新人から洗練されてないのは仕方ないとして、例外処理catchして放置するだけなのが気になる

でもとりあえずは動いてるし教えるのめんどくさくてなんも言ってない

ごめんね

2020-06-23

anond:20200623160355

try~catchを踏まえた例示なら,苦しいけど評価…しない

2020-05-27

anond:20200527231403

ありえない仮定を持ち出す

 「もしも太陽がなかったら」

自分に有利な将来像を予想する

 「地球はたちまち凍りつく」

全てか無かで途中を認めないか、あえて無視する

 「花は枯れ鳥は空を捨て」

自分見解を述べずに人格批判をする

 「人はほほえみ失くすだろう」

知能障害を起こす

 「イエーイ!」

主観で決め付ける

 「太陽生命の星だ」

 「幸せを守る炎だ」

 イーグルシャークパンサー

 イーグルシャークパンサー

一見関係がありそうで関係のない話を始める

 「俺たちの魂も燃えている」

ありえない解決策を図る

 「Follow The Sun, Catch The Sun

レッテル貼りをする

 「太陽戦隊サンバルカン」

2020-05-22

anond:20200522070250

try{

あと十把一絡げの人足コード書かせると正常系(しかポロポロ抜けあり)しか書いてこねぇのが問題

特にうちの案件に来た某スクール卒な奴らはみんなそうだった

手配師落ちこぼればっかり寄せたのかもしれんがね

}

catch(e){

}

2020-05-21

コードの書き方とかもうすこし座学を充実させたほうがいいんじゃない

知らんけどプログラミングスクールとか専門学校とかプラクティス的な教育が中心なんでしょ?

新卒現場に放り込まれて、現場に転がってるコードをお手本にして育って、リーダブルコードに書かれてるようなお作法に触れてないプログラマってコードがひどいよね。

まあ「コメントはしっかり書きましょう」程度のことは知ってるけど、方向性おかしくて、装飾がやたらと多い凝った書式のコメントを書くのに命をかけてたり、情報量ゼロコメントを大量に書いて満足してるとか、そんなのになりがちだし。

クラスとかも、同じような目的で使うサブルーチンをとにかく全部つっこんで「これ、クラスじゃなくてネームスペースつかうところじゃね?」みたいになってたりするし。

全部のメソッドcatch (Exception e) で括って「絶対に落ちないプロコード」とか誇らしげだったりするし。

2020-04-05

[][][]VORZE A10サイクロンSA遠隔操作するアプリを作った

内容が内容なので匿名ダイアリーに投げ捨てる。

Bluetooth端末で動作する。(CC0 License)

<!DOCTYPE html>
<html>

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>A10 Cyclone SA easy controller</title>
</head>

<body>
  <span id="status">initializing...</span>
  <script>
    let status = document.querySelector('span#status');
    let device, characteristic;
    const connect = async _ => {
      try {
        device = await navigator.bluetooth.requestDevice({
          filters: [{ services: ['40ee1111-63ec-4b7f-8ce7-712efd55b90e'] }],
        });
        status.textContent = 'connecting...';
        let server = await device.gatt.connect();
        let service = await server.getPrimaryService('40ee1111-63ec-4b7f-8ce7-712efd55b90e');
        characteristic = await service.getCharacteristic('40ee2222-63ec-4b7f-8ce7-712efd55b90e');
      } catch (e) {
        status.textContent = `failed to connect: ${e.message}`;
        return;
      }

      document.addEventListener('pointermove', evt => {
        evt.preventDefault();
        let y = evt.y / innerHeight * 2 - 1;
        let data = Math.abs(y) * 0x7f | (y < 0 ? 0x80 : 0x00);
        characteristic.writeValue(new Int8Array([0x01, 0x01, data]));
      });
      status.textContent = 'swipe up and down to move';
      document.removeEventListener('click', connect);
    }
    document.addEventListener('click', connect);
    status.textContent = 'tap screen to connect';
  </script>
</body>

</html>

anond:20200405230635

try-catch文を使えない言語では、例外処理記述するのにgoto文は便利だぞ。

2020-03-27

楽園こちら側」の「事実に誠意を」をほぼdeepLで翻訳してみた その1

https://georgebest1969.typepad.jp/blog/2020/03/事実に誠意を.html

これが原文です。

外国から問い合わせが来ているけれども時間がなくて訳せないということで、DeepLの性能確認ついでにやってみました。

この私訳と岩田健太郎先生無関係なのでよろしくお願いします。

訳された文章を原文と見比べ、翻訳文章おかしくなったところや慣用句は「必ず日本語側の文章をいじることで」できるだけ解消しました。

よって改変した文章だけをこちらに載せ、改変する必要がなかったところは段落番号しか載せていません。元文章は元ブログを当たってください。

英語に詳しいパーソンが精査していただけると幸いです。

1 Most of what I'm about to write is no different from what I've said and done in the past. However, I have been asked the same question repeatedly, so I would like to reiterate it. We have received many inquiries from overseas as well, so we should have prepared the same content in English, but due to time constraints, I'm afraid I'll have to skip it. This article is designed to be read without basic knowledge of infectious diseases and jargon, but it is rather difficult to understand. Please forgive me for that.

感想:「Chromeかなにかでそれぞれ母国語に訳してお読みいただけると幸いです。」がきれいさっぱり消えている。DeepLの自負心だろう。

2 The fact that the number of COVID-19 reports in Japan is very low compared to other countries is attracting attention from home and abroad. Is it true? It has been pointed out that the number of tests is so small that we may be misreading the actual number of infected people.

感想home and abrodeでいいんだろうか?

3 However, this point is wrong at various layers. In the first place, Japan does not aim to capture all the numbers of COVID-19. Whether it's administrative testing or insured care, the state basically has a testing strategy in mind to diagnose, hospitalize, and isolate critically ill patients who need to be hospitalized. It is natural that they "haven't figured it out" and they don't intend to. That's not a bad thing.In fact, the situation is the same in every country, large or small, and no country, whether in the United States, Europe, or Asia, is aiming to "capture the whole number.

感想最後の文はなぜか他の文と一緒に入力すると訳してくれなかった。この文一つだけ入力すると訳してくれた。

よく考えると「多かれ少なかれ」は通じないだろうから直した方がよかった。なぜかDeepLに繋がらなくなったのでもう直せない。

WHOもそんなことは求めていない。もっとも、そのわりに日本帰国者無症状者にPCRをやってみたり、無症状な検査陽性者を入院隔離させてみたり(軽症者は自宅じゃなかったの?)、プリンシプルにおいて首尾一貫していない。だから、「彼らがなにがやりたいか私たちはよくわからない」ので、人々は不安になる。リスコミにおける失敗と言えよう。

The WHO is not asking for such a thing. But instead, Japan gives PCR to asymptomatic returnees and isolates asymptomatic test-positive people in hospital (wasn't it home for people with minor illnesses?). It has not been coherent in its principles. So, people get anxious because "we're not sure what they want to do". It's a failure in the press.

感想:「なにがやりたいかよくわからない」に主語付与する必要があった。リスコミがpressになった。よくわかったな。

「〜は自宅じゃなかったの?)、」の、が.になっているのがよくわからない。なぜかDeepLに繋がらなくなったのでもう直せない。

4 The difference between Korea and Japan is the "result" and not the "purpose". In South Korea, where the number of infected people had surged in one place, we had to focus on inspections in and around the area. If such a phenomenon (let's call it an overshoot) occurs in Japan, the number of inspections will increase. When the situation is different, arguing only on the basis of the number of tests without observing the situation is like trying to say, "That team made 50 sliding tackles while this team made only one," without watching a football game. In games where you don't have to slide (e.g., when you're in possession the whole time), even 0 times isn't a "mistake," and of course 50 times isn't a mistake.

感想特に言うことはない。便利だなあ。

5 全数把握ができていない疾患など山のようにある。日本ではインフルエンザの「全数」把握はしておらず、定点観測である疫学上、感染対策上、それで十分な情報が得られているからだ。日本で毎年風邪が何例発生しているか、正確に把握したデータはない。レセプトデータを見ればわかるじゃないか、というのも間違いで、なぜなら多くの風邪患者は(ぼくのように)受診せずに自然に治るまで待っている。医療に限らず、経済学でも政治学でもデータサンプリングから母数を推定するのがほとんどで、「全数」は非効率的状態把握法なのだ

There are many diseases for which the total number of patients is not known. In Japan, we do not have a "total" number of influenza cases, but only a fixed-point observation. Because that's enough information, both epidemiologically and in terms of infection control. There is no accurate data on how many cases of the common cold occur each year in Japan. It's also a mistake to say that you can tell by looking at the receipt data, because many cold patients (like me) don't see a doctor and wait until they are cured naturally. Not only in medicine, but also in economics and political science, data are mostly based on sampling to estimate population numbers, and "whole numbers" is an inefficient way of grasping the situation.

感想:ちょこちょこ変えてある。日本語文章が多少おかしくなっているのは勘弁してほしい。接続詞を適切に入れると格段に翻訳が正確になる。

6 We have not seen the devastation in Japan as in Italy, Spain or New York City. There is no medical collapse in a critically ill patient, no use of the operating room as an ICU, no piling up of bodies on a skating rink with no place to put them. Even if the "numbers" are not known, it is a fact that the current situation in Japan (including Tokyo) is much better controlled than in other countries.

感想特に言うことはない。便利だなあ。

7 Even so, you may be interested in "Well, what about the actual situation? There are estimates. For example, Dr. Hiroshi Nishiura and his group estimate that the number of mild illnesses in Japan may be twice the reported number. The catch rate is 0.44, with a 95% confidence interval of 0.37-0.50.

感想特に言うことはない。便利だなあ。

8 Although the study was based on data from China, there is no guarantee that the Chinese COVID-19 demographic is the same as the Japanese one. Also, since the original study did not include asymptomatic patients or those with minor illnesses that did not require hospitalization, the number of infected patients estimated on that basis would inevitably be an underestimate. If you are more paranoid, it's not unreasonable to believe that "the Japanese and Chinese viruses are different because of the mutation" (although I don't think so).

感想特に言うことはない。便利だなあ。

9 This does not diminish the value of the paper itself. The model must always use existing parameters, and it is often impossible to prove the external validity of these parameters. If the underlying parameters are not reasonable, the predictions will not be correct. A model assumes a simplified world insofar as it is a model. A model without simplification, which is an adjectival contradiction.

数理モデルのこうした「前提」にイチャモンを付けるのは、例えばAという疾患を対象ランダム比較試験をしたときに、「Bという疾患については説明できないじゃないか」と文句を言うようなもので、業界仁義に反する意味のない揚げ足取りである

To complain about these "assumptions" of the mathematical model is like complaining, for example, "You can't explain disease B," when a randomized controlled trial is conducted for disease A. This is a meaningless tirade against the honor of the industry.

感想;「分からない」を「説明できない」に変えた。多分これでいいと思う。思いたい。

10 しかし、論文読み手にとっては別である

However, it is different for the reader of the paper.

A mathematical model that assumes a certain hypothesis should have internal academic validity, but it is the responsibility of the reader, as a resident of the real world, to appraise it in the real world.

Aという疾患を対象にしたRCTの知見をBという疾患に使ってはならないように、数理モデル制限理解し、現実世界にアプライするときに十分注意するのは当然だ。

Just as the RCT findings for disease A should not be used for disease B, it is natural to understand the limitations of the mathematical model and to be careful when applying it to the real world. For example, it would be wrong to read the paper and conclude that the total number of infected people in Tokyo is about 500 as of March 26.

感想;「読み手は別である」を「読み手にとっては別である」に変更し、「制限限界」は「limitations and limitations」になったので片方削った。

11 People make mistakes. The models are also wrong. Being wrong is not a big deal. The problem is to notice your mistakes and make corrections. Already, a group at Imperial College London has admitted that its original estimate that the peak of the infection should be moderated was "wrong" and has revised its prediction that the ICU will soon fail if it does not fight the virus fairly aggressively.

感想特に言うことはない。便利だなあ。

https://anond.hatelabo.jp/20200327215116その2

2020-03-24

anond:20200324163721

メソッドtry catch (Exception e)で括って、例外握りつぶすのを安全な書き方と言ってる現場とかあるな。

2019-11-07

anond:20191106210546

それだとCatch in the Ryeになるじゃん


  ← いやいや、 Catch me in the Rye だろw 他動詞目的語を省くなよ。

2019-11-06

ライ麦畑でつかまえて」って誤訳じゃね?

それだとCatch in the Ryeになるじゃん

Catcher in the Ryeだったら「捕手入りライ麦畑」じゃないのかね

ログイン ユーザー登録
ようこそ ゲスト さん