Electronic Locking, Brother & Ubuntu, GAE Python 3, Programming, Payments, Outsourcing, Hosting

Post date: Sep 17, 2016 8:36:10 AM

Drawbacks of electronic locking. In some cases it doesn't unfortunately deliver as promised. In some cases key identifiers might wear off so badly that it's impossible to reliably identify keys. Another problem is that locking management it deeply outsourced in deep nested chain. This means that any change that needs to get done, like disabling lost or stolen keys might take much longer than vendors advertise. They usually claim stuff like "immediately". What a claim. In truth it might take several days to get the task actually accomplished. It's just like out sourcing firewall management. I've seen so many times who task which should take about one minute, end up taking weeks or even months in some cases. This unfortunately applies to electronic advanced managed locking and access control solutions. Now disabling lost key has taken over 24 hours and counting. So much about all those bs advantages the sellers are always talking.
Even more fun configuring Brother Multifunction printer with Ubuntu (Lubuntu to be exact, but so what) and Scanning over Network (TCP). Luckily I've blogged all the essential things. Aka, hidden dependencies not publicly announced as well as the commands to activate the printer on computer.
Google App Engine Python 3 support - Finally. Well, maybe that's too late? Yet it's good have. In case there are some projects which I would prefer to run on App Engine. So far Linux VPS servers have provided a lot better bang for buck. But of course those solutions do not scale like App Engine does. Yet for limited loads, these are so much cheaper to run.
Found out more code made by elite coders which loop over data without any sleep virtually consuming all possible resources being thrown at those. So, how much server capacity is enough? Add 100 new machines to cluster? Not enough, still being 100% loaded, should we add more? - Phew, no comments. - As said, it's unfortunately very common that many programmers don't have a slightest clue what their code is actually doing. It was slow so I added threading... Great, but did you ever consider that it's slow because it repeatedly triggers table scan on HUGE table which possibly can't be even cached in memory due to it's sheer size. How about doing something else than adding threading to alleviate the performance problem. Just as awesome as acquiring exclusive lock on table for minutes. And other cool stuff which happens way too often. But I thought the ORM... Sigh. Fix that with threading and, now you've just created one kind of buffer bloat, now you've just created a queue of exclusive locks waiting to be applied on the table. Putting any other access at the end of the queue, guaranteeing that it's going to be darn slow. Adding threading once again just made bad situation lot worse. - Thank you for that too.
Studied some interesting payment related market studies. But unfortunately all related information is proprietary strategic business information, so I can't really say anything more about it. But it's interesting. Only thing I can say is that providers often got small market shares and nobody's dominating the market.
More server outsourcing and hosting negotiations. Ahh, it's so nice to see how different strategies different organizations try. They don't get it that bs will only make your negotiation position a lot worse or get you ignored immediately, when buyer is competent. Facts and prices, no talk about gold levels and other stuff which really doesn't matter at all. I don't care if your helpdesk. I'm actually really happy if I never need to contact your helpdesk. I'm not interested if they're really polite and nice, I want them to make the stuff just work.