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

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

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

От переводчика: прочитав статью, начал было отвечать в комментариях, но решил, что текст, на которую я собирался ссылаться, достоин отдельной публикации. Встречайте!

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass out of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.

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

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

Ребята называющие себя Open Source Society, взяли и собрали учебный план из бесплатных MOOC курсов, для желающих изучить информатику (Computer Science). Всего в программе 50+ курсов в ходе которых можно получить знания о разных аспектах CS. Курсы собраны с таких проектов как: Coursera, edX, Udacity, и т.д. На мой взгляд получилась добротная цепочка, на освоение которой, в зависимости от интенсивности и уровня подготовки, уйдет 1-2 года.

Маленький рассказ о том, как наша команда решила организовать иконки в грядущем проекте. Чуть-чуть исторического экскурса, взгляды по сторонам (на PNG и векторные шрифты) и рассказ о том, как мы всё-таки обустроились в итоге.

Иконки у нас используются, и активно – хорошо подобранная иконка заменяет слова и предложения (а фигово подобранной иконке можно сделать всплывающую подсказку, но не будем о грустном)

В общем, есть (и продолжают создаваться) иконки. Надо их положить на веб-страницу. Надо сделать это так, чтобы потом голова не болела про них весь остаток проекта и ещё пару лет в поддержке. Ну и есть дополнительные хотелки:

• хочется вектора. Ну, ладно, вектор – это средство, а не цель. Цель – не беспокоиться ВООБЩЕ об изменении размеров, ретина дисплеях, сохранении изображения в разных форматах для разных целей.
• хочется стилизации иконок. Потому что у нас из коробки как минимум два набора тем (светлая и тёмная), а то и контрастная, для людей с нестандартным зрением, а то и оранжевенькая какая-нибудь появится ближе к Новому году… В общем – одна и та же по сути иконка должна выглядеть слегка иначе в зависимости от выбранной на странице темы.
• хочется динамической стилизации иконок. Статики – нам мало. Этого хватает для скриншотиков и рекламных буклетиков, но не для живых пользователей. А мы хотели жизни! Мы хотели ховера! Мы хотели селекшена!!! И дизаблить, дизаблить их всех!.. Извините.
• НЕ хочется, чтобы в этом участвовал JavaScript в любой его форме и проявлении. Иконки – это внешний вид, а за него ответственный HTML + CSS. Ну, ладно, класс selected я готов навесить на элементы, но это последняя граница…

Есть и факторы, облегчающие задачу. Иконки сейчас (2015, осень, начинает снежить) в моде плоские, строгие. Если лет пять назад иконки пестрели, то сейчас это ушло под влиянием МС, Эппла, Материал Дизайна…

tl;dr Внимание. Следующие несколько разделов – это расплывание мыcлею по древу, причём вширь, обзор решений (в том числе – неудачных) и котик в разных ракурсах.
Кому хочется технических подробностей того, что же вышло в итоге – пожалуйте сюда.

Добро пожаловать на русскоязычный сайт для разработчиков на Rust!

Rust — это системный язык программирования, который очень быстро работает, предотвращает почти все падения, и устраняет гонки данных.

Создание сообщества назревает уже давно. Наш язык миновал заветный выпуск «1.0». Rust стабилен, экосистема растёт как на дрожжах, а улучшения поспевают в каждом новом выпуске. Самое время расширять аудиторию!

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



Анализ запросов в данном сервисе — не является заменой команде EXPLAIN, которая ориентирована на анализ производительности запроса, а является скорее дополнением, которое анализирует запрос с точки зрения его синтаксиса.

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

Задача:

• имеется некий самописный сервис, запускаемый и отслеживаемый из systemd;
• необходимо при появлении файла-флага рестартовать этот сервис;
• делать это изнутри сервиса нельзя по религиозным соображениям.

Решение:

Одним из главных принципов, лежащих в основе движения за открытый исходный код, — Open Source, — является свобода распространения информации. Жизнестойкость этой идеи подтверждают примеры многих успешных проектов, развиваемых свободным сообществом программистов со всего мира. Наверное, кого-то это удивит, но мы тоже активно развиваем множество opensource-проектов. И недавно мы обнаружили, информация об этих проектах разбросана по сети, и разработчики одних продуктов могут совершенно не знать о других, которые могли бы оказаться для них полезными. Так и родилась идея создать информационный сайт OpenSource.Mail.Ru.

Продолжаем улучшать быт системного администратора своими силами.

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

С одной стороны, такие задачи можно перевести в статус «Заморожена», например. Они перестанут захламлять список актуальных задач, с одной стороны. С другой — появляется риск про них забыть. С целью не допустить подобного и был создан плагин redmine_issue_open_date.

