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
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.
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.
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 (?)
I think it could be argued that the entire mechanics of drug development (and costs) would be fundamentally different in an environment without patents. Without the incentive of monopoly, there might be a lot more evolution (think of forking/branching of open source software projects) of meds, which I imagine would significantly alter the costs/incentives in drug development. These are kind of just my thoughts as a layman, though.
Just to add to this - it is true. I have researched this subject incidentally many months ago. ON Semiconductor is one of the more relevant companies in this domain. They are a public company with a market cap of $8.5B. You can look at their Ezairo series of system-on-chip products - they are built for digital hearing aids (with all consideration of power requirements, DSP/programmability etc).
I am as happy to work on mature codebases with big teams as on totally greenfield projects. If you would like to have me on for a couple of weeks to see how I get along with your team and codebase I can likely accommodate.
Congratulations on an income-generating project! That's an immense achievement. Perhaps the infrastructure cost is worth the headaches you spare yourself by being on GAE but have you looked at dedicated infrastructure from the likes of OVH/Hetzner (on both providers you can get ~2TB storage/64GB mem boxes for around $100/mo)? I moved all my projects to a single OVH box and it's been a champ. It does mean slightly more maintenance burden (ex you need to roll your own backup/restore plan). Perhaps it is a poor fit but that seems like a possible path to get those costs way under control
My progression has been PaaS -> AWS -> Digital Ocean -> Dedicated and I strongly feel that if you're going to make the leap from PaaS to VPS, it's not a whole lot harder to go dedicated and there you'll find much sweeter value. I'm currently on an OVH SP2 (Xeon + SSD + 32GB ram in a data center in Quebec so not terrible latency to where I am in the northeast US) that I pay $90/mo for (http://www.ovh.com/us/dedicated-servers/sp2.xml) and it's just jaw-droppingly powerful. If you're going to go through the trouble of migrating your app anyway, it's worth taking a good look at dedicated offerings like that as well.
This assertion is, categorically and empirically, ridiculous. Yes, the runtime and framework are slow compared to something like go and Revel, but that is not the principal benefit of Rails. Rails' principal benefit is taking care of Maslow's Hierarchy of Needs, or whatever its analogue is for developers. The most recent Rails app I wrote has average render times of 7ms (excluding network latency) on dedicated hardware largely because most views can be rendered with just 3 memcached hits. What's more, implementing the nested caching strategy necessary to achieve this was pretty simple with the out-of-the-box capabilities of Rails 4. If I'm busy worrying about lower-level concerns it doesn't matter if my runtime and framework are blazing fast - I don't have the confidence or time to implement strategies like this, or at least not with nearly as little effort. The proof is in the pudding. Anecdotes to the contrary are welcome.
When I was doing this, I was leaning toward going the 3rd approach, but it seemed a really momentous undertaking. That would definitely be a boon to the future of PaaS projects though, because it seems like OpenSSH doesn't really have the use-case in mind, plus I hate the idea of hacking something as fundamental as OpenSSH on my machine to do development work on a single project
I promised I would ask this next time there was a Flynn post. Having tried to hack a PaaS like this with git "push-to-deploy" functionality, one of the most problematic components to implement was SSH authentication. Getting a workable but unscalable solution was easy by just writing "forced command" entries to the ~/.ssh/authorized_keys file, but getting a scalable solution seemed to require hacking OpenSSHd to check public keys against a database (this is what github does, and requires patching and recompiling OpenSSHd). How is Flynn doing key lookup for the push-to-deploy?
Please enlighten if I'm mistaken but is this not, like, a microcosm for a certain current culture of unproductive client MVC fetishism? What do you think is easier to maintain, the officially supported data-attribute based implementation here: