Списки захвата в Swift: в чём разница между ссылками weak, strong и unowned?

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

Для reference типов особо смысла нет, а для value типов есть.
https://docs.swift.org/swift-book/ReferenceManual/Expressions.html#ID544

Списки захвата в Swift: в чём разница между ссылками weak, strong и unowned?

Согласен, недоглядел. Но смысл в том, что [numberOfLinesLogged] захватывает значение переменной. У вас в статье это не указано.

var numberOfLinesLogged = 0

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

numberOfLinesLogged += 1

logger1()

Списки захвата в Swift: в чём разница между ссылками weak, strong и unowned?

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

var numberOfLinesLogged = 0

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

Использование ReSwift: написание приложения Memory Game

Я правильно понимаю, что при любом изменении состояния, оно каждый раз полностью перестраивается?
И еще я вижу это рекомендуемая практика хранить в состоянии коллекции данных. Это нормально смотрится для сингл пэйдж приложения. Но если у меня много экранов, получается состояние хранит наборы неиспользуемых данных. Или они как-то подчищаются?

Инструменты для прототипирования на Mac: сопоставительная характеристика

Для mac и ios разработчиков отличный инструмент для прототипирования — XCode. Бесплатный и нативный инструмент.

Оптимизация рендеринга веб-страницы

Поэтому нет никакого «официального» описания как этим правильно пользоваться.

Вообще-то есть. CSS свойство will-change позволяет сообщить браузеру об изменениях, которые будут применены к элементу.

Symfony2: logging out

Файрвол, фейрверк, плейр, конвейр, андройд

Тестирование производительности популярных (и не очень) CMS

Ну например:

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() {}
}

Тестирование производительности популярных (и не очень) CMS

вот эту копипасту

    public static function getInstance() {
        if(is_null(self::$instance)) {
            self::$instance = new self();
        }
        return self::$instance;
    }

неплохо было бы сократить, используя позднее статическое связывание

jQuery State form или простой контроль за формой

Однажды сделал похожий плагин github.com/claustrofob/FormObserve. Состояние формы сохраняется простым form.find(':input').serialize().

Организуем выделение текста в textarea

И «propertychange» для IE, который либо не понимает либо хреново понимает «input».

simpleTooltip: HTML начиненный CSS и приправленный jQuery

Странное решение добавить статичный метод к $, а не стандартно плагином $.fn. А как вешать тултип на динамически добавляемые элементы?

Мобильная веб-разработка: жесты, фреймворки, цифры

Мультитач в андроиде появился с версии 2.2

Вышел в свет Zend Framework 2 stable

ключ.третьего.уровня = значение

Вышел в свет Zend Framework 2 stable

Однажды на хабре уже развенчали миф про то, что конфиг на чистом php быстрее habrahabr.ru/post/112402/. Ini-файлы и JSON быстрее массивов на PHP.

Input attribute placeholder

Кстати, на мой взгляд, ставить лабел под инпут, а не поверх него, более лучшее решение. Это позволит прятать лабел не при фокусе, а только когда в инпут был вставлен текст, именно так, как ведет себя дефолтный placeholder в последних версиях хрома. В свое время накатал плагин с таким подходом github.com/claustrofob/Default-Text.

Как лучше хранить хэши паролей

Соль уникальна, а хэш нет. Т.е. теоретически можно для данной соли подобрать пароль, который даст в итоге нужный хэш.

Как лучше хранить хэши паролей

А вообще, мы можем взять любой хэш из таблицы, и брутфорсить его по старой схеме. Теоретически, если мы увели таблицу юзеров с солью, то достаточно знать хотя бы один хэш из таблицы хэшей, чтобы взломать все пароли.

Как лучше хранить хэши паролей

По-моему, вы неправильно считаете.
При обычной системе нам придётся генерировать все хэши самостоятельно и сравнивать его с тем едиственным, который привязан к юзеру. С новой системой у нас намного выше вероятность угадать пароль для каждого сгененированного нами хэша. Скорость поиска хэша в таблице с индексами будет относительно стабильной с ростом базы, а скорость генерации хэшей будет пропорционально расти.
А в сочетании с медленным хэшем, новый способ очень ускорит подбор.

Как лучше хранить хэши паролей

Все равно не понимаю, чем сложнее подобрать пароль к любому из миллиарда хэшей, чем к одному? Получается, растёт размер базы и уязвимость. То, что такую базу на флэшке не унести, сомнительное преимущество.