В Норвегии, например, 96% электроэнергии из возобоновляемых источников.
Иметь электомобиль очень даже имеет смысл:
— огромные налоги на обычные машины и практически нулевые налоги на электромобили
— много бесплатных точек где можно зарядить машину
Как правило штрафом является оплата всего оставшегося срока контракта + они набрасывают какой-то процент, скажем 20%.
Мне кажется тут какая-то ошибка. При таких условиях нет смысла разрывать контракт. Если просто перестать пользоваться, то выйдет дешевле — не придется платить лишние 20%.
Если честно, я в принципе не понимаю как вы делаете мержи. У нас это делать не получалось. Git-svn из них делал одну ветку с помощью ребейза. Более того, ман git-svn(1) явно говорит:
it cannot yet represent merge history that happened inside git back upstream to SVN users. Therefore it is advised that users keep history as linear as possible inside git to ease compatibility with SVN
Running git merge or git pull is NOT recommended on a branch you plan to dcommit from because Subversion users cannot see any merges you’ve made.
Я с ужасом вспоминаю времена, когда наша команда использовала git-svn.
У нас расклад был такой: над продуктом работало две команды. Одна команда работала с SVN, а наша команда работала в git. Для этого мы себе склонировали репозиторий, положили его в gitorious и каждый пушил в него. Периодически кто-нибудь из команды эти репозитории синхронизировал с помощью git svn dcommit.
Из-за того, что Git и SVN концeптуально разные, мы наступили на грабли:
Грабли №1
Все коммиты из Git репозитория уходят в SVN репозиторий от имени того, кто запусткает git svn dcommit. После этой операции git-svn пересоздает локальный master бранч и забирает туда коммиты из SVN. В результате все авторы коммитов заменяются одним.
Гарбли №2
Мержи в SVN и в Git реализованы по-разному. По-этому git-svn перед тем как коммитить в SVN, «распрямляет» мержи с помощью rebase. В результате все мержи идут лесом, и приходится руками резовить конфликты.
В результате оказалось, что единственная работоспособная схема — это когда каждый клонирует себе SVN репозиторий и не использует мержи.
Интересно, наступил ли автор на те же грабли, и если да, то как решил эти проблемы.
Это нормальная зарплата для опытного программиста. Senior программисты получают больше. Был пост на Хабре пару лет назад.
В любом случае, если заплата меньше, то нужно к документам приложить диплом и резюме. Главное чтобы был оффер на руках.
Норвегия: Чтобы получить визу «Специалист» нужен только оффер на 500000 крон в год. Выдается вид на жительство на 3 года. Через три года постоянный вид на жительство.
Это немного нечестный пример.
Название может быть и пугающее, но это специализированный класс, который практически никогда не будет использоваться рядовым пользователем. Для человека, который разрабатывает фреймворки на основе Спринга и знаком со спринговой терминологией, это отличное название, которое четко говорит для чего он нужен и как его использовать.
Это всеравно что говорить: «эти химики все усложняют! Это ж надо такое придумать: аллилпропилдисульфид.»
У Вас ошибочное пониманимание того что является Паттерном.
«Ensure a class only has one instance, and provide a global point of access to it.» — это всего лишь секция «Intent» в описании патерна.
Цитата из GoF:
In general, a pattern has four essential elements:
The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two.....
The problem describes when to apply the pattern......
The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution doesn't describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.
The consequences are the results and trade-offs of applying the pattern.....
Из определения видно, что описание необходимых классов входит паттерн.
Согласно GoF, для реализации паттерна Singlton нужен всего один класс:
Participants
Singleton
defines an Instance operation that lets clients access its unique instance. Instance is a class operation (that is, a class method in Smalltalk and a static member function in C++).
may be responsible for creating its own unique instance.
Тепрь цитирую Вас:
А вот это как раз неверно. На стадии конструирования нам надо определить, сколько экземпляров мы создали, и если для какого-то класса мы создаем один экземпляр, то это и есть паттерн Singleton.
Единственный экземпляр класса в системе не является Синглтоном.
Если я создаю объект и через DI передаю его объектам — это не синглтон.
Синглтон — это паттерн, состоящий из вспомогательного класса, который предоставляет доступ к тому единственному экземпляру.
Вот она причина нашего недопонимания и как следствие спор о том, что чуше теплое или мягкое.
Каждый паттерн состоит из нескольких частей:
— Проблема, которую он решает
— Способ решить проблему архитектурно (На уровне ролей)
«гарантируйте, что у класса один экземпляр» — это не весь паттерн, это только проблема, которую решает паттерн.
Способ решения — «Сделайте класс Синглтон, который который контроллирует создание экземпляра и предоставляет доступ к этому экземпляра»
А детали реализации зависят от языка и необходимости в ленивой инициализации или в поддержке многопоточности. Именно детали описаны в топике.
Кажется у нас тут с Вами путаница в терминологии.
Похоже, Вы под Сингтоном подразумеваете единственный ЭКЗЕМПЛЯР ресурса.
Я же имею в виду СПОСОБ это обесепечить.
Про реализацию синглтона я не сказал ни слова, автор топика все отлично описал. Я сказал что этот паттерн в принципе решает одну проблему, но при этом добавляет еще две.
Вы приводите аргументы, подтверждающие проблемность Синглтона, но делаете противополжный вывод :)
Вероятно, вы хотите протестировать класс, зависящий от синглтона. Но эта постановка задачи неверна — класс должен зависеть от абстракции, а не от конкретной реализации (иначе бы никакие замены были невозможно, и мы бы не говорили о модульном тестировании). Следовательно, то, что вы тестируете, должно рассчитывать на получение экземпляра определенной абстракции (интерфейса, класса — не так
важно), и, в принципе, даже не обязано знать о том, сколько этих экземпляров в системе.
Абсолютно верно.
Следующий вопрос — откуда этот экземпляр взять, и вот он к синглтону как паттерну отношения не имеет.
Вот где Синглтон создает проблему.
Допустим у меня есть какой-то ресурс к которому нужен монопольный доступ. Синглтон предлагает изолировать его и предоставить один метод для доступа к ресурсу, скажем MyResource.getInstance().
Теперь у меня есть класс, для которого я хочу написать юнит-тест, но он использует Синглтон. В юнит тесте я не хочу создавать реальный экземпляр ресурса. Я хочу заменить его моком. Как мне это сделать? В книге «Working effectively with legacy code» предлагается сделать лазейку в виде сеттера MyResource.setInstance(). Но тогда есть опасность что этот метод будет использован кроме тестов еще и в продакшн коде.
Эта проблема вообще не имеет отношения к синглтону. Это типичная проблема любых неявных зависимостей (статических фабрик, сервис-локаторов и так далее). Соответственно, вам просто нужно выбрать (общий для всего проекта) стиль передачи/получения зависимостей (и у явного, и у неявного есть свои достоинства и недостатки) и придерживаться его.
Абсолютно верно.
Вместо в место Синглтонов и статических фабрик предпочтительнее использовать DI. Это позволит избежать описанной выше проблемы с тестированием.
Разделяйте dependency management и instance/construction/lifetime management. Мы можем взять DI как парадигму и Unity как IoC-контейнер, реализовать DI через вбрасывание в конструктор, а для конкретной зависимости указать, что ее Lifetime manager — ContainerControlled. Получим синглтон в DI — потому что у класса есть ровно один экземпляр. Можем сделать все то же самое, но выбрать не DI, а ServiceLocation (например, потому, что у нас нет контроля за созданием объектов) — получим синглтон через локатор (визуально практически не отличающийся от обычного синглтона).
Абсолютно верно.
Нужно разделять стадию Construction и стадию выполнения. На стадии выполния следует использовать те зависимости, которые были предоставлены DI контейнером, а не использовать Синглтон.
На стадии конструирования у нас есть полный контроль на тем сколько экземпляров мы создали, и в использовании Синглтона нет необходимости.
Общий вывод: На стадии конструирования Синглтон не нужен, а на стадии выполния его следует избегать.
В Норвегии, например, 96% электроэнергии из возобоновляемых источников.
Иметь электомобиль очень даже имеет смысл:
— огромные налоги на обычные машины и практически нулевые налоги на электромобили
— много бесплатных точек где можно зарядить машину
Мне кажется тут какая-то ошибка. При таких условиях нет смысла разрывать контракт. Если просто перестать пользоваться, то выйдет дешевле — не придется платить лишние 20%.
У нас расклад был такой: над продуктом работало две команды. Одна команда работала с SVN, а наша команда работала в git. Для этого мы себе склонировали репозиторий, положили его в gitorious и каждый пушил в него. Периодически кто-нибудь из команды эти репозитории синхронизировал с помощью git svn dcommit.
Из-за того, что Git и SVN концeптуально разные, мы наступили на грабли:
Грабли №1
Все коммиты из Git репозитория уходят в SVN репозиторий от имени того, кто запусткает git svn dcommit. После этой операции git-svn пересоздает локальный master бранч и забирает туда коммиты из SVN. В результате все авторы коммитов заменяются одним.
Гарбли №2
Мержи в SVN и в Git реализованы по-разному. По-этому git-svn перед тем как коммитить в SVN, «распрямляет» мержи с помощью rebase. В результате все мержи идут лесом, и приходится руками резовить конфликты.
В результате оказалось, что единственная работоспособная схема — это когда каждый клонирует себе SVN репозиторий и не использует мержи.
Интересно, наступил ли автор на те же грабли, и если да, то как решил эти проблемы.
В любом случае, если заплата меньше, то нужно к документам приложить диплом и резюме. Главное чтобы был оффер на руках.
Есть еще виза "Квалифицированный рабочий", но для нее нужно подтверждение опыта и образования.
По английски говорят практически все.
Название может быть и пугающее, но это специализированный класс, который практически никогда не будет использоваться рядовым пользователем. Для человека, который разрабатывает фреймворки на основе Спринга и знаком со спринговой терминологией, это отличное название, которое четко говорит для чего он нужен и как его использовать.
Это всеравно что говорить: «эти химики все усложняют! Это ж надо такое придумать: аллилпропилдисульфид.»
«Ensure a class only has one instance, and provide a global point of access to it.» — это всего лишь секция «Intent» в описании патерна.
Цитата из GoF:
Из определения видно, что описание необходимых классов входит паттерн.
Согласно GoF, для реализации паттерна Singlton нужен всего один класс:
Тепрь цитирую Вас:
Единственный экземпляр класса в системе не является Синглтоном.
Если я создаю объект и через DI передаю его объектам — это не синглтон.
Синглтон — это паттерн, состоящий из вспомогательного класса, который предоставляет доступ к тому единственному экземпляру.
Каждый паттерн состоит из нескольких частей:
— Проблема, которую он решает
— Способ решить проблему архитектурно (На уровне ролей)
«гарантируйте, что у класса один экземпляр» — это не весь паттерн, это только проблема, которую решает паттерн.
Способ решения — «Сделайте класс Синглтон, который который контроллирует создание экземпляра и предоставляет доступ к этому экземпляра»
А детали реализации зависят от языка и необходимости в ленивой инициализации или в поддержке многопоточности. Именно детали описаны в топике.
Похоже, Вы под Сингтоном подразумеваете единственный ЭКЗЕМПЛЯР ресурса.
Я же имею в виду СПОСОБ это обесепечить.
Про реализацию синглтона я не сказал ни слова, автор топика все отлично описал. Я сказал что этот паттерн в принципе решает одну проблему, но при этом добавляет еще две.
Вы приводите аргументы, подтверждающие проблемность Синглтона, но делаете противополжный вывод :)
Абсолютно верно.
Вот где Синглтон создает проблему.
Допустим у меня есть какой-то ресурс к которому нужен монопольный доступ. Синглтон предлагает изолировать его и предоставить один метод для доступа к ресурсу, скажем MyResource.getInstance().
Теперь у меня есть класс, для которого я хочу написать юнит-тест, но он использует Синглтон. В юнит тесте я не хочу создавать реальный экземпляр ресурса. Я хочу заменить его моком. Как мне это сделать? В книге «Working effectively with legacy code» предлагается сделать лазейку в виде сеттера MyResource.setInstance(). Но тогда есть опасность что этот метод будет использован кроме тестов еще и в продакшн коде.
Абсолютно верно.
Вместо в место Синглтонов и статических фабрик предпочтительнее использовать DI. Это позволит избежать описанной выше проблемы с тестированием.
Абсолютно верно.
Нужно разделять стадию Construction и стадию выполнения. На стадии выполния следует использовать те зависимости, которые были предоставлены DI контейнером, а не использовать Синглтон.
На стадии конструирования у нас есть полный контроль на тем сколько экземпляров мы создали, и в использовании Синглтона нет необходимости.
Общий вывод: На стадии конструирования Синглтон не нужен, а на стадии выполния его следует избегать.