manchego

My partner is doing a distance learning bachelors from the Open University in the UK. They have both part time and full time tracks. The part time takes 6 years to complete. It's interesting too because the university has been doing distance learning for a long time, so it's not a standard online class. I believe the cost for the whole degree is around 32k USD.

Also, I suspect that if you plan to continue working in software, since you have experience, you maybe shouldn't worry too much about a degree from outside the US. I bet many recruiters just view a degree as a checkmark and are more interested in your work experience.

Yeah, I guess then you don't need a screen for display. And to be honest the proximity sensor may have had the greater effect in the situation I referenced. I could hear it beeping from where I was about 30 feet from the car.

I agree that buyers should have the option to purchase simpler cars. But I think backup cameras are too valuable of a safety improvement to leave out. About a year ago I saw a toddler very likely saved by the backup camera and proximity sensor. This is of course just anecdotal, but it sold me.

My reading of the comment was that the German language is used enough that it would make sense to invest the time to learn. But that languages from smaller countries are less relevant outside of the given county.

Ah yeah, I can see that would be a problem. The part I dislike is trying tell which side is correct and frequently getting it wrong. Which I can see would happen with a king bed. When you get to the second corner you have to discern whether the side between the corners is too tight or just right.

My method for applying fitted sheets is to put the first corner of the sheet that I find onto any corner of the bed. Then try to add one of the adjacent corners to the bed. If I picked wrong, put the adjacent corner on the starting bed corner. I get it wrong half of the time, but I still think it's faster than spending time trying to determine which is the long side of the sheet (and often getting that wrong). In any case, the labels mentioned in the article would probably be better.

I should have said zenith, not poles. The issues occur when the device is pointed up at the sky or down at the ground. Edit: Though I would imagine it won't work too well at the poles either!

Agreed, the deviceorientation does work fine for relative orientation. I've been able to hack it for absolute orientation. What I am doing is: 1) taking the relative orientation euler angles from the event and converting them to a quaternion for easier manipulation. 2) taking the webkitCompassHeading from same deviceorientation event. 3) Calculating the "relative heading", eg how far the relative orientation is from its fake north. 4) calculating the difference between the relative and actual heading. 5) building a quaternion to describe the bearing difference, eg how far the relative orientation need to be corrected by spinning around the z-axis. 6) Multiply the two quaternions to get the final absolute orientation quaternion. This does work, though has the issues I mentioned previously, and relies on the undocumented fact the the relative orientation is actually absolute with respect to the down/gravity vector.

For my use case, I want to know the exact way the phone is pointed in all three axis. Which requires more information than determining the screen orientation (and which I believe can be done as you say). Unfortunately, the term "orientation" seems to be overloaded and used to describe both concepts.

I wish I had come to that conclusion a week ago, but I'm in too deep now. It's for a little side project, and it seems like the majority of people I want to show it to have iPhones.

Pretty much. The iPhone browser api only exposes compass data in one dimension, around the z-axis. So there is indeed gimbal lock-like behavior near the axis. Which is crazy since the magnetometer is 3 dimensional.

My wife has had to listen to me complain for the last week about what a pain it is to get the absolute orientation of an iPhone from the browser.

On Android you can use AbsoluteOrientationSensor or deviceorientationabsolute event. These will provide a quaternion or Euler angles describing how to rotate the device from the default orientation (flat on the ground, screen up, with the top pointing north) to its current orientation.

The situation on the iPhone has almost reduced me to tears. As far as I can tell, it only provides Euler angles relative to some implementation defined reference frame, along with the actual compass heading. In practice, the Euler angles given are absolute with respect to gravity, but always treat north as the direction the phone was pointed when the first sensor reading took place. To deal with this, you can use the actual compass heading to rotate the relative orientation to the absolute orientation. But this will have problems near the poles, as the Euler angles and heading will give conflicting values. Beyond this the compass heading field is really weird. If you want to experience its behavior for yourself, take the iPhone compass app and starting from flat, rotate the phone 360 degrees through the pitch axis. Notice at what points the heading flips between its start heading and start heading+180. I bet it will surprise you!

I read this and thought surely the center of gravity still has to pass over the bar. But right you are, the center of gravity can pass below the bar since it's just the average point of the mass. Cool!