これは、私たちの未来の物語 ――。 21世紀に始まったAIの圧倒的な進歩は、 社会の発展に寄与する一方、高い知性を持つ機械を道具として使う是非を、 人類に突きつけた。 そして22世紀後半。人々は「産業AI」とは別格の存在として、 人権を持った「ヒューマノイド」を当たり前に受け入れ、 共に暮らしている。 須堂光は、ヒューマノイドを治す新医科の医者として、 ヒトとAIの共存がもたらす「新たな病」に向き合っていく。 時に、裏の顔も使いながら……。
![TVアニメ「AIの遺電子」公式サイト](https://cdn-ak-scissors.b.st-hatena.com/image/square/83cb78e4b00035b747ed057fcbf52411a6a57b7c/height=288;version=1;width=512/https%3A%2F%2Fai-no-idenshi.com%2Fassets%2Fimg%2Fogp.jpg)
わたしは未だに自分が「仕事ができない」感がある。いや、たぶん思い込みじゃなくて、本当にそうだと思う。周りと比べても意味はないのだが、明らかにプログラミングのスピードが遅いし、ソリューションや思考の精緻さに欠ける。アメリカのテックカンパニーの人員削減が盛んだしいつ首になってもおかしくないと思う。 「向いていない」エンジニアへのあこがれアメリカで自分がしたかったことは、今度こそ胸を張って「エンジニアです」といえるようになること。何かを作れる人間になること。これは今までの人生で一度もかなっていないことだ。だから、正直なところ「向いていない」と自覚している。 だから、自分と一緒に働いているVincentに聞いてみた。彼は私よりずっと若いけど仕事をしっかりできる。私よりずっとプログラミングも素早いしロジックをよく覚えているし、複雑なリファクタリングもこなせる。 同僚の要領を得ない回答 彼にどうしたら
この疑問はもう俺の中で何十年もくすぶっているんだが、未だにその答えは見つかっていない。 そもそも俺はコンピュータサイエンスというものをよくわかっていないというのもあるんだが、プログラマーをやっていてコンピュータ・サイエンスの素養がなくて困ったことがない。 学生が言うところのコンピュータ・サイエンスが社会に出て何の役に立つんだよっていう話がしたいんじゃない。 ここに吐き出しつつ自分なりに問題を噛み砕いてみたい。 フラフラ思いつくままに書いているから頭悪い文章になることだけは先に宣言しておく。 仕事をしているうえでなんで困らないのかまずコレが最も重要なポイントだと思うんだが、仕事でプログラム書いていて、コンピュータ・サイエンスの素養がなくて困ったことがない、例えばコンピュータ・サイエンスのボキャブラリがないと会話すらままならないなんて言うことは起きたことがない。 更に言うならば要件定義をコード
Wasmはなぜセキュアなのか? 前回Wasmのバイナリを読んでみたが、実行時にどのようにセキュアに実行しているのか気になったので調べてみた。 とりあえず今回も公式ドキュメントを見ながら整理しつつ、実際のコードも無理なく辿れそうなところはwasmerの実装を参考に見ていきたいと思う。 Wasmの目指すセキュリティ とりあえず公式の記載を脳死で読解していく。 The security model of WebAssembly has two important goals: (1) protect users from buggy or malicious modules, and (2) provide developers with useful primitives and mitigations for developing safe applications, within the
November 2022 When interviewing programmers, I often ask them to code a simple program to count word frequencies in a text file. It’s a good problem that tests a bunch of skills, and with some follow-up questions, allows you to go surprisingly deep. One of the follow-up questions I ask is, “What’s the performance bottleneck in your program?” Most people say something like “reading from the input f
ジェフ・ヒューストンのブログより。 QUICトランスポート・プロトコル(RFC 9000)は、オリジナルのTCPトランスポート・プロトコルを改良したものに過ぎないという一般的な見解があります[1][2]。私は、この意見に同意し難く、私にとってQUICは、通信のプライバシー、セッション制御の完全性、柔軟性の面で、アプリケーションが利用できるトランスポート機能における重要な変化を象徴しています。QUICは、より多くの形式のアプリケーションの動作に本質的に役立つ、異なる通信モデルを体現しています。そうです。TCPよりも高速です。私の意見では、公衆インターネットは、いずれQUICがTCPに取って代わると思っています。ですから、私にとってQUICは、TCPに少し手を加えただけのものではありません。ここでは、TCPとQUICの両方について説明し、QUICがトランスポート・テーブルに加えた変更について見
2022年11月7日(月) 「現場で役立つシステム設計の原則 - Forkwell Library #9」 発表資料
Russ Cox, for the Go team 10 November 2022 Today we celebrate the thirteenth birthday of the Go open source release. The Gopher is a teenager! It’s been an eventful year for Go. The most significant event was the release of Go 1.18 in March, which brought many improvements but most notably Go workspaces, fuzzing, and generics. Workspaces make it easy to work on multiple modules simultaneously, whi
Alright, let’s mention the elephant in the room. Earlier this week, the article announcing the 1.65 release of the Rust programming language included this little aside: Before going into the details of the new Rust release, we’d like to draw attention to the tragic death of Mahsa Amini and the death and violent suppression of many others, by the religious morality police of Iran. See https://en.wi
スピーディにテストケースを再利用するノウハウや技術、そしてテストの「実行」ではなく「設計」の自動化に着目したアプローチ法について考える「品質か?開発スピードか?大規模アジャイル時代の品質確保」。ここで株式会社ベリサーブの朱峰氏が登壇。ここからは、過去と現在のITプロダクトへの考え方の移り変わりから、大規模アジャイルへの向き合い方について話します。前回はこちらから。 過去と現在のITプロダクトの前提の違い 朱峰錦司氏:主題の1つである「大規模」についてお話しします。スライドにチャートを貼りました。私見ではありますが、アジャイルという開発の文化はわりと小規模なWebプロダクトだったり、モバイルというアーキテクチャの拡大が伴ったものだったり、そういった製品ドメインから、小さなチームで素早くやるところから始まったものととらえています。しかし、今ではどこもスケールの課題にぶち当たりつつあると考えてい
AWS Dev Day 2022 Japanの登壇に用いた資料です https://aws.amazon.com/jp/events/devday/japan/?aws-dev-day-2022-japan-cards.sort-by=item.additionalFields.sortOrder&aws-dev-day-2022-japan-cards.sort-order=asc&awsf.aws-dev-day-2022-japan-filter-session-category2=*all&awsf.aws-dev-day-2022-japan-filter-track=track%23track-a&awsf.aws-dev-day-2022-japan-filter-dev-type=*all&awsf.aws-dev-day-2022-japan-filter-dev-sub
はじめに こんにちは。2022 年 7 月に入社したエンジニアの浅見(@astatsuya1)です。 今回は 20%ルールで実施した問題の早期発見をして開発体験を上げるために行ったことを紹介します。 はじめに コミューンの 20%ルールとは 何をやるか考えた commmune の開発における問題と課題 問題:問題の発覚が遅くなると多くの人を巻き込んでしまう 課題:出来るだけローカル環境で問題を検知したい 施策 ①:検知する項目を増やす リントでチェックする項目を増やす ローカル開発のみでしか使用しないconsole.logに警告を出す ローカル開発でのみしか使用しないtest.only, test.skipに警告を出す 英語のスペルチェックをする 施策 ②:ローカルでも出来るだけ早く検知出来るようにする コードを書く時のチェック Visual Studio Code の拡張を共有 書いたコ
2018年のある時期、時間にすると一週間くらいの間に Google、Facebook、Amazon、Apple、LinkedIn、Yelp からソフトウェアエンジニアとして働くオファーを受けることができました。ここでは、私がこれらの会社と、どのように年収交渉をしたかを紹介します。 本記事は英語で書かれた How I negotiated a $300,000 job offer in Silicon Valley という記事の翻訳記事です。一部の文章はより理解しやすいものとするため意訳をしています。また、現在のドル円相場は執筆時点で150円/ドルで推移しており、$300,000 は日本円にして4500万円程になります。しかし、当時この記事が執筆された時点では 109 円前後であるため、1ドル == 100円というレートでもって計算をしています。 長い面接の苦労もあとわずかです。大手ハイテク
yaml、どうしてこんなに使われているのだろうか。kubernetesにも責任があるというのはありそうな話だけど、色々考えてみるとそこまで簡単な話でもなさそうな気がする。例えばtravis-CIの設定ファイルがyamlであったりというように、この分野ではyamlは割と広く使われていたんじゃないかという気がする。思い起こせばGoogle AppEngineもapp.yamlに設定を書いていたし、設定にyamlというのは割とよくあることであった、のではないかなあ。 しかしなぜyamlなんだろうか。yamlのフォーマットには問題がたくさんあることが知られているし、自分も全く好きではない。 例えばyamlの問題の一つとして、キーに任意のデータ構造を持ってこれるという話があり、これが一部のプログラミング言語で問題を厄介にしている。またエイリアスがあってデータ構造がツリーにならない(複数の経路から同じ
背景 ゴリゴリ系エンジニア、pageoです。 TwitterでMtgのあるべき姿についてツイートしたところ、ぼちぼちRT/いいねをもらえたので記事を書くことにしました。(お友達欲しいのでフォローしてください🙏) 最近大手クライアントとのPJに関わることが増えてきたのですが、事前アジェンダ共有なしに急にMtgが開催されるなどの無法地帯な場面に何度か遭遇したので、今回の記事では"Mtgの型"のあるべきについて自分の見解をまとめてみました。 はじめに Mtgの型 以下の章で紹介する"Mtgの型"はMtgというより議事録の書き方に寄っていますが、以下の章に書かれたことを実践することにより劇的にMtgの生産性は上がると思うので、この記事を機に是非自分/組織全体の"Mtgの型"について議論や検討をしてみてください。 いきなり結論 "Mtgの型"で説明する"教え"は以下の4つだけです 第一教: ~アジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く