Just clarifying ... they took a version of master from say a month ago, did their work on it, then, they force pushed their work out, wiping everyone else's work that was added to master since one month ago?
I mean that's the equivalent of reversing your JCB through a house on a building site because "the house was not there a week ago when I last moved the JCB".
Basically equivalent to that. This was about a decade ago.
We had 4 teams, each released on a schedule. Each team had a branch. When a team released, it was merged from master, then each team pulled. The person who did the pull would change, and it was often a rebase.
So my team released, some other team rebased badly. There would be no sign of problems for us until after they released. But since 2 teams generally released at once, and people didn't remember who actually did the merge a few weeks earlier, it was hard to figure out who was actually messing up. (I had suspicions, but no proof.)
I've seen rebase used appropriately since. But that disaster left scar tissue.
So (sorry for picking on this scab) there became 4 branches each of which for the team concerned was the next beautiful branch and then say each week a team woukd merge into master and everyone woukd rebase but fuck that up once and now the beautiful branch team B is working on is out of step with the real master ... oh god.
It looks like you’re talking about rewriting history that has already been shared. Pretty much everyone agrees that is a bad idea. It even has a prominent warning in the git book.
What others here, including myself, are advocating is rewriting your own history before you share it, which makes a very different set of trade-offs.
How do you find the right commit from a month ago to reflog to?
How do you determine which combination of changes are yours, and not accidentally undo changes that other developers made in the last month?
Could git reflog have helped? Maybe sometimes. If we had the foresight to have saved the right commits from the past, sure. I think we did start saving old branches just in case it happened again, but then we had to sort through a month of changes to figure out what to keep, what to change, and what conflicts there might be.
Remember, the person screwing up didn't know he screwed up. And the person trying to fix it is doing so a long time after the fact. It was a disaster.
If the tool they use to make their game requires customers to install malware onto their machine you can't really blame the customer for avoiding software that is built with said tool.
Is there any indication all of the IronSource or other ad stuff will not be optional?
Not allowing developers to remove it from their games would certainly be a step too far (at this time anyway, who know what will they come up with in a couple of years).
The problem is that there is no way to trust that Unity will not alter the deal in an underhanded way in the future. I do not want my purchases beholden to their capricious whims. I sympathize with the devs, but sometimes it turns out that platform decisions made in the past are bad. It is what it is.
True, but there are certain things (e.g. including spyware in games not using their analytics and/or ads solution) some of their important customers would never tolerate. Then again they might just make no-"spyware" a "feature" only available in enterprise versions...
I went through a phase about a year ago where I started all my hobby projects in Crystal. It was a pretty fun exercise but I stopped eventually for the following reasons:
- Ultimately, I ran into some bugs with things in the standard library. There's still a lot of warts and a lot of vague error messages. Hopefully this has improved since I last touched it.
- No windows support. Much of my hobbyist time is spent dabbling with gamedev so it always felt like eventually this would be a dealbreaker.
- I found it hard to grasp some of the type grammar. Mixing the looseness of Ruby syntax with strict typing can sometimes result in weird ergonomics.
That said, I think if/when it matures further I plan on going back to it. Macros were really cool and at the end of the day I just really like working in ruby style languages. The community was also super helpful on Discord.
The windows support is a killer, but I think they’ve been working to improve it. 95% of workstations at my office are Windows, so there’s that’s a huge missing market share.
I still say that the initial lack of good windows support by Ruby was a major reason that Python “won”.
All banks work in the free Development environment, but for banks on OAuth, including Chase, you need to go through the Production approval vetting as a pre-requisite. Once you've been approved for Production (and if applicable for the given bank, gotten your security questionnaire approved as well -- I think Chase requires this) you can then access those banks in Development for free.
I'm in the middle of going down this path right now. It kind of works, except for certain banking institutions require more rigor than just getting accepted into the developer platform.
The steps, as far as I can tell, look something like this:
1) Sign up for Plaid developer account
2) Request developer access (without it you can only play with sandbox data)
3) Request production access
4) Submit application information including a name, website URL, and logo
5) Add a legal company entity name and address to my plaid account
6) Sign an MSA contract (no idea what its about)
7) Fill out a security questionnaire.
I'm at step 3 currently but I'm not sure how much further I'm realistically going to get. I'm not sure I could reasonably fill the rest without stretching the truth quite a bit and it seems to get deep into legal territory that I'm not sure I'm comfortable with.
I will say that while annoying (especially for Chase, which has the most paperwork-type requirements for developers) this process should be totally doable for solo developers. You can put your own name as the legal entity name if you don't have a company. The Master Services Agreement (MSA) sounds scary but is just the contract between you and Plaid -- the legalese laying out what you're paying for, what Plaid is providing, and the rights and obligations of both parties. And when it comes to the security questionnaire, fill it out as accurately as you can, but you don't need to stress over it -- Plaid doesn't expect a solo hobbyist to have the same security measures as, like, a publicly traded company.
Can confirm: I did this as a solo user of a personal API integration with Chase via Plaid. I answered honestly given the scope of what I was doing: for example, IIRC there was a question about whether all employees are background checked, and another about how we deal with terminated employee access. As the only user/employee/human, I could confidently say I background check all my employees and that if they’re terminated, their access will be promptly revoked :D
Thank you! I wish Plaid would document this on the website. I've always been hesitant to convert from my dev account to a production account because everything gives the impression you're looking for a Serious Business.
I'd much rather just pay the money and have the standard API, and my workflows are all built around Plaid anyway.
I spoke with a lawyer earlier tonight. Basically, there are no next steps for me. The next steps for them are to send targeted discovery requests for whatever it is they think I might have in relation to the case, and possibly ask me to testify in a deposition.
I don't feel that way. I went through a pretty big exercise slump over covid and I bought an apple watch at the start of 2021. If you make your goals modest at first, the numbers will be easy to hit and every couple of weeks the fitness app will suggest you raise them - if you raise them each time it suggests, you'll eventually hit a manageable goal where you're spending 30-60 minutes exercising per day.
The gamification aspect was really good for me to get off the couch and actually do something but now that I have good habits going I naturally enjoy the extra walk/yard work/gym workout. I don't really pay that much attention to my daily goals anymore, but if I look down and it's 4 PM and I see that I'm a bit short on today's exercise goal, I might consider taking the dog for a second walk or making an unplanned trip to the gym. It's not the end of the world if I don't make it, but it's pretty cool when the month ends and I get the "you hit your exercise goal every day for august" notification.
I actually don't relate to this statement at all. My college courses were filled with Python, Java, and C#. I loved python. I hated C# and Java even more. I learned PHP in my own free time. I then went on and happily cut my teeth on dynamic languages for the next decade.
I dabbled occasionally with typed languages, but it wasn't until Typescript was forced upon me by a respected coworker that I was able to recognize type safety as a net-win for development speed. Seeing an entire class of problems disappear in a codebase rife with them was an eye opening experience.
I briefly took a ruby job a little over a year ago and I missed type safety quickly. Despite how much I love Ruby, I love tracing through code paths to understand what a variable is a lot less.
But dhh didn’t say that. He said that very few programmers, not all, don’t like having their opinions changed in typing. He didn’t say they don’t like it when it happens on their own, they don’t like it when others try to do it. At least that what dhh says. Not saying I agree.
You can’t just read something, change it’s meaning and then argue against it.
> very few programmers are typically interested in having their opinion on typing changed. Most programmers find themselves drawn strongly to typing or not quite early in their career, and then spend the rest of it rationalizing The Correct Choice to themselves and others.
IME, my story doesn't seem to be that unique among typescript advocates thus I do not relate to DHH's statement.
I think typescript's type inference and structural typing is a big part of how it doesn't get in the way of writing code. I've always preferred the safety of static language, but understood the productivity benefits of dynamic languages. With typescript I feel I get the best of both worlds, as you only need to add types where they're vague, and structural types let you express more in objects without needing heavier class polymorphism all over the place.
Vue3/composition API -- probably the simplest if you're coming from React. Definitely feels like it was inspired by hooks.
Svelte/store -- svelte has a term called 'hook' but it's unrelated. The equivalent would be Svelte's store.
The other frameworks use something called 'Signals' (Preact, Qwik, Solid, Elm and even Angular/backbone though I don't personally have in depth knowledge of all of these).
IMO, I would prefer Svelte if you are adventurous, or Vue if you like React but just want something like 'better React'.
I mean, Svelte/store is something completely different though, isn't it? it's more akin to Jotai/Zustand/Redux and friends than it is to hooks. If you had to compare Svelte with React, the thing "closest" (while stretching that word very much) to hooks would be the `$` reactivity things Svelte does? Because if you want a state management solution, react has that as well (many, in fact). Just not built in, and a lot of them work really well
Wouldn't this be trivially solvable by git bisecting your deploy branch?