〝原爆の父〟と称される天才物理学者の半生を描いた「オッペンハイマー」。第二次世界大戦末期、広島、長崎に投下された原爆開発の舞台裏と天才科学者の葛藤を、壮大なスケールで映像化。日本公開までに曲折を経た一方、アカデミー賞では作品賞、監督賞、主演男優賞など７部門を制覇。賛否渦巻く問題作を、ひとシネマが独自の視点で徹底解剖します。 原爆を開発したマンハッタン計画の責任者ロバート・オッペンハイマーを描いた映画「オッペンハイマー」、ようやく日本でも3月29日から公開されます。ようやくなどと申し上げるのは理由があります。アメリカなど世界各国では昨年7月に上映が始まりましたが、日本ではながらく公開されなかった。日本では公開されないのではないかという観測も流れました。 海外での圧倒的評価　日本でもようやく公開映画の監督は、クリストファー・ノーラン。「バットマン」3部作や「インセプション」など、優れている上に

PHPカンファレンス関西懇親会で若者に「俺だってソフトウェアエンジニアの才能が無いかも…と悩んだことあるよ」って話をした。 そんな悩みを持っていたのは自分が25 ~ 26歳くらいの頃で自分はエンジニアとしてスタートが遅かった（異業種転職組）から、技術力の無さを痛感しながらも、それを才能の理由にしようとしていた。 続けるために必要なのは才能ではない 悩んでいるとき、飲み会で当時の同僚で先輩の @maepon さんに相談した*1ところ、次のことを言われた。 自分が「才能ないかも」と言ったあとに帰ってきた言葉は「もし、お前に才能が無かったとして、じゃあお前はどうするんの？そのifの中に実装があるの？何も無いんだったらそのifについて考える時間は無駄じゃん。必要なくない？」って感じ。 確かに才能が無かったとして、じゃあソフトウェアエンジニアを辞めて別の仕事したいってのがあるなら考えればいいけど、当

Redditで話題になっていたポストを訳してみた。 僕は自分が思っていたほどは頭がよくなかったという高校生の独白にたいしてつけられたこのちょっと長めの返信がとても的確で示唆に富んでおり、多くの人のこころをつかんでいました。私自身、勇気づけられるというか身につまされるところがあり、忘れないために翻訳をしてみました。 まずは高校生の独白から。 僕は自分が思っていたほどは頭がよくなかった 僕はいま高校の最終学年で、次の６月に卒業する予定です。高校の成績は、いままでずっとAを取りつづけていましたが、去年始めてBをとってしまいました。もしそのBがなければ、卒業生総代に選ばれていたでしょう。 総代にふさわしいのは自分だ、つまりクラスで本当に一番頭がいいのは自分だと思いたいです。でもこの一年で、僕にそれほどの知性はないし、僕より頭のいい人はたくさんいるんだということを思い知らされました。 また僕は、自分

