Пожалуй, самое большое количество вопросов возникает при кластеризации запросов. Точность ручной кластеризации опытного оптимизатора не превышает 40%. Это значит, что если вы не эксперт в нише для которой собираете ядро — лучше прокачать свои знания в ней или воспользоваться автоматом. Вся сложность в том, что каждый запрос имеет интент (задача, которую подразумевает пользователь при поиске). Поисковая система интент прекрасно определяет и знает. А вот человек — отнюдь не всегда. Кроме того, одни интенты могут продвигаться на одной странице, другие — нет. Поэтому, выполняя ручную кластеризацию следует смотреть на выдачу — как разделено именно там. Если в выдаче по одинаковым запросам присутствуют одинаковые страницы в ТОП — значит их можно продвигать на одной странице.

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

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

Когда в кино показывают компьютерных злодеев — это часто выглядит печально. Взлом системы, к примеру, обычно изображают, как быстро бегущие строки, которые сменяет большая зеленая надпись «Доступ получен». Режиссеров очень редко волнуют всякие мелочи, которые на их взгляд понятны только специалистам. А мы подходим в вопросу образования крайне серьезно. Программы обучения в образовательном проекте OTUS —
это всегда белые методы, с современным и легким подходом, порой, увлекает, так, что теряешься во времени. Чтобы не пропустить следующий День Открытых Дверей курса «Python», который состоится 17 ноября, поставьте себе напоминалку на 20:00 и подключайтесь к трансляции из любого города, страны, континента. И наконец, чтобы завладеть желанной целью получить бесплатное образование в OTUS нужно пройти тестирование https://goo.gl/jiaW8e

О чем говорят логи Garbage Collector?

Наверняка вы слышали, что сборщик мусора в Java может оказывать значительное влияние на производительность приложения. Многое может зависеть от типа сборщика и его настройки. Есть много инструментов для того, чтобы мониторить различные параметры сборки, но иногда достаточно внимательно посмотреть на логи, которые пишет GC. В этой заметке я расскажу, как выглядят логи, которые пишет сборщик мусора и что с помощью них можно понять о работе вашего приложения. Для начала, нужно запустить JVM, указав специальные параметры:
«-XX:+PrintGCDetails» — печатать детали о событиях сборки мусора
«-XX:+PrintGCDateStamps» — также печатать timestamp этих событий
«-Xloggc:/home/otus/gc.log» — опционально можно указать, в какой файл будут писаться логи, чтобы отделить их от логов вашего приложения.
Сборщики мусора SerialGC, ParallelGC, ConcurrentMarkSweepGC (CMS) разбивают память (хип) java-приложения на несколько регионов. Это «Eden+Survivor1+Survivor2» — молодое поколение и Tenured — старое поколение. Сборщик GC1 устроен иначе и его стоит рассматривать отдельно.
Сборки мусора могут происходить только в молодом поколении — Minor GC или во всех регионах — FullGC. Давайте посмотрим на логи на примере «ParallelGC (-XX:+UseParallelGC)».
В этих логах отображено 3 сборки мусора, сначала 2 minor, затем full:
«2017-09-17T21:03:30.200+0300: 0,449: [GC (Allocation Failure) [PSYoungGen: 3662K→336K(4608K)] 3662K→3408K(15872K), 0,0020199 secs] [Times: user=0,01 sys=0,00, real=0,01 secs]
2017-09-17T21:03:30.506+0300: 0,755: [GC (Allocation Failure) [PSYoungGen: 3652K→400K(4608K)] 6724K→6544K(15872K), 0,0021768 secs] [Times: user=0,01 sys=0,00, real=0,00 secs]
017-09-17T21:03:30.815+0300: 1,064: [Full GC (Ergonomics) [PSYoungGen: 400K→0K(4608K)] [ParOldGen: 9216K→9581K(18944K)] 9616K→9581K(23552K), [Metaspace: 3570K→3570K(1056768K)], 0,0047284 secs] [Times: user=0,00 sys=0,00, real=0,01 secs]»

«2017-09-17T21:03:30.200+0300» — сперва идет timestamp — абсолютное время, когда сборка была начата, затем время относительно старта приложения (0,449).

GC (AllocationFailure) — указывает, что это минорная сборка, при полной сборке будет указано Full GC. Причина начала сборки: не удалось выделить (allocate) место под новый объект.

