なぜ『はてなブログ』の人気エントリーはタイトルが『多重質問』になっている事が多いのか - オオカミの口の中を覗いてみる
なぜ『はてなブログ』の人気エントリーはタイトルが『多重質問』になっている事が多いのか タイトルを多重質問にした方が人気エントリーになりやすく、アクセスがたくさん稼げるからというのが僕の仮説です まずはよしきさんのnoteを是非ご覧ください note.com 多重質問とは 具体的に言うと「なぜ〇〇は▲▲なのか」というタイトルなのに▲▲が間違っているもののこと。※よしきさんのnoteから引用 ja.wikipedia.org たとえば「あなたはまだ妻を虐待しているのか?」といった質問がある。この質問に対しては「はい」と答えようが「いいえ」と答えようが、「あなた」には妻がいて過去に虐待したことがあるということを認めたことになる。つまりこれらの事実が質問の「前提」とされたため、相手は多重質問の誤謬の罠にかけられ、一つの答えしかできない状況に追い込まれる。質問者は修辞的にこのような質問を行い、特に返
脳の予測とクリエイティブ能力の関係。予測的符号化理論、ストーリー、音楽、ゲーム、そして観察力
今回は、以前のツイートの内容をちょっと掘り下げて書いてみる。 これマジでそう。音楽が基本的に繰り返しで構成されてるのは、脳にフレーズを学習させて次を予測させるためなのよね。予測が当たると脳は歓喜する。でもずっと同じ事を繰り返してると脳は飽きる。だからAメロからBメロ→サビって展開していく。展開が変わると予測が外れて脳は驚いて食い付く。音楽は新… — うみゆき@AI研究 (@umiyuki_ai) April 10, 2023 佐渡島さんが書いた「観察力の鍛え方」を読み始めた。佐渡島さんが言うにはいいクリエイターの条件とは、観察力を持ってる事らしい。で、観察力とは何か？というと、現時点での結論は「いい観察は、ある主体が、物事に対して仮説をもちながら、客観的に物事を観て、仮説とその物事の状態のズレに気づき… — うみゆき@AI研究 (@umiyuki_ai) April 17, 2023 あら
間違いを避ける方法 - 超ウィザード級ハッカーのたのしみ
ChatGPT が出てきて、平均値なものに価値がなくなって、外れ値に価値があるか、人の役割はノイズを与えるだとか言われているのを聞くが、そんなことはないと思っている。間違い方は無数にあるが、正しいのやり方はほんの少ししかない。なにかをするときには、無数の選択肢の中から、正しいものを選び取っていかないと、ゴールにたどり着かない。ChatGPT だってプロンプトとして与えられるものは無数にあるが、求める答えが得られるプロンプトはわずかだ。正しい答えを素早く得る能力の価値は ChatGPT があっても変わらない。 もちろん人間なので、たまに道から逸れるだろう。外乱もある。でも、その場合も都度都度修正していけば、目的地にたどり着ける。 ChatGPT の画期的なところは即座にフィードバックを与えて修正ができることだ。 だが、修正がなしに一発で決める方が、何度もフィードバックを繰り返すより、速い。仕
いつも間違っている人への対処法 - 超ウィザード級ハッカーのたのしみ
間違いを減らす方法を考えていて、ある程度以上はどうしようもないという役に立たない結論を得たのだったのだが、過激だったのか、意図せずアクセスが増えてしまった。単に苦労していますだけの内容を多く読まれても困るなと、一回取り下げて書き足しました。 間違いの減らし方を こちら に書きました。 仕事をしていると、必ず間違いを提出してくる人に出会ったことはないでしょうか？私は何度も悲しい思いをしており、そういう人にはもう仕事は頼めないと、非情ですが早々に判断するようにしています。 少なくともソフトウェア開発の世界では、正確さに大きな価値が置かれています。この業界だけでなく、一般的に、間違いは欠陥か事故であり、基本的に許されないものです。仕事は、紙の試験ではないため、百点満点が当たり前です。タクシーに乗ったら、事故せずに必ずつくことを期待する。手術で手が滑ることや、車を運転して信号を見間違えることは許さ
元司書が語る国立国会図書館を「調べる技術」で最高に役立てる方法
ブログ「読書猿 Classic: between/beyond readers」主宰。「読書猿」を名乗っているが、幼い頃から読書が大の苦手で、本を読んでも集中が切れるまでに20分かからず、1冊を読み終えるのに5年くらいかかっていた。 自分自身の苦手克服と学びの共有を兼ねて、1997年からインターネットでの発信（メルマガ）を開始。2008年にブログ「読書猿Classic」を開設。ギリシア時代の古典から最新の論文、個人のTwitterの投稿まで、先人たちが残してきたありとあらゆる知を「独学者の道具箱」「語学の道具箱」「探しものの道具箱」などカテゴリごとにまとめ、独自の視点で紹介し、人気を博す。現在も昼間はいち組織人として働きながら、朝夕の通勤時間と土日を利用して独学に励んでいる。 『アイデア大全』『問題解決大全』（共にフォレスト出版）はロングセラーとなっており、主婦から学生、学者まで幅広い層か
ハイデガー「技術論」から考える新しいゲシュテル: 極東ブログ
この間というかこの数年ハイデガー「技術論」のゲシュテル（Ge-stell）の視点から情報技術や超国家性について折に触れて考えているのだが、うまくまとまらない。そんなことを書くのはつらいし、およそ読みに耐えるものでもなかろうと思っていたのだが、なんとなく年越し前に少し書いておきたくなった。 ハイデガーの「技術論」は一九六三年に発表されたもので、その後七〇年代から八〇年代、九〇年代と、いわゆるテクノロジー対本来の人間という枠組みで問われてきたように思う。子細に見るなら、七〇年代はサルトル流実存主義の系譜、八〇年代にはニューアカ的な例えばデリダの背景的な後期ハイデガー論とも関係しているだろう。九〇年代には浅薄にジャーナリスティックなハイデガー論も起きたが、今となっては収束したかに見える。現在、ハイデガー「技術論」がどのように問われているのか、もはや時代に問われることはないのか、よくわからない。自
技術の本質について - KAKEHASHI Tech Blog
みなさんは、技術とは何か、考えたことはあるでしょうか。 ここでは、技術哲学の立場から考えるための参考として、ハイデガーの技術論を取り上げます。 技術論のタイプ A.フィーンバーグの技術: クリティカル・セオリーの分類によれば、 これまでの技術論は2つの立場に分けることができる、と考えられています。 道具説 自立的存在説 道具説は、世の中に広く受け入れられている見方で、 技術とは「中立的」であり、利用者の目的に奉仕する道具と考えます。 逆に、技術の中立性を否定する見方として、自立的存在説という見方もあります。 この説では、技術とはそれ自体が社会のすべてを管理の対象物として作り変えようとする、と考えます。 ハイデガーの技術論は、この説の代表的な考え方になります。 ハイデガーの技術論 技術への問い ハイデガーはその著書、技術への問いで、 技術について問うことを、以下のように述べています。 われわ
ソフトウェアエンジニアの“燃え尽き症候群”への対処法とは？ 米国チームが調査
Innovative Tech： このコーナーでは、テクノロジーの最新研究を紹介するWebメディア「Seamless」を主宰する山下裕毅氏が執筆。新規性の高い科学論文を山下氏がピックアップし、解説する。Twitter: ＠shiropen2 米University of California, Irvine（UCI）に所属する研究者らが発表した論文「Mental Wellbeing at Work: Perspectives of Sofware Engineers」は、現役で働くソフトウェアエンジニアのメンタルウェルビーイング（精神的健康）を調査した研究報告である。 ソフトウェアエンジニアは、燃え尽き症候群の割合が高いことが分かっている。そこで研究者らは、米国の多様な職場環境に勤務するソフトウェアエンジニア14人（女性5人、男性9人）を対象にメンタルウェルビーイングに関する調査を行った。
Nostrのrabble氏の投稿の日本語訳
rabble.md fiatjafはブログ記事を投稿しましたが、これがblueskyに関していくつかの議論を巻き起こしました：https://fiatjaf.com/ab1127fb.html これは、bluesky開発者のPaul Frazeeから長いskeetストリームの返信が来たことを引き金にしました：https://staging.bsky.app/profile/pfrazee.com/post/3jv72j3fp6g2r そして、私はいくつかの考えをまとめました： 分散型プロトコルの世界は勢いを増しており、NostrやBlueskyのようなプロジェクトが先頭に立っているのは興味深いことです。私たちの多くは、これらのプロトコルの開発に何年もの時間を費やしており、今では世界中で関心を集めています。私は長い間、さまざまな分散型ソーシャルメディアプロトコルを追跡しており、興味がある方は
開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察
先日サーバントワークスさんが公開した 計測によるスクラムチームのパフォーマンス向上 を読んで、 以前自分が書いた 開発の改善はKPIに翻訳しなければいけないのか をもうちょっと言語化することができそうだったのでメモ。 TL;DR 結論としては、開発の改善はKPIに翻訳しなければいけないのか でも書いた通り 開発組織はビジネスの実現を担っている職能であり、理想的には 「永久に持続性がある状態」で 「0秒 でしかも 並列数を無限」 でモノが実現されて、「不具合やパフォーマンスの劣化は 0」 であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない から考え方は変わってないが、改めて整理して 開発組織は、Ability to Innovate と Time to Market 2つのケイ
人に仕事を振れないパイセン向け：３時間で読めて一生使える本３選 - Qiita
はじめに 開発者として経験を積んで、「人に頼むよりも自分でする方が早いから」 という考えに固執し、「人に頼まず自分でやってしまう」 という壁にぶつかることがあるかもしれません。リーダーに昇格した直後などは、自分で仕事をした経験はあるけれど、人に頼んだ経験がないなどの理由でそのような選択をするかもしれません。 頼んだ相手が自分よりも大きな見積もりを出してしまうことがあります。その場合、自分に多くの作業を割り振ってしまい、「自分だけが忙しくなる状況」 に陥ってしまうこともあります。 そこで今回は、簡単に読めてこういった状況を避けるのに役に立つ本を3冊程紹介したいと思います。 最強のエンジニアになるための話し方の教科書 技術力(200%) x 伝える力(0) = 真のパフォーマンス(0) (出典：最強のエンジニアになるための話し方の教科書) どんなに技術力があってもちゃんと伝えないとダメなんだな
Basic認証、Digest認証、Bearer認証、OAuth認証方式について - プログラミング初心者がアーキテクトっぽく語る
Basic認証、Digest認証、Bearer認証、OAuth認証方式はRFCで標準化されている認証方式の中で最もよく目にする方式だろう。 Basic認証とDigest認証は多くのサーバ、クライントで実装されており導入障壁が低い認証方式だ。 機密性の高いデータを扱うサービスでは比較的安全なBearer認証、OAuth認証方式を目にすることが多い。 ここではBasic認証、Digest認証、Bearer認証、OAuth認証方式について簡単に触れる。 この4つの概要を理解しておけば大体のWebサービスは理解できるだろう。 もしサービスが固有の認証方式を実装していた場合でもこれらの方式との類似性に着目すればすぐに理解できるはずだ。SAMLやOpenIDと言ったより複雑な認証方式を理解する上でも助けになると考える。 1. Basic認証方式 最も理解しやすいのがBasic認証方式だ。RFC 261
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
