How would this kind of a book would be different? I think I already use when and if quite a bit. And then if you make your code consume and produce sequences then you will still do the assembly's CMP calls at the OS level but you would be seeing as you would do iteration. So what are the ways that Ruby could use? Maybe some of them could be applied directly? (I think this kind of book would work very well for golang code as there are... quite a bit of ifs)

Why do you want to minimize if statements? Maybe I'm confused?

Are you talking about like ad-hoc error handling ifs?

It would be great to know what the book says about it. Maybe they simply introduce Liskov substitution and this is what you meant when you said "less ifs"? The reason would be great. And maybe even some examples.

Conditionals aren't bad per se but using a lot of them can be a code smell. I think the main idea is that sometimes you should prefer polymorphism instead (e.g. multimethods/protocols in Clojure) (but yeah, I'd also like to see some examples)

So one example in the Confident Ruby book is handling special cases. The example it gives is using current_user which is a method to get the logged in user. So what usually happens is there are a lot of if statements checking for the existence of current_user (to handle when no one is logged in Example

if current_user
   render_logout_button
else
   render_login_button
end

I see. Well in FP my "technique" is to partition data into lists and pass those further "down the line" as a map or tuple that could be walked through. For instance I currently create a query parser and I have different clauses. I take those clauses and sort into lists based on something like this: (group-by :type clauses) And then I handle each clause separately and join the result together back into a query (I need to add clauses). If I'm correct you try to do some kind of UI-based user session handling. If you have only one user then you will still do the check somewhere even if you'll try to use objects and monadic/Liskov style of dispatch. So you could save a function that would decide what to do for this specific user. For instance the function could render whole webpage or part of it. Then you wouldn't need to run the check every time as you could curry that function until you produce a function that renders whole webpage (it depends but it could work like that). Also how is this different?

if logged_in:
  return new LoggedInUser()
return new LoggedOutUser()

if logged_in:
  return logged_in_render()
return logged_out_render()

;; let's say we already have a Context interface/protocol
if logged_in:
  (new MyContextProtocol_LoggedIn)
(new MyContextProtocol_NotLoggedIn)

I see. So my guess is they move the render function on the User objects as well. So then you just do user.render() and if it's a GuestUser it will render login otherwise render logout. I guess since it's just about favouring polymorphism for flow control you'd just do the same in Clojure if you wanted, and use multimethods or protocols. But depending what they considered the "code smell", it could just be that you don't use nil to represent a guest user, maybe you use a keyword and it becomes

(if (#{:guest} current-user) (render-login) (render-logout))

(case current-user
  :guest (render-login)
  :vip (render-vip)
  :logged-in (render-logout)
  ...)

Yup! I have a pair of solokeys and registered them everywhere I could but unfortunately most services don't support WebAuthn yet. I'm looking forward to a passwordless world... 😄

I'm sceptical about it. So how will I be able to use this public key if all my browsers aren't connected to each other? Also most of the times I use container tabs and other isolation features. So... it's important to isolate all of these browsing patterns. But this public key has to be synced somehow. How does it work? I'm sure that large corps are interested in consolidating their users under a single key/wallet. But how do I then sync these wallets?

I’m not sure how it works exactly yet, still have to read a ton - however you have the same problem with session cookies

you still need to authenticate in every separate context

But with session cookies you enter your PW and you have a new cookie for a new browser. And here there won't be passwords. So probably there will be wallets...? Also a wallet is a hierarchical thing. So users will really get tied to the browsers and a "single wallet, single user" philosophy.

Think of it as ssh key pairs maybe? You maintain them outside of the thing you’re using

Not sure yet!

To reuse the private/public key analogy: A hardware key serves as the private key. Most of the time it has a button on it, so in order to use WebAuthn on a website that supports it, you sign in, go to your account settings and add a security key. When the website asks for a confirmation, you plug the device in, press the button and the website connects that hardware key to your account. This is like adding a public key to your account. The difference is that instead of storing the private key as a digital file, you have a separate device (usually the same size as a small USB stick).

Ohhhhhh

That’s a very important detail I missed ty @UEQPKG7HQ

But the webpage said "Databases are no longer as attractive to hackers, because the public keys aren’t useful to them." - https://webauthn.guide/#about-webauthn So it has to mean that if we'll abandon the password model and not integrate with it then you MUST have a keychain. And if you would have a device which you can't change (the physical device you mentioned) then you have one keychain which you can't choose to change. Also how many USB sticks will you be able to plug in simultaneously? Also, since it's USB... how will you prevent two containerized browsers from contacting it and asking for the same details if they happen at the same time?

You could be using another device and switch to it’s key as long as you have both devices right? That would be a matter of application rather than the underlying mechanism

Yes, you can usually register/unregister as many devices you want

And it's generally good practice to use at least 2 (one for backup)

It's one of those technologies I'm very excited about

But you can't have 10 USB sticks (for each context provided you have more than two) plugged in into your laptop under different access rules for the same browser... Because if it's the same browser... how does it prevent itself from leaking the details where the corporation decided they would like to have it?

I assume it’s used for authentication and then you can still provide a token/cookie for a long session

> Because if it’s the same browser... how does it prevent itself from leaking the details where the corporation decided they would like to have it? You have the same issue with password entry

> how does it prevent itself from leaking the details where the corporation decided they would like to have it? Right, instead of typing a password, you press a button

I feel like it’s an improvement to own your credentials. It’s what we do with ssh after all and we tend to prefer that over password logins.

And having the physical thing as the key feels even better

You could have a password manager that unlocks a DB on a thumbdrive... Which would be more general than browserifying everything And you could encrypt that drive.

WebAuthn is just one application of hardware security keys

I'm using it to log in to my machine (instead of a password), connect over ssh (instead of using a passphrase), run sudo commands, etc

> DB on a thumbdrive But then anyway -- you'd need to sync it with other USB drives which misses the point

From a web dev perspective this sound incredibly attractive too. It seems like a web app has far fewer responsibilities this way.

I think it's not different than logging in using a crypto wallet like Metamask or Trezor. Because keys are deterministic there. So you only back up your master passphrase and you can migrate between systems. It's still a signature.

External services are just not it IMO. Having a widely implemented standard for this leads to less friction, more eyeballs, more standard tooling etc.

(Not saying those are bad or anything - just not quite the same)

Widely implemented standard is a good thing. But I already imagine how google will write "hey, sync your ID wallet one-click-easy" But what I don't imagine is passwords being thrown out as a stable fallback if all else fails. You just remember them.

I hope it won't be anything more than a "hey sign this whatever you like" or "sign this with key 15 in your chosen wallet". Because all this "attestation" and so on looks like there would be a central authority (like your govt) who gives out these USBs. It could work this way but I hope it won't be mandatory.

Passwords are a security nightmare because humans aren't good at creating/remembering them. So now we have password managers: centralized databases of everyone's passwords. How's that a good system? 😄 edit: Sure, you can carry around your keypassDX DB or self-host bitwarden and access your passwords over VPN but let's not kid ourselves, 99.9% of the population doesn't know how to do it or won't bother trying. > looks like there would be a central authority (like your govt) who gives out these USBs Even if that happens I doubt anyone will stop private companies from making them as well. If you worry about potential backdoors, solokey and nitrokey are open-source and both have been audited by independent, third-party teams.

Oh hey. You can probably already do it with dropbox..? https://wiki.trezor.io/FIDO2 But dropbox didn't remove the password log-in option.

> But dropbox didn't remove the password log-in option. Yes, it's still too early. Github also still requires a password, even if you have registered a security key. Sorry, I'm not sure what you're disagreeing with.

I don't yet know. It seems that the same things would be possible with this method but I look for flaws in privacy.

It depends. If you need to build something and then change it gradually - yep, that's the best IMO. But if you need to come up with a robust design first - a proper design tool is probably better. It would also have all those points, only you wouldn't have to deal with browsers' peculiarities and differences.

I have noticed that I tend to do a lot more CSS bug fixing directly in Chrome Dev Tools, and then when I'm happy with the look, copy and paste the CSS styles back into my Sass files.

I use both at the same time, definitely you want a fast feedback loop if you are working in your editor such as hot reloading. I often do fine tuning in the browser directly and sometimes I switch around nodes in the DOM or delete/duplicate them. But anything beyond that isn’t that great, because html and css are so complected that you need to move the structure and styling in sync. When using something like tailwind or anything that generates CSS (SCSS loops and such) then the browser also becomes a bit less useful outside of analysing. The actual changes are then too far away from direct CSS.

> • css grid visual tools built in This and the highlighting features are what makes dev tools great though. It’s really a seeing is understanding kind of deal if it comes to the overall layout behaviour - especially if you didn’t write it yourself (or a while ago).

No, because Chrome devtools is extremely frustrating to type in. All the little helper features, like arrow helpers are also wildly inconsistent in how useful they are. (Try arrowing values like opacity: 0.9 vs 90%). Typing in the element style pane also seems like it commits autocompleted junk without any user input, you just type the first few characters and this can happen. Recently, it has also started to crash constantly, and become slower than before. That said, it is still a great environment for gaining understanding of what is happening.

I've used http://hadron.app before; it has a neat idea going for it. Development seems to have stopped, and my impression was that they got stuck in the convoluted mess of JavaScript and npm.

@U013TCGL92T I think that there is React Native with their JSX thing and they have a basically... different and reduced CSS rules. I think this one could be harder than the HTML+CSS webpages. Because they'd probably need to support both then.