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

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

Рассказано, чем последний слайд (выполненные задачи) должен отличаться от слайда с целью и задачами в начале работы. Даже про "спасибо за внимание" совершенно верно рассказано.

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

#sudo #edu

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

Существует много онлайн-площадок разного уровня подготовки. Часто топовый (самый свежий и проработанный) материал доступен только на английском языке - это следствие бОльшей аудитории, охватывающей весь мир. Поэтому наибольшие знания вы можете подчерпнуть из англоязычных курсов. Тем не менее, рынок русскоязычных курсов тоже немаленький, и вы можете углубить свои знания в любой профессиональной области.

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

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

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

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

#sudo #edu

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

#sudo #edu

Частая проблема разработки CLI - как бы заставить всё работать с минимумом кода со стороны разработчика. Парсить аргументы командной строки с помощью if - надеюсь, таким вы не занимаетесь. Для python одним из наиболее простых решений является click - простой способ с помощью декоратора превратить функцию в консольное приложение. Такой способ потом легко позволяет превратить наработки в веб-приложение заменой декораторов для click на роутинг-декораторы. Достойный обзор вариантов CLI-библиотек для питона тут
#python

Товарисчи! Именно сейчас у вас есть прекрасная возможность послушать Радио-Т в онлайне с пре и после шоу, которые не попадают в запись.

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

Упс! случайно запушил в репозиторий какой-нибудь пароль или что-то, что не должно там быть? не проблема. Нужно просто удалить этот файлик и сделать новый пуш, тогда все будет ок.
Если ничего не смущает, то настоятельно рекомендуется к прочтению.

И даже если подумали: что за бред написан выше?! Все равно рекомендуется прочесть статью, а также ознакомиться с главой из книги, чтобы лучше понимать и знать, как изнутри устроена повсеместно используемая технология.
#skills

Полезные примочки для гита.
#skills

В тему закоммитил не то, забыл что-то закоммитить, хочется поправить коммит мессадж. Оказывается об этом уже подумали и не нужно и извращаться.
#skills

Любая работа по программированию начинается с анализа предметной области. Рекомендуется пара этих ресурсов - для русского и английского поиска.

https://cyberleninka.ru

https://www.researchgate.net

https://scholar.google.com/

В начале ищутся самые популярные статьи, потом следует подкрутить фильтры и взять самые свежие (не старше 5 лет, не старше 3 лет). Большую часть усилий стоит сосредоточить на англоязычных источниках. Очень важно изучить существующие открытые проекты на гитхабе.

Видео можно искать так
https://research.google.com/youtube8m/explore.html

Интересные рассмотренные статьи необходимо заносить в список с небольшой аннотацией.Такой список позволит в большей степени понимать и ориентироваться в предметной области. Например,

1. <ссылка>. Работа на "хорошо". В работе есть данные по нейросети, которая с 80% точностью распознаёт человека в маске. Ссылка на программу есть, на датасет нет. Напрямую применить нельзя, но можно взять часть про нормализацию кадра

2. <ссылка>. Выглядела на "отлично", по факту бред. Литературы нет, написано на коленке

Пример:
1. https://cyberleninka.ru/article/n/mnogokriterialnaya-otsenka-kachestva-fotografiy/viewer В статье рассматриваются различные критерии качества изображений, а также их количественная оценка. Из полезного: оценка резкости изображения, что может быть полезно для выделения одного наиболее информативного кадра в потоке на заданном промежутке времени. Есть математические операции по подсчету, а также примеры использования OpenCV для получения количественных оценок

2. https://cyberleninka.ru/article/n/algoritmy-predobrabotki-izobrazheniy-v-sisteme-identifikatsii-lits-v-videopotoke/viewer В статье описывается алгоритмы предобработки изображений для их последующей обработки. Сюда входит
- Обесцвечивание
- Выравнивание гистограммы яркости изображения
- Выравнивание изображения относительно вертикальной оси симметрии лица (по возможности)
- Масштабирование

3. https://www.researchgate.net/publication/341892534_VIDEO_DATA_QUALITY_IMPROVEMENT_METHODS_AND_TOOLS_DEVELOPMENT_FOR_MOBILE_VISION_SYSTEMS В статье производится сравнение подходов однопоточной и многопоточной мобильной обработки видео, зависимость скорости обработки видео от его разрешения, а также приводятся примеры перехода из пространства RGB в YUV на OpenCV с целью оценки освещенности изображения

4. https://github.com/shubham0204/Age-Gender_Estimation_TF-Android Приложение под Android, определяющее пол и возраст человека на изображении. Прилагаются скриншоты результатов распознавания. Если с точностью определения пола все хорошо, то c определением возраста как-то не очень (числовые оценки не приводятся). Есть ссылки на датасет и блокноты в Colab, которые экспортируют модели TFLite (используется в приложении для Android). Из полезного можно вынести на мобилку модель для определения пола.

#sudo #edu #devfm

