Mike Levin SEO

Future-proof your technology-skills with Linux, Python, vim & git... and me!

Of Vendor Wrangling & Tech Finesse

by Mike Levin SEO & Datamaster, 07/25/2013

Okay, starting a new day. New daily journal entry. It’s still only 9:17 AM, and I’m starting this entry, and already have an email off to my boss that’s been languishing a few days over simplifying the complexity of the answer - question being, how easy is it to extract the social functions from Tiger for Linux cron jobs and such. But I feel (and I’m sure he feels) a certain stall-out in my prototype delivery work in my new role. Artful information-exchange between the key stakeholders at the key time, overcoming the key obstacles, is what keeps these prototype projects moving forward. At first, I was given them one at a time, but certain ones have so many moving parts and dependencies, I can’t really be in a holding pattern wasting my time doing them serially. I have to do them in parallel. The trick and the question is how many such parallel prototype projects can I take on, adequately deliver-on (or alternatively explain why it can’t be a quick-and-clean prototype of the MikeLev.in variety), and not drop any balls.

And so it seems a big part of what I’m doing is gaining my legs in this new field of agile information system wrangling. That’s what all this is. As purely as I would LOVE to stay in the world of core Linux with Levinux, Python, vim and git, it appears that being the information age warrior such as I’m trying to be requires venturing into the hostile bizarre world of .NET and vendors desperately interweaving needless complicating license burdening expensive dependencies that once was the Visual Basic >=6 consultancy-world, but which today is ASP.NET apps that kind of sort of work in Chrome & Firefox, but which you had better still use Internet Explorer to be sure. Such apps tend to be back-ended by SQL Server. And because the developers are primarily interested in their consultancy careers rather than the best app possible (such is the standard in the consumer-goods world which drives iPhone UI’s & such to be so awesome), these apps aren’t exactly written to be robustly interacted with through software clients that aren’t their own.

The internals of such software exists in ASP.NET codebehind files. Enforcing data integrity happens in the browser with JavaScript form validation. Triggered events happen in this .NET code sitting on a file on the hard drive, instead of in triggers inside of SQL Server being called from stored procedures working on databases that have all the appropriate data-input constraints, foreign keys, and such. In other words, a business system app can virtually be inferred by a Ruby on Rails-like generalized system via an interrogation of all the enforced data integrity in SQL Server. You just look at the tables, indexes, foreign keys, stored procedures, tigers and the like. If all is set up correctly, there’s really only a very small set of apps that can exist that can wire to it and behave properly within those constraints. In other words, your SQL Server database IS your config file, and the application layer can and should recognize this and adapt it’s UI to it. ROR works roughly this way.

Annoyingly written ASP.NET apps work entirely inverted to that. There are no foreign key constraints, and you’re lucky if you get a true primary key that’s not the lazy-man’s Auto-Index. Without the database itself enforcing data integrity, there’s hardly any reason to inspect the stored procedures. Using them can do as much damage as inserting directly into the tables, given sufficient permissions an ODBC connection. And if the existence of data in one table necessitates things to happen elsewhere (triggers), then you can look for these triggers in SQL Server. But if you don’t find them, it doesn’t mean the absence of “must occur” events that prevent data corruption. It means that those triggers are hidden in C# code-behind files scattered on the hard drive of some webserver is not the machine you’re looking at, but which connects to it through a similar ODBC connection you’re using to look at the database. In other words, you have to be Sherlock Holmes to figure out what’s going on, rather than a basically competent auto mechanic of information systems (sysadmin, dbadmin, etc.)

All I have to do is write-up my discoveries from meetings earlier this month with a co-worker who has access to the live production system, and my discoveries from a phone-call I had just this Monday with the vendor - as far as this prototype goes. There are several ways to skin this cat, and I’ll write them up here in my daily journal and actually push them out public, as a nice documentation of “can’t stop me” thinking. Tech’s tend to blow smoke in your face, because they can. Think Star Trek techno-babble. We can’t reboot the tachyon field generator because the bobbles in the flux capacitor are nearing end-of-life and the nearest depot is still ten-million parsecs away. To say that I love it when tech’s start pulling that shit on me is well… an understatement. I live for those occurrences when a tech tries to blow smoke up my ass. Think being told of the reasons why you can’t do something, and a giant smile crossing your face knowing it’s just a matter of how much face you wish to allow him/her to save. You’ve been lied to, and you know it. You can demonstrate it to everyone involved in precisely as glorious a fashion as you wish. A giant power-shift has just occurred.

It goes something like this: Q: Oh, all data integrity is maintained through the Application Layer (ASP.NET)? A: [A little embarassment] Yes, we haven’t really implemented the foreign keys in the database. Q: Oh, what about the triggers? A: Yeah, the triggers are handled in the .NET code as well. Q: Okay, so given precisely the correct input data, I could still work through the stored procedures and do non-corrupting inserts into the tables, right? A: Well, the system is tied to a number of other systems, and doing something through the Web user interface triggers off a number of other events that need to occur. ME: Okay, so then of course working through the Web user interface is safe, so all I need to do is fire up WireShark and pick apart the communication chatter and emulate that. I’ll require original login to occur through the real app, then peel off the authentication token and hijack the session for my own interface. THEM: The session will time-out. ME: I’ll ping it to keep it alive. THEM: if your requests are coming from a different IP than original web login (handing hijacked session over to a cloud server or something), we can stop the hijacking. ME: Oh, I can make my client originates from the same IP and even uses the original useragent. It will be indistinguishable in all regards from the original browser. THEM: Oh. Well, that’s going to be a fragile app. ME: Yeah, I know. But I’m going to give my employer the option.

After a bit of can’t-lose Kung Fu like that, the vendor starts to see they better play ball. It comes to light that there are several requests in by my company that I didn’t know about that would call for the implementation of certain API’s that would also be useful to me in this prototype. The schedule is like 2 months off. I hear 2 months, and being one of the schedule-best-guessing over-optimists myself, I hear 6 months, and tell them the prototype if I allow it to proceed can’t wait 6 months. Just go ahead and peel off a VMWare instance of the webserver and database for me. I’ll go into it and do the rest. [Audible worry in the background]… THEM: That’s not a good idea because really so many systems are connected that it’s not a simple matter of cloning 2 machines. ME: All I’m doing is simulating what happens when you post a time-entry. That’s what? CompanyID, EmployeeID, JobID, WorkCategoryID, TimeStart, TimeStop? I’m not going to submit the week’s totals. I’m not going to do approvals. Just insert, insert, insert with very known input-ranges. Do I really need a tangled octopus of systems to simulate that? THEM: Oh, I see. Your scope is really that small (Translate: shit, we can’t blow smoke up this guy’s ass). We’ll see what we can do. ME: Okay, I’ll report back to my bosses.