PSYoungGen — тип сборщика. PSYoungGen — это сборка молодого поколения в ParallelGC. Также вы можете встретить DefNew — сборка молодого поколения в SerialGC, ParNew — сборка молодого поколения CMS.
Дальше идет самая интересная с практической точки зрения часть — занятая память до и после сборки по регионам:
«[PSYoungGen: 3662K→336K(4608K)]» — В молодом поколении до сборки было 3662K, после — 336K. Всего в регионе доступно памяти — 4608K.
«3662K→3408K(15872K)» — Статистика по всему хипу, доступно 15872K. И здесь мы видим интересный момент, что в молодом поколении освободилось 3326K, а общее место в хипе уменьшилось только на 3662 — 3408 = 254К. Это означает, что часть объектов были перемещены из молодого поколения в старое (promoted).
Сборка заняла 0,0020199 secs.
Для FullGC в логах видно статистику по всем регионам памяти, так как сборка запускается и в молодом и в старом поколении.
«[PSYoungGen: 400K→0K(4608K)] [ParOldGen: 9216K→9581K(18944K)] 9616K→9581K(23552K), [Metaspace: 3570K→3570K(1056768K)], 0,0047284 secs]»
«[Times: user=0,01 sys=0,00, real=0,01 secs]»
User — user-space время (операции вне ядра ОС), затраченное на GC. Sys — kernel-space — время, затраченное на системные вызовы ОС. Real — реальное время от начала и до конца сборки мусора. В нем учитывается, то время, пока процесс был прерван ОС или заблокирован (например, на IO).
При использовании параллельной сборки User-space время может быть больше чем real-time, потому что user-space будет суммироваться по всем CPU, на которых исполнялась сборка.
Вооружившись этими знаниями, вы сможете в рантайме смотреть за поведением GC и определить, не выросли ли паузы или количество FullGC. Как используется память вашего приложения и как объекты перемещаются между регионами памяти. Понимание этих процессов дает возможность более вдумчиво подойт

и к настройке вашего приложения.

#deeppostjava

Java EE в естественной среде обитания.
С каждым днем мы получаем все больше заявок на обучение от людей с начальным уровнем знаний и вынуждено отказываем в обучении, так, как проект OTUS направлен на стремительное увеличение профессионального опыта для тех, кто уже состоялся, как профессионал. Сегодня, как и вчера, мы не набираем группы Junior Java Enterprise. Курс «Разработчик Java Enterprise» — это бесценный обмен опытом с профессионалами высокого уровня для профессионалов высокого уровня в естественной среде обитания. Эти уникальные знания и опыт от преподавательского состава нашего проекта вы получаете «из первых рук». Вы полностью погружаетесь в атмосферу сильных профессионалов, вы развиваетесь в стремительном темпе в полностью адаптированной среде. Мы не просим вас тратить самый драгоценный ресурс «ваше время» на пустые разговоры или скучные лекции. Курс «Разработчик Java Enterprise» носит уникальный характер и достоин вашего внимания. Подробности программы обучения https://goo.gl/bqRo2T

Мы разделяем любовь Виталия Чибрикова (автора курса «Разработчик Java») к Java, поэтому грядущий набор на курс будет в OTUS уже 4-тым. Группа #1 уже закончила обучение и радует нас приятными отзывами о курсе и карьерными успехами на новых местах работы. Группа #2 недавно тоже закончила обучение и находится в активной фазе трудоустройства. Желаем ребятам успехов!
Опыт выпущенных групп позволил нам максимально доработать программу под потребности рынка, сместить акценты в сторону того, что действительно важно студентам и работодателям.
Ряды Java-преподавателей пополнили опытные разработчики и сертифицированные преподаватели Дмитрий Архангельский и Олег Климаков. При этом мы сохранили дружескую атмосферу на занятиях, где есть место серьезным вопросам и подробным ответам, монологам преподавателя и интерактивам для студентов. Мы продолжаем давать студентам не всегда простые домашние задания (но ведь тяжело в учении, легко в бою, да?), чтобы максимально эффективно закреплять практикой полученные знания. Несмотря на то, что преподаватели серьезно погружены в процесс проверки домашних заданий (ведь каждому студенту нужно дать развернутый фитбек в течение двух суток), у них остается время на дискуссии со студентами — ведь мы создали живое комьюнити по Java, где студенты делятся своим опытом, обсуждают домашние задания и лекции. Случается так, что кто-то из студентов пропустил вебинар (или несколько по причине, например, отпуска). В этом случае комьюнити и видеозаписи вебинаров (они всегда будут доступны студенту), помогут наверстать упущенное.
Хотите посмотреть, как проходит вебинар, чтобы оценить, подходит ли вам такой формат? Посмотрите небольшое видео с одного из вебинаров — говорим про SOLID.
Если вам интересна серьезная разработка на Java, хочется новых кейсов, опыта, знаний и карьерных возможностей, хочется учиться с удовольствием и вы не боитесь трудностей — приходите к нам на курс. Мы начнем погружаться в тонкости Java уже завтра! Смотреть видео https://goo.gl/aE6hpH

