My first poem for programmer girl 😘😘😘

My life is incomplete without you,
You are semicolon of my life

You are my increment operator,
you make my value increases

I am username and you are my password,
without you No one can access me

You are my initializer,
without you my life would point to nothing (NULL or “0”)

If I were a function you must be my parameter,
Because I will always need you

Can you be my private variable?
I want to be only one who can access you

You are my compiler,
My life wouldn’t start without you

You are my loop condition ,
I keep coming back to you

My love to you is like recursive function,
It will never ends & Will never enter into infinite loop

Forever and Ever

I can't stand Swift's initializers. No other languages have the problem with constructors/initializers that Swift does. It's a complete failure of a feature and to hell with safety if it comes with this cost.

Just to illustrate how ridiculous it gets, I want to have a class where my initialization logic can be split among reusable parts. That is, the logic that initializes the class with no parameters has logic that I want to reuse in my other initializers. Simple DRY stuff. Well, the only way I can do that in Swift is if I use a convenience initializer that calls another one. But convenience initializers have completely different rules from designated initializers (again, something only Swift does).

For example, you can't access "self" until you call a designated initializer. You can't chain designated initializers, and if you want to chain anything in the same class you have to handcuff yourself by using a "convenience" initializer (there's nothing convenient about them, I might add).

So now I want to subclass my class and initialize myself using one of my superclass initializers. Oh but the one I want to call is a *convenience* initializer so I can't, unless I turn my new initializer into a convenience initializer. Except wait, a convenience initializer must delegate with self.init(), so it can't even call a superclass initializer!

And it just goes round and round and round. I don't know if I should try to convert all of my initializers to convenience initializers or the other way around.

Why all this nonsensical madness? Get rid of the distinction and go back to nice clean powerful initializers like Objective-C. I mean what does it have to take? This is a complete nightmare.

!rant
Loving the the fact that constructors in Swift (initializers) can fail (returning null/nil) and be async.

In C# there is no other way than using static methods instead.

My workplace is still using xml based configuration, and non-spring boot projects.

So every spring boot tutorial I find feels like "Look at how easy you can get this running" and then it's just actually a toy you can't get into production.

Also it kind of bugs me that you need to be online to actually be able to initialize/create a spring boot project and every single tutorial says so.
You can make a local network m2 repository, but can one make a spring initializer service?

Either way, migrating every single project to Spring boot is a no-no,

And I'm stuck with like 5 prototypes of SSO integration from which only 2 work, and the other 3 have their own problems.

One does redirect to the login and all, but the SAML endpoint gets 404 on response when you log in.

One is on OpenID Connect, but I would need to update the project from Spring 3 to Spring 5 to get it working, which upon attempting to do seems to break everything else.

One has an external library handling the security context just the way we are accustomed to, but it only does a 401 forbidden when you go without logging in and I'm starting to think it is actually one of those that require you to extract the token or something manual like that, which wouldn't work for us

The other two are spring boot tutorials that worked out of the box, both SAML and OpenID, still can't use those for the main projects.

I'm tired of dealing with this configuration hell, been two months at this, I want to get features done as usual, not be stuck configuring stuff that might or might not work.

Rant aside, I think I figured I need to use a different Security adapter, but I needed to vent.

Question for iOS Swift guys:

Since Implicitly Unwrapped Optionals are now dropped for a while, and everything is an optional, hiw can I now declare property that has no value and intializer will not make fuss?

I used to do this:

class Bullet {
var calibre: Double!
}

This way I can avoid initializer which gets useful when there are properties which hold complex types, which get useful when writing tests.

If I remove ! Then compiler complains.
If I put ? Then My code becomes crap of guards and ifs to check for optionals.

Really hate this Optional thing in Swift. Half my time when I jave an issue is related to optionals.

Btw,
let x: Int! = 10
let y = x, yields y: Int?