dougbarrett

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.

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.

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 wonder why they didn’t just continue this under the Alexa product?

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.

I've been using echo for years. Has a great balance of adding helpful utilities while also not imposing bad patterns.

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.

Got it. Thanks for correcting me!

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.

I don't see the 13" MBP sticking around much longer. At this point, the differences between the Air and 13" MBP are minimal, so I see them eventually adding a few more cores to the air, possibly giving that some of the aesthetic treatment of these new Pro's, and removing the 13" from the lineup.

It's possible the Apple employee knows something we don't, but it doesn't make sense to keep it around since there is nothing particularly Pro about it when comparing it to the new machines.

I've got the M1 Macbook Pro, 16 GB RAM and 2 TB hard drive, and do 95% software development and 5% photoshop, related to web development, so I'm not dealing with massive files with a ton of layers.

I'd say that this is more than enough power to hold me off from upgrading for the next few years, so fortunately for you I'd say if you can, the RAM upgrade may be more important than the actual CPU upgrade.

I think my position is unique to others. A year after I started, my wife and I had our first child, so ensuring we had a stable and steady stream of income was my priority above all else.

Along with that, the company I work for has been good to me through the years. I've enjoyed working with my co-workers and the projects I work on. While I may be able to make more working for another company, I do think that the atmosphere and ethos of a company bring a certain amount of value that I would be trading off. I may be wrong, but I have no reason to think otherwise at this point.

I've always been self-taught, and always tried to be working on something on the side, so I believe that has allowed me to keep up with changes and try new things to scratch my itch of not being complacent.

When I first started working at my full-time job, I was the only developer working on my project and was entrusted with choosing the stack I felt could get the job done. It felt very early start-up in that sense. Shortly after that, I began working on another product that I'm still working on today, and wrote the main components in Go and some back office parts in PHP. To help support me being the sole dev, we had a few other devs come in and rewrite the majority of the components in Java because back in 2013, Go wasn't as widely used as it was today.

I'm thankful that for the most part I've always been able to choose the tech or libraries I want to work with, within reason. I try not to push it too much, for example we use MySQL and Redis primarily for data storage and transient storage, but part of our app does use Mongo and that was a direct result of me trying to hop on the bandwagon early on that I now do regret because Mongo provides us no benefit over MySQL.

If I do want to use some obscure tech to test out, then I'll use it for my own projects. If I feel comfortable enough then I'll use that for my client projects as well. Only if it's something I've battle tested will I see if I can use it in my primary job.

For the first time in 5+ years I am not developing a client side-project in PHP or Go, I'll be using Ruby on Rails, because I'm at the point that the stability of the toolset and my productivity outweigh any performance gains that may be had with Go, and these projects are primarily back office that won't be doing a ton of data crunching or have more than a dozen users using it at a single point in time.

I've been in my current role for nearly 9 years, working in the field for 12+. I'd say that the one piece of advice is to not get stuck to a certain stack if you have the authority to make those decisions.

You're definitely going to make the wrong decisions about the stack you choose, or the way you design elements of your code, but that is how you learn.

Good problems to have, like scaling to thousands of concurrent requests, have been the greatest opportunities to learn. You may not get the answers right away, but they will come.

Before I get comfortable with learning any new language, look into the best practices for caching, or how easily that is handled. Your ability to know how and when to cache whether it's in memory if the language you use supports that, or through memcached/redis is going to make it less likely that you're going to need to do a complete rewrite in the future.

I first started programming 20+ years ago before I was 10 years old, with Visual Basic and the demo. Eventually moving to access, and PHP in the early 2000's in my later years in high school. Today, some of the larger apps I've written have been written in Go. Lately in the last few weeks, I've really come to love Ruby/Ruby on Rails, and for apps that I don't need to scale, that is going to be my go-to language for my own projects and client projects.

Would I suggest we rewrite everything or utilize Rails in my day job? Not a chance, because 1) my productivity is not worth it and 2) it's not the right tool for the job. Maybe if we had to write some back office software I'd recommend it, or I'd use Sinatra for a basic API/demo.

What additional features are you looking for? I've been using beanstalk for the past few years, and just wrapped up doing a large deployment on it. I've never found beanstalk to be a bottleneck or not have a feature I was looking for.