orting

> node is different, in that bizarre though js may be, if you have to use it in the browser, there is a kind of logic to using it on the server as well.

I don thinkt that makes any sense. Should we also use js to implement the OS for the server? If js is good for server-side use it, if not use something else.

My main issues with php is that I dont trust the language and standard libraries to behave as I expect. There are simply to many strange type conversions, silent errors and strange behaviour going on.

Dont worry, you dont actually feel it when you hit 30. But I get the feeling you are talking about.

I started programming relatively late, mid-twenties, and started as a CS student when I was 28. For the first two years I had this idea that I had to be faster and better than the younger students, to have a chance. But the world doesnt work that way. What matters is to try and figure out what you actually want to do, and then spend the time it takes to do it.

If an expert system prescribed you extra strength Tylenol would you feel better? I think you are taking a too simplistic view of diagnosis and put to much faith in AI. I have also noticed Watsons good results, but I do not trust them yet, there is a lack of evidence supporting the claim that Watson can make 90% correct diagnosis.

Medical imaging is a big part of diagnosis, especially in many cancer patients. There is a huge effort to automate the segmentation of tumors, and even though algorithms often have higher inter- and intra-observability agreement than radiologists, they often fail miserably for "non-standard" tumors. A fully automated system that scans the patient, make the diagnosis and treatment plans and provides treatment is very far future.

A completely different issue is that the specific combination of a highly developed brain and opposable thumbs are sometimes necessary. Consider cardiac response teams in hospitals, but also general patient care where the ability to fluff a pillow can be just as important as placing a quick IV drop.

I think you need to view whatever process generated the answers as part of your model. In some cases, and in all textbook examples, we have a ground truth that is correct. But in real-world applications, such as segmentation problem in medial imaging, we have a gold standard which represents our best estimate, but is not necessarily correct.

Validation is not a magic bullet, we need to be critical of any part of the model that is given as truth, otherwise we might end up fitting a solution to the wrong problem.

More generally I think that textbooks should emphasize the need for the scientific method and stress that any model (or theory) is only as good as its ability to explain the entire problem domain.

pydicom is nice but it lacks network functionality: find, send, store and so on. And it cannot decompress jpegs. Two large open source toolkits are dcmtk[1] and gdcm[2]. Both comes with commandline applications for viewing dicom files and querying pacs servers. gdcm is bundled with itk[3].

[1] http://dicom.offis.de/dcmtk.php.en

[2] http://sourceforge.net/projects/gdcm/

[3] http://www.itk.org/

It is a beautiful little machine, looking forward to seeing it in action.

A simpler approach to get a small CT scanner is to use a stationary source and detector. This requires a cone-beam source, which might cost a lot more, but it makes it a lot easier to experiment with phase-contrast and darkfield imaging, which can improve soft-tissue contrast.

For reconstruction from the projections the Cph CT Toolbox https://code.google.com/p/cphcttoolbox/ contains open source implementations of several reconstruction algorithms. It is written in python.

From my viewpoint, CS student focusing on medical imaging, no single imaging modality will rule them all. It is much more interesting to look at the combinations like PET/CT and PET/MR that gives us complimentary information.

It seems to me that Libreoffice is geeting a lot of traction. From an anecdotal viewpoint alot more people are familiar with Libreoffice/Openoffice today than a couple of years ago.

Development of Libreoffice after the fork looks healthy, with a big focus on refactoring and consolidating the codebase in C++.

Because of the many language bindings to UNO, developing applications in Libreoffice is easier and a lot more interesting than developing for MS Office. I have only worked with Calc/Excel but Basic is a piece of crap language in both cases, and writing in Python is a big win. It also makes it easier to use version control and external editors.

Combine that with no license and support for the valencian language, then its the right thing to do.

The upside to writing software for healthcare is that your code might help people recover faster or in some cases survive where they otherwise wouldnt.

But it can be stressful to write software that has a very direct impact on peoples lifes. While I was rolling out an updated version of an inhouse application a serious bug was discovered. The application was used as part of chemotherapy follow-up/planning and on some occasions it gave the wrong answer for a test. I discovered that the bug was old and that wrong answers had been given for a long period. Personally I was relieved that I had not caused the bug, but from a medical perspective it would have been better if the bug was new and had only affected very few patients.

My takeaway from that experience is that care should be taken when writing critical software, but also that we will make mistakes and it is very important to always focus on how we can make fewer mistakes instead of pointing fingers.