Requirements, Specifications, Materialize CSS, Race Conditions, Web Sockets, Statistics, Time Zones

Post date: Jan 14, 2016 3:08:19 AM

• Stuff as usual. In one case when I asked if there are any requirements for database, answer was no. Standard database and configuration will do. After a while it turned out that it's essential that the credentials for the database are X characters long (not shorter or longer) and the password needs to be x characters long also exactly. As well as the password and username cant be changed. It also turned out that even if everything is configured correctly with the AD the Trusted_Connection can't be used. After a while, it also became evident that the database name must be fixed. Initial Catalog or Database parameter can't be used because the database name is hard coded. Now when we talk about database 'standard configuration' does this sound like it to you? Not anything new in IT business, but it's just slightly frustrating. Everything is setup as requested and then there are demands and more demands. Actually this is not unusual. It's pretty normal human behavior, when asked nobody bothers to think about it but later they'll be whining about it not being something they didn't mention earlier.
• Had a ton of suffering with Materialize CSS cards. It should be trivial and simple, but it isn't Those cars only work well if fixed in size. But I would like to have Google+ kind of interface where card size is allocated dynamically and the image with doesn't always match the card width. In some cases people take photos with phones and as we know, aspect ratio can be 9:16 and not wise versa. Actually the cards with Materialize CSS got even wider aspect ratio. I didn't check what it is, but it's probably more like 4:1 or something like it.
• Fixed bunch a of extra race conditions in one code. Phew. It's staggering how many of those issues you can put into code when coding fast. In some cases the optimistic concurrency control tried to recommit data without rereading it first. Which is well, guaranteed to fail again.
• Thought about web sockets for one project, yet I've been usually using web sockets on client side and only with 'trusted parties'. If web socket isn't written well with strict time outs and limits, it can be really easy way to DoS service even without DDoS. We sockets are very neat way to deal with trusted parties but I'll prefer standard HTTP/2 web hooks over web sockets, those also perform extremely well as well as the threat models are better handled, at least with the tools I'm currently using.
• Wrote extensive alternate statistics aggregation and collection code for one integration project. Now it can update statistics in less that 30ms and builds aggregate data on hour, day, week, month and year. I've seen so many cases where statistics collection is really taxing the system. In this case hour statistics is built first, it's being used for day and week statistics and day statistics is used for months and months for years. This allows to update information in less than 30ms for all aggregate levels. Only new data for new hour(s) is processed when updating stats and then rest is updated accordingly. I've seen solutions where things do work like that but all aggregate levels are built from original data source, making it really slow and heavy, especially if done repeatedly.
• Reminded my self about (GMT / UTC / UTC±00:00 / Zulu Time Zone) - I prefer using UTC timestamps always in software and integrations etc. Otherwise everything gets sooner or later badly screwed or you'll be looking something in logs and wondering why it's no there. Before after digging around for a long time you'll figure out that the system is using wrong time zone or not using summer time or something other screwing up the times in logs. It's always nice to notice that in some cases you'll need to use .total_seconds() and and in some cases .timestamp() and at time tz=... and at times tzinfo=... etc. But that's business as usual. kw: timezone, timestamp, total seconds since epoch, POSIX time, Unix timestamp.
• So much coding, studying, etc. Helping people to build their websites. Helping friends with their projects and stuff. Working as generic highly trusted helpdesk for close friends and other joys of life.