若手メンバーのスキルアップのための相談に乗っていると, うまい設計ができるようになる, 仕様の整理やメリット・デメリットの判断がうまくなる, あるいは技術の引き出しを増やすにはどうしたらよいか, という話がよく挙がる. この手の話題にいつも同じようなアドバイスをしていると気づいたので, 説明を楽にするために書き下しておく. ソフトウェア開発の話だけど, もしかしたら一般的な仕事のやり方の話だと思っても成立するかもしれない. 文脈 ソフトウェア開発のプロジェクトを進めるとき, 少人数の精鋭だけで開発するなら極論するとカウボーイコーディングでも成立するかもしれない. そうでなければ, たとえばスクラムのように, なんらか段取りをチームでマネジメントし, 不確実性を下げるためにどういう方法でアプローチするか検討し, 仕様を固めて細かいタスクに分解するプロセス(以降ざっくり「ソリューションを定める

はじめに 仕事に追われる日々から解放され快適に楽しく働くことができる環境を実現するためには、自己管理が重要です。ここでいう「仕事に追われず快適に楽しく働ける状態」とは、自分自身で意思決定を行い、仕事の進行を自らコントロールする能力を身につけることを意味します。 多くのエンジニアは仕事の量や複雑さに圧倒され、自分のペースで仕事を進めることができないという状況に直面しています。しかし、自己管理スキルを身につけることでこれらの課題を乗り越え、より自分起点な働き方が可能になります。 この記事では、よく起きがちな問題とあわせて自己管理を強化するための具体的な方法を示します。 1. 他の人から見て何をやっているかわからない問題 主要なポイント 「あれってどうなってます？」って聞かれていませんか？ これを頻繁に聞かれる場合、確実に何やっているかわからない人だと思われています タスクの状態は、必ず聞かれる

チームで仕事するとき、みんなもう少し自分の存在、自分のリアクションがチームに与える影響を自覚した方がいい。 例えばミーティングでブレストしているとき、議論が前に進むのは、あるときふと場に出されたアイデアに対して、誰かが"それいいですね"って言った瞬間である。アイデアを出したとき、その人にはふつう、確信なんてほとんどない。僕なんか自分の意見に自信なんかなくて(大体みんなそうなのだ)、言ってみて、まわりの反応を見て、あ、なんか良さそうだ…と思ったときにやっと前に進むことができる。みんな、自信なんてないのだ。だからアイデアは、場に出されたときはまだ、波際の砂のお城のようにやわらかである。 しかし、あるアイデアに対して、それいいね、と声をもらったとき。いい顔が見えたとき。姿勢が前のめりになってくるとき。そのときとあるアイデアは、はじめて光るのだ、形になる可能性を見せるのだ。 * 逆に言えば、議論に

開発生産性カンファレンスの講演内容です。

コンサルタントをやっていた時、「この人、コンサルタント向いてないよなあ」という人が何人も中途で転職してきた記憶がある。 例えば「本を1か月に10冊読む」という課題をやらない人。 いつも時間ギリギリにしか行動せず、重要な会合に遅刻する人。 自社の「目標」の達成度合いを気にせず、お客さんの成果にも無関心な人。 別の仕事や、前の会社では許されたかもしれないが、たいてい「コンサルタント」としてはうまくいかない。 私が在籍していたコンサルティング会社は、上のような「問題行動」には非常に厳しく、該当者には「コンサルタントとしての活躍は難しい」と、はっきりと告げていた。 「勤勉さ」は身につかない こうした事例を何度も見るにつけ、私は 「勤勉さ」 「時間を守る」 「目標遵守」 などの行動特性は、たとえ厳しく注意をしても、ほとんど身につかないか、改善したとしても、結局一時的なものにとどまる、という事を知った

前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪

意思決定できる人は進める手順の型みたいなものを持っているように見える。逆に意思決定が遅かったりできなかったりする人は、進めるときに型のうちの何かが欠けているのかもしれない。 体系化された話は書籍で語られつくされているとは思うが、思考整理のために雑にまとめてみる。 最後は決めるだけだという考えを持つ 目的や満たしたいことを明確にする 最終的な決め方や期日を明確にする 選択肢を広げて考える 今は意思決定しない、という意思決定も選択肢に入れる 意思決定の軸を明確にする 軸をもとに定量/定性データを集める 軸をもとに選択肢を評価する 自分はこうしたいという"推し"を決めてたたき台にする ここまでの話をドキュメントにしている ここまでのプロセスに時間をかけない 意見を聞く人を見定めてフィードバックをもらう 最初に明確にした決め方で意思決定する 意思決定できない場合は決め方と期日と意思決定軸を再定義す

キッコーマンです。 @kikkoman_desu キッコーマン公式アカウントです。 おいしい記憶をつくりたい。という思いを込めて、商品情報等を日々つぶやきます。コメントやDMへの返信はできないこともございます。(ソーシャルメディアポリシー・ご利用規約) bit.ly/2r0rxWu bit.ly/2Jtaovn ファンネーム：#キッコー民 kikkoman.co.jp/index.html キッコーマンです。 @kikkoman_desu 紀文さん紀文さん…今、メンションをせずに直接語り掛けています…聞こえますか？ はんぺんを使ったすごい発見をしちゃいました… 粉を一切使わずヘルシーなのに、満足感がすごいお好み焼き風が簡単に作れます… 味つけはあえてソースではなく本つゆで。 だしが効いててめちゃくちゃおいしいです。 pic.twitter.com/OOmuayQaim 2023-05-10

第0部　まずは「分かりづらい説明」を知ろう（p.14～） 第1部　口頭説明編（p.25～） 第2部　資料作成編（p.63～） 第3部　スライド作成編（p.81～） スライドのまとめ（p.115～）

クリエイターに出会ったり、もっとファンになったり、noteで創作をつづけたくなるようなイベントを開催する「noteイベント」。今回は「チャットAI使いこなし最前線」をテーマに、黎明期からチャットAIを活用しているnote CXOの深津貴之氏が登壇しました。こちらの記事では、ChatGPTユーザーの悩みを解決するプロンプトなどが語られました。 ChatGPTユーザーの悩みを解決するプロンプト 徳力基彦氏（以下、徳力）：まず今日はChatGPTの使い方をしっかり覚えていただきたいと思います。ここで「深津式汎用プロンプト」。 深津貴之氏（以下、深津）：僕は1個1個、個別の例を出すのはあんまり好きではないです。さっき言ったように原理原則を1個理解すれば、全部その原理原則から引っ張れる方向が好きですね。 なので今日も、細かいプロンプトを出すよりは、だいたいあなたの悩みのすべてを解決するプロンプトを1

今回はゲーム作りに限らず､心の片隅に置いてほしいこと｡ エンジンが動くから走れるのではない｡ 走り始めることでエンジンに火をつけるのだ!!

「日本国内でもトップレベルのスキルを持ったMySQLエキスパートは誰か？」 そう問われたときに、多くのエンジニアが名前を挙げる人物がいます。LINE株式会社のITサービスセンター データベース室 MySQL1チームでDBA（Database Administrator）として働くyoku0825さん*（@yoku0825）です。 日本人として3人目のMySQL分野のOracle ACEであり、2015年には「default_password_lifetime」の功績でMySQL 5.7 Community Contributor Awardに選出されたyoku0825さん。彼はひたむきに自己研鑽を続けるだけではなく、ブログ「日々の覚書」や技術イベントへの登壇などを通してMySQL関連の情報発信を行ってきました。 今回はそんなyoku0825さんに「これまでどのようなトレーニングをして、DB

プログラマー育成を支援するInitial Commitが、ローカルリポジトリにおけるGitの動作をシミュレート可能なコマンドラインツール「git-sim」を2023年1月22日にリリースしました。git-simを使うことで、Gitコマンドがリポジトリに及ぼす影響を視覚化した画像やアニメーションを生成できます。 git-sim - Visually simulate Git operations in your own repos with a single terminal command. https://initialcommit.com/tools/git-sim GitHub - initialcommit-com/git-sim: Visually simulate Git operations in your own repos with a single terminal c

ライマンの法則（Lyman’s Law）とは？「ふゆ（冬）」＋「したく（支度）」は「ふゆじたく（冬支度）」になりますね。 2つ目の語「したく」の「し」が「じ」に濁音化します。 でも、「ふゆ（冬）」＋「しょうぐん（将軍）」は「ふゆしょうぐん（冬将軍）」です。 「ふゆじょうぐん」と「じ」に濁音化しません。 もう一つ、例を見てみましょう。 「ふゆ」＋「かれ（枯れ）」は「ふゆがれ」で、2つ目の語「かれ」の「か」が「が」に濁音化します。 でも、「ふゆ」＋「かぜ」は「ふゆかぜ」と連濁化しません。 なぜでしょうか？この謎を説明してくれるのが「ライマンの法則」です。 二つの語が結合するときに、後ろの最初の清音が濁音化することを連濁といいます。 例えば、「ふゆ（冬）」＋「したく（支度）」は、「ふゆじたく（冬支度）」になります。 後ろの語（「したく（支度）」）の最初の語（「し」）が濁音化する（「じ」になる）の

本記事は、ラムダノートで発売している『RubyでつくるRuby』を買っていただいた方に「読んで」とお願いするための「私家版、読み方のおすすめ」です。また、この本は当社の本のなかでも過小評価されているところがあると思うので、「気になるけど買ってない」という方に興味を持ってもらうことも目的としています。 本書『RubyでつくるRuby』を買った人にも、まだ買っていない人にも、とにかくまず意識してほしいのですが、この本はRubyの解説書ではありません。 じゃあなんの本かっていうと、これは「そもそもプログラミング言語でプログラムを書くって、なに？」という根本的な問いへの取り組み方を教えてくれる本です。 もう一度言いますが、この本はRubyの解説書ではありません。なので、「Rubyを使うつもりはなくて、PythonとかJavaScriptが好き」っていう人や、「それらのプログラミング言語をいままさに

この時期になると亡くなったあの人を思い出す、というのは誰しもあると思うが、僕にとって正月という季節は、4年前に亡くなった山田のことを思い出す季節だ。 山田祐資（やまだ・ゆうすけ）は大学の1つ下の後輩、2019年1月6日に難治性のがんが寛解せずに38歳でこの世を去った。常にシニカルでコミカルで酔狂を気取る彼は、彼らしいスタイルを保ったまま、自分の死生をしっかり見つめながらこの世を去っていった。 2017年4月18日　NHK EテレハートネットTV「がんと共に歩む力を」より その飄々とした姿は全くもって「山田らしく」、不自然なところは無いかのように僕の目に映っていたのだが、あれから4年経ち、一つの言葉をきっかけとして彼の胸中にまた思いを巡らせている。 『“がん”になったと言うと、哀れみの目で見られる』 これは、別のがん患者の方がこの記事で語っていた言葉だ。 がんになっても... | 生き方 |