Никлаус Вирт, швейцарский ученый-информатик, в 1976 году написал книгу под названием «Алгоритмы + Структуры данных = Программы».

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

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

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

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

Переведено в Alconost

6 августа состоялось судебное заседание (рекомендую почитать трансляцию, местами смешно) по иску компании «Живая фотография» к Роскомнадзору и Генеральной прокуратуре. Роскомнадзор, в попытках, нарушить работу Telegram на территории России, массово блокировал миллионы адресов популярных хостингов, отчего пострадал и сайт «Живой фотографии». Основание для блокировки — знаменитое «резиновое» постановление Генпрокуратуры.

Результат немного предсказуем — требования истца (признать блокировку незаконной, что открывало возможность взыскать упущенную прибыль) суд не удовлетворил.

Интереснее то, что Роскомнадзор вынужден вытащить на свет божий само постановление. Которое до этого момента отказывался предъявить публике, ссылаясь на то, что не обязан этого делать. Правда и при этом ведомство умудрилось смухлевать. До 17 мая сети блокировалось по постановлению 27-31-2015/Ид4082-15, а с 17 мая номер документа в реестре внезапно изменился на 27-31-2018/Ид2971-18. Риторический вопрос — а что так можно было?

Здравствуй, Хабр. Меня зовут Виталий Котов, я работаю в отделе тестирования компании Badoo. Я пишу много UI-автотестов, но ещё больше работаю с теми, кто занимается этим не так давно и ещё не успел наступить на все грабли.

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

Статья будет интересна начинающим авторам UI-тестов, но и старожилы в этой теме наверняка узнают что-то новое, либо просто улыбнутся, вспомнив себя «в молодости». :)

Поехали!

Год назад в нашей компании произошли революционные изменения, у нас изменилась методология разработки, мы стали работать по Scrum.

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

На последней встрече сообщества Apache Ignite в Москве я рассказывал про:

• Open source-сообщество;
• Власть и деньги в open source;
• Как стать контрибьютором и коммитером, и зачем это нужно.

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

Процесс работы пользователей с интерактивными веб-сайтами может включать в себя шаг отправки им JavaScript-кода. Часто — слишком большого объёма такого кода. Если на сайте используется очень много JavaScript, это особенно сильно сказывается на мобильных пользователях. Например, вам случалось бывать на мобильных веб-страницах, которые, вроде бы, выглядят как уже готовые к работе, но не реагируют на щелчки по ссылкам или на попытки прокрутить страницу?


JavaScript-код, который попадает в мобильные браузеры, всё ещё остаётся самым дорогостоящим ресурсом, так как он, многими способами, может задержать переход страниц в состояние, в котором с ними можно взаимодействовать. Какую нагрузку на системы создаёт JavaScript в наши дни? Как анализировать сайты? Как ускорить загрузку и обработку браузерами интерактивных веб-страниц? Эдди Османи, перевод материала которого мы сегодня публикуем, решил найти ответы на эти и на многие другие вопросы, встающие перед теми, кто пользуется JavaScript для разработки веб-сайтов в 2018 году.

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

Когда при разработке приложений приходилось браться за CSS, это была не самая радостная часть работы. Но ее ведь не избежать, верно? Сегодня порадовать пользователя дизайном приложения настолько важно, что без CSS — никак.

Когда проект только начинается, все идет хорошо. У вас всего пару селекторов: .title, input, #app — проще простого.

Но постепенно приложение разрастается, и заглядывать в CSS становится страшновато: во всех этих селекторах разобраться уже не так просто. Вы начинаете писать что-то вроде div#app .list li.item a, какие-то куски кода повторяются снова и снова, а всю свою писанину сваливаете в конец файла: вам уже плевать, потому что CSS — отстой. Итог — 500 строк CSS-кода, поддерживать который невозможно.


Это я, когда сражаюсь с CSS

Переведено в Alconost

Картинка: источник

Привет, Хабр! Меня зовут Илья Аблеев, я работаю в отделе мониторинга Badoo.

Можно долго холиварить на тему того, какая система мониторинга круче. Основным инструментом для реакции на проблемы в Badoo является Zabbix, и мы неоднократно делились опытом его кастомизации.

«Из коробки» узнавать о новых проблемах можно либо через веб-интерфейс, либо по почте/SMS. Это хорошо работает и до определённого момента нас устраивали эти способы.

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

Оптимальным решением, на наш взгляд, был бы вывод важных уведомлений поверх всех окон (браузеров, чатов, консолей). В этой статье речь пойдёт о том, как мы допилили Zabbix, научив отправлять их прямо на рабочий стол.

Кому подойдёт данное решение:

