The other responses answer your direct question, but I was confused about similar flows when learning about SAML so I'll comment in case this is helpful.
SAML is just an authentication protocol, it doesn't really handle user provisioning. Which was confusing to me, because any time you'd use it you typically also need some kind of provisioning mechanism.
SAML does have a concept of "just in time" provisioning, which is what I've seen small SAAS companies typically support when they say they have SAML support. But basically all it can handle is creating accounts in the SP the first time a new person logs in (with valid credentials signed by the IDP). For user provisioning though what you really need is full programmatic CRUD access for accounts in the SP, which is outside the scope of SAML. I don't really understand why the SAML protocol bothers having such half-baked support at all, because you immediately run into issues. For example, giving some users different permissions than others in the SP, or updating accounts in the SP that already exist.
For user provisioning, for SPs that support it you can use the SCIM protocol alongside SAML, which gives you full control over provisioning accounts the way you need to. Then for instance instead of just logging someone out of the SP when they were removed from the IDP, it can fully deprovision the account in all your SPs as well so you're not left with orphaned accounts sitting around.
This was my gut reaction when I first learned about graphql, but in practice when I used it it didn’t end up being an issue (although we didn’t have to run at particularly large scale).
If your data models are pretty well structured, then basically every graphql object is a single table that you get by an indexed field, and traversing relationships can each do a where in query on the indexed id field. The parameters you expose on queries should be for indexed fields. So in practice, you’re not really autogenerating any particularly expensive queries, and if you assume the client isn’t asking for tons of data they don’t need, it’s not much different in query patterns than rest. Except that in some cases, the client can omit fields or related objects instead of re-using the rest route that’s a superset of what they need, so you can save resources sometimes too.
Then on top of all that, you have the option to not auto-map certain queries to the orm in special cases that are more complex, so you always can still write the code yourself to be more strict about what you allow. For writes, you typically would always do this to control exactly which fields you write.
> This makes the piracy route become more and more attractive again - and I don't like that this is the case. I want to pay people for their content.
People like to say this, but, no offense, it just doesn't seem true. It sounds like a justification. (And I'm not judging, I'm just not convinced by this reasoning).
Signing up for 3-4 streaming services is pretty easy. If you use something like an apple tv or fire tv you can even use a global search that links you into the app where the content you searched for lives. If you're willing to pay per episode or movie to rent or buy everything you watch on itunes or amazon, it's even easier and you can get almost anything instantly.
I do agree that in general, the more different streaming services are released the more that people's incentives are starting to tip back towards pirating. But I don't think there's much other reason beyond just cost.
Would you normally recommend running tekton in its own k8s cluster, or within the same cluster that runs production workloads? (Particularly if running in something like gke or eks)
It's a joke to say anything else. If a scooter can get hit by a car and mess up the car, we've gotta do something about this nuissance! If a scooter takes up 2 sq ft of space on a curb in between rides, they're ruining our streets! Capitalism run amok! But the entire row of cars parked for free a couple feet away? That's great. Not to mention, tens of thousands of lives lost every year? All good, nothing wrong with that.
It's also got absolutely nothing to do with people vs corporations, using that dichotomy here is absurd. Car makers spend hundreds of millions of dollars a year advertising to people to get them to buy more, bigger, more expensive cars. Not to mention, cars are even often leased or rented. I don't see why the business model of rental vs one-time purchase matters, but even if it does matter to you for some reason, cars and scooters are both rented!
IIRC the latest revisions of sb50 in California would have rezoned the whole state to allow fourplexes (while still upcoming even higher to 5 stories along transit corridors).
But it was blackholed for at least a year by the supreme chancellor of the senate (or whatever her official title is) even though it likely has enough votes to pass if it would have gone to the floor.
Even if the cost premium wasn’t an issue, who has the geometry in their living room to be able to take advantage of an 8k resolution? Even 4K is hard to take advantage of in a living room setting, you need a huge tv with your seating set up very close to it.
Biggest annoyance with the iMac though is you can’t, say, work from home with your work laptop and plug it into the screen.
This is another case with macs where the situation 8 years ago was much better since they used to have target display mode. From what I understand, they killed it because they needed to use a custom format to drive the 5k screen initially. Now regular DisplayPort 1.3 and 1.4 have enough bandwidth for it but there’s been no mention of bringing the feature back.
On this topic I am always surprised to notice, walking around downtown SF on a weekday that literally every single parking space is taken up by a work truck, like a contractor, repair person, plumbers, etc.
That’s pretty crazy when you stop to think about it. The space isn’t actively being used all day, I’m guessing these folks just know the right time to get there early after street cleaning to get a spot they can sit in all day because it’s cheap. Is there really no better use for this public space on some of the most expensive land in the world? Surely they could unload their equipment and then go park in a garage around the corner.
So to your broader point, yes obviously there needs to be some way to get heavy equipment, furniture, etc into cities. But there’s no reason it needs to be the extreme it is today, with so much priority given to private cars and parking.
Yes but I’ve never seen someone new to programming that bothered trying to figure out pyenv or similar. Even a lot of moderately experienced devs don’t bother with it. I guess it’s hard to realize the benefits of keeping environments organized until you’ve been burned by it.
It's honestly terrible for newbies. If they try to use it, there's no pip included. So then they easy_install all their libraries which installs things into different places than most python devs will be used to. Or they easy_install pip first. But even still, everything is installing to system paths, so when they try to install things it fails with permission errors. They find a stack overflow post that says just "sudo" everything and they go to town. And there's no way to reset anything when it gets borked either because it's the system install.
Compare that to "brew install python". Now you have the most up to date version, with the right permissions for your user, that you can always brew uninstall and reinstall later if you need a different version or a clean install.
I've been using iPhone and MacOS for years and successfully picking & choosing different parts of the ecosystem. Sure, the defaults are usually set up to opt you into their own products so it takes a bit of fiddling but it's not hard to opt into just the set of services you want to use - i.e. sync only particular services like iCloud Notes and password manager, but use gmail for email and calendars (using open formats to sync these natively to your phone), use dropbox instead if iCloud for file syncing, etc. It's very configurable and I don't feel particularly locked into anything.
And iMessage seems like a particularly bad example of lock-in because you can take your identifier (phone number) with you. If you switch from iOS to Android pretty much all that happens from a user experience perspective is your message bubbles are now green instead of blue when you text your friends with iPhones. It's very seamless between SMS and iMessages as far as messaging platforms go. To the extent that group threads with your family become harder, that's because group SMS sucks, not because you're locked in to iMessage.
It really seems like most of the time when people talk about lock in, all they mean is that the feature is particularly good. It does what I want and makes things easy, so there would be friction to change. How dare they build features like that!
Is the CEO really the best person to ask about such in the weeds details of the codebase, like how the choice of web framework is working out? The CTO seems like a much better choice but even they might be too far removed, I’d rather hear from a sampling of engineers and tech leads that are actually coding and solving technical problems in the app every day.
Interesting. Yeah, obviously the vested value is what matters to people at the end of the day.
In that case, maybe some kind of conversion view would be useful? Like splitting up: here is what you would expect an offer you receive today to look like (base, target bonus, and 4-year equity grant), and here is what your comp might look like at years 2, 3, or 4 at the company based on reported TC that factors in equity refreshers and recent stock appreciation.
My thinking is just that one of the obvious times when this tool is super useful is when you get an offer and you want to see how it compares to other offers the company has given out recently at the same level. But the offer you get will just be an initial grant and won't include stock appreciation or refresher grants (if there are target refresher grants, those would be listed separately in your offer). It would be cool if levels.fyi had some kind of normalized view to be able to do that direct comparison.
I guess I'm the only one that thinks USB-C is actually better?
The biggest win is that now I can use a single dongle for power, displayport to my monitor, and connection to a USB hub. So if I take my laptop home or into a meeting room, when I get back to my desk it's just a single thing to plug in now instead of 3+ separate cables. And since this stuff is all standardized now and there's no longer anything Apple proprietary like Thunderbolt 1, I would guess other makers will follow suit eventually and most monitors will support it directly without even needing a dongle.
Plus the MagSafe port was not without problems - every few months I would get like a little magnetic pebble or something stuck in there, and then it's plugged in but not charging charging and usually I'd realize when my laptop is almost dead and then have to find something small to try to pluck it out of there. The USB-C port doesn't have this issue and it's still a relatively small port with very low resistance to being pulled out. Tripping over the power cord just has never really been an issue for me, it kinda seems overblown (knock on wood though, I guess).
I do miss the external LED that showed whether you were connected to power or not and whether it was fully charged, it would be nice if they found a way to add that back on the side of the laptop or something since it can no longer be on the cable itself with a standard USB-C cable.
I find the site super helpful, so thanks for your work!
Have you considered letting people also report refresher equity grants? It would be interesting to see how they vary at different companies.
Another thing I’ve noticed on other tech career forums, is that a lot of people seem to report their equity based on the value it had once it vested rather than the value at the time of the initial grant, which obviously can inflate the numbers since the same growth isn’t guaranteed going forward. Any sense if this happens much with levels.fyi data?
I never understood this concept at all. Is this a metaphor somehow, or do you literally think everyone is secretly conspiring to make life more complicated for themselves and their team because of job security? What about the fact that everyone changes jobs every 1 to 3 years anyway? The market for engineers is pretty hot these days, I don’t think most devs even want all that much job security, much less are willing to go to such extreme lengths for it.
Have you considered that problems you’re not working on may actually have more inherent complexity than you realize?
From my own experience, and also just based on Ockham’s razor, it seems much more likely that people are mostly giving an honest effort and trying to solve real problems. Sometimes they succeed and sometimes they fail to solve the problem, or fail to recognize the right problem to work on, but overall real things are certainly getting done in the software world — new products launch and companies provide real value and gain real customers.
It’s sad that the idea of people being able to get by and live a comfortable life without the benefits from a full time job is so far outside the Overton window that it’s not even mentioned in these conversations.
That seems like such an obviously better outcome for everyone - what if we got rid of healthcare benefits and other types of favorable tax treatment that are tied to full time employment so that everyone is in the same boat? Then all contractors, including Uber and Lyft drivers could keep the freedom and flexibility of being contractors (which anecdotally, I have talked to a lot of drivers who really like this aspect of it), but also not struggle as much to get by?
(Universal healthcare is one path towards this world but not necessarily the only one, I think even the current healthcare system we have would work a lot better if premiums weren’t paid pre-tax by employers and people had actual choice and paid for their care with real money).
This is a pretty condescending take, and doesn't really seem rooted in anything substantial.
The core of your argument revolves around the inevitability of needing to drop down to raw sql for performance -- care to elaborate on that? It seems overblown, I've worked on some apps at decent scale and optimized quite a few queries and I haven't encountered this pattern of needing to throw out the ORM altogether in more and more places.
For any simple to moderately complex queries, the ORM is generating the exact SQL you would write by hand... There are a few pitfalls -- by default you may be fetching more fields than you absolutely need, but this is fairly cheap as long as your rows aren't super wide, and any good ORM offers an easy way to pluck only specific fields that you can use in hot paths. It's often easy to end up with N+1 queries in an ORM, but that's also a well-known access pattern that you learn to avoid with a little bit of experience and doesn't require raw sql. This latter is one area that I think a lot of ORMs could really improve upon, in terms of making it harder to do the wrong thing for inexperienced folks. But it's hardly a reason to throw out the whole tool, you can write n+1 queries in raw sql too.
I would agree that very complex queries can be more tedious to express in an ORM syntax. A good rule of thumb for when it's worth dropping down to raw SQL from the ORM, is if the shape of the query results don't match an object shape anyway -- i.e. for complex analytics type queries that are doing aggregations. But again I don't see much of an argument for throwing out the whole ORM just because you want to write a small percentage of very complex queries in raw sql. Use the best tool for the job. I don't think there's really al performance argument for these types of queries either, a really complex query can still be just as slow written in raw SQL. The solution to scaling these kinds of queries in a hot path tends to be denormalizing or precomputing or caching parts of the data.
I'm talking about literally day 1, not just like the first phase of the company. If a startup is exactly a single day (or single week) ahead of the competition such that the productivity on that day is make or break, that goes way beyond agility and is probably just not a very good opportunity.
SAML is just an authentication protocol, it doesn't really handle user provisioning. Which was confusing to me, because any time you'd use it you typically also need some kind of provisioning mechanism.
SAML does have a concept of "just in time" provisioning, which is what I've seen small SAAS companies typically support when they say they have SAML support. But basically all it can handle is creating accounts in the SP the first time a new person logs in (with valid credentials signed by the IDP). For user provisioning though what you really need is full programmatic CRUD access for accounts in the SP, which is outside the scope of SAML. I don't really understand why the SAML protocol bothers having such half-baked support at all, because you immediately run into issues. For example, giving some users different permissions than others in the SP, or updating accounts in the SP that already exist.
For user provisioning, for SPs that support it you can use the SCIM protocol alongside SAML, which gives you full control over provisioning accounts the way you need to. Then for instance instead of just logging someone out of the SP when they were removed from the IDP, it can fully deprovision the account in all your SPs as well so you're not left with orphaned accounts sitting around.