Данная статья представляет собой свободный перевод раздела "Исследования" из доклада State of the Art 2022 (октябрь). Доклад State of the Art публикуется уже пятый год. Это подборка самых интересных вещей в мире AI, (конечно с точки зрения авторов). Отчет включает в себя несколько блоков:

Привет! Меня зовут Максим Кульгин, я основатель xmldatafeed.com и clickfraud.ru. Мы занимаемся парсингом сайтов и защитой от скликивания, и не оставляем надежду выйти на глобальные рынки. Т. к. у нас своего опыта еще нет, я ищу интересные, откровенные статьи с сторонним опытом, которые перевожу для себя и теперь хочу поделиться с вами.

Прошлая статья, где переводил авторский опыт получения 35 000 скачиваний приложения по миру за ~50$ была относительно неплохо воспринята сообществом, поэтому решил продолжать. Да и самому интересно читать…

В этот раз меня «зацепила» статья, где автор (довольно опытный, судя по его постам и комментариям) делится своим опытом в виде ~77 советов (в оригинальной статье было ровно 100 пунктов, но часть я удалил, т.к. они мне показались крайне странными — к нашей действительности не применимы). Изначально я подумал, что эта статья а-ля «капитан очевидность», но когда вчитался — очень понравилось, т. к. это полностью отражает и наш небольшой опыт запуска ИТ- проектов в РФ. Посчитал, что будет полезно перевести.

Я позволил себе делать перевод «вольный» с своими комментариями, дополнениями и уточнениями (где-то расшифровал термины, где-то детализировал идею автора, адаптировал к Российской действительности и т. п.) . Больше информации вы можете найти на телеграм- канале «Русский ИТ бизнес» — в нем пишу всё, с чем сталкиваемся в процессе работы, без приукрашивания.

Дальше рассказ пойдет от первого лица автора с моими комментариями в скобках курсивом… Оригинал статьи на английском языке доступен здесь (вам потребуется VPN для чтения).

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

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

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

Когда-то поспособствовало расширению лично моих представлений:

Одна московская знакомая росла в Нью-Йорке в 70-х: её отец был советским специалистом в ООН. Смотрят как-то юмористическую передачу на американском TV: она, подросток, ухохатывается — отец ничего не понимает, хотя прошёл какие-то немыслимые тесты и языком владел отлично.

С тех пор её работа так или иначе связана с английским. В бюро переводов, где мы познакомились, она была редактором — искала ошибки в уже сделанных переводах. Помимо прочего, она читала английскую классику в оригинале, и я был уверен, что разговаривает как по-русски. А потом услышал её беседу с англичанином и был в шоке. Её речь оказалась до чрезвычайности скудной: почти никаких устойчивых фраз или идиом — она просто передавала мысль так, чтобы её поняли (в статье «О навыке говорения» я это называю первым уровнем развития речи).

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

Вполне толковая русская девушка прожила в Англии замужем за англичанином больше 10 лет. Англоязычный ребёнок, у ребёнка игрушечный динозаврик. При мне она сделала 2 (две) ошибки в произношении слова dinosaur. Слово очень распространённое.

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

Взрослые носители действительно порой не знают довольно распространённых английских слов. А два моих знакомых американца 59 лет, бывшие одноклассники, оба не знали, что у глагола swim есть 3-я форма swum.

Всем привет! Меня зовут Кирилл, я старший разработчик в группе «Полигоны и ограничения доставки» в Ozon. Cегодня я расскажу про фаззинг, встроенный в Go: что это такое, зачем он нужен в разработке программного обеспечения и как с его помощью найти баг в дикой природе open-source-коде (рассмотрим на примере).

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

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

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

Но и рассказывать про то, как браузер загружает страницы, тоже не будем. HTTP-запросы, сжатие, языки программирования, рендеринг страниц – всё мимо.

Что нам интересно, так это то, как данные находят путь от одного компьютера до другого.

