I used ngrok when it was the to-go answer for serving localhost (temporarily, not permanent) to the public, but the last time I searched for alternatives I stumbled upon the following jewel.
> tailscale funnel 3000
Available on the internet:
https://some-device-name.tail12345.ts.net/
|-- proxy http://127.0.0.1:3000
Press Ctrl+C to exit.
I've tailscale installed on my machine anyway for some connected devices. But even without this would convince me using it, because it's part of the free tier, dead simple and with tailscale it's coming from kind of a trusted entity.
Hey really recommend using a big long random string in that URL, because as you will have read above TAILNET NAMES ARE PUBLIC. You can find them here: https://crt.sh/?Identity=ts.net [warning, this will probably crash browser if you leave it open too long -- but you can see it's full of tailnet domains].
So anyway try it like:
tailscale funnel --set-path=/A8200B0F-6E0E-4FE2-9135-8A440DB9469D
http://127.0.0.1:8001 or whatever
Hey, I didn't mean to sell another tool over yours! It's just an experience that popped into my mind and I wanted to share. I appreciate your work and contributing to the problem space of exposing a local service. Thank you.
I did not play this (yet!), but just by watching this video I see how it overlaps with the coding games on https://code.org/en-US (Hour of Code!) in terms of having a code + gaming view to solve a challenge.
When I was teaching coding to kids, code.org was the to-go place besides using Scratch, to introduce coding patterns (mostly: conditional, loops).
An example is the famous Minecraft labyrinth [1]. There is also a Frozen themed one. If you have kids (~6y+), that's some fun way to get started instead of diving directly into actual code.
Back in the Macromedia Flash 5 days (25 years ago!), Robert Penner popularized the easing concept. I can't imagine the void we had before that. I clearly remember me starring at the formulas in ActionScript 1.0 (see [1]) without any chance of understanding them - but usage was clear, easy and fun!
Those formulas basically generated the required tweening numbers mathematical (comparable to the Bezier approach mentioned in the article). That's a much different concept to the linear interpolation described in the linked blog article where you pass in a static list of numbers. The more complex your curve the more numbers you need. That's when the author links to the external tool "Linear() Easing Generator" by Jake Archibald and Adam Argyle. It was a fresh and nice reading even though animations are less a topic for me then it was back with Flash.
Here an example of an easing function from the linked source file.
The tween executing function would pass in time (t) and other parameters I can't name to calculate the resulting value continuously.
Math.easeInOutBack = function (t, b, c, d, s) {
if (s == undefined) s = 1.70158;
if ((t/=d/2) < 1) return c/2*(t*t*(((s*=(1.525))+1)*t - s)) + b;
return c/2*((t-=2)*t*(((s*=(1.525))+1)*t + s) + 2) + b;
};
If you want to dig deeper, visit roberpenner's easing overview [2] with some resources. Surprisingly all of those links are still working.
I missed the "About" link in the footer but still found my way to the repo [1], where the project is briefly explained including a ton of great example images. Thanks for that!
> This website (technology demo) allows you to aggregate and visualize massive amounts of air traffic data. The data is hosted in a ClickHouse database and queried on the fly. You can tune the visualizations with custom SQL queries and drill-down from 50 billion records to individual data records.
Yeah there are some issues. PR is stuck at "Checking for the ability to merge automatically..."
By accident I landed on https://us.githubstatus.com/ and everything was green. At first, I thought, yeah sure, just report green, then I realized "GitHub Enterprise Cloud" in the title. There is also a EU mirror: https://eu.githubstatus.com
Edit:
The report just updated with the following interesting bit.
> We identified a faulty network component and have removed it from the infrastructure. Recovery has started and we expect full recovery shortly.
That's interesting—my understanding is that Github Enterprise Cloud is part of the same infrastructure as Github.com, so this status page seems maybe incorrect? Probably some missing step in the runbook to update both of these pages at the same time.
Content wise a nice idea, but I also like the conclusion about how AI made this possible in the first place. The author itself mentions this motivation. AI is undoubtedly perfect for utilities, small (even company internal) tools for personal use where maintainability is secondary as you can ditch the tool or rebuild it quickly.
> Two years ago, I wouldn’t have bothered with the rewrite, let alone creating the script in the first place. The friction was too high. Now, small utility scripts like this are almost free to build.
> That’s the real story. Not the script, but how AI changes the calculus of what’s worth our time.
I've found that to be very true. For bigger projects, I've had rather mixed results from ai but for small utility scripts, it's perfect.
But like the author, I've found that it's usually better to have the llm output python, go or rust than use bash. So I've often had to ask it to rewrite at the beginning. Now I just directly skip bash
That all the naysayers are missing the tons of small wins that are happening every single day by people using AI to write code, that weren't possible before.
I specified in a thread a few weeks ago that we manage a small elixir-rust library, and I have never coded rust in my life. Sure, it's about 20 lines of rust, mostly mapping to the underlying rust lib, but so far I've used claude to just maintain it (fix deprecations, perform upgrades, etc).
No, just no. Or maybe it depends. But if you want to provide a lovely, modern, interactive frontend, you can't just blindly ignore what evolved on the frontend ecosystem for the sake of your purity. It's arrogant and dismisses all the people who love to craft enjoyable frontends.
Following some thoughts about how to merge Rails and modern frontend approaches and how Inertia finally solved that question for me.
--
I consider myself more frontend focused but I have a deep love for Rails and some advanced experience, for sure less than in frontend though.
I tried hard following the route of hotwire, stimulus and friends knowing that DHH and the rest of the community loves those JS patterns.
Creating reusable stuff, cresting just a little bit more complex components, sharing those components through the UI.. it's just horrible cumbersome, repetitive and far, far away from all those best practices and patterns we've developed in the frontend.
I tried creating a diff viewer with comment functionality with stimulus. It worked, I was kind of proud but it was cumbersome the define components and share functionality. Maintainable? No way.
Then I wanted to create a double list where you can drag items from left to right. It was the hell to include css, js, manage the hierarchy and then I just gave up. I was demotivated by the constant nagging of my brain how much more simple this would have been with a single, simple react/vue component.
Then I went the wrong route: Rails API plus React. That's just giving up on most of what Rails gives you and I wasted ton of my time creating an additional auth layer on top of the session that Rails would give me. And then the horrible duplication of your state. One in Rails and then the same stuff in React. The same nagging in my brain now told me: That's wrong.
And then I found the holy grail of modern Rails development: Inertia.js.
I heard about it very often but never at the right time. So I forced myself to try it out.
And here I am: I use Rails with Inertia Rails. I have the full pleasure of Rails but I can create React components that represent any page I like to write in React. Inertia will serialize and pass in the data from my controller. So no state. Just pure UI building.
If you love Rails and the frontend: Try out Inertia. It feels like I'm using the best of both worlds. The layer inertia creates is very shallow and optional. So the risk is low.
I relate absolutely zero with their reasoning around AI. It's so fabricated.
> While staying true to Google’s iconic four colors, the brighter hues and gradient design symbolize the surge of AI-driven innovation and creative energy across our products and technology.
I've a related observation. In my experience the amount of hallucinated urls with structured output (think of a field `url` or `link`) is pretty high. Especially compared to the alternative approach, where you let the llm generate text and then use a second llm to convert the text into the desired structured format.
With structured output, it's like the llm is forced to answer in a very specific way. So if there is no url for the given field, it makes up the url.
Here a related quote from the article:
> Structured outputs builds on top of sampling by constraining the model's output to a specific format.
What I've found is that it is very important to make structured outputs as easy for the LLM as possible. This means making your schemas LLM-friendly instead of programmer-friendly.
E.g. if the LLM hallucinates non-existing URLs, you may add a boolean "contains_url" field to your entity's JSON schema, placing it before the URL field itself. This way, the URL extraction is split into two simpler steps, checking if the URL is there and actually extracting it. If the URL is missing, the `"contains_url": false` field in the context will strongly urge the LLM to output an empty string there.
This also comes up with quantities a lot. Imagine you're trying to sort job adverts by salary ranges, which you extract via LLm. . These may be expressed as monthly instead of annual (common in some countries), in different currencies, pre / post tax etc.
Instead of having an `annual_pretax_salary_usd` field, which is what you actually want, but which the LLM is extremely ill-equipped to generate, have a detailed schema like `type: monthly|yearly, currency:str, low:float, high:float, tax: pre_tax|post_tax`.
That schema is much easier for an LLM to generate, and you can then convert it to a single number via straight code.
As you know, (most current) LLMs build text autoregressively. This allows them to generate text with _exactly_ the same distribution as the training data.
When you constrain LLM output at each token, that gives a completely different distribution from letting the LLM generate a full output and then doing something with that (trying again, returning an error, post-processing, etc).
E.g.: Suppose the LLM has a training set of (aa, ab, ab, ba), noting that "ab" appears twice. Suppose your valid grammar is the set (ab, ba). Then your output distributions are:
Baseline: {invalid: 25%, ab: 50%, ba: 25%}
Constrained: {invalid: 0%, ab: 75%, ba: 25%}
Note that _all_ the previously invalid outputs were dumped into the "ab" bucket, skewing the ratio between "ab" and "ba". That skew may or may not be desirable, but assuming the training process was any good it's likely undesirable.
You've observed it in URLs, but I see it in JSON output as well. LLMs like to truncate long strings from time to time, but when they do they're more likely to provide invalid JSON (adding an ellipsis at the end of the fragment and doing nothing else). If that truncation starts to happen in a constrained environment, a period is a valid character in a long string, and eventually the grammar constraint will force a closing quote to appear. The result is still garbage, but instead of a detectable parse failure you have an undetectable corrupt field.
1. Choose the first token. If well-trained you have a 75% chance of choosing "a" and a 25% chance of choosing "b". Both are valid for that grammar.
2. Choose the second token. Regardless of your first token there is exactly once choice of grammar-adhering completion. You're now at a 75% chance of "ab" and a 25% chance of "ba" (mirroring the first-token chance).
For a toy example like this you obviously wouldn't use an LLM, but techniques like you're suggesting don't work because it's infeasible to enumerate all the valid outputs and re-weight and because greedy and semi-greedy strategies aren't anywhere near sufficient to side-step the issue. At the point in time you select the "a" token at a 75% probability it's game-over unless you re-run the LLM. You can't beam search either (doing so just changes which token you'll mis-predict, and even then only for very local grammar mistakes).
Looking at my JSON example from earlier, a beam search to avoid that re-weighting requires a depth of at least 4 (going as far as the ellipsis plus the stop token), and it won't suffice to just consider locally high-weight paths (you can probably hack something together for that one issue in particular which searches high weight paths and backtracks if they're found to be low-weight due to grammar mismatches, but that has its own bias unless you fan out to all 1e19 length-4 paths, and it won't solve the general problem regardless).
Phrased slightly differently, you don't have a compute_future_grammar_adhering_weight(token) function which is tractably computable, so you can't actually redistribute the 8.3% probability from the "a" branch to the "b" branch.
Oh now I understand. I thought your ab and ba were single tokens (even though that doesn't make sense in context). Once you point out they're separate tokens, I follow you. Thank you!
Edit: that's a great example
Edit 2: even more fun: training data is [ab, ab, ba, bb, bb, bb]. Then constrained sampling flips your likelihood from 1:2 to 2:1
Thanks :) My example is minimal, which is a little nice since I wind up re-deriving it in a hurry every time I need it. I do like the 1:2 to 2:1 symmetry though. Very elegant.
> let the llm generate text and then use a second llm to convert the text into the desired structured format
this sounds similar to what they discussed in the article with regards to "thinking" models, i.e. let them generate their <think>blah blah</think> preamble first before starting to constrain the output to structured format
Can you please give any sources? While it sounds plausible and interesting it's nothing more than a wild conspiracy theory without some background information.
Buy a broadcom smartphone. Turn bluetooth off, and set it to airplane mode. Then Bluepwn your device, with bluetooth turned off.
Funny how airplane mode didn't work.
That's just one of the quirks. Baseband and what qualcomm is tracking is way worse.
I recommend buying an old Motorola Calypso device and fiddling with osmocomBB, you can DIY an IMSI catcher pretty easily. And you'll be mind blown how many class0 SMS you'll receive per day, just for tracking you. Back in the days you could track people's phones remotely but the popularity of HushSMS and other tools made cell providers block class0 SMS not sent by themselves.
You made the assertion that basebands remain in contact with towers even in airplane mode, and so can be tracked. Someone asked for supporting evidence for that claim. You've responded with examples and links to different issues. It's a fairly extraordinary claim (it's not one I'd heard before - it's clear that other radios may remain alive for various purposes even when airplane mode is switched on, given that you can use wifi and bluetooth on planes, but you're the first person I've heard make this claim about the cellular radio), and you haven't provided any evidence to back it up at all.
Saying more words and then linking to a page from an IMSI catcher's wiki (where it doesn't talk about radio on/off states) isn't exactly "providing sources".
Baseband SoC running their own OS independent from Android/iOS and staying asleep (while still listening for incoming signals) is very much no longer in conspiracy theory territory and more an established fact now. I don't have the source at hand but it's in one of the standards. And the purpose is very clear: LEA like Interpol must be able to locate any IMEI at any point if in tower range, regardless of the power state of the "main" OS
I don’t doubt SoCs have their own micro-OS, but I too would love to see a reliable source showing phones connect to towers when powered off. Wouldn’t this, at a minimum, violate FAA/EASA rules? Google tells me the cellular radio in an iPhone has no power when in airplane mode or when off.
Interesting, but you should probably use a control. Two phones, same hardware, same software. One inside the faraday cage, one outside, both in the same room with the same conditions otherwise.
Repeat the experiment a few times. Then cross over: liberate the caged phone, cage the free phone, and repeat the experiment a few more times. Or alternate the phones' positions between experiments. This mitigates hardware and software differences that might've been overlooked (such as a faulty battery, etc).
Analyze the results, draw your conclusions, publish, and encourage others to reproduce.
It would still be simpler for you to link to a credible source. A bit strange that you seem uninterested in doing so, and prefer to tell people to do their own experiments, in this case one that requires an extra phone and a week of time.
