I just use a bookmarklet that nukes any position:fixed elements on the page. Works on toolbars, cookie banners, full page interstitials — really shockingly useful on the hostile web.
There's a Sensor Watch simulator that demonstrates the features of the various firmware images; this one[1] is running the firmware that shipped with the first boards, and includes a clock, world clock (UTC by default, but customizable by holding the Alarm button), sunrise/sunset, moon phase and temperature. For the sunrise/sunset to work, you'll have to click the "Set Location Register" button, which will prompt for location access.
There are other versions of prebuilt firmware here[2], but my favorite one (even if it's a bit impractical) is the Stargazer firmware[3], whose second watch face can display the locations of the sun, moon and seven planets both in right ascension and declination, as well as altitude and azimuth if you grant location access. We're able to fit a truncated version of the VSOP87 model for planetary motion, right there on your wrist.
The Movement framework for developing watch faces tries to steer folks toward low power consumption by default; the watch spends most of its time in standby, and a custom watch face only runs code once per loop (which is once a second by default, although you can request more frequent updates from 1 to 128 Hz). This means most watch faces can actually stay under 10 µA as long as they don't need to update too frequently; up to about 16 Hz, power consumption remains decent.
Anecdotally, my daily driver is coming up on 550 days on the same CR2016 coin cell from February 2022, and I think it's on track to make it to 2024. A far cry from the original's 7+ year battery life, but still pretty good considering all it's capable of!
oh hey, this is my project! Sensor Watch definitely has different goals — less smart, more watch — but I love this, and I love how the F-91W represents such a blank canvas for folks to project their vision onto. It's small and so very thin (at home on any person's wrist), water-resistant and vaguely indestructible. It's also so inexpensive and ubiquitous that you can take it apart and hack on it without feeling like you're breaking something important, and you can safely assume that anyone in the world can probably grab one at a local store and hack along at home. It's a wonderful object.
I made an Apple Watch app and complication a few years ago that averages $800 a month. I don't put any money into marketing or search ads, and it's been feature-complete since 2019:
The app is built around two small, simple features: today's date with a customizable format, and a three-year calendar so you can see what weekday dates fall on outside of the current month. It also supports several alternative calendar systems including the Islamic and Hebrew religious calendars, which I think may be another use case that drives sales.
Anyway: it's a one-time, two-dollar purchase that lots of folks are still finding and finding useful.
I'd been planning to use it with the Feather M0 Bluefruit, but for now I'm testing with an M0 Express with one of these LED displays next to it [1] on a board doubler. Good to know that this is more temperature rise than you'd expect to see; I'll have to confirm that (and measure the thing's current draw, which I have not had a chance to do yet). Thanks!
Weirdly coincidental timing on this! I've been working on a PCB design (FeatherWing form factor) to track weather data on my hikes, making use of a BME280 and a GPS module. First revision of the board[1], I discovered that the sensors started out accurate, then drifted up to a steady 3° above ambient. Probably because the GPS module was heating up. So last night I found myself reading up on design considerations for temperature sensors [2], including specific things like the cutout you have on the left side of this board.
I'm guessing you designed this — any advice as I embark on designing a second revision of my hiking log?
This reminds me of a short story by Paul Ford from a few years back[1]:
We had gone to a baseball game at the beginning of the season. They had played a song on the public address system, and she sang along without permission. They used to factor that into ticket price—they still do if you pay extra or have a season pass—but now other companies handled the followup. And here was the video from that day, one of many tens of thousands simultaneously recorded from gun scanners on the stadium roof. In the video my daughter wore a cap and a blue T-shirt. I sat beside her, my arm over her shoulder, grinning. Her voice was clear and high; the ambient roar of the audience beyond us filtered down to static...
I told my waiting daughter to go ahead and pay the few dollars, just part of the latent cost of a ticket. She tapped and the tablet made its cash-register sound, and the video was irrevocably destroyed so that it could never again be shared.
You can avoid airlines that have the 737 MAX in their fleet (domestically, the biggest are United, Southwest and American). Whenever I fly I fly Delta, and I’ll never fly on a MAX because Delta doesn’t have any.
I half want to make a Kickstarter called "Let's Kill Facebook" that promises to give people $50 of the total proceeds to delete their Facebook account. I'd venture a surprising number of people who really care about killing Facebook would back it, and a surprising number of people who don't care that much about Facebook would take the $50. If it went viral enough to make an impact on people's networks, #3 would take care of the rest.
(I'm not actually going to do this, but it's a fun thought experiment.)
The thing to keep in mind is that before the sighting, the months are pre-calculated for when the first crescent moon should rise over Mecca. So a change only affects the single month where the observation differed. For example, if you're expecting to see the first crescent moons on October 10, November 9 and December 8, but you didn't see the first one until October 11, that doesn't push the moon sightings out for the rest of the year. It just means that the month you thought would end on October 9 will have an extra day, and the month you thought would start on October 10 will start a day later (and as a result will be a day shorter).
Future months are still totally fine; the date offset is just a temporary fix that the user remembers to turn on when the announcement is made, and to turn off at the end of the month.
I've encountered just about every item on this list working on my Apple Watch complication, Better Day[1], which supports 11 calendar systems in 21 languages. The funny thing is, the last item on this list — always use ICU through the NSCalendar API — is the exact conclusion I arrived at, and one that I preach to anyone who will listen.
Especially with modern Swift syntax, complex questions like "what's the current day of the year" end up having simple, almost poetic answers like "calendar.ordinality(of: .day, in: .year, for: date)". And you can trust that they are correct for every calendar and every locale. Usually. [2]
This is actually one of the reasons I posted this, because I'm not sure, I'm not a lawyer and while I'm hopeful I got it right, I'd love guidance if I got it wrong.
Can you elaborate? What am I missing / what would I need to do to be GDPR compliant?
Background: I decided to write my own privacy policy for a personal side project of mine. It ended up being an interesting exercise for me, and I thought I'd share the final text.
It's a simple, static website put together with Jekyll; nevertheless, I realized that I do come into contact with user data in the course of publishing this small side project. Writing my own privacy policy, instead of pasting in from boilerplate, forced me to think about all the user data that I might come in contact with, and explain both the technical background for laypeople and my rationale for collecting the data in the first place.
I'm not sure the title is click-baiting; the reality sounds exactly as dire as the headline.
> The agency, which investigates deadly transit accidents, said Uber’s self-driving system determined the need to emergency-brake the car 1.3 seconds before the deadly impact. The NTSB report said that, according to Uber, automatic emergency braking isn’t enabled in order to “reduce the potential for erratic vehicle behavior” and that the system also isn’t designed to alert the operator in case of an emergency.
Since there seem to be a lot of knowledgable folks in these threads, I have a question about GDPR's impact on decentralized or federated social networks like Diaspora[1]. On these networks, users can create a profile on any server, and be connected with users on any other server via a federation protocol[2].
All the ideals of user control and data portability are there and central to the Diaspora project; but technically, the underlying protocol involves passing users' posts and comments from one server to another. This seems like it would fall afoul of guidelines against passing data to third parties, and the same technical constraint seems to be fundamental to other federated services like Friendica[3] and Mastodon[4]. I'm really curious how the GDPR would affect services like this, especially as someone who's quit Facebook and is looking at decentralized networks as an alternative.
This is going to sound crazy, but I spun up an instance of a simple open-source comments system[1] for a blog that I write, and I chickened out of deploying it because I wasn't sure if it complied with GDPR. I distrust Disqus over their ad-driven model and deep tracking of users, so for now I’m just doing without comments.
Is it possible to self-host something that handles user data (name, comment, IP address) and comply with this regulation? What if there's more data, federated data? Can one just spin up an instance of Friendica, for example, or are there additional steps required for compliance? I'm honestly not sure anymore.