2
points
merek
Joined 466 karma
- If you've ever built a website for mobile but never heard of PWAs (Progressive Web Apps), I recommend checking them out. In essence, adding 2 files can make the site installable from a mobile browser and define caching behavior for offline functionality.
1. manifest.json: a JSON file that defines the app's name, icons, theme colors, and how it should launch when installed.
2. Service worker: a JS file that controls things like resource caching for offline usage
Unfortunately PWAs don't receive first class support compared to native apps. Still, I still hope to see wider adoption. I think for many not-too-complex apps, they can significantly lower the cost of development, and the development experience could be as simple as
- Building with HTML + JS + CSS. No clunky SDKs, reduced need to test on painfully slow emulators or expensive physical devices
- Installable from a browser. No need to maintain a listing in the Playstore/App Store, avoiding policy headaches, rent, etc.
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
- I recently came across Open Web Advocacy (OWA) who summarize my mobile-platform concerns well. They "advocate for the future of the open web by providing regulators, legislators and policy makers the intricate technical details that they need to understand the major anti-competitive issues in our industry and how to solve them."
Their top 3 priorities:
1. Apple's ban of third party browsers on iOS is deeply anti-competitive
2. Web Apps need to become just Apps. Apps built with the free and open web need equal treatment and integration. Closed and heavily taxed proprietary ecosystems should not receive any preference.
3. All artificial barriers placed by gatekeepers must be removed. Web Apps if allowed can offer equivalent functionality with greater privacy and security for demanding use-cases.
Website: https://open-web-advocacy.org/en/
- I figured if a single AZ has an outage, let alone the entire region, I can rest easy knowing much bigger companies will have bigger problems. It will probably be newsworthy, and when customers email in, my excuse will be defensible, since I can send them links to external status pages, news articles, etc.
Whilst this was mostly true, it was still a very unpleasant experience, and my service was hanging by a thread for much of the time. I recently moved an important part of the stack from EC2 to Fargate, with two services: a single task to post jobs to a queue, and another service running many tasks to process jobs from the queue.
The incident knocked out the job posting service, which would not come back up. Had I left it to AWS to resolve automatically, my service would have been out for maybe 12 hours.
Fortunately the worker tasks were still available and waiting. I tracked down the old "job poster" code that used to run on an ec2. I sshed into an old ec2, and "deployed" the code by copying and pasting onto the server. The service came back up, although I had to edit the code directly on the ec2 to slow things down, since the ec2 had 1vCPU and an upgrade was not possible during the incident. Furthermore, Fargate workers would not scale out if they had too much work.
This was at about 2 or 3 AM my time, and was carried out whilst customers were emailing in, and cloudwatch alarms were going off all over the place. Once the service was back up, even with my unnerving hacky solution, I got a couple hours sleep.
What I've learnt:
- When the incident was first reported, I thought it would last 2 hours max. A 12 - 16 hour disruption to AWS resources is absolutely possible.
- Maybe don't use us-east-1 for future projects, but I'm not convinced there's much logic to this. Despite past issues, it's impossible to predict where an outage might occur and the affected resources, as well as spillover into other regions.
- Think of ways to make my service more portable, to other regions, even other cloud providers, but the motivation to do this will be gone by tomorrow. It's way more valuable for me to focus on customers, new features, etc, rather than bomb-proofing the service. I don't write airline or medical software. An outage of my service isn't going to kill anyone, and most users are understanding. I'll accept the hit.
- > I never told them what my business does or what I'd use the money for.
This stuck out to me. I'm in the process of opening a bank account in Singapore for a newly registered company, and boy is it difficult.
Hour-long KYC interview. Details of what the business does. Anything remotely controversial could be a red flag. They want to hear about boring B2B services. They want to see evidence of customer communications or contracts, so they can see you're a legit business and not a shell company. This is very difficult for a company that hasn't started operating yet. Why would I start operating without banking? How can I show business activity before commencing operating?
By comparison, I've opened business accounts in both AU and the US without hassle.
- > The meta-analysis of 33 studies, the first of its kind, looked at the relationship between sensitivity and common mental health problems such as depression and anxiety. Researchers found there was a significant, positive relationship between the two
> In the study, sensitivity was defined as a personality trait that reflects people's capacity to perceive and process environmental stimuli such as bright lights, subtle changes in the environment and other peoples' moods.
> Around 31% of the general population are considered highly sensitive
- I recently deployed a few static websites on Cloudflare. I use AWS as a registrar, and I had to use Pages since Workers don't support "Custom domains outside Cloudflare zones" [1]. There's no way I can transfer the domain since I have subdomains tightly integrated with AWS services.
If anyone from Cloudflare sees this, are there plans to have Workers support external custom domains, or is this a fundamental limitation of Workers?
[1] https://developers.cloudflare.com/workers/static-assets/migr...
- It's not bankruptcy if the company has no liabilities. You're allowed to wind down a profitable company because you can't be bothered running it any more.
A question of legality might come from German authorities determining if this is solely to avoid tax, which is open-ended. It might be hard for them to make this argument if you can prove you transferred operations to country X to maximize company's growth, access local talent, closer proximity to customers etc.
Regardless, anther commenter pointed out that the exit tax applies to all companies that you own regardless of location. In that case, the approach isn't feasible.
Also it goes without saying, seek your own legal advice rather than trusting random comments on the internet.
- There's a note at the end
> You could, of course, sell or wind down your company, which would solve all problems outlined here. But this is not an option for most entrepreneurs.
For a software business, you could presumably:
- Incorporate a company in your country of choice
- Transfer subscribers from German company to new foreign company (depending on payments provider, this can be a massive effort, for example, not a simple form field in Stripe).
- If new company incorporated in a country you want to live in, use it to obtain an investor Visa
- German company now has 0 in revenue, wind it down and leave.
- > The FDA approval comes based on trial data submitted by the pharmaceutical company, so it's worth noting that published peer-reviewed reports are yet to be published. Peer-reviewed publications often follow regulatory approvals, not precede them, which is common in the field of ophthalmology and dermatology.
Does anyone know the reason that data is published after approval rather than before? Seems illogical at face value, but I'm obviously missing something.
- Interactive images can be found here
- They only observed an area of sky approximately the size of "three full moons"
> By using the data from the James Webb Space Telescope’s 6.5‑meter (21-ft) mirror, scientists at UC Santa Barbara have surveyed 0.54 square degrees of sky, which is equivalent to the area of three full moons when viewed from Earth. Charting nearly 800,000 galaxies, the COSMOS-Web dataset covers almost 98% of cosmic history.
- This is the overall process used by Meta as I understand it, taken from https://localmess.github.io/:
1. User logged into FB or IG app. The app runs in background, and listens for incoming traffic on specific ports.
2. User visits website on the phone's browser, say something-embarassing.com, which happens to have a Meta Pixel embedded. From the article, Meta Pixel is embedded on over 5.8 million websites. Even in In-Cognito mode, they will still get tracked.
3. Website might ask for user's consent depending on location. The article doesn't elaborate, presumably this is the cookie banner that many people automatically accept to get on with their browsing?
4. > The Meta Pixel script sends the _fbp cookie (containing browsing info) to the native Instagram or Facebook app via WebRTC (STUN) SDP Munging.
You won't see this in your browser's dev tools.
5. Through the logged-in app, Meta can now associate the "anonymous" browser activity with the logged-in user. The app relays _fbp info and user id info to Meta's servers.
Also noteworthy:
> This web-to-app ID sharing method bypasses typical privacy protections such as clearing cookies, Incognito Mode and Android's permission controls. Worse, it opens the door for potentially malicious apps eavesdropping on users’ web activity.
> On or around May 17th, Meta Pixel added a new method to their script that sends the _fbp cookie using WebRTC TURN instead of STUN. The new TURN method avoids SDP Munging, which Chrome developers publicly announced to disable following our disclosure. As of June 2, 2025, we have not observed the Facebook or Instagram applications actively listening on these new ports.
- I'm a big fan of YouTube anti-scammer vigilantes. They bait scammers, expose their tactics, humorously waste their time, or even manage a counter attack.
I believe these guys can be a big part of the solution. YouTube creates a financial incentive for individuals to go down this route, and apart from being entertaining to viewers, it broadens awareness of scammer tactics, which hopefully means more people detect scams early.
I wish these guys success and hope to see more anti-scam YouTubers appear.
Examples:
- > It turns out that BEVs (battery electric vehicles) reduce the amount of brake dust by 83%, according to a new analysis by EIT Urban Mobility (a body of the European Union) and Transport for London. The study looked primarily at London, Milan and Barcelona.
> The primary reason for this is the use of regenerative braking, meaning that electric vehicles can slow down without rubbing friction brakes. Other vehicles that use regenerative braking reduced brake emissions too, with Hybrids reducing them by 10-48%, and PHEVs by 66%.
Technically not cleaning the air as the title says, but still a major improvement.
The query also filters to PostTypeId = 1, what does this refer to?