Блог

Календарь
Заметки за 2018

Почему я до сих пор не использую Linq к базам данных

В этом видео показатель, почему я до сих пор не использую Linq. На 4:26 показана интересная конструкция, которую Linq сгенерировал на простую просьбу найти записи, которые начинаются с определенного слова. Такая задача решается очень просто, достаточно просто LIKE 'СЛОВО%', но Linq зачем-то добавил еще какую-то проверку на длину совпадения. Вот этого я не совсем понял, зачем такое нужно. 

Боязнь индексов – это паранойя

Мне тут довелось общаться со специалистом по базам данных MS SQL Server и из разговора вышло, что он противник индексов. По его мнению, индексы – это практически зло, потому что они замедляют вставку и обновление данных. 

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

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

А что ты делаешь с исключительными ситуациями?

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

Хрен с ним, начали искать конечно же это заняло не более 10 минут. Код выглядит вот так:

Поиск решения для Swift 3

Swift 3 так сильно изменился по сравнению с первой версией, что это стало проблемой при поиске возможного решения простых проблем. Когда гуглишь какое-то решение, то в первых рядах вылетают ответы для более старых Swift и приходится постоянно фильтровать - это работает только в Swift 2, это только в Swift 1 и т.д. Пока найдешь самое свежее решение, хочется вернуться на .NET. 

Если Swift первого пришествия был простым и гибким, то сейчас далеко не все так выглядит. То, что некоторые методы упростили и теперь имена выглядят короткими и понятными - это круто. Но количество символов ! и ? очень сильно увеличилось. После открытия старого проекта на Swift 1 я добавил столько этих восклицательных знаков, что в них можно было утонуть. 

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

Микросервисы

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

Когда-то давно появилась технология сервисов и многие говорили, что это круто и именно так нужно строить свои сайты. Я не увидел тогда необходимости использования SOAP внутри проекта. Для взаимодействия между вендоровами и различными системами - да, я использовал сервисы. В очень редких случаях я использовал их и для внутренних нужд, но не так часто. 

С появлением подхода микросервисов я вынужден согласится с теми, кто их продвигает, что микросервисы - это правильно реализованные сервисы.

Тормоза компиляции Xcode

Мне понадобилось тут освежить одно из своих приложений для iOS, которое я писал на Swift и количество изменений в язык заставили меня потратить целый день на то, чтобы вручную адаптировать код. И это уже немного начинает бесить. Причем код теперь выглядит не так уж и красиво, как раньше. Большое количество ужесточений привели к более некрасивому результату. 

Пока я исправлял косяки, меня начала бесить более серьезная проблема - компиляция была невероятно медленной - как минимум минуту и постоянно шла какая-то индексация, которая не должна быть. Я уже перегрузил Xcode, собирался уже перезагрузить Mac (вообще для меня это очень редкая операция), но после фикса очередной ошибки типа: "операция слишком сложная, подумайте над тем, чтобы ее разбить на несколько", компиляция стала проходить практически мгновенно. 

Зоопарк технологий

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

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

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

Почему должен быть только один Assert?

Недавно смотрел видео, в котором специалист из MS рассказывал про юнит тесты, кажется я его смотрел на Channel 9. Так там затронули тему того, что рекомендуется, чтобы у каждого теста был только один Assert. Один тест - одна проверка. 

В видео специалист MS сказал, что он не совсем согласен с требованием, ограничивать тесты только одной проверкой, и считает, что их должно быть немного, но необходимо достаточное количество. 

Лично я не против большого количества проверок Assert и не понимаю, зачем их ограничивать. Вот сейчас я пишу тесты для системы, которая будет давать какие-то перки за определенные действия - клиент называет это Promotion Engine. Там клиент конфигурирует различные промоушены, потом загружаются данные, и движок на основе данных проверяет, должен ли я дать призы тем, кто хорошо играет в игры или нет. 

Тесты затормозили сайт

Я дома перешёл на Visual Studio 2015, хотя он немного более требователен к ресурсам. До этого я не использовал тесты MS, а тут вдруг решил перейти на них для своего последнего проекта. В общем создал проект для тестов, набросал кучу полезных вещей и заодно пока писал тесты нашёл несколько ошибок в своём коде. 

Вчера нужно было делать демо через gotomeeting, а у меня компьютер начал нереально тормозить, сайт не грузиться и даже sp_who2 в SQL Server не хочет выполнятся. Я перезапустил SQL Server и вроде бы помогло, сайт загрузил страницу. Но при попытке перейти куда-то дальше, все снова повисло. 

Не знаю зачем, но я что-то решил закрыть Visual Studio, наверно в голове пролетела мысль, что нужно освободить немного оперативной памяти. Как только я закрыл студию, сайт снова начал грузиться и я смог показать, что я натворил. 

Использование автомаперов

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

Преимущество использования автомаперов - не нужно писать код типа:

dst.Field1 = src.Field1

dst.Field2 = src.Field2

dst.Field3 = src.Field3

Все говорят пишите тесты, а ты пишешь тесты?

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

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

Нагрузочное тестирование

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

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

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

О блоге

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

Обратная связь

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

Пишите мне