Не всегда так и немного не так, но в целом есть такое дело. Если что — можно понять в рантайме какие были дженерик параметры в особых случаях. Создавать дженерики в рантайме нельзя.
Ну как минимум в это время еще не вышел новый XC90. S-класс тоже обновился в 13м году и его тестов нет в NHTSA. Так что этот перс-релиз явно устарел.
Ну и сам он довольно спорный (http://www.roadandtrack.com/go/news/government-politics/nhtsa-says-the-model-s-isnt-the-safest-car-ever-tested)
Во первых мы говорим о Северном Кипре или Греческой части? С реалиями севера я не очень хорошо знаком. На юге, наколько я знаю, все отсалось практически так-же. Из интернета CYTA + PrimeTel (в Лимасоле еще есть ребята которые тянут кабели — но это только город). Жилье — от 400 евро за студию. 2 бедрума от 550. Жить без машины даже в Лимасоле проблематично(добратся до Карфура или Лидла тяжело), не говоря о деревнях. На счет Никосии не знаю — но что-то подсказывает что там еще хуже. По автобусам — в самом Лимасоле все более-менне ок, но если есть желание жить в деревне (что гораздо интереснее имхо) то автобус ходящий 2 раза в день навивает мысли о покупке машины.
С самими машинами попроще конечно — можно было взять средней убитости японку за 2,5 — 3 к евро. 3х летний хечбек из японии стоит порядка 8-9к евро.
Бензин тоже не очень дешевый. Ну и + немилосердные счета за электричество (100 — 250 евро за два месяца) и если есть отопление в дома — то и за него тоже.
Еда — как я помню от 4,5 евро за кебаб до 10 евро за обед в какой — нибудь Коламбии.
Или все уже не так?
Кипр — дорогие перелеты, практически обязательно брать машину в аренду (публичны транспорт практически не работает), не дешевое жилье. Хреновый и дорогой интернет. На самом деле адоватое место для жизни фрилансера.
Если что — у самого есть опыт жизни на Кипре (2,5 года)
Вы пытаетесь писать на функциональном языке как на императивном — используя наиболее низкоуровневые концепции языка. Имхо — это стандартная ошибка новичков. Если так хочется сделать все через список (а не ввести свой тип данных на котором эти операции будут действительно работать оптимально), то лучше использовать высокоуровневые примитивы типа fold для этих задач. Там как минимум будет оптимизация tail call будет. Вообще написание своих собственных рекурсивных функций на стандартные типы данных — это антипаттерн для функциональных языков.
Да кстати стандартный pop (вытаскивание элемента из стека или очереди) вполне решается вот такой функцией:
let pop stk =
match stk with
|[] -> (None, [])
|hd :: tail -> (Some(hd), tail)
Если задача критична — нанимают прямо команду, или создают ее внутри платя огромные деньги консультантам на время становления команды.
Тот-же Збертех когда организовывался — выкупал нужные комманды чуть-ли не целиком.
У всех компаний которые указанны в списке ОГРОМНОЕ количество проектов. И судя по моему опыту (работы в Дойче Банке) эти проекты делятся на 2 кучки — бизнес критикал и все остальное. Все остальное спокойно идет на аутсорс. Бизнес — критикал всегда остается внутри компании. Как правило — все самые интересные проекты — бизнес критикал.
Я когда пишу на C++ обычно пишу интерфейс класса в header, и наследуюсь от этого описания в файле реализации (ну и +статический метод create который создает соответствующий объект). Получается немного сложнее но при этом более логично (для меня) и так-же безопасно. Тут конечно могут возникнуть проблемы с производительностью из-за виртуальных методов, но по факту это очень редко является узким местом. Ну и в реализуемые методы становятся чище. Конструкция типа children_.do_something() для меня куда более интуитивно понятна чем data_.children_.do_something()
MEF — это готовая библиотека для написания плагинов к приложениям, которая позволяет отлично делает service discovery, dynamic library loading и прочие не очень тривиальные штуки, для которых раньше надо было изобретать свои велосипеды. Вместе с Autofac — делает встраивание плагинов в ваше приложение совсем прозрачным и требующим минисального количества усилий.
Использовать его как основной DI фреймворк имхо — не разумно, хотя лично видел и такие решения. Причем они неплохо работали.
И? У тебя есть локальная копия на твоей машине, идешь в bitbucket, google code или поднимаешь свой gitolite на Amazon и все. Смена github на другой сторадж технически — 3 комманды в консоли. Где тут зависимость?
Про iTunes и музыку — глупости. То что пока нельзя завещать свой iTunes аккаунт другому человеку — правда, но вам ничего не мешает скопировать всю свою библиотеку. И drm там тоже нет.
Обычно нельзя сказать «Тут проблема дизайна — ничего делать не буду, я работаю только с идеальными решениями. И вообще — давайте все перепишем с нуля!» :)
По моей практике как раз такой подход и приводит к переписыванию с нуля :)
Заложить время на рефакторинг в следующей фиче, которая будет касаться этого класса — имхо более правильный подход, чем аа с этим классом все равно уже ничего не сделать — так пусть маячит тут куском кода на 400-500 строк.
Нет такого состояния. Все зависимости внедряются вызовами конструкторов полей по умолчанию. Т.е. к началу выполнения тела любого конструктора (и тем более нестатического метода) все будет инициализировано.
Вот тут вы меня убедили. Опасного состояния действительно нет. Тогда остается лишь вопрос сментики.
Но представьте, что будет, если зависимостей хотя бы штук 5, а конструкторов несколько.
Это наталкивает меня на мысль что класс отвечает за слишком много вещей и неплохо бы его разбить на несколько. Это проблема дизайна и хороший DI фреймворк обычно должен о ней подсказывать.
Кроме того, на мой взгляд, логически правильнее отделять зависимости от параметров конструирования.
Очень странная мысль. Как можно отделить конструирование объекта от его зависимостей? Это значит что у нас точно есть состояние когда объект недособран? Как это состояние отлавливать? Вставлять кучу проверок на null? Мне этот подход кажется очень странным. Как минимум это убирание проверок с момента компиляции в рантайм. Тут начинаем терять часть прелестей статической типизации. Вкупе с моделью памяти в C++, где неинециализированный указатель это не null — есть реальная возможность словить кучу сложно-уловимых ошибок.
В спринг и в ее входит гораздо больший набор технологий.
Ну и сам он довольно спорный (http://www.roadandtrack.com/go/news/government-politics/nhtsa-says-the-model-s-isnt-the-safest-car-ever-tested)
С самими машинами попроще конечно — можно было взять средней убитости японку за 2,5 — 3 к евро. 3х летний хечбек из японии стоит порядка 8-9к евро.
Бензин тоже не очень дешевый. Ну и + немилосердные счета за электричество (100 — 250 евро за два месяца) и если есть отопление в дома — то и за него тоже.
Еда — как я помню от 4,5 евро за кебаб до 10 евро за обед в какой — нибудь Коламбии.
Или все уже не так?
Если что — у самого есть опыт жизни на Кипре (2,5 года)
Да кстати стандартный pop (вытаскивание элемента из стека или очереди) вполне решается вот такой функцией:
и использовать ее можно вот так:
Тот-же Збертех когда организовывался — выкупал нужные комманды чуть-ли не целиком.
Эээ — atomic?
Вобще с 99го года очень много воды утекло.
children_.do_something()для меня куда более интуитивно понятна чемdata_.children_.do_something()Использовать его как основной DI фреймворк имхо — не разумно, хотя лично видел и такие решения. Причем они неплохо работали.
По моей практике как раз такой подход и приводит к переписыванию с нуля :)
Заложить время на рефакторинг в следующей фиче, которая будет касаться этого класса — имхо более правильный подход, чем аа с этим классом все равно уже ничего не сделать — так пусть маячит тут куском кода на 400-500 строк.
Вот тут вы меня убедили. Опасного состояния действительно нет. Тогда остается лишь вопрос сментики.
Это наталкивает меня на мысль что класс отвечает за слишком много вещей и неплохо бы его разбить на несколько. Это проблема дизайна и хороший DI фреймворк обычно должен о ней подсказывать.
Очень странная мысль. Как можно отделить конструирование объекта от его зависимостей? Это значит что у нас точно есть состояние когда объект недособран? Как это состояние отлавливать? Вставлять кучу проверок на null? Мне этот подход кажется очень странным. Как минимум это убирание проверок с момента компиляции в рантайм. Тут начинаем терять часть прелестей статической типизации. Вкупе с моделью памяти в C++, где неинециализированный указатель это не null — есть реальная возможность словить кучу сложно-уловимых ошибок.
Конструктор гораздо лучше подходит для данной задачи. Плюс строгие проверки на момент компиляции (особенно если использовать ссылки)