Дорогие друзья, в связи с тем, что deeppost Java, который мы подготовили для вас, имеет сложную структуру подачи, мы не можем отправить его в канал Telegram и приглашаем вас к прочтению статьи на официальной странице facebook OTUS https://goo.gl/vjkNTM

Ура! Наступил долгожданный день! Сегодня стартует первый день занятий у четвертой группы программы обучения «Разработчик Java»!
Поздравляем слушателей курса и наших преподавателей с этим событием. Популярность курса Java растет каждый день и увеличивается в геометрической прогрессии, а это говорит о том, что специалистов с каждым днем будет становиться больше и больше. Сегодня последний день, когда можно записаться на обучение в группу #2 по курсу «Разработчик Java» https://goo.gl/KLKw6P

Друзья, сегодня День Открытых Дверей по курсу «Разработчик Python»! Начало трансляции в 20:00 по московскому времени. Именно сегодня состоится розыгрыш бесплатных мест обучения для тех, кто прошел тестирование.
Пройти тестирование можно тут https://goo.gl/EsNEmj
Присоединиться к трансляции https://goo.gl/XX9xXn
Станислав Ступников программист компании Mail.ru, преподаватель образовательного проекта OTUS сегодня в 20:00 по московскому времени в прямом эфир для вас. Можно и нужно задавать все волнующие вопросы об обучении, формате занятий и т.п. Все самые популярные вопросы: а как? а почему? а можно ли …? Будут рассмотрены именно сегодня. Присоединяйтесь!

Говоря об оптимизациях, мы должны понимать сложность используемых алгоритмов, но, зачастую, имеем ввиду только вычислительную сложность. Конечно, скорость работы алгоритма - это очень важная метрика, но мы можем и не успеть полностью, утилизировать CPU, если у нас кончится память. В реальном мире есть много ресурсов, которые надо беречь. Не про деревья и воду, а дисковый и сетевой ввод/вывод, объем кэша и даже скорость памяти. Попробуем оценить аппетит поедания памяти в динамике. Насколько легко понять, сколько и какой памяти требуется для работы нашему чудо-сервису?
«#include <array>»
«#include <memory>»
«auto static_storage = std::array<char, 0x40000000>();»
«int main(int argc, char *argv[])»
«{« «static_storage.fill(0);»
«auto dynamic_storage = std::make_unique<std::array<char, 0x40000000>>();»
«dynamic_storage->fill(0);»
«auto automatic_storage = std::array<char, 0x400000>();»
«automatic_storage.fill(0);»
«return 0;»
«}»
В примере трижды вызывается конструктор «std::array» и трижды метод «fill». Как меняется потребление памяти после выполнения каждой из этих строк? Как влияет на потребление памяти то, что первый объект со статическим временем жизни, второй в куче (да, при этом сам указатель на стеке), а третий целиком на стеке? Зачем в примере используется метод «fill», память и так уже выделена, в чем подвох? Почему память выделяется не в том порядке, в котором можно было бы ожидать? Оптимизация ни при чём. И, кстати, сколько раз массивы будут заполнены значениями? Конструктор «+ fill» и, так три раза – неверный ответ. #deeppost c++

Спешим сообщить, что 17 ноября завершился День Открытых Дверей по курсу «Разработчик Python». По традиции в гонке тестирования «светлых умов программирования» есть два победителя, которых мы спешим поздравить с тем, что они заслуженно получают в награду бесплатное образование по курсу «Разработчик Python». Ура! А, те, кто хотел присоединиться к трансляции, но не смог, приглашаем к просмотру на официальном канале YouTube образовательного проекта OTUS https://goo.gl/tNKCEg Друзья, спасибо всем, кто присутствовал на встрече! И увидимся на первом занятии!

Друзья, сегодня особенный день! В образовательном проекте OTUS, сегодня, в 19.00 часов по московскому времени, будет проходить открытый урок по Java EE. В формате вебинара будут рассмотрены вопросы проектирования API на платформе Java. Слушатель научится разрабатывать приложения построенные на базе SOA с использованием технологий «JAX-WS» и «JAX-RS». Присоединиться к трансляции можно тут https://goo.gl/Zx57tu

