Log in
On March 21, 2006, Jack Dorsey posted a simple message: “just setting up my twittr”.
|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
Pennsylvania, USA
When Reuters reported Friday that Amazon is working on a new smartphone, the reflexive reaction was obvious: Didn’t they already try this? And didn’t it go spectacularly badly?
Yes, on both counts. The Fire Phone, which launched in 2014 when Jeff Bezos was still running the company, lasted 14 months and led to a $170 million writedown.
It was packed with gimmicks, including a 3D display and a camera feature that recognized products and let you buy them on Amazon. It might have been the biggest example of Amazon failing to live up to its legendary mantra of starting with the customer and working backwards.
But dismissing Amazon’s new effort, codenamed “Transformer,” as a sequel to that disaster misses the point. This isn’t Amazon trying to redo 2014. It’s Amazon looking at the AI landscape and betting that the shift to AI is going to fundamentally change what a mobile device is, and that the dominant smartphone makers might not be the ones leading that charge.
The AI opening: Apple and Samsung together command about 40% of global smartphone sales, but their recent devices have been incremental upgrades, not breakthroughs. Neither company is at the forefront of AI in the way that OpenAI, Anthropic, Microsoft, and Amazon itself are.
A growing number of companies are already trying to exploit that gap. OpenAI is working with former Apple design chief Jony Ive on a dedicated AI device. Meta is pushing its Ray-Ban smart glasses as an alternative to pulling out your phone.
Earlier attempts at standalone AI gadgets, like the Humane AI Pin and Rabbit R1, rivaled the Fire Phone as flops in their own right, but they demonstrated the potential of AI devices.
That’s where Amazon may see an opening.
Project details: The phone is being developed by a group called ZeroOne inside Amazon’s devices unit, which has a mandate to create “breakthrough” gadgets, according to Reuters.
It’s headed by J Allard, the former Microsoft executive behind Xbox and the Zune music player, who joined Amazon in 2024, as GeekWire first reported.
The phone is envisioned as an AI-driven personalized device that syncs with Alexa and could potentially bypass traditional app stores altogether. That concept feels increasingly plausible in an era when AI agents can act on a user’s behalf without opening an app.
The company, for the record, isn’t commenting on any of this. The project is still early, the timeline is undefined, and Reuters noted that it could still be scrapped.
The connectivity question: Amazon hasn’t even approached wireless carriers yet, according to the report.
But that detail actually raises an interesting question. Amazon’s Leo satellite internet initiative, formerly known as Project Kuiper, sits in the same Devices & Services division as the new phone project, all under the umbrella of Panos Panay, another former Microsoft executive. Those satellites could provide wireless connectivity directly to devices, potentially bypassing traditional carriers altogether.
There’s no indication the two efforts are connected, but it would make a ton of sense.
And then there’s Amazon Sidewalk, the company’s existing mesh networking protocol that uses Echo and Ring devices to create a low-bandwidth wireless network.
Between satellites overhead and Sidewalk on the ground, Amazon has been quietly building out the infrastructure that could support a device like this without ever involving a traditional carrier.
For the new phone project, Amazon has explored both a conventional smartphone and a stripped-down “dumbphone” with limited features, according to the Reuters report. It has considered positioning a simpler version as a companion device that customers would carry alongside their existing iPhone or Galaxy. One inspiration is reportedly the Light Phone, a minimalist handset with a camera, maps, and not much else, selling for about $700.
During the original Fire Phone development, two internal teams debated the direction: a low-cost, stripped-down device vs. a high-end phone packed with features, as noted in a great “Version History” podcast by The Verge. Bezos sided with the high-end camp, and it failed.
This time, Amazon appears to be hedging by exploring both paths simultaneously.
The Jassy factor: It’s also worth reconsidering the conventional wisdom that this kind of hardware bet is out of character for Amazon under CEO Andy Jassy, Bezos’ successor. Jassy has spent much of his tenure streamlining the company and cutting projects that weren’t working.
But the goal of that effort isn’t to avoid big bets, it’s to clear out bureaucracy and make Amazon more nimble and deliberate when it makes them. Creating a dedicated hardware group with a “breakthrough” mandate and staffing it with a veteran product leader is evidence of that.
Ultimately, the fact that Amazon is willing to revisit its most painful hardware failure shows how seriously it takes the idea that AI has the potential to change what a mobile device can be.
This piece was adapted from a discussion between Todd Bishop and John Cook on this week’s GeekWire Podcast. Listen above, or subscribe in Apple, Spotify or wherever you listen.
Pennsylvania, USA
This week on the GeekWire Podcast: Amazon is working on a new smartphone, code-named “Transformer,” more than a decade after the Fire Phone debacle, according to Reuters.
We dig into the connection to a past GeekWire scoop: former Microsoft Xbox leader J Allard joined Amazon’s devices team in 2024, and he’s now leading a group called ZeroOne with a mandate to create “breakthrough” gadgets. Is this an AI-native device? A companion to your iPhone? J Allard’s shot at redemption? Maybe all of the above.
There’s more great Fire Phone background in this Vergecast “Version History” podcast.
Then: Microsoft shakes up its Copilot team, shifting Mustafa Suleyman to a narrower role and unifying consumer and enterprise AI under a new leader. Todd has strong feelings about Microsoft’s history of cutesy consumer tech, from Clippy to Mico.
Plus: Todd’s adventure using Claude CoWork to browse LinkedIn (and the stern warning he got in response). We also discuss King County Metro’s slick new tap-to-pay feature catches the transit system up with the modern world, the upcoming opening of cross-lake light rail, and round things out with an Amazon Treasure Truck trivia question.
Subscribe to GeekWire in Apple Podcasts, Spotify, or wherever you listen.
Audio editing by Curt Milton.
Pennsylvania, USA
This keeps coming up in real conversations, and it usually surfaces right when decisions start to matter. Someone says they are "in GCC," and from there the assumption creeps in that Azure Government is somehow already in the picture. That leap feels small in the moment, but know it is not. The reference and assumption snowballs into bad architecture, wrong scoping, and uncomfortable conversations when compliance teams start asking harder questions. People are not being careless here. The way...
Pennsylvania, USA
My gut reaction has often been to compare WebAssembly to Kubernetes. Flash back to over four years ago: Then, I put this concept to the test by comparing WebAssembly to Kubernetes in an article.
Not long after the article’s publication, I attended a workshop generously hosted by Cosmonic to use the WebAssembly cloud and learn how to deploy applications with WasmCloud. I got my first hands-on experience with WebAssembly.
As Cosmonic CTO Bailey Hayes helped me play around with WasmCloud during the workshop, I really thought, “Wow, I can deploy things without having to change the underlying infrastructure, essentially anywhere I want, with just a CPU instruction set through a single endpoint.” I did that by setting up microservices with WebAssembly, in that case with WasmCloud, all simultaneously with just one command line. Boom — it was there everywhere. I thought, “Well, maybe that could be something. Isn’t that what Kubernetes is supposed to do? Plus, it’s simple.”
As I learned more about WebAssembly, I realized that wasn’t really the case — they are two different things. Still, I had that inkling in the back of my head. Then came Helm, supporting WebAssembly modules directly. I thought, “Oh, here we go again. We can run WebAssembly modules with Helm; maybe we won’t need Kubernetes.” Wrong again.
This has been part of my learning journey, but it helped me realize that now, with Helm 4 supporting direct WebAssembly modules thanks to the Extism WebAssembly plugin, the isolation previously missing in Helm 3 is provided. You can implement many policy considerations, multi-language elements, and other features in these modules and deploy them on Kubernetes.
So no, WebAssembly is not going to replace Kubernetes, and that is missing the point of the concept: WebAssembly is almost always an extender of existing systems. In this case, you use WebAssembly through Helm to deploy, manage, and distribute workloads to a theoretically infinite number of endpoints that can run a CPU instruction on Kubernetes.
That was the topic of the talk “Helm Meets WebAssembly: Secure Extensibility Without Replacing Kubernetes,” which I gave this week in Barcelona at the Wasm I/O conference as the co-presenter with Shivay Lamba. Lamba had to cancel his trip due to geopolitical issues that disrupted his flight from India, but delivered his part of the talk via video.
As Lamba said during his talk, the Existim plugin provides a lightweight framework for building WebAssembly-based systems. To lock these rules in place, instead of simply running the code, Helm 4 uses a built-in tool — with the help of Extism — to instantly build an invisible, isolated sandbox inside of its own system. Helm then drops the plugin’s code into this safe box. In this environment, the plugin is completely blind and disconnected from the actual computer, Lamba said.
“Helm takes the command you have typed, packages the data up safely, and slides it into the sandbox to be executed so the plugin can start working. Since the plugin is isolated, it cannot directly touch your computer’s hard drive or the internet,” Lamba said. “If the plugin needs to download a file to do its job, it must formally ask the host function standing outside of the sandbox. If the security rules specify that the plugin is allowed to download a file from github.com, then the host guard will go out.”
However, if the plugin tries to access something that it does not have permission to reach, the guard will immediately block it, Lamba said. “Once the plugin finishes its work, it packages up the final result and sends it back to Helm. As soon as Helm gets the result, it immediately destroys the sandbox — which is the WebAssembly module — and wipes out any temporary files that the plugin was using,” Lamba said. “In this way, with the help of Extism, Helm ensures that plugins only get what they need to do their jobs and absolutely nothing more.”
Little protection, big protection
My demo partially failed. I did manage to show with Helm 3, the WebAssembly plugin (Extism in this case) is not “sandboxed.” A simple script with my full permissions that lists my home directory and other info is listed. Obviously, you do not want that.
It’s an unbounded security risk:
The “executable not found” error is exactly why the Extism provided protection is so important. Helm 4 refuses to run the plugin because it can’t find the secure sandbox runner.
It would rather fail than run the code insecurely:
Once I restored the secure path, the “guard” went back up and protected the system:
There you have it. Our talk shows how and why the Extism Wasm plugin improves supply chain and runtime security through mandatory signing and verification, clearer provenance, while still keeping Helm “batteries included” for default behavior.
Again, no, it is not going to help WebAssembly replace Kubernetes, but it will help make Kubernetes through Helm more secure and computationally efficient.
The post Why WebAssembly won’t replace Kubernetes but makes Helm more secure appeared first on The New Stack.
Pennsylvania, USA
Transform a messy Flutter project into a professional codebase — one PR at a time.
GitHub - VB10/flight_booking: Flight App for refactoring real project
⭐ github.com/VB10/flight_booking
📺 Video Series: 1-Overview · 2-Pubspec · 3-Linter · 4-Architecture · 5-Main.dart
🤖 Want to apply these changes to your project? See the AI prompt at the end.
What is Flutter Refactoring Masterclass?
After years of building Flutter applications — some from scratch, some inherited — I’ve seen the same patterns repeat. Projects that start clean eventually become messy. New team members struggle to understand the codebase. Even the original developers forget why things are the way they are.
This series is my attempt to fix that. I took a typical “bad” Flutter project and I’m cleaning it up piece by piece, documenting every step with:
- YouTube videos — Walking through the reasoning and implementation
- GitHub PRs — Real code changes you can review and copy
- Articles — Written summaries with before/after comparisons
- AI prompts — So you can apply the same refactoring to your own projects
The goal isn’t to teach you something new — it’s to show you how to apply what you already know in a systematic, repeatable way. When a new developer joins your team, they should be able to understand the project structure in minutes, not hours.
Let’s start with the foundation.
The Problem
Every Flutter developer has inherited — or created — a messy project. Files scattered in lib/ root. Dependencies listed without any organization. Default linter rules that catch nothing. A main.dart bloated with Firebase initialization, analytics setup, and business logic.
When someone new joins the team, they spend hours just understanding where things are. When you return to the project after a month, you wonder who wrote this chaos. That developer was you.
This article covers the foundation refactoring — the boring-but-essential changes that transform a hobby project into a professional codebase. We’ll work through real PR diffs from the flight_booking repository.
What We Changed
- pubspec.yaml — Organized dependencies by category, removed boilerplate comments
- analysis_options.yaml — Switched to very_good_analysis, enabled strict mode
- .gitignore — Added *.lock pattern
- .vscode/settings.json — Format on save, organize imports
- .vscode/launch.json — Flavor-based launch configurations
- lib/ folder structure — Feature-based architecture
- main.dart — Clean initialization with AppInitializer pattern
1. Pubspec.yaml: Your Project’s Table of Contents
The pubspec is the first file anyone reads. It should communicate what your project does and what it depends on — at a glance.
Before:
# ❌ Before — pubspec.yaml (86 lines with comments)
dependencies:
flutter:
sdk: flutter
# The following adds the Cupertino Icons font to your application.
# Use with the CupertinoIcons class for iOS style icons.
cupertino_icons: ^1.0.8
dio: ^5.3.2
shared_preferences: ^2.2.2
shimmer: ^3.0.0
lottie: ^2.7.0
flutter_svg: ^2.0.9
firebase_core: ^2.24.2
firebase_remote_config: ^4.3.8
firebase_analytics: ^10.7.4
package_info_plus: ^4.2.0
# ... 40 more lines of Flutter-generated comments
After:
# ✅ After — pubspec.yaml (64 lines, organized)
dependencies:
flutter:
sdk: flutter
cupertino_icons: ^1.0.8
# Network
dio: ^5.3.2
# Database
shared_preferences: ^2.2.2
# Firebase
firebase_core: ^2.24.2
firebase_remote_config: ^4.3.8
firebase_analytics: ^10.7.4
# View utilities
shimmer: ^3.0.0
lottie: ^2.7.0
flutter_svg: ^2.0.9
# Native plugins
package_info_plus: ^4.2.0
dev_dependencies:
flutter_test:
sdk: flutter
flutter_lints: ^5.0.0
very_good_analysis: ^10.0.0
build_runner: ^2.9.0
Why this matters: When a package causes issues, you immediately know which category it belongs to. When onboarding a new developer, they understand the project’s tech stack in seconds.
2. Analysis Options: The Team’s Code Contract
Default Flutter linting catches almost nothing. When you write code that works but isn’t maintainable, nobody tells you. The very_good_analysis package changes that—it's the linter used by Very Good Ventures, one of the most respected Flutter consultancies.
Before:
# ❌ Before — analysis_options.yaml
include: package:flutter_lints/flutter.yaml
linter:
rules:
# avoid_print: false # Uncomment to disable the `avoid_print` rule
# prefer_single_quotes: true # Uncomment to enable...
After:
# ✅ After — analysis_options.yaml
include: package:very_good_analysis/analysis_options.yaml
analyzer:
language:
strict-casts: true
strict-raw-types: true
exclude:
- "**/*.g.dart"
- "**/*.freezed.dart"
- test/**
errors:
missing_return: error
dead_code: error
unused_import: error
argument_type_not_assignable: info # TODO: fix this
linter:
rules:
avoid_print: true
prefer_single_quotes: true
always_declare_return_types: true
prefer_const_constructors: true
prefer_final_locals: true
use_super_parameters: true
public_member_api_docs: false
lines_longer_than_80_chars: false
Why this matters: strict-casts: true catches implicit type conversions that cause runtime crashes. prefer_final_locals enforces immutability. These aren't preferences—they're bug prevention.
3. VSCode Settings & .gitignore
Lock files cause merge conflicts. Team members have different editors. Imports get shuffled randomly.
New: .vscode/settings.json
{
"dart.lineLength": 80,
"[dart]": {
"editor.formatOnSave": true,
"editor.formatOnType": true,
"editor.rulers": [80],
"editor.codeActionsOnSave": {
"source.organizeImports": "explicit",
"source.fixAll": "explicit"
}
}
}New: .vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "App (Development)",
"request": "launch",
"type": "dart",
"toolArgs": ["--dart-define", "FLAVOR=development"]
},
{
"name": "App (Production)",
"request": "launch",
"type": "dart",
"toolArgs": ["--dart-define", "FLAVOR=production"]
}
]
}Updated: .gitignore
# Added
*.lock
Why this matters: When every save auto-formats and organizes imports, code reviews focus on logic — not style. Removing lock files from git eliminates 90% of merge conflicts in iOS projects.
4. Folder Structure: Feature-Based Architecture
All files dumped in lib/ root is the #1 sign of a beginner project.
Before:
lib/
├── main.dart
├── cart_page.dart
├── checkout_response_model.dart
├── flight_detail_page.dart
├── flight_list_page.dart
├── flights_response_model.dart
├── login_page.dart
├── login_response_model.dart
├── profile_page.dart
├── splash_page.dart
└── firebase_options.dart
After:
lib/
├── main.dart
├── core/
│ └── util/
│ └── string_helper.dart
├── feature/
│ ├── auth/
│ │ ├── cart/
│ │ │ ├── cart_page.dart
│ │ │ └── checkout_response_model.dart
│ │ ├── flight/
│ │ │ ├── flight_list_page.dart
│ │ │ └── flights_response_model.dart
│ │ ├── flight_detail/
│ │ │ └── flight_detail_page.dart
│ │ └── profile/
│ │ └── profile_page.dart
│ ├── unauth/
│ │ ├── login/
│ │ │ ├── login_page.dart
│ │ │ └── login_response_model.dart
│ │ └── splash/
│ │ └── splash_page.dart
│ └── sub_feature/
│ └── main/
│ └── main_app.dart
├── product/
│ ├── initialize/
│ │ ├── app_initializer.dart
│ │ ├── platform_initializer.dart
│ │ └── firebase/
│ │ └── custom_remote_config.dart
│ └── package/
│ └── firebase/
│ └── firebase_options.dart
└── module/
└── utils/
Why this matters: When someone asks “where’s the login logic?”, the answer is obvious: feature/unauth/login/. When you need to add a new feature, you know exactly where to create the folder.
5. Main.dart: The 10-Line Ideal
Your main.dart should be readable in 5 seconds.
Before:
// ❌ Before — main.dart (65 lines)
import 'package:firebase_analytics/firebase_analytics.dart';
import 'package:firebase_core/firebase_core.dart';
import 'package:firebase_remote_config/firebase_remote_config.dart';
import 'package:flutter/material.dart';
// Global variables - bad practice
late FirebaseRemoteConfig remoteConfig;
late FirebaseAnalytics analytics;
void main() async {
WidgetsFlutterBinding.ensureInitialized();
await Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform);
remoteConfig = FirebaseRemoteConfig.instance;
await remoteConfig.setDefaults({
'minimum_app_version': '1.0.0',
'force_update_required': false,
// ... more config
});
analytics = FirebaseAnalytics.instance;
await analytics.setAnalyticsCollectionEnabled(true);
runApp(MyApp());
}
After:
// ✅ After — main.dart (10 lines)
import 'package:flight_booking/feature/sub_feature/main/main_app.dart';
import 'package:flight_booking/product/initialize/app_initializer.dart';
import 'package:flutter/material.dart';
void main() async {
AppInitializer.run();
await AppInitializer().prepare();
runApp(const MainApp());
}New: app_initializer.dart
// ✅ After — product/initialize/app_initializer.dart
final class AppInitializer {
AppInitializer() {
platformInitializer = kIsWeb
? WebPlatformInitializer()
: MobilePlatformInitializer();
}
static void run() {
WidgetsFlutterBinding.ensureInitialized();
}
late final PlatformInitializer platformInitializer;
Future<void> prepare() async {
await Future.wait([
platformInitializer.prepare(),
Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform),
CustomRemoteConfig.instance.initialize(),
]);
}
}New: custom_remote_config.dart
// ✅ After — product/initialize/firebase/custom_remote_config.dart
final class CustomRemoteConfig {
static final CustomRemoteConfig instance = CustomRemoteConfig._();
CustomRemoteConfig._();
final FirebaseRemoteConfig remoteConfig = FirebaseRemoteConfig.instance;
final FirebaseAnalytics analytics = FirebaseAnalytics.instance;
Future<void> initialize() async {
await remoteConfig.setDefaults({
'minimum_app_version': '1.0.0',
'force_update_required': false,
});
}
}
Why this matters: Global variables are gone. Firebase logic is encapsulated. Platform-specific initialization is abstracted. Adding a new initialization step means adding one line to Future.wait().
Key Takeaways
- Organize pubspec.yaml by category — Network, Database, Firebase, UI. Future you will thank present you.
- Use very_good_analysis — It catches bugs before they reach production. Enable strict-casts and strict-raw-types.
- Remove lock files from git — Add *.lock to .gitignore. Run pod install locally.
- Feature-based folder structure — feature/auth/, feature/unauth/, product/, core/. Each feature is self-contained.
- 10-line main.dart — Everything else goes in AppInitializer. Parallel initialization with Future.wait().
What’s Next
In Part 2, we’ll tackle the Theme & Design System — building a proper AppTheme, AppColors, and AppTextStyles that support light/dark modes and scale across the app.
This article is part of the Flutter Refactoring Masterclass series, where we transform a messy real-world project into production-ready code, one PR at a time.
📺 Watch the Full Series
🤖 Apply This to Your Project
Use this prompt with Claude or your AI assistant to analyze and refactor your Flutter project:
Analyze my Flutter project and apply these refactoring steps:
1. **pubspec.yaml** - Organize dependencies by category (Network, Database, Firebase, UI, Native plugins). Remove all Flutter-generated comments.
2. **analysis_options.yaml** - Switch to very_good_analysis with strict-casts and strict-raw-types enabled. Add exclude patterns for generated files.
3. **.gitignore** - Add *.lock pattern to prevent merge conflicts.
4. **.vscode/settings.json** - Add formatOnSave, organizeImports, and 80-char ruler for Dart files.
5. **Folder structure** - Reorganize lib/ into feature-based architecture:
- feature/auth/ (authenticated screens)
- feature/unauth/ (login, splash)
- product/initialize/ (app initialization)
- core/util/ (shared utilities)
6. **main.dart** - Reduce to ~10 lines using AppInitializer pattern. Move all Firebase/analytics setup to separate initialization classes.
Show before/after for each change. Create PRs or commits for each step.
📋 Full Series Roadmap
This is Part 1 of a 20-part series. Here’s the complete roadmap:
Completed: v1–v7 (Project Setup, Theme, View-ViewModel-Mixin)
Coming Next: Navigation, State Management, Network Layer, Code Generation, Testing, and more.
Flutter Refactoring Masterclass — Part 1 was originally published in Flutter Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Pennsylvania, USA
Next Page of Stories