Blog‎ > ‎

SQL DBA, CLM, HTML5 vs App, coding patterns, SFTP, Java, Data Lake, Pointer fail

posted Jul 2, 2016, 10:52 AM by Sami Lehtinen   [ updated Jul 2, 2016, 10:52 AM ]
  • Picked up again interesting SQL Database Engineering chatter. DBA claimed that MS SQL is bad, because it doesn't work properly with large data sets. Many other databases perform flawlessly but MS SQL fails. Well what was the query? SELECT * FROM freaking_huge_table ORDER BY id; MoveLast; Hmm. Maybe it's better if I don't say anything, because I don't have anything nice to say at all. It seems that most of people are absolutely clueless why there's a thing called Query Timeout. Deep breath, not my war to fight. But still, I'm feeling some mental pain.
  • Studied Contract Lifecycle Management (CLM) - tools for one project which involves large number of contracts.
  • Even more interesting discussions about HTML5 / Web App vs Multiple Native Apps.
  • Nice post about coding patterns and using if statements. - I liked it. Most of the cases shown are more than familiar to every coder I guess.
  • Even more SFTP servers configured. Secure configuration is really boring, N+1 parameters to tune and figuring perfect setting for everything and configuring multiple overlapping layered firewalls.
  • Security tools. Awesome! This one security tool requires to use IE11 with Java to make systems extra secure. Great! Or maybe not so? Didn't work with Chrome, Firefox or Edge. Absolutely requires Java Plug-in to be installed. Feeling so secure.
  • Laughed at Data Lake approach. I've actually used that with many projects. I might have a single log life, which is called dump. It's a file where inbound or outbound objects are dumped as JSON and file is compressed. All object types are just dumped into same file. But isn't this a data warehouse or a log? Well, basically it is. But the main point is that only code required to utilize this data store is just dump(object). I don't have even code in place to parse that dump file. All data is there, if it's needed later. Cheap storage has made this possible. When and if required, I can just write a program which reads and processes the data from the log I'm looking for. I've actually used that a few times for cases where I've needed to check something. - Just checked from server. Yesterdays dump is 509 megabytes after LZMA compression. - Is this something new? Sounds funny. Because this is just an obvious thing to do. Dump stuff that might be needed, but isn't currently needed and store it. Cheap storage space makes this totally possible. In normal circumstances I would only keep such dumps for a week or so, for debug purposes. But because there's plenty of cheap storage, why to delete the logs / dumps, if those can be potentially useful later.
  • Encountered serious issues due to extremely classic reason. Pointer pointed to near end of memory page 2 bytes from end of page and then memcpy tried to copy 4 bytes. Memory access violation and crash boom bang. This only of course happened when pointer was pointing to the very end of page. Causing problem to be bit hard to repeat and isolate. Oh well. This is one of the reasons why I prefer mostly using modern and higher level languages for my software development. Wasn't first nor the last time pointers and data types cause a screw ups. This time the error wasn't even in my code. Phew. But it still caused my code to malfunction when calling other code which had the issue. Doing too much Python and Java makes you forget that stuff like that even exists.
  • Something different: Gravity-Gradient Stabilization