2026年8月31日 API レベル36+ の件

もう疲れました。

Google PlayアプリのターゲットAPIレベル要件
2026年8月31日から開始:

・ Google Playに提出される新規アプリおよびアプリのアップデートは、Android 16(APIレベル36)以降をターゲットにする必要があります。ただし、Wear OSおよびAndroid Automotive OSアプリはAndroid 15(APIレベル35)以降をターゲットに、Android TVおよびAndroid XRアプリはAndroid 14(APIレベル34)以降をターゲットにする必要があります。

・既存のアプリは、アプリのターゲットAPIレベルよりも高いAndroid OSを実行しているデバイスで新規ユーザーが引き続き利用できるようにするには、Android 15(APIレベル35)以上をターゲットにする必要があります。Android 14(APIレベル34)以下をターゲットとするアプリ(Wear OSおよびAndroid TV向けのAndroid 13(APIレベル33)以下、Android XR向け、Android Automotive OS向けのAndroid 12(APIレベル31)以下を含む)は、アプリのターゲットAPIレベルと同じかそれ以下のAndroid OSを実行しているデバイスでのみ利用可能です。

アプリのアップデートにさらに時間が必要な場合は、2026年11月1日まで延長を申請できます 。アプリの延長申請フォームは、今年後半にPlay Consoleからアクセスできるようになります。

👉 Target API level requirements for Google Play apps - Play Console Help

実質のユーザ利用の端末OSレベルが API 36+ で 22.3% ということなのですが。

アプリ開発側だけが辛い感じで。

みなさんは、どう思ってますか。


ComposableView の闇

Jetpack Compose を導入したからといって、アプリが「Compose アプリ」になったわけではありません。

多くのプロジェクトでは、XML を ComposeView に置き換えただけで移行を終えています。

しかし、その状態は Compose の世界と View の世界の両方を同時に抱える アーキテクチャです。

一見すると移行できたように見えますが、実際には複雑さが増えていることも少なくありません。

 

🧑🏻‍💻 Compose に見えて、実は View

ComposeView は名前の通り View です。


Activity
└── Fragment
    └── ComposeView
        └── Composition

つまり、Compose を書いていても、

- Activity のライフサイクル
- Fragment のライフサイクル
- View のライフサイクル
- Composition のライフサイクル

という複数のライフサイクルの上で動いています。

Compose 本来のシンプルさは、この時点ではまだ得られていません。

 

🧑🏻‍💻 View のルールから逃げられない

Compose だけなら意識しなくて済むことも、ComposeView では必要になります。

例えば Composition の破棄タイミング。


composeView.setViewCompositionStrategy(
    ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
)

これを適切に設定しなければ、Composition が期待どおり破棄されないケースがあります。

Compose アプリでは考えなくてよいことを、ComposeView では考える必要があります。

 

🧑🏻‍💻 Fragment は消えていない

ComposeView を使う構成は、多くの場合こうなります。


Fragment
    ↓
ComposeView
    ↓
Composable

これは

Fragment を Compose に置き換えた

のではありません。

実際には

Fragment の中へ Compose を埋め込んだ

だけです。

Fragment の責務もライフサイクルも Navigation も、そのまま残っています。

 

🧑🏻‍💻 「View を Compose に置き換える」は移行の半分

Compose 化というと、多くの人は View を Composable に書き換えることを思い浮かべます。

しかし、本当に変わるのは UI だけではありません。

Compose First の設計では、

- Fragment が不要になる
- XML が不要になる
- ViewBinding が不要になる
- FragmentManager への依存が減る
- Navigation の考え方が変わる
- State の持ち方も変わる

つまり、アーキテクチャ全体が変わります。

 

🧑🏻‍💻 Navigation 3 が示している未来

Navigation 3 のサンプルを見ると、Fragment は登場しません。


Activity
    ↓
NavDisplay
        ↓
Composable Screen

