Android 14 (Credential Manager) におけるパスキー対応が面倒すぎる
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. DroidKaigiにココらへんの話をしようと思って、CfP書いたけど落ちたので、自分用の覚書。 Firefox (GeckoView) AndroidでCredentail Managerの対応を入れたのが、GeckoViewとしてはバイナリサイズを大きくしたくないため、JetPackを一切使わずにCredential Manager経由でWebAuthn対応を行うコードをJavaでスクラッチで書いた。おそらくJavaでスクラッチで書いたのはChromeとGeckoViewだけだし、おそらくこの2つの製品以外でスクラッチ実装がされることは今後もないと思う。 しかもGeckoViewはWebブラウザエンジンなわけだから、いろんなWebサイトで実行可能な
Java の enum を使いこなせるあなたに sealed interface
はじめに Java の enum は大変便利で非常多くのシーンで活用されています。例えば区分を表すようなオブジェクトを表現したい際にもよく使われていますね。 Java 14 で正式機能となった switch式にて網羅性検査が行えるようになり、それまで以前ではどうしても抽象メソッド等を活用する必要があった処理についても、switch式を利用する事で簡潔に表現することができるようになりました。 また、Java 17 で正式機能となった sealed classes/interfaces と Java 21 で正式機能になった Record Patterns によって、これまで必要だった区分値のような enum を必ずしも定義しなくて良い場合も出てきました。 この記事では、今まで enum を使っていたコードがこれらの機能によってどのように変わるのかを紹介し、盲目的に enum を定義するのでは
Enumとてもつらい、でも負けない - エムスリーテックブログ
列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2. switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi
9時間足すんだっけ引くんだっけ問題～あるいは、諸プログラミング言語はいかにタイムゾーンと向き合っているか - エムスリーテックブログ
私は日付時刻の処理が大好きです。 タイムゾーンの問題でデータ抽出が9時間分漏れていたとか、朝9時の始業前のログが昨日付けになってしまっていたなんていう問題が起こると喜んじゃうタイプ。 そんな私にとって、各プログラミング言語が標準で持っている日付時刻型クラスにはそれぞれ思うところがあり、今日はちょっとその品評会をしてみたいと思います。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@yuba@reax.work) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の2日目です。 至高の日付時刻型を持つ言語、BigQuery SQL 不足はないが蛇足、Java 8 日付時刻で画竜点睛を欠いたC# C#よりややまし、Python 型は良い構成、なのに命名と処理関数で損しているPostgreSQL まとめ We ar
Rust の DI を考える — Part 1: DI とは何だったか - paild tech blog
paild 社でお手伝いをしている yuki です。みなさんは Rust で DI をしようと思った際に困ったことはありませんか？この連載では、他のプログラミング言語で利用される DI パターンを参照しながら、Rust でそれを実装するためにはどのような工夫が必要かまでを検討します。中には Rust での実装が難しいパターンも出てくるかもしれません。その際は、なぜ難しいのかまでを検証します。 そこそこの規模のソフトウェアを実装するにあたって、ソフトウェアエンジニアが共通して利用する手法がいくつかあると思います。その中でも DI (Dependency Injection; 依存オブジェクト注入) は最もポピュラーな手法の一つであり、保守運用まできちんと耐えうるソフトウェアの設計をしたいとなったときに、まず真っ先に候補に上がる手法でしょう。 Rust ではこの DI をどのように行えばよいの
Javaエンジニアだった私が当時困ったRustのコンセプト - paild tech blog
お手伝いの @helloyuki_ です。今回はポエムです。 今回は、Rust を始めた当時、プログラミング言語は Java しかまともに触ったことがない新米若手 Java エンジニアだった私[*1]が「見たことがなく、使いどころがわからなく理解が難しい」と感じたポイントについて紹介します。対象とするソフトウェアのレイヤーが低いか高いかを問わず、とにかく Rust をやってみて理解するまでに時間がかかり、難しいと感じたポイントについて紹介します。 Rust の「メモリ安全」って、結局何 所有権とライフタイム 参照 スマートポインタ 代数的データ型 関数が第一級である モジュールシステム self 型クラスという側面でのトレイト まとめ 私が Rust をある程度使いこなせるようになるまでの話 「難しい」って何？、の話 Rust の「メモリ安全」って、結局何 そもそも論ですが、Rust が取
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
例外を初めて実装した言語 - from scratch
リクルートアドベントカレンダーの20日目の記事です。 adventar.org 最初にこの疑問を思ったのは、今も忘れない R-ISUCON 2021 というリクルートの社内ISUCONの運営で炎上していた時の話です。 ちなみに R-ISUCON 2021 は劇的な結果で終わっているので、興味のある方は見てみてください。 blog.recruit.co.jp R-ISUCON 2021 では、 Node.js (TypeScript), Go, Java の3パターンの実装が出てくることが通例になっていまして、今回は Java の実装から Node.js, Go に適用していた時に一緒に実装していたメンバーからの疑問が『例外には色々な議論があるけれど、「例外を初めて実装した言語」ってどういう気持ちで実装したんだろう』という話が挙げられたので、そのネタを持ってきました。 ちなみにここで指してい
実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
OSSか、それともSaaSか。グローバルを見据えたプロダクト開発へ向けて | DevLounge.jp Opening Session レポート | Wantedly, Inc.
エンジニアリング界をリードする著名人が「いま話を聞きたい」開発者を直接指名し、日頃なかなか聞けない開発トピックについて語り尽くすオンライントークセッション「DevLounge.jp」。このイベントのオープニングを飾ったのは、Nature株式会社VPoEのSongmuこと松木雅幸氏と、ローンチャブル(Launchable）Co-CEOの川口耕介氏です。 Songmu氏は日本で、川口氏はアメリカ・カリフォルニアでそれぞれ活躍されています。セッションでは、お二人が感じるオープンソースソフトウェア(OSS)とSaaSの違いから、グローバル展開を目指す際の考えなどを語っていただきました。その一部をご紹介します。 Songmu(松木雅幸)Nature株式会社VPoE。大学で中国語と機械翻訳を学び、中国でIT分野での起業、語学学校でのシステム担当兼営業、印刷系SIerでの金融系Webシステムや物流システ
フェアユースは認められたが、Googleは対価を支払うべき - Java API訴訟に寄せて - arclamp
ようやく裁判の結果が出ました。結果としてフェアユースが認められたのはよかったのですが、Googleが勝訴したということは素直に喜べないので、その理由を書いておきます。 関連ニュースは、こういったところから。 約1兆円の賠償金を巡るGoogleとOracleの10年にわたる訴訟が決着、「APIのコピー」は結局違法なのか？ - GIGAZINE Google、オラクルの著作権侵害せず 米最高裁判決: 日本経済新聞 グーグル、米最高裁でオラクルに勝訴--「Android」Javaコード訴訟で - CNET Japan 経緯 では、経緯について時系列に沿って整理していきます。推定可能な事実に基づきますが、一部、妄想も含まれています。 2005年 Google（広告収入増やすには無償で改変自由なスマホOSが重要になるはず。普及させるなら開発者の多いJavaベースだよな。でも、クラスライブラリ改変しな
［速報］10年にわたる著作権訴訟でGoogleがオラクルに勝訴、米連邦最高裁判所で判決。Java SEのコードのコピーはフェアユースの範囲
［速報］10年にわたる著作権訴訟でGoogleがオラクルに勝訴、米連邦最高裁判所で判決。Java SEのコードのコピーはフェアユースの範囲 オラクルがGoogleに対して、Android OSがJavaの著作権を侵害しているとして訴えていた裁判で、米連邦最高裁判所はGoogleが著作権侵害をしていないとの判断を示し、Googleが勝訴しました。 以下は米連邦最高裁判所の動向を伝えているSCOTUSblogのツイートです。 BREAKING: In major copyright battle between tech giants, SCOTUS sides w/ Google over Oracle, finding that Google didnt commit copyright infringement when it reused lines of code in its An
優秀さについて
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 白のカピバラの逆極限 S.144-3 はじめに 「【転職エントリ】Googleに入社します｜Lillian｜note」という、医師から未経験で Google のソフトウェアエンジニアになった記事があります。 note.com 私は、この記事に出てくる「とある元 Google のソフトウェアエンジニア」で、面接の対策を立てました。 記事が出た当初から大反響で、私もそれなりの反応を見まして、いろいろと誤解されているなあ、と思う一方、アドバイザーはあくまでもアドバイザーだから、アドバイザーとして知りえた情報については、口をつぐむべきだと思っていました。 ただ、あまりにも誤解されており、悪影響が大きく、犠牲者も多くなってきたと思ったので、… 同僚からこれについてどう思うか、と聞かれた。元の文章が
SpringでField InjectionよりConstructor Injectionが推奨される理由 - abcdefg.....
SpringでField InjectionよりConstructor Injectionが推奨される理由を調べてみたメモです。 (2016/12/30) サンプルコードにfinalをつけるように修正 (2017/03/29) Immutabilityについて追記 --- 家でも会社でもIntelliJを使って開発しているのですが、 Spring Bootで@Autowired(@Inject)を使うと下記のような警告が出るようになりました。 警告内容を見てみると、フィールドインジェクションは推奨されません、とのこと。 「Field injection is not recommended.」 警告の詳細を見てみると下記のように書いてあります。 「Field injection is not recommended. Spring Team recommends: "Always use
Reactor Core 2.5: もう一つのJava向けReactive Extensions実装 - Qiita
Reactive Extensionの調査中にReactor Core 2.5が面白いことに気がついたのでまとめ。 JavaDoc GitHub A lite Rx API for the JVM by Sébastien Deleuze (Spring I/O 2016での発表資料) Reactor Core (2.5) = Reactive Streams + Reactive Extensions(の一部) Reactor(〜2.0)は効率的な非同期プログラミングのためのツールキットで、基本的な関数型(Java8以前に開発されたため)に始まって高効率なスケジューラー上に実装されたReactive StreamsやそのReactive Extensions(Rx)、非同期のネットワークライブラリ等を提供していました。 ところがReactor 2.5を開発するにあたってプロジェクトの構成
IntelliJ Platform 2020年ロードマップ | Post Blog
IDEs AppCode CLion DataGrip DataSpell Fleet GoLand IntelliJ IDEA PhpStorm PyCharm RustRover Rider RubyMine WebStorm Plugins & Services Big Data Tools Code With Me Quality Assurance JetBrains Platform Scala Toolbox App Writerside JetBrains AI Grazie Team Tools Datalore Space TeamCity Upsource YouTrack Hub Qodana .NET & Visual Studio .NET Tools ReSharper C++ Languages & Frameworks Kotlin Ktor MPS Am
現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ - t-wadaのブログ
この文章の背景について この文章はテスト容易性設計をテーマに 2013/11/26 に CodeIQ MAGAZINE に寄稿したものです。残念ながら CodeIQ のサービス終了と共にアクセスできなくなっていたため、旧 CodeIQ MAGAZINE 編集部の皆様に承諾いただき、当時の原稿を部分的に再編集しつつ、ライセンス CC BY（クリエイティブ・コモンズ — 表示 4.0 国際 — CC BY 4.0） で再公開いたしました。 旧 URL にいただいたブックマークとご意見はこちらです（これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE）。旧記事には本当に多くの反響をいただき、誠に感謝しております。 目次 この文章の背景について 目次 出
ArrayListじゃなくListを使うという話 - 日々常々
具象型ではなく抽象型で扱え、インタフェースを使え、みたいなお話に対して。 前置き Javaの話。他の言語だと話は変わります。 「こうするのが絶対的に正解」と言うものではありません。私の現在の選択の説明です。明日になったら違うこと言ってるかも。 主な登場人物は掲題の java.util.ArrayList および java.util.List、そして java.util.Collection と java.lang.Iterable です。 こんな世界観。他のインタフェースやクラスもたくさんありますが、この話の本筋では無いので触れません。 前提として以下を置いています。 フレームワークやライブラリではなく、一つの業務アプリケーションに閉じた話です。ゆえに不特定多数から使われる型ではなく、影響を与えるコードは全て目が届く範囲にあるものとします。 計算量は別の話です。扱うドメインにもよりますが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話 - DMM inside
Project Reactor