В связи с тем, что гугль мало помог в решении возникшей проблемы — пусть это останется тут, может кому из коллег-админов поможет сэкономить некоторое количество времени и нервов.
Имеем ejabberd 2.1.13 из портов freebsd (10), полторы сотни зарегистрированных пользователей внутри организации, и некоторую потребность в его обновлении.
Пересобираем (portmaster) erlang (с R16 до R18), перезапускаем ejabberd — имеющиеся в онлайне в вечернее время полтора десятка пользователей успешно переподключились.
Собираем ejabberd, бекап, portmaster ejabberd, рестарт. Конвертируем конфиг в yaml.
Сервер поднимается, полтора десятка клиентов подключились, sendxmpp работает, zabbix тоже заработал, спокойно уходим домой.

С утра выясняется, что у одного из сотрудников не работает клиент (Miranda IM).
То есть происходит подключение, грузится список контактов и тут же — уход в офлайн.
Пробуем шаманства — обновить клиента, поменять на Miranda NG, поменять клиентский комп…
Потом выясняется, что проблема не только у одного пользователя.
У другого пользователя — подключение удается с… дцатой попытки.

Привет, Хабр!

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

Мнение автора может не отражать позицию компании и других коллег.

Знакомьтесь — Александр Ефимов, Configuration manager/DevOps

Есть у меня знакомый, который, будучи первоклассным сисадмином, мечтает стать программистом. По его словам, хочет творить, а не использовать уже существующий… не очень хороший софт. В чем-то я его понимаю: «чистое» творчество — безусловно, круто. Но давайте разберемся, что и как происходит на самом деле.

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

Кому это будет интересно?

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

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

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

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

Когда вышла версия 1.0 Redux, я решил потратить немного времени на серию рассказов о моем опыте работы с ним. Недавно я должен был выбрать “реализацию Flux” для клиентского приложения и до сих пор с удовольствием работаю с Redux.

Почему Redux?

Redux позиционирует себя как предсказуемый контейнер состояния (state) для JavaScript приложений. Редакс вдохновлен Flux и Elm. Если вы раньше использовали Flux, я советую прочитать, что Redux имеет с ним общего в разделе "Предшественники" новой (отличной!) документации.

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

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

Всем привет! Меня зовут Андрей Новиков и в последнее время я работаю над проектом по разработке приложения, которое используется в разных частях нашей страны и автоматизирует работу людей. В каждом конкретном часовом поясе нашему приложению необходимо правильно получать, сохранять и отображать время, причём как в прошлом, так и в будущем – например, рассчитать начало рабочей смены и так же правильно его отображать: отсчитать время до конца смены, показать, сколько люди ехали до точки назначения и определить, уложились ли они в норматив, в также многое-многое другое.



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

В результате, сегодня мне есть, чем с вами поделиться. Если вы регулярно встречаетесь с тем, что время сохраняется или отображается некорректно с характерным разбросом в несколько часов (3 часа для Москвы), какие-то ночные записи перекочёвывают на соседние дни, а время упорно отображается не так, как хотят пользователи, и вы не знаете, что со всем этим делать — добро пожаловать под кат.

Почему первая? Потому что раньше были игры для программистов, и были стратегические ММО-игры. Но до нас еще никто не делал игру, которая одновременно и является ММО с единым постоянным миром, и при этом целиком и полностью ориентирована на программистов.

В ноябре прошлого года мы запустили краудфандинговую кампанию на Indiegogo, собранные средства с которой позволили доработать прототип до полноценного продукта. Весь июнь и июль получившие приглашение игроки тестировали версию Early Preview. И вот, теперь мы объявляем о публичном запуске этого необычного проекта. Встречайте Screeps!



Под катом небольшое описание, отзывы и технические подробности проекта.

По следам недавних топиков, а также постоянных рассказов в стиле «мой стартап не взлетел, потому что его зохавала лапша из callback-ов».

Как раз недавно я закончил небольшой проект (ссылку не даю, чтобы не заподозрили — кому надо см. профиль), полностью и на всех этапах написанном только на JS, и притом полностью асинхронный. Разумеется, я столкнулся с пресловутой проблемой «лапши». И, вы не поверите, совершенно спокойно решил её без всяких там фреймворков и хитрых приемов.

Итак, допустим, у нас есть задача: асинхронно выбрать из базы количество книг, потом асинхронно же выбрать из базы нужную пачку книг, потом асинхронно же выбрать из базы метаданные по книгам, а потом свести всё это в один dataset и отрендерить шаблон. Как это обычно выглядит?