А мы начали говорить, про Java EE :) https://www.youtube.com/channel/UCetgtvy93o3i3CvyGXKFU3g/live

Если вы еще думаете, чем заняться в декабре — эта информация для вас! 27 ноября нас ждет уникальный День Открытых Дверей посвященный курсу «Разработчик C++». Великолепный специалист и виртуозный преподаватель Дмитрий Шебордаев в прямом эфире! Профессионал высокого уровня, выпускник МГУ, персона youself, совершенствуется c каждым днем и с радостью делиться своим опытом с нами!
Обратите внимание, что разработчик C++ в OTUS — это не начальный курс для новичков или тех, кто еще ищет себя в профессии. Это сильный курс для сильных. Это не просто скучные лекции или учеба по принципу «Ну, что нового вы сможете мне рассказать?». Это глубокий курс с увлекательным погружением в мир C++. Только лучшее, только самое смелое, ловкое и увлекательное в процессе обучения. Совершенствоваться вместе с OTUS, в атмосфере абсолютных профессионалов и единомышленников — это быстрый рост профессиональных навыков, достижений и личных побед. 80% наших учеников меняют свои профессиональные предпочтения после обучения в лучшую сторону. Ведь мы не только учим, мы вдохновляем на достижение наивысших результатов и гордимся каждым из вас!
Работодатели по окончании курса: Yandех, Luxoft, Kaspersky, КРОК, 1C. Перед началом трансляции протестируй свои знания и, кто знает, может быть именно Вам выпадет уникальная возможность бесплатного обучения в OTUS https://goo.gl/5XVuSY

Mail API. Среди распространенных требований, предъявляемых к приложениям уровня Enterprise, следует отметить необходимость отправки электронных писем на стороне сервера. Например, может потребоваться отправить сообщение пользователю после регистрации или смены пароля в системе, или же отправка сообщения с новостной рассылкой. Нет сомнений, что каждый найдет свой случай для применения этой полезной функциональности. Рассматривая стек технологий JavaEE, важно отметить, что все необходимое для отправки электронных писем доступно «из коробки» и можно использовать для любого JavaEE-приложения. Данная технология так же известна, как «Mail API», располагающаяся в пакете «javax.mail». Важно понимать, что JavaEE не решает вопросов создания почтового SMTP-сервера. Для этих целей Вы можете использовать готовые решения, к примеру, любой общедоступный сервер как Gmail, Yandex, Mail и т.д. Для целей отправки писем достаточно знать параметры используемого почтового сервера: имя и порт сервера, параметры соединения. Для безопасной отправки писем также допустимо использование «SSL» и «TLS-протоколов». С помощью «Mail API» можно отправлять не только простые письма, но и включать вложения, прикреплять изображения, документы, использовать HTML-форматирование и т.д. Наиболее значимые сущности для возможности отправки email — это класс Session, инициализирующий основные параметры для соединения с SMTP-сервером, MimeMessage, включающий информацию о получателе письма, теме, теле и вложениях сообщения, а также класс Transport, реализующий непосредственную отправку методом void send(MimeMessage message). Обратите внимание, что количество инициализируемых параметров соединения класса Session напрямую зависит от типа SMTP-сервера. Для серверов, в которых не требуется какой-либо аутентификации, достаточно указать лишь свойство «mail.smtp.host» и оставить без изменения 25й порт, используемый по умолчанию. Но для случаев использования почтовых серверов, поддерживающих SSL или TLS аутентификацию, важно детализировать оба параметра «mail.smtp.host» и «mail.smtp.port». Если рассматривать Gmail в качестве почтового сервера, то в нем используются 465й и 587й порты для SSL и TLS, соответственно (самая актуальная информация о деталях почтового сервера Gmail доступна по ссылке). Взгляните на код метода, обеспечивающего отправку письма, используя TLS-аутентификацию: «public static void sendEmail(final String username, final String password)»
«throws MessagingException {»
«Properties props = new Properties();»
«props.put(„mail.smtp.auth“, „true“);»
«props.put(„mail.smtp.starttls.enable“, „true“);»
«props.put(„mail.smtp.host“, „smtp.gmail.com“);»
«props.put(„mail.smtp.port“, „587“);»
«Session session = Session.getInstance(props,»
«new javax.mail.Authenticator() {»
«protected PasswordAuthentication getPasswordAuthentication() {»
«return new PasswordAuthentication(username, password);»
«}»
«});»
«Message message = new MimeMessage(session);»
«message.setFrom(new InternetAddress(„youremail@gmail.com“));»
«message.setRecipients(Message.RecipientType.TO,»
«InternetAddress.parse(„whomemail@gmail.com“));»
«message.setSubject(„Your Subject“);»
«message.setText(„This is test email! Don’t answer!“);»
«Transport.send(message);»
«}»
Данный код в особых комментариях особо не нуждается, поэтому для лучшего закрепления материала предлагается реализовать метод, который отправляет email через Gmail, но уже с использованием SSL-аутентификации.

