seanwoods

Not all geothermal systems are closed loop. I have an open-loop geothermal system at my house on Cape Cod, MA. It uses the same water pump I use for my domestic water, runs it through the heat pump, and discharges back to the aquifer via another well drilled exclusively for this purpose.

couple good ones:

https://www.youtube.com/watch?v=nZqq-zAkGy4

https://www.youtube.com/watch?v=8FeZe5P803c

Reminds me of:

http://backchannel.org/blog/friendfeed-schemaless-mysql

When I say "they" I don't mean the doctors, I mean the hospital administration. They operate on a different set of incentives and motivating factors. The doctors are usually not involved in the process in a very substantive way. It's this fundamental disconnect, which is so common in enterprise software, that's brought us to where we are today.

I know people on HN have fire in their breast to change the world but the rock is harder to move then many think. I tried to do it for almost 5 years and didn't get very far.

I am defining "unconventional" from the point of view of the physician...when compared with the common medications he/she prescribes. An outlier, in other words. Generally in a setting like the Emergency Department, which is where I developed products for 7 years, the docs only describe 20-30 meds 90% of the time. Other specialties, like pain medicine, are similar. For those we build a pre-selected set of favorite meds that they could just click.

The doc would say the pharmacist is not being restrictive enough because the doc has to wade through so many permutations of what is medically the same med, or has to sift through medication forms that he/she has no use for.

From the pharmacist's perspective I want a _complete_ database so I can record with very granular accuracy what the order was. Also, the pharmacy database has things like ingredients in it which it factors into allergy and interaction checking.

I agree with your other points, though. Free text entry is faster - especially if you have voice recognition.

The way to design med lookups, in my opinion, is to have a dropdown for the pharmaceutical substance the physician wants, then the dose, then an optional drop-down for the form (tab, injection, suppository, whatever).

A suitable medication form would need to be found between what's medically indicated, what the pharmacist is okay with, and what the hospital has in stock - ideally in a dispensing machine at the point of care.

One problem with most pharmacy dictionaries (e.g. First DataBank) is that it's optimized for pharmacists, not physicians. The docs want to say "give ${x} units of substance ${y}" but they can't do that because their lists are all in dosage forms. Something as simple as tylenol comes in a dizzying array of varieties and often those are presented directly to the user. You can mitigate this problem somewhat by building favorites but the minute the doc wants to order something unconventional they get sucked into the medication cattle shoot again.

The problem in healthcare is humans and organizations, not software. There is no will to conform to standards and foster interoperability.

You can rant about it all you want, but that's the reality. The status quo exists for a reason.

I just want to second this comment. Focus on solving problems no matter what the technology is. Also, HN talks a lot about web apps, as if they are the only apps out there. Don't get me wrong, I prefer writing software for the web, but there is a surprisingly high number of people who don't feel the same way and would rather use Excel or FileMaker or whatever to get the job done.

Bon chance!

I recently discovered Ugarit and although I haven't used it at all, it traces its lineage back to Venti (and also Git).

Not sure how mature it is, but might interest some:

https://www.kitten-technologies.co.uk/project/ugarit/doc/tru...

This article makes it much more complicated than it needs to be. It tries to be all things to all people. In practice you're going to have to sacrifice some functionality for the sake of usability and your own sanity.

When I add a CSV import feature to a project I'm working on, I tell people "this works with MS Excel flavor of CSV." This covers most, if not all, real world cases because in my world the people who want to import data are non-programmer types who all use Excel.

I'll often include the basic rules in the screen that accepts the import. If I ever had to accept data from something that was _not_ Excel I'd probably include a combo box on the web form that lets you pick the dialect. So far I haven't had to do that.

The only thing I might not be totally covering is how Excel handles newlines, but in practice I've never had to deal with that.

I actually think the OP's suggestion is the most elegant of everything I've seen here.

It's a matter of aesthetics.

The topic of CTEs was recently discussed (with much vigor) on the SQLite users mailing list:

https://www.mail-archive.com/sqlite-users@sqlite.org/msg8119...

I think this is exactly right. Often people rush to conclusions in favor of the new and shiny, but Python is a great language that works pretty darn well at the moment, even in v2.7, giving the community the freedom to fully vet their ideas and make a valuable product.

I remember reading commentary on HN when a new version of PuTTY was released, and there was general sentiment that PuTTY is - for all intents and purposes - a "finished" product in that it does what you need it to do.

https://news.ycombinator.com/item?id=2758696

Python v2.7 is similar in that it's a tool that does many amazing things and is very stable. Could it be improved? Sure! But for the most part it's a great piece of software.

The care and planning that went into creating the tool is also going into the upgrade process, and I think that's a good thing.

