Евгений (MalDeckard) Черешнев поделился личным опытом и написал исчерпывающий гайд, который может помочь многим людям и предостеречь от последствий:

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

Справедливости ради, большинство воров уже в курсе того, что каждый смартфон — это, по сути, радиомаяк, по которому всегда можно укравшего отследить. Поэтому они редко оставляют его включенным — практически сразу достают и выбрасывают SIM-карту, сам телефон вырубают и сдают на запчасти за копейки. Что крайне обидно — ибо шансы того, что, например, мой iPhone 12 Pro Max 512 банально разберут на экран, аккумулятор и несколько особо востребованных микросхем — стремятся к 100%. То есть, вор украл крайне дорогой девайс, а получит за него или хрен или (если он идиот) — срок. Но это не всегда так. Иногда можно получить реально грузовичок и тележку проблем. Во-первых, в ряде типов краж (как в моем случае) телефон попадает в руки плохого парня в разлоченном состоянии и есть риск, что злоумышленник девайс специально не залочит — будет держать его активированным и извлекать из него максимальную пользу, на что у него будет в теории до 24ч (после чего сработает система защиты в заводских настройках и снова попросит ввести пин-код, даже, если телефон до сих пор разлочен).

Адаптировано из нашей будущей книги «Рефакторинг UI»

Видели эти модные генераторы цветовой палитры? Когда выбираешь цвет, настраиваешь несколько параметров с музыкальными словечками типа «триада» или «четвёртый мажор» — и получаете пять идеальных цветов для своего веб-сайта?



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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Сложно представить человека, у которого перед выходом на сцену не дрожали бы коленки. Особенно, если ТАМ ждут 100 (200) человек, а за плечами у вас только выступление на школьном утреннике.

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

Меня зовут Алексей Андросов, я уже много лет работаю в Яндексе фронтенд-разработчиком. Два года назад мне и моим партнерам пришла в голову идея создать мобильную социальную сеть Verb. Идея Verb в том, что пользователи могут делиться небольшими статусами — “вербами” — о том, чем они занимаются в данную минуту, простыми вещами, о которых хочется рассказать друзьям, но некуда об этом написать. И мы уже даже получили инвестиции, но сейчас не об этом. Сегодня я хочу рассказать о том, как и почему я написал мобильное приложение на react-native.

В апреле этого года мы перезапустили tinkoff.ru. Банк превратился в финансовый супермакет. Теперь не только клиент банка, но и любой посетитель оплатит мобильный, проверит налоги и оформит ипотеку — всё на одной платформе. В этой статье я поделюсь опытом и технологическими решениями, к которым мы пришли за год разработки.

Здравствуйте, меня зовут Дмитрий Карловский и я… клиент-сайд разработчик. За плечами у меня 8 лет поддержки самых различных сайтов и веб-приложений: от никому не известных интернет-магазинов, до таких гигантов как Яндекс. И всё это время я не только фигачу в продакшн, но и точу топор, чтобы быть на самом острие технологий. А теперь, когда вы знаете, что я не просто хрен с горы, позвольте рассказать вам про один архитектурный приём, которым я пользуюсь последний год.

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

Осторожно: чтение может вызвать вывих мозга, приступ холивара, а также бессонные ночи рефакторинга.

Для новичка, экосистема вокруг React (как и фронтэнда в целом) может показаться запутанной. Этому есть несколько причин.

• Изначально, React был нацелен на экспертов и ранних последователей
• Facebook открывает исходный код только тех продуктов, которые использует сам, т. е. не нацеленные на проекты-меньше-чем-Facebook
• Огромное количество гайдов по React совершенно разной сложности

Здесь и далее, я предполагаю, что вы уже знакомы с HTML, CSS и JavaScript.

Все мы не раз слышали о test-first — философии разработки, которая призывает писать тесты раньше кода. Уверен, что любой, кто пытался применять этот метод на практике, сталкивался с тем, что у него просто не получается написать тест до функции (обычно в этом случае просто игнорируют эту проблему и локально нарушают test-first). Я считаю, что причина подобных провалов фундаментальна, и попытаюсь показать почему.

Для начала следует уточнить, что здесь и далее я буду говорить про тестирование функции в широком смысле слова как тестирование некоторой условной примитивной единицы кода. Оставим в стороне вопрос, какую подобную единицу нужно тестировать (например, метод или класс), на дальнейший ход рассуждения эти детали влияния не окажут. Я буду использовать выражение «тестирование функции» в этом смысле на протяжении всей статьи.

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

