kodebrew

Shortcomings are listed quite clearly in the README.

Found myself wanting to build something like for a long time. Pretty much every time I work on any sort of significantly sized Javascript project I'm frustrated with the speed and fragility of the tools.

This isn't a replacement for webpack yet as it doesn't have a full featureset.

Ever struggled reviewing a large pull request in GitHub? PRHero is an open source alternative UI for reviewing pull requests.

I'm playing around with a lot of ideas here, feedback welcome.

Huh interesting. I do agree that this is also a problem for me.

Would it follow naturally from just being able to see the files that are affected? I'll look at the model file first and then move onto the controller file for example.

It should handle large PR's quite well. It probably doesn't right now but that's more a function of the code being hacky.

I think the problem with the GitHub UI is you have so much scrolling that it's a large amount for the browser to try and paint out and for a user to parse through. Since this is only showing a diff on a file at a time it's not subject to that issue.

Understand what "cost" means to an economist.

To understand cost in economics you'll learn topics like externalities (positive and negative) as well as internalities and their meaning. You'll dive into concepts like opportunity cost as well as fixed vs sunk costs.

Once you get at truly what cost means to an economist you will be so much better informed in making business and personal decisions. In my line of work (software development) so many products and daily decisions hit the sunk cost fallacy of wanting to hang onto projects we are in love with. Other ideas like negative externalities really are the underpinning of understanding why climate change is out of control.

Cost is always oversimplified. Spending some time to understand it deeply and learn the concepts and common language is incredibly valuable.

Yep usability. Some sort of common patterns for all of these tools.

I've found deploying to all these new infrastructure tools is a big gap. I've been open sourcing a tool https://deliverybot.dev that I built internally at my current org.

You are right to be skeptical - this is a really new idea that I did just get started on this week. To answer your question:

I've investigated whether it's feasible technically, talked with a few people who would use it to refine the concept and built a really rough prototype of the UI.

Is this just to gauge interest? Yes. In doing that though I have found a first customer that wants to switch from their current system if it works as advertised. I can't promise it will but I definitely will try :)

Thanks for your question, I hope you'll give it a shot once it launches.

I wonder if mattermost has the APIs to support this. Good suggestion, I'll take a look at this!

I definitely agree with this. I have to say though, I really enjoyed Blink and the storytelling around that. I visited the statue from the first chapter in the story and marvelled at how researchers "just believed" it was fake.

Sometimes pop-psychology, if it gets us more interested in subjects, may not be that harmful.

Similar experience, we ended up building way more custom tooling and scripting than we wanted for our CI pipeline. We used Jenkins so speed was OK but I was really reminded that Kubernetes is not a PaaS it's Iaas. Basically we weren't really ready to go build a platform internally for our developers.

If you are curious I've been working on open sourcing some of the ideas we've built internally at my organization into some tooling built around deploying from GitHub: https://deliverybot.github.io/

I found the same - I had to actually launch my own cluster and build my own terraform scripts from scratch to really understand how it works. Basically this:

https://github.com/kelseyhightower/kubernetes-the-hard-way

Really helped me, especially going through it multiple times.

I think we had this issue as well. I kind of hoped turning over kubectl to the team would be a lightbulb moment and everyone would just get it. It really wasn't. Did a lot of training but I think that we mostly ended up writing our own tooling wrapping everything.

Yes I think it would insert an empty string. I think all the tests are using uuid's as primary keys, this is a good point -- thanks for raising.

Agreed.

Thanks for finding the typos!

Short answer: It's sqlx + a query builder + some extras around transaction management.

Maybe this is true? I may not have thought through the entire feature that carefully.

The initial thought behind it: Go programmers generally use values for scalars instead of pointers. Can we make an sql mapper that reflects that general practice?

Maybe the answer is no.

Hi founder of CloudCosts here. I built this tool to simplify my daily monitoring of what I spend on AWS / Google cloud. After a $400 bill that I received once while on vacation.

Let me know if you have any feedback on the product.

Hey, this looks really cool! I've been working on a very similar product: https://cloudcosts.io/. It's only hosted, no open source versions of the software and much simpler.

It has a few users and I haven't figured out yet if it could be monetized. The basic thing that I wanted was a daily email of my cost changes from AWS.

How have you found trying to integrate Google Cloud and AWS billing? That's where the real value in this type of product is to me.