Pull to refresh
47
0
claustrofob @claustrofob

User

Да, и мне не совсем ясен смысл capture list вообще без модификатора unowned или weak, ведь как раз его смысл — избегать циклов сильных ссылок.

Для reference типов особо смысла нет, а для value типов есть.
https://docs.swift.org/swift-book/ReferenceManual/Expressions.html#ID544
Согласен, недоглядел. Но смысл в том, что [numberOfLinesLogged] захватывает значение переменной. У вас в статье это не указано.
var numberOfLinesLogged = 0

let logger1 = { [numberOfLinesLogged] in
    print("Lines logged: \(numberOfLinesLogged)")
}

numberOfLinesLogged += 1

logger1()
Нужно было упомянуть и о capture list. Случай 4 тогда лечится таким способом:
var numberOfLinesLogged = 0

let logger1 = {[numberOfLinesLogged] in
    numberOfLinesLogged += 1
    print("Lines logged: \(numberOfLinesLogged)")
}
Я правильно понимаю, что при любом изменении состояния, оно каждый раз полностью перестраивается?
И еще я вижу это рекомендуемая практика хранить в состоянии коллекции данных. Это нормально смотрится для сингл пэйдж приложения. Но если у меня много экранов, получается состояние хранит наборы неиспользуемых данных. Или они как-то подчищаются?
Для mac и ios разработчиков отличный инструмент для прототипирования — XCode. Бесплатный и нативный инструмент.
Поэтому нет никакого «официального» описания как этим правильно пользоваться.


Вообще-то есть. CSS свойство will-change позволяет сообщить браузеру об изменениях, которые будут применены к элементу.
Файрвол, фейрверк, плейр, конвейр, андройд
Ну например:
abstract class singleton {

    public static function getInstance() {
        static $instance = null;

        if(is_null($instance)) {
            $instance = new static();
        }
        return $instance;
    }

    protected final function __construct() {}
    protected final function __clone() {}
    protected final function __wakeup() {}
}
вот эту копипасту
    public static function getInstance() {
        if(is_null(self::$instance)) {
            self::$instance = new self();
        }
        return self::$instance;
    }


неплохо было бы сократить, используя позднее статическое связывание
Однажды сделал похожий плагин github.com/claustrofob/FormObserve. Состояние формы сохраняется простым form.find(':input').serialize().
И «propertychange» для IE, который либо не понимает либо хреново понимает «input».
Странное решение добавить статичный метод к $, а не стандартно плагином $.fn. А как вешать тултип на динамически добавляемые элементы?
Мультитач в андроиде появился с версии 2.2
ключ.третьего.уровня = значение
Однажды на хабре уже развенчали миф про то, что конфиг на чистом php быстрее habrahabr.ru/post/112402/. Ini-файлы и JSON быстрее массивов на PHP.
Кстати, на мой взгляд, ставить лабел под инпут, а не поверх него, более лучшее решение. Это позволит прятать лабел не при фокусе, а только когда в инпут был вставлен текст, именно так, как ведет себя дефолтный placeholder в последних версиях хрома. В свое время накатал плагин с таким подходом github.com/claustrofob/Default-Text.
Соль уникальна, а хэш нет. Т.е. теоретически можно для данной соли подобрать пароль, который даст в итоге нужный хэш.
А вообще, мы можем взять любой хэш из таблицы, и брутфорсить его по старой схеме. Теоретически, если мы увели таблицу юзеров с солью, то достаточно знать хотя бы один хэш из таблицы хэшей, чтобы взломать все пароли.
По-моему, вы неправильно считаете.
При обычной системе нам придётся генерировать все хэши самостоятельно и сравнивать его с тем едиственным, который привязан к юзеру. С новой системой у нас намного выше вероятность угадать пароль для каждого сгененированного нами хэша. Скорость поиска хэша в таблице с индексами будет относительно стабильной с ростом базы, а скорость генерации хэшей будет пропорционально расти.
А в сочетании с медленным хэшем, новый способ очень ускорит подбор.
Все равно не понимаю, чем сложнее подобрать пароль к любому из миллиарда хэшей, чем к одному? Получается, растёт размер базы и уязвимость. То, что такую базу на флэшке не унести, сомнительное преимущество.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity