andrewallbright
andrewallbright on Hacker News
This helps in two ways. First, it helps me formulate my requests of ChatGPT. Second, it helps me discover incorrect output which I can then either fix myself or make a subsequent request of chatGPT.
I consider ChatGPT an extremely eager junior dev who makes mistakes by moving too quick in this slice of time. (Im sure it'll get much better very, very soon).
What a time to be alive.
For example should people be advised to rotate phone numbers every N amount of time?
Will you evaluate this tool to see if it affords a nicer workflow for you?
I would recommend getting into arduino. It's fun to buy little components, build little circuits, and see how your ability to program can have a physical manifestation.
As for programming concepts -- yes kinematics and inverse kinematics will allow you to move robotic limbs to certain points in real space.
And you'll find yourself wanting a larger conceptual framework to put those technical bits. That's where things like finite state machines, hierarchical finite state machines, behavior trees, and/or goal oriented action planners may come in handy. This grouping of concepts is often called "ai programming" but whatever you decide to call it, they're algorithms to decide what to do at any given slice of time.
Obviously follow your own path in this subject; follow the bits that resonate with you.
I dev on windows, osx, and Ubuntu.
So far I've written a go CLI that is able to bootstrap some stuff for a fresh computer, and tell me what I'm missing.
What conceptually helped me out was the idea that behavior trees (BTs) are hierarchical finite state machines (HFSMs). I read that and thought "woah!"
I've been fascinated by behavior trees ever since I learned that they were a big thing in Halo. It's charming to me to think that video games are able to help out in robotics, as the book pontificates on briefly.
Do whatever you need/want to that makes your software successful. The rules are meant to be broken if it means you shipping.
It's a much different scenario than what is usually talked about with these stories (2x full time vs full time + part time). Still, I wonder if there is (or soon will be) someone who has a part time job and will get fired for it?
Again, I doubt it because I don't think people looking into the scenario would think that's the right outcome. But you never really know I suppose!
How has living a post child life given you more insight into your pre child thoughts?
I'd love to know what optimization techniques are used so that those precious CPU/GPU cycles can go to those good looking things.
Side note: being absolutely forced to optimize the heck out of games as an essential practice gives me a much greater sense of performance characteristics in my "real" job and also in leetcode.
Why bravery to say "I don't know; I could probably find out but I cannot."
I started to teach myself unity in December 2021. I've personally experienced benefits to writing automated tests and using CICD; therefore, I thought it would be fun to learn about writing tests for a 3D based software. It will be different from the web/CLI based stuff I usually write.
So, it turns out that the video game community (or at least the online circles I frequent) are extremely against the idea of writing automated testing for various reasons. This translates into there effectively being a non-existent pedagogy around teaching how to write tests for 3D based software. Content is scarce, and the content you do find is produced by people who obviously don't write automated tests. So, for me I've hit the books to arbitrage & translate techniques and philosophies into this "untapped" domain.
It's interesting because I've figured out tips & tricks that I'd consider low hanging fruit... For example, if you place a "test" camera in the test case, you can actually see what's going on in the test when it's executed. Or how important it is to clean up every created game object in your test after each test; if done right, you can keep your SUT at origin (0,0,0). Or the importance of "test prefabs" who are effectively mocks of other "real" prefabs...
One innovation that I would like to use/build that I truly consider (((revolutionary))) is this: I want the test cases I write to also automatically (or when tagged with a certain C# attribute) generate the same game objects in a "exploratory(manual) test scene." I think this innovation is the "killer app" that will completely and totally sell the value proposition of automated tests to those opposed. If you decide to build this, please also publish it on openupm and reach out to me.
I have plenty of other thoughts and ideas on this space. I love talking about automated testing; it feels like a very futuristic programmer practice. I hope this post demonstrates why this work and space is so interesting.
Assuming you successfully did the hard work above, or have opted to skip it... Let's think about the future. Try to imagine where you want to be in 5 or 10 years. What does that look like? Is it an accomplishment? A style of living? A feeling? Freedom? Think however makes sense to you as we all have different sense of what we want. That's your end point that you'll try to target. Try to think of what would have to happen each year, each month, each week to get there. How can you do that sustainably? This is a type of thinking that may be helpful to you.
In my opinion it's good that you're auditing yourself like this. Maybe you don't really want to be doomscrolling your life away. But the hard question to answer is where do you want to turn your attention? What is important to you?
Hope some of this helps.
I know this because I struggle against these "pain during code design" & "get abstractions right" forces when I program.
Declaring types is really declaring what domain objects your program cares about and function signatures are really just describing interactions that can happen. So what 'domain objects' should meaningfully exist in my program and how do they interact? A bad abstraction can burn up a lot of time, so make sure you check your abstraction. I typically check mine describing stories to my friends (or rubber duck) and ensuring I'm using plain English and the other person doesn't get lost. YMMV
When you're doing web client programming you're typically using a library to accomplish work, and much of that work is reacting to user input and rendering data. I would argue that because so much of the linguistic heavy lifting has been done for web client programming, practicing the abstraction exercise is done less than in other programming domains. Doesn't mean it couldn't, just trying to highlight a difference in programmer domains. This is why the pain is more apparent in library programming than web client programming.
I imagine that advanced individuals in code design understand more of the connection between math and programming and are capable of describing systems of interesting work in few simple statements. I hope to reach those heights someday.
They're going to lose that opportunity now. For what? Tighter control so VRchat can engineer their own knock off mods? Greedy. Sad.
Abstract interfacing techniques like base classes, abstract classes, and (my favorite) interfaces allow me to model interesting things.
Thinking about relationships between things in my systems versus categorizing things helps me avoid the "if you want to do something in OOP you must first define the universe" type problems.
DDD and conceptualizing how 'infrastructure' components interact with my main system is a nice guide for me.
Trying to write good tests is how I'm able to bounce around a few projects without having to read source code to reload context.
These are things that work for me. As I continue my practice I may find that I'm wrong or misinformed about some things. I should hope that I'll be able to incorporate a higher understanding as I gain more experience.
Any tips are welcome and appreciated. If not, I'll do heavier research when I am ready to hack this idea into life.
(1) Why do people think subpar programming from outsourcing companies will always hold true? The more business/experience these shops acquire the more likely the engineers develop better software practices. The developers writing crappy code have an opportunity to learn how and why it is bad. Over a long enough period the environment will eventually produce excellent developers I would argue.
(2) What happens to the displaced talent? If big corp decides to slash its talent and compete in the software world with the equivalent of a zerg rush (many outsourced engineers versus one onshore engineer), what if they are really sowing the seeds of their own destruction? If amazing engineer with business domain knowledge and enough to comfortably live on savings for 6-12 months is laid off, perhaps they decide to join a competitor or even start their own competing software?
"We just didn't fit" is a fantastic conclusion.
The ego is one helluva thing, and a hurt ego with negative self talk can lead one down silly paths. OP is cool as a cucumber.
- Unity + mirror (multiplayer library) for the server client. The library documentation will help with a mental model of a multiplayer game. Export the binary of whatever your target OS will be. I prefer linux. - Unity for the game client. I prefer webGL export for the client so I can host the HTML/JS/WASM like a normal static site. However; you can (also) export windows, Mac desktop apps too. - nginx to host the static site and reverse proxy to the multiplayer - systemctl units for nginx, and the multiplayer binary on some linux OS. I prefer Ubuntu.
For the code; it's all about developing a mental model of what things exist in your system and what interactions those things have with each other.
It being me, there is a CICD system somewhere running tests for pretty much anything.
I need to look into if I can back up my digital movie purchases onto physical media. This maneuver is outrageous.
My experiences as a person tell me that people and egos and circumstances constantly conspire against goals, ambition, and vision. There's always something that stymies a project. Maybe it's someone's ego. Maybe it's a problem that drains someone out completely. Maybe it's just a bad day for someone.
When networks of people are able to join together and fight entropy enough to sustain the life of a project... Wow. Just wow.
Anyone who added any type of energy into Linux that sustained it for everyone has my admiration.
By putting out relatively cheap VR headsets and requiring a meta (Facebook) account to use it, they are getting young people signed up for meta. Those young people might not have signed up for Facebook/Meta otherwise. It's a sneaky way to reduce friction and maybe convert young people onto the social media platform.
It also reminds me of how google's social network automatically created profiles on their social media spot. That experiment failed. Will meta's growth play fail?
This is purely me trying to figure out the business angle.
Was it bottom up, with factories competing to make products (trucks, ammo) for lend lease? Basically government used tax payer money to become a big buyer of things, incentivizing companies to reorient towards making those things? And then when the US entered the war, the types of contracts offered changed.
Was it top down, with the government operating more like a command economy telling businesses what to make, and when? It wasn't a choice, it was a demand because the country is at war!
These are two guesses I have. My mental model is based mostly on the movie "War Dogs." I'm sure it's a mix of both bottom up and top down. Maybe with a mix of cocktail parties with important industry business people and important government people chatting about would is feasible sprinkled in.
I do not understand how the war time mobilization of the US economy actually happened. If anyone knows, I would appreciate a summary or a book recommendation. I think I have a topic for my next Wikipedia deep dive.