Я уверен, где-то существует книга «Как подсидеть тимлида». Она передается из рук в руки, из команды в команду и содержит советы типа: «Тимлид никогда не уволится по своей воле, потому что это не работа, а сказка! Его нужно сломать», или «Если ваш тимлид уехал в отпуск, напишите ему, что вам нужно поговорить, когда он вернется. Пусть вместо серфинга думает, что в его отсутствие команда разбежалась», а еще «Саботируйте попытки тимлида внедрить новые полезные рабочие процессы фразой из Agile-манифеста о том, что люди и взаимодействие важнее процессов и инструментов». Иначе просто невозможно объяснить, почему все тимлиды сталкиваются с одними и теми же проблемами и страхами.

Я, Егор Толстой, опросил более 400 тимлидов, чтобы провести деконструкцию некоторых из страхов тимлидов. Результаты опроса и исследование рынка тимлидов помогло понять, как с ними справиться, и я хочу поделиться результатами. Простые лайфхаки помогут меньше страдать от синдрома самозванца не только тимлидам, но и вообще любым специалистам, которые еще недавно выполняли конкретные задачи, а теперь руководят командой исполнителей.

Привет, Хаброжители! Все, что вам действительно нужно знать о машинном обучении, может уместиться на паре сотен страниц.

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

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

В .Net Core есть встроенный механизм Model Binding, позволяющий не просто принимать входные параметры в контроллерах, а получать сразу объекты с заполненными полями. Это позволяет встроить в такой объект все нужные проверки с помощью Model Validation.

Вот только данные, нужные для работы API, приходят нам не только из Query или Body. Какие-то данные нужно получить из Headers (в моем случае там был json в base64), какие-то — из внешних сервисов или ActionRoute, если вы используете REST. Для получения данных оттуда можно использовать свой Binding. Правда и тут есть проблема: если вы решили не нарушать инкапсуляцию и инициализировать модель через конструктор, то придется пошаманить.

Для себя и для будущих поколений я решил написать что-то вроде инструкции по использованию Binding и шаманство с ним.

Эффективность – красивое слово. Удобно вставлять его в фразы типа: "я работаю максимально эффективно", "нужно найти эффективное решение", "повышаем эффективность процессов", "наша цель – эффективный код", "Вася – эффективный менеджер". Но что конкретно при этом мы имеем в виду?

У слова "эффективный" есть два значения:

1. дающий эффект, действенный, позволяющий достичь желаемого результата, далее в тексте – результативный
2. оптимальный, позволяющий достичь желаемого результата с минимальными затратами, наименьшими нежелательными эффектами/ошибками, рентабельный, организованный, с высоким КПД, далее в тексте – производительный

В английском языке – это два разных слова: effective и efficient.

• Being effective is about doing the right things, while being efficient is about doing things right.

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

Кроме огромных репозиториев с источниками для подготовки к интервью, здесь много чего интересного

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

А я его перевел, т.к. показалось, что пост многим будет интересен. Перевод очень вольный: я опустил нерелевантные промо-ссылки и гипер эмоциональные похвалы автора оригинала, чтобы оставить только суть. Еще, обновил цифры, чтобы информация была более актуальной к моменту публикации этого перевода. Итак, перейдем к списку.

Вечная конкуренция

Для многих из нас уже давно не секрет, что найти заказчика на проект краткосрочный или долгосрочный на ресурсах интернета — это очень непростая задача. В основном, потому что очень большая конкуренция: от тебя хотят максимум работы за минимум денег. И когда ты откликаешься на ту или иную задачу — ты просто становишься в длинную очередь из кандидатов. На вкус они разумеется в большинстве своём не очень, что очевидно из постов многих работодателей/рекрутёров, которые пишут статьи здесь же, на Habr. Однако, я уверен, что каждый из нас оценивает себя более-менее объективно, и если не воображает из себя гуру всего и вся, то хотя бы как минимум заслуживает уважения, ведь уважения заслуживает каждый человек — без исключения. Но рынок фриланса перенасыщен донельзя. У каждого наёмщика на один проект по 10 кандидатов в день.

