It may be useful to have a newbie library/toolkit "howto" somewhere on one of the wiki's or documentation sites.
I'm learned M off of two books (which aren't VistA specific) and just a lot of pouring over VistA. Having this information to fill up my "bag of tricks" would be useful on the M side. But my argument is for non-David like developers. Take my co-worker Bob (not someone's real name) who's done VB6, Java, and .NET for pretty much the last 8+ years. He'd want to use, probably, .NET to build a user interface for generating bulk user registrations for testing the HL7 outgoing ADT stream. To him (and honestly me), if I could write a few SQL strings to create new visits with random patients - that would be cool and easy. If he had to learn M - well, we'll look and see what other EMR we have installed (and we do use other EMRs for generating those HL7 feeds to test with). That's the trick. Take someone whose comfortable writing C apps, hand them C# in .NET and they don't feel too bad. Hand them PHP and they won't be as effective. Hand someone used to doing TSQL (which is a real large % of all data stores) and give them FM/M, they'll just not be as productive. It's not just syntax but understanding the underlying data structure differences. If the SQL engine in Cache is smart enough to handle both, then I'd say that's a very good route to take. Thoughts? /David. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Woodhouse Sent: Wednesday, December 22, 2004 3:58 PM To: hardhats-members@lists.sourceforge.net Subject: RE: [Hardhats-members] modern day programming (was: Intersystems) In fact, VistA does supply some useful libraries, though I don't know of an MD5 implementation. Do an Integration Agreement inquiry on OpenForum and XLFDT will give you date handling functions, XGF will give you screen and terminal functions (very much like curses under UNIX, DILF includes various Fileman utilties, DID tools for DD access and more. --- David Sommers <[EMAIL PROTECTED]> wrote: > I'd honestly say that the approach to querying data out of M and > using > it with someone's "bag of tricks" is the #1 way to gain adoption. > > Taking a page out of Microsoft's hand book - if you can get > developers > to use your wares (regardless of whether it's the best available) - > you'll gain momentum. > > We have about 6 or so developers here and none of them (besides me) > can > use M, FM, or anything in VistA. Not saying they couldn't learn, but > these are developers doing Java and Oracle for 5+ years - it's easier > to > hand them a SQL statement and an IDE (.NET, VB6, C, InterDev, > Dreamweaver, etc) to code Web or thick apps (like CPRS). They can > apply > traditional OOP, libraries/frameworks, unit testing, etc. I don't > think > I can explain encapsulation, inheritance, unit testing, or libraries > easily ... (if you know what I mean). > > But that's different to everyone on this list. I'm sure Jim and Greg > have routines for hashing strings, one-way encryption, easy file > system > access, etc. I don't know these and instead use .NET for its > framework > to provide these. > > So for instance, if you want to hash the string plaintext into MD5: > > HashAlgorithm cs = CryptoConfig.CreateFromName("MD5"); > byte[] cb = cs.ComputeHash(ASCIIEncoding.ASCII.GetBytes(plainText)); > > Want that in Base64? > > string s64 = Convert.ToBase64String(cb); > > I have similar functions for VB6 but I had to write the libraries > that > make it work. So it really is your "skillset" and your "bag of > tricks" > but the more flexible you are to allow external tools to work, the > more > likely a system will be adopted. > > Then there are web services... but that's another thread... :) > > /David. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Greg > Woodhouse > Sent: Wednesday, December 22, 2004 12:52 PM > To: hardhats-members@lists.sourceforge.net > Subject: Re: [Hardhats-members] modern day programming (was: > Intersystems) > > I'm sure that's a big part of it. Though every product out there > seems > to have its own flavor of SQL, using a relational database does offer > a > common model, and I suppose knowledge of MySQL (say), is more > "transferable" to Oracle than it is to Fileman -- though, in fact, I > think Fileman is much more relational than people often realize. It > is > often argued that relational database technology has a stronger > theoretical background than Fileman, but I'm not impressed by this > argument. I may be true that relational technology is an improvement > over network and hierarchical databases here, but that's not Fileman. > It is often argued that support for ad hoc queries is a significant > advantage of an RDBMS over Fileman, but consider what you can do with > "Search" option and relational navigation. I would also point out > that > indexes are very much a fact of life using relational products: if a > file design favors certain potential queries over others, so does > RDBMS > design. Perhaps the most cogent argument I've heard is that Fileman > is > built around pointers, which are not part of the relational model. > Maybe so, but one-to-one relationships are hardly unique to Fileman, > and foreign keys referencing candidate keys other than the primary > key > are the exception rather than the rule (and it is not clear to me > whether this is really even all that useful). Beyond that, even in an > RDBMS you will generally end up indexing fields you frequently use as > the basis of joins. The real difference here is that multiple-valued > pointers ultimately make use of a subfile, but that subfile is in an > optional one-to-one relationship with the referenced file, so you may > as well think of it as a nullable foreign key. When you get right > down > to it, even this seems to reduce to terminology (and a little > bookkeeping), after all. > > --- "Nancy E. Anthracite" <[EMAIL PROTECTED]> wrote: > > > Correct me if I am wrong, but isn't the reason for so much interest > > in SQL > > that so many people in the work force are trained to make queries > > using SQL? > > Isn't the issue writing an interface that allows SQL queries of a > > Mumps > > database. Isn't that what that company in Massachusetts > > ( http://mde.srs-inc.com/aboutmde.html) and Cache does that people > > want? > > > > > ===== > A practical man is a man who practices the errors of his forefathers. > --Benjamin Disraeli > ==== > Greg Woodhouse > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > ===== A practical man is a man who practices the errors of his forefathers. --Benjamin Disraeli ==== Greg Woodhouse [EMAIL PROTECTED] [EMAIL PROTECTED] ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
