anetto1502

anetto1502

Канал про разработку на python и не только https://t.me/+0JMEYBjpMDJiYTMy
На Пикабу
Дата рождения: 29 августа
14К рейтинг 107 подписчиков 148 подписок 65 постов 25 в горячем
Награды:
За участие в Авторской неделе5 лет на Пикабу

7 красных линий (The Expert)

У крутых маркетологов есть принцип "спрашивайте клиента о проблеме, а не о решении". Покупателю нужно повесить картину — это его проблема. Можно предложить миллион решений, но, скорее всего, покупатель придёт в магазин за конкретным инструментом, который, как он предполагает, решит его проблему. Популяризовал подобную концепцию Котлер в своей книге "Маркетинг от А до Я": Не продавайте функции. Продавайте пользу, результаты и ценность. О проблемах, возникающих при попытке следовать решению клиента — в известном видео "7 красных линий". Начинается видео так:


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

Для желающих — оригинал на английском.


Интернет не был бы интернетом, не найди он решение. D. Scott Williamson, Expert предложил такое. Оригинал тут.

На просторах интернета также можно найти такое решение:

7 красных линий (The Expert)

Знать проблему клиента важно, чтобы предложить подходящее решение.


В телеграмм-канале DevFM разбираем разные нюансы из жизни разработчика на Python и не только. Все посты за сентябрь можно посмотреть тут. По пятницам говорим о культурном коде и прочих развлечениях.

Показать полностью 1 1
37

Stackoverflow developer survey 2022, часть 2. Специализации, технологии, IDE

Продолжаем ковырять stackoverflow developer survey. Начнём с области деятельности (developer type). Интересно узнать, как много представителей тех или иных специализаций.

Удивительно много full-stack developer. Разработчиков настольных приложений больше, чем мобильных разрабов. В области devops трудятся 10%, отбирая хлеб у старых добрых сисадминов с их 8%. Облачной инфраструктурой заняты 9%.

При этом не разработкой единой. Полно специалистов в совершенно разных областях. Интересно, что преподавателей (Educator) только 3.5%. Столько же SRE (Site Reliability Engineering), занимающихся обеспечением надёжности функционирования сайта. У гугла есть книга про SRE. Нередко devops и SRE смешивают. Отзовитесь, у кого есть SRE и DevOps, кто чем занят?


Тестировщиков только 5%. Надеюсь, это следствие разработки тестов сразу с кодом со стороны разработчиков. Юниттесты наше всё.

Отдельно 2% ребят про blockchain.

В прошлом посте я на основе TIOBE показывал динамику популярности разных ЯП, но выводам мешает субъективность любого рейтинга. В опросе же вопрос сформулирован "на каком языке вы интенсивно разрабатывали в последние годы и на каком хотите работать в следующие годы?". Посмотрим отдельно действующих разработчиков: в лидерах привычные JS, python, Java, C#. Удивительно высока доля bash наравне с C# и почти с Java.

А вот среди студентов (категория learning to code) есть интересные тенденции. Во-первых, 58% python (против 44% у действующих разработчиков). Тенденцию мы видим и вокруг себя, многие любят python в качестве первого языка программирования. Я считаю, что у этого подхода куча минусов, и как-нибудь соберусь поделиться своими мыслями на этот счёт. Во-вторых, среди студентов только 38% SQL против 53% у разработчиков. Думаю, без знания SQL разработчику, в целом, не очень комфортно. Интересно, что доля PHP составляет 19% у студентов и 21% у разработчиков. Это противоречит динамике рейтинга TIOBE. В-третьих, крутой Go с 12% у разработчиков занял только 5% в умах студентов (даже не влезло в картинку ниже).

Дальше смотрим на базы данных у профессиональных разработчиков. PostgreSQL на почётном первом месте. При этом топ-4 базы являются реляционными. Учите SQL, господа студенты, это полезный навык. Что интересно: если mongoDB 28% у разработчиков и 31% у студентов (скрин не стал вставлять), то elasticsearch 14% у разработчиков и 1.5% у студентов. То есть elasticsearch не учат.

С точки зрения облачных платформ ситуация такая. AWS в лидерах, дальше ряд крупных игроков. При этом по затраченным на облако финансам, насколько я помню, AWS крупнее остальных топ-5 игроков вместе взятых. Или уже нет?

