Don't code, validate your ideas first (to first 1000 paying customers if monetization motivates) and 99% is not even worth to be started with, life is just too short for that.
With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just too powerful today.
This is so much out of touch with reality. You somehow assume OP is interested only in profitable projects and that idea validation is easy. It's not. For technical person it is much easier to code a prototype/mvp than to try to get potential paying customers by any other fake landing page means. 1000 customers? You are dreaming.
> you shouldn't write code until you know someone is willing to buy
This is kind of a weird line to see in a thread where people are talking about coding for the joy of the craft. Also makes me think about where we would be if everyone who contributed to OSS projects over the years thought this way. And to be clear, I'm not shunning or criticizing, having this mindset is totally fine and I'm sure it does well for you personally.
Yeah it's just a totally different thing than what the thread starter was talking about.
This may be good advice for bootstrapping a business (though personally I feel like people who do this are being pretty hostile to their customers by pretending something exists when it doesn't at all, which is not to say it isn't effective) but it is just irrelevant to someone wanting to build something for themselves.
Everything is a hierarchy, even the tags in your mind do belong under some tree/node like imagination. Tag is essentially just what you described "duplicates or symlinks or whatever."
This isn't really true. Even mature, sophisticated attempts at making hierarchical classification systems (e.g. the UDC[0]) don't claim to have created a system where each document gets a unique leaf on a tree, and indeed instead attempt provide some syntax for adding additional metadata into its "nodes," i.e. the nodes become the sum of their tags.
congrats, can't wait when this ships as you'd have pretty much the only mechanical keyboard that follows the macbook keyboard layout on 4 keys left from space and prob would be instant sell to every mackbook owner who likes mechanical keyboards.
the rotary button has no value imho but I can just break this off for the sake of being constant with the mackbook keyboard layout :) cause you know muscle memory
@Jabo although search is really great you instantly know the quality of recipes is "aggregated or marketing" junk when one recipe contains quantities in millilitres, mystical cups and a oven temp in unknown centigrade scale
so heres a idea for you to automatically rate those things by just investigating unknowns and either help them to be converted to multiple centigrade scales, and single/multiple comparable metrics you've achieved the ultimate
you are missing direct links to search results, to single search result and it's hell of a task to find a link to click that opens the little modal with recipe information (click on square should be enough)
Cups, spoons, etc, are convertible to millilitres.
Most recipes call for pre-heated over at 180ºC unless states otherwise.
Cooking does not observe reproducible builds. You always, always needs to taste, poke, look. If your flour is of a different type of grain or not as fine, if you use different varieties of vegetables, or if your kitchen is a few degrees warmer or cooler, you WILL get different results.
So go ahead and use any mystical cup you want. Ingredient proportions are what matters. If you fail, write down what went wrong so you know better next time.
I've been cooking and programming for a long time now and wholeheartedly agree with everything you said except the default oven temp thing. Baking is a cargo cult of chemistry and I'd say most folks are well advised to follow those recipes exactly.
>> quantities in millilitres, mystical cups and a oven temp in unknown centigrade scale
As somebody who likes to cook and has not the slightest idea of what Farnheits, Ozs, Yards, Feet, Gallons, are, nor anything about how Freedom Unit Related & Co. converts to simple decimal metric measures, you are speaking Klingon.
just take the science out of it, carseat for a kid does nothing more than to rise them to suitable seatbelt height or makes the seatbelt usable for really young kids.
Isofix does not have to have a leg etc could be just bars holding the seat at place, thats its only benefit it keeps the object attached to isofix in place in case of a accident. It will not fly around the car as it is attached to it thus provides more safety.
At the end if the crash is huge then newtons laws apply a bigger mass will just run everything over, does not matter if it is secured or not you just can't beat a bigger mass.
For every action, there is an equal and opposite reaction. If a customer can ask anything then a company asked can ask anything in return and if you send those out "en masse" you just become a subject to GDPR yourself.
this is a narrow view based on someones versioning habits , the point of rebase can also be a solid linear history that allows multiple teams to fork and pull request features between forks. If developer chooses to play merging inside his own repo, fine but as soon as you have large teams working on their own you will end up in merging hell between developers and teams.
say team a does 58 commits per day has 75 team-members and team b has 126 members that are doing 187 commits per day and there's team c, d , e .... n giving non conflicting input to your codebase.
the flow in this case would be to always rebase developer specific features on non-conflicting codebase before you are allowed to pullrequest your changes to central repo. Rebasing to master or to any feature branch developer needs to work will allow them to see any conflicting changes they have made directly in their repo (rebase conflicts and a way to solve those as they know what conflicts, they have introduced the conflicts) instead of merging it together and finding out that the repo they need to PR this stuff will utterly fail cause they are lagged behind or several developers have changed the same files.
in this case rebase flow brings the shit to developer to handle and gives them knowledge that it will break. This mainly happens cause they are not having the latest version of code whereas merge strategy will merge in the conflict and send it to others to discover that thy can't merge any more cause of other developers conflicts.
Merge strategy is not suitable in case where code is edited rapidly daily and some features take , weeks, years, are to be included. Whereas rebase strategy ensures that every developer will always send you changes that are not conflicting with up to date version of whatever is versioned.
With AI there's nothing to be ashamed of as it is "what you can dream of, you can get today". There's not much left in programming in most of the projects (that are just repeated code, output, what not over and over) after AI , tools are just too powerful today.