こんにちは、AI・機械学習チームの浮田です。最近、私が筆頭著者の論文が公開されたので、今回はその紹介をします。 発表した論文はこちらです： www.ncbi.nlm.nih.gov この論文では、 胸部X線 (レントゲン) から間質性肺炎を検出するAIの評価を行いました。 結果、このAIを使うことで医師の読影成績が統計的有意に改善しました。 このAIを使うことで間質性肺炎の見落としを減らすことができることが期待されます。 エンジニアリンググループで論文を書くのは珍しい機会でしたが、査読対応など大変な時も経て無事公開することができました。 図1. 今回開発・検証した医療AIの実際の画面。プレスリリースより転載 今回開発・検証した医療AIの概要 有効性を検証するための臨床試験 目的 データセット、実験設定 結果 評価方法の詳細 感想 We're hiring! 今回開発・検証した医療AIの概要

こちらはエムスリー Advent Calendar 2023の14日目の記事です。 こんにちは、デジスマチームの堀田です。普段はデジスマチーム*1でWebフロントとバックエンドの開発を行なっていますが、 サブタスクとしてデジカル*2のiOSアプリの改善も行なっています。 改善には軽微なバグ修正も含まれていましたが、新機能の追加や大幅な変更が行われることもありました。その結果、初期のバージョンからは大きく変貌を遂げています。 良いタイミングなので、このプロジェクトの歴史をまとめようと思いました。 初めまして、手書きアプリ 認証機能周りの強化 Main.storyboardからカルテ画面の切り出し PencilKitの検討 iPhoneアプリ 〜カルテビューワー〜 のリリース カルテビューワーのデザインリニューアル カルテビューワー in 手書きアプリ機能 〜miniPhone機能 〜 Git

KeebKaigi 2023 レポート ～Rubyコミュニティと自作キーボードコミュニティのつながりから生まれたイベント 2023年5月11日から13日に行われたRubyKaigi 2023のプレイベントとして、5月10日に自作キーボードに関するイベントであるKeebKaigi 2023が長野県松本市のコワーキングスペース33GAKUにて行われました。 会場入り口 KeebKaigiとは なぜ、RubyKaigiのプレイベントに自作キーボードのイベントが行われたのでしょうか？ 近年のRubyKaigiの会場では、RubyKaigiの参加者たちが自主的に自作キーボードを持ち寄り廊下でミートアップが開催されていました。 そして今年の開催地である松本市には、44キーの分割キーボードであるSilverBulletや、自作キーボードの試作に便利な基板である無限の可能性の設計者である王立魔界鍵盤製作所

こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 これまでは、中村の記事で宣言した 「医師版Stack Overflow」(12/16に正式名称Docpediaとしてリリースされました) の技術的チャレンジの 記事を続けて書いていたのですが、今回はここで宣言しなかったClean Architectureについて書きます。 浪江駅（なみええき）は、福島県双葉郡浪江町にある、東日本旅客鉄道（JR東日本）常磐線の駅。本文には特に関係ありません。 Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘出版社/メーカー: ドワンゴ発売日: 2018/08/01メディア: Kindle版 なぜ書くのか 参考にできる実例を増やしたい Tech Blogはそのままドキュメ

エンジニア組織の内製化を進めるには、事業構造、事業戦略、企業文化、人材などの所与の条件を踏まえて、最適な方法を実践することが求められる非常に難易度の高い取り組みです。エス・エム・エスは2015年よりエンジニア組織の内製化に取り組んできました。そのプロセスとそこで得られた反省や学びを技術責任者の田辺に聞いたインタビューの後編です。 tech.bm-sms.co.jp 前編では、2015年の入社から1年半くらいの間にやったことを話しました。リサーチから始めて会社の特性を理解しにいくということと、小さく始めて検証をするというスタートをきり、小さな新規サービスの立ち上げに上流からかかわって、アジャイルな開発がうまくいったということでした。 エス・エム・エスは当時40近い数のサービスを展開していたのですが、最初の1年半で内製化を進める主要なサービスと注力をせず終了するサービスや CMS 化で開発能力

blog.hatenablog.com 3社に訊く、技術ブログの活用・運用法 モデレーター 株式会社はてな 取締役 サービス・システム開発本部長 大西康裕氏 登壇者 エムスリー株式会社 執行役員VPoE/PdM 山崎聡氏 富士通株式会社 研究本部 先端融合技術研究所 主任研究員 横田耕一氏 LINE株式会社 Developer Successチーム 桃木耕太氏 セッション 企業によるブログを活用した技術情報のアウトプット ブログの目的 エムスリー 圧倒的採用目的 テック系で知られてなかった 書くのを楽しむ人が増えた、エンジニア同士のコミュニケーションにも 月7-14本 富士通 技術ブランディング目的 ビジネス寄りとは切り離して純粋に技術寄り 月1-2本 LINE 採用とブランディング 知ってもらうため 会社は知られてても中で何しているかは知られてない 月1-7本 KPI エムスリー 明確に

