As the first comment there points out, a 96% accuracy doesn't mean much without knowing the false positive and false negative rates.
I have no doubt that this is good work in the right direction - but the headline alone doesn't make it a home run.
1,115 karma · joined March 13, 2009
I have no doubt that this is good work in the right direction - but the headline alone doesn't make it a home run.
Right now, PWAs will not replace native apps in their current form. In particular:
- Companies want to have an "app" in the "store". The app store is a huge search engine, and if you don't have an app in the store, then you're missing out
- iOS limits the amount of offline storage you can have, and will just start deleting your data if you go over the limit, so you can't reliably store offline data
- There are a bunch of APIs (especially on iOS) that PWAs don't have access to (there are a number of sites that show that, including the ones the author linked to)
So: PWAs are ok for some things - but will in no way replace native anytime soon :/
Definitely excited to check this out; thanks Jeremy and Sylvain!
If you know JavaScript and want to make mobile apps, give React Native a try! It’s a good choice for most business apps, and even some games.
Also, if you like videos better, there is a huge collection by him on https://nutritionfacts.org/ - searchable by condition (like "cholesterol"), or on his youtube channel: https://www.youtube.com/user/NutritionFactsOrg
Spoiler alert: all of his conclusions boil down to just a few things:
- don't drink calories
- eat less processed food
- eat less meat and dairy
- eat more fiber (beans, greens, fruits, veggies)
(check out the recent videos on that channel as well - he's just done several videos covering scientific studies about all types of fasting!)
In just two months 65 groups have gone live, with over 450 people signing up - which I think is pretty awesome!
From a technical side, it uses Rails 6 with React for the tricky UI parts. ActionText is probably my favorite new rails feature for the rich text boxes - it was super easy to set up!
Once you're established, I find that people don't think about "finding new clients" so much as "winning new contracts" - which (as you point out) - is entirely different.
If you're trying to win big projects (vs "find clients"), you probably have a small team already, and then yes, that's when you really get into RFPs, etc.
In the beginning though - I would advise against going after big projects that need multiple rounds of selection, etc - and instead focus just on relationships. Then, once you have a small base of clients, you can decide to go bigger from there.
Generally, small airplanes are moved around a lot more by wind gusts - which means some people get really motion sick in smaller airplanes. That could be quite a shock for people who are used to bigger airplanes.
Does anyone know how these really small multi-rotor air taxis are with turbulence?
https://www.youtube.com/watch?v=-J_xL4IGhJA&list=PLE18841CAB...
One of the things I liked about meetup was that many (most?) groups were hosted on it, but I think what this has shown is that meetup had a kind of monopoly in that way (which wasn't good!)
My plan is to charge organizers (like meetup does today) to cover costs - but never to charge members to attend free events.
I've been looking for a solid project to spend time on, and this just became it.
I put up a landing page this morning, and I've already started coding:
If you store some state in JS variables, and some in the DOM (forms), then that's not true anymore. That's not necessarily a problem if you're expecting it (uncontrolled components are a valid React paradigm) - but if you're expecting controlled components, but some of them aren't, then you can run into trouble.
Also, once you're used to controlled components, it actually feels like a hassle to keep the data in the DOM - you have to constantly be getting it from the DOM to do form validation, submitting, field resetting, etc.
Again - I would say that neither is more right or wrong; but it's more of a style choice.
> "I have no desire to become a professor/researcher"
I don't have a PhD, but my take is that if you don't like/want those things, then a PhD will be a big waste of time.
It sounds like you're in a situation that you don't currently like, and are hoping that a PhD will help solve that for you; but I suspect that you'll find that being in a PhD program will feel like more of the same.
Also, if you have published papers, and keep up with current research and publishing papers, then you _can_ go get a PhD after being in industry for awhile if you think it was a big mistake. You don't have to do one right after a masters.
I hope you figure out what you want to do - And good luck with whatever you decide!
I tried to do some research into this awhile ago. What I found is that you (generally, kind of) are able to use copyrighted work to make another work as a "transformative work". For example: you can look at an image of a person and use that as _inspiration_ to draw the same person (as long as you aren't tracing). However! that's still kind of a gray area.
ALSO: how does that apply if you are using the exact pixels of 1,000,000 images to make new ones? I don't think anyone has a definitive answer yet.
My guess is that it will have to be decided in some high profile court case before we get real answers :)
That said - if you're not familiar with the JS ecosystem (node_modules, etc), then it can seem a bit overwhelming at first, especially when you encounter configuration or build errors. I don't have any great answers for that except that "it gets easier" with more time and practice.
Also, if you haven't looked at React Native for a couple of years and had a bad experience before - try it again! It's come a really long way in just a few years.
For example: I used to have to worry about cross platform code/libraries working on iOS and not Android - but almost never run into that anymore.
I can still try to answer the staging question though:
So - once you create a commit, it's in the repo forever, so with staging, you can gradually build up a commit without doing it all at once (adding one file at a time, over time for example). You can also stage just part of a file (just a few changes), and create only the commit that you really want to go into the repo.
I suppose it's kind of like a "commit preview" that you build over time.
In practice, a lot of people do just add all their changes and then commit immediately though - so yeah, in that case a staging area doesn't make any difference :)
- Mercurial is similar to git in that way, but "fully featured" is supposed to contrast to other systems like SVN; the point is that there is a full git repo on every developer's machine - you're not just connected to a single central repo. So when you commit locally, you're actually committing into a repo that has all the power that the remote repo has
- Correct, HEAD is a special place on the tree, but I included it because you'll see and hear all three terms used nearly interchangeably.
- I could have explained stash a little better probably, but the "crash" course was already getting fairly long ;) Stash is a place to put work in progress, and some developers use it more than others. It's a bit of a "special" place (even though it's technically part of the local repo)
- I agree with the last point: mostly, this guide is for devs who already use git and know what 'pull' and 'upstream' mean, but are perhaps confused about the exact mechanics of how to "get files down" other than just cloning repos and checking out branches.
Hoped that helped clear a few things up a bit! Thanks for the feedback
And I could really see a use case for when bandwidth is a problem for true video calls... next to full video, streaming the avatar info would be next to nothing - so it could turn "video" calls into basically just the audio as far as the internet connection is concerned.
Awesome!
1. Find something you want to play around with; for me recently, that was React Hooks
2. Start a codesandbox (I guess that only works if you're doing web dev stuff though), and just start messing with the examples from the tutorials
3. I almost always find something I want to explore further during that step, so then I take it offline and start a larger project
So I guess my advice would be: start small; even smaller than you think you should start (i.e., don't come up with a whole project to do - just "mess around" with the tech/idea in some small way first).
Then eventually, you'll get ideas about what you can try out, and what you should break off into a bigger chunk and try as a larger (but still small!) side project
1. Hang out online where people talk about new technologies. For me, that's HN, dev.to, and twitter (only works if you follow people doing cool things in tech)
2. Try out new technology by doing _small_, mostly pointless, but FUN little projects. That way, you don't have time to "get bored", because they're just little fun side projects! Also, you don't have to worry about them "scaling", etc - because you can just tell yourself that it's just a silly little project. But after several of these silly little projects - you'll be surprised at how much you've learned, and actually accomplished!
It walks you through all the basics of deep learning (with PyTorch) with a concept video, code video, and then suggested project for each week.