At work we use Google meet, which can handle multiple people screen sharing at once, and VSCode live share. It works pretty well. VSCode will forward ports for you so both people can access the running webapp, and you can allow them access to a terminal so it’s lets both of you to work in the code base as if they are developing solo locally.
> I hope that some of these optimizations are a pleasant surprise and will factor in your decisions to write clear, intention-revealing code and leave it to the compiler to do the right thing.
This was my key takeaway from this article. Writing clear code that is easier to maintain will have good enough performance most of the time. I was particularly impressed with the devirtualization optimizations and will be less likely to shy away from using polymorphism in future due to performance concerns.
I’ve always been super happy using Ruby. Never had any experiences that would cause me to label it in the way that you have. However, I am interested to know what those flaws are. Could you elaborate?
Disclaimer: I do ruby for my day job, and python for fun
Disclaimer 2: I don't hate ruby, despite all these criticisms. If I had to pick a worst dynamic language it would be PHP.
Things I don't like about ruby:
- two string types, symbol and string, with string being the mutable by default one.
This means given a random thing back from an api, you don't know whether to do thing[:id], thing["id"], or thing.id
This has been acknowledged as a pain point by Matz, which is why in ruby 3 strings will be immutable by default.
- Simultaneously too many names for things and not enough.
Is it .length or .size or .capacity (probably not capacity)? is_a?, kind_of?, or instance_of?? Why can I do .select or .keep_if but not .filter?
- Too many function types.
Do you want a method, a block, a proc, or a lambda? There are subtle differences between each, so choose wisely. I'll note that python suffers from this too (method, function, lambda, comprehension).
- Too much emphasis on magic
Novice rubyists get frequently bitten by all the advanced (and very hard to google) ruby concepts. How do you know what arr.map(&:id) is without already knowing that it's calling symbol.to_proc? How about $1 $? $! (if you know what all these do, you're a better rubyist than I am).
Since the author of the referenced post criticizes django for being too magical, try rails. In addition to the names of files mattering a ton, there's the routes DSL, the migrations DSL (which is not well specified in the guides), and ActiveSupport, which you only realize you're using when it's gone.
- Horrible error messages
undefined method :[] for nil:NilClass (when you try to get something out of a hash and it's nil)
cannot convert Symbol into Integer (this is on an array being returned where a hash is expected)
Also, if you get a stack trace, it's completely inscrutable. Python's stack traces (at least ipython's) show you both the line number and the line in question (often with context).
Password salts aren't secret. They are stored alongside a password hash because they're necessary to reconstruct the hash from the plaintext. If you look at a bcrypt string, for example, the salt's encoded in it.
The problem is instead that now that the client-side hash is actually the password.
(edit: some people use a "pepper" at the application level and apply it to all passwords, which might be kind of what you're thinking of? Buy you don't need to do this with modern key derivation algorithms. You can if you want, it just doesn't really matter much.)
That's not why (the salt does need to be secret secret), but it is true that the hashing should not be done client side. It's more because it doesn't actually accomplish a whole lot. The hash basically just becomes the password, so you'd need to hash it again on the server to get the same level of security.
Quite well. From Rails 5 there’s an API only init flag which removes the view layer and then you can just return JSON from controllers. Chuck nginx in front to proxy backend requests and serve your static front end bundle and you’re golden.
Its based on Ubuntu, so whatever you can install on Ubuntu should work on Elementary. Only issue I've run into is while adding an apt repo(for docker I think) I needed to point it to bionic instead of juno.