When we set out to build an auth API, one of the first big challenges was just wrapping our heads around all the various acronyms and protocols. Despite the existence of standards like OAuth, OIDC, JWTs, SAML, etc., authentication is anything but standard. As hobbyist devs, we wanted the interface to be simple. RESTful. Leverage HTTP verbs. We wanted an auth API that we wouldn't have to think about and would save us time.
After a lot of consideration, we settled on creating an abstraction for /credentials. With this, we've been able to abstract away sign-in flows for email+password and passwordless auth. "Just create a credential!" As Josh Bloch once said, “Good names are the API talking back to you”. We're super glad with how credentials abstract turned out. In the future, we plan to extend it for supporting protocols like OAuth as well.
Feather has saved us a ton of time while building other projects these past couple months, and we're happy to share it with everyone today :)
wow, just reading that term "line of business" makes me anxious. I used to work on a global payments platform that supported "multiple LOBs", and it was a nightmare of ifs and switch statements all the way down. The situation was made more difficult by the fact that our org couldn't standardize the LOBs into a common enum.
If you're in the "talking with customers" phase, you should also check out "The Mom Test" by Rob Fitzpatrick.
http :// momtestbook .com (EDIT: I just noticed this is an http site... breaking up the link into pieces for now. Sill recommend Googling the book)
The tldr; is that as soon as you tell someone about your idea, it's going to bias their subsequent answers. They're going to lie to, try not to hurt your feelings, want to get rid of you, etc. So if you're trying to validate an idea, the most important rule is "Don't talk about your idea".
What "The Mom Test" recommends is to instead ask prospective users about their lives and specifically to recall individual moments when they had the problem your idea will supposedly solve. With this "unbiased" recollection, you (as the entrepreneur) have to put 2 and 2 together to figure out if people 1) really have a problem and 2) are open/looking for a solution.
My friend and I got really frustrated with existing authentication providers like Auth0, so we decided to create API called Feather to make it easier to add authentication to our web/mobile apps.
Still quite a work-in-progress.. but currently designing a stateful React library so that you can drop sign-in, sign-up, forgot-password, session-management, etc. into your app with ~10 lines of code. Plus it comes with a nice admin dashboard for user-management built in!
Hmm that's a bit disappointing.. I feel like Ive and Cook could be wrong on this one. If desktop/mobile is an appropriate parallel, then it seems like they've decided to undercut their desktop machine to have the "ergonomics" of a mobile device while still not being mobile. If the VR headset is a stationary experience, then what's wrong with having a hub sitting around nearby?
I’d guess the AR headset is more interesting to Apple and probably not a stationary experience.
The goal is new UI extension of iOS similar to the watch. Eventually making it so you don’t need to pull out your iPhone to interact with software (and the world) at all.
Probably at first will be notifications and such. No idea if there’s any truth to this video, but it makes sense to me that Apple would focus on this as the next platform when the hardware becomes possible: https://www.youtube.com/watch?v=r5J_6oMMG7Y
I think there’s huge potential for a massive shift in capability if this is done right.
100% spot on that the external distractors are easier to manage than the internal ones. A buzzing phone, tempting social media websites, and loud rooms all tend to be relatively easy problems to fix. As for internal distractors, I feel like telling a personal story after reading this.. There are two internal distractors I've recently noticed myself struggling with:
1) A busy mind.
I often find my brain meandering on ideas or conversations completely unrelated to the work I'm trying to do. Daydreaming, imaginary arguments, and unnecessary tangents all tend to creep in (esp in the afternoon for some reason). I'm glad this post touched on Zen Buddhism and the beginner's mind. At risk of proselytizing, I have to say the best way I've found to manage a busy mind is through meditation. Consciously setting aside 10-15 minutes everyday to practice letting go of thoughts has helped build a (tiny) mental muscle which I can sometimes use to bring my focus back on the things in front of me.
2) Alcohol.
This is a bit of an external distractor, but also an internal one. In college, I was able to stay up all night drinking and coding. No longer! I find it amazing how insanely less productive I am even after a single glass of beer. I now get tired shortly afterwards and have immense difficulty focusing. Perhaps as the article mentions, the alcohol is wrapping up my ego in the task at hand. I don't have a drinking problem, but I now solve this by consciously deciding how to spend my next couple hours. "Am I going to grab a drink and take an extended break (perhaps for the rest of the day)? Or am I going to grab a water/tea and continue working?" Gone are the days when I could reliably reach the Ballmer peak (https://xkcd.com/323/).
For alcohol, throttling the bottles worked for me. I consume one particular day of the week instead of any random day. I consciously say no to any urges/temptations in between. This has helped me to control my habit.
For controlling distractions, other hobbies like music or something else apart from programming keeps me ticking.
For internal distractions - I agree with the post. Separate me from problem I am trying to solve.
I've found that I almost can't program anything sensible after even very small amounts of alcohol, even half a beer or 25ml of vodka is enough. It's either alcohol or programming for me. I don't drink too often, but when I do, even after large amounts I don't have hangover and I remember having memory loss only once.
One of my teammates said he thought he coded best with a slight buzz, but who knows - maybe he was just creating tech debt and vulnerabilities at scale.
For me, having one beer when coding helps because it removes my discomfort of sitting in a chair for very long. If I've been sitting for a while and coding, my mind is willing but my body is complaining about the discomfort. A bit of alcohol goes a long way to help that.
Interesting. I'm in my 50s, and I've found the Ballmer Peak to be a real thing for me ever since college. It's consistently been 2-3 beers. More than that brings a very steep dropoff in productivity, but I wonder if those 2-3 beers are de-egoing my programming. I suspect in my case they are.
This is interesting.. I've never heard of the term "tacit knowledge" before, but it makes a lot of sense to me. It particularly reminds me of my experience being on-call at my last company.
Our systems were pretty unstable, and the most stressful part of the job was getting paged at 4am when everything was falling apart, customers couldn't use the app, multiple analysts would be sending messages asking "what's going on?", and as the on-call engineer, I happened to be the last line of defense (the system wasn't managed by a devops team).
In that moment, there's a lot of stuff that has to be done quickly:
- orient yourself and figurate out what's going on (even in a sleep-deprived state)
- prioritize mitigation over root-cause analysis
- communicate early and often with the stakeholders present
This isn't stuff one can pickup by reading a "runbook". It took years of working with the systems, absorbing knowledge from my senior co-workers, and learning from past mistakes to get to a point where these priorities became in-grained in the way I approach outages.
So from my own experience, I would disagree with the definition that tacit knowledge is purely muscle memory or that it can't be improved. One's mindset can certainly evolve and I would consider that as "gaining" tacit knowledge.
I would even say something like music theory can be tacit knowledge. If you talk with musicians that do a lot of improvisation, they can certainly talk to you about music theory, but they're rarely "thinking" about music theory when they play. Just intellectually telling someone how notes/chords relate to one another doesn't transmit that "feeling" one needs to create great music.
I'm sure you're right that people occasionally leverage a friend network to upvote content to the front-page. I get the sense this happens a lot on Product Hunt.
But I know for a fact this isn't the _only_ way to reach the front-page of HN because I didn't ask anyone to upvote this post. ¯\_(ツ)_/¯
For what it's worth, Ask and Show posts are less likely to fall into the abyss than regular posts because they both have their own front pages where the threshold is lower than the main FP. So they have a longer exposure time to gain the upvotes to make it to the FP.
When we set out to build an auth API, one of the first big challenges was just wrapping our heads around all the various acronyms and protocols. Despite the existence of standards like OAuth, OIDC, JWTs, SAML, etc., authentication is anything but standard. As hobbyist devs, we wanted the interface to be simple. RESTful. Leverage HTTP verbs. We wanted an auth API that we wouldn't have to think about and would save us time.
After a lot of consideration, we settled on creating an abstraction for /credentials. With this, we've been able to abstract away sign-in flows for email+password and passwordless auth. "Just create a credential!" As Josh Bloch once said, “Good names are the API talking back to you”. We're super glad with how credentials abstract turned out. In the future, we plan to extend it for supporting protocols like OAuth as well.
Feather has saved us a ton of time while building other projects these past couple months, and we're happy to share it with everyone today :)