EugeneTheDev

import androidx.compose.animation.core.*
import androidx.compose.foundation.background
import androidx.compose.foundation.layout.*
import androidx.compose.foundation.shape.CircleShape
import androidx.compose.material.MaterialTheme
import androidx.compose.material.Text
import androidx.compose.runtime.Composable
import androidx.compose.runtime.getValue
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier

xavierLowmiller

import SwiftUI

public struct Shimmer: AnimatableModifier {

    private let gradient: Gradient

    @State private var position: CGFloat = 0

    public var animatableData: CGFloat {
        get { position }

swiftui-lab

// Authoer: The SwiftUI Lab
// Full article: https://swiftui-lab.com/scrollview-pull-to-refresh/

import SwiftUI

struct RefreshableScrollView<Content: View>: View {
    @State private var previousScrollOffset: CGFloat = 0
    @State private var scrollOffset: CGFloat = 0
    @State private var frozen: Bool = false
    @State private var rotation: Angle = .degrees(0)

sleepyfox

'Users hate change'

This week NN Group released a video by Jakob Nielsen in which he attempts to help designers deal with the problem of customers being resistant to their new site/product redesign. The argument goes thusly:

1. Humans naturally resist change
2. Your change is for the better
3. Customers should just get used to it and stop complaining

There's slightly more to it than that, he caveats his argument with requiring you to have of course followed their best practices on product design, and allows for a period of customers being able to elect to continue to use the old site, although he says this is obviously only a temporary solution as you don't want to support both.

swlaschin

Architecture

• Use Onion architecture

  • Dependencies go inwards. That is, the Core domain doesn't know about outside layers

• Use pipeline model to implement workflows/use-cases/stories

  • Business logic makes decisions
  • IO does storage with minimal logic
  • Keep Business logic and IO separate

• Keep IO at edges

fphilipe

solnic

Calculating -------------------------------------
ActiveModel::Validations
                       134.000  i/100ms
      dry-validation     2.145k i/100ms
-------------------------------------------------
ActiveModel::Validations
                          1.499k (±11.5%) i/s -      7.504k
      dry-validation     22.300k (±10.5%) i/s -    111.540k

Comparison:

rbobbins

PS: If you liked this talk or like this concept, let's chat about iOS development at Stitch Fix! #shamelessplug

Protocol-Oriented Programming in Swift

Speaker: David Abrahams. (Tech lead for Swift standard library)

• "Crusty" is an old-school programmer who doesn't trust IDE's, debuggers, programming fads. He's cynical, grumpy.

• OOP has been around since the 1970's. It's not actually new.

• Classes are Awesome

  • Encapsulation
  • Access control

swlaschin

// General hints on defining types with constraints or invariants
// 
// Just as in C#, use a private constructor 
// and expose "factory" methods that enforce the constraints
//
// In F#, only classes can have private constructors with public members. 
//
// If you want to use the record and DU types, the whole type becomes
// private, which means that you also need to provide:
// * a constructor function ("create").

mattt

struct Complex<T: FloatLiteralConvertible> {
    var real: T
    var imaginary: T
}

func +(lhs: Complex<Double>, rhs: Complex<Double>) -> Complex<Double> {
    return Complex<Double>(real: lhs.real + rhs.real, imaginary: lhs.imaginary + rhs.imaginary)
}