タグ

Horiuchi_Hのブックマーク (2,322)

  • ESLint と Prettier の設定を共通化し、異なるプロジェクトでも同じ設定を使えるようにする(Shareable Configs 機能) | 35D BLOG

    ESLint と Prettier の設定を共通化し、異なるプロジェクトでも同じ設定を使えるようにする(Shareable Configs 機能) 🦥 複数プロジェクト間でコーディング規約を統一するの、マジでオススメです。 はじめにこの記事では、ESLint と Prettier の設定をプロジェクト間で共通化する方法について解説します。共通化するのに必要な知識(ESLint / Prettier で提供されている Sharable Configs 機能、npm パッケージへの公開、各プロジェクトでの読み込み方)をメインに解説していきます。 対象読者は、フロントエンドエンジニアとさせていただき、「ESLint / Prettier とは何か」と言った部分に関しては、この記事では割愛させていただきます。ご了承くださいませ。 背景と課題僕たちの会社 J-CAT も創業して1年が過ぎ、だんだん

    ESLint と Prettier の設定を共通化し、異なるプロジェクトでも同じ設定を使えるようにする(Shareable Configs 機能) | 35D BLOG
  • 新型コロナにおける子供からの家庭内感染 傾向と対策|ai

    新型コロナに家族全員感染したので、知見をまとめます。何ぶん個人差の大きいものではありますが、これが地震や台風のような一つの災害の例として、家族で備えるための一助となればと思います。 経緯小学校低学年の子供が高熱、通っている学童で既に陽性者有(小学校で陽性があったと発熱の前日にお知らせが来たが、同じ学童の子だという事は熱を出して学童を休む連絡をした時に知った)。検査して陽性。 2 日後私が高熱、検査して陽性。 夫はその翌日微熱、濃厚接触者として保健所から検査を手配後。陽性確認。 自宅療養約 1 週間の後、私と子供はホテル療養。 やっていた感染対策夫婦共に40代前半、在宅勤務、基礎疾患なし、外・会旅行はここ 1 年半以上なし、手洗い・消毒、マスク(不織布)、出かけたのは近所の小規模なショッピング施設での買い物、人のいない近所のマイナーな公園だけ。とても感染に気をつけていたというよりは、単

    新型コロナにおける子供からの家庭内感染 傾向と対策|ai
    Horiuchi_H
    Horiuchi_H 2021/08/23
    “後遺症ではなく、社会の方にある問題”
  • badssl.com

    badssl.com 🎛Dashboard Dashboard 🎫Certificate expired wrong.host self-signed untrusted-root revoked pinning-test no-common-name no-subject incomplete-chain sha256 sha384 sha512 1000-sans 10000-sans ecc256 ecc384 rsa2048 rsa4096 rsa8192 extended-validation 🎟Client Certificate Certificate Downloads client client-cert-missing 🖼Mixed Content mixed-script very mixed mixed-favicon mixed-form ✏️HTTP h

  • エンドツーエンド暗号化と法規制 – JPNIC Blog

    dom_gov_team 2020年12月14日 インターネットガバナンス エンドツーエンド(E2E)暗号化(E2EE)とは、端末間の全部の通信経路でコンテンツを暗号化することを意味し、通信経路の途中の仲介者がデータを復号化して内容を読むことが事実上不可能となります。Whatsapp、iMessage、Signalなどのチャットサービスで主に使われているようです。利用者にとっては安心ですが、犯罪などに使われた例もあるため、法執行当局からはこれまでテロや児童虐待などの対策の際に問題となるという主張がなされてきました。 2020年秋の動きとして、E2E暗号化に関する7ヶ国共同の声明が公開され、かつEUでの決議案のリークがありました。稿ではその内容をご紹介したいと思います。 ファイブアイズ諸国とインド・日による声明 2020年10月11日、英国、米国、オーストラリア、ニュージーランド、カナダ

  • 設計書には何を書くべきなのか - terurouメモ

    設計とは、 要求(やりたいこと)をヒアリングする 要求を要件(何を満たさないといけないのか)に落とし込む 要件を実現するために考えられる手段を洗い出す 手段の検証を行う 検証結果を元に、どの手段を使うかを選定する 選定した手段を合意する(一部要件を満たさない事項がある場合は、代替策や妥協ラインについても合意する) 合意内容を元に、実装や設定に落とし込む をやることである。画面設計や機能設計のように、3-5の検証/選定が薄くなったり曖昧になったりするものはあるが、一般化するとこの流れになる。 設計書には、上記の設計でやってきたことを順番に書いていけばよい。これを文章構成のテンプレに落としていくと、 要求 要件 方式 対応案(いわゆる比較表で書いていくのが楽) 検証結果 選定・合意結果(合意した代替策や妥協ラインについても記載する) 詳細設計(どういう実装にするとか、パラメーターにするとか、細

    設計書には何を書くべきなのか - terurouメモ
  • 時系列予測で使えるpythonライブラリ一覧 - ざこぷろのメモ

    記事では、時系列予測に利用できるpythonのライブラリの使い方について説明をします。 パッとライブラリを使うことを目指すため具体的なアルゴリズムの説明は省きます。 ※説明が間違えている場合があればご指摘いただけると助かります。 目次 利用データ ライブラリ Prophet PyFlux Pyro Pytorch Lightgbm 補足:Darts まとめ ソースコード このブログで記載されているソースコードはGitHubに上げておいたのでもしよろしければ参考にしてください。 github.com 利用データ 今回用いるデータはkaggleのM5 Forecasting - Accuracyと呼ばれるコンペティションで利用されたデータを用います。 作成したランダムなデータよりも実データのほうが予測をしている感があるからです。 予測に使うデータはwalmartの売上データです。 下図はその

    時系列予測で使えるpythonライブラリ一覧 - ざこぷろのメモ
  • 機械学習の説明可能性(解釈性)という迷宮 - 渋谷駅前で働くデータサイエンティストのブログ

    ちょっと前に、しょうもないことを某所で放言したら思いの外拡散されてしまいました。 機械学習の説明可能性(解釈性)、大半のケースで求められているのは厳密な分類・回帰根拠ではなく受け手の「納得感」なので、特に実ビジネス上は説明可能性に長けたモデルを開発するより、納得できないお客さんを巧みに関係性構築した上で口八丁で完璧に説得できる凄腕営業ピープルを雇う方が重要— TJO (@TJO_datasci) 2019年11月23日 これ自体は与太話なので実際どうでも良い*1のですが、最近色々な研究や技術開発の進展はたまた実務家による考察などを見ていて、「機械学習の説明可能性(解釈性)というのは思った以上に複雑な迷宮だ」と感じることがままあったのでした。 ということで、今回の記事では僕のサーベイの範囲でザッと見て目についた資料などを超絶大雑把にリストアップした上で、主に実務における説明可能性とは何かとい

    機械学習の説明可能性(解釈性)という迷宮 - 渋谷駅前で働くデータサイエンティストのブログ
    Horiuchi_H
    Horiuchi_H 2020/07/17
    “「ヒトが直感的には理解できないような構造の学習データに対しても多層モデルによって柔軟に対応して優れた当てはまりを実現できる」”
  • (中室教授御発表資料)科学的根拠に基づいて「9月入学」を考える.pdf

    ログイン読み込んでいます…

    (中室教授御発表資料)科学的根拠に基づいて「9月入学」を考える.pdf
  • 0から始めるNode.jsパフォーマンスチューニング

    近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド(ブラウザ側)とバックエンド(サーバ側)ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js

    0から始めるNode.jsパフォーマンスチューニング
  • http://www.cml-office.org/wwatch/magne/togakkai.pdf

    Horiuchi_H
    Horiuchi_H 2019/11/18
    謎水装置への、と学会例会レポート
  • 近年のデータ分析基盤構築における失敗はBigQueryを採用しなかったことに全て起因している - データエンジニアの酩酊日記

    久しぶりにペラペラな思いつきを書き捨てて、寝ます。 2、3年前ぐらいにSIerコンサルでTreasure Dataとか使ってマネージドDWH作ろうぜっていう風潮が流行って、今は運用フェーズに入ってどこも結構苦しんでるってのが僕のすごく狭い観測範囲での印象。 AWSのReadshiftしかり。 なぜ苦しんでるかっていうと、言うほどスケールしないからであり、言うほどマネージドじゃないから。 Treasure Dataは基的に割当メモリが固定でオートスケールしないので、ピーク時に合わせて必要なメモリを確保しておかないといけない。そうなるとメモリ使用量とか負荷とかをモニタリングしないといけないわけだけど、Saasだから内部のアーキテクチャが隠蔽されていていちいちサポートに問い合わせないといけなかったりする。 Redshiftの場合はそもそも自前でクラスタ管理しなくちゃいけないのでそれが大変って

    近年のデータ分析基盤構築における失敗はBigQueryを採用しなかったことに全て起因している - データエンジニアの酩酊日記
    Horiuchi_H
    Horiuchi_H 2019/10/24
    “本当の意味でフルマネージドであり、スケールするDWHはBigQueryのみ”
  • がん 早期発見・早期治療が善であるとは限らない - 名郷直樹|論座アーカイブ

    がん 早期発見・早期治療が善であるとは限らない 一臨床医から見たがん検診の一般的な問題点 名郷直樹 「武蔵国分寺公園クリニック」院長 菊池誠氏の「福島の甲状腺検査は即刻中⽌すべきだ」の記事に関して、Twitter上で多くの反論が寄せられているのを目の当たりにしたが、反論に対する意見の一つとして、筆者が2年前に日刊ゲンダイに書いた記事(注1)が周辺で引用されていたこともあり、Twitter上の議論を追いかけてみた。しかし、議論はかみ合わず、お互いが非難し合って終わるという状況だ。 反論の多くが、がん検診についての一般の人たちの意見としては十分理解できるものである反面、科学的、論理的な部分を欠いているというのが正直な感想だ。そこで自分がうまく情報を提供できるという自信があるわけではないが、日々根拠に基づく医療(Evidence-based Medicine: EBM)を実践し、がん検診を担当し

    がん 早期発見・早期治療が善であるとは限らない - 名郷直樹|論座アーカイブ
  • 第569号コラム:「ウイルス罪の運用が最近変な方向に行ってないか?」 | デジタル・フォレンジック研究会

    第569号コラム:上原 哲太郎 副会長(立命館大学 情報理工学部 教授) 題:「ウイルス罪の運用が最近変な方向に行ってないか?」 前回のコラムの最後で、「コンピュータウイルスに関する罪の運用が一段と広がっており、技術者の立場からみて疑問が残る司法判断がいくつか下ってしまった」と書きました。今回はその話を少し掘り下げて書いてみたいと思います。 第546号コラム:「年末のご挨拶:2018年のデジタル・フォレンジックを振り返る」 前回コラムで問題にしたのは、俗に「Wizard Bible事件」「Coinhive事件」と呼ばれる事件でした。さらに、この半年の間にこれに加えて「無限アラート事件」と呼ばれるものが加わってしまいました。Coinhive事件はその後無罪判決が出たことで大きく報じられましたが、罰金刑が確定してしまったWizard Bible事件や、不起訴となった無限アラート事件はそれに比べ

    第569号コラム:「ウイルス罪の運用が最近変な方向に行ってないか?」 | デジタル・フォレンジック研究会
    Horiuchi_H
    Horiuchi_H 2019/06/27
    “それを横目で見ているサイバー犯罪者たちにとっては、日本の警察を脅威とは全く感じられないでしょう。警察にはもっと重大な被害が起きている事件に注力していただきたいと思っています。”
  • IC旅券の公開鍵が公開されてない件について | forest of KIRIGAKURE

    なにやら「公開鍵を公開しない病」なんてのが流行っているらしいですね。 パスポートのセキュリティ – AAA Blog https://www.osstech.co.jp/~hamano/posts/epassport-security/ 筆者はNFCを使用してIC旅券の真正性を確認できるAndroidアプリを開発したそうです。 その紹介の中でIC旅券のセキュリティについて、特に公開鍵について段落を分けるほどに熱心に語っています。 公開鍵を公開しない病い (中略) 不開示とした理由 旅券冊子の情報暗号化に関する情報であり,公にすることにより,旅券偽造のリスクが上がる等,犯罪の予防及び公共の安全と秩序の維持に支障を及ぼすおそれ並びに日国旅券の安全性が損なわれ,法人の円滑な海外渡航に支障を来すことにつながる可能性がある等,旅券事務の適正な遂行に支障を及ぼすおそれがある。 また、当該情報は,国際

    IC旅券の公開鍵が公開されてない件について | forest of KIRIGAKURE
    Horiuchi_H
    Horiuchi_H 2019/04/24
    “「公開鍵を開示することにより電力解析やプローブ解析を行い、その結果としてIC旅券を偽造されてしまう脅威がある」”公開鍵から秘密鍵が導出できる訳がない。むしろそれが出来る方法があるなら知りたい。
  • 領域内高速塗りつぶし法 / High-speed Region Fill Method – WAISJP

    図1のような閉じた領域の内部を高速に塗りつぶすアルゴリズムと、プログラム例を示す Why? かつて作っていた『お絵描き掲示板』に、「塗りつぶし」コマンド(=お絵描きソフトで、ペンキ缶のアイコンのやつ) をつけようかなと思い、そのやり方を考えてみました。そしたら、とてもいいロジックが出来たので紹介することにしました。このロジックは、私が今まで調べたもののうち、どんなものよりも高速で、 かつ単純なものになっています。 (ただし、これは2000年ごろに作ったものですし、もっと速いやり方があるかもしれません!)。 ではさっそくそのロジック(アルゴリズム)を説明します。 原理 一般的な塗りつぶしのアルゴリズムは以下のようなもの。 これは、走査線一ごとに境界を探して行く方法なので、 「スキャンラインアルゴリズム」とか「走査線アルゴリズム」とか呼ばれている。 処理ステップ 前提として、図2のような、閉

  • オンラインコミュニケーションでの相手での心遣い - Konifar's ZATSU

    インターネッツでは毎日がエキサイティングである。これを見て、たしかに〜わかることもある〜と思った。 「コミュ障エンジニア」の他の特徴として、Slackやプルリク等での文章のやりとりにおいて「断定形/詰問形/命令形が非常に多い」というのがありまして、「違います/〜しましたか/〜してください」みたいな、ビジネスマナーを理解できてない稚拙な言葉遣いをしてしまう傾向が見受けられますねw(^.^;)— 勝又健太@テック系Youtuber (@poly_soft) October 20, 2018 たぶん嫌な気持ちになることが何度もあって、ひとしきり考えてからちょっと尖った言葉を選んだのだろう。コミュ障かどうか、稚拙かどうかは置いておいて、たしかに「ちょっと言い方変えた方がいいのになー」と思う人はいるよね。そういう人とのコミュニケーションに慣れていないと、気をつかってしまったりイライラしたりしてちょっ

    オンラインコミュニケーションでの相手での心遣い - Konifar's ZATSU
    Horiuchi_H
    Horiuchi_H 2018/10/25
    “チームの心理的安全性が保たれるようにしておけば、言葉遣いについてはある程度気にする必要がなくなるのだろう。”
  • The Twelve-Factor App (日本語訳)

    はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F

  • Node.jsのアプリケーションデバッグ・改善方法をおさらいする - hiroppy's site

    ステップ実行 --debugと--debug-brkは Node8 の時点ですでに非推奨なので、使わないでください。 デバッグ方法 コンソール Chrome devtools または、VSCode のような IDE に任せる 今回は、エディタ依存の話は特にしないです。 共通的な手順 基的には、debugger を止めたい場所に置いていくことになります。 例として、以下のコードで説明していきます。 "use strict"; const { readFile } = require("fs"); const { promisify } = require("util"); const readFileAsync = promisify(readFile); (async () => { const data = await readFileAsync("hello.txt", "utf8"

    Node.jsのアプリケーションデバッグ・改善方法をおさらいする - hiroppy's site
  • ファミコンエミュレータの創り方

    ------- GND -- |01 31| -- +5V CPU A11 -> |02 32| <- M2 CPU A10 -> |03 33| <- CPU A12 CPU A9 -> |04 34| <- CPU A13 CPU A8 -> |05 35| <- CPU A14 CPU A7 -> |06 36| <> CPU D7 CPU A6 -> |07 37| <> CPU D6 CPU A5 -> |08 38| <> CPU D5 CPU A4 -> |09 39| <> CPU D4 CPU A3 -> |10 40| <> CPU D3 CPU A2 -> |11 41| <> CPU D2 CPU A1 -> |12 42| <> CPU D1 CPU A0 -> |13 43| <> CPU D0 CPU R/W -> |14 44| <- /ROMSEL (/A

    ファミコンエミュレータの創り方
  • オブジェクト指向の呪いと、その避け方 - mizchi's blog

    このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(

    オブジェクト指向の呪いと、その避け方 - mizchi's blog
    Horiuchi_H
    Horiuchi_H 2018/08/01
    クラスはできるだけ使うな、というのは同意。あとは、ミュータブルなデータもなるべく減らしたい。