Паттерн декоратор часто применяется в разработке для динамического добавления или изменения функциональнеости объекта.
В питоне декораторы - встроенная фича языка. Даже не будучи погруженным в тему декораторов разработчики часто с ними сталкиваются - сделать метод статическим, объявить абстрактный метод, настроить роутинг в веб фреймворке.
Помимо встроенных декораторов возникает необходимость реализовать свой, например для какого-то хитрого измерения времени работы функции.
В серии из двух статей (раз, два) очень детально рассказывается о декораторах в питоне, объясняется, как написать свой декоратор. А главное после изучения материала использование встроенных декораторов в повседневной разработке не будет казаться какой-то магией.

#python

Автор в художественном стиле выплёскивает свою боль от входа в ИТ и сложности перехода от решения хорошо формализованных задач к решению неформализованных.

Хорошо показана разница между выполнением уже решённой задачи (как тренировка - лабораторная работа, выполняемая студентом), понятной задачей (формата практики - уже есть понимание результата или даже MVP, осталось реализовать) и непонятной задачей (формата курсовой или дипломной работы - когда надо понять, можно ли вообще это сделать, какие есть способы, попробовать и выбрать).

Собственно, аналогично можно иллюстрировать разницу между junior (могу писать код, скажите куда) и middle (могу решить задачу) разработчиками. Senior в этой линейке за счёт широкого кругозора умеет решить задачу эффективно или показать, что задачу решать вовсе не требуется.

PS: в комментариях многократно подчёркивают важность навыка "чтение чужого кода". Писать все могут, ты попробуй прочитать...

#edu

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

PS: Кстати, недавно вышла статья, как стать senior-разработчиком на курсах по программированию

#procode

Давно Джоел Спольски рассказал о "законе дырявых абстракций". В современном мире, чтобы починить проблему, часто надо уметь работать на уровень ниже текущего уровня абстракции. Проблема может быть с compose, docker, конкретной библиотекой, python, операционной системой, сетью, железом... Чем больше абстракций вы знаете, тем больше вероятность, что вы сможете решить проблему следующего уровня.

Нельзя в один момент освоить десяток нужных инструментов и абстракций. Нужно плавно расширять используемый инструментарий. Освоили git? Ни строчки кода далее без него. Научились тестам? В каждом проекте их нужно писать с самого начала. Теперь Docker в копилке? Применяем, если это уместно. Чем больше опыта в разных технологиях, тем вы сильнее как специалист
#edu

Задумывались ли вы, как работает ценообразование? Почему Microsoft Windows 10 домашняя стоит 200$, pro версия 289$, а pro for workstations уже 439$? В статье Джоела Спольски Верблюды и резиновые уточки поэтапно рассказано, как производитель может извлекать выгоду из различного подхода к покупателям не только в сфере программного обеспечения, но и в других бизнес-вопросах.

Да-да, это тот же Джоел. У него много достойных статей на разные темы. Часть статей объединены в книги - "Джоел о программировании", "Джоел. И снова о программировании". Рекомендую

PS: а про баланс спроса и предложения неплохо написано на пикабу
#edu

Пятничное развлекательное.

Один из самых известных скетчей на тему постановки задачи неспециалистом – 7 красных линий, в оригинале The Expert.

PS: а решение задачи существует
PPS: современное образование - вообще проблема

#fun #edu #sudo

В любой сфере деятельности встаёт вопрос об измерении результата. Для линейного персонала иногда можно внедрить простую метрику (KPI), например, число закрученных рабочим гаек на заводе. Даже в этом случае сразу есть проблемы. А если гайка закручена не до конца? А если гайка поцарапана и некрасиво выглядит? Решить можно внедрением ограничений - например, учитывать только принятые на приёмке гайки. И, если закрученные гайки являются основным продуктом, то KPI работает хорошо. Но как быть с работниками более творческих профессий?

Всё ломает эмпирический Закон Гудхарта с формулировкой "что измеряешь – то и получаешь".

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

В этом случае любые метрики могут выступать только косвенным индикатором проблемы. Программисту нужно думать, что вообще измерить затруднительно. А по производительности разработчики различаются в десятки раз, о чём напомнили в статье 10x developer.

#edu

Продолжаем разбирать вопрос разработчиков с десятикратной производительностью – 10х-разработчиков.

В статье говорится, что основной драйвер на пути становления 10х-разработчиком – это эффективность.
— задавайте вопросы
— избегайте отвлечения (cколько времени вы тратите на соцсети и игры? Попробуйте измерить в часах в неделю. "Пока вы спите, враг качается")
— используйте инструменты для ускорения (особенно хоткеи и CLI)
— учитесь. Читайте. Слушайте подкасты. Смотрите туториалы и проходите обучающие курсы. Я тоже всегда так советую, но тут надёжнее – совет случайного человека из интернета
— найдите ментора
— помогайте остальным

PS: в первом же комменте автору подсказали, как стать 11х-разработчиком, превратив его 4 строки CLI и одну короткую
git stash branch new_feature

#edu