はじめに はじめまして。エムスリー AI・機械学習チームの河合(@vaaaaanquish)です。 本記事投稿日と同日、エムスリーが開発しているOSSのうちの1つであるgokartのversion 1.0.0をリリースする運びとなりました。 本記事は、これまでのgokartの軌跡と成果を紹介しつつ、内情を含めながら、gokart 1.0.0に込めた想いを綴るものです。 はじめに gokartとは gokart 1.0.0 ドキュメントの拡充とロゴの追加 gokart.build gokartメジャーバージョンリリースに寄せて おわりに gokartとは gokartは、元チームリーダーであった西場さん@m_nishibaが、AI・機械学習チームを1人立ち上げた際、チームの基盤となるよう作成した、機械学習パイプラインを取り扱うPythonモジュールです。 github.com 機械学習のパイ

Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき？」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数） 実装の指針

未来の自分のためのメモです。 仕事でやってないせいですぐ忘れるし、都度思い出すの大変なので・・。 ただまぁだいたいの人はSkyWayとかEasyRTCとか何かしらのライブラリを使うはずで、そういう人たちにはあまり関係ない内容かも。 生のjsでWebRTCを書くときに、先に知っておきたかった系のメモです。 素人ではないがベテランでもない、そんな微妙な知識レベルだと思います。 まだ枯れた仕様ではないので、記事を読む時は日付に注意してください... WebRTC is 何 WebでRealTimeCommunicationできる仕様 もといクライアントどうしでP2Pで通信できる仕様やそのAPI群 See WebRTC Home | WebRTC 仕様まわり WebRTC 1.0: Real-time Communication Between Browsers Identifiers for W

達人プログラマーを読んだせいか、最近よく考えてることでもあるので、この際なのでポエムにしてみた。 受託の会社バイアスはあるかもしれないけど、基本的にコードを書くエンジニアには通ずるところがあるはず。 設計に時間をかける これは、「いきなりエディタに向かってコードを書き始めない」ということ。 フォーマットはなんでもいいけど、 まずどういうものを実装しようとしていて 愚直にやるならこうする それによって既存のコードに影響がないか 過去のコードと一貫しているか 他の要件とぶつからないか etc.. などなど一通り思案して、必要ならメモを書いて、頭の中でコードをイメージする作業を先にやる。 そしてイメージできたものを、ガッとエディタに打ち込んで動くコードにしていく。 もちろん書いてみてはじめて気づく落とし穴もあったりするけど、その時はまたエディタから離れる。 コードを見てコードを治そうとすると、あ

どうも。ユアマイスター星（@inase17000）です。 このブログもしばらくイベントやニュースの告知だけになってしまっていました。。。 今回は久しぶりの技術記事。先日から利用をしているSendgridとAWSの機能紹介と、恥ずかしながらハマったところをシェアします。 それでは行ってみましょう！ 前提条件 ユアマイスターではシステムからメールを送信するときに、Sendgridというメール配信サービスを利用しています。 ユーザがご自身でフォームに入力したメールアドレスに対して、メールを送信するのですが、どうしても誤字脱字の記入ミスや、他のいろいろな理由により、メールが届かないことがあります。 その結果、ユーザへの連絡に気づいてもらえなかったり、システムのフローにおいて支障をきたすことになるので、定期的にお問い合わせの発生やトラブルの原因となるリスクを孕んでいました。 システムからSendgr

こちらはAWS Containers Advent Calendar 2020の13日目の記事です。 本記事は個人の意見であり、所属する組織の見解とは関係ありません。 とてもこまか〜い話ですが、Amazon ECSのタスク定義設定ではCPUのリソース設定に関して以下の２つのパラメータがあります。この２つのパラメータがどんな挙動をするのか気になりましたのでドキュメントと実機での挙動確認から調べてみました。最後にOSレベルですが素潜りもしてみました。(時間があればcgroupのコードも確認したかったのですが時間がなく、残念) タスクサイズのCPU: タスクに使用される CPU量。 コンテナ定義レベルでのCPUユニット: コンテナ用に予約した cpu ユニットの数 長い記事になってしまったので調査結果の結論を先に行ってしまうと、以下の通りになりました。 コンテナのCPUユニットは、 各コンテナに

