mcmancini

For US market, a scale is a Class 1 medical device.

Probably not sufficient. The patient is still using it to guide medical decisions.

It would be worthwhile to speak to someone familiar with Canadian medical regulations.

IIRC, Canada largely follows CE. One other problem might be that you're using the Pebble sensors, and so that could fall under regulatory purview too.

But from the landing page:

An individual's data can help adjust their medications, change eating patterns and maximize sleep schedules.

That sounds like it's being used to guide treatment.

This is a great idea (and name!), but does this fall under FDA regulation? I haven't kept up with the FDA's current policy on medical apps.

Exciting work. CL on the LLVM has been needed.

Is this project something that you're doing to support your own research goals in computational chemistry? If so, can you share how this project fits into the bigger picture?

I guess I'm having trouble figuring out where the numbers are coming from.

I'm seeing that the FDA recommended maximum dose for aspartame is 50mg/kg/day. Assuming a 70kg Standard Man, that's 3.5g/day of aspartame. Diet Coke has 125mg per 12oz. can, so that would be 28 cans/day. Each packet should be around 35mg aspartame, so 100 packets/day (the amount of aspartame per packet was hard to find, and the approx. was from an American Cancer Society article).

Agreed that 9–12 packets doesn't sound like much, but I think we're talking way more than that.

Overall, this was a nicely done study. The microbiome is fascinating and an exciting area of research.

One criticism however would be that the dose of artificial sweetener tested was atypically high.

It'll be neat to see further research into the cause of variable responses of the subjects to the artificial sweeteners.

I maintain that the sapphire screen rumors were patently ridiculous to anyone with a basic understanding of materials science.

The only people who took these rumors seriously were pundits who started and then perpetuated (and now, continue to discuss) the idea.

Business management & administration

Nice catch. Someone in the comments section pointed out that the WaPo actually listed MIS as one of their "most unemployable majors." (Is that irony on some level?)

http://www.washingtonpost.com/blogs/wonkblog/wp/2014/08/26/t...

Thinking of it from the point of view of an academic, one generally credits the first to discover/build/describe/do something. It's part of placing things into context, which is an important element of academic discourse.

Wearing the academic hat, when I read something that fails to credit The First and instead credits someone else I think to myself, "this person is uninformed and doesn't really understand X..."

In this context, PE is the professional engineering exam. You take it in a specialty area, and software engineering was added last year. It's one of the last steps for licensure as a professional engineer.

Some states, like Texas, are extremely picky about who calls themselves an engineer, irrespective of industrial exemption (which the vast majority of people fall under). PE licensure in other engineering areas (like civil engineering) is required to offer services to the public, helps when offering expert testimony, and can be required for principals at consulting firms. The software engineering PE is an extension of IEEE's efforts in software engineering, and is probably a good thing for safety-critical industries.

Since passing the fundamentals of engineering (FE) exam is (usually) a prerequisite, someone who has a PE in software engineering probably knows their way around a free body diagram or Laplace transforms or MSD systems, i.e., stuff the other engineering fields do.

If we're talking about someone that passed the software engineering PE, then yes, I think they get plenty of (well-deserved) respect. I'm guessing that's not whom the article is referring to however...

I met a lot of "software engineers" that think their mad coding skills are singularly notable or worthy of respect in business. They're wrong. Technical ability is but one aspect of business. The developers who get that, who have other business skills and/or are willing to learn other business skills I greatly respect and value. A developer who is competent at coding and has one of good communication skills, project management skills, interpersonal and conflict resolution skills, is of much greater value to me than a developer who is excellent at coding and mediocre elsewhere.

For in vivo studies, and even possible human studies, have you given any thought for how you will do PK/BD on these? I'm having trouble imagining how you'll be able to detect these non-optically, unless you had some made of heavy isotopes for ICP/MS.

Continuing with the human studies thought, are these particles seeing RES uptake? I assume, based on the high QY, that these the emission centers for these particles are protected by a thick shell and/or corona. General handwaving from the FDA was that they were as concerned with particles persisting as with elemental toxicity. Is there a predicted degradation pathway for these particles?

Can these particles be made with a hydrodynamic radius, including corona, <8nm? Is it possible to dope them to get better NIR emission?

Unrelated to technical stuff: I thought that a YC thing was that you had to move to San Diego for a few months. That doesn't seem all that conducive to wet lab work, in fact, it seems like a non-starter. Is that still a requirement for the bio-related startups? If so, how how disruptive is it?

Thanks for the answers!

What's the fluorescence emission mechanism, defect sites in the crystal lattice? What's the QY? What's the absorption spectrum look like, especially in the NIR range? If we were exciting these particles at 785nm, what would the emission spectrum look like (peak and FWHM)? Is the YC startup focused on the nanocrystals themselves, or on imaging agents including a targeting ligand?

Sorry for the basic questions, I no longer have journal access :( and this sounds neat :)

P.S., oh, and do they blink?

But that doesn't work on an e-ink reader.

In addition to the other replies, Haskell lacks a proper ISO or ANSI standard.

I think that current safety-critical best practices (what real software engineers actually do) do a good job at correcting the warts inherent to the C family while respecting the need for real-time execution. Not clear what Haskell brings to the table here (or on other embedded systems in general).