When I find myself doing the same kinds of things over and over again in M, I often try to re-cast the code as a reusable tool. One thing I've found, though, is that it is difficult to sell the idea of using tools like this to developers that are used to the "just do it in M" approach. I can sympathize, too, because I find it a very comfortable language to work in, and it's easy to just sit down and start writing code. But there is a downside: reading through VistA code, I see people doing the same sort of thing over and over again, and enhancing or modifying code often turns into a kind of hunting expedition (where was this data structure touched? how and why?) I have also developed HL7 interdaces using the tool based approach, and it has really paid off in terms of reliability. It's nice when you only need to code something once and then can rely on it to work correctly.
--- David Sommers <[EMAIL PROTECTED]> wrote: > 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 > ===== 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
