https://hrmethod.connpass.com/event/326745/ で登壇した資料です。 組織課題における未完了の問題点、組織課題に向き合うアプローチとして、 - Inside-Outなメンタルモデル - FEARLESS CHANGEにあるような組織で物事を実践するための…
Golangの標準パッケージであるnet/httpを使ってHTTPルーターを自作する話です。 表紙は新書メーカーさんで作成しました。 https://yubais.net/tools/paperback-maker/ 追記: 要約版をqiitaに書いてあります。手短に知りたい場合はこちらが良いかもしれません。 https://qiita.com/bmf_san/items/312fac5b3132d8bee4ca 自作ルーターがawesome-goにリストアップされました :D https://github.com/avelino/awesome-go#routers 追記: コードのハイライトを修正しました。 追記: Go Conference 2021 Autumnで"net/httpでつくるHTTPルーター自作入門"というタイトルで発表しました。 https://speakerdec
内容をさらに盛り込んだ「最高の勉強法」が書籍化されました→https://amzn.to/3t7YIux 効果的な勉強方法について、科学的根拠を示しながらまとめてみました。多くの人が行っている再読・繰り返し読むということやハイライトをすることは、他の勉強方法に比べて効果が低いと考えられています。勉強をする時は、アクティブリコール、間隔反復・分散学習、連続的再学習、など、とにかく繰り返しアウトプットすることを意識してみてください。さらに覚えにくい場合は、記憶術を使うことをお勧めします。 0:00 はじめに(勉強法について) 0:36 今回の勉強法に関する動画の構成 1:05 安川の成績 2:42 他の勉強法と比べて効果が低い勉強法①繰り返し読む・再読 4:32 他の勉強法と比べて効果が低い勉強法②ハイライト・線を引く 5:52 効果が高い勉強法①アクティブリコール 9:18 アクティブリ
TLSの有無 言うまでもないことですが、httpsでは通信路をTLSを使って保護することが想定されています。[1][2] デフォルポート httpは80、httpsは443です。[3][4] 権威性 以降の説明に入る前に前提を確認します。本稿は「httpとhttpsの違い」と題されていますが、これはURLのスキーム部分のことを指しています。URLはリソースの所在を指すものであり、通信方法はそこから二次的に決まるものです。このことを前提に置きつつ権威性について説明します。 Webにおいて、所望のリソースにアクセスする方法はひとつではありません。このような方法のうち、リソースの所有者の制御下にある(第三者による加工などが行われていないと期待される)方法で取得することを権威的アクセスと呼びます。[5] どのようなアクセス方法が権威的とみなせるかについて100%客観的で統一的な指標があるわけではな
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 元記事 元記事を読んで恐くなり、災害用公衆無線LANの00000JAPANを含むFree Wi-Fiの使用を躊躇してしまった一般利用者個人のためにこの記事を書きました。 本記事では大雑把に元記事がどのようなリスクを指摘しているのか、そしてなぜそれを考えなくて良いのかを説明した後、情報セキュリティについて持論を述べる前に理解しておくべき点に触れます。 結論 正しくスマホやPCを使う限りFree Wi-Fiは危険ではありません。00000JAPANをぜひ活用してください。 これに同意した方とネタが嫌いな人はセキュリティクラスタは口が悪いまで
想定よりだいぶ大変でした。 hecto 成果物はこれ↓ 参考サイトはこれです↓ インスパイア元↓ 感想 Rustはこのチュートリアルが初体験 ずっと勉強したいとは思っていたので良い機会だった チュートリアルを進めていくなかで所有権とかライフタイムとかを少しずつ導入していき説明も挟んでくれるので助かった しかし3000行の経験を積んだ程度ではまだまだエラーの読み解きは難しいな〜という印象 https://bsky.app/profile/kawarimidoll.bsky.social/post/3l3znqvdbx42q パターンマッチ、ResultやOptionといった概念は先にGleamをやっていたおかげで問題なく理解できた 外部依存ナシのC言語版が1000行程度だったので外部ライブラリを使えるRust版は行数が少ないのかしらと思ったが結果的に3000行になった C版は1週間ほどで完成
ふと気になって調べたことの備忘メモです ✍ (2022/11/3追記)ご指摘頂いた内容を踏まえて加筆修正をおこないました なぜ調べたか Webアプリケーションの開発に携わっていると CSRF という脆弱性への対処を求められますが、多くの場合利用しているフレームワークが設定追加だけで対応してくれたり、既に前任者によって適切な処置がされていたりなど、実務上で目を向ける機会はその重要性と比較して少ないのでないかと思います また、Webブラウザの実装やHTTP周辺の関連仕様の変化から陳腐化している情報も多く、現代において全体感と具体的な対処法を理解するには少しばかりハードルが高いように感じていました ですので、自身の現時点での認識を明文化して残しておくことにしました なお、私はWebセキュリティの専門家でなく、一介の開発者のため、誤りが多分に含まれる可能性があります ご指摘を頂ければ修正したいと思
「現場を知っていること」は本当に「良いこと」なのか!?:「おまえは現場をわかっていない」というフィードバックが、相手に1ミリも刺さらない理由!? 「現場を知っている」「現場を知らない」という言葉があります。 ・ ・ ・ 我が国は「現場志向(Genba)」の強い国のひとつなのかもしれません。 「あいつ、現場がわかっていないよね」 「あのひとは、現場をわかっていないよ」 なんて他者から後ろ指さされて「指摘されようもの」なら、 「あなたは、役に立たない」 「あなたでは、話にならない」 という「烙印(負のスティグマ)」を貼られたかのように聞こえてしまいます。 それほどまで「現場」という言葉はひとびとを魅了するロマンチックワードです。「現場を知らない」という言葉は、「破壊力が強い」。 ▼ しかし、この「現場を知っている」という言葉なのですが、よくよく考えてみると、本当にその「奥底」には、たくさんの意
FTX事件についての情報を整理します。 FTX事件とは 世界有数の暗号通貨取引所FTXやその関連企業が突如として経営破綻した事件です。 事件の全容はいまだ不明瞭です。 この記事について この記事では情報を整理して、現状わかっている事件に至るまでの過程をオープンな記事としてまとめたいと思います。 現時点で大量の情報が出ていますが、将来経緯を追うことが難しくなることも予想されます。 また現状に混乱されている方も多いはずです。 まずは、交通整理をするためにも、一次ソースを中心にまとめて残しておこうと思います。 個人的にこの衝撃的事件を克明に記録しておきたいという思いもあります。 記事をご覧になって何か補足があればご連絡よろしくお願いします。 将来の資料とするため、ツイートは基本的に埋め込みとスクリーンショットの両方を記載しています。 主な登場人物 SBF 本名 Sam Bankman-Fried
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、もっちゃんと申します。 今AIの快進撃が続いておりますね!2000年代に第三次AIブームが始まってからはや十数年、ここ数年の進化のスピードは眼を見張るものがあるのではないでしょうか。そしてその話題の中心となっているのがOpenAIやMicrosoftなどが開発を行っているChatGPT,GPT-4といった大規模言語モデルです。 特に今年に入ってからは本当にあまりにも各所でアップデートが巻き起こっていてついていくのに必死な状態ですよね(笑) また、情報を追うのと同時に実際に触っていくことも大事ですので、今回はAzure Ope
概要 S3 互換オブジェクトストレージの サービス を自分のためにまとめている。サービスとして提供されているのが前提で、 自前運用は範囲外 。 目的 以下の内容に絞って調べている。 日本リージョンの有無 egress の費用 容量の費用 追加調査予定 PutObject 対応 PresignedGetObject 対応 S3 互換 S3 互換の条件は s3cmd や aws sdk s3 がそのまま利用できる事。細かい互換性は気にしない。 比較用の AWS S3 https://aws.amazon.com/jp/s3/pricing/ 最小プラン Tokyo / Osaka リージョンあり 1 GiB 追加の egress 転送量は 0.114 ドル 1 GiB の追加容量は 0.025 ドル TODO SLA 書いてるのと書いてないのがあって拾いにくい 対象外 Azure は S3 互
家を整理してたら大昔の雑誌が出てきたんだけど、インターネットが流行り始めてた時期のものだったみたいでいろんな広告にデカデカと「http://www.なんたらかんたら.net」 みたいなURLが記載されてて、わー懐かしいと思ってたのね。 けどよくよく考えたら令和になった今の広告やら名刺やらにもhttps://って載ってたりするな、ということに気が付いて、なんだかちょっと不思議な気持ちになった。この表記思いの外長寿じゃない? インターネット出始めの頃ってhttp://www.っていう部分がいかにも一般向けのことは考えずに作った仕組みです感があって、仮っぽいというか生っぽいというか、良くも悪くもちょっと怪しい感覚があって、まあそのうち仕組みも整えられるだろう位に思ってたんだけど、検索エンジンが出てきてもなおhttp://は生き残り続けてるわけだ。 インターネットを作った人は全世界の人が使うように
この動画は3Blue1Brownの動画を翻訳・再編集し公式ライセンスのもと公開しているものです。 チャンネル登録と高評価をよろしくお願いいたします。 翻訳: Ufolium ufolium.comでは、線形代数や基礎解析のシリーズをはじめ様々なトピックを解説する、中学から大学までの数学のコースを提供しています! https://ufolium.com 日本語版Twitter https://twitter.com/3B1BJP 元チャンネル(英語) https://www.youtube.com/c/3blue1brown 元動画(英語) https://youtu.be/wjZofJX0v4M Richard Turner's introduction is one of the best starting places: https://arxiv.org/pdf/2304.10
Docker を利用すると、ローカル環境でも本番に近い環境を構築し、テストすることが一般的です。 本記事では、フロントエンドとバックエンドを分離した Web サービスを構築し、HTTPS を用いた ローカル環境 のセットアップ方法を解説します。 環境構築の要件 1. HTTPS でアクセスするために必要なもの HTTPSでアクセスするためには、まず証明書が必要です。AWS Route 53でドメインを登録し、証明書を取得します。 ドメインの設定 フロントエンド URL: https://front.com バックエンド URL: https://back.com とする場合、両方を A レコード(IPv4) として 127.0.0.1 に登録します。
こんにちは、 @okazu_dm です。 この記事は、CookieのSameSite属性についての解説と、その中でも例外的な挙動についての解説記事です。 サードパーティCookieやCSRF対策の文脈でCookieのSameSite属性に関してはご存知の方も多いと思います。本記事でCookieの基礎から最近のブラウザ上でのSameSite属性の扱いについて触れつつ、最終的にHSTS(HTTP Strict Transport Security)のような注意点を含めて振り返るのに役立てていただければと思います。 前提条件 Cookieについて Cookieの属性について SameSite属性について SameSite属性に関する落とし穴 SameSite属性を指定しなかった場合の挙動 SameSite: Strictでも攻撃が成功するケース 例1: スキームだけ違うケース 例2: サブドメイ
まとめ https://yomu.jp/4274065979 のような https://yomu.jp/ + ISBN という URL で本の概要が見られるサービスを作った slack に貼り付けると、その場の preview で書影とタイトルが見られる https://yomu.jp/https://www.amazon.co.jp/%E3%83%8F%E3%83%83%E3%82%AB%E3%83%BC%E3%81%A8%E7%94%BB%E5%AE%B6-%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%82%BF%E6%99%82%E4%BB%A3%E3%81%AE%E5%89%B5%E9%80%A0%E8%80%85%E3%81%9F%E3%81%A1-%E3%83%9D%E3%83%BC%E3%83%AB-%E3%82%B0%E3
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を知
「海外事情」に寄稿した文章です。許可を得てこちらに転載します(初稿)。書いたのは昨年12月なのでデータはやや古くなりましたが、「総括」なので、内容は特に問題ないと思います。御覧ください。 緒言 日本の新型コロナ対策を「総括」、すなわち総合的なパースペクティブからまとめようとしたものが過去に2つ存在する。一つは、書籍になった「新型コロナ対応/民間臨時調査会 調査・検証報告書」[1]であり、もう一つは、政府が招聘した新型コロナウイルス感染対応に関する有識者会議が出した「新型コロナウイルス感染症へのこれまでの取組を踏まえた次の感染症危機に向けた中長期的な課題について」[2]である。 しかし、前者はどちらかというと「証言集」に近く、やや厳しい言い方をすれば、「個人の感想」集であり、属人的なものだった。データ解析、ファクトの解析には乏しかった。後者については政府に依頼されて役人が突貫工事でまとめたも
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く