I'm surprised you're getting downvoted. Running youtube costs money, some creators spend a lot of time or even make a living out of their videos, that we, the users, willingly enjoy to watch. Youtube (just like Nebula) enables us to watch content we like, and helps funnel some money from the users to the creators.
The whole tracking industry sucks, contextual ads seem acceptable as an alternative to payment and still protect privacy. But there is no free lunch
The first thing I would advise is to be as transparent as possible with the founder, you can't go on like this. Don't go in as the whole team, it'll probably be a hard time for him, you need to break the news but let him time to digest before going into the details. Keep in mind without him you probably won't be working together on this great product.
I see 3 probable outcomes:
- he does not see the situation as you do, but does not want to leave. this would make leaving the company easier for you if your disagreement is too profound.
- he understands the misalignment won't be solve and quit (either by choice or following investors pressure)
- he agrees to try to change things, this will be hard because it won't happen instantly. Your team will need to set checkpoints with dates, which if not met bring you back to the start.
Anyway for your own mental state (and your teammates) you cannot go on like this.
And still there is a 'follow us on FB' button on the EFF website and this specific page, which acts as a tracker (and as such gets blocked on Firefox).
However since the moon period is not the same as a GEO period, maybe the fact that you could juste 'catch' the end of the cable before falling back to earth without having the speed to maintain at GEO could help you save some delta-v.
Without considering the fact that the orbit of the Moon is not circular, this only helps reduce the delta-v needed to go from the surface of the earth to the surface of the moon by ~3.2km/s, but we still need ~12-14km/s to go to GTO/GEO.
The point was to illustrate the fact that 'world domination' is a strange word to use when comparing against 3 countries only, leaving aside a lot of well educated students, some of who ranked as the best of their field - for instance korean and french students in ML.
Plus the fact that the US dominates the tech sector has more to do with the available capital there than the technical skills of US students (on average)
meanwhile European CS students, with their fellow students from the UK, Switzerland, Korea, Japan, [add whatever country you like except the 3 which are - on average - worst than the US in CS) are busy getting even more better than the average CS US student
- 1 & 2: just use virtualenv, js has its own version manager too (nvm) which is very useful. This is one of the reason why only python2.7 is included in OSX, since most of seasoned python devs not use it. usr/include vs usr/local/include in cpp are not easier to use / understand.
- 3: my opinion is this forces you to write readable code, in which you don't have to ask yourself where the scope starts / ends
- 4: since import use dot notation you just need to follow the path until you find a file and in this file the corresponding function. Or read the doc. Or use an IDE with autocompletion. Looking a .h files in c sometimes lead to using a wrong function judging only by its name.
- 5: They are called "list" because they are lists, not arrays in a C sense (size not fixed)
- 6: multiline strings are a mess indeed, but python3 handles them all in utf-8 (one of the reasons why it broke backward compatibility)
- 7: just like js, making them 2 of the 3 most used languages. Understand the difference between pointers and references is harder to grasp for a beginner to just remind modifying the arguments of one method is dangerous unless you know what you're doing
- 8: there is the from ... import ... which allows you to avoid this while being explicit
You have EU funds to help bootstrap your company, either directly or via subsiding the institution which is funding you (even if it can be harmful), cheap or even free medical services for when you're getting sick and you don't have any insurance since you've put all your money in your startup. Allowing people to come to work for you without having to handle the visa nightmare means you're not giving them insanely hight amounts of money every months. Price for incorporation is <1000$ in almost every EU country. Your employees don't have to pay taxes on stocks they haven't sold yet. There are some upsides too.
Totally agree with you. There is a huge benefit having a clean API which works for a variety of clients (native / mobile / desktop) and a corresponding variety of team members instead of maintaining 2 different view sets on your backend, without even talking of the specific issues you can find yourself in in web development (browser specific features / inputs / styles / ...). And you still can't do any real native apps.
I'm not sure this is a fair comparison though since PMs usually are experienced when junior software engineers are common, and even more you can have SE switching to PM roles but the opposite is quite rare. But the reality remains that is way more difficult to find a good PM than a good SE.
Graphql and apollo add some overhead to your queries, both in your client and your API. And since you're still performing a POST query with each graphql query it's kinda logical to see that pure / well designed REST can outperformed graphql (if you know exactly what you want to return you don't have to run through the graphql schema / node / resolver to get the value your looking for)
as sgdesign said, you can write your own resolver function (which allows you to retrieve a particular field deep in the nested graph of graphql). It's very easy to create decorators to handle the usual permission cased on the field level.
One important thing to note: performance-wise, both in front-end when used with apollo, and in backend (you need to handle nested queries smartly) a good implementation of a REST api would probably be faster / lighter, but it should be largely enough for any web-app / web-service used by human beings ;)
I'd like to add that correctly designed resolvers allow you:
- to control very easily who can fetch what where it's fetched (permissions)
- to fetch nested data when you need it without writing serializers
- to help your frontend team find what they are looking for without asking the backend team everytime
- mutations are a huge plus when it comes to standardization of your API too
FYI we're using it in production over a django backend (which comes with some drawbacks, since subscriptions == pushed updates are not perfectly implemented) with our react/apollo apps (web and native) and in my opinion the overhead lies surprisingly more in the frontend side (writing data connectors is longer, but way more explicit, than using rest queries returning json)than on the backend (where you just declare resolvers, a thing you don't even need to do in nodejs) and handle permissions.
I definitely don't think official software updates could be made not reversible. And worst brick a perfectly fine device. Would love to hear from the ppl downvoting too.