CodingItWrong

Original version: https://support.2k.com/hc/en-us/articles/360058975454-Borderlands-3-Transferring-Character-Saves-from-PS4-to-PS5

(typos corrected below)

1. To start, on your PS4, make sure you have your save file uploaded to the PlayStation cloud. If you aren't sure, go to Settings, then "Application Saved Data Management", then "Saved Data in System Storage", then "Upload to Online Storage", then "Borderlands 3". Choose your save then choose Upload.

All the remaining steps are on the PS5.

2. On your PS5, go to Settings > "Saved Data and Game/App Settings"
3. Delete all the Save files you have locally stored on the PS5 for both game versions: PS4 version and PS5 version.

CodingItWrong

# http://bit.ly/jest-snippets

'.source.js':
  'Jest Async Test':
    'prefix': 'jitasync'
    'body': """
      it('$1', async () => {
        $2
      });
    """

CodingItWrong

JavaScript TDD Live Stream - Dec 22, 2000

Join me at 5 PM ET on my Twitch channel!

Today we'll be working on a code exercise from the JavaScript track of Exercism.io called "D&D Character". In this exercise, we write a class that allows us to generate a character for a role-playing game with random values for different character attributes.

Like all Exercism exercises, this one comes with a prewritten set of tests to guide us. But this time the tests aren't written in the Test-Driven Development style I prefer. We'll look at the tests to see how they aren't enough to fully specify the behavior we want. It's hard to do so when random values are involved! So we'll look at ways we can think about splitting up what is under test and what is not. Along the way we'll uncover an abstraction that will make our tests easier to understand.

[My Solution on Exercism.io](https://exercism.io/tracks/javascript/exercises/dnd-character/s

CodingItWrong

// option 1
() => {
  return call1().then(response1 => {
    return call2(response1.field);
  }).then(response2 => {
    console.log({ response1, response2 }); // response1 not in scope
  });
};

CodingItWrong

“What parts of this app are the most awkward or thorny?”

• Requiring parens after the decorators for Ember Data attr/hasMany is inconsistent with other Ember decorators; will be nice when those are no longer needed
• I forget why I’m using .set() and pushObject() on Ember Data models. They might not be required, but if it is, that’s not ideal because inconsistent—it’ll be good when we can use assignment and push() everywhere.
• I ran into an issue where I tried to have a computed property based on an Ember Data ID, but its ID is not tracked, so I needed to use .get(). This inconsistency was unintuitive. emberjs/data#6393
• I’m always loading core data in routes but saving changes in components. Routes have the store available automatically but components need it injected.
• Having to return RSVP.hash for multiple model calls rather than Promise.all is not ideal; it’d be nice to be on the JS standard. (Not 100% sure if I need to use RSVP.hash, but at some point I understood t

CodingItWrong

Hey y’all, I have a couple of questions in response to Episode 31, “You can only code so fast.” Maybe they’d make interesting followup discussion.

The question addressed is “what comes after senior?” You mentioned at the end of the episode that you don’t necessarily need to be looking to move beyond senior, but the gist of the convo implied that most devs most of the time would. I want to dig into that a bit more:

• You mentioned the idea "I can't get paid any more to keep doing what I'm doing right now." I’m privileged to be paid pretty well. Am I a crazy outlier that I don't think I need more money than I'm making right now?
• Do you think that most developers will always want to continue to be challenged in new ways? Do most developers never reach a point where they say "what I'm doing here is great, I want to continue doing what I'm doing in different arenas and for different people?"

As far as when people do want a new challenge, the two categories you mostly discussed were deeper IC computer-

CodingItWrong

// see https://vue-apollo.netlify.com/guide/apollo/mutations.html
{
  addTag() {
    // We save the user input in case of an error
    const newTag = this.newTag
    // We clear it early to give the UI a snappy feel
    this.newTag = ''
    // Call to the graphql mutation
    this.$apollo.mutate({
      // Query

CodingItWrong

Inspired by this exchange:

@rickhanlonii: My phone autocorrects in-n-out to --no-config it's probably okay

@CodingItWrong: There are a lot of configuration-heavy burger places these days

• React: You just get the hamburger patty because we want it to be edible by the widest possible variety of people. How can we know in advance how you want to eat it?
• Preact: less than three calories and just as tasty as React to most people's tastebuds.
• Vue: we include the pieces that most burgers will need: the patty, the cheese, and the bun. Everyone can add the condiments they already like.
• Ember: the burger will be more delicious if all of us focus on improving one recipe.

CodingItWrong

import React, { Component } from 'react';
import {
  TextInput,
  View,
} from 'react-native';

export default class NewMessageForm extends Component {
  render() {
    return (
      <View>

CodingItWrong

import React, { Component } from 'react';
import {
  View,
} from 'react-native';

export default class App extends Component {
  render() {
    return (
      <View>
      </View>