Hi all - this is a culmination of a lot of work I've been doing over the past few years of trying to make different code generators, DSLs, and this is something I'm pretty proud of (but yes, I did lean heavily on Claude Code to see this vision through)
Some of the key features here are:
- API generation - transparent calling of API's from server or client-side. It's all go code and `gux gen` generates the http middleware for communicating to the backend
- Model scaffolding - generate admin screens with complex data relationships using a JSON configuration file
- Claude Code ready - comes baked in with skills and an initial CLAUDE.md file to get started
- Tailwind baked in - keeps your CSS file small
- Docker ready. Build the entire stack into a single binary that contains the wasm file and all dependencies.
I'd appreciate any feedback, good or bad, I know that this is a lot of "magic" for Go that is primarily frowned upon - but I've heavily inspired this off of tools like nicegui and streamlit and wanted to build something like that for Go.
I think they meant the 'Plan with Opus' model. shift+tab still works for me, the VS code extension allows you to plan still too, but the UI is _so_slow with updates.
I wonder if it's a difference between SSE and HTTP streaming support? I've been working on a tool for devs to create their own MCP tools and built out support for both protocols because it was easier for me to support both protocols vs explaining why it's not working for one LLM client or another.
Batching is a pattern I’ve had to manually build in the past to push large amounts of analytic data to a database. I’d push individual events to be logged, map reduce those in batches and then perform insert on duplicate update queries on the database, otherwise the threshold of incoming events was enough to saturate the connection pool making the app inoperable.
Even optimizing to where if an app instance new it ran the inert on update for a specific unique index by storing that in a hash map and only running updates from there on out to increase the count of occurrences of that event was enough to find significant performance gains as well.
I've seen this argument come up frequently and I find this is just a weird hill to die on. I can see where the author is coming from as far as taking you out of the experience, but QR codes and NFC absolutely have a place in the restaurant ordering experience and I'm here for it.
Plus, if you’re writing the front end in react or something else, that’s essentially the “other endpoint”. You’re just moving that back closer to the source of the origin.
This is definitely possible, and this is definitely already happening. It may be hard for some people to even tell the difference between an AI generated script/audio vs 100% human curated.
AWS beanstalk allows you to run on very cheap instances, even cheaper if you get a plan and commit to a term.
It’s not a 1:1 experience, but I’ve enjoyed it as an alternative to Heroku for sure. Alternatively, you could spin up a server and install dokku which is pretty close to a shipping experience, but still requires some maintenance and hand holding.
Have you considered doing payment processing, then the output goes to the users preferred payment method? So say my customer pays with a CC (via stripe or braintree on your end) - you could pass that payment along to PayPal, stripe, crypto, etc.
To me, that would be a useful alternative because all I'll need to do is enter my CC info, or preferably use apple pay which is much faster than me needing to ensure I have paypal, zelle, etc. installed.
I'm probably in the minority here, but I know for older people paying by CC is going to be easier than using an alternative payment processor.
This is really cool! I tried building something more basic than this a few years back, but this looks a lot more mature. I'll definitely be following and testing it out on a few small projects.
If I were you, I would stick with applying for senior or management positions if that's what you're looking to do ultimately. Are you interviewing or are you working on your resume?
If you have any long-term clients in your portfolio, maybe break those out as subsections within your resume under freelance/contract work. Instead of having many bullet points for freelancing, you have it broken out by company/project.
I'd suggest working on the proof of concept projects in your downtime with the language you're interested in working in. Unfortunately, I do not see many PHP jobs (that I'm interested in, at least). Still, I'm seeing many Go, Python, Ruby, Java, and .NET jobs, and you seem to have familiarity with most of those languages.
I think an excellent senior developer can understand the core concepts of what's going on in the application even if they're not an expert at writing the code, so I would lean on the fact that you bring prior experience with several different languages, and over many different industries. You'll be able to share pain points you've run into, best practices you've learned over the years, etc.
Best of luck in your job hunt; stay focused and keep your head up - don't devalue yourself!
Congrats on the build! I had a similar idea and worked on a similar project a few months back: https://infreq.social/ it obviously doesn't have the same polish that your project has, but the mission as far as what the end goal is for the frequency of the user viewing posts, and the ideal way of monetizing the platform are very much the same.
It's great to see that I'm not the only one with this crazy idea!
Hi all, Infreq Social is a social network I've been working on for the past few weeks. Over the past few years, everyone has seen an obsession with social networks, and more often than not people are checking their social network multiple times a day.
I wanted a place where I could connect with friends and family and not have to continue checking throughout the day, but just once a day and be able to move on with the day.
The focus of the social network is to not create features that tie you into the network. It has the ability for you to look back as far as a week to see what is going on in case you only frequent the website every few days if you prefer as well.
I hope someone will find this useful, I'd love to continue adding features to it for those who think it would fit their lifestyle with their friends and family!
Hi everyone! This project scratches an itch I've had for awhile now (ok, maybe 5+ years). I used to love using goo.gl in the past. It was an easy way to collect analytics for links that I would share around, and was accurate in it's reporting where other services like bit.ly were not.
I couldn't find anything that would do a few things I was looking for:
- Allow me to create a short URL, and instantly have a dashboard
- Give me basic geo, browser and referrer information like goo.gl did
- Not require me to make an account for this information.
I understand bullet point three is a feature that could go both ways, but the point is that I wanted something where I can get up and running with a shareable link as quickly as possible.
As for the tech stack, I tried to use some technologies that I haven't used before, and some that I have.
- It's written in Go, I'm very familiar with the language and have used it at scale.
- Hosted on AWS Beanstalk - again I'm familiar with hosting software here, and Beanstalk has the opportunity to use arm64 machines which I was eager to test out, so it was just a matter of me compiling a linux/arm64 compatible binary to push out. I'm on the smallest instance available at a cost of ~$3.60/mo.
- Uses dynamodb for meta data - I've used Mongo in the past, but I wanted to use something I didn't need to manage, and Aurora was cost prohibitive for a project that may never see the light of day.
- Uses Timestream for analytical data - Again, I didn't want to use MySQL to track this data, I wanted to find something scaleable and I knew timeseries databases were all the rage. I saw that this is a pay-as-you go solution and a zero-maintenance service.
Hopefully someone else that misses the simplicity of goo.gl will find this useful!
I don't think your default is necessarily the easiest way to get an app up and running, and certainly because of vendor lock-in and training required for the Google platform/services, you risk limiting the pool of available talent.
My default would be Ruby on Rails, or Laravel, and use something like Heroku or Render for hosting where all you need to do is push to a git repo to deploy.
Decoupling your frontend and backend may be useful down the line for scaling, but to start a monolithic stack is going to allow you to be the most productive.
From what I understand of alpine, it's commonly used for Docker images to provide a lightweight distro for your apps vs using something like ubuntu or debian which may include more than what's required.
I don't believe it's intended to be used in a desktop environment, but I could be wrong.
I'd argue against that. Recently, I tried making a few test apps with Phoenix and Rails to get my feet wet with something different (I write Go, Java and PHP in my day job), and with Phoenix I ran into a few issues getting the environment set up, the guide doesn't seem to be as coherent as the Rails dev guide, and there is no matching the resources available for Rails compared to Phoenix.
It'd be great to see that change over time, but to be honest I'd be more excited to see some movement behind the crystal lang, because I love coding in Ruby. All of my side projects are now being written in Ruby because I don't need something that scales in microseconds, or 10's of milliseconds for that matter, and I feel so much more productive.
Again, I hope I'm proven wrong. I think Phoenix has a lot of potential, but it still has a long way to dethrone Rails.
Some of the key features here are:
- API generation - transparent calling of API's from server or client-side. It's all go code and `gux gen` generates the http middleware for communicating to the backend - Model scaffolding - generate admin screens with complex data relationships using a JSON configuration file - Claude Code ready - comes baked in with skills and an initial CLAUDE.md file to get started - Tailwind baked in - keeps your CSS file small - Docker ready. Build the entire stack into a single binary that contains the wasm file and all dependencies.
There's some more info on https://guxcore.dev as well.
I'd appreciate any feedback, good or bad, I know that this is a lot of "magic" for Go that is primarily frowned upon - but I've heavily inspired this off of tools like nicegui and streamlit and wanted to build something like that for Go.