• дежурным администраторам, которые не только круглосуточно смотрят в монитор, но и занимаются решением других задач;
• всем остальным администраторам, которым не нравится просматривать простыню PROBLEM и OK`ов в почте или SMS, но которые хотят своевременно узнавать о критичных проблемах.

Придётся потратить время на установку, но, думаю, если вы используете Zabbix и уже использовали кастомные скрипты, для вас это не составит труда.

Решение об обновлении базы данных MySQL принял после того, как прочитал на сайте разработчика, что в восьмой версии внедрена более полная поддержка UTF. В частности в MySQL 8.0.11 используются регулярные выражения на базе ICU, International Components for Unicode.

Первое, что заметил это то, что границы слова в регулярных выражениях теперь нельзя обозначить как:

SELECT 'слово' REGEXP '[[:<:]]слово[[:>:]]'; 

Границы слова в новой версии обозначаются таким образом:

'\\bслово\\b'

Привет, %username%!



В обсуждении новости про Passport разгорелись жаркие дискуссии на тему безопасности последней поделки от авторов Telegram.

Давайте посмотрим, как он шифрует ваши персональные данные и поговорим о настоящем End-To-End.

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

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

История о подкастах

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

И вот вы решаете нанять людей, которые сделают для вас этот сайт. Вы пишете для них абсолютно чёткие требования:

• Быстрая загрузка сайта в Северной Америке
• Поддержка загрузки прошлых выпусков подкастов и трансляции в реальном времени текущих
• Трансляция не должна падать или замирать в течении первых 15 минут для 99.99% пользователей. Желательно вообще никогда, но хотя бы так.
• Интеграция с Google Adwords (а в будущем, возможно, и с аналогами)
• Интеграция с трансляциями Facebook, поскольку там вы проводите свои передачи. Если можно создать альтернативное решение, которое будет позволять стримить более удобно — ещё лучше.

Вы даёте эти требования разработчикам и, возможно, немного общаетесь с ними. Проходит 2 месяца. Они показывают вам демо и вы покрываетесь красными пятнами. Становится понятно, что вы только что выбросили в пропасть 15 000 $. То, что вам показали, совершенно неприемлемо ни с какой стороны, просто куча мусора. Вы хотите назад свои деньги, но поезд уже ушел.

Сегодня Mislav Marohnić объявил о том, что разработчики Github избавились от jQuery на фронтенде GitHub.com. Казалось бы, в самом этом факте нет ничего примечательного, если бы не один интересный момент.

Проблема выбора нового фреймворка для фронтенда была решена радикально — решено было обойтись без фреймворков в принципе. Вместо них были использованы следующие средства:

• querySelectorAll (который предположительно был вдохновлен когда-то именно jQuery),
• fetch для работы с AJAX,
• delegated-events для обработки событий,
• полифиллы для работы с DOM,
• пользовательские элементы (Custom Elements), которые сейчас на подъеме.

Помимо Custom Elements, ничего другого из Web Components было решено не использовать. Разработчики присматривались к Shadow DOM и были бы не против прибегнуть к нему — однако, в силу того, что на полифиллах скорость поиска в DOM оставляет желать лучшего, им пришлось пока отложить эту затею.

Зачем разработчикам в принципе потребовалось все это сделать? По их словам, для того, чтобы «отдавать» посетителям меньше килобайт, иметь возможность использовать более явно выраженный синтаксис для выполнения манипуляций с DOM, а также ради возможности использовать библиотеку Flow.JS для статического анализа типов. По словам разработчиков, процесс ухода с jQuery занял годы.

До недавнего времени в Одноклассниках около 50 ТБ данных, обрабатываемых в реальном времени, хранилось в SQL Server. Для такого объема обеспечить быстрый и надежный, да еще и устойчивый к отказу ЦОД доступ, используя SQL СУБД, практически невозможно. Обычно в таких случаях используют одно из NoSQL-хранилищ, но не всё можно перенести в NoSQL: некоторые сущности требуют гарантий ACID-транзакций.

Это подвело нас к использованию NewSQL-хранилища, то есть СУБД, предоставляющей отказоустойчивость, масштабируемость и быстродействие NoSQL-систем, но при этом сохраняющей привычные для классических систем ACID-гарантии. Работающих промышленных систем этого нового класса немного, поэтому мы реализовали такую систему сами и запустили ее в промышленную эксплуатацию.

Как это работает и что получилось — читай под катом.

Привет, Хабр! Представляю вашему вниманию перевод статьи "10 Tips to Designing Perfect Forms".


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

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

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

Снял интервью с сисадмином, который открыл свой ИТ-аутсорсинг. Работал сам на себя, но дорос до 6 сотрудников. И вообще, нормально так поднялся. Освещаю его опыт развития через «виральный маркетинг» (его рост клиентской базы сейчас идёт в основном через рекомендации) и про разделение обязанностей, чтобы скинуть с себя рутину. Всё происходит в небольшом городе (250 тысяч население).

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

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

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

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

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

Здравствуйте, меня зовут Наталья, я инженер по тестированию компании Docsvision.
Иногда, когда я просматриваю ошибки, записанные новенькими (а иногда и старенькими) тестировщиками, рука машинально тянется к лицу. В голове возникает только одна мысль:



«Что? Что я сейчас прочитала?»

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

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

Большинство сайтов можно отнести к маленьким и очень маленьким проектам, масштаба единиц человеко-месяцев. В силу малости размеров такие проекты спокойно поддаются хорошему продумыванию и легко реализуются с помощью водопадной модели, достаточно просто не лениться на каждом этапе разработки (от написания ТЗ до сдачи проекта). Применять к этим проектам гибкие методологии разработки нет смысла, а как раз есть смысл применять хорошее ТЗ. К тем сайтам, которые не попадают под водопадную модель не стоит применять описанный ниже подход.

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Как мы уже писали в своей первой статье, мы в Just AI специализируемся на технологиях искусственного интеллекта для понимания естественного языка (NLU). У нас есть своя платформа для разработки разговорных ассистентов, как текстовых, так и голосовых. Платформа имеет развитую функциональность для решения NLP-задач (кластеризация логов, поиск семантически близких фраз и др.) и собственный язык разработки (Just AI DSL). С использованием DSL команда лингвистов-разработчиков пишет код сценариев чатботов, интеграционные модули для связи с внешними системами, а также автотесты.

В этой статье мы расскажем о созданном нами инструменте для разработки ботов под разные платформы, в том числе для Яндекс Диалогов, без знания DSL и навыков программирования.

Сразу после событий с блокировками Telegram в Иране и России, в бета-версиях мессенджера начал появлятся новый тип Proxy, а если быть точным, новый протокол — MTProto Proxy.

Этот протокол был создан командой Telegram для решения проблем обхода блокировок, но так ли он хорош?