shimms

Ory stack has been working very well for us.

> What's the confusion here?

Acknowledging that developers are in fact customers, is often where it comes undone in my experience.

In a lot of places, only revenue paying people are considered customers, everyone else is a cost centre.

Dev tools are often seen as a tax the business pays to be able to generate revenue. Investing in them, or treating them like the production level systems they are, isn’t intuitive for most, and for some a hard cost to justify.

My very first purchase on eBay was to buy a used copy of Visual Basic 6 Enterprise Edition sometime while I was in school.

Then for a period of time I lost the physical CD it came with, and couldn’t install it anymore on a new system. Some time later I remember finding the CD at the bottom of some box of random stuff and being so happy - it was scratched up and didn’t reliably install, but I think I managed to burn a copy of it onto a new disk complete with inkjet printed sticky disk label that resembled the original disk.

Must had been mid/late 90s I think.

Had so much fun making stuff in VB back then.

This has been the case for ever. I recall opting to use Windows Server 2003 over XP back in the day for desktop/workstation use.

Could even enable XP themes IIRC.

It’s been a while (a decade?!) but if I recall correctly Capistrano did this for rails deployments too, didn’t it?

It’s not a simple plug in and stream product, but ever since replacing Sonos with Control4 we’ve been incredibly happy. Josh on top of it for voice and it “just works”.

As I said, not a direct comparison, but starting to think consumer level stuff like Sonos and HonePods just doesn’t have the right incentive structure anymore to deliver the level of quality we all seem to be asking for.

Half-Life, and Valve generally, were such a big part of my life in the late 90s and early 2000s. Exploring this definitely brings back a heap of memories.

Not sure if it is new or not, but really glad this history has been preserved.

I found some info on setting up DNS for other providers, but it isn’t officially supported and for something as important as email I don’t want them randomly breaking it one day, which they could since they expect all customers to be configured through their API integration with GoGaddy. No need to advise in advance of MX host changes etc when it’s supposed to be entirely managed by them.

I understand their target demographic here might not be super technical, so the deep integration with godaddy makes sense, but would be nice for a supported advanced user pathway too.

We just went down the rabbit hole of trying to migrate to Microsoft 365 Family with custom domain. You (officially) need to move your domain to GoDaddy, which was unfortunately a blocker for us as they don’t support our domains TLD.

From what I read DKIM also isn’t offered on Family which is disappointing. Business plans get expensive quickly when you want Office apps as well.

Mercedes EQA.

v11 update was the straw that broke this Tesla owner's back. We just purchased a new EV from another manufacturer and are selling the Tesla.

I'm so glad there are an increasingly larger range of EVs to choose from. In Australia the choices are comparatively limited still, but more and more are becoming available. When we got our Tesla the choices were really Tesla or cars with really limited range.

I used to think I'd get used to the touch screen and muscle memory would allow me to do things while driving easily. Hasn't happened - I use the steering wheel buttons for changing the temperature, but everything else requires taking my eyes off the road for too long.

Test drove the new car and was surprised by how better physical buttons were. The cognitive load to drive it was so much less. After years of Tesla touch screen land, I think I'd forgotten how much easier and usable traditional interfaces are.

There is an expectation that during core working hours people will be somewhat responsive. That will differ org to org, and perhaps in your org there are no set working hours. In that case my current approach probably doesn’t hold as much.

My experience has been that simply telling them not to feel obliged to respond doesn’t really cut it, and people feel obligated regardless. This may be a cultural thing too, and again will probably differ company to company and region to region.

I’m talking about the opposite where you are the boss. I don’t send emails at night so my staff don’t feel the expectation to be constantly checking and replying to me. Just because I work weird hours doesn’t mean I expect my staff to.

If one of my team sends too many emails at weird hours I’d make a point of talking to them about their workload and life balance at an upcoming 1:1 to make sure things aren’t getting too off track.

It sets the expectation for a lot of people that they should be checking and responding to messages at all hours.

I’m a night owl, I like to do thought work after the day of busy meetings. I don’t want my direct reports feeling like I expect them to reply at 11pm when I send them an email, or on Sunday if I’m working. So I schedule it to arrive in the morning or in the next work day instead.

