Туалет такой же важный атрибут как хорошая вентиляция и фильтрованная вода. Мне пришлось документы забрать после пары дней, где на сотню мужиков 1 тулает, хоть и офис в центре Москвы. Очереди, запах, и ведь эта сотня как-то терпит это:)
Лучше договор почитать. там хорошо про гарантию написано:
Пользователь не получил ни одного предложение о трудоустройстве, он обязуется:
…
6.4.4. принять предложение о трудоустройстве от Сервиса или работодателей,
предложенных Сервисом, которое соответствует его способностям, навыкам и знаниям,
приобретенным в процессе прохождения Программы.
6.5. Обязательства Сервиса по оказанию содействия в трудоустройстве считаются выполненными
при получении Пользователем от работодателя и принятие им предложения о трудоустройстве, либо
при отказе Пользователя от 3 (трех) предложений о трудоустройстве
6.6. Сервис не несет ответственность за отказ работодателя сотрудничать с участником программы
по причинам, не связанным с уровнем профессиональных компетенций.
Т.е. рабство, минимальные зарплаты и необоснованные увольнения.
Но в комментариях хоть честно написали «лучшим», а реклама вводит в заблуждение, будто всем гарантированное
Использование готовых итераторов и интерфейса IteratorAggregate позволяет нам значительно упростить создание собственных классов-итераторов.
…
результат будет таким же, как и при собственноручной реализации интерфейса Iterator.
Из статьи может показаться, что IteratorAggregate нужен только для готовых итераторов. Более точно: IteratorAggregate позволяет отделить код итератора от итерируемого объекта. И отличие такой реализации в том, что можно обходить один и тот же объект во вложенных foreach-циклах (т.к. итератор создается для каждого цикла свой).
Все знают, что сейчас программирование — это… супероплачиваемая профессия.
Все? Я, например, не знаю. Вот для чего это вообще писать? Привлечь больше людей на курсы, где зарплата у преподавателей 250$? Что значит супероплачиваемая?
Отлично. Недавно понадобилось сделать такую же анимацию, нашелся только старенький jquery-плагин.
Единственное пожелание: добавьте файл лицензии (MIT или другую), чтобы можно было спокойно использовать в коммерческих проектах.
А почему исчезнет? Можно с другой стороны подойти. Если параллелизм это один из способов, то вот задача: как выполнить конкурентно 20 потоков на 2 ядрах, используя этот способ?
Так о том и речь. Распараллеливает шедулер, если он этого делать не будет, конкурентность не исчезнет. А если реализовать конкурентность через параллелизм, то как только все ядра получат по треду, работа выполняться будет, но пользоваться системой будет нельзя. Потому заголовок статьи бессмысленный.
Не способ. При параллелизме нет конкурентности. Параллелизмом лишь можно ускорить конкурентность. Да и что значит «достижение»? Например, если шедулер решил все треды выполнять на каком-то одном ядре из 8, конкурентность никуда не пропадёт.
Всё зависит от того, чем потоки занимаются. У меня сейчас на 8 ядрах запущено 2600+ потоков и всё летает. А если 8 потоков заняты вычислениями, загружая каждое ядро на 100%, то, естественно, что не делай, они не начнут быстрее выполнять свою работу.
Эрик Гамма например считает что вреда от GoF вышло столько же
А ссылку можно? Гуглится только, что он хотел бы только чуть отрефакторить книгу и добавить новые шаблоны.
Про SOLID. В статье об этом примерно и написано. Liskov/DI существуют давно, ISP по сути то же самое, что и SRP, а SRP и OCP это и есть основные способы достичь «loose coupling, high cohesion». Мартин нового ничего не придумывал, просто грамотно описал концепции.
> К сервис-локатору это никак не относится.
Если обработчик заказов использует другой сервис, например склад сервис, то согласно паттерну SL он должен будет сделать Locator.Resolve<IWarehouseService>().
> что разница между средними и лучшими программистами в 10 раз обуславливается как раз таки способностью понимать и строить сложные абстракции.
> Все дело в главном императиве — борьба со сложностью.
Противоречие. Разница между средними и лучшими, наоборот, обуславливается способностью строить простые и понятные всем абстракции.
После нескольких лет с симфони попробовал развернуть веб-приложение на ASP.NET MVC (тру энтерпрайз). Делать что-то на одно удовольствие: всё очевидно и просто, и дело не в похожих концепциях, а именно в их реализации. Может энтерпрайзу не так уж и нужна лишняя сложность?
> 4) Прекрасно расширяется, разделение бизнес-логики по бандлам
Ну кстати по официальному гайду рекомендация хранить всё в одном бандле.
Но если делать действительно гибко, и «framework-agnostic», то бизнес-логику вообще не надо класть в бандлы.
> 3) Статически-типизированный фреймворк. В Laravel или Zend повсеместно нарушается ООП при использовании fluent-интерфейсов
В Laravel можно и правильно всё делать, можно и не по ООП. С таким же успехом можно и symfony испортить (у меня проект есть, где все зависимости разруливаются через $container->get()).
Т.е. рабство, минимальные зарплаты и необоснованные увольнения.
Но в комментариях хоть честно написали «лучшим», а реклама вводит в заблуждение, будто всем гарантированное
Из статьи может показаться, что IteratorAggregate нужен только для готовых итераторов. Более точно: IteratorAggregate позволяет отделить код итератора от итерируемого объекта. И отличие такой реализации в том, что можно обходить один и тот же объект во вложенных foreach-циклах (т.к. итератор создается для каждого цикла свой).
Все? Я, например, не знаю. Вот для чего это вообще писать? Привлечь больше людей на курсы, где зарплата у преподавателей 250$? Что значит супероплачиваемая?
Единственное пожелание: добавьте файл лицензии (MIT или другую), чтобы можно было спокойно использовать в коммерческих проектах.
Про SOLID. В статье об этом примерно и написано. Liskov/DI существуют давно, ISP по сути то же самое, что и SRP, а SRP и OCP это и есть основные способы достичь «loose coupling, high cohesion». Мартин нового ничего не придумывал, просто грамотно описал концепции.
"SELECT [Name]"вместо@"SELECT ""Name""".Если обработчик заказов использует другой сервис, например склад сервис, то согласно паттерну SL он должен будет сделать
Locator.Resolve<IWarehouseService>().Аргументы в статье валидные, но и были уже давно описаны Фаулером в популярной статье, Inversion of Control Containers and the Dependency Injection pattern.
> Все дело в главном императиве — борьба со сложностью.
Противоречие. Разница между средними и лучшими, наоборот, обуславливается способностью строить простые и понятные всем абстракции.
После нескольких лет с симфони попробовал развернуть веб-приложение на ASP.NET MVC (тру энтерпрайз). Делать что-то на одно удовольствие: всё очевидно и просто, и дело не в похожих концепциях, а именно в их реализации. Может энтерпрайзу не так уж и нужна лишняя сложность?
Ну кстати по официальному гайду рекомендация хранить всё в одном бандле.
Но если делать действительно гибко, и «framework-agnostic», то бизнес-логику вообще не надо класть в бандлы.
> 3) Статически-типизированный фреймворк. В Laravel или Zend повсеместно нарушается ООП при использовании fluent-интерфейсов
В Laravel можно и правильно всё делать, можно и не по ООП. С таким же успехом можно и symfony испортить (у меня проект есть, где все зависимости разруливаются через $container->get()).