Введение

Недавно у нас закончился крупный проект с довольно сложным продвинутым UI. Не вдаваясь в детали, скажем, что внутри браузера было реализовано что-то вроде рабочего стола (desktop) с окнами, перекрытиями и всем, чем полагается. Разумеется, проблемы с утечками памяти не обошли нас стороной. Признаемся честно, до поры до времени сосредоточились на получении бизнес-результата. Когда дошли руки до утечек памяти, то обнаружилось, что окна браузера занимают гигабайты оперативной памяти. Мы классифицировали ошибки и в общем виде выработали подход к их устранению. Этим подходом и хотим поделиться с вами.

По теме утечек памяти в клиентских приложениях написано уже немало. Изначально основную проблему представляли из себя браузеры IE8 и младших версий (смотрите, например:
http://habrahabr.ru/post/141451/
http://habrahabr.ru/post/146784/
https://learn.javascript.ru/memory-leaks).
Но и теперь, когда можно сказать, что IE8 в прошлом, проблемы остаются. Даже применение такого языка как TypeScript не гарантирует их отсутствия. А с учетом того что front-end в web-приложениях становится все сложнее, актуальность проблемы только возрастает.

На хабра-сайтах не раз (см. тут и здесь) выходили статьи о том, как защитить себя от замены sim-карты. Но, не смотря на то, что все эти советы — дельные, в них есть одно слабое и при этом — очень значимое место, которое с юридической точки зрения называется добросовестность одной из сторон, т.е. провайдера.

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

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

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

В этой серии статей я соберу бОльшую часть своего опыта разработки на Ruby on Rails. Эти методики позволяют контролировать сложность и облегчают сопровождение проекта. Большинство из них придумал не я, и, по возможности, буду указывать источник.

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.

CSS-препроцессоры в своё время значительно облегчали работу по написанию CSS кода. Однако в некотором роде все они были несовершенны и имели значительные изъяны в работе. А потому на смену препроцессорам пришёл постпрепроцессор PostCSS.

Это довольно таки мощный инструмент, облегчающий работу с CSS. Постпрепроцессор уже сегодня используется в таких крупных компаниях как Twitter и Google. Кроме того, по сообщениям разработчиков Bootstap, пятая версия CSS-фреймворка вероятнее всего также будет написана на PostCSS.

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

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

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

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

Создавая HTML код для email, приходится иметь дело с изрядным количеством больных вопросов. И вряд ли для кого то будет приемлемо, если нам к тому же ещё и придётся следить за новыми email-клиентами и размерами устройств, которые появляются каждую неделю. Поддержка media query как и сам CSS разнятся среди приложений, в следствии этого, каждый раз когда вы слышите что появилось новое восхитительное почтовое приложение, для которого тоже нужно провести тесты, вас неизбежно одолевает страх.

Но что если бы вы могли создать шаблон, который был бы отзывчивым даже в окружениях с наименьшей поддержкой современного CSS? Что если каждый раз, услышав о каком-то очередном почтовом приложении, которое все испытывают, вместо того чтобы предаваться страху, можно было бы чувствовать себя спокойно и уверенно, зная что ваши email наверняка будут выглядеть хорошо?

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

Он называется fluid-hybrid method, иногда упоминается как spongy метод для email разработок. Часть fluid предполагает что мы используем изрядной количество процентных вычислений. Часть hybrid означает что мы также используем max-width дабы ограничить некоторые из наших элементов на экранах большего размера.

Благодаря популярности CSS фреймворка Bootstrap, для него разработали массу различных дополнений. Даже сейчас вы можете использовать Bootstrap практически для любой задачи при разработке и оформлении вебсайта.

Для статьи я подобрал наиболее полезные дополнения «на все случаи жизни».

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

Привет, Хабр! Многие уже знают о моей страсти к попытке собрать самое лучше, что может быть полезно для веб-разработчиков или веб дизайнеров. И шрифты — не исключение. Программное обеспечение для работы со шрифтами постоянно развивается. Количество дизайнеров желающих опробовать себя в типографике растет с каждый днем. А сегодня я хочу представить вам их наработки — 30 потрясающих бесплатных шрифтов, которые мне удалось собрать за последний год.

Polar