Hello fellow NLP enthusiasts! As the race towards finding better and better neural networks for language modeling continues, I thought it might be a good time to get an overview of the progress made over the years. Enjoy! 😄 Disclaimer: This article is not a complete list of research done in NLP, which would struggle to fit even in several books! Rather, it is a personal overview of some of the mo

Exploring the Implementation of “t.Run”, “t.Parallel”, and “t.Cleanup”

SaaS をアーキテクトをするにあたって、どのような事を考えればよいのか？をまとめました。

UXについて色々と考えることがあり、少し言葉にまとめてみた。何が正しいという話ではないが、率直に感じていることである。 意図されたBad UX 車を運転する人なら経験したことがあると思うが、「近づかないと識別できない信号」というのがある。 この手の信号は、近付くまで青なのか赤なのか判別できない。そのため信号の近くになるまで、このまま進むべきか、ブレーキを踏むべきか、とドキドキさせられる。 先日までペーパードライバーだった私は、当初、スムーズな運転を妨げてストレスを感じさせるこの信号を、液晶の表示角度などの計算を誤った設置ミスだと思っていた。 しかしこれは、複雑な交差点などでの交通事故を防ぐために意図的に仕掛けられたもののようである。 いちドライバーとしては、けっして心地よい体験ではない。しかし、社会全体にとっては良い方向に向かうようデザインされた信号といえる。 このような「意図的にユーザー

以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから

みなさん、こんにちは！採用広報の安田です。 今回は2023年10月19日に開催したChatwork EM Talkシリーズ第二弾となる「ChatworkのEMの頭の中」のイベントレポートをお届けします！ 当イベントでは新メンバーの原を加えた4名でEMとして働く上でのノウハウや考えていることについてお話しました。イベント内でお答えしきれなかった質問のQAもあリますよ！ このnoteは2023年10月19日に実施したイベントのレポート記事です。 部署名や体制はイベント当時のものであり、掲載時と異なる場合があります。 メンバー紹介原 孝治/プロダクト本部 エンジニアリングマネージャー 広告制作会社、印刷会社システム部に勤務の後、産業技術大学院大学を修了。株式会社識学 識学開発部開発責任者、株式会社GA technologies PjM、株式会社ランドネット 経営企画室副部長、株式会社FOLIO

11月のブラックフライデー／サイバーマンデーセールもあり、今年もMac appを中心にいろいろなソフトウェアを導入してみました。中にはきっと使わなくなってしまうものもありそうですが、これは使う使わないだけでなく、実装されているUIの研究をする目的だったり、あるいは単にクリエイターへの「応援」としてでもあったりします。いくつかピックアップしてみます。 Procreate Dreams (iPad)Procreate DreamsはiPadOS向けの2Dアニメーション制作ソフトウェアです。iPadで一番有名なお絵かきソフトウェアの一つ、Procreateを作っている会社が新たにリリースしたアプリケーションです。 私はアニメーション制作をやるようなクリエイターではないのですが、Procreate DreamsはとにかくUIがよくできていて、まずワクワクしてしまったというのもあるのですが、やっぱり

このPDFは「LLM全盛時代の開発プラクティス」というタイトルの資料で、baseballyama氏によって作成されました。内容は主に大規模言語モデル（LLM）を活用した開発プラクティスに関するものです。 主な内容は以下の通りです： 1. **GitHub Copilotについて**: - Copilotの利用が増え、コード提案を受け入れてから精査する流れが一般的になった。 - インターネット接続がないと利用できないことが難点。 - Copilotは開いているファイルを参考にしてコードを提案し、統一されていないコードは提案の精度を低下させる。 2. **AIツールによる効率化**: - AIレビューツールとFigma to Codeツールについて議論。 - AIレビューツールは一般的なアドバイスに留まり、具体的な自社ルールに基づいたレビューが求められる。 - Figma to Codeでは、

