231–240 of 362 posts
There was a project called Radio Receiver which used an RTL SDR, but it is a chrome app and chrome apps are pretty much dead.
Earlier quoted context omitted.
Why do you think AR will become a "thing"? Do people really want to run around wearing glasses/headsets all the time? If you'd ask me, this idea could just as well end the same way as 3D TV.
I actually think ARkit will be big precisely because it's not a headset. You can just hold it in your hand. Imagine the Metaverse exists, fully fledged, and there are two products which can access it: 1) A headset that you strap on your head, and you're "inside" 2) A picture frame that you can hold up and look through, and the Metaverse appears on the other side. You can reach behind the frame with your other hand, a…
Much of what people have mentioned here will be really great. I think self-driving cars have the most potential to impact people lives day to day, followed by AR. I guess infinite, cheap, clean energy could also spark another industrial revolution. But all these things aren't likely to impact the happiness and life satisfaction of those living in the developed world. The internet has been huge, but it really hasn't m…
Serious question. Has any technology done this?
We don't appear to be happier than any other animal. Even in the developed world plenty of people are downright miserable.
Unless primitive humans were just far sadder than the average animal, I can't see how technological advancement has made us happier as a whole, because we're not all that happy.
If antibiotics, electicity, and the steam engine didn't noticeably move the needle, it seems absurd to expect phone tech to do the deed. Whatever technology is solving "for the whole", it's not happiness.
Without doubt, GraphQL is the next technologo I will learn. The idea is so brillant compared to REST. If you are convinced by SQL and in general by Domain Specific Languages, I think you should give GraphQL a try.
Forgive me if this sounds hyperbolic, but unless you have unusual or strict requirements, building a new app in 2017 REST-first is most likely a terrible mistake.
Let me clear up some misconceptions I see in almost every HN comment thread on GraphQL:
1. GraphQL isn't more suited to Graph databases. Your data sources can be a mix of relational DB, NoSQL, key value, a REST API, or anything else.
2. n+1 has always been a solved problem in GraphQL thanks to DataLoader[1], a query batching utility which coalesces calls to your data sources from different parts of your app, specifically to avoid n+1.
3. It's unquestionably production-ready, battle-tested, has a real spec and official reference implementation, and it's probably the safest bet you can make at this moment in an industry as fickle as this.
With GraphQL you simply write your schema, define types and relationships, and you’re then able to request data in almost any shape you wish, with very little extra work. This is invaluable during development.
If you have a list of recent comments with author names, and later decide to show an avatar alongside the name, you don’t need to write any extra code on the server. You add an extra line to your query (or component’s fragment) on the client.
The same goes for any field, any relationship, no matter how complex the resulting shape. If you wanted a comment author’s follower’s comments’ likeCounts, you still don’t need to write another line of server code.
This makes it stupidly simple to rapidly prototype new features, try out new layouts, and means you can share a single API endpoint between mobile apps and desktop site without sending useless data to one or both.
There have been many occasions when we simply wouldn't have had the time to implement a feature correctly with REST, particularly when we might not even know what data we'll want until we begin developing the feature and get a feel for how it works.
It doesn't just save server dev time either. On the client side there are libraries like Apollo[2] and Relay which take care of fetching data, caching, normalization, and you should almost certainly use one (I recommend Apollo) unless you have a good reason not to. Writing fetch calls and managing your store manually is just going to be a huge waste of time.
And the spec is more than queries and mutations. It's subscriptions, live queries, and more [3]. Real-time data is a first-class citizen of GraphQL, and the two most popular front-end libraries have official implementations of subscriptions (with live queries in progress).
GraphQL is elegant, has a well-designed official spec, great DX and just plain makes sense. But it's really something you need to try out for yourself (preferably on a real project) to see just how great it is.
If you’re planning to build something new with REST, seriously, reconsider. There's a slightly higher upfront cost to using GraphQL (particularly if you're new to it), but once you settle into it you'll be glad you did.
Useful tools and resources:
- GraphiQL[4] - an incredibly useful tool for running queries on your GraphQL API
- Graph.cool[5] - BaaS for quickly prototyping a GraphQL API
- Apollo Launchpad[6] - Try out GraphQL server code in your browser
[1] https://github.com/facebook/dataloader
[2] https://github.com/apollographql/apollo-client
[3] https://dev-blog.apollodata.com/new-features-in-graphql-batc...
AR. Being able to superimpose software on top of real objects is amazing. It has so much economic potential that it hurts not being in the space already (working on that though). I feel AR will be the app craze 2.0.
> It has so much economic potential that it hurts not being in the space already (working on that though) As someone not familiar with the area, could you elaborate on some examples of what you think the economic potential is? To an outsider like me, being able to overlay virtual objects on a scene seems like a nice curiosity, not particularly an engine for commerce. Edit: specifically, I was curious about areas wher…
Use cases in industry abound. On a trip to the doctor's office, your physician can overlay your medical file and get pertinent information about you. If you are a politician holding a fundraising dinner, AR + facial recognition will supply you with the biographical information, social media profiles, voting records, donation history, etc. of the people in the room allow you to schmooze ever so effortlessly and ever more efficiently. AR tailor made for athletes could do a number of physiological measurements like heart rate, VO2, etc. (with wearables or implanted sensors) that could combine to produce some sort of stamina bar, allowing for more effective substitution patterns. An activity like paintball can will feel closer to an actual military engagement or a video game if a minimap that includes your teammate's location will be in the corner of your vision.
The Terminator franchise did a great job of showing it's utility by giving Arnold "Terminator vision" in shots from his POV. Video games also make extensive use of OSD. A 1st person shooter's OSD really shows the advantages of AR.
Advances in computer vision and networked IoT devices will be a multiplier for AR's utility. Imagine an app that overlays your vision with the mathematical patterns of nature: illustrating the Fibonacci sequence in the leaves, petals and seeds of plants or in the way tree branches form and split. It could highlight all of the phenomenon that exhibit golden ratios. It could show the equations of motion for objects moving or spinning in your field of view or detail the biomechanics of the elegant dancers of the Bolshoi ballet. In a way, you get to experience what the mind of a Leonardo Da Vince or John Nash might be like, like you are able to get an insight into the mind of a genius.
Much of what people have mentioned here will be really great. I think self-driving cars have the most potential to impact people lives day to day, followed by AR. I guess infinite, cheap, clean energy could also spark another industrial revolution. But all these things aren't likely to impact the happiness and life satisfaction of those living in the developed world. The internet has been huge, but it really hasn't m…
Earlier quoted context omitted.
From crystal-lang.org, Crystal is a compiled language I never understood the phrase compiled language .
A compiled language uses a compiler to create a executable binary as opposed to a runtime that interprets or just-in-time compiles the language as it runs. Ruby is interpreted, C is compiled. Generally speaking, compiled languages are more performant but lack some of the flexibility of having a runtime available. Crystal sacrifices some of Ruby's metaprogramming capabilities for performance and static type assurances…