I would hope so. The expectation is to build a multi-billion dollar company. There are more interesting products and ideas to explore out there, but they won't make you rich.
Which is why I'm super-skeptical of anyone who says they're at some rocketship growth startup because they just want to make "great products". Unless their definition of a "great product" is one that makes a lot of money or is popular, they either aren't being honest or don't fully understand their own motivations.
Where’s the part where anybody defrauded anybody? This was clearly incompetence that benefited nobody (certainly the developers would rather not have TITAN implode and all of this USDC locked in a contract...). Embarrassing yes. Fraud? Pretty clearly no
Depends on how you write the contract. If you make a smart contract unilaterally updatable, then it's no longer decentralized and trustless, because people with admin rights can plunder it, or can be extorted, or compelled by authorities to turn over the capital.
Polygon right now has capped the number of validators at 100, and the protocol atop which it is built (Tendermint/“Peppermint”) only remains fast and cheap if the “active set” of validators remains small. Polygon team have said they will introduce an “auction” mechanism for new validators to join the active set, but one would anticipate that will just favor validators with large stakes (i.e. the existing validator active set). Cosmos/ATOM is the sort of keeper of Tendermint and responsible for the reference implementation and they too cap the validator active set at 125 or 130. Practically speaking none of these L2s are very decentralized. They are fast and cheap which is what most people want but practically pretty centralized...(i.e. project founders and early operators are totally capable of launching 50% or 2/3rds attacks...they probably just don’t want to, and the small “active set” of validators is likely to mostly stay the same). A genuinely decentralized PoS L2 (i.e. can accommodate very large number of validators) that is also fast and cheap is something I’d love to see
DigitalOcean Spaces offers S3 API compatible object storage (i.e. you can use any S3 client library without modification) and a seamlessly integrated CDN that is markedly cheaper than CloudFront: https://www.digitalocean.com/products/spaces/
Having used and written on this subject extensively, you are right but in practice these approaches mean something along the lines of making a single primary key lookup (like 0.1 to maybe 3ms in most cases) to save many tens or hundreds of queries (in addition to the cost of rendering/templating) to build the nested content, so it is still extremely practical.
Honestly, as a person who prizes Apple’s products and happily depends on them for work, personal life, etc. I think Tim Cook needs to either open up sideloading or be promptly fired and replaced by somebody who will. None of this sits well with me. It is a situation we do not need to be in. I agree that he is a moral coward, and in far too important and dangerous a position to be so.
The first duty of public companies is to the shareholders. Users fuzzy feelings figure very little in the incentive structure. Sideloading is probably too damaging to the short term profits of the company to be on the table. Or it might not even be a question worth considering for the board .
I strongly feel that at this point the intuitive solution would be a broad boycott/protest of Apple’s products until they elect to allow sideloading of applications on iOS. They shouldn’t even _want_ to negotiate moral issues like this and I feel it’s just really ugly for them to be in a position to arbitrate matters of such gravity when they don’t have to be. Enough people will continue to use the App Store for convenience that I doubt it would have any substantial consequence for revenue, and even if it did, this is such an intuitively ugly thing that I would argue whatever the cost is it is worth it. Even dependent as I am on Apple products for my work, it may pain me too much to buy another if this is still going on come the time.
I have worked extensively in both frameworks and would add to this:
* Django has comparatively limited I18n and localization faculties compared to Rails (with Django’s i18n built atop gettext, which I always found kind of brittle with .po files/string-based keys)
* No intelligent/efficient class reloading in development. The whole development server just restarts when you make changes
* No reloader for the shell (horrible for developer ergonomics - you can't just type "reload!", you have to restart the shell to pull in any change)
* Caching faculties in Django are much more limited - no template digests (to make template fragment caching much more robust)
* ActiveSupport has also always been a god-send for productivity. It may seem small but things like “Array#to_sentence” and the time functions (i.e. 1.day.ago) are incredibly useful.
* No default assumption of multiple environments (no default development/testing/production configuration files, environment detection, etc). This is pretty ridiculous for a web application framework.
* No built in credential encryption (makes keeping a team in-sync with keys for integrations a comparative pain)
* Dependency management is much more challenging in Python. The de-facto virtualenv + requirements.txt combo is lossy (no dependency graph) and awkward compared to bundler. There are other solutions here but something so foundational shouldn’t be so hard.
Django was the first web application framework I learned and I still work with it professionally from time to time (as recently as ~2 months ago). I am just a bit stunned by how much it has fallen behind in terms of its broad state of maturity, community/ecosystem, productivity, etc.
For once a fair criticism of Django by someone who seems to know the framework well.
I don't quite share the same experience with i18n though. I always found Django statical code analysis to extract translation keys to be superior in many ways to other translation systems. It is giving useful context that are stored in the PO files and good translation tools use them. I also never had any issue with string based keys. You can chose an english based key or an abstract whatever you prefer.
Some of the annoyance you mentioned, that I agree completely, are more of a language issue like: reloader, or dependency management.
For multiple environments there is a very simple pattern you can put in place using an environment variable and conditional imports. something like:
from settings.base import *
if env == 'prod':
from settings.prod import *
A bit funny (sad) about the dependencies - zope, the early web application server - brought much to python (eg: eggs) - and essentially worked more like bundler + Gemfile/Gemfile.lock - with its zc.buildout dep (and more) manager. And like with ruby/rails, it could be difficult to get it to converge on "known good sets" of dependencies.
Take a look at this dated doc for zope 4 - anyone who's had to fight with bundler should see some similarities - good and bad i think:
I am surprised that nobody has raised the question of whether this is 15% of gross pay, pre-tax or 15% of net pay, post-witholding (well assuming W2 positions)? Those are very different things, especially in states like CA/NY where I imagine many candidates might end up being placed. In those contexts 15% of gross might be more like a 25-30% effective share of the developer's net income (?)
