I'm not a fan boy of DHH but I really like his critical thinking about the status quo. I'm not able to leave the cloud or I better phrase it as it's too comfortable right now. I really wanted to leave redis behind me as it's mostly a hidden part of Rails nothing I use directly but often I have to pay for it "in the cloud"
I quickly hit an issue with the family of Solid features: Documentation doesn't really cover the case "inside your existing application" (at least when I looked into it shortly after Rails 8 was released). Being in the cloud (render.com, fly.io and friends) I had to create multiple DBs, one for each Solid feature. That was not acceptable as you usually pay per service/DB not per usage - similar how you have to pay for Redis.
This was a great motivation to research the cloud space once again and then I found Railway. You pay per usage. So I've right now multiple DBs, one for each Solid feature. And on top multiple environments multiplying those DBs and I pay like cents for that part of the app while it's not really filled. Of course in this setup I would also pay cents for Redis but it's still good to see a less complex landscape in my deployment environment.
Long story short, while try to integrate SolidQueue myself I found Railway. Deployment are fun again with that! Maybe that helps someone today as well.
It's such a fabulous tool as the generated images can be used for effects like glass/ice displacements, cheap water-like effects, but you can also generate terrains from it or just cool visual effects that benefit from random patterns. The core property to me is that it feels very organic/natural.
This was such a common tool in Flash AS3 back in the days to create stunning effects, games and such. I'm not active in building visual stuff like that anymore but I bet it's still very common in this field, because why not?
Author here. P5JS is great and I've used it in the past. However you can get pretty far with just VanillaJS. Here's the source code to the ASCII Clouds tool, it's almost all plain JS.
Author here, yes you are correct that it's Simplex noise. I also use a method of domain warping, I used this article as reference https://iquilezles.org/articles/warp/
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'm not a fan boy of DHH but I really like his critical thinking about the status quo. I'm not able to leave the cloud or I better phrase it as it's too comfortable right now. I really wanted to leave redis behind me as it's mostly a hidden part of Rails nothing I use directly but often I have to pay for it "in the cloud"
I quickly hit an issue with the family of Solid features: Documentation doesn't really cover the case "inside your existing application" (at least when I looked into it shortly after Rails 8 was released). Being in the cloud (render.com, fly.io and friends) I had to create multiple DBs, one for each Solid feature. That was not acceptable as you usually pay per service/DB not per usage - similar how you have to pay for Redis.
This was a great motivation to research the cloud space once again and then I found Railway. You pay per usage. So I've right now multiple DBs, one for each Solid feature. And on top multiple environments multiplying those DBs and I pay like cents for that part of the app while it's not really filled. Of course in this setup I would also pay cents for Redis but it's still good to see a less complex landscape in my deployment environment.
Long story short, while try to integrate SolidQueue myself I found Railway. Deployment are fun again with that! Maybe that helps someone today as well.
reply