You can tell them until you’re blue in the face, but actions speak louder than words.

My current box of books that I recommend to new managers on my teams:

Technology Specific:

* An Elegant Puzzle: Systems of Engineering Management (Will Larson)

* Accelerate: The Science of Lean Software and Devops: Building and Scaling High Performing Teams (Nicole Forsgren, Jez Humble, and Gene Kim)

* Team Topologies: Organizing Business and Technology Teams for Fast Flow (Matthew Skelton and Manuel Pais)

* Empowered: Ordinary People, Extraordinary Products (Marty Cagan)

* The Phoenix Project (Gene Kim, Kevin Behr, George Spafford)

General:

* The Goal (Eliyahu Goldratt)

* Turn the Ship Around! (L David Marquet)

* Just Culture (Sidney Dekker)

* Leadership on the Line (Ronald Heifetz, Marty Linsky)

* Emotional Intelligence (Daniel Goleman)

The town of Mallacoota is essentially surrounded by a moat of fire at the moment. The residents are trapped inside this ring, one part of which is the ocean. The Navy, as well as supplying, are evacuating people off the beach as there is no other safe way out of that part of the country at the moment.

Have you checked out Sorbet?

I was complaining about this with a coworker today. AirDrop 1 was flawless, since 2.0 it has been more often than not unreliable between Macs.

I’d love to know if anyone knows the technical details about what caused this regression?

Up, a relatively new digital bank in Australia does this already - I had my card setup in Wallet about 2 minutes after signing up online, a full week before the physical card arrived.

Nope I’m the same, my 2018 MBA keyboard is the best keyboard I’ve used, and I loved the old Thinkpads too. The 2016 MBP keyboard on the other hand is terrible.

I print my stuff on actual paper and do a manual proof read when I think I’m done. I’m constantly surprised by how many spelling mistakes I still find during final proof reading that Word isn’t underlying with red squigglies.

TFS/VSTS/DevOps (Microsoft)

I check hacker news regularly and this was the first time I saw it. Reposts aren’t inherently bad. I’m glad it was reposted and I’ve now had the chance to learn about it.

DevOps toolchain you've got covered. Your pipelines are pretty neat.

One thing I really like about GitLab is seeing pipeline errors in the merge request. For instance, we have rspec bubble up failures and they're right there in the test summary on the merge request. GitLab shows us a check failed, but we have to click through to Circle CI to see what the actual failures were.

One thing GitHub does well is the idea of checks. The entire pipeline in GitLab is a binary pass or fail. To see which bits failed, you have to dig into the pipeline.

Would be great to see that (similar to test results) in the merge request, in a similar way that GitHub checks are displayed.

Our typical DevOps set up is Jira for issues, GitHub for source and peer reviews. The pull requests are set up to include a few things like Quality (usually Code Climate), CI (usually Circle CI, sometimes Buildkite), a security auditor, a dependency auditor etc. At the other end, we use a service like Codefresh or whatnot to handle deployment to our environments.

Obviously, GitLab does all this in one ALM, which makes it closer to Azure DevOps than GitHub for direct feature comparisons, so this is more about the source code peer review through merge/pull requests than other aspects of the ALM process.

In GitHub pull requests, when checks fail, we get immediate visibility right on the pull request screen which checks failed, rather than having to go into the pipeline to look at jobs.

From a DevOps perspective, GitLab far exceeds GitHub (obviously). From idea to code, to review to build and publish is great. The pipelines (as I said above) are good.

I'd just like more integration points in the merge request process for external services to augment the functionality provided out of the box, such as Code Climate, Hound, Dependabot, LGTM/GuardRails/Snyk etc. Whilst you can wire these up (kinda) yourself - you could just use rubocop instead of Hound - you don't get the deep merge request integration. When Hound finds a rubocop violation it adds a contextual comment on the pull request at the line of code that is offending. In GitLab with rubocop, you simply fail the pipeline and then trawl through log output.

As I said in reply to sytse above, I think that is the main difference between cultivating a thriving eco-system of integrations vs providing an API and instructions.

Thanks for the reply sytse.

I don't think it's fair to say that GitHub has more simply because it has less built-in functionality as compared to GitLab.

