AppCode was ten times the IDE xcode is, only problem is they couldnt parse Apple’s storyboards and xibs reliably and probably due to some proprietary knowledge required to make that work.
I loved AppCode because I could go into a clients iOS app and the linter would immediately show so many problems that were easily fixable but Xcode would never show. I was sad to see it go.
The tooling(?) (starting with xcode) is quite objectionable and is enough to drive people (me) away. The language choices are well. Interesting.
Kotlin fills the need for mainstream Swift better than Swift, and without all the baggage that Apple brings to the table.
If you want to see what open source Swift is going to end up like, just look at GNU objective C. It will likely follow the same pattern of adoption over time and be hobbled on non-Apple platforms.
Im not sure why people post these kinds of things. First of all it does not define really anything, it just gropes at the subject trying to find something to hold on to.
And of course theres the crazy web articles that made funny memes about cows multiplying by calling POST over and over.
So Im not going to actually get into any of that text book stuff because alot of it is actually described in academic language, or simply being metaphorical, or describing a “result” as this 5 min blog post did.
So heres what idempotent actually is:
ID - empotent
Means literally “empowered by ID”, or ID aware if that feels better to you.
It means that things that have been created will not be recreated because an ID prevents that from happening. And thats all it means. To make that mean something in your app, you have to convert that to a semantic and hopefully contractual interaction.
The server returns the ID of the created address, which should now forever identify this address.
So what happens if we do the POST to addresses again and omit the ID?
We will be creating a new address we already created. This is exactly what should happen.
But what should happen if we call POST again with the ID?
You have some options for the response here. Here are some obvious choices:
409 CONFLICT
400 BAD REQUEST
The point being that POST should not process requests to create items that already have an ID assigned as provided by the client.
You can return a response like “Call PUT dummy” but thats not necessary.
And thats really it some shops sort of muddy the waters by saying that IDEMPOTENCY means “upsert”.
Again thats describing a behavior with an intended result not IDEMPOTENCY.
While its technically true that APIs should when provided with the same input have the same output it doesnt mean you should code a POST as an upsert.
We have semantics for creates and updates already in REST.
So be empowered by ids and make your apps semantics match.
Apple’s excuse is poppycock. 10s of thousands of developers in the US use Jetbrains products in the US and pay for them routinely with their debit cards on subscription. Jetbrains is located in St Petersburg.
They should be sued, and also given that such sophisticated attacks are usually the domain of state sponsors, if they dont pay they can be assured that the next one wont be reported to them.
In practice, *practice*, we use the term iterative pretty loosely. In fact sort of like this IEEE article, it feels dated now, and was never really true in my experience.
It seemed like the word iterative became a euphemism for “dont worry about it”. I have worked across the entire industry for 30 years, and I have never seen a “true iteration”. On any feature or application. Anything at the end of the sprint that doesnt work is just a bug. Thats not iteration.
Iterative development was just a powerpoint slide for the Scrum Industrial Complex which was hard selling itself and it worked!
This article which seems even more antiquated than Id like to describe, seems to confuse iterative with “having all the requirements at once”. Iteration and the quality of requirements, and the bandwidth to analyze them and design a system dont really have much to do with each other.
And thats why iterative came to be a stand in for “dont worry about it”.
I personally feel that the creators of Scrum or some responsible group of modern architects, should audit the results of supposed iterative development, and do an honest assessment of what it actually is in practice. Because its not what we were sold, and its not iterative. It does result in awfully bad software but there have been other shifts in development practice that have accelerated the awfulness of delivered work in the industry, and Ill just leave it at that.
Please resist the temptation to comment, “because your not doing scrum right”. That was the genius of the Scrum Industrial Complex, to suggest that somehow this simple thing is really magical and complex and keep repeating the same things over and over. Its not magical or complex, its just bad.
As far as the article goes, I have been on projects that did spend over a year ingesting requirements and doing design before starting to code. Its true they usually fail. But thats a money/commitment/time to market problem.
Starting to “code” right away creates some better optics and fewer arguments in meetings. The one who pays the piper calls the tune as always.
The termites thing is kind of amusing. But isnt much of whats described in the article properly known as “rent seeking”?
A monopoly might be the ultimate form of rent seeking. But for example a company that buys other companies/products in bulk to trap customers, but never improves or maintains those products and increases prices, is not only engaged in rent seeking but probably committing fraud. But expectation fraud is not a crime.
I think theres a tipping point in economics that once rent seeking becomes a certain percentage of the economy, its pretty much over.
Its economic corruption partnered with govt corruption.
I read the article. She specifically stated that back to work policies of 3 days in the office, with congestion pricing might go back to full remote. There may be different versions of her comments, but thats what I read plainly in the beginning of the article.
This has kind of always been the case hasnt it? The governor of the state has special powers over NYC. At least they have stepped in and bullied the city before, usually because the city is broke or has some crisis it needs the state to sort out with a pile of money.
Personally, as a remote worker, it bugs me that she’s doing this to force people to go to work. So basically she wants the pollution and massive waste of resources if someone can sell a bunch of 15 dollar sandwiches and 10 dollar coffees at street level every day. In other words she wants to fleece employees either way.
I feel for the business paying rent based on foot traffic in cities, however they know that if the foot traffic goes away, they can get out of their leases, since at least in malls etc the price per sq foot is based on foot traffic.
But what I have zero interest in is this argument that I have to go to work so that I can be fleeced by businesses every time I walk down the street, so that they can stay in business. That is not my problem. Its pretty insulting given how much better for the environment and people’s personal lives it is to work remotely to treat us like a bunch of chickens going through a toll gate.
Progressive companies that know the future have already let their leases go and gone full remote. More will follow. There will be no back to office.
Wow, well I guess its good to know what your weaknesses are. I support anyone who bothers to try and improve the UI situation with the web.
Unfortunately, I think at some point the industry is going to have to start over and throw away HTML and CSS. Maybe throw away the browser as well. Javascript will survive on its own, but who knows if it will be useful in Web 6.0
The web browser is really holding us back. Something’s gotta give. And htmx is not going to be it.
I have seen Kafka pulled out by its hairs and replaced with request based architecture.
Event driven architecture, to me is itself an antipattern.
It seems like a replacement for batch processing. Replayable messages are AWESOME. Until you encounter the complexity for a system to actually replay them consistently.
As far as the authors video, while there was some truth in there, it was a little thin, compared to the complexity of these architectures. I believe that even though Kafka acts the part of "dumb pipe", it doesnt stay dumb for long, and the n distributions of Kafka logs in your organization could be 1000x more expensive than a monolithic DB and a monolithic API to maintain.
Yes it appears auditable but is it? The big argument for replayability is that unlike an API that falls over theres no data loss. If you work with Kafka long enough you’ll realize that data loss will become a problem you didnt think you had. You’ll have to hire people to “look into” data loss problems constantly with Kafka. Its just too much infrastructure to even care about.
Theres also, something ergonomically wrong with event drive architecture. People dont like it. And it also turns people into robots who are “not responsible” for their product. Theres so much infrastructure to maintain that people just punt everything back to the “enterprise kafka team”.
The whole point of microservices was to enable flexibility, smart services and dumb pipes, and effective CI/CD and devops.
We are nearing the end of microservices adoption whether it be event or request driven. In mature organizations it seems to me that request driven is winning by a large margin over event driven.
It may be counterintuitive, but the time to market of request driven architecture and cost to maintain is way way lower.