【追記】2023年3月21日 YAPC::Kyoto 2023で、ジョブキューシステムFireworqの設計と運用実績も含めて発表されました。id:tarao ++ 【加筆修正】 2020年2月16日 執筆時から6年も経過していますが、たまたまこの記事を振り返る機会があったので、日本語がおかしいところを一部修正したり、一緒に取り組んだ方々の名前が書かれていなかったところを修正しました。 【追記】2017年12年24日 このエントリのジョブキュー実装がFireworqという名でOSSとして公開されました。id:tarao ++ github.com この記事ははてなエンジニアアドベントカレンダー2014の4日目です。 前回は Mackerelで採用している技術一覧とその紹介 - Hatena Developer Blog でした。 社内の開発合宿で、 id:taraoさん、id:hakobe

自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ

pprof って go のやつでしょ？　node のプロファイルが取れるわけ無いやろ，と僕も思っていたんですが以下のライブラリを使うことで取れることがわかりました． github.com 使い方については Using the Profiler に書いてあるとおりで，アプリケーション側に const profile = await pprof.time.profile({ durationMillis: 10000, // time in milliseconds for which to // collect profile. }); const buf = await pprof.encode(profile); fs.writeFile('wall.pb.gz', buf, (err) => { if (err) throw err; }); という風に書いてあげるとwall time

「Offersエージェント」では、業界で活躍するプロフェッショナルがあなたの転職を徹底サポート。CxO経験者を含む現役エンジニア・デザイナー・プロダクトマネージャーが在籍し、職種に特化した専門的なアドバイスをご提供・非公開求人の紹介も可能です。 →【かんたん30秒】無料登録で転職相談する 今の案件内容と獲得経路 Javaをメインにフリーランスエンジニアをしている、いろふ（@irof）です。システム開発の仕事は10年以上、フリーランスとして独立して4年目になります。 会社員をしていた頃は主に企業内で使われる基幹システムの開発に携わってきました。フリーランスとしてはシステム開発だけでなく、Javaに限らない技術支援やチームビルディングのサポートなどいろいろさせてもらっています。コミュニティ活動として関西Javaエンジニアの会などをやっています。 ▲JJUGでの直近の登壇資料 今回は、フリーラン

クラウドワークスのエンジニアの森田（@minamijoyo）です。 ついにRails5がリリースされましたね。今日はRails5じゃないですけど、Rails3/4並行稼働させた話をしようと思います。Railsバージョンアップを検討している方々の参考になれば幸いです。 はじめに 去る2016/03/28 「Rails Upgrade Casual Talks」というイベントでRails3/4並行稼働させる仕組みを作ってる話をしました。 イベントの模様はエンジニアブログにきびたん(@ctokoro_me)がまとめてくれてるのでこちらを参照して下さい。 engineer.crowdworks.jp 上記のイベントで発表した内容はこちらです↓ Railsバージョンアップを段階的に行うためにRails3/4並行稼動させる仕組みを作ってる話 from Masayuki Morita www.slide

くぼた・まさき／テレビ情報番組制作、週刊誌記者、新聞記者、月刊誌編集者を経て現在はノンフィクションライターとして週刊誌や月刊誌へ寄稿する傍ら、報道対策アドバイザーとしても活動。これまで200件以上の広報コンサルティングやメディアトレーニング（取材対応トレーニング）を行う。 著書は日本の政治や企業の広報戦略をテーマにした『スピンドクター "モミ消しのプロ"が駆使する「情報操作」の技術』（講談社α文庫）など。『14階段――検証 新潟少女9年2カ月監禁事件』（小学館）で第12回小学館ノンフィクション大賞優秀賞を受賞。 情報戦の裏側 できれば起きてほしくない「不祥事」だが、起きてしまった後でも正しい広報戦略さえ取れば、傷を最小限に済ませることができる。企業不祥事はもちろん、政治家の選挙戦略、芸能人の不倫ネタまで、あらゆる事象の背後にある「情報戦」を読み解く。 バックナンバー一覧 ネット上で一方的に

転職活動中にブログでやらかすのもアレなので更新を止めていました。*1 つまりなにしたの? 新卒から5年間働いたNECを退職しました。いわゆる退職エントリです。 退職エントリが嫌いな方、昨年流行った過激なエントリを期待している方には不向きな記事なのでここから離脱してください。 上司や一緒に働いた皆さんはお世辞抜きにすごい人たちでした。 なんで入ったの？ ソフトもハード(電気・電子)も経験のある人になりたかったのと、日常生活や個人では関わることすらないようなものを作れるの面白そうって思ったからです。 どんな仕事してたの？ 私は新卒でハードウェアの設計開発職に就きました。もともと情報科学の専攻だったのですが、ハード（センサとかモータとかFPGAとか）もやらせてくださいなんでもしますからって言ったらやらせてくれました。 もうこの時点でNECの（私の上司たちの）懐の広さがおわかりかと思います。 情報