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

Deathwing

<Bronze Donator>
16,719
7,734
I'm still confused, who is this gui intended for and how does it help compared to programming in ANY scripting language?
 

ShakyJake

<Donor>
7,885
19,828
I'm still confused, who is this gui intended for and how does it help compared to programming in ANY scripting language?
It's intended for our people in the implementation department, not the customer. They need to be able to map fields in our software to a field or fields in the HL7 message. However, it is often not a simple one-to-one relationship. Quite often we need to go through multiple conditionals, string operations, comparisons, etc. in order to determine how the data is mapped.

Again, currently we are using Visual Basic scripts to perform this logic. Easy. The company now wants to provide a GUI-based tool for our people to do this sort of work. Not easy. At least, not easy in the respect that they want this GUI tool to be "nearly" as flexible as what they now do in VB.

I don't know what they have against using some sort of other scripting language that's framework-agnostic. It feels like they do not like the idea of our "grunt" employees having to write code.
 

Noodleface

A Mod Real Quick
38,245
15,030
QA at EMC had a nice scripted test suite that worked well and they made them switch to the GUI system. It was the worst.

Also they only added a bunch of features after people requested them, so you had to update it like everytime you loaded it.
 

ShakyJake

<Donor>
7,885
19,828
Also they only added a bunch of features after people requested them, so you had to update it like everytime you loaded it.
That's my fear is that we'll constantly have to update the tool to accommodate some special condition at site X. One thing I learned is that we have no spine. Management consistently folds to a client's demands.
 

Deathwing

<Bronze Donator>
16,719
7,734
The pessimist in me sounds like this priming the implementation work to be shipped off to India. I worked at Allscripts a while back and they were big on offshoring whatever they could.
 

ShakyJake

<Donor>
7,885
19,828
I worked at Allscripts a while back and they were big on offshoring whatever they could.
Hey, I worked with an Allscripts analyst once. If remember correctly, they did pretty much the same type of work as we. Do you know what they use/used for mapping HL7 data?
 

Deathwing

<Bronze Donator>
16,719
7,734
This was a while back, but they used GE's ConnectR for that. It was kinda shitty, and I think they were losing their license shortly after I left, so no idea what they use now.
 

Khane

Got something right about marriage
20,314
13,961
It's intended for our people in the implementation department, not the customer. They need to be able to map fields in our software to a field or fields in the HL7 message. However, it is often not a simple one-to-one relationship. Quite often we need to go through multiple conditionals, string operations, comparisons, etc. in order to determine how the data is mapped.

Again, currently we are using Visual Basic scripts to perform this logic. Easy. The company now wants to provide a GUI-based tool for our people to do this sort of work. Not easy. At least, not easy in the respect that they want this GUI tool to be "nearly" as flexible as what they now do in VB.

I don't know what they have against using some sort of other scripting language that's framework-agnostic. It feels like they do not like the idea of our "grunt" employees having to write code.
This is not going to work. It never does. I work in the healthcare industry in Middleware and my job is to do what this "software" is supposed to so that the business teams don't have to. Giving non-technical people "easy to use technical tools" never, ever works. Especially not with something as convoluted as HL7. I'm assuming they want this because of how HL7 v2 works. It's a guideline more than a spec and every hospital, doctor's office, etc that sends HL7 messages puts different information in different segments and sub sections. So they want an "easy" tool to map it to the correct field in your internal system. It ain't gonna work man. It just ain't gonna work.

The software I work with (Microsoft BizTalk) has probably the best gui based mapping tool around and HL7 v2 still gives me nightmares.

Tell your company to forget trying to build a gui based tool unless they build it around FHIR. So tell them to wait 3 years until that shit is normative. It will make everyone's lives so much easier.
 

ShakyJake

<Donor>
7,885
19,828
This is not going to work. It never does. I work in the healthcare industry in Middleware and my job is to do what this "software" is supposed to so that the business teams don't have to. Giving non-technical people "easy to use technical tools" never, ever works.
Yeah, you're preaching to the choir, brother. Problem is, I'm the only dev on the team that has actually worked with this stuff. The others are clueless and are just designing based on the requirements given by the even more clueless product owners.

FHIR is very interesting. I hadn't heard of that until you mentioned it. That makes a case to wait since we will conceivably have to do this all over again in a few years.
 

Khane

Got something right about marriage
20,314
13,961
Well you could theoretically build it out now and use it as your internal interface and just use this amazing mapping gui (heh) to map it to v2 or v3 for outgoing and incoming from external trading partners. But like I said it isn't normative yet, so the spec could (and will) change at any time. Best thing about it though is it is no longer a guideline. You don't follow the rules of the spec you aren't compliant and if you aren't compliant you can't trade FHIR data. It's all part of the meaningless (err, meaningful) use initiative.
 

Noodleface

A Mod Real Quick
38,245
15,030
These people here man. All these experimental requirements, requirements that are up in the air, no real priority on the tasks, asking me to add stuff that has no right being in the code. I am losing my mind, slowly.
 

Lendarios

Trump's Staff
<Gold Donor>
19,360
-17,424
Regarding the client side UI framework, sadly it is where the technology is going. Go back on this thread exactly 7 months and you will see the rant and issues I had with a coworker set on using angular plus sql for the application. Now six months removed from it, here is my hopefully unbiased opinion. .net Mvc rocks, however it lacks a lot of the wow factor that angular and other client side libraries have. We did some very nice things client side for example building a sql query tool that the user moves boxes around instead of writing sql. We allow the user to move boxes and modify the Dom by dragging, these things are hard to do on regular .net, but they are a breeze to do in angular.