Популярность веб-фреймворков среди разработчиков. Интересно сравнение со студентами. Резко потерял популярность angular (23% у разрабов против 10% у студентов), схожая ситуация у ASP.NET Core (21% у разрабов против 10% у студентов). Набирает популярность Django (14% у разрабов против 21% у студентов). Радует заметная популярность FastAPI с его 6%.

Интересная ситуация с other tools у разработчиков. Сюда зачем-то включили менеджеры пакетов (npm, yarn, homebrew) и фреймворки для игр (unity и unreal engine). Если их убрать, то 70% docker + 25% kubernetes. Можно сделать вывод, что без докера в современной разработке серверных приложений никуда. Среди студентов, кстати, доля docker только 31%. Надо подтягиваться, господа.

Используемые IDE разработчиками такие. С большим отрывом лидирует VSCode. Интересна доля notepad++. Совсем удивительна доля vim 24% + 6% neovim. Это больше, чем IntelliJ. Ура фанатам vim :)


В целом, не очень репрезентативные данные. Сравниваются IDE общего назначения и специализированные по языку. Условный PyCharm для python, IntelliJ для Java, а VSCode для всего. Отсюда и перекосы. Видны умирающие мастодонты типа NetBeans с 5%. Ладно, не видны, не влез он на скрин.

Для совместной работы в лидерах Jira.

Для коммуникации slack, teams, zoom. Не знаю, почему телеграмма нет.

Интересно, что среди разработчиков аномально высокая доля linux. Удивительную долю занимает SWL.

Вот такая вторая часть обзора. Надеюсь, вам понравилось.


В телеграмм-канале DevFM разбираем разные нюансы из жизни разработчика на Python и не только. Все посты за сентябрь можно посмотреть тут.

Показать полностью 12
24

Stackoverflow developer survey 2022, часть 1. Как учатся разрабатывать и что с возрастом по индустрии

В 2022 году в stackoverflow developer survey участвовало более 70к человек из 180 стран. Из-за большого числа участников получаются репрезентативные данные — какие технологии в трендах, куда в целом индустрия плывёт. Во многих опросах в качестве ответа можно выбрать несколько вариантов, поэтому сумма больше 100%. Для тех, кто не видел результаты опроса, я планирую показать отдельные кусочки в серии постов с моими (да кому они нужны) комментариями.


Как вы научились программировать? Среди ответов лидируют онлайн-ресурсы.

Интереснее посмотреть срезы по возрасту. Все данные можно посмотреть тут. Среди лиц до 18 популярность онлайн-площадок 85%, и книг 37%. С увеличением возраста доля онлайн-площадок падает, а книг растёт.

Для самой многочисленной категории 25-34 (их 40%, ниже будет) заметны 21% "учусь у коллег" против 3% у предыдущей категории. Вот почему считается важным работать в сильном коллективе. Обмен опытом часто продуктивен в обе стороны.

Для сравнения, в категории 45-54 лет доля книг 85%. Грустная тенденция, с моей точки зрения книги часто дают более целостное представление о технологии. С грустью узнал, что тот же Изучаем Python Лутца многие не хотят читать из-за объёма.

Любопытно, что под online resources подразумевается и техническая документация. Доля how-to videos аж 60%. Люди любят видео контент, хотя это самый медленных путь потребления технической информации. Можно смотреть на ускорении типа 1.25-1.5, но я вот на большей скорости не воспринимаю. Кто может смотреть на х2, признавайтесь?

Среди образовательных площадок за рубежом лидирует Udemy. Мне больше нравится Coursera со второго места. Среди отечественных вариантов знаю популярный stepik. Кто-нибудь видел свежий обзор отечественных образовательных площадок?

Общий опыт разработки (включая обучения) показывает такое распределение. У 16% респондентов свыше 20 лет опыта. Но костяк индустрии составляют миддлы с опытом 5-9 лет (минус года 4 на образование, то есть 1-5 лет)

Собственно, так мы и видим в разрезе "сколько лет разрабатываете профессионально".

Важно при этом, кто людей 35+ в программировании много. Можно не переживать о будущем разработчика, они и в годах востребованы. Есть подозрение, что с годами средний возраст разработчика продолжит расти.

