|
vs wont compile typescript without node installed.
|
#
¿
Jun 28, 2018 22:06
|
|
|
|
| # ¿ May 14, 2024 16:26 |
|
|
jit bull transpile posted:That is absolutely not true. I did not have node on my work machine and I compiled typescript all day. Did this change in a recent version of vs or something? idk if its changed but new asp.net core apps require node.js be installed outside of VS to compile TS and for other functions
|
|
#
¿
Jun 28, 2018 22:25
|
|
|
Finster Dexter posted:Uninstall and reinstall nodejs? that may be what has changed because I don't have node installed and a brand new project fails to build with a "go install node" error.
|
|
#
¿
Jun 28, 2018 22:26
|
|
|
as of now I don't want to use typescript enough to install node.
|
|
#
¿
Jun 28, 2018 22:32
|
|
|
it should be written in c# or c++ and be integrated into msbuild
|
|
#
¿
Jun 28, 2018 23:15
|
|
|
gonadic io posted:hey shaggar i found it: your worst nightmare https://itnext.io/functional-devops-with-scala-a-kubernetes-3d7c91bca72f I guess its better than using ruby or something
|
|
#
¿
Jun 29, 2018 14:47
|
|
|
javascript was such a huge mistake
|
|
#
¿
Jul 2, 2018 15:42
|
|
|
jquery is better than just plain javascript. its not good, but javascript is just that bad.
|
|
#
¿
Jul 2, 2018 21:01
|
|
|
its not the current fad so its bad.
|
|
#
¿
Jul 2, 2018 21:04
|
|
|
DynamicParameters
|
|
#
¿
Jul 2, 2018 21:21
|
|
|
the language itself is garbage and the terrible ecosystem on top if it is a direct result
|
|
#
¿
Jul 2, 2018 22:46
|
|
|
Blinkz0rz posted:what's so bad about javascript shaggar by far its totally hosed type system is the worst part and prevents it from ever being fixable. the way it interacts with the dom is also dumb as hell.
|
|
#
¿
Jul 3, 2018 01:04
|
|
|
yes its part of the hosed up type system for sure.
|
|
#
¿
Jul 3, 2018 01:23
|
|
|
If this is something that is done realtime within the application then a web api on top of the db that the application uses is probably appropriate. if its a periodic load type thing then just use SSIS.
|
|
#
¿
Jul 9, 2018 16:40
|
|
|
Peeny Cheez posted:Fake your death and move to Belize.
|
|
#
¿
Jul 9, 2018 19:02
|
|
|
our health information vendor has an API that lets us send a list of topic ids and a coversheet (in html) and sends us back a PDF with the coversheet and all the health information topics specified by the IDs. we then email or mail this to a patient. Turns out they check for script tags in the html which is good, but they do it wrong. How did I find this out? We had a failing health info print request that was getting rejected because it contained a script tag. We don't send script tags so I start troubleshooting. The coversheet contains a list of topic names so the patient has a summary of what health info is on the document we send them. It seems that if I remove the topic list, it works fine. So I look at the topic list and look to see which of them might be causing the error. Of course it was "Prescription Medication". Their anti-script code just looks for "script" and that's it. so I just added a replace on the topic list to replace script with s<span></span>cript and now it works. great. I love 2 program
|
|
#
¿
Jul 11, 2018 19:15
|
|
|
yeah its dumb. I sent them a bug report but idk if they care. it would be pretty trivial to do it right w/ html agility pack or something.
|
|
#
¿
Jul 11, 2018 19:25
|
|
|
anthonypants posted:could you export to ods, or to xml and generate the xlsx container yourself its the xml that's the issue. using the openxml sdk is the best way to generate openxml docs/spreadsheets but you still have to deal with problems related to the specification itself. most of them have to do with display issues caused by wonkiness in old versions that has become expected behavior by users. also you can set formatting in the document itself or in a stylesheet so what goes where can be a headache.
|
|
#
¿
Jul 12, 2018 23:07
|
|
|
JawnV6 posted:hey eschaton because make files and xcode are bad
|
|
#
¿
Jul 13, 2018 02:03
|
|
|
floatman posted:"Hey guys let's only send diffs fron our dynamic forms to save space in message transmission!" software engineering
|
|
#
¿
Jul 13, 2018 04:15
|
|
|
if you're talking about posts then sure but if you're talking about stuff that matters consistency is critical.
|
|
#
¿
Jul 13, 2018 16:55
|
|
|
how would they access stuff in NoSQL if the NoSQL isn't available because their network is down. or are you suggesting everyones medical records are stored at every provider location
|
|
#
¿
Jul 14, 2018 13:25
|
|
|
MononcQc posted:Yes, it's a thing called data replication. People can work with local redundant copies, which get synced, repaired, and updated across regions once the network heals. they absolutely do not have everyones records and in fact that would be a hipaa violation. The only way CVS would have your records is if they've been authorized to look at them and then that would require an active internet connection. In your scenario where you've taken out the internet for the provider, be it hospital, pharmacy, or whatever, unless you have previously interacted with them they are not going to have access to your records if their access to the HIE over the internet is down. Even if they have previously interacted with you theres no guarantee they will have up to date records. If the us were a tiny monoculture then maybe pushing records to everyone provider everywhere might be viable but in the US its absolutely not nor would I want it to be. Its a massive security risk.
|
|
#
¿
Jul 14, 2018 22:53
|
|
|
In modern healthcare the way it works with HIEs is your PCP has pretty much everything going on with you and then if you visit elsewhere the new provider can pull the consistent records for you from the HIE and then push their results back to anyone interested in your data (your pcp). This results in accurate and up to date information. Everything is basically immediately consistent or not used. The whole reason you're calling the pharmacist to confirm an order is because you need immediate consistency in the view of the patient's history. if you're stuck waiting for eventual consistency you'll be too late to help the patient. Theres also no real way to say that in the event of a network issue some data is more important than other data so you should sync the important data first. Its a clinical decision the computer cant make. Once the data is consistent then the computer can help and can do things like point out medication errors. That is, if the humans using the system don't ignore it And when you're talking about the data within the local emr, consistency is always more important than performance and if performance is a problem in your local instance it means you've hosed something up. like maybe you used a javascript based back end. Even in the overall HIE performance shouldn't really be an issue since there really isn't much going on in there. Certainly not like what youd see in a financial or social network. Your alarm scenario is totally different. If dropping alarms is ok then you never needed a consistent view to begin. Theres no such thing as data you can drop for later in healthcare.
|
|
#
¿
Jul 15, 2018 03:32
|
|
|
MononcQc posted:They do. But the idea that "lol nosql you can't have inconsistencies" I think is reductive. Git allows you to throw away consistency so its a bad example, but you could definitely implement something like svn in sql. The server is always consistent and the clients are either up to date or out of sync. Theres no situation where a client is ever consistent and the server is not.
|
|
#
¿
Jul 15, 2018 03:37
|
|
|
code that is uncommitted is effectively non-existent and should be treated as such. If you treat your uncommitted code as a valid state you start running into problems caused by people getting way out of sync without realizing it.
|
|
#
¿
Jul 15, 2018 03:46
|
|
|
MononcQc posted:if you don’t consider clients part of the distributed system, you have an incomplete view of your distributed system, and end up pushing that complexity back onto the users. source control is not a distributed system
|
|
#
¿
Jul 15, 2018 04:39
|
|
|
Progressive JPEG posted:eh that stuff is v complicated so i think the length is warranted, and its good material despite the condescending start uncommitted code is not valid code. git adds a bunch of uncertain state by giving you no authoritative repo so everyone's repos are both correct and wrong at all times. with subversion there is one authoritative repo and everyone else is wrong. You can make changes to the authoritative repo to change its state, but whatever its state is is always correct. branching is included in the state of the repo.
|
|
#
¿
Jul 15, 2018 19:25
|
|
|
eventual consistency is fine for a lot of stuff as long as the delay is acceptable for the use case. ex: atm withdrawls (or card payments in general) can be eventually consistant because the money going in and out isn't critical and/or the consumer has been informed of the delay. eventual consistency doesn't work at all for something like an inventory system where the delay can and will result in overutilization of inventory during peak usage. At that point delaying the user's ability to access the inventory through apparent application slowness is more acceptable than promising the user an item you don't actually have in inventory.
|
|
#
¿
Jul 15, 2018 19:36
|
|
|
|
| # ¿ May 14, 2024 16:26 |
|
|
nah MySQL can be used successfully for basic stuff even if there are better options.
|
|
#
¿
Jul 16, 2018 16:02
|
|