画面そのものが Composable になり、状態は Compose の仕組みを中心に管理されます。

ここでは ComposeView は必要ありません。

Compose がアプリの土台になっています。

 

🧑🏻‍💻 ComposeView は悪者ではない

もちろん ComposeView が悪いわけではありません。

既存アプリを段階的に Compose へ移行するには、とても重要な仕組みです。

大規模アプリでは、一気に Compose へ移行できるケースはほとんどありません。

だから ComposeView は今でも価値があります。

問題なのは、

ComposeView を使っている状態を「Compose 化が完了した状態」と思ってしまうことです。

 

🧑🏻‍💻 本当の Compose 化とは

本当の Compose 化は、単に XML を消すことではありません。


XML
    ↓
ComposeView
    ↓
Fragment を減らす
    ↓
Navigation を Compose 中心へ
    ↓
State 管理を Compose に合わせる
    ↓
Single Activity

この変化によって初めて、

Compose のシンプルな設計思想をそのまま活かせるようになります。

 

🧑🏻‍💻 おわりに

「ComposeView を使っています。」

この一文だけでは、そのアプリが Compose アプリなのか、View アプリなのかは分かりません。

もし ComposeView が Fragment の中にあり、Fragment Navigation の上で動いているなら、それはまだ View ベースのアプリに Compose を埋め込んでいる状態です。

Compose の本当の価値は、UI を書き換えることではありません。

アーキテクチャそのものをシンプルにできること。

そこまで進んだとき、ようやく「Compose 化した」と言えるのではないでしょうか。


【Kotlin】コピペで使える「null」を消すテクニック頻出順40

 

🧑🏻‍💻 1. Non-null を基本にする


// 悪い
val name: String?

// 良い
val name: String

Nullable を作らないことが最も重要。

 

🧑🏻‍💻 2. DTOだけ Nullable


data class UserResponse(
    val name: String?
)

外部データだけ Nullable にする。

 

🧑🏻‍💻 3. Domain は Non-null


data class User(
    val name: String
)

アプリ内部では Non-null を維持する。

 

🧑🏻‍💻 4. Repositoryで吸収する


fun load(): User =
    api.load()?.toUser() ?: User.EMPTY

Repository より先へ Nullable を持ち込まない。

 

🧑🏻‍💻 5. デフォルト値を使う


data class User(
    val name: String = ""
)

初期値で null を不要にする。

 

🧑🏻‍💻 6. orEmpty()


val name = user.name.orEmpty()

null を空文字へ変換する。

 

🧑🏻‍💻 7. emptyList()


fun users(): List<User> = emptyList()

List? を返さない。

 

🧑🏻‍💻 8. emptyMap()


fun settings(): Map<String, String> = emptyMap()

Map? を返さない。

 

🧑🏻‍💻 9. emptySet()


fun tags(): Set<String> = emptySet()

Set? を返さない。

 

🧑🏻‍💻 10. ?: return


val user = repository.find(id) ?: return

null を早期に除去する。

 

🧑🏻‍💻 11. ?: continue


val name = user.name ?: continue

ループ中の null をスキップする。

 

🧑🏻‍💻 12. ?: break


val item = iterator.nextOrNull() ?: break

null を終了条件として扱う。

 

🧑🏻‍💻 13. ?: error()


val token = token ?: error("Token required")

あり得ない null は即座に失敗させる。

 

🧑🏻‍💻 14. mapNotNull()


val names = users.mapNotNull { it.name }

変換と null 除去を同時に行う。

 

🧑🏻‍💻 15. filterNotNull()


val names = names.filterNotNull()

Collection の null を取り除く。

 

🧑🏻‍💻 16. Flow filterNotNull()


val users: Flow<User> =
    repository.userFlow.filterNotNull()

Flow の null を流さない。

 

🧑🏻‍💻 17. firstOrNull() ?: return


val user = users.firstOrNull() ?: return

最初の要素が無ければ早期終了する。

 

