Python, Firebase, IPv6 Literal, Onedrive, Outlook, gcsf, Cloud

  • Python 3.7 installed and tested on all Linux platforms. Works perfectly, in test, development and in production. Windows platform will follow soon. All projects, unit tests etc passed. So no known reasons to stick with old version. Same work needs to be done on Windows still.
  • Went through Google Firebase / Firestore documentation. Yeah, yet another document database. Nothing new really. Basics like: Data model, Data structure, Data insertion, Data transactions (snapshots), Data batch writes, Data validation, Atomic operations, Security rules. Compound queries are also logically totally standard, just with bit different syntax. Pagination using startAt and startAfter, ok, works, of course limit and order by features are also supported. Support for Composite Indexes is also provided. Internal support for Offline Data is quite nice. I actually use quite often SQLite database just in this manner. Where there's "type" or "document" column, key and value. It allows single table to contain several "types or documents or collections" having own key space and then values are of course any data. Then the data can be stored as pickle, msgpack, protobuf, bson or json, or traditional integer or string. Simple things can be done just in so many different ways. The Firebase also seems inefficient for many use cases, but that's quite common for simple databases, which offer limited interface. It was kind of funny that the Firebase Python documentation is for Python 2.X which of course is well, pretty old stuff.
  • Did someone say horrible kludge stuff? ipv6-literal.net - Omg. Yeah, it works (no it doesn't work with your browser). But it's kind of absolutely horrible! And of course it only works on Windows. Well, yet another format for expressing IPv6 addresses to confuse users. Read more IPv6-Literal @ Wikipedia
  • Similarly there has been lot of questions about using OneDrive. Mapping OneDrive as network drive doesn't seem to really work at all. But you can always use the OneDrive SyncClient and then just Subst the drive to a drive letter. Not exactly a same thing, but performance wise it's better option. Because data can be instantly dropped to the OneDrive "drive" and then it'll be synced in background. For most of users, this is better than the actual usage as network drive, which performance is usually extremely bad. (It's much worse than the network performance is).
  • More Microsoft Outlook quality, when I move messages from folder to the same folder, the messages disappear. Until I refresh that folder. Kind of funny. It seems probable that they actually move messages to the same folder, and that hides the message being moved. And it appearing to the same folder, doesn't trigger refresh, so the message remains hidden until folder content is refreshed. - Not serious, but just gave me a WTF moment. - Why would users set source and destination folder to the same folder when moving messages. It doesn't make any sense anyway, because the message is already in that folder. - Therefore, why would anyone bother to test for such event?
  • Using Google Drive as a (FUSE) file system - Nice. In some cases, these things are really useful things to have.
  • GitLab, not leaving the cloud - All very familiar arguments. I've been at the core of such discussions a few times. And so far mostly opted for Cloud. There are just a few specific cases where I haven't used cloud.
  • Non-cloud use cases, for now. Cheap semi long term storage. It's hard to get a cloud which would beat price of 16TB drives in RAID6. It's just so cheap. Especially when availability isn't really important. If it's down for a day, then it is. Maybe could be replaced with B2 in future. It's still hard thing to replace the use cases where speedy local access is required. Yet this could be handed by the cloud cache / buffer / mirror box. Which would cache data to local disks from cloud (single disk, no need for raid) as well as buffer writes to the cloud, to allow speedy read / write operations locally. But that adds complexity. One solution is simply to have local disk system which is backed up to the cloud or vise versa. - Another use case, is servers with high RAM, CPU and storage space requirements. But if high capacity Internet bandwidth is required, then it's dedicated server. Using cloud for this, would be just wasteful. Yet again, case where high reliability isn't required. If there's a problem with the server, then there is. It will be back as soon as it's fixed. - All the other usual cases, load balancers, database servers, front end & back-end servers. application, integration, terminal servers. etc stuff. Is of course in the cloud.
  • Something different? Miniature Hit-to-Kill Missile (MHTK) by Lockheed Martin.