Служба DNS, невидимая обычному пользователю, периодически оказывается в фокусе интереса IT-специалистов. По разным поводам. Особенно актуальной эта тема становится в периоды, когда основные провайдеры DNS подвергаются DDoS-атакам. Именно тогда, когда DNS становится частично неработоспособной, приходит понимание, что DNS – это основа, костяк всей структуры интернета.

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

• Реестры доменов
• Глобальные домены верхнего уровня (gTLD)
• Различные национальные домены верхнего уровня (ccTLD)
• И растущий с каждым годом список всех прочих доменов высшего уровня (.space, .photography и так далее)

Все это делает и так не простую систему еще более сложной.

Представьте: вы написали программу и презентуете ее в офисе заказчика. Вы много работали над ней, преодолели не очевидные на первый взгляд проблемы, уложились во все ограничения и техтребования. И вот вы, с волнением и гордостью, запускаете программу, появляется главное меню. Вы уже готовы показывать функционал, как вдруг слышите, что кто-то из проходящих по офису сказал: «я бы написал на другом языке». В голове проносится: «Что? Что это было?! Кто-то знает, на каком языке написана моя программа? В этом офисе есть программисты? Фух, нет, наверное показалось». Отогнав глупые мысли вы готовитесь начать презентацию, как вдруг кто-то из зрителей наклоняется к монитору и отчетливо говорит: «Эта программа не будет работать, в ней полно багов». Вы в шоке — надо быть гением, чтобы сделать такой вывод из первого экрана. Другой зритель менее сдержан: «Ну и г*вно. Не мог сделать что-нибудь нормальное?». Зрители высказывают мнение, вы в панике. Когда очередной проходящий по офису говорит: «Код должен быть более нативным», вы сразу же подбегаете к нему с вопросом: «вы разработчик?». Он отвечает: «Да нет, я делаю ремонт в этом офисе». Очевидно — либо мир сошел с ума, либо вас окружают гении, которые видят гораздо больше вас.

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

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

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

Код, использующий неявное поведение, может быть основан на каком-нибудь недокументированном, но уже реализованном функционале. Например, в мире написана целая куча НЕВЕРНОГО кода, который полагается на то, что функция файловой системы, возвращающая список директорий, вернёт их в отсортированном по алфавиту порядке. Это и вправду часто работает именно так, но ровно до того момента, пока не ломается по «непонятным» причинам. А на самом деле просто никто никогда этой сортировки не гарантировал.

Всем привет! Хочу поделиться своим переводом статьи React is Slow, React is Fast: Optimizing React Apps in Practice автора François Zaninotto. Надеюсь, это кому-то будет полезным.

Краткое содержание:

1. Измерение производительности React
2. Почему ты обновился?
3. Оптимизация через разбиение на компоненты
4. shouldComponentUpdate
5. Recompose
6. Redux
7. Reselect
8. Остерегайтесь объектных литералов в JSX
9. Заключение

React может быть медленным. Я хочу сказать, что любое React приложение среднего размера может оказаться медленным. Но прежде, чем искать ему замену, вы должны знать, что и любое среднее приложение на Angular или Ember может также оказаться медленным.

Хорошая новость в том, что если вы действительно заботитесь о производительности, то сделать React приложение очень быстрым довольно легко. Об этом — далее в статье.

Всем доброго времени суток! Меня зовут Николай, я iOS-Lead в компании Touch Instinct. В процессе разработки часто приходится иметь дело с проектами, которые должны работать на нескольких языках. Расскажу, к какому подходу мы пришли при работе с локализацией.

Минусы базовых подходов

Есть несколько основных подходов для локализации iOS-приложения. Сперва стоит определиться, разрабатывается приложение с использованием storyboards или нет.

С использованием storyboards

Можно локализовывать строки напрямую в storyboard. Однако, при таком подходе есть ряд минусов:

