HN user

ablanco

105 karma
Posts4
Comments19
View on HN

I think there are two main reasons to download from yt. The first one is that a lot of music is only available there. Services or torrents are not as vast as one would like when you are looking for something specific. The second reason is that services that provide offline usage are cumbersome to use in certain escenarios; eg: old car stereo

I'm using it to port an auv3 plugin to a standalone app. The overall experience is amazing when compared to the constraint based method proposed in previous xcode versions. There are parts missing, but it's fairly easy to wrap uikit components and use them in swiftui

Overall I think it's a great step forward

this looks amazing! (beware on mobile for giant gif size)

SwifUI is a breath of fresh air compared to xcode builder, that giant unmergeable xml and the constraint madness where really clumsy to work with.

I don't agree at all. The reasons in the article all seem like "envs are bad because if you make a mistake you can expose them". This is not exclusive to envs, it applies to all secrets, independent of the medium used to make it available to the process using it.

In my experience, if you prevent using envs for secrets (as docker swarm does) all you get is a disgruntled programmer reading the contents of a secret file to an env in the entrypoint.

In my point of view, most programming stacks are as hard as understanding the context they are planned for. Eg, It's much easier to learn a new JavaScript novelty ui framework knowing exactly where this piece you're writing will fall into. If you know the bounds of something it's easier to fill in the gap.

If you are learning frameworks just for the sake of it you'll have a hard time building something real.

I don't think this is a problem with git-flow, it's more a problem of using git-flow when you don't need it.

I use git-flow on projects that need to be installed by various different clients and there's no way to force all of them to migrate to the latest version, so you have to maintain support for older releases.

When the software needs to be installed in a single place and you can do it with CI/CD theres no need for the git-flow complexity.

I think this is a discussion about building stuff.

When the idea is just taking form I think getting too many people involved is a mistake. All you need is 2/3 people really invested in the idea. For example: unix

When the idea is near completion I think it's really good to get all the feedback you can.

Don't get me wrong, if you are to measure success by the money you raise, then I completely agree with you. I meant thinking of an app as a mean of expression rather than a cow to squeeze money from. If you want to make something more in the arts department, getting people to tell you what they think early on might be a horrible and non constructive idea.

I don't think this kind of reasoning applies to all projects. If you're doing something without the pressure to make money you can make something that you're proud of. Of course, this can only be a side project unless you're already rich. The one thing I know is that if you don't love what you do, it's the same wether you own some super hot startup or you write forms for some accountant firm.