I've been using this for a while (the voice input, not their keyboard) and it's so refreshing to be able to just speak and have the output come out as fully formed, well punctuated sentences with proper capitalization.
I actually don't mind speaking punctuation, in fact it kind of helps. What I really hate is the middle-spot where we are right now, where it tries to place punctuation and sucks badly at it.
You're right that it exists, but it's complete crap outside a quiet environment. Try to use it while walking around outside or in any semi-noisy area and it fails horribly (iPhone 13, so YMMV if you have a newer one).
You cannot use an iPhone as a dictation device without reviewing the transcribed text, which IMO defeats the purpose of dictation.
Meanwhile, i've gotten excellent results on the iPhone from a Whipser->LLM pipeline.
I've never found real-time dictation software that doesn't need to be reviewed.
I'm definitely waiting for Apple to upgrade their dictation software to the next generation -- I have my own annoyances with it -- but I haven't found anything else that works way better, in real time, on a phone, that runs in the background (like as part of the keyboard).
You talk about Whisper but that doesn't even work in real time, much less when you have to run it through an LLM.
What's the real-time requirement for? We may have different use cases, but it's not needed if I don't need to review the results. Speak -> Send, without reviewing the text, is the desired workflow. I.e. so you can compose messages without looking at your phone.
So yes, i'm not sure of alternate real-time solutions, but the non real-time solution of Whisper is much better for my real-world use case.
This looks great! I've been wanting to drop the Swipe keyboard ever since I saw sneaky ads on it (like me typing "Google Maps" and getting "Bing Maps" as a "suggestion").
I can get behind people doing their own custom "licenses" that amount to throwing their work into the public domain, but if someone builds their own limited licenses around a thing, I won't touch their product. This FUTO license is garbage. Use a real license and either be open source or not; inventing new personal licenses doesn't do anyone any good.
Side note: this is actually a great advertisement for server side rendering! If they didn't do all this client side rendering, exposing data in JSON APIs, then I doubt this reverse engineering would have been possible.
I see what you mean. The barcode wouldn't work offline.
It seems like that didn't matter at the venue though? The spotty internet connection not allowing the code to load was the first part of the article wasn't it?
The article goes into that. If you open up the app ahead of time and download the ticket, it gets enough information to re-generate the barcode every 15 minutes. It's only a problem if you don't go into the app and fetch the data ahead of time.
I'm doing the same on an old macbook. Off topic, but any idea on how you remap command + left/right? On a mac it is the equivalent of Home and End. I tried xmodmap but it doesn't seem to work with those types of combinations... but maybe I'm missing something obvious?
We also migrated to ClickUp (though not from Jira) but while it's better than what we used before, it still feels... I don't know, sluggish. Loaders everywhere, lists are jumping when you scroll. Sometimes I click on a task, the detail modal opens up and there is a noticable delay while the data loads. Typing a / in the description which opens up the command panel or integration panal or whatever it called, freezes everything for like 100ms or more.
It looks like it's using Pocketbase as the DB. I've been using it in a Flutter app and have been thrilled with it. Definitely recommend it, especially a hosted instance on Pockethost
I use Workman as well. I tried Colemak (a bunch of variants) and it never sat well with me. There are some words on Workman that hammer the same hand. "People" is one that trips me up sometimes that is very common. Overall, I like Workman too
Yep I know exactly what you mean. I just assume that other layouts have equivalent words that are strange/awkward to type; seems unrealistic that there's a layout out there that is perfect for every common word. In any case I don't stress too much about whether or not the layout I use is the #1 top dog. The main thing was getting off QWERTY and onto something else that uses the home row more, because QWERTY hitting that top row a lot isn't the nicest for my average-sized hands (i.e. the scissoring motion contributed to a bit of discomfort long term).
This doesn't apply to LLMs writing code, and it is quite an aside, but I think we have destroyed a lot of ways the web works by chasing a "good" dev experience.
It is "nicer" to write JSX and Typescript in a Next.js project than it was to write jQuery in inline script tags on WordPress. No doubt. But I never had issues maintaining, scaling, updating, or improving those old sites. And I definitely wasn't nickel and dimed for every feature/service I needed to add.
I didn't have to wait for builds, or compiling, or worry about the deployment Node.js being a different version than the local Node.js. Or "open source" framework features being locked to certain hosts (looking at you RSC and Next.13) and their platforms. And the worst thing, coming back to a project after a couple years and it being impossible to get working because all the tooling has changed and/or been abandoned.
I recently had a client from 8 years ago want to move their hosting. They had been sitting on a PHP/Laravel-based CMS, hosted on DigitalOcean, paying $10 a month for ~7 years.
I haven't deployed any websites in the last 3 years that I think could even survive that long. Let alone even run locally after that time. The site could be running fine, but the tooling to work on it, or the platforms supporting it, will break. But my dev experience writing them has been, Chefs kiss!
React will be updated, and perfectly workable things will be deprecated, the tools to build/bundle code will be deprecated or abandoned for ones with a "better experience", and the hosting providers will drop support for older Node.js versions.
Maybe this speaks more to the disposable nature of the web these days, but I feel like websites specifically started getting more brittle and complicated when we started chasing dev experience over user experience.
I think you're getting some causality twisted - websites started getting more brittle (if they did?) when they started getting more complex, and they started getting more complex precisely because better dev tooling enabled it.
I think this is mostly your own personal experience and likely a bit rose tinted.
It is perfectly possible to deploy a webapp in React that will last for 10 years more or less how a website from 10 years ago could still function today. Also jQuery's very existence was due to how much of a disaster writing webapps was in the past with the host of compatibility issues between not only browsers but just within versions of the same browser. Also there's no issue scaling WordPress? WordPress is notoriously slow and hard to scale. It's a great option for getting a basic website up and running quickly but by God is it a slow and bloated mess and while you can performance tune it, it's not at all a simple or straight forward process and it certainly wasn't easier 10 years ago.
I've been a web developer since 1998 and it's definitely much easier to deploy, maintain and scale websites today than it ever was not to mention that websites today play a much larger role with the rise of mobile computing than they did back then.
To the extent that it was easier to do anything in the past, it was because the concerns of the past were much smaller than they are today. Security was a much lesser concern 10-15 years ago than now. Writing webapps that work across multiple devices also was a much lower priority. Compatibility was a complete mess, many sites were developed to just work on a specific version of Internet Explorer. The idea that 10 years ago there were minimal problems deploying websites or maintaining them is likely you remembering the good parts and forgetting the bad or that your websites didn't need much scale or didn't address many of the modern concerns that exist today. Things were pretty bad back then to be frank and it's much easier today than it ever was.
Don't get me wrong, I agree with you that things are easier for developers.
I followed a lot of the (let’s face it) hype and marketing around going headless and using hosted services. And the experience is pretty great for a developer.
But I've had clients who aren't happy with waiting for builds, paying per seat for a CMS, the turnaround of bug fixes and features, having to buy new services that used to be included, and also keep on top of the 100s of dependencies or changes among those services. All while being constantly charged for these "pleasures".
When asked what regulations Google is considering when it comes to bringing Bard to Canada, Sebastian cited the Online News Act, which would force tech giants and other companies to pay Canadian news producers for links posted to their platforms
“We’ll bring (Bard) here to Canada very soon as we manage through all the regulatory issues,” Sebastian said.
