pudwallabee

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.

For example lets use REST.

POST /addresses

{ "first-name": “bob", “last_name": “johnson”, “street”: “foo… }

201 CREATED: { “id”: "8c3d03c4-7fe7-4355-afd4-25e838c4f884" "first-name": “bob", “last_name": “johnson”, “street”: “foo… }

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?

POST /addresses { “id”: "8c3d03c4-7fe7-4355-afd4-25e838c4f884" "first-name": “bob", “last_name": “johnson”, “street”: “foo… }

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.

..or maybe thats the plan.

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.