Об ИТ из Канады

Блог Михаила Флёнова - программист, блогер, автор нескольких скандальных книг какими-то глазами...

Последние комментарии

Михаил Фленов

Собираюсь переходить

2017-06-22 06:06:39 - Перейти к заметке

Сергей

Почему не 2017? Его неплохо оптимизировали.

2017-06-22 01:33:44 - Перейти к заметке

Михаил Фленов

Простая PS4

2017-06-21 19:35:47 - Перейти к заметке

Radekk

Черный мак крутой конечно, но уже насчитали энтузиасты примерную цену, и она будет как у подержанного Golf GTI(~15000 долларов). Кто такой комп на работу себе возьмет, для меня, например, большаааая загадка.

2017-06-21 09:49:58 - Перейти к заметке

Radekk

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

2017-06-21 09:47:11 - Перейти к заметке

Dmitry Romanenko

Одно дело речь идёт о трёх переменных, а что если есть сложная структура разбитая на сотни таблиц, с минимум сотней переменных в ней? Мапить просто присвоение в одном месте ладно, а что если проект не двухминутный и у тебя минимум 20 ендпоинтов? А ведь тебе нужно не только строки присваивать, но и работать хэшмапами, списками из классов и многое другое.
Увы, но я бы сказал все зависит от сложности проекта. Иногда автомаппер это именно та вещь, которая тебя спасает.

2017-06-16 09:21:03 - Перейти к заметке

Синьор с Троещины

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

Автомаппер чаще всего юзаем в вебАпи проектах. Особенно помогает при использовании с шаблоном DTO.

2017-06-16 04:35:24 - Перейти к заметке

MrDxdy

Игра прЕстолов.

2017-06-16 04:23:22 - Перейти к заметке

Илья

Считаю автомаппер не нужным делом. Не вижу реальных сфер применения.

2017-06-16 03:33:14 - Перейти к заметке

Ololo

А как не маппить объекты? В базе нормализированная модель, одна бизнес сущность можеть быть разбита на кучу таблиц по правилам нормализации/реляционной теории. В слое бизнес логики надо работать с бизнес (Domain) моделями. На фронт энде в 75-90% случае бизнес модель подойдёт, но иногда это не удобно или в разных местах надо немного другая модель, тут уже View (DTO) модели помогают. На счёт маппинга я использую или AutoMapper, или удобный способ с помощью расширяющих методов в C# что-то вроде ".ToMyDomainModel(), .ToMyViewModel(), .ToMyEntityModel()", это помогает просто вынести маппинг в отдельное место на захламляя код, маппинги часто бывают большими и когда в коде который реализует какую-то задачу его захламляет маппинг я этого не люблю, особенно в слое репозитория всё время куча маппингов с Entity моделей в Domain при выборке из базы и наоборот из Domain в Entity при сохранении в базу. С Dapper подход немного другой, он маппит сам.

2017-06-16 03:09:35 - Перейти к заметке

severvam

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

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

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

2017-06-16 02:04:16 - Перейти к заметке

DiDimus

Насколько мне известно, число циклов заряда относится к полному циклу, т.е. заряд от 0 до 100% - есть полный цикл.
То есть, если аккумулятор заряжен на 50% и его начать заряжать до конца, то это будет половина цикла заряда, и от гипотетического значения в 20 оставшихся зарядок останется 19,5. Если заряжен на 25% - цикл будет равен 0,75 и т.п.

2017-06-14 07:32:49 - Перейти к заметке

Сергей

Ставь BolgenOS и не парься.

2017-06-12 16:35:42 - Перейти к заметке

MasDen

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

2017-06-12 11:26:30 - Перейти к заметке

Влад

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

2017-06-12 09:01:59 - Перейти к заметке

Леонид

Эх, эт самое трудное - жить в 2 стороны

2017-06-12 07:13:43 - Перейти к заметке

Ololo

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

2017-06-12 06:27:09 - Перейти к заметке

Михаил Фленов

Ко мне родители не хотят, переезжать.

2017-06-12 06:07:11 - Перейти к заметке

Леонид

Эт понятно, а родители не хотят к тебе переехать?

2017-06-12 03:47:29 - Перейти к заметке

SergeyS

Рекомендую попробовать Pine64, стоит примерно столько же, только производительность на высоте и никаких торомозов

2017-06-11 23:53:22 - Перейти к заметке

О блоге

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

Внимание!

А ты уже читал мою последнюю книгу о больших сайтах и приложениях? Узнай, что это такое здесь

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

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

Пишите мне