Mixpanel employee here, I actually just emailed Jitsu this morning to ask about adding Mixpanel as a destination. We're willing to work with them (or any of you!) to get the PR open. Feel free to reach out directly to [email protected]!
I believe their value lies in their e-commerce partnerships. You can effectively check out (almost) as seamlessly as a using a credit card on partner sites. I used Klarna when I bought new golf clubs. They show up right on the checkout screen. I can afford to buy them outright but it was an interest free loan for two years so it made logical sense to me.
I believe tech is still largely a meritocracy. If you think you should be paid more than someone, you should prove it with impact. If the goal of your education was compensation and your education doesn’t enable you to have more impact than a boot camp grad, then you overpaid.
Mixpanel is hiring full-stack and front-end leaning software engineers for its new ATX office. This is a unique opportunity to work with top-tier talent and be compensated as such while helping us a grow our small team in Austin into something bigger.
The product engineering team creates the face of Mixpanel. We organize in small, nimble product groups (two to five engineers in close partnership with PM and design) with huge autonomy over what we build and how we build it. You will own the full stack for your product areas, from database schemas and HTTP APIs to data visualization down to the last CSS detail. A passion for product and empathy for the user are key. Our stack includes Python, Golang, and lots of JavaScript & TypeScript.
This is a concern with monorepo but you can still enforce the boundaries programmatically. For example you can add some simple, custom lint rules that prevent cross-boundary imports.
Another thing you can do is have your CI only check out specific directories when running tests using something like git’s sparse-checkout.
We have been using a small bit of glue code to write Web Components declaratively with Snabbdom for a couple of years at Mixpanel: https://github.com/mixpanel/panel. Happy to talk further about our experience!
Just curious, what are the reasons to be on "a bunch of metrics platforms"? Specifically, what are the various problems you were trying solve with different tools?
It's funny to me how many people are outraged at Facebook's focus on data collection and privacy "invasion" for the sake of monetization. Every company is using whatever data they can access to make as much money as possible without alienating their user base.
Facebook might be more aggressive (or perhaps just more transparent) about it. However, to think, as a rule, any company (particularly a public company) is making decisions based on ethics or your best interest is naive. It's all about revenue.
We've been using Web Components + Virtual DOM to build our web apps for the last year at Mixpanel: https://github.com/mixpanel/panel. The biggest issues have been dealing with polyfill issues (especially Shadow DOM leakage) and versioning elements (given the global namespace issue of "registerElement")
I'm pretty sure that the concept (or implementation) of virtual dom wasn't invented as a part of React. IANAL but I don't think they could patent it. Ignoring specific optimizations, a virtual dom algorithm is fairly simple.
It's just personal preference. I really dislike the lyft product because I don't want the driver to treat me like I'm his friend (fist bumping and what not). It feels fake, forced, and awkward. I much prefer the general experience in an Uber black where the driver asks me where I'm going, makes sure I'm comfortable (a/c, water, music) and then let's me be. The irrelevant small talk just annoys me at best.
P.s. I also dislike the pink mustaches. So gimmicky.
I think iterating quickly is great for product decisions where you don't know how people will react. Technical decisions, however, can be objectively evaluated up front given the right experience. I don't think a migration from a monolithic system is particularly exceptional.
Loose coupling is awesome and dogfooding your public API is smart as well. However, it seems like there is a lack of strong technical leadership and a lot of big decisions are being made without thinking them through. For instance, "We were constrained by the same rules we enforced on third-party applications... It was not possible, for example, for a microservice to notify users about activity on private tracks". This type of constraint should be immediately obvious to the person/people making large architectural decisions. Throughout the article there are a few examples of "we tried this but shortly found out it wouldn't work". I may be wrong though and this whole post was actually the result of an hour meeting to discuss new architecture but phrased to sound like you actually tried all of those approaches.
One of the biggest shocks to me when moving to the Bay Area is the difference in social norms and acceptable behavior. I grew up in Texas and went to college on the east coast. For the first few months after moving out here I was in awe by some of the things people would do and thought were acceptable. In fact I'm still in shock by many of these things but used to them by now. From some of the things I've seen managers do in regards to relationships with their employees and behavior at office parties to an entire section at AT&T park cheering when an opposing pitcher gets hurt and pulled.
Furthermore I also found it much harder to communicate appropriately as social cues seem a bit different. I have at many times found myself in a conversation (or lack there of) filled with awkward silence.
Although I'm happy to see someone attempt to do what Simple is attempting to do, I don't think any sizable amount of people will be willing to drop their bank and move to an alternative that doesn't allow cash deposits. I have two bank accounts I regularly use: one is a regional bank based in Texas and the other is Wells Fargo.
I hate my Wells Fargo account but I keep it open so I can deposit money and I can receive account transfers easily from other people. Even with this setup I sometimes find it difficult to get the money where I need it (specifically out of my Wells Fargo account into my regional bank account) without hassle (and fees).
Anyways, the MVP if you will for a bank that I would switch over to would be one that allows me to deposit from anywhere (checks from home, cash from any ATM anywhere that accepts deposits), withdraw from anywhere, and transfer to any other account in a timely fashion.
There is certainly a line that can be crossed when it comes to over thinking OO. However, Dependency Injection enables you to write much more testable code where in many cases people would use static methods therefore breaking the ability to properly unit test.
As for your argument against traits, using global functions clutters up the global namespace and doesn't lend very well to modular development. Next thing you know you have two libraries with "create_hash($string)" or something similar that do two different things.
For what Twitter is today, I'm sure they are. They are essentially the world's largest chat room except every participant gets to curate their own experience (plus it's all indexed). Maybe their revenue stream won't be directly a tech product but will certainly be the result of one.