Кстати, суровая гендерная правда — 92% мужчин. Нужно больше девушек!

В следующий раз обсудим технологии.


В телеграмм-канале DevFM разбираем разные нюансы из жизни разработчика на Python и не только. Все посты за сентябрь можно посмотреть тут.

Показать полностью 10
22

Ответ на пост «Flask на практике или сам себе злобный буратино»1

Концептуально, начинать стоит с мануала по выбранной технологии. Для flask это документация.


После изучения мануала есть два подхода:

1. Брать идею конкретного сайта и реализовывать её. Берём и делаем "свой вконтакте". Лучше замахиваться на что-то относительно небольшое, типа "сделать поиск песен как вот тут". Годится для разработчиков с опытом, которые самостоятельно могут выбрать решения.

2. Брать идею с открытой реализацией, чтобы было куда подсмотреть. Пытаемся реализовать самостоятельно, в случае проблем - смотрим код исходного приложения. Куда лучше подходит для начинающего, так как всегда есть источник подсказок. Частым проектом является список задач (туду-лист) ввиду простоты с одной стороны и потенциальной бесконечной расширяемости с другой.


Потом ищем свежие решения. Смотрим в поиск в гугле, хабре и на пикабу, в последнем сразу получаем Как я свой первый учебный Fullstack-проект писал. Можно запустить решение товарища, а потом пойти в сторону самостоятельной реализации backend-части, взяв его готовый фронт. Это возможно благодаря разделению приложения на две части — фронт отдельно, бэк отдельно.


Можно поискать на github и найти проекты вроде DailyNotes. При отборе проекта обращайте внимание на его размер — чем меньше, тем лучше для первого проекта.


Для оценки размера проекта могу порекомендовать cloc. Запускается через докер. Клонируете целевой проект <project> и выполняете

docker run --rm -v $PWD:/tmp aldanial/cloc <project>

В результате получаете такую картину (ссылка на ТГ-источник)

Ответ на пост «Flask на практике или сам себе злобный буратино»

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


В процессе обязательно использовать git и github/gitlab. Для понимания git рекомендую читать книгу Pro Git. В части gitlab могу порекомендовать своё видео на этот счёт, где за час показывается процесс создания небольшого проекта.


Кстати, не flask-ом единым. Можно посмотреть обзор веб-фреймворков 2021 года на tproger (django, flask, aiohttp, FastAPI, falcon, bottle), или свежее сравнение Django vs FastAPI на meduim. Если смотреть текущее состояние рынка на hh.ru, то вакансий с упоминанием django 720, flask 360 и FastAPI 323. Конкретно FastAPI модный, стильный, молодёжный. Правда, по этой причине сообщество пока не большое и материалов немного. С другой стороны, официальная дока FastAPI хороша и переведена на русский.


В телеграмм-канале DevFM разбираем разные нюансы из жизни разработчика на Python и не только. Все посты за сентябрь можно посмотреть тут.

Показать полностью 1
15

Стандарт де факто — git. Давно ли?

Stackoverflow с 2011 года проводит масштабные опросы разработчиков. В 2022 году в stackoverflow developer survey участвовало более 70к человек из 180 стран. Из-за большого числа участников получаются репрезентативные данные — какие технологии в трендах, куда в целом индустрия плывёт.


Сейчас лидер среди систем контроля версий (СКВ) де-факто Git со своими 97% среди профессиональных разработчиков. Можно выбирать несколько, поэтому сумма больше 100%.

Если переключиться на ответы начинающих разработчиков (скрин ниже), то SVN с 6% падает до 1.5%. Значит, через 3-5 лет в индустрию придут новые разработчики, которые не знакомы с SVN. Кстати, если вы не пользуетесь СКВ, то вы либо в 1.38% профессиональных разработчиков, либо среди 17% новичков. Учите git, любите git.

Ну, и меркуриал почти умер.

А зачем знать тренды? Чтобы не тратить время на умирающий инструмент. Например, какую систему контроля версий посоветовать начинающему разработчику. Вики насчитывает более 30 СКВ. И git был с нами не всегда.


