thibauts

« Don’t be evil »

The secret sauce will most likely be tight integration with Shortcuts, enabling the language interface to drive and automate existing apps.

I did exactly that with a custom GPT and it works pretty well. I did my best to push it to respond with its training knowledge about brand reputation and avoid searches. When it has to resort to searches I pushed it to use trusted product information sources and avoid spammy or ad-ridden sites.

It allowed me to spot the best brands and sometimes even products in verticals I knew nothing about beforehand. It’s not perfect but already very efficient.

That was indeed a big parameter. We missed someone on the team able to connect to us to one or two large early adopters. We learned that building a good product and building a company selling it are two very different things !

Lack of traction basically. We ran out of time and money. Also we, maybe wrongly, did not feel like we could compete with the big ones without clustering. Yet we had a lot of fun building it. It was a thrill to see our product deliver performance on par or above in-memory messaging systems while being fully persisted and fsync’ed. I’m sure you know what I mean ! Good luck with Iggy anyway. Looks like you are on the right track !

Built something similar in Go with a friend a few years ago.

https://github.com/thibauts/styx

That is my understanding also. I would very much like an expert answer on this one !

They make money because growth. Any strategy that is not based on information asymmetry or unique clever use of information makes less than the market on average.

You couldn’t feel that way if you had no doubt or did not care about your level or worth as a developer. So you do care about how others perceive your level and you are not totally convinced that your self evaluation is right.

I would say don’t judge yourself too much. You don’t have to be perfect (especially if you are not, and nobody is). You probably are in this business to learn, so give yourself some room to learn a bit (or a lot!) more. People that criticize your work may be wrong. Don’t take their criticisms as absolute truth. In case you feel they may be right, drop your ideas right away, ruthlessly steal theirs and make them yours. This is how you don’t get stuck in local minima. You don’t have to care about having been wrong, there are more constructive things to do.

It’s time we fork a « software design » category from the software engineering catchall.

Yet many great suggestions on this topic but one is missing, which in my opinion sums up a lot of the software design classics : « The Design of Everyday Things » by Don Norman.

You can deploy your whole monolith on one single lambda and it will scale the same. It may even help to keep it hot.

Services, micro or not are only really useful when load factors are vastly different and you’re not serverless. Or when you have sufficiently many large teams and a sufficiently large codebase that a single deploy becomes unmanageable because too much communication / coordination is needed.

Right. Then HTTP requests being share-nothing they horizontally scale in a single instance, too. Just spin more cores.

This microservices craze has been mind-boggling. As for many other fashions, it’s excruciatingly difficult to make young or even average senior devs understand it’s bullshit at 90%.

When Netflix does it and the self-appointed expert bloggers praise it, as a CTO or team lead you’re pretty much screwed.

I wouldn’t call these talented.

Welcome to advertising driven journalism.

I call it wasting time trying to fit square pegs in round holes. Many things and approaches have their virtues and their place, be it top-down, bottom-up or tests. Silver bullet techniques and dogma have absolutely none.

Then it’s not test « driven ».

How does TDD force you to a better design ?

No. TDD is as top-down as it can be.

« Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later. » [1]

[1] https://en.m.wikipedia.org/wiki/Test-driven_development

Used to use this cheat sheet

https://scikit-learn.org/stable/tutorial/machine_learning_ma...

Here is an event stream abstraction that has very strong semantics (exactly once in most cases) with simple usage examples, native HTTP and websockets APIs, strong atomicity and durability guarantees [1].

What it doesn’t have is clustering and a father that’s != null at marketing =]

[1] https://github.com/thibauts/styx

You’re right, I pushed it a bit too far.

What I was feeling and trying to convey is how it flips the design process from bottom up to top down, by forcing the design of the interface first. From my experience you miss a lot by doing that. The reason is when you start from the code interface based on some requirements you most often find an impedance mismatch when you reach the bottom AND you don’t get the chance to tweak or rethink the requirements from straight, simple bottom-up code. Requirements being natural language and by nature informal and incomplete (else they would be code), building on them is risky. Building on the software APIs you stand on (starting at the bottom) is much less prone to change. This is the sound approach in my opinion from an engineering perspective. You start from what exists and what you stand on and grow you software by aiming for the requirements, trying to land the closer you can to them.

This process of discovering natural interfaces that emerge when you specialize a lower software layer API is the most profound and impactful realisation (and huge boost in both productivity and quality) I had in 25 years of programming.

Everything starts to fit, have easy path forwards, becomes easy to maintain and evolve.

I think the gut feeling I have when I see people advocating for TDD is that. I feel it will prevent proper co-evolution of code and requirements, and lead to the usual mess.

When tests amount to specs waterfall tends be be referred to as TDD.

Exactly this. Encoding business requirements or expected output of a complex algorithm by writing tests before code can make some sense. Writing tests for something that has no defined shape yet doesn’t.

You can move the code that hides behind the interfaces that you test, but you can’t redesign these interfaces which is the essence of design.

That’s right, but the WebSocket browser API is event driven so the browser HAS TO recv from the socket and dispatch a JS event as soon as data is available.

You’ll get proper back pressure on websockets with synchronous clients that read messages actively.

This is a browser API spec problem more than a protocol problem.

What about a wire only linking the earbuds to each other and providing controls and a Bluetooth transmitter ?

This is my experience too. Millions of persisted and serialized TPS on regular NVMe with ms latency. Though it took a bit of effort to get to these numbers.

https://github.com/dataptive/styx

I’ll be more than happy to get your feedback if you test it ! Especially potential shortcomings preventing its use in production settings.

Styx was built with this kind of use in mind, among other things. If you’re using Go you can even use the storage engine standalone. It’s pretty robust and very fast (millions of fsynced writes/sec).

https://github.com/dataptive/styx

This [1] could be a solution to most of author’s problem. Simple to use / few moving parts, very high perf, native HTTP produce and consume, clear and simple processing model with strong guarantees, among other things.

[1] https://github.com/dataptive/styx