2015-06-11

Oh yeah, the thing called team work

Manager,

I did have a chat with Techlead yesterday. It was mostly unrelated to work, and it was amiable and left me optimistic. I'm hoping it's the beginning of something better.

However, the notion that suggesting bad stuff will be held against me sucks. It means discussing approaches to problems comes at a cost, but clearly an end result that does not meet expectations is costlier.

I'm hoping that this won't happen again. I don't want to be hard to work with and I need feedback to improve.

Below is what I consider to be a good idea, and it would be intellectually dishonest to say it's not an indictment of Techlead, but I'd really rather earn my untrustworthiness and incompetence with my own words.

In fairness, I wasn't quite this coherent when I talked to Techlead about it.

Yours angrily,

Evil Albino

---

One of the weaknesses of the current implementation of uniqush-push is keeping the client waiting on an open http connection for a result response while uniqush-push connects to remote services.*

Unless you're implementing something acting as a conduit between two parties, an http proxy, for example; or you know for sure you'll always get a timely reply, it is, n my opinion, bad design.

APNS is particularly bad, for several reasons, one of them the 20+ second wait time between attempts.

No wonder uniqush-push runs out of memory and file handles in a high volume environment.

That's why I proposed to make it async with callback:

* you send request and pass along a callback,
* uniqush acknowledges the request and promises to get back to you,
* when done uniqush calls back with the result,
* you then decide what to do with the result, in our case we could, if it failed, fall back on our old push implementation.

I suggested Hessian as a callback service, not out of conviction, but because Employer seems to like so much. I had checked and there are go libraries for Hessian. But the protocol of the callback is irrelevant.

Techlead pointed out that:
A) waiting on result is not a problem worth solving,
B) especially since it's mostly an APNS issue and we're not using uniqush for APNS,
B) we've modified our Hessian and would have to make modifications to any existing go library,
C) we'd add another async layer to an async layer, ie the web tier's push requests are handled asynchronously by the mobile tier and it's the mobile tier's job to do the work and of it has to wait, let it wait.

I agree, ultimately it's about which problems are problematic enough worth solving.

This was not an ideal exchange in terms of attitude on either party, but I it's unfair to hold proposing ideas against me, even bad ones.

---

* A single push request can legitimately cause many connections to all services uniqush implements. Even if this goes flawlessly and while it's done in parallel it'll still take time.

No comments:

Post a Comment