Добрый день меня зовут Александр и я токсичный душнила с двадцатилетним стажем в айти, готовый откусить вам кадык, как только вы расслабьтесь. Мои характеристики делают меня хорошим техническим собеседующим, поэтому добро пожаловать на моё провальное собеседование. Запомните, вы его никогда не пройдете. А знаете почему?

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

Если вкратце, то рабочий кейс, это когда: (А) имеется основание для снятия: уже живете зарубежом полгода, либо имеется иностранный ВНЖ, (B) грамотно составлено заявление на снятие с учета и подписано вашей подписью, (C) в военкомат идет ваш представитель по доверенности, которая оформлена у российского нотариуса или в зарубежном консульстве РФ.

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

Новый закон об электронных повестках потенциально касается практически всех российских мужчин от 18 до 70 лет. Я узнал у адвоката со специализацией в вопросах мобилизации, чем конкретно нам грозят эти нововведения, и можно ли как-то «выписаться из военкомата» удаленно.

Когда пользователи откликаются на Remote вакансии в LinkedIn, они часто не получают ответов. Есть подходы, которые помогают увеличить количество ответов на запросы, например, прямое общение с работодателями через Inmails. Но для верного и результативного общения требуется сделать ряд подготовительных действий. Первое из которых - обновление профиля в LinkedIN и исправление наиболее частых ошибок.

Типичные ошибки встречаются довольно часто, и могут негативно повлиять на профиль пользователя, уменьшить его шансы на получение откликов, ответов и работы.

Не стоит повторять одни и те же ошибки. Здесь мы рассмотрим 10 типичных ошибок, которые совершают многие пользователи LinkedIN при создании профиля и поясняем, как повысить эффективность профиля за счет их исправления.

Последнее время только ленивый не хайпанул на теме ChatGPT. Все, как один, бросились к ИИ решать все свои проблемы, от бытовых и философских вопросов до серьезных задач вроде “найди мне работу” или “помоги релоцироваться”.

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

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

Прокрастинацию принято считать разновидностью лени и ерундой, а эффективным лекарством от нее грозный окрик: «Соберись, тряпка!» На деле прокрастинация — опасная проблема, сродни зависимости, которая вызывает много вины и стыда, и способна со временем разрушить личность. Почему она так опасна, редко лечится попыткой «взять себя в руки» и как ее одолеть?

Какие качества отличают хорошего технического лида? Уверены, как минимум инициативность, стратегическое видение, интерес к новым практикам и инструментам, идущие рука об руку с желанием постоянно развиваться. Немалую роль в lifelong learning техлида могут сыграть правильно подобранные книги.

Немет, Луц, Лав, Танненбаум, Страуструп, Олифер, Лукас — вот лишь некоторые известные авторы, о которых мы сегодня не будем говорить. Надеемся, что раз вы стали лидером технической команды, то с фундаментальной литературой в своей области знаний знакомы не понаслышке.

Под катом рекомендуем 7 изданий о soft-skills, методологиях, управлении командами и проектами.

Привет, Хабр! Меня зовут Денис Захаров. Я занимаюсь разработкой веб приложений на протяжении уже 14 лет, но история будет не об этом. Расскажу о том, как и почему я создавал эргономичное рабочее место, которое в последствии превратилось в проект Easyworkstation. Эта штука уже несколько лет полностью заменяет мне и еще нескольким десяткам пользователей привычное компьютерное кресло и рабочий стол.

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

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

Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?

Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?

Тогда вам сюда:

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

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

Начнем с бэкенда.

Доброго времени суток, коллеги!
Меня зовут Роман и эксперт отдела анализа защищенности (в простонародье — пентестер). До того, как перейти в это направление, я 10 лет был системным администратором (преимущественно Windows систем). Скажу вам честно, мне очень нравится симбиоз такого опыта. На мой взгляд, человеку, который знает внутреннюю кухню администрирования, разработки или их сочетаний, будет легче и интереснее смотреть на инфраструктуру с точки зрения атакующего.

В процессе работы меня постоянно посещают флешбеки с вопросом «А как у меня было настроено?». И сегодня хочу поговорить о таком компоненте инфраструктуры, как Wi-Fi. По долгу службы я часто тестирую данный элемент в разных организациях и скажу вам, что если бы можно было дать совет по Wi-Fi себе, как админу, я бы этим непременно воспользовался.

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

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

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

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

Но действительно ли всё это надо? Разработчик в самом деле обязан проводить всё своё свободное время за написанием кода? А обязан ли разработчик постоянно развиваться?

В какой-то момент времени я превратился в педанта брюзгу. В фильмах малейшие нестыковки и провалы в логике портят мне весь просмотр. В чатах меня бесит it's вместо its. А в статьях про программирование... Всё плохо. За меня всё уже сказал @AlexanderAstafiev, я лишь процитирую:

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

Самое забавное, что, по моим ощущениям, везде я вижу одни и те же классы проблем. Я даже запилил сервис, где можно закинуть код и получить код ревью, и, собрав немного статистики, понял, что 50 типов ошибок достаточно, чтобы покрыть большую часть проблем в чужом коде. Но выборка у меня была небольшая, и я подумал: а что, если проверить много кода?

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

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

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

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

Приступим!)

За последние 10 лет я поменял 3 работы, прособеседовался с 10+ компаний на позицию разработчика (software engineer) и вел переписку с HR/рекрутерами из нескольких десятков фирм. По ходу дела заметил, что вопросы, которые я задаю на собеседовании с менеджером/командой или с HR, повторяются, и решил их структурировать. Некоторые из них являются общими, и их может задать кандидат на почти любую вакансию; другие касаются только вакансий для программистов. В этой статье поделюсь с вами наиболее типичными и важными вопросами, которые, на мой взгляд, может задать соискатель потенциальному работодателю.

На первом интервью чаще всего рекрутер может задать вопрос о зарплатных ожиданиях кандидата — “What Are Your Salary Expectations?”. Я принимаю участие в найме продукт-менеджеров, дизайнеров и инженеров и хочу поделиться с вами своим опытом как правильно отвечать на этот вопрос применительно к рынку США.

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

По приезду в Ереван я порвался на кучу маленьких Игорей от вывесок, меню, табличек и прочих инфоносителей. Мозг отказывался воспринять "S" как "Т" и совершенно не видел разницы между Ե и Է.

Букварь я себе, конечно, нашёл, но лень — штука непробиваемая.

Задача сформулировалась: "как бы так выучить алфавит, чтобы его не учить". Звучит оптимистично, люблю такое.

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