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

Важно понимать, что вспомогательные глаголы для образования сложных времён — это не что-то особенное, и у нас они тоже есть: рус. буд.вр. он будет писать письмо, укр. дпр.вр. він був написав листа. Более того: колебания между использованием и неиспользованием вспомогательного глагола русскому языку тоже знакомы: в древнерусском было два простых прошедших времени (аорист, невѣжѧ писа недума каза "незнающий написал, недумающий показал", и имперфект, ѡни моляхуся аз же глумляхъся "они молились, а я шутил") и впридачу сложное, перфект: еси приходиле в русь "ты приходил в Русь", зарубати посылали есмо "мы посылали зарубать". Простые прошедшие времена исчезли из всех славянских языков, кроме болгарского и македонского; с перфектом же произошла более интересная история...

Приветствую, дорогие друзья! Меня зовут Алексей, и я backend java developer. На одном из моих проектов была задача -  предоставлять по требованию SQL запросы уходящие в БД, для этого их решили логировать.  В этой статье я постараюсь поделиться несколькими способами, которыми можно достичь данной задачи.

Проект был написан на Spring, поэтому все примеры будут на нём. Запросы были написаны с использованием JPA или сгенерированны через Spring Repository.

Самое многозначное слово в русском языке — «идти». У него 26 основных значений и еще больше десятка фразеологических. 

Вот только по многозначности английский язык сильно перегнал русский. В нем есть слова и с сотней значений, а рекордсмен в этом смысле имеет целых 645 дефиниций. 

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

К старту курса о разработке на Java делимся переводом вводной статьи о Quarkus — "родной" для Kubernetes Java-платформе для создания высокопроизводительных веб-, бессерверных (serverless) и нативных приложений (оптимизированных для используемых микропроцессоров). В ней используются предварительная компиляция AOT и агрессивная оптимизация, например сканирование путей к классам, перезагрузка конфигурации и предварительная конфигурация самозагрузки приложения в процессе сборки. Результатом становится впечатляющая скорость загрузки. Другими словами, приложения, созданные с Quarkus, запускаются не просто быстро, а очень быстро!

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

Сегодня мы поговорим о достаточно скользкой теме в грамматике английского. На вид она простая. «Bad» — прилагательное, а «badly» — наречие.

Но как сказать правильно: «I feel bad» или «I feel badly»? «I feel good» или «I feel well»?

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

Это ответ на переведенную публикацию «Почему Kotlin хуже, чем Java?». Поскольку исходная аргументация опирается всего на два примера, то не теряя времени пройдем по этим «недостаткам» Kotlin.

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

При этом английский язык на рынке уникален в этом “только не по учебнику”, потому что нет масштабного запроса, скажем, на немецкий/испанский/китайский/физику/биологию не по учебнику.

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

Все java-разработчики, рано или поздно, встречаются с пресловутой ошибкой OutOfMemoryError. 

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

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

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

Кто занимается этой очисткой? Как и когда очищается память? Как выглядит структура памяти? Давайте разберем с этим подробнее.

Сегодня хочу поговорить о том, как проводить one-to-one встречи. 

Сначала о том, зачем они вообще нужны. One-to-one встречи – это один из инструментов развития команды. На этих встречах вы постепенно, планомерное выстраиваете отношения с сотрудником. Прозрачные, ясные отношения, в которых становится возможным сотруднику развиваться. В итоге эти встречи работают на адаптацию сотрудников, на их мотивацию и удержание. 

На встрече важно обсудить не только задачи. Вот примерная схема проведения one-to-one встречи.

 1. О сотруднике. С этого стоит начать. Спросите, как у него дела, что у него в жизни происходит.  

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

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

 4. Компания. Тут вы возвращаете сотрудника к тому, что он часть компании, что он приверженец определённой группы. Поделитесь с ним новостями компании и спросите, как это ему, поделитесь информацией про команду и тоже спросите, как это ему. Таким образом вы закрепляете за человеком его вовлечённость. 

 5. Работа с тимлидом. Самый неудобный вопрос) Можно задавать в лоб: «Как тебе работается со мной?» или окольными путями: «Что бы ты хотел в нашем взаимодействии улучшить, как тебе one-to-one, что бы ты хотел вынести на one-to-one», и т.д.

 6. Кризисы. Если в команде возник конфликт, пертурбация (например, когда из-за вируса все стали работать из дома), не старайтесь делать вид, что ничего не изменилось. Разъясните сотруднику происходящее, спросите, как он чувствует себя внутри всего этого. Вы таким образом можете снизить его тревогу. Сейчас достаточно много вызовов мира, которые заставляют сотрудников поступать по разному. И для нас важно понимать, не останется ли завтра проект без важного сотрудника, по его личным причинам.

На одном из потоков курса «PSYvIT для управленцев» меня спросили, надо ли на каждой встрече говорить про компанию. Разве может отношение к компании меняться раз в неделю? Нет, не обязательно каждый раз, но раз в 2-3 недели спросите. Вопросы могут меняться: держите в фокусе компанию, а спросите про продукт, про новый релиз. Компания – это вообще про окружение сотрудника, про команду. Опять же, многое зависит от того, что в вашей компании происходит сейчас. Кроме вопросов, рассказывайте об успехах и изменениях, которые происходят. Очень важно, чтобы новости компании сотрудники узнавали от вас, а не из новостной ленты социальных сетей.

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

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

Всем привет.

Есть такие люди, которые работают с облачной инфраструктурой и не используют автоматизацию, потому что это долго, нужно вникать, а им надо фичи пилить. Накликали что-то там в UI, подключились по ssh, поставили всякого с помощью apt и т.д. и конфигурационные файлы ещё вручную поменяли. Документации конечно же написать времени не хватило или в ней много разных хитрых шагов и повторить настройку этой инфраструктуры в точности уже нельзя или очень сложно, а сервисы крутятся в проде. А потом человек забыл что и как делал в точности или вообще уволился.

Хочу показать на небольшом примере, что автоматизировать инфраструктуру, например в AWS, может быть достаточно просто и приятно, а получившийся результат достаточно прозрачен и сам по себе является документацией, т.к. это инфраструктура как код. Если конечно есть знания Terraform или желание его немного изучить.

Реактивное программирование — один из самых актуальных трендов современности. Обучение ему — сложный процесс, особенно если нет подходящих материалов. В качестве своеобразного дайджеста может выступить эта статья. На конференции РИТ++ 2020 эксперт и тренер Luxoft Training Владимир Сонькин рассказал о фишках управления асинхронными потоками данных и подходах к ним, а также показал на примерах, в каких ситуациях нужна реактивность, и что она может дать.

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

Большинство списков вопросов интервью по Spring Boot заставляют вас запоминать случайные детали из документации Spring Boot. Но запоминание — плохая замена истинному пониманию и уверенности в знании Spring Boot.

Поэтому сегодня мы собираемся применить другой подход. Вместо того, чтобы перечислять 50 вопросов по мелочам Spring Boot, мы сосредоточимся на 11, которые заставят вас задуматься и, таким образом, многому научиться на этом пути.
Вот они, в произвольном порядке.

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

1. Специфика англоязычного резюме