We've found https://tilt.dev/ to actually be a great alternative to docker-compose that also keeps the local setup and knowledge more inline with production (which is Kubernetes hosted)
Technologies: JavaScript, PHP, Python, Java, SQL, NoSQL, DevOps, Cloud, Marketing & Ad Ops, full-stack, etcetera. (Anything web related: You name it, I've probably evaluated and/or used it professionally.)
Resume: Currently employed, so reach out via email for resume/identification.
I have an entrepreneurial background, am currently the head of Technology for a major (Fortune 500) corporation, and looking to relocate to the San Diego area. Extensive experience designing/building and managing development of very high traffic web properties and software systems for major/global brands. In particular, I have deep insights in the marketing & advertising space. Would love to help a smaller to mid-size company optimize and grow their tech department.
It's typically 'SESSION' specific things with connection pooling that I've seen underlying (sometimes long-uncaught) bugs in production systems.
e.g. A 'ALTER SESSION'/'NLS_DATE_FORMAT' commands in Oracle or even an unfortunate 'USE <db>' w/MySQL.
There are of course safe solutions & techniques for this, but when you have an otherwise stateless-by-design codebase (such as with PHP), picking up "possibility state-laden" connections is a bit of an unexpected concept that I've seen catch developers more than once.
Actually, in larger enterprises (or maybe this should be "non-startup stage companies") I find its actually often the exact opposite.
If we're profitable, we're going to invest in a better working experience so that our employees spend minimal time 'dealing with' a tool's 'issues'. -because we can.
If we're a smaller pre-profit/cash-strapped/VC-beholdened company everyone is going to be expected to tolerate working with 'rough' tools if it can save a few bucks.
Literally, all of those trusts in that scenario are with 'people' which are indeed quite easy to corrupt (or fail without awareness). Possibly more so than potential crypto and chain/ledger based systems.
And again if "probability is low" is the bar, then we can surely keep _exploring_ Internet voting systems without engendering rejection as academicly 'impossible' for the whole concept.
If you apply zero-trust (as you are here), then its also _impossible_ to assure all those attributes are present in the current voting system.
So I see no harm in attempting to solve for "better" or even "equal but more convenient" than the current. -Which does not technically rule out _some form_ of internet voting.
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
If by "single folder on a hidden home page containing unused default apps" you mean "App draw", then you've described Androids (arguably superior) default UX.
Put another way.. You're manually 'fixing' the iOS UX to operate like the Android "default"?
I'm currently the head of Technology for a major (Fortune 500) corporation, looking to relocate to the San Diego area. Extensive experience designing/building and managing development of very high traffic web properties and software systems for major global brands. In particular, I have deep insights in the marketing/advertising space. Would love to help a smaller to mid-size company optimize and grow their tech department.
Also, the security aspect: Hangouts would get a bunch of backlash in the Enterprise world if they added the Allo type features to it. So they have pretty much to have separate systems for Enterprise vs Consumer if they want to integrate all the Google Now capabilities.
Also worth a look depending on your needs:
https://codenvy.com/ (based on open source eclipse che IDE)
http://www.koding.com/ (easy hybrid local IDE and/or cloud IDE integration)
There are firms that offer patent infringement insurance services. The cost is astronomical (7 figures per year).
I have a fair amount of experience with patent trolls.
I've seen companies sued for using facebook, where the damages are X dollars times the number of facebook followers/posts/comments they have. (So the level of risk is very hard to estimate for an insurer, because interaction numbers on the internet can spike easily)
Also, the the troll will practically _always_ offers a settlement that is roughly equivalent (or a few percent cheaper) than the legal fees to defend and win the case. -So a company has two options: Spend Y dollars to make it go away; or Spend Y*0.99 dollars and a year of wasted time to _maybe_ win. The system is setup such that Patent Trolls can't lose and companies can't really win.
I'm currently the head of Technology for a major (Fortune 500) corporation, looking to relocate to the San Diego area. Extensive experience designing/building and managing development of very high traffic web properties and software systems for major global brands. In particular, I have deep insights in the marketing/advertising space. Would love to help a smaller to mid-size company optimize and grow their tech department.
> Facebook has a massive incentive to stop fake accounts
As an advertiser, I am pretty certain this is not the quite case in (current) reality. A large part of FB's proposition for more money from us includes:
A) Pay more for increased reach and engagement.
B) Our traffic isn't decreasing (despite outside reports/indications to the contrary) and you would be missing a massive and engaged audience if you didn't spend with FB.
This combined with the fact that a _lot_ of ad-spend isn't directly attributable to conversions (often by design), means that more "activity" whether its fake or not, drives up ad-revenue for FB.
You see the same issue occur with other publishers by the way. -It is not uncommon for a publisher (or other related party) to purchase a swarm of fake bot traffic to boost impression and engagement numbers of an ad buy they've sold. -Advertisers un-aware of how much of the traffic to their ads are bots vs legitimate humans (read: "publishers stealing money from advertisers") is a major problem for advertisers, but the bigger the publisher, the harder it is to 'not' be on their platform too. (and FB is _very_ big)
I think you may also be misconstruing the point. Saying that fingerprints aren't passwords is _not_ the same as saying a fingerprint shouldn't be required to unlock a phone.
(as with most web logins, its userid + password. But shouldn't be one or the other)
The key point though is that security tokens must be changeable/revocable and and bio-metric data is not-so-much.
Since Lyft actually 'supports' the ability for riders to tip their driver, I would suspect the same person is always happier when their fair is using Lyft's app.
The number of people here defending long 'darlings' (or over-generalizing 'long one-liners'), is both shocking and dimsaying to me.
Beyond basic functionality one of any (serious) programmer's _top_ priorities is to maximize the readability of their code for the next (unkown) programmer that touches the source.
We all have large monitors -often rotated 90degrees to portrait. Extra lines are not a bad thing (especially if it helps visually break things into multiple smaller steps), and more work on a single line does not == elegance.
We just do all that compilation prior to check-in for release branch. Basically, version control holds the compiled 'snapshot' of a working app, and host specific variances in the code is forbidden. (composer is for project bootstrapping rather than a 'build step')
-btw, we do this with subversion since git doesn't handle large repos well +empty directories.