bytasv

We’ve been building Design/UI development app with first class support for code generation (react + next) - https://www.kubi.design

It’s UI/UX is pretty similar to Figma (you can import from Figma). We do support integration of your own design system, that means that you can use actual code components in design canvas with all interactions and business logic. (Currently we have integrated Ant design and Mantine libraries)

We are looking for beta testers who want to speed up UI development or simply save money on FE development.

Even if the process that they have is working it doesn't mean that it can not be improved. And if you obviously see the parts that could be improved because you already stepped on the same rake many times why not do that? Ofc as a newcomer trying to change things you are always gonna be welcomed with strange looks but that's another side of it - how to implement the changes so that everyone is happy...

@1. You don't need threads if workers are enough for you, that's how you should do computation intensive tasks...

You might agree with the author if you are working with self-managing team where everyone is capable to deliver something daily.

But more often that's not the case:

1. "Members of the team already know what I did yesterday, because they can see the completed items in the "DONE" column on the Scrum Board." - this is not true, because in case someone is a slacker in a team and does nothing you won't be able to track that, you can't see progress of "doing nothing" unless two days in a row you hear the same person still "working on the same problem". Everyone who participates in a stand-ups knows that bad feeling when you are on a standup and you don't have to say anything about what you have done, you force yourself to fix that because that embarrasses you.

2. "This question is a little maddening, isn't it? I can tell you what I'm planning on doing today, like maybe finishing the task that I just told you I was halfway through, and then grabbing the next..." - this is to prevent multiple persons on jumping the same task, that's your daily planning.

3. "Waiting for the daily stand-up is a terrible way to deal with impediments." - again, nobody forces you to wait for a standup to deal with problems that arise, this is used to explain why were you spending so much time on fixing some small bug. For example - you spent whole day trying to fix a bug, but the fix itself was a "one-liner". After looking to your commit I could make a false assumption that you were slacking the whole day and only made a single "change" where on a standup you have time to explain what problems forced you to spent whole day on tracking down that bug... Another example - someone spends whole day on a feature but still doesn't finish that even though it's trivial to implement, he might either explain that he faced a problems that prevented him from implementing that feature faster or he won't have anything to say because he was slacking

Is "Countries represented" only from W15 or overall? If it's only from W15, could it be possible to know the list of all countries represented since the beginning of YC?

I'm also using it but only on a side project. The primary reason for choosing ESLint over the other two is ability to create your own rules.

I think that whatever style rule You set you should be able to add rule for that or else nobody will care about it.

Talking about other two: - JSLint - is too restricted (heard many calling it too Crockfordish) in many cases and You don't have much control on how one should write code - JSHint is much like JSLint but with a much more options to customise how You want to write Your code

It would be really interesting to see the same test done with 2 and then maybe 3 dynos running. I'm wondering how well would that scale with more dynos running. Is it possible to buy dynos for shorter time than a month?