Друзья, приглашаем Вас к прочтению свежей и полезной статьи "Применение DevOps практики Infrastructure as Code (IaC)" опубликованной на официальной странице OTUS в Facebook. Читать сейчас https://goo.gl/LB4VXA

Внимание, уже через час стартует сразу два Дня Открытых Дверей по курсам: «Разработчик Python» и «DevOps практики и инструменты». Старт встреч ровно в 20:00 по московскому времени. Трансляция встречи «Разработчик Python» https://goo.gl/C2Rwpp
Трансляция встречи «DevOps практики и инструменты» https://goo.gl/95nRGe

У вас есть еще час, чтобы пройти тестирование и принять участие в розыгрыше бесплатных мест обучения. До встречи в прямом эфире!

Мы начинаем дни открытых дверей по курсам «DevOps практики и инструменты» и «Разработчик Python». Присоединяйтесь!

20 ноября проходил открытый вебинар по курсу «Разработчик JavaEE» в OTUS. Почти 500 человек в прямом эфире с экспертом по Java технологиям Виталием Ивановым. Смотреть запись вебинара можно тут https://otus.pw/PEmF/

Ни для кого не секрет, что язык PHP имеет довольно низкий порог вхождения, что делает его как одним из самых удобных языков для быстрого создания веб-приложений, так и самым уязвимым для неоптимизированного кода. Зачастую разработчики даже middle-уровня ограничиваются в своей работе тем, что используют среды разработки типа OpenServer или XAMPP. Разумеется, для небольших проектов в этом нет ничего фатального, но как только размер проекта вырастает, то появляются новые проблемы, которые до этого не были известны. Во-первых, большие проекты не терпят отключения на время обновления кода. При этом на самом сервере, ни о каком OpenServer речи не идет — зачастую случается, что у разработчика стоит Windows, а на сервере работает Linux-подобная ОС. При выкатке проекта выясняется, что код, который работал локально, вдруг перестаёт работать в Production-окружении, прерывая работу ресурса. Во-вторых, большие проекты не ограничиваются простым делением на DEV и PROD. Они имеют сервера QA, где идет приемочное тестирование, имеют множество разработчиков, которым к тому же надо обмениваться своими наработками. И их среды разработки тоже могут отличаться, к примеру, потому, что кто-то не обновил ПО. Так что же делать в таких ситуациях? На помощь приходят виртуальные машины, которые собираются по строго заданным шаблонам с предустановленным единообразным LAMP/LNMP-стеком. Их прелесть также и в том, что они совершенно беспроблемно могут создавать неограниченное число копий Production-окружения, делая процесс разработки максимально гибким. Можно собирать машину вручную, но для быстрого старта можно использовать существующие решения автоматизации. Мы рассмотрим работу в Windows-системах. Достаточно будет двух программ — Vagrant и VirtualBox. VirtualBox — это среда для управления и запуска виртуальных машин, а Vagrant — это программа автоматизации их сборки. Более того, энтузиасты уже подготовили готовые инструкции для работы с PHP, NGINX, MySQL и другими популярными модулями стека. Если Вы планируете работать с этой сборкой, то установите также Git. При необходимости нужно добавить путь к Vagrant в переменную PATH. «set PATH=%PATH%;C:HashiCorpVagrantbin» Теперь мы можем создать отдельную директорию для нашей виртуальной машины или же перейти в уже созданную. Можно развернуть «голую» ОС Ubuntu, либо взять готовую сборку из репозитория на GitHub «https://github.com/kiaplayer/vagrant-php» Если рассматривать второй случай, то нужно будет выполнить команды «git clone https://github.com/kiaplayer/vagrant-php.git» Инструкция по сборке виртуальной машины располагается в директории «.chef.» Это файл Vagrantfile, который нужно скопировать на уровень выше. После этого уже можно запустить сборку самой виртуальной машины «vagrant up». По завершению её работы в меню VirtualBox появится новая строчка с Вашей только что созданной виртуальной машиной. Она уже имеет возможность подключения по сети, а также располагает стеком LNMP. Как видите, работа с виртуальными машинами совсем несложная!