Интересно, а как именно думает рекрутёр?

Где-то недавно тут была статья, о том, что наёмщик считает адекватными только 2-3 человек из 100 кандидатов, прошедших интервью, и что хороший кандидат — это человек, который верит в ваш продукт, верит в вас, и в макаронного монстра, и в биткоин по 300к$. Иными словами, идеальный наёмный сотрудник — это просто бессознательное существо, которое должно почему то верить в чужое дело (а оно по факту чужое, т.к. это не его собственность, а работодателя, и он знает его всего 2 часа), верить в вас, и свято верить в «Наше» правое дело, великолепно кодить и строить архитектуру, а деньги тут играют далеко не главную роль.

Очень удобная позиция, не правда ли? Я хочу найти senior/team-lead разработчика, который будет с пеной у рта писать проект с рвением, отдавая всего себя, и не просить за это хороших денег. То, что вы только что прочитали — это демонстрация полного неуважения работодателя к будущему сотруднику. Хорошая качественная и компетентная работа должна оплачиваться сполна.

Эта статья написана как ответ на статью «Собеседование в Додо Пиццу» со стороны разработчика с опытом синьора. Я не претендую на истинность суждений, мне хотелось бы выразить довольно популярное среди моих знакомых мнение о процессе найма в частности и жизни разработчика в целом.

Занимательная история о том, как выгорание владельца смогло прикончить вполне перспективную ИТ-компанию.

Финляндия — это Нокия, сауны, хоккей, лыжи, тяжёлый металл, Angry Birds. И ещё самые счастливые люди на планете на 2018 по WHR (это, скорее, экономические показатели, чем желание радостно смотреть ковёр всё время).

Краткая история: сначала была просто земля с местными народами, потом территория вошла в состав Швеции надолго, в 1809 году перешла в состав Российской Империи (но получила нехилую независимость, даже собственная марка ходила), а сразу после прихода большевиков ко власти стала отдельной страной с разрешения Ленина. То есть жители некогда части Империи пропустили весь сюжет с девяностыми и с СССР. Точнее, видели часть его в перекрестье снайперского прицела во время войн 39-44 годов.

У нас опять пятничный урбанизм, и я хочу рассказать про город Хельсинки. Главное ощущение города — прилив окситоцина. Это гормон, который, среди прочего, отвечает за долговременную любовь мужчины к женщине, родителя к ребёнку и человека к собаке. Выражается он в физическом ощущении счастья в виде спокойствия и безопасности. В Хельсинки хватает и того, и другого.

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

INTRO

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

Я увлекаюсь безопасностью, поэтому решил из интереса проверить безопасность фишингового ресурса.

"Админку" мошенников удалось успешно взломать, внутри нашлось n-количество украденных учеток. Их логины были переданы в службу безопасности VK, плюс соответствующие "abuse" жалобы были направлены регистраторам, хостерам.

А теперь расскажу как и какие оказываются бывают Phishing-as-Service панели...

Существует не так много туториалов по созданию roguelike в Unity, поэтому я решил написать его. Не с целью похвастаться, а для того, чтобы поделиться знаниями с теми, кто находится на том этапе, на котором я был уже довольно давно.

Примечание: я не утверждаю, что это единственный способ создания roguelike в Unity. Он просто один из. Вероятно, не самый лучший и эффективный, я учился путём проб и ошибок. А некоторые вещи я буду изучать прямо в процессе создания туториала.

Будем считать, что вы знаете по крайней мере основы Unity, например, как создать префаб или скрипт, и тому подобное. Не ждите, что я буду учить вас, как создавать спрайтшиты, об этом есть множество прекрасных туториалов. Я буду делать упор не на изучение движка, а на то, как реализовать игру, которую мы будем создавать вместе. Если у вас возникнут трудности, то зайдите в одно из потрясающих сообществ в Discord и просите о помощи:

Unity Developer Community

Roguelikes

Итак, давайте приступим!

Этап 0 — планирование

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