🧑🏻‍💻 18. by lazy


private val repository by lazy {
    UserRepository()
}

遅延初期化で Nullable を不要にする。

 

🧑🏻‍💻 19. Smart Cast(ローカル変数へ退避)


val user = currentUser ?: return

println(user.name)

Smart Cast を有効にして !! を避ける。

 

🧑🏻‍💻 20. StateFlow を Nullable にしない


private val uiState =
    MutableStateFlow(UserUiState())

StateFlow より状態オブジェクトを持つ。

 

🧑🏻‍💻 21. Compose State を Nullable にしない


var uiState by mutableStateOf(UserUiState())

mutableStateOf より状態オブジェクトを持つ。

 

🧑🏻‍💻 22. Java境界で Non-null 化する


val title: String =
    javaApi.title.orEmpty()

Platform Type (String!) を入口で閉じ込める。

 

🧑🏻‍💻 23. requireNotNull()


val user = requireNotNull(user)

引数や入力値の null を早期に拒否する。

 

🧑🏻‍💻 24. checkNotNull()


val database = checkNotNull(database)

オブジェクトの状態が不正なら失敗させる。

 

🧑🏻‍💻 25. Null Object Pattern


interface Logger

object EmptyLogger : Logger

Logger? の代わりに空実装を使う。

 

🧑🏻‍💻 26. sealed class / interface


sealed interface UiState {
    data object Loading : UiState
    data class Success(val users: List<User>) : UiState
    data class Error(val message: String) : UiState
}

null の代わりに状態を型で表現する。

 

🧑🏻‍💻 27. Result


fun load(): Result<User>

失敗を null ではなく Result で表現する。

 

🧑🏻‍💻 28. value class


@JvmInline
value class UserId(val value: Long)

IDなどを専用型にして null を減らす。

 

🧑🏻‍💻 29. takeIf()


val adult = user.takeIf { it.age >= 18 } ?: return

条件を満たさなければ早期終了する。

 

🧑🏻‍💻 30. firstNotNullOf()


val token = providers.firstNotNullOf {
    it.token
}

最初に見つかった Non-null 値を取得する。

 

🧑🏻‍💻 31. SharedFlow を使う


private val events = MutableSharedFlow<Event>(
    replay = 1
)

イベントでは StateFlow より SharedFlow が適している場合がある。

 

🧑🏻‍💻 32. Nothing を使う


fun fail(message: String): Nothing =
    throw IllegalStateException(message)

val token = token ?: fail("Token required")

Nothing を使うと独自のガード関数を作れる。

 

🧑🏻‍💻 33. !! を使わない


// 悪い
val user = user!!

// 良い
val user = requireNotNull(user)

!! より意図が明確な API を使う。

 

🧑🏻‍💻 34. let を減らす


// 悪い
user?.let {
    println(it.name)
}

// 良い
val user = user ?: return
println(user.name)

ネストを減らして読みやすくする。

 

🧑🏻‍💻 35. lateinit


private lateinit var repository: UserRepository

後から初期化する参照型では Nullable を避けられる。

 

🧑🏻‍💻 36. Delegates.notNull()


var count: Int by Delegates.notNull()

Int や Boolean など lateinit が使えない型向け。

 

🧑🏻‍💻 37. takeUnless()


val user = user.takeUnless { it.deleted } ?: return

条件を満たしたら除外したい場合に使う。

 

🧑🏻‍💻 38. firstNotNullOfOrNull()


val token = providers.firstNotNullOfOrNull {
    it.token
}

最初の Non-null を取得し、無ければ null を返す。

 

🧑🏻‍💻 39. Kotlin Contracts


@OptIn(ExperimentalContracts::class)
fun requireUser(user: User?) {
    contract {
        returns() implies (user != null)
    }
    requireNotNull(user)
}

独自関数でも Smart Cast を効かせられる。

 

🧑🏻‍💻 40. associateNotNull() パターン


