1,107 karma · joined August 25, 2014
Coalition is working to solve cyber risk. We are a small, well-funded team of security experts, insurance professionals, and intelligence community veterans building a better cyber insurance product. Coalition is automating risk assessment to make purchasing this insurance easy, and using our knowledge to educate clients and mitigate risk where possible.
We are looking to hire our first front-end engineer, who will set the technical direction for our front-end and take ownership of it. We are open to various front-end technologies if you can make an argument for it. Experience with Python is a plus, as you will likely need to touch the back-end at some point (which is in Python 3.6).
Email jobs@thecoalition.com for more information.
Most things aren't math equations. All distinctions in the real world are messy, seemingly arbitrary at some level. Can you define what it means for something to be alive or dead? I seriously doubt it. Yet we do not dispute the existence of such distinctions. The concept of life improves our understanding of the world despite its slipperyness.
It's not something I'd use for serious security applications, but fun for interactive fiction.
Coalition is working to solve cyber risk. We are a small, well-funded team of security experts, insurance professionals, and intelligence community veterans building a better cyber insurance product. Coalition is automating risk assessment to make purchasing this insurance easy, and using our knowledge to educate clients and mitigate risk where possible.
We are looking to hire our first front-end engineer, who will set the technical direction for our front-end and take ownership of it. We are open to various front-end technologies if you can make an argument for it. Experience with Python is a plus, as you will likely need to touch the back-end at some point (which is in Python 3.6).
Email jobs@thecoalition.com for more information.
That being said now that I don't get free food from work, I'll be buying groceries and cooking often enough to use the larger portions.
Of course you would. The bank would call the FBI and tell them you're hacking the bank, and the FBI would then knock down your door, tear up your house and drag you away. The system would then do everything it could to represent what you did as a crime, and if you are lucky you get away with only a year in court, many thousands in debt and your name dragged through the mud.
tl;dr The actual legality of an action is only tangentially related to how the legal system will be used against you in response to it.
Is your browser publicly available? Did you create it yourself--and if so, what did you use?
> If you are a web dev or dev ops then why not comment on the article rather than playing with toys.
Not sure what you mean here, or whether I'm supposed to be offended. I don't think I play with toys--I host my own site, carefully keep each page under 100kB total, and am working on a framework to make it easier for others to do so.
Whether this makes a significant difference is probably highly dependent on the page and the user's connection, and I have no idea without profiling. But it's at least plausible that it would help some users on slow connections.
Of course, it could just be that devs are A/B testing time until the "load" event fires, in which case they've just found a way to cheat the metric.
[0] Specifically, the dual numbers: https://en.wikipedia.org/wiki/Dual_number
[0] "23andMe says that it is also able to share anonymous and pooled data about their self-reported health traits without asking." - https://www.forbes.com/sites/matthewherper/2015/01/06/surpri...
I agree intuitive validation is harder. I think it would be a vast improvement to separate the parts of the validation that are form-only from the ones that are actually database constraints, e.g. in a form_validation kwarg, because in my experience half the problem is that developers aren't aware of what's happening on the form vs the database. They could also add some of the validation that is currently on forms to the database via CHECK constraints. And they could also do validation in model setters, not allowing a model attribute to be set to a value it wouldn't accept via forms.
I have used DRF, and I find the serializers and validators quite easy to work with. My complaint only complaint with DRF is that, at least at the time when I used it 1-2 years ago, it was annoyingly easy to accidentally expose more fields for writing than one intended--in fact my first exposure to it was frantically fixing a bunch of security vulnerabilities I discovered in an API written using it.
For other frameworks, I have used Flask+SQLAlchemy (Core) and found it a lot better than Django. Like any good framework grump I am also developing my own, which avoids all of these problems in exchange for what I'm sure are a host of problems I haven't considered.