Мы будем писать roguelike. В основном мы будем слушаться мудрых советов разработчика Cogmind Джоша Ге, приведённых здесь. Сходите по ссылке, прочитайте пост или посмотрите видео, а потом возвращайтесь.

Какова же цель этого туториала? Получить крепкую простую базовую roguelike, с которой потом можно будет экспериментировать. В ней должна быть генерация подземелий, движущийся по карте игрок, туман видимости, враги и предметы. Только самое необходимое. Итак, игрок должен иметь возможность спускаться вниз по лестницам на несколько этажей. допустим, на пять, повышать свой уровень, совершенствоваться, а в конце сражаться с боссом и побеждать его. Или умирать. Вот, собственно, и всё.

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

Меня зовут Паша и я web-разработчик, который успешно релоцировался в Польшу г. Варшава на работу, но перед тем, как это сделал, проанализировал очень много других вариантов и вывел своего рода аспекты и правила как принять правильное решение при выборе компании для работы за границей без привязки к какой либо конкретной стране.

---

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

На то есть определенные причины, для компании в Европе намного легче нанять сотрудника из России чем для компании в США.

В связи с этим очень много неизвестных компаний из Европы предлагает работу.
Такие сайты как linkedin.com буквально пестрят предложениями о работе в Польше, Латвии, Эстонии и других близко расположенных странах. Растет количество компаний и независимых HR-фрилансеров, которые помогают с релокацией и всячески популяризируют эту тему.

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

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

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

В октябре прошлого года я летал в Сибирь на TEDx Novosibirsk и в самолёте внезапно оказался рядом с другим спикером – Павлом Буковым. Он психотерапевт и собирался сделать доклад про профессиональное выгорание: как бы выгорать пореже и не дотла. Я, естественно, вспомнил, как год назад выгорел сам. Заодно вспомнил, сколько людей набивается в зал, когда на технологических конференция докладчик рассказывает про выгорание. В общем, пока мы летели в Сибирь, я записал с Павлом эпизод подкаста про стресс и выгорание и решил собрать из него статью.

Binary heartbeat by Kevin Tong

Надо признать, я не умею выбирать подарки. Но люблю научную фантастику (надеюсь, эти два факта не связаны). Как насчет придумать подарки на 8 марта не для настоящих, а для книжных героинь? Заодно вспомнив, какие фантастические романы отличаются сильными и яркими женскими персонажами.

Звучит как безобидная забава, но не забываем — некоторые из этих девушек легко могут убить за неудачный выбор подарка.

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

В этой статье я поделюсь рекомендациями по составлению «холодного» письма о вакансии. Под «холодным» я подразумеваю письмо с описанием вакансии специалисту, с которым мы незнакомы.

В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.

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

Так вот, не будет.

Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.

Обычная ситуация, что разработчик первой версии системы уже десять лет как умер или уехал, а системы ядра, запущенные в старом гипервизоре внутри нового гипервизора (чтобы обеспечить совместимость) ещё в проде.

То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных.

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

Как были устроены U-образные, плоские и «треугольные» патроны? Почему некоторые, казалось бы, очевидные инженерные решения не удается внедрить более полувека? Ответы на эти вопросы, фотографии и чертежи некогда секретных военных разработок — под катом.

Мы живем в неидеальном мире. Здесь код пишут люди, а люди по своей природе склонны совершать ошибки. Все бы ничего, ошибки можно отловить на этапе тестирования и не дать им никому навредить. Можно, если писать тесты. Чего люди делать почему-то не любят. Но возможно, есть надежда — автогенерация тестов из написанного кода.

Юлия Волкова хочет проверить идею в реальности и пробует переложить на машину создание тестов на основе кода, причем без использования дополнительных инструкций или контрактов. О том, какие открытия приносит путешествие в мир метапрограммирования, AST, синтаксического анализа и токенизации, и чего это все позволило добиться в автогенерации тестов, Юлия расскажет на Moscow Python Conf++. А пока я расспросил, откуда появилась сама идея — автоматизировать тестирование, что лежит в основе прототипа и с чем еще предстоит справиться.

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