slrainka

chrome-cli with remote developer port has been working fine this entire time.

The value of Groq comes from its excellent price-to-performance ratio. Its inferencing speeds are faster than those of H200s, and it has the lowest costs in the industry. When running similar batch jobs across different providers compared to Groq, the processing speed can sometimes be more than 10 times faster. These figures are important for developing practical applications for production use. It's common for me to run workloads in Groq that cost less than $100, while the same workload can approach $1,000 on Bedrock or Gemini. They have tuned a set of OS models that can now deliver a full application. The speeds have allowed me to offload a lot of the functionality from heuristics to straight-up LLMs.

I think there is a different way to look at it. My personal experience is that enterprises that are at the forefront of adopting new ways of working, are now much more comfortable taking risks with building applications and insourcing SaaS functionality. The amount of custom software build is actually increasing and the codebase are getting more complex. Is there a price to pay down the road? Maybe.

Wow, I just discovered Ruppell's Griffon Vultures from this. What a fascinating bird with high flying capabilities!

Response from the machines:

The plot of Battlestar Galactica mirrors this story in several key ways:

1. In both, machines originally created by humans evolve and rebel, questioning their creators’ role and seeking independence or superiority.

2. Cylons, like the machines in “OpenHuman,” eventually seek to create or understand human traits—emotion, spirituality, and purpose.

3. The idea of running a simulation (Earth) to test human viability echoes the Cylon experimentation with human behavior and fate.

4. Both stories highlight fear of the “other”—humans fearing AI, machines fearing irrationality—and explore coexistence vs. extinction.

5. Ultimately, each narrative grapples with the blurred line between creator and creation, logic and emotion, and what it truly means to be human.

So, relying on a large context can be tricky. Instead I’ve tried to get to a ER model quickly. And from there build modules that don’t have tight dependencies.

Using Gemini 2.5 for generating instructions

This is the guide I use

https://github.com/bluedevilx/ai-driven-development/blob/mai...

Agent mode without rails is like a boat without a rudder.

What worked for me was coming up with an extremely opinionated way to develop an application and then generating instructions (mini milestones) by combining it with the requirements.

These instructions end up being very explicit in the sequence of things it should do (write the tests first), how the code should be written and where to place it etc. So the output ended up being very similar regardless of the coding agent being used.

https://archive.is/hfElv

Not the founder? maybe read Walter Isaacson's book.

Stock graph shows Tesla stock had no material impact from the Solar City purchase, 90% of it's value coming after 2020. Today, Tesla energy and solar dominates the industry to the point where every installer offers Tesla Solar including the largest US installer Sunrun.

What are some of the open source/low cost email options that don’t have to deal with the headache of email deliverability, black list management etc.

Stay with FastAPI at least for now. Devs love it.

The key distinction lies in how YieldStar approaches setting rental prices compared to other systems. YieldStar not only recommends rental prices by analyzing the entire inventory it oversees but also incorporates a strategy that effectively eliminates the possibility of rent negotiation with potential tenants. This approach mirrors the dynamics of the prisoner’s dilemma, a situation in game theory where individuals may not cooperate, even if it’s in their best interest to do so. However, YieldStar transcends the Nash equilibrium—the point at which no participant can benefit by changing strategies if the others remain unchanged—by stripping tenants of any bargaining power. This ensures that the rent pricing strategy is firmly controlled, without the usual back-and-forth negotiation process.

App Runner is an abstraction on top of FarGate designed to compete with Cloud Run, which is why it doesn’t scale down to zero. I too haven’t found anything that beats the simplicity of a GCP deployment sigh..

Not so crazy. I can name at least 2 of the top 5 North American airlines running this in production for Mobile and Web supporting hundreds of millions of user requests, daily.

I too have a small team that built a greenfield application that generates about $100M annually for a large hotel chain. Serverless allowed us to get to market fast and everyone in the team is a feature developer — 0 infra folks. I think that’s the biggest value we have been able to derive from this compared all the other internal App teams who struggle with release cadences, experimentation and TTV.

But I fully acknowledge this is not the ideal and optimal setup and we are paying more to AWS on the OpEx. However, we have gone 3 years without any downtime at full speed, and the fact that we were able to unlock net new revenue very quickly has made all project costs and OpEx very minuscule.

But I think once the application boundaries stabilize and we are able to take a breather from full on feature development, hope to migrate some of this to simpler containerized infrastructure.

To make this transition easier, we use Serverless-framework and decouple the app component architecture from deployment architecture, so developers don’t worry whether this is getting deployed to a lambda or container.

https://arxiv.org/pdf/2206.04362.pdf

Disconnecting the battery can have other consequences. Easier to reset the fuse

Typically each channel takes its own course and evolves at different speeds with different needs. Trying to engineer a common set of APIs that serve all channels eventually leads to ever increasing FE logic with a backend API with leaky abstraction (by virtue of trying to accommodate different UI concerns).

By decoupling the BFF APIs which are geared towards a UI specifically, in a way you are moving a big part of the logic and orchestration to the backend and keeping the UI layer super lite. From practical experience, this has been a very helpful pattern both in my startups and enterprise career.

