В самом минимальном и простом варианте это пожалуй так, но дождаться аккуратного и рационального и адекватного современным практикам кода от начинающего javascript программиста будет несколько сложнее, выбери он python ruby или php.
Те. с задачей «анимировать форму с помощью jquery» новообращенный справится вполне достойно, но на более сложных и маштабных задачах будет выдавать лютый нечитабельный треш.
Прототипный подход к наследованию, функциональная и объектная парадигмы, тотальная асинхронность, нюансы с областями видимости, зачатки параллельности в виде вебворкеров, огромное количество способов сделать одно и то же.
Только за счет этих факторов js сложнее большинства скриптовых языков программирования, так что я не рискнул бы утверждать, что изучить javascrpt на хорошем уровне — это действительно детская задача.
С технической точки зрения Ember.js не уступает Angular2, а в чем-то даже превосходит, например ember-cli зайдействовали для написания аналогичной утилиты для Angular.
Если Евгений нас читает — было бы интересно услышать его мнение по поводу данного фреймворка.
В статье обращаются к программисту, хотя обращение к стартап-холдеру было бы уместнее.
Точно так же, в командной работе мы крайне легко опускаемся до деталей и перестаём обращать внимание на то, почему мы создаём программы и системы так же, как это делали изначально.
С точки зрения программиста — для опыта и денег. А еще это весело.
В своём лучшем проявлении, компания может создавать смысл и цель для своих сотрудников, обогащать их жизни и жизнь сообщества, и добавлять привлекательности окружающему ландшафту.
Почему бы не проводить валидацию в модели формы\контроллере, это позволит как соблюсти инварианты, так и снять с модели ответственность за их проверку. В самой же модели можно проверять принципиальную допустимость совершения операции с данными параметрами, тут и выбрасывание исключений было бы вполне уместно.
Как валидация команд решает следующий таск?
Имеем две формы регистрации, на страницах example.com/en/register и example.com/cn/register, на первой форме валидными считаются номера банковских карт европейских\американских банков-эмитентов, а на второй — только китайских.
В данном случае любой существующий номер карты в принципе валиден (те. команда успешно завершится), но присутствуют некоторые инварианты, введенные лишь для удобства пользователя.
Жаль, что помимо DO в тест не был включены другие представители зарубежного хостинга, тот же OVH предлагает весьма и весьма заманчивые тарифы на vps.
Из российского хостинга пробовал timeweb\ihc, в обоих случаях соотношение цена\качество оказалось не слишком хорошим.
Но простите, репо angular1 48,787 звезд, yii2 7,957. Более того, angular распространен повсеместно, а yii2 большей частью на территории СНГ.
Относительно минусов yii2, главным на мой взгляд минусом является гвоздями приколоченное ActiveRecord и отсутствие в документации инструкций по интеграции DataMapper, что влечет за собой непопулярность TDD\DI\DDD практик в сообществе.
Так же к минусам (а возможно и к плюсам) следует отнести явную нацеленность фреймворка на прототипы, об этом говорит обилие странных виджетов, вроде Pjax\Modal\Nav\Carousel, полезных на этапе прототипа, но слишком сложных в кастомизации для продакшена.
Но можно писать книгу, искусственно растягивая или сжимая повествование, добавляя воды и совершая прочие манипуляции, выгодные издательству, но никак не читателю. Интернет же предоставляет максимальное количество вариантов объяснения интересной темы, всегда можно выбрать то что
а) соответствует твоему уровню на момент чтения
б) написано более понятным языком
в) затрагивает интересные читателю смежные темы
Но и в изучени по блогам\статьям есть свои минусы — очень сложно судить об авторитете и опыте автора, можно ли ему доверять.
Никто и никогда не знает, что придя в больницу можно записаться на клизму, гастроскопию и прогревания, теперь сделаем эти процедуры обязательными? Никто и никогда не знает же, хорошо оправдание.
Единственная правда в том, что альтернативные всеобщей блокировке методы — даже не рассматриваются, этот факт говорит больше любых слов об изначальном назначении всех этих законопроектов.
Большая часть программистов стала программистами не по причине любви к большим деньгам, а по причине интереса к данному роду деятельности, странно пытаться применять к ним метод работы «от забора до обеда».
Между тем тот самый «челлендж» — это не более, чем обратная сторона тяги к программированию\исследованию и фактически является профессиональной чертой разработчика.
Новые выразительные стредства\Сахар как раз и вводятся в целях борьбы со сложностью, дабы программист мог писать более эффектиный, расширяемый, а главное понятный код. Конечно в некоторых случаях сахаром злоупотребляют, в некоторых он входит в противоречие со старыми концепциями и нарушает совместимость легаси кода, но конечная цель — все же помочь программисту, разве это не так?
Давайте за пример возьмем php4 (да, я утрирую, но для аналогии не помешает), помогает ли его простая структура программисту больше концентрироваться на Api приложения, его архитектуре и алгоритмах? Скорее нет чем да, вероятно программист будет тратить добрую часть своего времени на борьбу с ограничениями языка, вместо того, чтобы просто воспользоваться встроенными возможностями.
В конце концов синтаксис\экосистема языка изучается один раз, это не столь большая плата за использование более мощного инструмента.
Посмотрите на современные мультипарадигменные\объектные\функциональные языки, они действительно настолько сложны, чтобы это вызывало проблемы?
Lisp это язык совершенно иного сорта, он изначально расчитан на легкое расширение и создание собственных выразительных средств, сравнивать с ним некорректно.
Тут вопрос, как жить с изначально (by design) простым языком, дальнейшее расширение\усложнение которого этому «by design» и противоречит.
Кажется автор имел в виду не усложнение ради усложнения\элитарности, а намеренное ограничение языком Go доступных программисту выразительных средств. Как может выглядеть путь развития Go программиста? Какие инструменты язык предоставит ему для совершенствования своего кода? Какими новыми навыками Go программист будет располагать через несколько лет?
Между тем стоит заметить, что современные яп постоянно наращивают арсенал выразительных средств, пример тому — ecmascript 2015, новая версия которого на порядок улучшила лаконичность кода.
У вас типичная batch задача, такую стоило бы делать или средствами SQL, не прибегая к маппингу вообще (вне зависимости от того, AR это или DM), либо просто поставить её в очередь и обработать в отдельном потоке.
Резюме: AR не виноват, проблема в ошибочном выборе инструмента.
В статье предполагается изначальная полная незащищенность организации:
— у всех есть доступ в публичную сеть
— допускается явное использование сотрудником чужих доступов
— использование чужих машин и аккаунтов
С тем же успехом сотрудник мог погулять по интернет ресурсам\принять email, «случайно» запустив червя в сеть компании. Кстати для «шпиона» это было бы куда более надежным и правильным вариантом, так как даже при наличии всех логов — возможно будет вычислить лишь адрес утечки, да и то не всегда.
Если делегирование по-прежнему лучше наследования, но при этом делегирование — всего лишь передача полномочий прототипу, то какой вывод можно сделать из первого утверждения:
1) прототипное наследование лучше наследования классов?
2) делегирование невозможно без прототипного наследования?
Кажется автор вводит свою уникальную терминологию, которая не вяжется с терминологией «банды четырёх», либо я просто не смог понять посыл автора.
Функциональные языки в отличие от объектно-ориентированных Ruby и JavaScript предлагают совершенно иной подход к решению задач.
Но когда JavaScript успел стать объектно-ориентированным, позвольте спросить? Скорее его можно назвать мультипарадигменным, так как он включает неплохой набор инструментов как для функциональной парадигмы, так и для прототипной\объектно-ориентированной.
Те. с задачей «анимировать форму с помощью jquery» новообращенный справится вполне достойно, но на более сложных и маштабных задачах будет выдавать лютый нечитабельный треш.
Только за счет этих факторов js сложнее большинства скриптовых языков программирования, так что я не рискнул бы утверждать, что изучить javascrpt на хорошем уровне — это действительно детская задача.
Если Евгений нас читает — было бы интересно услышать его мнение по поводу данного фреймворка.
С точки зрения программиста — для опыта и денег. А еще это весело.
Простите, но это маркетинговый булшит.
Как валидация команд решает следующий таск?
В данном случае любой существующий номер карты в принципе валиден (те. команда успешно завершится), но присутствуют некоторые инварианты, введенные лишь для удобства пользователя.
Из российского хостинга пробовал timeweb\ihc, в обоих случаях соотношение цена\качество оказалось не слишком хорошим.
Относительно минусов yii2, главным на мой взгляд минусом является гвоздями приколоченное ActiveRecord и отсутствие в документации инструкций по интеграции DataMapper, что влечет за собой непопулярность TDD\DI\DDD практик в сообществе.
Так же к минусам (а возможно и к плюсам) следует отнести явную нацеленность фреймворка на прототипы, об этом говорит обилие странных виджетов, вроде Pjax\Modal\Nav\Carousel, полезных на этапе прототипа, но слишком сложных в кастомизации для продакшена.
а) соответствует твоему уровню на момент чтения
б) написано более понятным языком
в) затрагивает интересные читателю смежные темы
Но и в изучени по блогам\статьям есть свои минусы — очень сложно судить об авторитете и опыте автора, можно ли ему доверять.
Единственная правда в том, что альтернативные всеобщей блокировке методы — даже не рассматриваются, этот факт говорит больше любых слов об изначальном назначении всех этих законопроектов.
Между тем тот самый «челлендж» — это не более, чем обратная сторона тяги к программированию\исследованию и фактически является профессиональной чертой разработчика.
В конце концов синтаксис\экосистема языка изучается один раз, это не столь большая плата за использование более мощного инструмента.
Посмотрите на современные мультипарадигменные\объектные\функциональные языки, они действительно настолько сложны, чтобы это вызывало проблемы?
Тут вопрос, как жить с изначально (by design) простым языком, дальнейшее расширение\усложнение которого этому «by design» и противоречит.
Кстати, почему Go, а не Nodejs?
Между тем стоит заметить, что современные яп постоянно наращивают арсенал выразительных средств, пример тому — ecmascript 2015, новая версия которого на порядок улучшила лаконичность кода.
Резюме: AR не виноват, проблема в ошибочном выборе инструмента.
— у всех есть доступ в публичную сеть
— допускается явное использование сотрудником чужих доступов
— использование чужих машин и аккаунтов
С тем же успехом сотрудник мог погулять по интернет ресурсам\принять email, «случайно» запустив червя в сеть компании. Кстати для «шпиона» это было бы куда более надежным и правильным вариантом, так как даже при наличии всех логов — возможно будет вычислить лишь адрес утечки, да и то не всегда.
1) прототипное наследование лучше наследования классов?
2) делегирование невозможно без прототипного наследования?
Кажется автор вводит свою уникальную терминологию, которая не вяжется с терминологией «банды четырёх», либо я просто не смог понять посыл автора.
Но когда JavaScript успел стать объектно-ориентированным, позвольте спросить? Скорее его можно назвать мультипарадигменным, так как он включает неплохой набор инструментов как для функциональной парадигмы, так и для прототипной\объектно-ориентированной.