Давно не писал не сюда - работа и личный проект не давали передышки. Но вот появилась минутка - а с ней и желание написать.
## И сегодня я напишу про "велосипедостроение"
Начнем с теории. Две основные крайности в этом вопросе обозначают как:
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/)
Налетайте!