Давно не писал не сюда - работа и личный проект не давали передышки. Но вот появилась минутка - а с ней и желание написать. ## И сегодня я напишу про "велосипедостроение" Начнем с теории. Две основные крайности в этом вопросе обозначают как: 1. Not invented here (изобретено не нами) - ситуация, при которой любое новшество отклоняется, так как было создано вне конкретной компании или команды. 2. Proudly found elsewhere (с городостью найдено в другом месте) - ситуация, когда любая внешняя разработка считается предпочтительнее внутренней, просто потому, что она внешняя. Если закрытые совковые организации явно тяготеют к "изобретено не нами", то стильные, модные и молодежные IT компании обычно находятся с другой стороны забора и посмеиваются над "созданием велосипедов". Но ведь оба пути - это крайность. В обоих случаях вы принимаете идеологически догмы в качестве простого ответа на сложный вопрос. Но так как современное коллективное бессознательное IT сообщества создается компаниями с западным мышлением, то доминирующая крайность - "не создай себе велосипед". И как вы уже поняли - я с этой позицией не согласен.

Ссылки ну другие части: - [Что я узнал, сделав интернет-магазин. Часть 1 - разработка и дизайн](http://80levelelf.com/Post?postId=26). - Что я узнал, сделав интернет-магазин. Часть 2 - продажи и продвижение. Напомню, что посмотреть готовый результат можно [здесь](http://ros-inst.ru/).

Ссылки ну другие части: - Что я узнал, сделав интернет-магазин. Часть 1 - разработка и дизайн. - [Что я узнал, сделав интернет-магазин. Часть 2 - продажи и продвижение](http://80levelelf.com/Post?postId=27). На голову мне свалилась одна проблема - надо для семейных нужд сделать интернет-магазин. Желательно быстро, недорого, качественно и чтобы продажи шли. Кому сразу интересен результат - [Российский Инструмент](http://ros-inst.ru/).

Скажите, часто ли у вас возникала такая ситуация: - Какая-то часто используемая сущность хранится в таблице (_какой сюрприз!_) - Меняется это сущность из многих и многих мест. Например, в одном месте мы обновляем название компании, в другом - её рейтинг, в третьем - название и адрес, в четвертом... Как делать такой слой хранения данных? Много маленьких методов? Как-то проверять данные на null? А если нам **реально** нужно изменить данные на null? - А еще бывают случаи, когда при сложной логике вы **заранее не знаете, что именно обновится**, а дергать миллион маленьких методов или как-то еще сильно смешивать слои логики и хранения данных не хочется. - А еще бывают микросервисы, которые по-хорошему должны относиться друг к другу как к **черному ящику**, который и упасть может. В таком случае вы получите наполовину обновленные данные.

####Ссылки на другие части: - [Развитие ИИ. Часть первая - что же (скорее всего) будет?](http://80levelelf.com/Post?postId=23) - Развитие ИИ. Часть вторая - почему мечты о раю для всех (скорее всего) окажутся ложью. Любите ли вы научную фантастику 20-го века? Азимова, Стругацких? Видели ли вы (хотя бы мельком) фильмы 20-го века, действие которых происходило в будущем? Летающие автомобили, смешные роботы из фольги, нарочито яркая и дурацкая одежда обитателей мнимого мира будущего?  Знаете, что объединяет все эти массовые произведения культуры о будущем? Они не о будущем, они лишь об *антураже будущего*. Будущее в этих фильмах лишь экстраполяция настоящего. Азимов в своем фантастическом мире (а он связал все свои произведения от Р. Д. Оливо до Основания в единую вселенную) создал позитронный мозг - мощный искусственный интеллект общего назначения. Этот интеллект в его книгах может направлять человека, помогать человеку, обслуживать человека, стараться быть человеком, но **никогда не пытается заменить человека**. Все открытия в мирах Азимова принадлежат человеку. Позитронный мозг в Основании оказался достаточно сильным, чтобы осознать движение человеческой цивилизации, но изменить направления этого движения довелось именно человеку (Гэри Селдону).

####Ссылки на другие части: - Развитие ИИ. Часть первая - что же (скорее всего) будет? - [Развитие ИИ. Часть вторая - почему мечты о раю для всех (скорее всего) окажутся ложью.](http://80levelelf.com/Post?postId=24) Не так давно наткнулся на одну интересную статью: [«Не миллионы людей потеряют работу — десятки миллионов»](https://vc.ru/29737-ne-milliony-lyudey-poteryayut-rabotu-desyatki-millionov#comment-570071). За пару дней до этого на еще более интересную (и самое главное - более основательно подготовленную): [Правдивая история роботизации, начинающаяся с одного простого графика](https://habrahabr.ru/company/parallels/blog/342360/). Аналогичных статей каждый из нас уже читал множество. Тема влияния ИИ на наше общество и экономику встала остро. Что же - и я внесу пять копеек.  

# Часть 2. Введение в IOC-контейнеры на примере Ninject. ####Ссылки на другие части: - [Первая часть: Теоретические основы Dependency Injection и IOC-контейнеров](http://80levelelf.com/Post?postId=20 "Первая часть: Теоретические основы Dependency Injection и IOC-контейнеров") - Вторая часть: Введение в IOC-контейнеры на примере Ninject И так, в прошлой части было рассмотрение идеи Dependency Injection и причин, по которым в «сыром виде» Dependency Injection не очень удобен для использования. И плавно повествование перешло к IOC-контейнерам. IOC-контейнер (Inversion of control) – это автоматизированная настраиваемая фабрика (factory), которая берет на себя всю «черновую работу». Для рассмотрения мы возьмем именно Ninject, хотя в общем-то это не самый лучший выбор. Он весьма удобный и легкий в использовании, [но очень медленный](http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison "Он весьма удобный и легкий в использовании, но очень медленный"). Так или иначе, Ninject стал де-факто стандартном .Net IOC-контейнеров, и не смотря на низкую скорость, является довольно распространенным. Тем не менее, все нижеизложенные принципы применимы и ко всем другим IOC-контейнерам (отличаться могут лишь названия каких-то методов или атрибутов).

# Часть 1. Теоретические основы Dependency Injection и IOC-контейнеров. ####Ссылки на другие части: - Первая часть: Теоретические основы Dependency Injection и IOC-контейнеров - [Вторая часть: Введение в IOC-контейнеры на примере Ninject] (http://80levelelf.com/Post?postId=22) Глава 1. Зачем нам нужен Dependency Injection? ---------------------------------------------- Наверное, это и есть самый главный вопрос, на который нужно ответить. Обычно в этом месте начинаются пространные рассуждения о том, что у нас есть класс Car и класс CarEngine и они слишком связанны между собой и … Это все, конечно, так, но на вопрос это не отвечает. Главный ответ на то, зачем нужен Dependency Injection (внедрение зависимостей) – это тестирование. Но он отнюдь не единственный. А теперь чуть поподробнее. В любом относительно большом программном продукте возникает потребность в логическом разделении частей. Вариантов и идеологий этого – огромное количество, но задача одна – сделать различные части системы максимально независимыми друг от друга по двум основным причинам: - Для того, чтобы упростить разработку системы (чтобы изменения в одной части не вели к большим переписываниям кода в других частях). - Для того, чтобы упростить автоматизированное тестирование (чтобы можно было взять максимально маленькие части системы и тестировать их максимально независимо, не превращая автоматизированное (юнит) тестирование в интеграционное тестирование).

Зашел сегодня на сайт с телефона (на котором нет AdBlock'a) и увидел интересную картину: фоток увы не сделал, но если в вкратце, то внизу как ни в чем не бывало висел баннер. Баннер, к которому отношения я не имею. Офигенно! – Подумал я. И начал смотреть как же он добавляется. И нашел: один из .cshtml файликов на хостинге был отредактирован и стал содержать вот такие вот строчки кода: <script data-cfasync='false' type='text/javascript' src='//p67136.clksite.com/adServe/banners?tid=67136_109560_1&type=slider&side=center&size=468x60&animate=on'></script> <script data-cfasync='false' type='text/javascript' src='//p67136.clksite.com/adServe/banners?tid=67136_423352_0&tagid=2'></script> Которые и делали что надо. Остался лишь один вопрос: как этот файлик был отредактирован. По-хорошему есть лишь два адекватных ответа: - Уязвимость в хостинге - Уязвимость в Asp.net MVC Почему я думаю, что вряд ли взломали именно мой код? Потому, что вряд ли кто-то будет тратить свое личное время на никому не известный маленький блог. Особо навара с баннеров на моем сайте не будет, так что предположу, что взлом был осуществлен автоматически. В итоге убрал вредоносный код. Буду следить за развитием событий.

Наверняка многие натыкались на переводы статей этого человека на vc.ru или Хабре, но сам Алекс прошел мимо вас - если это так, то постараюсь исправить это недоразумение. Если в кратце, то человек пишет про то, как он находит идеи для своих проектов, создает и монетезирует их. Ничего занудного, только цифры, рассуждения и результат. И вот его самые крутые статьи. __На английском:__ [Сам блог на Медиуме](https://medium.com/@moskovski) [Создание Postio](https://hackernoon.com/i-used-lamp-to-make-a-saas-with-3700-mo-profit-heres-how-1c47033900e9 ) [Создание Menu Maker](https://hackernoon.com/how-i-made-a-saas-webservice-earning-1000-monthly-profit-6d2b782b95c8 ) [Создание QuoteArtist](https://hackernoon.com/how-i-made-a-saas-webservice-earning-1000-monthly-profit-6d2b782b95c8 ) __Те же статьи на русском:__ [Создание Postio](https://habrahabr.ru/post/321978/) [Создание Menu Maker](https://habrahabr.ru/post/320292/) [Создание QuoteArtist](https://habrahabr.ru/post/338350/) Налетайте!