val map = users
    .mapNotNull {
        it.id?.let { id -> id to it }
    }
    .toMap()

Map を作る途中で null を除外する。

 

🧑🏻‍💻 まとめ

「null」を未だに使ってるプロジェクト、実際現場では多いですよね。

「NullPointerExeption(ヌルポ)」の対応による開発時間の損失は、IT業界全体で年間数十兆円、個々の開発プロジェクトでも全体の数割の時間を奪うレベルの巨大なインパクトを持っています。


AI を使ったプロンプトに入れておきたい著名プログラマーの哲学的名言100

「プログラマー」という人種を見てて「哲学がない」と感じる昨今。

ちょっと調べてみた。

No. 名言(日本語) 名言(英語) 発言者
1 優秀なプログラマーは何を書くかを知っている。偉大なプログラマーは何を書き直すべきかを知っている。 *Good programmers know what to write. Great ones know what to rewrite.* Linus Torvalds
2 プログラミングの早すぎる最適化は諸悪の根源である。 *Premature optimization is the root of all evil.* Donald Knuth
3 デバッグはプログラムを書くことの2倍難しい。 *Debugging is twice as hard as writing the code in the first place.* Brian Kernighan
4 怠惰、短気、傲慢は、プログラマーの三大美徳である。 *Laziness, Impatience, and Hubris are the three great virtues of a programmer.* Larry Wall
5 完璧を目指すよりもまず終わらせろ。 *Done is better than perfect.* Mark Zuckerberg
6 私はすばらしいプログラマーではない。私は単にすばらしい習慣を持つ平凡なプログラマーだ。 *I'm not a great programmer; I'm just a good programmer with great habits.* Kent Beck
7 シンプルな方がいいんだよ。 *Simpler is usually better.* Rich Hickey
8 未来を予測する最良の方法は、未来を創り出すことだ。 *The best way to predict the future is to invent it.* Alan Kay
9 実のところ、すべてを備えていない言語のほうがプログラミングは簡単である。 *In fact, a language that doesn't have everything is easier to program in.* Dennis MacAlistair Ritchie
10 プロジェクトの遅れは、人員の追加で取り戻せない。 *Adding manpower to a late software project makes it later.* Frederick Brooks Jr.
11 抽象化は、複雑性を管理するための主要なツールである。 *Abstraction is the main tool for dealing with complexity.* Bjarne Stroustrup
12 良いエラーメッセージは、問題を半分解決する。 *A good error message solves half the problem.* Donald A. Norman
13 最高のコードとは、まったくコードを書かないことだ。 *The best code is no code at all.* Jeff Atwood
14 ソフトウェアは成長する。建築されるのではない。 *Software is a growing thing, it is not built.* Frederick Brooks Jr.
15 プログラミングとは、思考を明確にする行為だ。 *Programming is the act of clarifying thought.* Andy Hunt
16 ソフトウェアは常に変化し続けるものであり、固定的な考え方を持つべきではない。 *There is no code etched in stone.* Dave Thomas
17 大胆な挑戦の末での失敗ならば、問題ではない。 *Failing to achieve a daring goal is not a problem.* Larry Page
18 アイデアに価値はない。それを実行できてはじめて価値になる。 *Ideas are easy. Implementation is hard.* Larry Page
19 失敗を恐れてはいけない。ただ、失敗を繰り返しすぎてはいけない。 *Don't be afraid to fail, but don't fail the same way twice.* Jeff Bezos
20 私は難しい問題を解くために怠惰な人を選ぶ。怠惰な人は楽な方法を見つけるからだ。 *I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.* Bill Gates
21 全て自分でやるからこそ、すごく勉強になる。 *It's great to do everything yourself because you learn so much.* Steve Wozniak
22 誰もが、自分自身の法則を見つけなければならない。 *Everyone has to find their own rules.* Steve Wozniak
23 ステイ・ハングリー、ステイ・フーリッシュ。 *Stay Hungry. Stay Foolish.* Steve Jobs
24 偉大な芸術家は盗む。 *Good artists copy, great artists steal.* Steve Jobs
25 プログラミングとはシンフォニー(交響曲)を作曲するようなものだと思っています。 *I think of programming as composing a symphony.* Larry Wall
26 ソフトウェアの構造が、それを作成した組織のコミュニケーション構造を反映する。 *Organizations... are constrained to produce designs which are copies of their communication structures.* Melvin Conway
27 複雑性は、死への道だ。 *Complexity is the road to death.* Jeffery James
28 自分の書いたコードを、まるで他人が書いたもののように批判的に見よ。 *View your own code as if someone else wrote it.* Ward Cunningham
29 技術的な負債は、複利で増大する。 *Technical debt accrues interest.* Ward Cunningham
30 私は間違いを犯したことがない。ただ、うまくいかない1万通りの方法を発見しただけだ。 *I have not failed. I've just found 10,000 ways that won't work.* Thomas Edison
31 顧客が本当に欲しがっているものを、彼らが知る前に理解せよ。 *The customer does not know what they want until you show them.* Alan Cooper
32 プログラミングの核心は、データ構造ではなく、データ構造とそれに対する操作の関係である。 *Algorithms + Data Structures = Programs.* Niklaus Wirth
33 コードの品質は、それが動くかどうかではなく、どれだけ理解しやすいかで決まる。 *Code quality is measured by how easy it is to understand, not whether it runs.* Martin Fowler
34 リファクタリングは、コードを改善するだけでなく、設計を改善することでもある。 *Refactoring is not just an improvement in code, it is an improvement in design.* Martin Fowler
35 コンピュータは驚くほど高速で、正確で、愚かだ。人間は驚くほど低速で、不正確で、素晴らしい。 *Computers are incredibly fast, accurate, and stupid. Humans are incredibly slow, inaccurate, and brilliant.* Albert Einstein
36 良いプログラムとは、驚きが少ないプログラムである。 *A good program is one that has fewer surprises.* Jon Bentley
37 プログラムはまず人間が読めるように書くべきであり、機械が実行できるのは二の次である。 *Programs must be written for people to read, and only incidentally for machines to execute.* Harold Abelson
38 良いコードは、最高のドキュメントである。 *Good code is its own best documentation.* Steve McConnell
39 外部の変化スピードが内部の変化スピードを上回れば、終わりは近い。 *When the rate of change outside exceeds the rate of change inside, the end is in sight.* Jack Welch
40 変革せよ、変革を迫られる前に。 *Change before you have to.* Jack Welch
41 成功は、失敗から熱意を失わずに次に進む能力である。 *Success is the ability to go from one failure to another with no loss of enthusiasm.* Winston Churchill
42 私は、私の書いたコードを、半年後の私が理解できることを期待して書いている。 *I code for myself six months ago.* Matt Johnson
43 知識を共有しないプログラマーは、ボトルネックになる。 *A programmer who doesn't share knowledge becomes a bottleneck.* Eric Sink
44 エラー処理は、プログラムの本質的な複雑さの一部である。 *Error handling is an essential part of the inherent complexity of a program.* Bjarne Stroustrup
45 私の仕事は、物事が機能しない理由を見つけることではない。機能するようにすることだ。 *My job is not to find reasons why things won't work, but to make them work.* Robert C. Martin
46 真実は一つの場所にのみ存在すべきである。 *The truth should exist in one place only.* Robert C. Martin
47 自分の書いたコードに疑問を持て。それがプロの証だ。 *Question your own code. That is a sign of a professional.* Dave Thomas
48 プログラミング言語は、思考の限界を設定する。 *A programming language is a way of thinking about programs.* Alan Perlis
49 ソフトウェア開発とは、単にコードを書くことではない。世界を理解するシステムを構築することだ。 *Software development is not just about writing code; it's about building systems to understand the world.* Grady Booch
50 誰もが、自分自身の法則を見つけなければならない。 *Everyone has to find their own rules.* Steve Wozniak
51 私は、コンピュータが人間よりも賢くなる可能性を信じている。 *I believe in the possibility of computers becoming smarter than humans.* Marvin Minsky
52 プログラミングは、思考を紙に書き出すことから始まる。 *Programming begins by writing thoughts on paper.* John von Neumann
53 良い設計とは、変更を容易にする設計である。 *Good design is about making changes easy.* Alan Cooper
54 私は、私が理解していないソフトウェアは使わない。 *I won't use software that I don't understand.* Richard Stallman
55 自由ソフトウェアは社会問題であり、技術的な問題ではない。 *Free software is a social issue, not a technical one.* Richard Stallman
56 あなたが本当に気にするものは、テストする価値がある。 *Anything that you care about, test it.* Kent Beck
57 プログラムをデバッグする最良の方法は、プログラムを書かないことである。 *The best way to debug a program is not to write it.* Seymour Cray
58 私たちの問題は、人間がまだ十分に洗練されていないことだ。 *Our problem is that humans are not yet sophisticated enough.* Grace Hopper
59 船は港にいるときが最も安全だが、船はそれを作るために作られたわけではない。 *A ship in port is safe, but that is not what ships are built for.* Grace Hopper
60 人々はコンピュータが万能だと思っているが、そうではない。 *People think computers will do everything, but they won't.* Grace Hopper
61 プログラミングとは、機械に何をすべきかを教えることではなく、人間が何をしたいかを教えることだ。 *Programming is not about instructing a machine what to do; it's about telling a human what you want.* Alan Perlis
62 プロジェクトは、仕様書どおりではなく、人が理解したとおりに作られる。 *The system is built as the people understood it, not as it was specified.* Joel Spolsky
63 技術は、それを理解しない人々によって支配されるべきではない。 *Technology should not be ruled by people who don't understand it.* Dennis MacAlistair Ritchie
64 シンプルさは、究極の洗練である。 *Simplicity is the ultimate sophistication.* Leonardo da Vinci
65 小さく、早く、頻繁にリリースせよ。 *Release early, release often, and listen to your customers.* Eric S. Raymond
66 私は、コードを書く喜びが失われるような仕事はしない。 *I don't do jobs where the joy of coding is lost.* Linus Torvalds
67 常に次に来るべきものは何かと問うて、その一歩先を行け。 *Always ask what's next, and take the step ahead.* Bill Joy
68 良いコードは、コードを読んだ時の驚きが少ない。 *Good programs are those that have fewer surprises when read.* Jon Bentley
69 良いプログラムは、バグの量が少ない。 *Good programs have a small number of bugs.* Donald Knuth
70 私は、私が理解していないソフトウェアは使わない。 *I don't use software I don't understand.* Richard Stallman
71 完璧な設計は、市場投入を遅らせる。 *Perfect design is the enemy of launch.* Reid Hoffman
72 経験とは、欲しいものを手に入れなかった時に得られるものだ。 *Experience is simply the name we give our mistakes.* Oscar Wilde
73 未来の技術は、今日のSF小説から生まれる。 *Any sufficiently advanced technology is indistinguishable from magic.* Arthur C. Clarke
74 妥協は、コードを台無しにする。 *Compromise ruins the code.* Grady Booch
75 良いアーキテクチャは、システムを理解しやすくする。 *Good architecture makes a system easy to understand.* Martin Fowler
76 顧客は何が欲しいかなんて実は知らない。 *The customers don't know what they want.* Henry Ford
77 プログラマーにとっての最も危険な言葉は、「問題ない」である。 *The most dangerous phrase in the language is, "We've always done it this way."* Grace Hopper
78 私は、コンピューターで遊んで育った。 *I grew up playing with computers.* Bill Gates
79 人の心をつかむもの、それは誠実である。 *The thing that can gain a person's heart is sincerity.* Bill Gates
80 ソフトウェアは、知識を具現化したものである。 *Software is the embodiment of knowledge.* Grady Booch
81 私は常に、自分の書いたコードが本当に正しいのかどうかを疑っている。 *I always doubt if the code I wrote is truly correct.* Donald Knuth
82 テストされていないコードは、壊れたコードである。 *Untested code is broken code.* Robert C. Martin
83 良いプログラマーはコードを書く。偉大なプログラマーはコードを削除する。 *Good programmers write code. Great programmers delete code.* Jeff Atwood
84 バグの90%は、コードの10%に集中している。 *90% of the bugs are in 10% of the code.* Tom DeMarco
85 測定できなければ、改善できない。 *If you can't measure it, you can't improve it.* Peter Drucker
86 あなたの書いたコードは、あなたが出会う最も重要なユーザーである。 *The most important user of any piece of software is its programmer.* Bjarne Stroustrup
87 プログラムは、コードの行数で測られるべきではない。 *Programs should not be measured by lines of code.* Frederick Brooks Jr.
88 計画は無用だが、計画を立てることは不可欠だ。 *Plans are useless, but planning is indispensable.* Dwight D. Eisenhower
89 コードコメントの真実とは、コメントは嘘をつきがちだということだ。 *Comments lie more than the code.* Jeff Atwood
90 複雑なことをシンプルにすること。それは才能である。 *The ability to simplify means to eliminate the unnecessary so that the necessary may speak.* Hans Hofmann
91 良いプログラムとは、その作成者がいなくても読めるプログラムである。 *A good program is one that can be read even without its creator.* Kent Beck
92 経験とは、間違いを犯した後で、それを二度としない能力である。 *Experience is the ability to not make the same mistake twice.* Paul Graham
93 ソフトウェアは常に完成途上にある。 *Software is never finished, only abandoned.* Frederick Brooks Jr.
94 私は、コンピュータが世界を変えると信じている。 *I believe that the computer will change the world.* Bill Gates
95 私は、人生で最も賢い人々の何人かに会ったが、彼らはプログラマーだった。 *I met some of the smartest people in my life, and they were programmers.* Steve Wozniak
96 プログラミングは、論理と芸術の融合である。 *Programming is the fusion of logic and art.* Donald Knuth
97 誰にも見つからないバグは、実質的に存在しない。 *A bug that no one finds is effectively non-existent.* Grace Hopper
98 誰かがコードレビューをするたびに、コードは改善される。 *The code improves every time someone reviews it.* Jeff Atwood
99 この世界、10年後の実用になる技術なんてのは、寝言と同じ価値しかない。 *Technology that will be practical 10 years from now is worth no more than a sleeper's monologue.* Dan Kogai
100 我々のゴールは、最小の努力で最大の効果を得ることである。 *Our goal is to achieve maximum effect with minimum effort.* Larry Wall

 

🤔 まとめ

見てると考えさせられます。

大きく変わったと思います、プログラミング。

プロンプトに入れるには抽象的すぎでした。

Dan Kogai さんもランキング入りしててワロタ。

👉 『AIで書いたコードは危険』と語る著名プログラマーたちのコメント


【macOS】DeskPad - A virtual monitor for screen sharing を使ってみる

少し話題になっていたので気になっていました。

👉 Stengo/DeskPad: A virtual monitor for screen sharing

仮想モニター?

 

🤔 よく分からないので使ってみた

ディスプレイ設定ウインドウが開いています。

DeskPad を起動させると、
拡張ディスプレイとして認識されるので、

レイアウトを整えて、

設定のウインドウを拡張ディスプレイの方向に移動していくと、

DeskPad 上に移動して表示される。

動画。



そんな感じです。

すげえ!

 

🤔 まとめ

これ、いろいろ使えそうですね。