HL7v2 is just the schema - the mechanism for sending these messages is normally something called MLLP which is just a simple framing protocol and has no built in security. It is possible to send/receive HL7v2 over other protocols, MLLP is the most common.
Its normal to secure the endpoints via network level security - ipsec etc. HL7v3 transformed into FHIR which is done over HTTPS instead.
This is because RoR projects do not do unit testing, they do integration testing with a real DB.
This approach is terrible and causes the poor performance.
There are whole sets of testing "tools" for RoR projects that promote this mechanism of testing - if you're testing an API you need to use an external tool to properly hit that API.
If you're writing unit tests, write unit tests with mocked dependencies.
> This is because RoR projects do not do unit testing, they do integration testing with a real DB.
Lots of RoR projects do unit testing without the DB involved, I did it for ~10years and you can write small unit tests until your eyes bleed, but eventually you'll want to test the controllers.
> There are whole sets of testing "tools" for RoR projects that promote this mechanism of testing - if you're testing an API you need to use an external tool to properly hit that API.
You can just use the built in minitest tools and some fixtures to hit the API, and even back it with sqlite so it's fast and light. Most people don't because thing like Rspec, FaktoryBot, and Cuprite are convenient and nice to work with if a bit slow.
>If you're writing unit tests, write unit tests with mocked dependencies.
There were like 3 talks at Rails Conf about this, people do it all the time in Rails land.
It's hard to really test business logic without hitting the database or other components, no matter the language and the framework. You really have to trust your mocks and sometimes you discover only in production that one of them didn't do what it should do. It happened to me.
The teams I work with tend to write unit tests to demonstrate that a class or module or whatever work, then integration tests to demonstrate that that part of the application works from the frontend code down to the database.
Disasters like powershell returning a 0 exit code even if there is an error? Its a pile of trash that doesn't add anything new other than a big shiny MS logo.
I don't have a problem - I don't use bash unless its few lines or absolute must.
Its disaster because launching process to achieve simple math expression is just ridiculous, besides being slow and besides having to terminate it with ;. Its wrong on so many levels I don't even know where to start, they must have been smoking some nasty things back in time.
Neither [ nor $(()) start subshells/subprocesses. [ is built-in in pretty much every shell, and there's absolutely no reason for any shell to make a subshell/subprocess for $(()). You might be confusing it with $().
In any case, worrying about subprocesses and their slowness in a shell is completely moot. Shells aren't built to run fast, and are rather built to work with executables conveniently.
> besides having to terminate it with ;
Is that really a complaint? Does that bother you a lot? This seems so petty, I'm a bit lost for words.
[ is a regular command because the control structures of the shell are flexible enough to support any command for their conditions.
I don't know if you're asking for the shell to make a super-special exception in its syntax for that particular command just so that people won't have to type ; under certain circumstances, or if you're asking for control structures to be more restricted and allow only [ instead of any command for their conditions.
> they must have been smoking some nasty things back in time.
So far, you've given the impression of someone complaining that screwdrivers really suck for inserting nails. I wonder if the issue is that you've never seen hammers before or if you've never seen screws before. Or maybe the issue is you believe each tool should be equally fit for everything?
