Backend-разработчик
Пока педагоги бьют в колокол, опасаясь, что ChatGPT порушит систему образования, они сами ломают её изнутри популярным нейромифом о доминирующем стиле обучения.
Опросник Высшей школы экономики показал: 80% преподавателей вузов верят, что студентов можно разделить на визуалов, аудиалов, вербалов и кинестетиков. Более широкое международное исследование говорит: 89,1% педагогов считают, что люди учатся лучше, когда получают информацию в «своём стиле обучения».
При выпуске нового релиза сборки её версию обычно меняют. Это особенно актуально, если разрабатывается библиотека, от которой зависят другие проекты. Но что, если этого не делать? Предлагаю вашему вниманию небольшую историю о проблемах с библиотеками от Microsoft.
Как вы наверняка знаете, LINQ (Language Integrated Query) - это очень мощный и гибкий язык, встроенный в C# и существует он начиная аж с .NET Framework 3.5. Однако, несмотря на свои возможности, синтаксис запросов часто игнорируется в пользу более популярного аналога - синтаксиса методов. Хотя синтаксис методов действительно мощный, в этой статье я на практических примерах покажу преимущества query-синтаксиса и его полезность для опытных разработчиков на C#.
Долгие годы люди стремились к всё более реалистичному изображению окружающих их вещей. Много лет прошло от симпатичных наскальных мамонтов до шедевров эпохи Ренессанса и Просвещения. Однако где-то в 19-м веке (примерно, когда стала появляться первая фототехника, ага), что-то пошло не так, и живопись сменила своё направление от реализма к абстракции. Дальше больше; и все "скатилось" до клякс, пятен и потёков, размазанных по холсту или любой другой поверхности стоимостью в миллионы долларов... И при этом зачастую совершенно было непонятно, кто автор "шедевра": 3-х летний ребенок, маститый художник, нейросеть или кот, опрокинувший банку варенья.
Похожие процессы происходят и в мире данных, синтетические, сгенерированные, абстрактные данные обретают всё большую ценность на рынке. Такие данные являются более безопасными, а также позволяют тестировать системы качественнее и воспроизводить проблемы до их появления в продакшене... А еще делать прогнозы, анализ, безопасно обмениваться и многое другое.
В этом посте мы рассмотрим основные моменты генерации данных с нуля (на основе схемы БД), а так же на основе уже существующих данных. Рассмотрим способы, методы, особенности и инструменты. А каждый шаг будем иллюстрировать примерами живых и настоящих SQL-запросов (в основном PostgreSQL-flavour, но постараемся и не только). И в итоге убедимся, что SQL позволяет нам не только эффективно работать с уже существующими данными (на минуточку, уже почти на протяжении 50 лет), но с помощью него их можно еще и довольно эффектно придумывать.
Да, тайтл кликбейтный, но тема алгебраических свойств integer'а и float'а, действительно, не часто освещается в литературе и интернетах, однако эти знания углубляют понимание реализации компьютерной арифметики и применимы на практике.
Толчком Мотивацией к написанию статьи послужил кейс, продемонстрировавший свойство целого типа, которое легко упустить из виду, но на практике приводящее к неожиданному поведению. Это ни разу не новое открытие в computer science, и под капотом все довольно просто, но сохраним интригу. Подойдем к этому свойству через реальную задачу, затем посмотрим на целочисленную арифметику с точки зрения теории групп и разложим все по полочкам. Если вы используете язык программирования с ограниченными целыми числами, то статья может оказаться полезной.
Веб платформа ASP.NET за последние десятилетия получила достаточно широкое распространение. С ее помощью разрабатывают веб-сайты и веб-приложения с помощью таких средств как HTML, CSS и JavaScript. Также с помощью ASP.NET можно создавать веб-API и веб сокеты.
Одной из основных проблем при разработке в контексте безопасности является невозможность функциональной проверки у того, или иного приложения. То есть, при разработке приложения мы не можем просто подключить какие-то библиотеки, сделать какие-то настройки при сборке проекта, и затем сказать, что все, наше приложение защищено и можно передавать его в продакшен. Так не бывает. На практике возможны два основных сценария: худший когда мы узнаем о проблемах с безопасностью нашего приложения из СМИ и интернета, например, когда приложение взломали или, когда в сеть утекли данные, обрабатываемые нашим приложением (да, обычно эти утечки организуют бывшие или действующие сотрудники, и это не совсем вина приложения, но, как говориться осадочек все-равно остается). Более мягким является сценарий, когда мы узнаем об уязвимостях в нашем приложении в результате пентеста или когда сознательные исследователи сами сообщают разработчикам о найденных уязвимостях, например в рамках баг баунти. В таком случае нас скорее всего еще не скомпрометировали и репутационного ущерба для компании разработчика не будет. Ну а срочные баг фиксы выпускают все.
И к чему было все это вступление? ASP.NET является достаточно сложным решением, а сложность это всегда враг безопасности. С одной стороны вроде-бы злоумышленнику трудно разобраться в сложном решении, но с другой и защищать сложное решение тоже весьма непросто. И практика показывает, что очень часто именно злоумышленники быстрее разбираются в сложных системах и оперативно находят уязвимые места.
Я много работаю с массивами, поэтому хотел бы освежить тему того, как наиболее быстро по нему перемещаться в C#. Речь пойдёт об экономии наносекунд и оптимизации на уровне IL-кода. Кажется, что в 99% случаев вам это знать не нужно и задумываться об этом не стоит. Тем не менее, для горячих сценариев или если вы из high-load или геймдева, вам это может пригодиться.
Сейчас 1:30 ночи, и я смотрю на фрагмент кода, который написал около месяца назад. В то время он казался мне произведением искусства. Все здесь имело смысл. Он был элегантен, прост и замечателен. Но больше нет. У меня завтра дедлайн, а я обнаружил баг всего несколько часов назад. То, что казалось простым и логичным в то время, сейчас просто не поддается моему пониманию. Конечно, если я написал этот код, мне ведь должно хватить мозгов, чтобы понять его?
Спустя слишком большое количество подобных ситуаций я начал серьезно задумываться о том, почему мой код предельно понятен, пока я его пишу, но выглядит как какая-то тарабарщина, когда я вновь возвращаюсь к нему через несколько недель или месяцев.
Примерно 11 месяцев назад я начал разрабатывать пет-проект - Telegram чат для сайта. С тех пор и до сегодняшнего дня занимаюсь его разработкой и продвижением самостоятельно. Правда занимаюсь им в свободное от основной работы время, которого мало.
Недавно проект перешагнул за 100 платящих пользователей в месяц и 100 000 рублей суммарной выручки (именно выручки, всё возвращается в проект, в карман ничего пока не положил). Вложения пока не отбились, но плавно к этому иду.
Хочу рассказать тем, кто тоже работает над своими проектами, как за год я пришел к текущим показателям (что было нелегко). Попробовал структурировать свои мысли, вышло довольного много текста. Текст разбил на статьи, содержание будет в каждой статье.
Хабр, привет!
Сегодня я предлагаю совершить небольшое исследование на тему "как нам обустроить интеграционное тестирование и встроить его в сиайку".
Написать эту заметку меня сподвигла дискуссия, случившаяся недавно на работе. Инициативная группа "четырехглазых в свитерах" пыталась родить меры по улучшению качества нашего изделия и снижения трудозатрат QA-инженеров на проведение рутинного регрессионного тестирования. Как это часто бывает, разработчики если и писали тесты, то только модульные, оставляя интеграционные и end-to-end для тестировщиков. Для выполнения интеграционного тестирования QA-инженеры используют "тестовый стенд", на котором развернуты компоненты приложения (еще около 40, с позволения сказать, "микросервисов"), сервер базы данных (с не всегда ясным наполнением этой самой базы), брокер сообщений (RabbitMQ) и все остальное, что может потребоваться для запуска приложения. На этот тестовый стенд натравливаются автотесты, которые шатают приложение за все доступные снаружи конечные точки, таблицы БД и элементы UI пытаясь проверить максимальное количество тестовых сценариев в границах (и за ними!) возможных входных данных.
Обзор кода - один и составляющих процессов поддержания качества программного обеспечения. В ходе него один или несколько человек изучают и оценивают программу в основном путем просмотра и чтения отдельных фрагментов его исходного кода.
Код Хабра день за днём впитывает в себя время, мысли и чаяния многих людей. Этому коду более 10 лет: он оброс множеством знаний, в том числе и тайных. Места c bus factor = 1 — не эка невидаль, а вполне конкретные люди с ответами на часто задаваемые вопросы.
Меня зовут Антон Каракулов, я тимлид команды бэкенд-разработки Хабра. Хабр стартовал в 2006 году, и за всё время здесь поработало, наверное, команд пять. Мне посчастливилось быть в двух из них, забегал в третью.
Эту статью я написал в рамках проекта Хабра «IT-гид», где разработчики рассказывают про свои направления. Постарался собрать в ней главные практические выводы и интересные грабли, которые нам попадались в процессе превращения старого хабракода в чистый, масштабируемый и понятный для всех — то есть человекочитаемый.
Все события утрированы, а совпадения — беспочвенны.
