IT/Software career thread: Invert binary trees for dollars.

I'll stick to my structs and enums

Certainly not, no talk of trees

Spent all day yesterday and continuing to merge two BIOS code bases (based off a single codebase, but with their own modifications). I've never written so many #ifdefs in my life.

Still a few hundred files to modify by hand. Hoping once it's done the BIOS images still work

Deathwing_sl said:

They won't, and it will be for the stupidest bug too.

Click to expand...

Hence the smiley. I already know it's broken without even running it.

A fix for my timing issue was merged into the main branch of the library so now I just need to wait for that to make its way into the world at large.

Project is still in testing. No feedback so far. Doing other things in the meantime.

So, back in 2008 our company re-developed our bread-and-butter application from an old school VB6 desktop app to Silverlight. Big mistake because we're now paying for it as more browsers disallow the plugin. We now have a team investigating which technologies and frameworks to rebuild the application with.

The team responsible is clearly heading us towards a Javascript client-side framework such as Angular, React, or Ember and a WebAPI back-end probably using ASP.NET WebAPI2 and MSSQL (which makes sense because we're not redoing the db).

I have my reservations on the Javascript front-end, though. It makes sense for traditional public-facing web applications, but for us our application is used within hospital systems. I've been warning them that it may not be a good idea to have our front-end written entirely in Javascript. It's possible a hospital's IT could disable Javascript support on their browsers for security reasons. If they were to do this then our application wouldn't work. Period.

Additionally, our developers have little to no Javascript experience. Trying to apply C# and OO constructs to Javascript will be a mess.

I'm suggesting they go the ASP.NET MVC route and just spit out plain-jane HTML and CSS withminimalJavascript (for validation and some nice UI-widgets like date-pickers, etc.). So Javascript isn'trequiredand the application will continue to function if it's turned off.

I get why they want to completely separate the front-end from the back. By going ASP.NET MVC route we could be facing the same dilemma 5 years from now, I suppose.

I dunno, just kinda wanted to rant a bit.

My thought would be to err on the side of caution like you're suggesting. I mean, the decision makers could always negotiate not having clients turn off JS but that's a headache for both sides and the client could always go elsewhere if they felt security was at risk. Shit, they should KNOW this already. I've been in the hospital industry. HIPAA dictates a lot, including security. I guarantee that's a non starter for a lot of places.

I had to touch over 1000 files manually. Somehow the bios still builds. Fucking damnit all.

I've got a whopper of a project we're working on for this release and I seriously don't believe it's feasible.

First, some background: as I mentioned previously, our product is used in hospital systems. One of the features of this product is that we can transmit HL7 data to the hospital's HIS. Up to this point the mechanism that we used to massage data into a form that the HIS accepts is via an old-ass Visual Basic 6 application. We have an entire department whose function is to modify VB6 scripts to transform the data into whatever the client needs.

It's works great and we can pretty much do whatever the client requires since we have the full power of a programming language (e.g. conditionals, loops, wealth of string formatting options, etc.) Problem is, it being VB6 is starting to cause problems and it's really at a point where it needs replacing. What sucks is that any replacement will require touching every deployed system out there since the code is specific to Visual Basic 6. There's no porting it to straight into a .NET version or anything. Basically we're looking at a complete rewrite for every site. It sucks and there isn't any way around that.

However, for it's replacement TPTB wants a dumbed-down GUI-based tool that will allow formostof the functionality of the VB6 app. Conceptually, the tool will have drop-down pick-lists for "IF THEN ELSE", "STRING CONCAT", "STRING APPEND" -- shit like that. In my opinion, this is insane. Absolutely insane. MAYBE this would be feasible if we had real UI experts working for us, but we don't. Most of our devs are back-end guys with minimal UI experience. In fact the demo tool that the team spent months working on is pretty ugly. It actually works okay for simple scenarios but it quickly explodes into an unwieldy mess once one needs to do nested conditionals and stuff (which is a pretty common requirement).

Anyway, I'm wondering if anyone has had experience with any sort of tool that does this sort of thing (i.e. a UI-based script engine). I really would like to see some examples of their approach. I also toyed with the idea of creating our own VERY simple scripting language but, man, I have no idea where to begin on that one. And I realize that itself is no simple task.

Lastly, don't even attempt to recommend third-party solutions such as Mirth. Not-Built-Here-Syndrome is strong with us.

Some guy at work made a gui scripter for ssh sessions here since everything is done over serial comm. He did it in a way that you'd make a block diagram of your scripting steps and the program converted it to iron python and ran the script. Whole company adopted it.

The program SUCKED DICK. I hated it and never used it.

Noodlemod_sl said:

Some guy at work made a gui scripter for ssh sessions here since everything is done over serial comm. He did it in a way that you'd make a block diagram of your scripting steps and the program converted it to iron python and ran the script. Whole company adopted it.

The program SUCKED DICK. I hated it and never used it.

Click to expand...

Yeah, we're going to face a mutiny when the implementation guys see our proposal. Again, they're used to the flexibility of a programming language in order to get the job done. Forcing them to use a UI-based scripting "language" is not going to go over well.

What I suggested in the past (and was promptly dismissed out-of-hand) was to use an embedded scripting language, such as Javascript, Python, or even Lua, that the engine would execute against some context object. This way, the scripts themselves have no dependency on the framework they're executed on. We could easily switch from .NET to Java or whatever and the scripts will still be valid.