Нашёл для вас опрос 2008 года, где лидер Subversion, скрин ниже. К сожалению, ни числа опрашиваемых, ни процентов у каждой из систем не указано. Тем не менее, git тут и не пахнет, а до настоящего времени дожили №1 SVN и №3 TFVC (они себя сейчас так называют).

В 2014 году на хабре был опрос по СКВ. Результат на скрине ниже — 71% был за git, 32% за SVN, 16% за mercurial, 8% за TFVC от Microsoft.

Так вот git пришёл, запушил, победил. Не исключено, что во многом из-за популярности github.


В телеграмм-канале DevFM разбираем разные нюансы из жизни разработчика на Python и не только. Стримы по программированию, что такое WSGI, миграция БД без даунтайма, чему стоит научиться в вузе, обман нейронных сетей. По пятницам у нас культурный код с фильмами, книгами и всяким разным.

Показать полностью 3
186

Ответ на пост «ИТ Пузырь»2

Прочитал пост и 200+ комментов, которые на сейчас есть. Вроде никто не указан на важное — реально выросла потребность в разработчиках. Это одна из причин драйва зарплат — конкуренция работодателя за кадры, т.к. предложение меньше спроса.


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


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


Условно, middle python разработчик решил пойти преподавать. У него года два или три займёт получить опыт преподавателя, и, возможно, он станет хорошим преподавателем. Но он уже на 2-3 года устарел по технологиям. Да, изменилось не всё. У нас всё ещё семиуровневая модель в интернете. Но всё поменялось вокруг.


И зарплаты у преподавателей такие себе. Например, возьмём топ технических вузов. Пусть будет №13 по рейтингу — МИРЭА. Смотрим их зарплаты — старший преподаватель до 30 лет будет получать 127к в месяц. Это 110к на руки. А после 31 года уменьшится стимулирующая надбавка за молодость и зп упадёт до 107к (93к на руки). Вспомним рейтинг зарплат с хабра за 1 полугодие 2022 года? Медианная зарплата разработчика в Москве 180к.


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


Большой спрос на ИТ-специалистов пытаются закрыть платные курсы. Типа вместо полезной математики и кучи бесполезного типа философии в институте мы даём только профильное, поэтому и в срок до года можно уложиться. Но, к сожалению, высокая цена не является гарантией качества. Более того, посмотрите вакансии спецов, которых набирают на курсы для code review или преподавания. Там опять зарплаты ниже, чем у разработчиков. Что в результате? В среднем мы имеем либо совсем инфоцыганские курсы, либо дорогие курсы со средним материалом. Я сейчас про курс "с нуля до middle", с ними основные проблемы. Есть исключения. Например, есть небольшие курсы по отдельным технологиям, которые вполне могут быть оправданы.


Институты и хорошие курсы (платные или бесплатные) держатся на тех активистах, которые и разработку продолжают, и хотят делиться знаниями. Если знаете таких активистов, скажите им спасибо :)


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


А ещё растёт потребность в управленческих должностях (team lead и прочие ребята). С их подготовкой вообще ужас — им нужен опыт управления людьми. А где его взять? Как создать условия, чтобы после института/курса на выходе был team lead с реальным опытом руководства несколькими командами? Переквалификация разработчиков в team lead имеет кучу неприятных побочных эффектов. Разработчик привык управлять послушным компьютером, а тут непослушные и недетерминированные люди. Ужас.


Даже область HR стагнирует. Они совсем не умеют подбирать кадры.


А собеседования разработчиков — вообще ужас. На них спрашивают то, что не нужно в работе. Создана отдельная индустрия натаскивания на собеседования. Готовиться к собесам — зло. Насколько я понимаю, это исключительно ИТ-специфика. Вы слышали истории, чтобы хирург готовился к собесу? Или пилот? Воспитатель в детском саду? В отдельных профессиях есть сертификация, конечно. Но это немного другое.


Излил я вам свою боль о современном состоянии подготовки новых кадров в разработке. Есть ли у вас идеи, как ситуацию починить?


Что сделал я для исправления ситуации? В телеграмм-канале devfm разбираем разные нюансы из жизни разработчика на Python и не только. Стримы по программированию, что такое WSGI, как спроектировать сервис, чему стоит научиться в вузе. По пятницам у нас культурный код с фильмами, книгами и всяким разным.

Показать полностью
323

ООП сейчас не все используют