С 2013 года я работаю в IT и прошла путь от Account manager до Senior Product manager в таких компаниях как МегаЛабс (Мегафон), Билайн, X5 Retail Group. С 2017 года я начала собирать свои команды в роли PO (до этого работала под руководством других PM или PO) и все это время я изучала, что же входит в широкий термин «Управление командой». Проходила множество обучений на эту тему, наблюдала за коллегами и их опытом работы, слушала доклады PO на проф. мероприятиях и читала статьи на тему. И все это интересовало меня, так как была цель дать максимум пользы крутым специалистам, с которыми мне повезло работать в одной команде.

В этой статье я не буду рассказывать о распределении рабочей загрузки или описывать тактики управления командой. Информации (разного качества) на эту тему предостаточно. Я расскажу о своем опыте, с точки зрения «чего делать НЕ нужно». Каждый пункт, который я опишу, был найден моим лбом в виде граблей из самых лучших побуждений. Если опыт моих провалов окажется полезным для вас, буду очень рада.

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

Когда нужно делить фронтенд-часть приложения на микросервисы? Какой стек использовать? И какие стандарты использовать, чтобы не выстрелить себе же в ногу при переходе на микрофронты? Михаил Трифонов (Lead Frontend в компании Cloud) ранее уже выступал с докладами о микросервисах, получил фидбек от сообщества и с его учётом сделал новый доклад на HolyJS. А теперь мы (организаторы HolyJS) сделали для Хабра текстовую версию этого выступления.

Странно было бы делать доклад про микросервисы монолитным. Поэтому каждая глава этого поста является изолированным, слабо связанным кусочком. Так что можете читать по отдельности, а можете — целиком.

Привет! На связи СберМаркет Tech. Эту подборку книг составили инженерные менеджеры СберМаркета и ведущие подкаста «Для tech и этих» Олег Федоткин, Никита Елагин, Семён Мацепура и Вячеслав Артемьев. Сейчас в подчинении у ребят суммарно более 200 инженеров. Мы попросили их поделиться книгами, которые в своё время помогли им вырасти из разработчиков в управленцев. Эти книги не только про лидерство, но и про найм, стратегическое мышление и коммуникации. Они будут полезны тем, кто уже управляет командой или идёт к такой цели. Поехали!

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

И одновременно перфекционист — это ругательство. Это человек, который устроит истерику, пока логотип на сайте не передвинут на 1 пиксель. Как человек, страдавший от перфекционизма, расскажу, когда он несет благо, а когда зло, и как превратить дурной перфекционизм в полезный.

Всем привет, меня зовут Антон, я iOS-разработчик платформенной команды в inDrive. В августе прошлого года исполнилось 10 лет с момента, как я начал работать программистом. За это время успел поработать в больших компаниях и в стартапах, в продуктовой команде и в аутсорсе, в геймдеве и в мобильной разработке. Сейчас я решил подытожить полученный опыт и сформулировать его в виде советов начинающим разработчикам. 

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

Одной из революционных особенностей Go в сравнении с другими компилируемыми языками стало автоматическое управление освобождением памяти от неиспользуемых объектов (сборка мусора). В то же время она может привести к потере производительности при передаче контроля процессу управления памятью, но альтернативного механизма в Go представлено не было. Начиная с Go 1.20 появляется поддержка экспериментального решения для управления памятью, которое позволяет совместить безопасное выделение динамической памяти и уменьшить влияние интегрированного в скомпилированный код управления памятью на производительность приложения. В этой статье мы рассмотрим основные аспекты использования Memory Arena в Go 1.20.

Привет! Меня зовут Виталий, я фронтенд-тимлид в KTS. Рассказываю, что входит в нашей компании в обязанности тимлида, а что — нет.  Спойлер: это не расставление задач в таск-трекере.

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

Мы выстроили свою схему разделения обязанностей между тимлидами, менеджерами и аналитиками. Она позволяет снять с тимлидов менеджерскую работу, для которой не нужно обладать глубокими техническими знаниями, но нужно часто переключаться между разными задачами и сотрудниками. Это даёт возможность тимлидам работать над теми задачами, которые и отличают их от менеджеров, — с технической частью проекта. Рассказываем, как мы реализовали эту схему для компании из 80 сотрудников.