Reminds me of "the highest level feature of C"

http://prog21.dadgum.com/166.html

"The possibilities when compiling a switch are much more varied. It can result in a trivial series of if..else statements. It can result in a binary search. Or, if the values are consecutive, a jump table. Or for a complex sequence, some combination of these techniques. If each case simply assigns a different value to the same variable, then it can be implemented as a range check and array lookup. The overall sweep of the solutions, from hundreds of sequential, mispredicted comparisons to a single memory read, is substantial."

I agree. This is stupid and immature.

Appreciate the response. The problem is that the new process introduces another click where you have to select the document format. In iWork '09, you click the menu, then drag to word, then a menu opens. so 1-2 clicks vs. extra clicks and context shifts. It's a step backward.

I realize an update to Mavericks won't necessarily affect iWork, but I'm too attached to my current process to even risk it. It's an irrational behavior, I know. :-)

I'm disappointed not to see the "Share" menu make it into this list.

In iWork '09, there's a "Share" menu. It has a few different output formats (PDF, Word, etc). When you click an output format, it exports to an attachment and automatically opens Mail. This is so incredibly efficient and reduces so many clicks.

I use this feature at 5-10 times a day, at least, and it's the one feature that is preventing me from upgrading to Mavericks on my primary laptop.

I realize that when I install the new iWork, the old iWork will still be there, but it still feels risky.

Apple, if you're listening, please fix this.

I would love a combination Raspberry Pi/hard drive enclosure. This way you could tote the two around in one handy container. I'm thinking 3D printing companies could handle this "easily" -- at least for prototype??

I blame the companies providing these services more than the consumers who sign up for them.

At my company, we write new MUMPS code all the time. Some of this is sanely written ANSI standard MUMPS, some uses the Caché extensions.

There are techniques and strategies for containing legacy code which are pretty well known in the community. At minimum, this would involve wrapping it in a sane interface. You'd want to isolate global variable state too. Alternatively in Caché you can wrap it in classes (whose semantics are close to Java/.NET)

It's on our list to rewrite the legacy code "some day."

Came here to plug the GT.M version of MUMPS, which is really great. It uses the underlying UNIX system as much as possible (so, for example, your routines are not stored in the database!)

http://tinco.pair.com/bhaskar/gtm/doc/books/

It's easy to put a CGI interface on top of GT.M - performance is quite good.

http://71.174.62.16/demo/TestCGI.htm

Personally I am working on a utility that wraps GT.M in an "environment" similar to a Python virtualenv, but I'm not sure I'm ready to show my baby to the world yet...

You're referring to legacy MUMPS code. It's possible to write it more expressively (why do you think the examples on Wikipedia are like that?) People don't usually capture that nuance, sadly because many people don't care.

Yes, it's a bear to sift through poorly written MUMPS code. Yes, the language gives you more than enough rope to hang yourself. However, it's also possible to write code legibly and take advantage of abstractions that MUMPS provides (chiefly persistent arrays -- which are now ACID).

https://robtweed.wordpress.com/2013/05/24/making-mumps-accep...

I feel like this article could have been written with half as many words and 2/3 fewer lofty concepts.

I agree with most of this except the part about sessions. I'll assume OP does not want session ID/token garbage in the URI, to which I answer with a resounding "Amen!"

It's super annoying how a once-simple Blogger blog now takes at least 3-4 seconds to load some Ajax garbage which is not needed. At all. It's just engineers putting it in the because they can, and because they think its cool, but ultimately it detracts from the overall usability of the site.

+1 for Pick. I've met several people who were/are Pick devotees. Also heard stories about how Dick Pick was kind of crazy.

Agreed. It seems that the trajectory from 2.0 to 3.0 was much, much slower than the one from 3.0 to 4.0 (at least judging by data points so far).

Anyone know of any reason for this?

It's relatively straightforward to extract data from MUMPS. Epic (and many other vendors) just won't let you do it.

Also, it would be nice if people didn't always associate MUMPS with that Daily WTF post. How about linking to the Wikipedia page?

Can the readme file please include information about what this software does and what its goals are? I realize many in this community have probably been following the project, and I vaguely recall seeing it here before, but with all the projects that appear on this web site it's really hard to remember what each one does.

I appreciate your efforts, but this response doesn't really answer my question. It's too granular (and a bit biased). When I go to your web site, I need some context. I need business problems that this software solves. Based on the name I would say it's Medicare/insurance eligibility checking, but the web site should guide me through what needs the product addresses and why it's better than the alternatives.

Also, I'd advise you not to jump straight to messages about "non-technical bureaucracies." It's certainly true in some cases, but it sounds derogatory. Better to address the objectives these people are trying to meet.