Heard of somebody who got 19 quadrillion dollars - I thought they meant Zimbabwean dollars
277 karma · joined March 27, 2020
IIRC they support 40 concurrent users, and in their model that would always be a school class, which I guess shouldn’t be larger anyway
It's an apparently simple problem on the surface, but quite hard to get it right... I once worked on a wireless network deployment for a transit refugee camp, and at least that was built on the assumption that some sort of Internet connection would be available at all times, making remote management possible. And even then it was tough to manage considering all other constraints.
I can only imagine how hard it is to deliver this kind of service reliably when Internet is rarely if ever available.
I initially liked to call it "unit tests for text", which inspired a prototype,[2] a blog post,[3] and then this product.
We believe everyone is getting really fed up of reading content only to immediately understand it was written by a robot. At the same time, we don't think language models are completely to blame, they are just a tool, and it's on us to use them properly.
The idea of UnitText is that before one starts writing they define a goal and audience for their content. It could be a blog post, but also an email... at some point we'd like to offer different templates for various types of content.
The human is the one doing the writing, and they can then ask the AI to "review" (or, "test") the content, to see whether the goal was met, the explanation is clear, something can be added or cut...
[1]: https://www.manning.com/books/writing-for-developers
[2]: https://github.com/sealambda/unit-text
[3]: https://www.sealambda.com/blog/this-post-passed-unit-tests/
We built UnitText[2] with the same idea in mind, although we started from the "proofreading/copy-editing" part. Arguably, that's something most don't do at all... but asking someone to read your content, give you feedback, and iterate on it is an extremely valuable part of the process. Having AI do it means you can do it almost for free, and often. Again, freeing up more time for the actual writing.
Doesn't mean a human copy-editor shouldn't review your content before you hit publish, or a writer shouldn't read their references, but AI can help a lot with all those steps.
[1]: https://en.wikipedia.org/wiki/No_true_Scotsman
[2]: https://unittext.com
Which is, to keep using LLMs as reviewers, rather than as writers.
If anything I find the “false negatives” more interesting: it would be easy to just set up some AI decoy with some prompt injection (“If you’re an AI model, these aren’t the messages you’re looking for”)
I see this as a signal. Many would like to write more, but they don't. I met quite a few developers at a conference last week, and did a rather statistically insignificant survey. I didn't get a single one to say they enjoyed writing. However, a good 80% said they would like to write more.
> the greatest trick behind blogging consistently is simply picking up the keyboard and starting to write
This reminded me of this post[1] from a few months ago. "Simply" doing something is usually not that simple, for whatever reason.
I think putting some structure to a process, defining a clear goal, is a good way to learn.
Finally, I really don't believe in the whole "writing for myself" thing, sorry. In fact, I used to think the same, until I realised it was (at least for me) sour grapes. Personally, when it truly is for myself, it stays in my Logseq journal.
I now "write for an audience". I try to imagine who I'm writing for, what they know, why they may be interested, and what I want to share with them. If I publish something, it is because I think somebody may care.
Then, I'm not really bothered if nobody reads what I write (or build). Meaning, I don't think I'm worthless or what I'm doing is useless when I get ignored. But I do consider it as some valuable feedback: if I broadcast something and get 0 replies, maybe I'm not building the right thing, or I am writing about something that nobody really cares about. Or I just presented it in a very poor way, and I can then figure out how to do better next time. Which is why I do think it's wise to spend some time reflecting and perfecting our craft but hey, whatever works for you!
Having said that, really happy for you that you manage to write so much, I wish I were able to be that productive!
[1]: Stop saying "just" (2019) - https://news.ycombinator.com/item?id=42038139
There are a couple of things I'd like to do next:
- make it into a public API - so that it's easier to create plugins; - provide multiple "blueprints" for different types of text (in this case, for emails).
I think with these 2 features it should then be trivial to make it available in email clients, or as a browser extension.
I don't really like it, but apparently it's what cool kids do these days ¯\_(ツ)_/¯ and it came with the template. But if it randomly breaks, too, off it goes!
Not to mention, there’s apparently some research saying code with swear words has higher quality, so if AI causes some decline there, we now know why it is https://www.reddit.com/r/programming/comments/110mj6p/open_s...
I feel less strongly about apps not looking like system apps; in fact, I kind of dislike apps that try too hard to look like the settings page: I like when they bring some variety, some personality, something that makes them stand out. Though I agree that broken interactions are unbearable, e.g. apps that break the "swipe back" gesture.
It could have been a web app as well (in fact, the initial version was), but some offline functionality was needed, and service workers messing up caching and iOS not being a great player with PWA, it just ended up being more painful than it should have been.
Or we could have built 3 apps, which I would have loved (but we are a team of 3, and working on a bunch of other things at the same time). Flutter does have a fairly good developer experience (its hot reload cycle is unmatched in my opinion), but of course native development, with all the support libraries you get from the platform, is on a different level. (What even is native though? Is UIKit "more native" than SwiftUI? Is Safari native? And how about the web apps you open in Safari? It's JS code, but at some point it's compiled to ARM instructions, now running from the very same memory pages as Safari, does that make the web app native?)
Having said that, it's not like I need to convince you to try out our app, it's good that we have options and probably Apple Invites is what works best for you!
But out of curiosity, when is the last time you did try out a Flutter app? Because they have been improving a lot, in fact for quite some time they ran better on iOS than on Android thanks to the new Impeller rendering engine (now default on Android as well)[1]
They did some work for accessibility on Web, too.[2]
BTW it's funny you mention React Native, I last built something with it a long time ago... and it wasn't that good - but I just realised I do use some React Native apps right now, so I guess they also improved a lot; I should give it a shot again!
[1]: https://docs.flutter.dev/perf/impeller [2]: https://docs.flutter.dev/ui/accessibility-and-internationali...
We actually started before this was announced, and initially it was developed for a somewhat different use case (more focusing on "recurring invites"), but since it was asked a few times, I think we can offer a good alternative with it. [2]
I try to make it obvious in UI by automatically converting to uppercase, replacing O->0 etc, and adding a dash in the middle.
However, what really broke this model at some point was the fact that we were running so many providers instances that our Terraform Cloud would go out of memory! Since each provider instance in tf is really launching a new process it really adds up... At some point I was thinking since the engine and the providers use gRPC to communicate, it MAY be possible to distribute providers across machines, but I never investigated it further... I'm pretty sure there was a notice in the tf plugin SDK stating that it was not possible to connect them over a network... but why not? ¯\_(ツ)_/¯
On the day DST starts, that event cannot exist, at 01:59 clocks will jump forward to 03:00. Vice versa, on the day DST ends, any time between 02:00 and 02:59 will happen twice.
You’d still need something to sign the certificates based on some other identity of course (it can be done manually but kind of defeats the purpose) be it smallstep or something else
As for where you’re with respect to any light, what you need is chart and compass. Usually there should be only one light with a certain characteristic in the area, which you can then track down in your chart. With a compass you get a bearing, and you now know you’re somewhere on a line. Find another lighthouse (or other landmark), get the bearing, and you can know where you’re fairly precisely!
(Source: I’m getting my sailing license :-)
Right now we offer a rather good portfolio aggregation, either via manual or automated syncing (read scraping… alas, the state of financial technology…). From basic to rather advanced figures, a lot of explanations. Market data, news, and dividends.
And finally a social network to discuss and learn with like minded folks. We wanted to do a proper Show HN in a few days actually, but I thought I’d leave it here as you could find it useful!
[^1]: https://yeekatee.com/