А Вы обновляли прошивки (дакота 20)? Я точно не помню какая версия у меня сейчас, но был приятно удивлен, что одного комплекта хватало на 2-3 дня в велопоходе по горам Марокко. Помню что яркость выкручивал на минимум, смотрел на трек не часто (все же не самая дикая местность), выключал на стоянках/привалах.
Garmin Monterra — в США 650 долларов, в Голландии — 670 евро.
Все же обычный навигатор для «экстрималов» — Dakota 20 за 250 евро выглядит разумнее при том же времени работы и 2-х батарейках вместо 3-х. Пусть не такой отзывчивый, но для остального и телефон можно на сдачу купить.
> К примеру цикломатическая сложность метода не должна превышать 10, иначе нужно упростить или разбить его.
Есть такое исключение (например в соглашениях для кода ядра линукса), что чем проще метод, тем длиннее может быть его код. Например: if (...) {
...
} else if (...) {
...
}
...
else {
...
}
само собой цикломатическая сложность у данного метода растет очень быстро.
Аналогично при использовании Fluent Builders в ООП.
Вообще из своего опыта скажу что самые действенные способы для чистоты кода — четкие соглашения по стилю написания, парное программирование и постоянные ревью.
В статье, мало внимания уделено соглашениям, все же интереснее какие именно правила позволяют сделать код чище. Вот, например, для C#, частично как адаптированный конспект по Clean Code: csharpguidelines.codeplex.com/
в большинстве — да, согласен. но вот что касается мыши — то очень уж интересно выглядит, например, для презентации на большом экране перед аудиторией: пришел, подключил ноутбук к проектору, запустил. конечно, переключалку слайдов никто не отменял, но если показывать работу живого приложения — очень даже удобно.
Вот скажите при чем тут DAL? Именно эта часть обычно уже написана в другой библиотеке и просто используется (nHibernate, EF, RavenDB...). А то что имеет смысл абстрагировать, это уже бизнес сущности. В таком случае репозиторий имеет дело с бизнес объектами, которые представляют не только данные, но и поведение (где и появляется ООП). Вот на стороне бизнес модели и реализуется более специфичное поведение.
С подобным можно столкнуться когда доменная область строится через EventSource, где хранится не сам объект, а только набор событий. Тогда имеем: сохраненный объект (1+ событий), новый объект (0 событий) и несуществующий объект (0 событий). Вот тут и получаем что только отвечающий бизнес код должен знать где использовать Find, а где Get.
Все зависит от бизнес контекста и поведения, которое требуется.
В основном получение записи по идентификатору — та операция которая должна всегда возвращать сущность и при отсутствии таковой будет исключительная ситуация.
Другой же момент когда в бизнес логике явно предусматривается возможность что таковой сущности не существует. Тогда в той же логике есть определенное поведение, которое предусмотрено. Возможно, это поведение будет проверять «подмененную» сущность на существующую, хотя это не является предпочтительным применением (при следовании DDD нет понятия проверки Id на 0, это техническое решение, а функциональное будет иметь соответствующее имя, хотя бы — IsNew).
Идея в подмене состоит в том, что мы не получаем исключительную ситуацию, а продолжаем работу так же, как когда сущность присутствует. Разница в том что методы этой сущности не делают ничего, но и не прерывают выполнение остальной логики. Например, мы выполняем ряд операций над сущностью пользователя, который может быть связан с профилем компании (который это изменение также должно затронуть). Вместо добавления множества проверок на существование профиля компании — мы продолжаем выполнение логики на подмененной сущности, эти операции ничего не делают и с точки зрения производительности нам никак не мешают (мы же не «экономим на спичках»). В результате наш код более читаем, так как содержит только операции, да и цикломатическая сложность уменьшается с уменьшением ветвлений.
Я не трогал метод Find, потому что с ним все хорошо.
В исходной статье как раз с Get «все хорошо», он кидает исключение когда не находит сущность, а вот Find возвращает упакованный в «монаду» объект, если он не найден.
Null object pattern это из другой оперы.
Это как раз из той же оперы, решают одни и те же проблемы (только приводят к разным другим). Я следую принципу «Null-object pattern poor man's maybe monad» для языков без поддержки монад.
А решение через Maybe — относительно дешевое. В соответствии с практиками ООП и DDD, Null-object предпочтительнее и ближе к домену, но в то же время затратнее (количество кода => поддержка + написание) для полной («правильной» по отношению к остальной бизнес логике) реализации.
Очень тяжело сопоставить предыдущую статью и эту, ощущение что они обе из разных областей.
В первой озвучивается типичный для меня при следовании DDD подход к реализации Repository: методы Get и Find (в практике еще часто встречаю метод Exists для других сценариев). При чем первый не должен возвращать null ни в коем случае — либо результат, либо exception, который должен быть более конкретным чем NRE, хотя бы RecordNotFound.
Второй момент в исходной статье — Null Object pattern, который в приведеннои примере позволяет следовать функциональному («ленивому») подходу.
Контракт сам по себе — описывает как должна вести себя система. Раньше такое делали при помощи Assert'ов (по крайней мере во время c++ & mfc 4.2), а теперь с контрактами можно хоть на интерфейс проверки навесить.
В данной же статье «забыт» метод Find, остается только Get и усиленно критикуется.
Ну и про Null Object pattern:
Ссылочный тип может ссылаться на null. Зачем засовывать один ссылочный тип в другой и добавлять в контейнер свойство HasValue, для меня решительно не понятно.
Типичная реализация, вполне согласована с Nullable<> по синтаксису.
А приведенный код где используется ref вообще никак не согласуется с предыдущим «функциональным» принципом (согласно книге Framework Design Guidelines кода с ref и out следует избегать).
Информации по поводу необходимости полной переустановки, когда выйдет release версия апдейта (как с тестовыми сборками самой Windows) пока нет, есть только кучи вопросов в блогах.
с разрешениями не исправили и думаю не исправят.
недавно поставил на нетбук, увидел что ни одно метро-приложение не работает и снес.
еще вай-фай почему-то не хотел подключаться к 802.11n WPA2-PSK (все драйвера по-умолчанию поднялись и работали, сеть видел, пробовал разные настройки драйвера — никак).
в общем, преимуществ не получил.
1) Знаю русский, украинский и английский. Знание голландского абсолютно не критично для айтишника (если планировать оставаться в Голландии — то за 5 лет хорошо бы выучить и сдать экзамен), английский — обязательно.
2) Условия хорошие для highly skilled. Главное найти работодателя, иметь диплом о высшем образовании и подтверждения что Вы востребованы на локальном (в моем случае украинском) рынке труда (мой работодатель сделал поиск вакансий по сайтам с похожими требованиями как у них), и справка о доходах за 3-6 месяцев. Есть еще минимальные з/п, что-то вроде 35к в год до 30 лет и 55к в год после 30 лет (можно поискать по сайтам, не помню). Это важно при подаче документов, но проблем не вижу.
Про подтверждение — это к работодателю, как я вижу — проблем никаких нет. У нас в компании очень мало голландцев, а среди айтишников вообще один-два.
1) Знаю русский, украинский и английский. Знание голландского абсолютно не критично для айтишника (если планировать оставаться в Голландии — то за 5 лет хорошо бы выучить и сдать экзамен), английский — обязательно.
2) Условия хорошие для highly skilled. Главное найти работодателя, иметь диплом о высшем образовании и подтверждения что Вы востребованы на локальном (в моем случае украинском) рынке труда (мой работодатель сделал поиск вакансий по сайтам с похожими требованиями как у них), и справка о доходах за 3-6 месяцев. Есть еще минимальные з/п, что-то вроде 35к в год до 30 лет и 55к в год после 30 лет (можно поискать по сайтам, не помню). Это важно при подаче документов, но проблем не вижу.
Про подтверждение — это к работодателю, как я вижу — проблем никаких нет. У нас в компании очень мало голландцев, а среди айтишников вообще один-два.
Процесс проходил довольно долго и растянуто. Вначале было несколько телефонных интервью (с рекрутером, с менеджером и одно техническое). После интервью не было никаких вестей примерно месяц. После перезвонили, спросили не хочу ли я на 2 года в другой офис, в Оман — отказался. Позже забыл про них (прошел еще через несколько собеседований), а через еще через 2 месяца пригласили на он-сайт интервью, для которого мне сделали визу (обычный одноразовый шенген — примерно неделя на все документы, от работодателя — отель, самолет и приглашение).
Был день собеседований в Голландском офисе, больше обсуждали с чем и кем мне было бы удобнее работать. Технические вопросы по сравнению с нашими «формализованными» интервью — простые (формализованные — это те где интервьювер обязан прогнать кандидата по всем темам и проставить оценки, самому приходилось такие проводить для других проектов).
Во время интервью нашел единомышленника, с которым теперь и работаем в одной команде.
Далее после собеседования прошло до месяца и со мной связались для согласования условий работы. Через неделю получил оффер, который подписал и отправил обратно по DHL. После они звонили по моим референсам (бывшие работодатели) за отзывами.
Процесс получения вида на жительство больше контролировался работодателем, мне показался относительно простым (только документы приходилось делать быстро, поэтому платил за «ускоренные» процедуры)
Документы (украинские официальны нужно перевести на англ. и поставить два апостиля, в бюро переводов в курсе):
— свидетельство о рождении (брал копию нового образца, вместо советского — 1 день в ОВИРе по месту рождения)
— (в моем случае ничего пока) свидетельство о браке/о разводе/нотариально заверенное заявление что не состою в браке (последнее если незарегистрированного партнера забирать)
— документы партнера/детей (не в моем случае — ехал изначально один, холостой)
— диплом (нужен позже, лучше делать заранее, для 30% рулинга)
— письмо от работодателя с доходом за последние 3 месяца (также позже — для 30%)
— выписки из банка (я по привычке беру за пол года с движениями по валютному счету на англ.)
В это время работодатель одновременно распечатывает сканы моих документов (свидетельство, паспорт) и подает в IND и на визу. Через 2-3 недели я получаю подтверждение и иду с документами забирать MVV визу (6 месяцев, мультивъезд). Покупаю билеты, бронирую отель и еду. После открытия счета в местном банке — мне заплатили деньги на релокацию.
В основном это все, далее уже на месте. Сложнее всего найти жилье, а в остальном работодатель координирует. Вид на жительство я получил через неделю после прилета. Вот 30% рулинг — ждал долго, т.к. почти 2 месяца собирал документы находясь в Голландии.
В общем есть ряд мелочей, а так — все очень просто.
Встроенные diff/merge можно настроить извне, например для git описано здесь: www.codewrecks.com/blog/index.php/2013/03/19/how-to-configure-diff-and-merge-tool-in-visual-studio-git-tools/
Для остального внешние инструменты кажутся более подходящими.
Все же обычный навигатор для «экстрималов» — Dakota 20 за 250 евро выглядит разумнее при том же времени работы и 2-х батарейках вместо 3-х. Пусть не такой отзывчивый, но для остального и телефон можно на сдачу купить.
Есть такое исключение (например в соглашениях для кода ядра линукса), что чем проще метод, тем длиннее может быть его код. Например:
if (...) { ... } else if (...) { ... } ... else { ... }само собой цикломатическая сложность у данного метода растет очень быстро.
Аналогично при использовании Fluent Builders в ООП.
Вообще из своего опыта скажу что самые действенные способы для чистоты кода — четкие соглашения по стилю написания, парное программирование и постоянные ревью.
В статье, мало внимания уделено соглашениям, все же интереснее какие именно правила позволяют сделать код чище. Вот, например, для C#, частично как адаптированный конспект по Clean Code: csharpguidelines.codeplex.com/
С подобным можно столкнуться когда доменная область строится через EventSource, где хранится не сам объект, а только набор событий. Тогда имеем: сохраненный объект (1+ событий), новый объект (0 событий) и несуществующий объект (0 событий). Вот тут и получаем что только отвечающий бизнес код должен знать где использовать Find, а где Get.
В основном получение записи по идентификатору — та операция которая должна всегда возвращать сущность и при отсутствии таковой будет исключительная ситуация.
Другой же момент когда в бизнес логике явно предусматривается возможность что таковой сущности не существует. Тогда в той же логике есть определенное поведение, которое предусмотрено. Возможно, это поведение будет проверять «подмененную» сущность на существующую, хотя это не является предпочтительным применением (при следовании DDD нет понятия проверки Id на 0, это техническое решение, а функциональное будет иметь соответствующее имя, хотя бы — IsNew).
Идея в подмене состоит в том, что мы не получаем исключительную ситуацию, а продолжаем работу так же, как когда сущность присутствует. Разница в том что методы этой сущности не делают ничего, но и не прерывают выполнение остальной логики. Например, мы выполняем ряд операций над сущностью пользователя, который может быть связан с профилем компании (который это изменение также должно затронуть). Вместо добавления множества проверок на существование профиля компании — мы продолжаем выполнение логики на подмененной сущности, эти операции ничего не делают и с точки зрения производительности нам никак не мешают (мы же не «экономим на спичках»). В результате наш код более читаем, так как содержит только операции, да и цикломатическая сложность уменьшается с уменьшением ветвлений.
В исходной статье как раз с Get «все хорошо», он кидает исключение когда не находит сущность, а вот Find возвращает упакованный в «монаду» объект, если он не найден.
Это как раз из той же оперы, решают одни и те же проблемы (только приводят к разным другим). Я следую принципу «Null-object pattern poor man's maybe monad» для языков без поддержки монад.
А решение через Maybe — относительно дешевое. В соответствии с практиками ООП и DDD, Null-object предпочтительнее и ближе к домену, но в то же время затратнее (количество кода => поддержка + написание) для полной («правильной» по отношению к остальной бизнес логике) реализации.
В первой озвучивается типичный для меня при следовании DDD подход к реализации Repository: методы Get и Find (в практике еще часто встречаю метод Exists для других сценариев). При чем первый не должен возвращать null ни в коем случае — либо результат, либо exception, который должен быть более конкретным чем NRE, хотя бы RecordNotFound.
Второй момент в исходной статье — Null Object pattern, который в приведеннои примере позволяет следовать функциональному («ленивому») подходу.
Контракт сам по себе — описывает как должна вести себя система. Раньше такое делали при помощи Assert'ов (по крайней мере во время c++ & mfc 4.2), а теперь с контрактами можно хоть на интерфейс проверки навесить.
В данной же статье «забыт» метод Find, остается только Get и усиленно критикуется.
Ну и про Null Object pattern:
Типичная реализация, вполне согласована с Nullable<> по синтаксису.
А приведенный код где используется ref вообще никак не согласуется с предыдущим «функциональным» принципом (согласно книге Framework Design Guidelines кода с ref и out следует избегать).
Еще спасибо за такой забавный оффтопик: NeverWet
Scott Hanselman пишет, что с этого превью обновиться на release/обратно не получиться
недавно поставил на нетбук, увидел что ни одно метро-приложение не работает и снес.
еще вай-фай почему-то не хотел подключаться к 802.11n WPA2-PSK (все драйвера по-умолчанию поднялись и работали, сеть видел, пробовал разные настройки драйвера — никак).
в общем, преимуществ не получил.
2) Условия хорошие для highly skilled. Главное найти работодателя, иметь диплом о высшем образовании и подтверждения что Вы востребованы на локальном (в моем случае украинском) рынке труда (мой работодатель сделал поиск вакансий по сайтам с похожими требованиями как у них), и справка о доходах за 3-6 месяцев. Есть еще минимальные з/п, что-то вроде 35к в год до 30 лет и 55к в год после 30 лет (можно поискать по сайтам, не помню). Это важно при подаче документов, но проблем не вижу.
Про подтверждение — это к работодателю, как я вижу — проблем никаких нет. У нас в компании очень мало голландцев, а среди айтишников вообще один-два.
2) Условия хорошие для highly skilled. Главное найти работодателя, иметь диплом о высшем образовании и подтверждения что Вы востребованы на локальном (в моем случае украинском) рынке труда (мой работодатель сделал поиск вакансий по сайтам с похожими требованиями как у них), и справка о доходах за 3-6 месяцев. Есть еще минимальные з/п, что-то вроде 35к в год до 30 лет и 55к в год после 30 лет (можно поискать по сайтам, не помню). Это важно при подаче документов, но проблем не вижу.
Про подтверждение — это к работодателю, как я вижу — проблем никаких нет. У нас в компании очень мало голландцев, а среди айтишников вообще один-два.
Был день собеседований в Голландском офисе, больше обсуждали с чем и кем мне было бы удобнее работать. Технические вопросы по сравнению с нашими «формализованными» интервью — простые (формализованные — это те где интервьювер обязан прогнать кандидата по всем темам и проставить оценки, самому приходилось такие проводить для других проектов).
Во время интервью нашел единомышленника, с которым теперь и работаем в одной команде.
Далее после собеседования прошло до месяца и со мной связались для согласования условий работы. Через неделю получил оффер, который подписал и отправил обратно по DHL. После они звонили по моим референсам (бывшие работодатели) за отзывами.
Процесс получения вида на жительство больше контролировался работодателем, мне показался относительно простым (только документы приходилось делать быстро, поэтому платил за «ускоренные» процедуры)
Документы (украинские официальны нужно перевести на англ. и поставить два апостиля, в бюро переводов в курсе):
— свидетельство о рождении (брал копию нового образца, вместо советского — 1 день в ОВИРе по месту рождения)
— (в моем случае ничего пока) свидетельство о браке/о разводе/нотариально заверенное заявление что не состою в браке (последнее если незарегистрированного партнера забирать)
— документы партнера/детей (не в моем случае — ехал изначально один, холостой)
— диплом (нужен позже, лучше делать заранее, для 30% рулинга)
— письмо от работодателя с доходом за последние 3 месяца (также позже — для 30%)
— выписки из банка (я по привычке беру за пол года с движениями по валютному счету на англ.)
В это время работодатель одновременно распечатывает сканы моих документов (свидетельство, паспорт) и подает в IND и на визу. Через 2-3 недели я получаю подтверждение и иду с документами забирать MVV визу (6 месяцев, мультивъезд). Покупаю билеты, бронирую отель и еду. После открытия счета в местном банке — мне заплатили деньги на релокацию.
В основном это все, далее уже на месте. Сложнее всего найти жилье, а в остальном работодатель координирует. Вид на жительство я получил через неделю после прилета. Вот 30% рулинг — ждал долго, т.к. почти 2 месяца собирал документы находясь в Голландии.
В общем есть ряд мелочей, а так — все очень просто.