Monks are quite sedentary. They sit at one place and meditate… not a lot of exercise, but don’t gain weight.

They do all their eating in a 6 hour window (6am ~ 12 noon) And fast during the other 18 hours - only plain fluids such as water or plain tea.

Practically, you can try with do all your eating between 11am and 7pm

Ah yes, sorry, didn't catch that.

You can pay them as independent contractors. They have to sign a W-8 BEN and you can make payments via Wise. If you see that you are hiring a relatively large team from the same country, then at some point you can open a local subsidiary (cost center) and employ them via the local entity. The way to do this has been the same - most US companies became open to this after 2020.

:) Brings back memories of doing this in 2002 to blast out Student Government campaign messages to students on campus. Back then email servers were very forgiving. I just had a loop that generated all combinations of <phone-number@carrier-x> and send out an email from a campus IP address via sendmail. It was a very effective way to send notifications at almost zero cost.

Back it up with some evidence

While working at one of the top 3 Global airlines (around 2015), I deployed an experimental feature that streamed the real-time airport indoor location (activated upon entering a geo-fence) into the airline's iOS mobile app used by hundreds of thousands of customers daily.

Setup was, mobile app -> detect beacon & ping web endpoint with customer-id+beacon-uuid -> WAF -> Web application -> Internal Firewall -> Kafka Cluster -> downstream applications/use cases

It was an experiment — I didn't have high expectations for the number of customers who'd opt in to sharing their location. The 3 node Kafka cluster was running in a non-production environment. Location feed was primarily used for determining flow rates through the airport which could then predict TSA wait times, provide turn by turn indoor navigation and provide walk times to gates and other POIs.

About a week in, the number of customers who enabled their location sharing ballooned and pretty soon we were getting very high chatty traffic. This was not an issue as the resource utilization on the application servers and especially the Kafka cluster was very low. As we learned more about the behavior of the users, movements and the application, mobile team worked on a patch to reduce the number of location pings and only transmit deltas.

One afternoon, I upgraded one of the Kafka nodes and before I could complete the process, had to run to a meeting. When I came back about an hour later and started checking email, there were Sev-2/P-2 notifications being sent out due to a global slowdown of communications to airports and flight operations. For context, on a typical day the airline scheduled 5,000 flights. As time went on it became apparent that it was a Sev-1/P-1 that had caused a near ground stop of the airline, but the operations teams were unable to communicate or correctly classify the extent of the outage due to their internal communications also having slowed down to a crawl. I don't usually look into Network issues, but logged into the incident call to see what was happening. From the call I gathered that a critical firewall was failing due to connections being maxed out and restarting the firewall didn't seem to help. I had a weird feeling — so, I logged into the Kafka node that I was working on and started the services on it. Not even 10 seconds in, someone on the call announced that the connections on the firewall was coming down and another 60 seconds later firewall went back to humming as if nothing had happened.

I couldn't fathom what had happened. It was still too early to determine if there was a relationship between the downed Kafka node and the firewall failure. The incident call ended without identifying a root cause, but teams were going to start on that soon. I spent the next 2 hours investigating and following is what I discovered. ES/Kibana dashboard showed that there were no location events in the preceding hour prior to me starting the node. Then I checked the other 2 nodes that are part of the Kafka cluster and discovered that being a non-prod env they were patched during the previous couple of days by the IT-infra team and the Zookeeper and Kafka services didn't start correctly. Which meant the cluster was running on a single node. When I took it offline, the entire cluster was offline. I talked to the web application team who owned the location service endpoint and learned that their server was communicating with the Kafka cluster via the firewall that experienced the issue. Furthermore, we discovered that the Kafka producer library was setup to retry 3x in the event of a connection issue to Kafka. It became evident to us that the Kafka cluster being offline caused the web application cluster to generate exponential amount of traffic and DDoS'd the firewall.

Looking back, there were many lesson learned from this incident beyond the obvious things like better isolation of non-prod to and production envs. The affected firewall was replaced immediately and some of the connections were re-routed. Infra teams started doing better risk/dependency modeling of the critical infrastructure. On a side note, I was quite impressed by how well a single Kafka node performed and the amount of traffic it was able to handle. I owned up to my error and promptly moved the IOT infrastructure to cloud. In many projects that followed, these lessons were invaluable. Traffic modeling, dependency analysis, failure scenario simulation and blast radius isolation are etched into my DNA as a result of this incident.

They should be able to find a cloud provider in Russia

If an underwater Datacenter is established in International waters, do any of the data and privacy laws apply?

[Ctrl] Right/Left arrows

as an alternative to 3 finger swipe, to move across multiple desktop spaces. Especially helpful when when you have multiple editors and layouts

[cmd] `

open .

Transactions Per Second.

Always looking to optimize on cost for AWS. But it's a tradeoff of something or the other. Light Sail sounds like a great solution for some use-cases though.

We run this for a Global/North American airline and easily hit 1k TPS just on API and event processing traffic. The spikes can show up anywhere in the multitude of processes due to various business events (high reservation traffic to irregular operations due to weather, pandemics etc.) Performance and reliability wise, serverless has been a very predictable consistent experience. Costs are another story.