• в случае наличия большого количества storyboards, локализованные строки разбросаны по проекту;
• невозможность использования атрибутных строк, а также строк, которые состоят из нескольких составных частей;
• вам всё равно придется часть строк локализовывать в коде. Это ведет к еще большему разбросу в приложении;
• фактически отсутствует возможность что-то проверить другому разработчику при проведении code review.

Без storyboards

В этом случае локализуем всё в коде. Однако и тут есть ряд минусов. Дело в том, что файлы со строками локализации localizable.strings — магические. При изменении таких файлов очень велика вероятность возникновения ошибки из-за человеческого фактора. Изменения нельзя отследить, пока ошибка не будет найдена в процессе тестирования.

Таким образом, хотя для локализации уже есть готовые механизмы в iOS SDK, они имеют существенные минусы. Более подробно смотрите здесь.

Первую часть вы можете найти здесь: Управление рисками. Часть 1

«Нужно пожертвовать многим, чтобы спасти все» Тадеуш Костюшко

После крайне важных двух первых шагов: определения рисков и первоначальной их оценки, вам пора начать что-то делать с ними.

Здесь существуют следующие возможные стратегии:

• принятие
• передача
• уменьшение

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


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

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

Amazon S3 — это файловое облачное хранилище, которое используют такие известные сервисы как Dropbox, Trello и миллионы других проектов. Несмотря на сбой 28 февраля 2017 года, в результате которого кое-где перестали работать даже холодильники, S3 остается, пожалуй, самым популярным распределенным хранилищем, в котором пользователи и бизнес хранят фотки, видео, бэкапы и другой полезный контент.

Web Call Server — это медиасервер с поддержкой технологии WebRTC и записи видеопотоков из браузеров и мобильных устройств. HTML страница в браузере или мобильное приложение может захватить видеопоток с веб-камеры и отправить на сервер для дальнейшей ретрансляции и записи.

В этой статье мы расскажем как записать видеопоток со страницы браузера Google Chrome с последующей отправкой mp4-файла в хранилище Amazon S3.

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

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

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

Важно!

• В статье присутствует определенная доля иронии.
• Статья ни в коем случае не ущемляет чьи-либо интересы.
• В статье не противопоставляется SCRUM водопаду и не смешивается «мягкое с теплым».
• У каждого свое мнение на процесс разработки проектов, свой опыт или его отсутствие, свой счастливый клиент или свой провалившийся проект, выполненный по методологии, с помощью проектных методик, руководствуясь принципами или интуицией.
• Будьте добрее!

Я всегда восхищался силой коллективного разума. И укреплению моей убежденности в ней послужила недавняя история: я рассказал, как можно интегрировать телефонию с Telegram с помощью сервиса IFTTT, на что коллеги из Voximplant ответили, как это можно сделать проще, а потом господин recompileme в своем комментарии обратил внимание на то, что удобный API телеграма решает задачу без участия каких-либо третьих сервисов.

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

В недавнем хабрапосте SvyatoslavVasiliev показал, как с помощью популярного сервиса IFTTT и нескольких заклинаний настроить Telegram-уведомления о пропущенных звонках. Концепция «дерни url, и бот тебе напишет, что передано в json payload» мне очень-очень понравилась. Прототипирование и нотификации «на коленке» за несколько минут. Причем не только про телефонию. Точно таким же способом можно сделать уведомления о «прилегшем» сервисе, DDOS атаке или о выходе хабрастатьи в «лучшее». IFTTT – очень хорошая штука, но кликать надо много. Если посмотреть оригинальную статью, то количество скриншотов впечатляет. Под катом я покажу, как сделать то же самое всего в несколько команд.

Автор — Нолан Лоусон, менеджер проекта Microsoft Edge

Прокрутка — одно из самых древних взаимодействий в вебе. Задолго до появления методов pull-to-refresh и списков бесконечной загрузки скромная полоса прокрутки решила изначальную проблему масштабирования в вебе: как взаимодействовать с контентом, который распространяется за пределы доступной области просмотра?

Сегодня прокрутка всё ещё остаётся самым фундаментальным взаимодействием в Сети, и, возможно, самым неправильно понятым. Например, вы знаете разницу между следующими сценариями?