Случайно наткнулся на такой комментарий

ООП сейчас не все используют

И прямо полыхнуло.


Где в трёх принципах ООП (наследование, инкапсуляция, полиморфизм) есть что-то про сеттеры, геттеры и деструкторы?


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


Сейчас в трёх китах ООП логика такая:

1. инкапсуляция — это объединение данных (называемых полями или атрибутами) и функций для работы с ними (называемых методами),

2. наследование — возможность породить класс из существующего, взяв себе все поля и методы,

3. полиморфизм — это возможность взаимозаменять объекты в рамках иерархии.


Давайте на примере. У нас собака - это сложная такая штука. Но всю сложность на себя берёт программист, который реализовал класс Собака. У нас есть поля (например, количество лап), есть методы (например, бежать). Вы можете сказать собака.бежать(), при этом внутреннее устройство собаки вас не интересует - в этом смысл инкапсуляции. Некоторые ошибочно говорят про "сокрытие" и начинают про private-public-protected, но этого не требуется. Поэтому, например, в python нет сокрытия, а инкапсуляция всё ещё есть.


Дальше. Мы создали Собаку. Теперь хотим Чихуахуа. Чтобы не переписывать общие места, у нас есть наследование. Мы создаём Чихуахуа(Собака), то есть наследуемся от неё. Теперь мы можем переписать только отличающиеся места (например, изменить метод Бежать так, чтобы Чихуахуа ещё противно шкрябала когтями).


И третье - полиморфизм. Это когда мы можем сделать много собак, и для каждой собаки вызвать метод собака.бежать(). В зависимости от типа собаки (Собака или Чихуахуа) у нас будет вызван нужный метод бежать. То есть на питоне


# создадим пару очаровательных собак
dog_party = [ Dog(), Сhihuahua() ]
# пройдёмся циклом по всем собакам
for dog in dog_party:
.  # у каждой собаки вызовем свой метод бежать
dog.run()
И тогда все собаки из dog_party побегут как умеют. Такие дела.


PS: некоторые относят к китам ООП ещё и абстракцию "для выделения в моделируемом предмете важного для решения конкретной задачи по предмету" (вики). Тут у меня вопрос. Вообще всё программирование состоит в выделении важного и игнорировании неважного независимо от парадигмы. Причём тут ООП? А если мы говорим о выделении сущности собаки в виде полей, то это свойство называется инкапсуляция.


В телеграмм-канале devfm разбираем разные нюансы из жизни разработчика на Python и не только — python, bash, linux, тесты, командную разработку.

Показать полностью
79

Вопрос на собеседовании python junior developer — вывод списка

Наткнулся на github на список вопросов к собеседованию python разработчика. Заинтересовал вопрос про вывод списка, ответ на который морально устарел.

Что выведет такой код?

В первую очередь это вопрос на внимательность. Но есть и о чём порассуждать.
1. Сразу начнём с PEP8. Называть переменную List нельзя, такой формат именования используется для классов.

class List():
.  pass  # точка в начале - иначе пикабу не даёт выставить табуляцию

2. Заметна опечатка — создался List, срез делается по list. Но тут начинается интересное. Эта версия кода в python3.6 вызовет ошибку TypeError: 'type' object is not subscriptable.

Связано это с тем, что list — ключевое слово для создания списка в формате list(). Но без круглых скобок list — это сам класс list, а не экземпляр. У самого класса список не определена операция получения элемента по номеру (subscription).


С обновлением системы указания типов в 3.9 питоне, выражение вида list[10:] рассматривается интерпретатором как список диапазонов или list[slice(10, None, None)] и выдавать ошибку уже не будет.

3. Если код был бы такой
list_a = []
print(list_b[10:])

То мы получили бы ошибку NameError: name 'list_' is not defined независимо от версии питона.

Итого исходный код приведёт к:

— TypeError, если мы использовали ключевое слово list в python3.6

— list[slice(10, None, None) для python3.9

— NameError, если мы использовали несуществующее название переменной.


И такой код вообще не должен пройти code review.


В телеграмм-канале devfm разбираем разные нюансы из жизни разработчика на Python и не только — python, bash, linux, тесты, командную разработку.

Показать полностью 2
Отличная работа, все прочитано!