仕事においては、「人を助ける」という行為は、美徳に見えますが、意外にもそれなりの思慮を必要とします。 場合によっては、せっかくの行為が、単なる自己満足になることも。 というのも、「助けないこと」と「助けること」を天秤にかけると、あえて助けないほうが良かった、という結果もかなりの頻度で起こるからです。 ＊ 実は昔、私はお世話になった方から「勝手に人を助けるな、「助けてくれ」とはっきり言う人しか、助けないほうがいい」と言われたことがあります。 「どういうことですか？」と聞くと、彼は次のようなことを言いました。 まず、「勝手に人を助ける」とは、はっきりと助けを求められていないのに、何となくその人を助けてしまうこと。 いわゆる「善意」に近い。 しかし「善意」は問題を引き起こしやすい。 なぜか。 一つ目、当人が失敗して反省するという貴重な経験を奪う 命に関わる失敗はまずいですが、オフィスワークでその

当サイト【スタビジ】の本記事では、大規模言語モデル（LLM）の仕組みや種類について分かりやすく解説していきます。ChatGPTなどの大規模言語モデルの基本を理解してこのAI時代の流れに乗り遅れないようにしましょう！ こんにちは！ データサイエンティストのウマたん(@statistics1012)です！ テキスト生成系のAIのChatGPTや画像生成系AIのStable Diffusionをはじめとする様々な生成系AIの登場でAIブームが訪れました。 その中でもChatGPTなどの大規模なテキストを学習した生成系AIモデルを大規模言語モデル（LLM）と呼び注目を集めています。 この記事では、そんな大規模言語モデル（LLM）について分かりやすく解説していきたいと思います！ Youtube動画でも分かりやすくまとめているので是非チェックしてみてください！

先日Quora日本語版でこんな回答を書いたのですが、ついでなので少し文脈情報を付け足してブログの方に再録することにしました。理由は単純で、このブログでディープラーニングの歴史についてまとめた記事を今まで書いてきたことがなく、そしてブログ記事にした方がより認識違いや調査不足などについての指摘をもらいやすいと思われたからです。ということで、以下の説明に関してツッコミがあれば是非コメント欄などにお寄せくださいm(_ _)m (A Neural Network Playground) ディープラーニングを語る上で、その前史であるパーセプトロン、そして（人工）ニューラルネットワークの話題は欠かせません。以下大まかに説明していきましょう。（※歴史解説中では敬称略、各種用語は原則カナ表記*1） パーセプトロンの登場 ミンスキーによる批判と第1の冬の時代 誤差逆伝播学習則と中間層を用いたニューラルネットワ

Have you been in any of these situations? Managers make decisions that’s out of their leagues and everyone else in the team ends up paying for it. Knowledgeable people passively observe without bothering to contribute. Sometimes they are denied access to the room. Developers act like code monkeys, throwing the code over a metaphorical wall for the QA to test and “DevOps” to run. In “you build it,

私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

2023年1月11日より開催された「Regional Scrum Gathering Tokyo 2023」の登壇資料です。 https://2023.scrumgatheringtokyo.org/index.html ----- Visionalのエンジニアリングに関する最新情報はTwitter、ブログで発信しています！📣 ▼Visional Engineering Blog https://engineering.visional.inc/blog/ ▼VISIONAL ENGINEERING Twitter https://twitter.com/VISIONAL_ENG

A list of online resouces relating to "『Team Topologies』" in Japanese. order by created_on DESC.

ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb

みなさんこんにちは。@ryuzeeです。 最近立て続けにプロダクトオーナーを誰がやるとよいのか聞かれることがあったので、パターンとメリット・デメリットを整理しておきます。 なお、組織のサイズや業種、扱っているプロダクトによっても変わってくるので、考え方のロジックとして読んでいただければと思います。 プロダクトオーナーとは？まず最初に前提として、プロダクトオーナーの責任ややるべきことをスクラムガイド（2017）で確認しましょう。 5ページ：プロダクトオーナー プロダクトオーナーは、開発チームから生み出されるプロダクトの価値の最大化に責任を持つ。組織・スクラムチーム・個人によって、その方法はさまざまである。 プロダクトオーナーは、プロダクトバックログの管理に責任を持つ1人の人間である。 (中略) プロダクトオーナーは1人の人間であり、委員会ではない。委員会の要求をプロダクトバックログに反映する