Now is it the future? Not version 1, is just too ducking complicated to understand. Let's see if version 2 of angular is more developer friendly.
 

Khane

Got something right about marriage
20,314
13,961
These people here man. All these experimental requirements, requirements that are up in the air, no real priority on the tasks, asking me to add stuff that has no right being in the code. I am losing my mind, slowly.
That's every company I've ever worked for. The business people tend to think software is magic and anything is both possible, and simple.
 

Noodleface

A Mod Real Quick
38,245
15,030
Well it's like "why doesn't the bios automatically update this hardwares firmware?" uhhh.. Why do you want bios upgrading shit, there's an EFI shell utility that will do it and also it slows boot time not to mention all the hang scenarios. That's just one instance.
 

ShakyJake

<Donor>
7,885
19,828
So, after some thinking, I'm going to propose we construct our own scripting language. It sounds like a daunting task, but quite honestly the language does not have to be that complicated. All the guys do, typically, are check for values in some HL7 field or fields, then assign a string value or do some kind string manipulation (concat, substring, whatever).

Instead of having to build this incredibly complicated GUI with drop-downs and shit, we can simply have one UI control: a textbox. One of the problems with the current Visual Basic implementation is that they have this huge monolithic script that performs assignments to all the mapped fields. My idea is to break it out so that each mappable field has it's own mini-script that works against the HL7 message. I think this will be far more manageable. Additionally, the language isn't platform specific so it can be easily ported to some future framework.

Also, I found a great book on compilers and interpreters:Writing Compilers and Interpreters: A Software Engineering Approach.

It actually includes a full Pascal interpreter/compiler written in Java. I'm thinking/hoping it will pretty effortless to convert this to .NET and change the language to something dumb.

Way to spend my Christmas break....
 

Noodleface

A Mod Real Quick
38,245
15,030
Anyone got tips on staying focused at work? At Emc it was easier, I was the lead on the firmware for one of our server designs as well as some other tasks and meetings. Felt pretty important. Here I'm just starting out. When I hit the build button and it takes 20 minutes I find it easy to load up reddit or rerolled.

I tried a chrome extension before that would lock me out, but found myself disabling it.

Is it normal to build then browse the web?
 

Vinen

God is dead
2,789
495
Anyone got tips on staying focused at work? At Emc it was easier, I was the lead on the firmware for one of our server designs as well as some other tasks and meetings. Felt pretty important. Here I'm just starting out. When I hit the build button and it takes 20 minutes I find it easy to load up reddit or rerolled.

I tried a chrome extension before that would lock me out, but found myself disabling it.

Is it normal to build then browse the web?
Adderall. You are next to MIT... this shouldn't be hard.
 

Tuco

I got Tuco'd!
<Gold Donor>
46,831
78,477
So, after some thinking, I'm going to propose we construct our own scripting language. It sounds like a daunting task, but quite honestly the language does not have to be that complicated. All the guys do, typically, are check for values in some HL7 field or fields, then assign a string value or do some kind string manipulation (concat, substring, whatever).

Instead of having to build this incredibly complicated GUI with drop-downs and shit, we can simply have one UI control: a textbox. One of the problems with the current Visual Basic implementation is that they have this huge monolithic script that performs assignments to all the mapped fields. My idea is to break it out so that each mappable field has it's own mini-script that works against the HL7 message. I think this will be far more manageable. Additionally, the language isn't platform specific so it can be easily ported to some future framework.

Also, I found a great book on compilers and interpreters:Writing Compilers and Interpreters: A Software Engineering Approach.

It actually includes a full Pascal interpreter/compiler written in Java. I'm thinking/hoping it will pretty effortless to convert this to .NET and change the language to something dumb.

Way to spend my Christmas break....
Don't do it!

We automated a thing earlier this year by creating a javascript API that would support very basic routines. It was pretty successful. I'd recommend using an existing scripting language and not try making your own.

Making your own will add a lot of development cost, will be buggier in weird, annoying ways and will be much harder to extend later.
 

ShakyJake

<Donor>
7,885
19,828
Don't do it!

We automated a thing earlier this year by creating a javascript API that would support very basic routines. It was pretty successful. I'd recommend using an existing scripting language and not try making your own.

Making your own will add a lot of development cost, will be buggier in weird, annoying ways and will be much harder to extend later.
I totally agree that making our own isn't a great idea. But I can hear the bitching and moaning right now if I suggest Javascript, Python, or anything else that doesn't originate from our loins. A few months ago we wanted to implement a more thorough logging system (just for diagnostics) in our application. Instead of writing our own I suggested Log4net (.NET port of the popular Apache Log4J framework). They recoiled in horror at the mere thought of that.

So, I'm working through this book on compilers and interpreters anyway for my own edification. It's actually pretty interesting.
 

Tuco

I got Tuco'd!
<Gold Donor>
46,831
78,477
I did a thorough analysis of all the C++ logging libraries a few years ago and found our own, somewhat basic, system was superior for our needs. There's so much variety to what you can do with logging that other people's libraries will have cruft you don't want. But rolling your own logging framework should not be a justification to roll your own language. It's madness!!!