SiliconAlley

So everybody is in it for the money? Noted.

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

Though a classic, I think we can all agree this is literally the opposite of what the OP is asking for...

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.

I agree. I hope this will be enough of a disaster in terms of optics that it renders him unfit and forces this outcome.

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).

SEEKING WORK - NYC or remote

Available for on-site contract work in New York City or remote

4 years Ruby on Rails experience: deeply versed in and loyal to the idioms of the framework. Obsessive about performance.

Extensive startup experience. BA in CS (Columbia).

Infrastructure automation experience, DB performance tuning, very strong fronted skills, iOS (Cocoa Touch Framework/Obj-C/Swift), some fronted MVC, Desktop frameworks (Qt, Cocoa), Python/Django

Personal info/blog: http://www.writtensoftware.com/me

Portfolio: http://www.writtensoftware.com

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.

I look forward to hearing about your company

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:

https://stripe.com/blog/stripe-checkout

or the model/controller code in the article? Maybe I've missed the point.

I would love to help out with this. It's an area of deep personal interest for me. I've got homepage/contact links in my hn profile. I'll write in a bit.

Thanks! I thought about astroturfing my area with accounts just to make it not look like a ghost town, but felt it was against the spirit. I felt the best thing that I could do in this respect would be to make sign-up as frictionless and semi-anonymous as I could (plus let people toggle on and off account visibility) because I and most other tech folk I know are hyper-protective of their identity online. One of the huge turn-offs of Coder's Coffee for me was mandatory sign-up-via-linkedin. My modest goal for the end of the week is to make one local appointment for myself.

I would (and have, in the recent past) opt for Stripe subscription billing: https://stripe.com/docs/subscriptions. Upgrading/downgrading plans for users is baked in (and you can even choose to prorate or not), plus, of course, it's an integrated service rather than something that sits atop another gateway and adds additional fees

"Models are intended to serve only as an abstraction to the database"

I'm really tired of hearing this unqualified argument. Fat models is not a creed. It's a practical and natural design choice that we've made because it fits real world workflows best. Do you really want to be copy/pasting your order total calculation logic into 5 separate controller actions? Obviously not. And fat models doesn't mean 800 line source files. On reasonably sized Rails applications the logic gets bundled into nicely organized and maintainable concerns.

http://tinypag.es

It's ultra-minimalist hosting. A bare HTML document and a short url. Built it to scratch my own itch. Bought the domain and opened the repo on March 5th. Launched 2 days later.

This isn't a new project -- I first discovered and used it on a social video app I helped build for a startup last summer. That said, it's well-written and the de facto standard for integrating facebook authentication (though it supports many other backends) in Django apps. Recommended!

SEEKING WORK - Remote or NYC area

- iOS, Ruby on Rails, MySQL, general web frontend (HTML/CSS/JS)

read about me and view work + contact info at http://bit.ly/AiQ4c8

Relatedly, don't underestimate the contribution that quality typography makes to a sites perceived professionalism. I'd play around with some non-user-agent typefaces (using @font-face) for you homepage copy and links. Off the top of my head, looking at the site, maybe a Museo font (see: http://www.trybloc.com -- no affiliation, but they use the font for their heading).

Thanks! Yes, I’ve already found that to be the case while working on the successor project. Plus, though I didn't mention it in the piece, there are many things peripheral to actual development that were a big time sink but that now are just done and I don’t need to think about (incorporation, associating my individual-type Apple dev program account with the company, contracts etc).

Longtime lurker, first time OP. Apologies if it's poor form to post your own writing. I was motivated to write by an HN comment to the Fiplab guys a while back: http://news.ycombinator.com/item?id=2979091