darshan

Have you tried and failed, or you're just worried it might be hard? When I first set up a client for API calls, I put this paragraph in my system prompt:

Never ask questions or attempt to keep the conversation going -- answer the questions directly asked, and give additional information where it is likely to be helpful, but don't offer to do more things for the user.

I've never had an LLM offer to do things or try to keep the conversation going with this in my prompt.

It seems at least mostly on topic to share here this thing I released a little over a year ago: https://www.swapadoodle.com

It's definitely not useful for the same things, but it has a lot of similarities and seems potentially interesting as something to compare and contrast with this.

Mods: the link should perhaps be changed to: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/We...

This currently has 1215 points, and the link is no longer valid. It now just shows an image of Firefox's devtools and the sentence "Replay is an early experiment. We'll let you know on @FirefoxDevTools when it's ready for input." That's not useful, interesting, or informative. The MDN docs seem like an appropriate replacement.

I'd agree with you if it were just the first message. But they then explained exactly what they meant and why, and that's what I offered them feedback on.

They apologized to the person they said it to, and it all seems settled from my perspective.

Telling someone "this isn't interesting to you" in place of "I don't want to talk about it" is definitely not polite!

I'd say it's rude in general to tell someone they won't find something interesting, and especially so when it's done as a way of disowning your own preference not to talk about it.

I don't know if I'm having one of my hyper-literal moments, or if this is some other neurodiversity thing, but I can't make sense of the last paragraph... Can someone help explain it to me?

The way I read it is:

* 219-09-9999 is a made-up number that was never issued to anyone.

* The woman thought it was her number for unexplained reasons.

* She used the pamphlet as evidence that it was her number.

I must be missing something important. Is it a joke, with the punchline being that she thought the pamphlet was her social security card? If so, how was this the fault of the Board? Was it her SSN somehow? If so, how did the pamphlet prove it?

Here's an example of something really adorable made collaboratively by two people. The first person sent the first part to the second person, who used the Doodle-on-Doodle feature to add to it and make an even cuter story out of it.

https://www.swapadoodle.com/d/5288420972691456

I think 9× is the best speed to watch it at. (I'm still thinking of adding a way for the author of a Doodle to change its default speed.)

Thanks so much!

Were you using it in a browser? If you just use "Forward" in the browser, you'll go back (that is, forward) to the doodle you created, if you accidentally back out of it. In the native apps you can't go "forward" again, but if you have a (free) account, all your created doodles are in your "Doodles" folder.

Or am I picking up on confusion about my general model (which I'm certainly open to feedback about). If you draw and don't share, but press back or try to leave the page, you're prompted about destructively leaving. Sharing creates the doodle and makes a link for you to share (or bookmark, or whatever you like), so the contents aren't considered wiped at that point; they're considered successfully sent.

Please let me know if I'm failing to understand what isn't working as you expect, of if you think my model is confusing to new users. Thanks!

Thanks so much! I was definitely inspired by Go's (the language I use on the back end) careful balance of well-honed simplicity. There was a lot more work than one might think to keep things so simple!

Thanks! Yeah, I occasionally considered not including undos and redos, but there's so much positive value that easily outweighs the occasional negatives. Just a couple of the things I love about including them:

1) Much of the general idea is a sense of connection and intimacy -- it's not just the final product that you're sharing, but the process. When you see the mistakes, or the attempts to get something just right, it's a moment of connecting with the sender's experience while making it.

2) You can make emotionally evocative doodles by removing elements, so they're only present fleetingly but not present in the final image. (Examples of this are by friends I haven't thought to ask permission to share. But think: drawing a small plant, then undoing and drawing a bigger one, for several iterations, for example. You can sometimes do that by "erasing" the part you want to remove by drawing the background color, but if you want to remove something that's on top of something else, undoing is so much easier.)

When I first started making the app, Dart existed, but Flutter didn't. Then Flutter existed, but didn't support the web. I thought that was still true, but I just checked, and Flutter for web [https://flutter.dev/web] does now exist, as a technical preview ("When trying Flutter for web, you can expect to experience crashes and missing features.")

When Flutter came out, I looked into it, wondering if it might be worth switching my approach (I figured most of the Dart code would probably be able to stay the same). There were other deal breakers at the time, but I don't recall them.

Maybe once Flutter for web is production ready, it would make a compelling alternative, but for now it isn't an option. I'm not sure if would have made things harder or easier. But I'll be curious to check it out.

Nope, that's not accurate at all. The native apps support push notifications, in-app payments, native UI elements, proper lifecycle management (storing in-progress doodles across the app being killed in the background, or the device being restarted, for example), and more offline support than would be possible with the website. Among other things.

The things that are in the native wrappers are things that would be iOS-specific or Android-specific regardless of zero shared code or maximum shared code. In my case, the bulk of the app is shared -- everything that can be a common code base is a common code base.

According to GitHub's rough metrics, that's: Go 44.7% Dart 32.8% Java 7.1% JavaScript 6.9% Swift 6.6%

Thanks! I bought two iOS devices to develop on, but I haven't ever used the Messages app. Does it animate the drawing for the recipient, or just show the final image?

I just launched (like, an hour ago: https://news.ycombinator.com/item?id=20700196) a cross-platform app that is almost all shared code. In my case, the solution is a web app with very lightweight native wrappers, and I'm quite happy with it. Obviously that wouldn't be the perfect fit for all apps, but none of Dropbox's "(not so) hidden costs" are relevant in my case, and I suspect many apps would be a good fit for the architecture I went with.

Hi, all. OP / owner / founder here.

I’m finally launching a product that’s taken me years longer than I’d anticipated to complete. It’s a much bigger project than anything I’ve done before. My first app was the first battery indicator on Android, back in 2009, which was very successful by my standards (I didn’t have a college degree at the time and made way more money from it than I’d ever made from a job.) I also have a free instrument tuner on the Play Store.

Swap-a-Doodle aims much higher, and was quite an undertaking for me. It’s a cross-platform app (Android, iOS, and the web) for social drawing. I knew nothing about computer graphics when I started out, and just a bit about web programming. I learned so much along the way. I’m sure I’ll learn a lot more as the app grows.

The front end is written in Dart. The back end is written in Go and runs on App Engine, with Compute Engine for the websocket servers for live drawing (sharing a canvas with a friend to draw together at the same time). The Android and iOS apps are fairly small wrappers around the web app.

Feel free to ask questions. I’m of course open to feedback, or I wouldn’t post here — but I do feel somewhat vulnerable in this surreal moment of finally launching, so please keep that in mind and try to be kind if you do have criticism, and maybe frame it as “something that could be even better,” if that’s not too much of an ask. Thanks!

I've used Direct Labs multiple times over the years (including for 25 hydroxy) and I've always been perfectly happy with them.

I turned this on today via gcloud, and the certificate I was issued is from Let's Encrypt.

https://play.google.com/store/apps/details?id=com.darshancom...

When Android was pretty new, I got the myTouch (the second public Android device) and was surprised that there was no way to easily see the exact battery level. I'd been a hobbyist programmer for quite some time, and it seemed like a problem I might be able to tackle. The result was Android's first battery indicator app, which remains by far the most-used piece of software I've ever built, with over 8 million downloads.

The obvious answer is phonelessness. Sure enough, that's what the paper linked to in the article says: 3.4% of households surveyed did not have a phone.

http://www.cdc.gov/nchs/data/nhis/earlyrelease/wireless20151...

Ah, that totally makes sense, thanks!

I'm having trouble figuring out with Google -- what does CUD stand for here?

That is strange! I'm also on a stock 5.1.1 Nexus 6, but in the U.S. I guess you can at least be happy that this appears to be a bug (which means hopefully it will be fixed soon) as opposed to a bad design decision.

I have build 1.0.0.94391081, and I get the trash icon both when looking at individual photos and when selecting one or more photos. Which build do you have? (And which device?)

I'm interpreting the suggestion to mean that the original default with Go 1.0 should have been 2, because that is the lowest value (and thus would have the least of the the performance problems documented here) that would, as you say, reveal the same bugs. That way raising it to runtime.NumCPU wouldn't be a potentially breaking change.

Personally, I've found the issue to be documented well enough, and it is easy enough to set GOMAXPROCS to whatever works best for a given program, that I'm content with how the team has handled it. And I'm thrilled at the work that is being done now to fix the issue once and for all.

That was a typo -- the assembly stub took about 0.8 ms as shown in the trace.

That's intentional. Lollipop no longer has silent mode; instead it has "no interruptions" mode, which considers the LED indicator an interruption. I suspect there are third-party apps that can do a pseudo-silent mode that may work for you.

I'm pretty sure I mouse as quickly as anybody. It's just that the difference between 17 ms per frame and 33 ms per frame on my system only affects the smoothness of animations. There's no perceptible lag no matter how quickly I move things around.

That is completely different from my experience; I think you must have another problem besides the 30 fps frame rate. Perhaps your machine is just having trouble pushing that many pixels? On my machine, animations are just slightly, subtly choppy -- like Android used to be before all the "butter." But there's still very much the sense of instant responsiveness.

I'm pretty sure I came across information that up-to-date Macs can do all the necessary wrangling to make it work. If I planned to buy one and connect it to a Mac, I'd do some Googling to verify that, though.