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

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

Пару лет назад я начал исследовать приложения телеграм, протокол MTProto. Я использовал некоторые методы API не по назначению, в общем, был типичным пользователем телеграм, пока не заметил некоторую особенность, о которой мало кто упоминает, возможность изучить которую отсутствует в большинстве официальных графических приложений (за исключением Telegram X). Я начал исследовать ее и решил поделиться об этом с читателями Хабра.

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

Кирилл Розов @kirich1409, известный многим Android-разработчикам, на нашей конференции Mobius выступал с докладом «Как пройти архитектурную секцию собеседования». А заодно на той же конференции ответил Анне Жарковой @anioutka на более общие вопросы о собеседованиях в целом, не связанные с мобильной разработкой.

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

Как всё начиналось

Всем привет! Меня зовут Елена Поплоухина. Я — один из авторов Youtube‑канала по тестированию «Багаж тестировщика».

На канале выходил выпуск про построение процесса ручного тестирования с нуля. Данная статья содержит основную информацию из этого выпуска — 2 общих совета и 6 первых шагов для организации процесса.

Всем привет!

О том как я делал бота, который файлы с Яндекс.Диска показывает, для лично-производственных целей.

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

И вот на рынке появляются сотни, если не тысячи резюме вчерашних выпускников курсов, с одинаковыми резюме, одинаковыми заявленными скиллами, инструментами. Кто-то даже с опытом работы в IT.

Так как же понять, кто из кандидатов действительно хорош?

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

Идея написать статью про стрелочные функции в 2023 году выглядит не самой очевидной, но я постараюсь объяснить свою мотивацию. Я разработчик, который пришел в профессию после того, как в JavaScript появились такие инструменты как классы, async/await, стрелочные функции и т.д.. В результате, я воспринимаю их как данность и не всегда понимаю, какой важный вклад они внесли в современный JS. И из-за этого непонимания в коде появляются ошибки, которых можно избежать, если оглянуться назад и изучить, какие проблемы эта технология была призвана решить в момент выхода. В этой статья я хочу разобраться: зачем появились стрелочные функции, чем они отличаются от обычных, и какие особенности содержат. 

Переписали виртуальную машину на новый DSL

И теперь ее гораздо проще менять, оптимизировать и проводить эксперименты.

В качестве примера, можно посмотреть на попытку добавления register-based интерпретатора. Другой пример, что часто два опкода идут вместе и выполняются последовательно большую часть времени. Например, LOAD_CONST и RETURN_VALUE. Для оптимизации, можно добавить новый опкод этой операции. Вместо двух действий он будет выполнять одно. На частых задачах получится неплохая прибавка к производительности. 

Еще один пример: опкод CALL_FUNCTION. Сам по себе довольно медленный. У него есть целая семья оптимизаций, например специализация CALL_FUNCTION_ISINSTANCE, когда мы выкидываем промежуточный слой и сразу вызываем C-реализацию isinstance. Минус в том, что Python богатый и динамически типизированный язык. В runtime может что-то поменяться и мы получим замедление — придется сваливаться обратно на общий путь опкода CALL_FUNCTION.

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

Всем привет! Перед началом статьи сразу скажу:

САМЫЙ ВАЖНЫЙ ДИСКЛЕЙМЕР: естественно, покупая смс на чужой номер вы полностью компрометируете безопасность своего аккаунта. Мало ли кто его потом еще купит для получения доступа. Поэтому, помните, что представленный в данной статье способ получения доступа - это только на "поиграться". Не стоит вводить туда свои реальные почты и использовать это в работе, так как полученный доступ может быть в любой момент взломан/прикрыт.

Но да ладно, приступим. Здесь без всякого объяснения того что такое ChatGPT - кому надо тот знает. В этой статье я хочу поделиться путем который вас за 30Р может к этому боту привести. Вдаваться в детали бота я не хочу, это чисто статья для ребят которые хотят без лишних запар пройти путь человека который доступ к боту уже получил :)

Как и многих вокруг, меня удивила новая технология от Open AI. Попытался зайти и зарегистрироваться через гугл, но...

Привет, Хабр! Я - начальник отдела разработки небольшой IT-компании, и мы - те самые люди, которые не ищут на работу сеньоров, и мы готовы брать не только мидлов, но даже и джуниоров, и готовы растить их до уровня крепких мидлов. Однако 80% приходящих на вакансию frontend-разработчика соискателей, даже называющих себя мидлами, с опытом работы, по сути оказываются не то что джуниорами - вообще не программистами. Что же на самом деле должен знать джун, чтобы попасть в компанию, подобную нашей, и как к этому прийти, если за плечами нет высшего программистского образования или богатого опыта программирования в школе? Я расскажу об этом и о том, как устроен процесс найма в нашей компании.

Базовый уровень программирования

Итак, к нам приходит среднестатистический кандидат, который прошел курсы по JavaScript, сделал там пару проектов. Потом узнал, что во многих местах хотят React, сходил на курсы по нему, тоже сделал пару проектов, выложил их на Github. Приходит к нам, уверенный в себе. И мы его просим написать функцию, которая выбирает из строки все большие буквы, или реализовать "вручную" какой-нибудь метод из array. И половина кандидатов в этом месте выбывают из строя. Кто-то вообще не может это сделать, у кого-то на двухминутную функцию уходит больше получаса. Зачем мы вообще это спрашиваем и почему с этого начинаем?

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

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