В статье рассматриваются этапы поиска работы Java-разработчиком в 2025 году. Требования к резюме. Советы по прохождению. Технические вопросы с собеседований. Варианты развития событий. Немножко мемов. Моральная сторона вопроса. В 2025 году вышло много статей про падение рынка айти. Давайте посмотрим, есть ли ещё шанс найти работу или пора на завод.

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

Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.

А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.

Всем привет. Я сеньор и тимлид на .NET (C#). До недавнего времени работал в Росатоме, пока там внезапно не сократили целую дирекцию по цифровизации. Так что пришлось срочно выходить на рынок, причём, впервые в моей жизни (до этого работа находила меня сама). По результатам нескольких циклов собеседований получился неплохой дневник, который я здесь привожу.

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

Срезы (slices) в Go могут показаться простыми при первом знакомстве, но их эффективное использование требует понимания внутреннего устройства и особенностей работы с памятью. Многие разработчики сталкиваются с путаницей между понятиями длины и емкости срезов, что может привести к неэффективному использованию памяти или даже утечкам. Важно разобраться, как эти концепции работают при выполнении базовых операций: инициализации, добавлении элементов, копировании и нарезке.

В этой статье мы рассмотрим внутреннее устройство срезов, длину, емкость и связь с базовыми массивами, а также разберем распространенные ошибки и оптимальные практики их использования. Мы изучим особенности работы с функциями append и copy, узнаем, как предотвращать утечки памяти при работе с большими срезами, и обсудим различия между нулевыми и пустыми срезами. Также уделим внимание вопросам производительности, включая правильную инициализацию срезов и работу с указателями, чтобы помочь вам писать более эффективный и безопасный код.

Большую часть жизни я думал, что музыка — это не мое, хотя и отучился несколько лет по классу фортепиано. Когда-то очень давно вполне сносно играл какую-нибудь пьесу с листа, но вот удовольствия это не приносило. Я и подумать не мог, что спустя 20 лет начну с нуля осваивать игру на электрогитаре и это станет одним из моих любимых хобби.

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

Всем салют!

Хочу рассказать вам историю о том, как я начинал с уровня — «не могу решить даже 1 easy задачу из 10» до уровня — «могу решить каждую вторую medium задачу» и прошел несколько coding сессий в таких компаниях как Meta, Booking, Careem, Avito...

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

Сегодня предлагаю рассмотреть вариант сборки домашнего NAS дендральным методом.

Всё описанное в статье является результатом деятельности моего воспаленного мозга поиска оптимальной конфигурации для своего домашнего файлохранилища и не является призывами к прямому действию. Представляет из себя изыскание того самого продукта, который может максимально покрыть мои потребности за сравнительно небольшую плату. Не поднимает вопрос о подлинности и законности использования указанного решения на территории предприятия, для всего остального – есть GPL v2.

Готовый набор окружения веб сервера на базе контейнеров Docker. Включает в себя MySQL, PHP, NGINX, composer, SSL сертификаты и механизм резервного копирования в облако.

Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих от Бхаргава А. Эта книга рекомендована Яндекс Практикум при подготовке к алгоритмическому собеседованию. Сам автор указывает, что книга для самоучек, студентов, выпускников и тех, у кого программирование не является основным профилем.

Мое впечатление неоднозначно. С одной стороны, до сего момента я не встречал описания динамического программирования, поиска кратчайшего пути в графе по алгоритму Дейкстры и использование K ближайших соседей для классификации и аппроксимации (возможно, все это есть в 4^м или последующих томах Кнута, но в магазине они мне не встречались). С другой стороны, описания и примеры, приведенные в книге, таковы, что практической пользы не представляют. Описания очень поверхностны, примеры нарочно примитивны, код в половине случаев не приведен. Но даже там где есть код, он нарочито упрощен под конкретный пример и на практике бесполезен.

Казалось бы, есть масса книг - каталогов шаблонов. Они реально полезны и новичку и профессионалу. Эта книга не из их числа. Но, видимо, это и не было целью. Напоминает научно-популярные книги издававшиеся в СССР: простым языком рассказывает о сложных вещах, прививает у читателя интерес к теме, расширяет кругозор. Не более. Но тоже важно.

Вернемся к Яндекс Практикум и их рекомендации. Если алгоритмы так важны, то почему именно эта книга? Есть масса других, где и алгоритмов больше и разобраны они так, что бери да пользуй. Например, классический труд Д. Э. Кнута Искусство программирования. Да, рисунки в детском стиле в Грокаем алгоритмы забавны. Но иллюстрации в Искусство программирования полезны для понимания. Разве это не важнее, если уж кандидата посылают на алгоритмическое собеседование?

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

Я постарался копнуть в каждый вопрос чуть глубже чем, возможно, надо бы — что бы у читателя был не только короткий ответ на вопрос, но и некоторое понимание "а почему именно так устроена та или иная штука". Более того, крайне рекомендую ознакомиться и с ссылками на источники, что будут под ответами — там вы найдете более развернутые ответы.

Да, это очень объемный пост, и вряд ли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.

В этой статье я хочу поделиться примером, как можно развернуть простое приложение на Golang в Kubernetes, с помощью helm чартов и skaffold скриптов. Думаю, данная статья может быть полезной тем разработчикам, которые только знакомятся с Kubernetes, а возможно и более опытным разработчикам, которые смогут почерпнуть что то интересное для себя.

Как сейчас проходят собеседования на golang разработчика? Что спрашивают?

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

На связи Паша Емельянов, тимлид в AGIMA. В этой статье расскажу, как на одном из проектов мы переписывали старый функционал, разработанный когда-то на PHP, на Golang, с какими проблемами столкнулись и как их решали. Статья будет интересна и начинающим, и миддлам, а еще системным архитекторам, т. к. здесь затронем как инфраструктурные вопросы, так и вопросы реализации конкретного сервиса под потребности бизнес-заказчика.

Как я писал в предисловии предыдущей статьи, я нахожусь в поисках языка, в котором я мог бы писать поменьше, а безопасности иметь побольше. Моим основным языком программирования всегда был C#, поэтому я решил попробовать два языка, симметрично отличающиеся от него по шкале сложности, про которые до этого момента приходилось только слышать, а вот писать не довелось: Haskell и Go. Один язык стал известен высказыванием "Avoid success at all costs"*, другой же, по моему скромному мнению, является полной его противоположенностью. В итоге, хотелось понять, что же окажется лучше: умышленная простота или умышленная строгость?

Я решил написать решение одной задачки, и посмотреть, насколько это просто на обоих языках, какая у них кривая обучения для разработчика с опытом, сколько всего надо изучить для этого и насколько идиоматичным получается "новичковый" код в одном и другом случае. Дополнительно хотелось понять, сколько в итоге мне придется заплатить за ублажание хаскеллевского компилятора и сколько времени сэкономит знаменитое удобство горутин. Я старался быть настолько непредвзятым, насколько это возможно, а субъективное мнение приведу в конце статьи. Итоговые результаты меня весьма удивили, поэтому я решил, что хабровчанам будет интересно почитать про такое сравнение.

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

Теперь я постараюсь показать, как этот пакет можно использовать на примере простейшего бэкенда для апплета “Труд всем”. Немного поясню идею этого апплета. Допустим у нас есть любой сайт — от хомяка до новостной ленты, а в любом свободном углу при обновлении страницы показана случайная вакансия. Код апплета будет отправлять запрос на сервер и получать в качестве результата HTML код (уже готовый рендер) для вставки на страницу сайта.

Правда интригующе? Где же получать информацию о вакансиях? Где хранить эту информацию? Какие критерии отбора вакансий использовать? Для того, чтобы узнать ответы на эти вопросы, прошу заглянуть под кат!

В мире программирования существуют технологии, must have для каждого разработчика, к числу которых относится и Docker. Подразумевается, что это просто, как таблица умножения, и известно всем. О том, зачем в 2021 году в 100500й раз заводить разговор про докер — статья Сергея Кушнарева, руководителя отдела разработки ZeBrains.

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