2018年9月20日、Quanta Magazine "Titans of Mathematics Clash Over Epic Proof of ABC Conjecture" の翻訳 今回は日本国内向け。どうもこの話では、言語の壁があるせいで日本国内と海外で認識の差がありすぎるところが問題だと思えるので、内外で出回っている情報を相互に訳して提示することをしてみよう、という実験をしている。どのくらいの人々が読んでくれているのか分からないが。 この記事は、Scholze さんと Stix さんが2018年3月に京大を訪れて望月氏と議論し、そのレポートが公表された2018年9月の時点で Quanta Magazine に書かれたもの。筆者の Erica Klarreich さんは数学者でもありサイエンスライターでもある人。

美大ではない総合大学で、作品制作する学生と論文を書く学生を一緒に教えていると、いくつか典型的なすれ違いが起こることに気づく。以下は、作品制作コースの学生が私のゼミで発表するときのために、発表者と聞き手双方のメソッドをまとめたもの。誰かの参考になれば。ゼミ生と共同で作成しました。

個人的な経験を書きますが、ぼくはエンジニア生活 10 数年で 5 社を転職して渡り歩いています。そして、その 5 社すべてでなにかしらの勉強会なり研修なりといったものをやってきました。 そして、それが仕事であろうとなんだろうと自分がエンジニアに研修なり説明会なりをするときは、自分がもらったものを返すつもりでやってきました。そのときそのときは当然所属している会社があるわけですが、その会社のため (だけ) にやったことは一度もありません。プロジェクトによって参加している人の立場も発注元だったり受託開発の常駐エンジニアだったり様々だったので、あくまで一人のエンジニア同士として自分が伝えられることをなるべく伝わるような言い方で伝えるということをやってきました。その中では所属会社へ都合の悪い話も出たりしますが、これは所属会社へのコミットメントとは別の話です (PHP 使ってる会社で PHP の悪い点

ただ、それだけではあれなので、ここでは「どういう人にオススメか」、「どういう心構えで行くといいか」を書きたいと思います。 Ruby（rails）系の人 SmartHR社の技術スタックがrailsなので即コードを読みに行ける自分はRubyよくわからん人なのでバックエンド側はよくわからんかったWebフロントエンド系の人 今の時点ではTypeScript + React + Redux構成は素直なので慣れてる人は見ればすぐわかると思う 開発フロー的にはかなり最適化されてるのでどちらかの環境だけしかわからないというのは問題ないと思いますが、両方わからないと短期間で環境把握できなくて辛いかもしれません。 （自分はRubyよくわからんけど、セットアップで困ることはなかった。もちろん両方知ってるほうがいい） 日数に関しては（普通に会社に所属してると難しいかもしれないけど）3日以上がいいと感じました。1日

なにかにつけ大きな主語を使ったり、隙あらば「○○は死んだ」と言ったりするのはインターネッターの悪い癖だが、ここで私は大きな主語を使いながらネットワーク中立性について書く。 ネットワーク中立性とは「ユーザー、コンテンツ、サイト、プラットフォーム、アプリケーション、接続している装置、通信モードによって差別あるいは区別することなく、インターネットサービスプロバイダ（インターネット接続業者）や各国政府が、インターネット上の全てのデータを平等に扱うべきだとする考え方である」（Wikipedia）である。

クックパッドがハチミツを利用した離乳食レシピや、豚ユッケを掲載していた件で、批判を集めている。CGM（Consumer Generated Media）やウェブ2.0なんて言葉が死語に近付きつつある中、こうしたCGMサービス、Web 2.0企業に対する逆風が今になって強まっているのは偶然だろうか。 一番の例は、Naverまとめだろう。Naverまとめは誰でも投稿できるCGMプラットフォームだが、他者の著作物を転載、再利用したコンテンツが散見されながら、プラットフォーム側はその対応を十分に行っていないと言われている。無断転載はブログ時代にもあったことで、CGMと無法者の関係は今にはじまったことではない。しかし、これまでその矛先はブログ著者など個人に向かうことが多かった。今や批判は「まとめ主」など投稿者よりも、プラットフォーム側へ移りつつあるようだ。 似たような例として、海外でのYouTube

転職するたびにブログ記事を書く必要はないと思いつつ、入社エントリがあったのだから退社エントリもないとダメだろうという自分の中の律儀さに応えるために、なんらか書いてみます。 Facebookには4年前、2012年4月16日に入社しました。Ad Operationという役職でしたが、研修中にMedia Solutionsへチーム名が変わりました。2013年12月にはClient Solutionsに再度変更。「名前が変わってもやることは変わらない」というのはよくある話ですが、実際には会社がすさまじい勢いで大きくなる中で、名前より早くやることが変わっていく状態でした。2014年9月にはそのままClient Solutionsチームのマネージャーになりました。 2015年6月にMarketing Scienceというチームに移籍、Instagramの担当となりました。2016年からはInstagr

Rails 5から、production environmentでのDB破壊系のtaskの実行を防止する仕組みが入りました。 例えば、production environmentでdb:dropを実行しようとすると、下記のようなエラー(ActiveRecord::ProtectedEnvironmentError)が発生します。 $ RAILS_ENV=production ./bin/rails db:drop rails aborted! ActiveRecord::ProtectedEnvironmentError: You are attempting to run a destructive action against your 'production' database If you are sure you want to continue, run the same co

とりあえずHashが何であるかとか、どういう作りになっているかとか、そういうことは既知とする。リストの配列ってことね。←これで何言ってるか分からないおまえらにはこの文章はちょっとはやい。先にデータ構造の教科書を読むことをおすすめ。以下ではHashに登録されるキーとデータのペアのことをentryと呼び、リストの配列と言ったときのリストのほうをbin、配列のほうをbucketと呼ぶ。つまり、

どこの会社でも「1行直すだけでしょ？　そんなに大変なの？」ということを何度も聞かれる (もしくは言外にそのニュアンスを含められる) ので毎度説明するのだけれど、「いや、そう思うだろうけれど大変なんですよ」以外に答えられていなくて、自分でもあまりうまい答えではないなと感じるのでまじめに考えてみた。 まず大前提として1行を修正するのに本当に言われるがままにその1行を直すのであればそれは作業者で世の中にエンジニアなんて職業はいらないわけで、ぼくらの付加価値は1行を直すときに1行の外にあるものを想起できるから価値があるわけです。 じゃあ、どんなことを考えているかというと、まずたいていそんなすぐに安請け合いできないシステムというのは1行を直すときに影響を受ける行数というのは10行や20行ではないことが多い。そこで影響範囲を考えます。途端にこれが1万行になったりする。すると、1万行へ影響が出るのにこれ

アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。 （UI改修なので基本的にフロントエンドからみた内容） これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。 （ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい） そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。 （サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない）