11
votes
Fortnightly Programming Q&A Thread
General Programming Q&A thread! Ask any questions about programming, answer the questions of other users, or post suggestions for future threads.
Don't forget to format your code using the triple backticks or tildes:
Here is my schema:
```sql
CREATE TABLE article_to_warehouse (
article_id INTEGER
, warehouse_id INTEGER
)
;
```
How do I add a `UNIQUE` constraint?
For people that are working on projects solo and using version control... do you follow the convention of creating a branch for each "feature" you're working on? Or does everything happen on the master branch, for you? All of my projects are pretty much solo, at the moment, but I'm still trying to think about and follow best-practices.
Feature branches are a good idea even for a solo project. Ideally you would commit smaller changes as you progress and then merge the final result once the feature itself is completed and validated. If at any point in the middle of these smaller commits you decide that you don't want the feature, are unable to implement it due to some fundamental limitation, or need to switch to a higher priority task, you don't want to have to manually roll back these changes in the master branch. If you have it done in a feature branch then you can just abandon the branch and optionally return to it later.
In other words, feature branches give you the freedom to abandon or postpone changes while still keeping them tracked via version control. Definitely use them.
I generally only create a branch if it's a larger change that's going to be a longer-term project, or something that I otherwise expect could be interrupted before I finish it. If it's the only thing that I'm working on and I'll probably finish it within a couple of days, there's not really any significant benefit from a branch.
Even if I do end up needing it to be in a branch after I've started, it only takes a couple commands to "move" it, by just creating a branch off the
masterstate and then resettingmasterback to the previous commit. So it's really not a big deal either way, you can always switch.I think that the best answer to this for small projects is to do what feels best to your brain. If small features live in branches, and that's the way you think (it's the way I think) then it's a good idea to make branches for things. If that feels like unnecessary work, then don't do it. The important thing to remember is that "features go in branches" is a guideline because for a non-trivial number of developers, that actually aids development; it's not done just to impose nonsense rules on people. But it's also just as important to recognize if that is something that resonates with how you do your work; the most important thing is that workflow is effective.
A lot of people on both sides of this issue forget that the only important thing is that workflows are effective. They end up loving the workflow qua workflow, which is dangerously stupid.
There are a variety of reasons that I find features in branches effective, and why I tend to do pull requests for my own work, even if I'm the one reviewing them. I like to see what a patch in its entirety is doing to a codebase. It's possible to do this without using a branch and a PR, but using a PR makes it trivial to do this review. Before merging something in, I like having the "okay, now actually review all the things you actually did" step. I also tend to work on multiple things concurrently; I might be working on Feature A, which is not trivial, and have an idea for Feature B. I'll switch to different branch, and outline what I'm planning, then switch back. It's an organizational tool for me.
I find that using feature branches adds friction to the development process, so I avoid them for small projects and spikes. There are various ways to reduce that friction through automation (e.g. git-town), but even then it's not worth it for personal projects, so those just get developed on the main branch.
I do use feature branches for professional work (even when solo), because often several different features will be in flight at any one time, and having them separate makes things much simpler when it comes to selectively deploying to staging or production environments.
I guess I could use feature-toggles instead of different branches (which is what Trunk-based development advocates), but that comes with its own headaches and is mostly meant for many-person projects.
For super small projects I work directly off of master, for larger ones I just go master > develop > sandbox and merge up as needed, and split off big features from develop when needed.
Depends, mostly only when I'm trying to develop two different features in parallel, which happens if one of them is large, or sometimes when I'm switching computers and don't want to commit and push for some reason.
Just started learning rust and I'm wondering what the recommended way of indexing the same data in several different ways is. I want the data both in a linear fashion on disc (using Vec atm) and in a recursive fashion for easy traversing. How do you handle referring to the same item in two different places? I tried putting the data in the tree hierarchy as references, while the actual objects are stored in the linear storage for faster iterations, but I need to do lots and lots of lifetime hints everywhere, am I going about it in the correct way? I want everything to have the same end of life, i.e. it should stick around until the program shuts down.
(Very late response, sorry!)
A commonly-used approach to this sort of problem is, rather than storing references, to place your actual items in a
Vecand then store int indexes into thatVecin your other structures. This is definitely not a perfect solution (you give up all ability for the compiler to check the validity of your indexes, because they're just ints, for instance), but completely sidesteps lifetime issues.An even later response to your response =)
I appreciate the tip even though it's not perfect, a lot of learning a language is learning the best practices and common workarounds for the problems that exist with that language (and there are problems with all languages). I hope these kind of "cheats" aren't too common in rust as it would completely remove the point of using rust for me. But as long as they aren't too common it's good to know =)
As a comment to OP, sql dialects vary a lot, what database are you using? (Assuming it was a genuine question and not just an example =) )
Haha, perfect. I thought it sounded like something that'd be very easy to look up yourself =)