Мне не нова магия Flexbox, но я не часто ее использую, и поэтому после паузы в использовании мне приходится открывать вот этот пост на CSS-Tricks чтобы освежить память.

Я решила создать краткую визуальную шпаргалку по Flexbox для тех случаев освежения памяти после паузы в будущем. Думаю, что у меня получилась шпаргалка, основанная на… шпаргалках.

Редкий разработчик под iOS или OS X не использовал сториборды и еще меньше программистов не передавали данные между экранами.
Все мы знаем метод performSegueWithIdentifier и трудности работы с ним.

Начав проект на Swift в один момент мне стало обидно: «Почему мы должны в строго-типизированном языке использовать обертку для передачи данных?»
Через пару минут сформировалось видение решения и в скором времени реализация.

Долго думал, стоит ли писать об этом, поскольку материал крайне небольшой, но эти 50 строк могут вам очень сильно помочь

menuController?.performSegueWithIdentifier(changeItemIdentifier, sender: nil) { segue in
    let controller = segue.destinationViewController as! ChangeMenuItemController
    controller.viewModel.sourceMenuItem = item
}

Таким образом, легко использовать сториборды и роутеры вместе. Устранить разрастание prepareForSegue и увеличить контекст чтения кода. В то же время это не вынуждает отказываться от prepareForSegue при удобных ситуациях.

Разберемся как это работает? Не претендую на уникальность, но мне кажется подход интересным.

Я работаю программистом уже много лет, на протяжении которых, как это ни странно, я всё время что-то программирую. И вот какую интересную вещь я заметил: в коде, написанном мной месяц назад, всегда хочется что-то чуть-чуть поправить. В код полугодичной давности хочется поменять очень многое, а код, написанный два-три года назад, превращает меня в эмо: хочется заплакать и умереть. В этой статье я опишу два подхода. Благодаря первому архитектура программы получается запутанной, а сопровождение — неоправданно дорогим, а второй — это принцип KISS.

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

Почти каждый из нас испытывал дискомфорт, когда при нажатии на кнопку или при вводе текста в iOS или Mac приложениях, как внезапно пользовательский интерфейс переставал отвечать, приложение будто замирало и переставало реагировать на ваши действия.

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

Но обеспечить постоянную отзывчивость пользовательского интерфейса не так уж просто. Как только приложение выполняет множество задач, оно начинает подтормаживать. Не так уж много времени выделяется для выполнения большого количества задач в главном потоке и для обеспечения отзывчивости интерфейса.

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

Одним из методов для одновременного выполнения операций в iOS являются использование классов NSOperation и NSOperationQueue. В этой статье вы узнаете, как их использовать! Вы будете работать с приложением, которое совсем не использует многопоточность, таким образом, оно будет очень медленным, и будет «тормозить». Когда вы измените приложение, чтобы можно было добавлять параллельные операций и — надеюсь – это обеспечит более отзывчивый интерфейс для пользователя!

Всем привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. В свободное время я люблю искать баги. В сегодняшнем посте я хочу рассказать об одной довольно интересной уязвимости, которую я нашёл и зарепортил в bug bounty нескольких крупных компаний, за что получил солидное вознаграждение. Уязвимость заключается в следующем: если сформировать специальный видеофайл и загрузить его на сервер, то:

• можно получить на нём SSRF;
• можно получить local file read;
• если пользователь скачает этот файл, то автоматически будет подвержен уязвимостям, даже если его не откроет: можно будет получить доступ к данным на компьютере пользователя и узнать его имя.

Выражаем благодарность за подготовку статьи Артему Жуковец — CTO NovaPress Publisher. Проект-победитель конкурса “Герои российских стартапов”

Просто «El clasico»

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

Этот пост подготовлен с учетом реалий Великобритании, а потому совершенно логично, что в других странах ситуация может выглядеть иначе, в частности, когда речь идет о социальном статусе разработчиков программного обеспечения.

Средства массовой информации не перестают освещать тему нехватки квалифицированных программистов («программистов», «кодировщиков», «разработчиков ПО», поскольку все термины означают одно и тоже, я буду использовать из как взаимозаменяемые). Постоянно ведутся споры по поводу низкого уровня квалификации программистов. По сути мы просто не в состоянии подготовить кадры, соответствующие «солидным запросам завтрашнего дня». Вот что пишет The Telegraph:

«Согласно данным Научного Совета, к 2030 году количество специалистов в сфере информационно-коммуникационных технологий вырастет на 39%, а в отчете О2 за 2013 год отмечалось, что для удовлетворения спроса на такого рода специалистов в период до 2017 года потребуется порядка 745 000 новых сотрудников.

Кроме того, по результатам исследований, проведенных в прошлом году City & Guilds, три четверти работодателей из сферы IT, компьютерных и информационных услуг отметили явную нехватку квалифицированных кадров, в то время как 47% опрошенных заявили о неспособности действующей системы образования подготовить хороших специалистов».

На Хабре было уже много статей на тему классического ARP спуфинга, однако все они были похожи тем, что для полноценного перехвата трафика надо было подменять ARP записи у двух машин. Как правило, это жертва и ее шлюз по умолчанию. Однако, идея спуфить шлюз не всегда хороша. Он вполне может иметь на борту детектор атак, который в два счета доложит админу что сеть ломают и халява кончится, не начавшись. В данной статье будет рассмотрен метод перехвата трафика, при котором атака производится только на хост-жертву. Как обычно в таких случаях, статья чисто для ознакомления, использование во вред карается по закону и т.д.
Под катом много букв.