I agree that GitLab has broader functionality than GitHub, but it isn't so broad as to cover the breadth of functionality provided by all of GitHub's integrations combined.

Code Climate is a good example - yes you're right you have builtin quality reports, but setting it up is significantly more complex than on GitHub, and as an example serves to illustrate what I see as the very different attitudes and approaches towards building an eco-system.

Referring to your docs on code quality[1], you need to edit the CI configuration file, understand what a docker-in-docker executor is on runners etc.

Compare this to GitHub's Code Climate integration[2]: single button "Set up a plan" that guides you through s small number of screens and links your account and presto done.

Things that successful marketplaces like Heroku, GitHub, Atlassian, Slack etc get right are the ease with which to add integrations and the seamlessness of the experience.

Single button provisioning, combined billing, single sign-on etc. Just the way GitLab position the idea of integrations makes it seem to me that creating a platform isn't a priority for you (which is totally fine obviously, you're focusing on your priorities, and clearly doing pretty damn well doing so).

GitHub makes their marketplace and integrations front and centre, have extensive developer guides, etc. GitLab's are a bit more... spartan. They're lacking any real spark, they're not inviting. Compare your overview[3] page to the best equivalent I think I could find on GitHub[4]. They're chalk and cheese.

Again this isn't to say GitLab's approach is wrong, its just a different focus.

More specific feedback (and this may have changed since we evaluated it a year ago) a GitLab integration could only perform API actions as a real user of a GitLab account. We wanted to build an integration that would add comments to merge requests, but not be attributed to a real user, but a bot user for the integration. That wasn't (or at least wasn't easily discoverable) possible back then, and was a show stopper for our integration.

1: https://docs.gitlab.com/ee/ci/examples/code_quality.html 2: https://github.com/marketplace/code-climate 3: https://about.gitlab.com/partners/integrate/ 4: https://developer.github.com/

I want to like GitLab, but the (comparative) lack of integrations is a showstopper.

For instance in our Github, Code Climate runs against all pull requests and adds comments on files when it detects quality issues (as a bot user).

I get this is up to companies like Code Climate to build, but having done a bit of integration building myself, the platform and marketplace strategy at Github is just so much more mature and thought out. The GitLab marketplace/integrations capability feels very much like an afterthought (no bot users for one thing).

Would love to see GitLab focus on making a broader platform & marketplace play, and working with big ecosystem players to really enhance the GitLab offering.

Two things:

The demand for the semi-premium model outweighed the standard by 6 to 1, so no, the demand is right where the new obvious entry model is.

It is still technically available, but not in any obvious way (if you weren’t to already know, it’d be fair enough to assume it wasn’t available anymore).

In my area you are required to update our roads authority within 14 days of changing address, and they send you a sticker to put on the back of your current license card.

Yup - we’ve always duplicated that data in our systems. Aside from anything, if Stripe/payment-processor-of-choice changes their data model, or rearranges feature tiers in the future to make reporting beyond the last 180 days an enterprise add on or whatever, we’d rather not be beholden to them to be able to analyse our business performance metrics.

From experience, associating an account directly to their current plan in this was adds some complexity in being able to have a history of plan changes (downgrades/upgrades etc). You might be accommodating for this in other ways, but a typical setup I've seen is to add a "subscriptions" table between account and plan.

The account has many subscriptions, only one of which can be the current. The subscription is linked to a plan.

When a customer upgrades, the current subscription ends, and is replaced by a new one. Tracking start and end dates helps with churn and upgrade/downgrade metrics reports, such as time on premium before downgrade etc.

I've also been stung before by checking for a specific plan, as opposed to checking for the abilities or attributes of the current plan. In your example you're checking if the plan name is "trial" to determine if they should have trial limitations put upon them. This becomes tricky if you need to introduce a new trial option, named differently in the future, that needs to co-exist with your current single trial plan set up. I'd prefer to be checking "is the current plan a trial" or ideally link them to a real plan, but check if it is "in trial" (via dates, boolean etc).

I've seen (but not done myself) products that let you move up and down between plans during trial so you can really assess the impact of not having feature available on higher plans. Doing this is impossible with a single plan called "trial".

Subscription billing, dunning, pro-rated upgrade, taxes, discounts etc is a ridiculously complex set of functionality.