• Пользователь прокручивает страницу двумя пальцами на тачпаде
• Пользователь прокручивает одним пальцем на тачскрине
• Пользователь прокручивает колесо мыши
• Пользователь щёлкает по полосе прокрутки и тянет её вниз и вверх
• Пользователь нажимает стрелки «вверх», «вниз», PageUp, PageDown и «пробел» на клавиатуре

Если спросите среднего интернет-пользователя (или даже среднего веб-разработчика!), они могут сказать вам, что эти действия равнозначны. Правда гораздо более интересна.

Империи зла нередко получают лучи ненависти со стороны конечных пользователей. Не смотря на это, Uber частично оплачивает наши поездки, хоть и временно, а Google придал значительное ускорение технологии WebRTC, которая бы так и оставалась проприетарной и сильно платной софтиной для узких целей b2b, если бы не ИЗ.

После появления WebRTC, видеочаты стало делать проще. Появились различные API и сервисы, серверы и фреймворки. В данной статье мы подробно опишем еще один способ разработки видеочата между веб-браузером и нативным Android-приложением

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

Обычно в таких ситуациях никто не настроен вас долго слушать — скорее всего у вас будет около 3-5 минут чтобы рассказать суть вашей идеи, объяснить почему это вообще кому-то надо, кто и как будет это реализовывать и, собственно, изложить суть вашего делового предложения. Возникает серьезный риск что во время такого Elevator Pitch у вас просто не получится донести до понимания адресата даже саму суть проекта, не говоря уж о его сильных сторонах и возможной выгоде.

Вне всякого сомнения, о дизайн-системах меня спрашивают чаще, чем о чем-либо другом. За последние несколько лет я посвятил много времени размышлениям о том, как выстраивать, реализовывать и представлять дизайн-системы для таких продуктов, как Marvel, Bantam и Modulz, и теперь решил, что пришла пора поделиться тем, чему научился в процессе.



Что такое дизайн-система?

Ни для кого не секрет, что дизайнеры любят хорошие UI-киты. Но, по моим наблюдениям, в последнее время все больше внимания уделяется не просто наборам инструментов и руководствам по стилю, а созданию систем, которые связывают воедино целые продукты. Компании вроде Shopify и Intercom формируют особые команды, которые занимаются только и исключительно дизайн-системами. Люди начинают осознавать, как важен системный подход в дизайне. Это внушает оптимизм. Кто знает, возможно, в один прекрасный день появится инструмент для дизайнеров, который не будет предполагать, что в каждом новом проекте мы начинаем все с нуля.

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

Эпиграф: Если у человека нет чувства юмора, у него по крайней мере должно быть чувство, что у него нет чувства юмора.

Не далее как сегодня с коллегами вычисляли неблагополучно подключенное устройство с целью отключить порт на коммутаторе в воспитательных целях.

В нашем случае мы физически видели железку, но, к нашему несчастью, дёрганье патчкорда из неё так и не положило порт на коммутаторе — спасибо замурованным хабам и стихийно-историческому становлению СКС в этом помещении.

Созрел план вычисления железки по тотальному анализу вендоров оборудования по MAC (технически по MAC OUI, первым трём байтам mac-адреса).

Обмен информацией шёл через Lync, изумительно раскрасивший портянку с MAC-адресами смайликами.

The Web Accessibility Initiative's Accessible Rich Internet Applications Suite (WAI-ARIA, или просто ARIA) — это набор инструментов и указаний для того, чтобы сделать веб-контент и приложения более доступными.
В частности, он включает в себя набор атрибутов, которые мы можем добавлять к HTML-элементам для придания им семантической информации, которая может быть прочитана с помощью специальных возможностей (assistive technologies).

Хотя ARIA может быть достаточно полезной, нам стоит быть осторожными в вопросах, как и когда её использовать. Вот 5 правил, которые необходимо учитывать при использовании ARIA в HTML.

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