Ответ HR-девицам

Г-ди, испанский стыд то какой

23 непростых вопроса для JavaScript-собеседования

Так рекурсивный подход используется в динамическом программировании, разве нет? И если рекурсия хвостовая, то ее можно написать в виде цикла.

23 непростых вопроса для JavaScript-собеседования

Рекурсивно и динамически?

Разработка в монорепозитории. Доклад Яндекса

Меня больше всего волнует мусорность коммитов и, как было описано выше, коллизии с пулреквестами. Так же сталкивались со временем сборки, которая в лучшем варианте была полчаса. Что касается зависимости бэка и фронта, то в данном случае придётся тестировать сразу 2 ПР. Мы мокали заранее оговоренный сваггер и пушили в свои ветки. Потому это все поднималось на дев среде в контейнерах и тестилось е2е. Потому все поднималось на проде. П.С. У нас был ньюанс. Было с десяток фронтовых микроаппов и около 20-ти микроаппов бэка, что не так много.

Разработка в монорепозитории. Доклад Яндекса

del, misscliked

Разработка в монорепозитории. Доклад Яндекса

Если про фронт я ещё могу понять идею моно репа, то как вы относитесь к монорепу, где лежит и бжу и фронт?

Неожиданный порядок инициализации наследованных классов в JavaScript

Да, виноват, по диагонали код автора прочитал. Там впринципе тупо сделано.

Пожалуй надо было так:

class BaseTooltip {
  type = 'baseTooltip';
  content;

  constructor(someField) {
    this.content = someField;
  }

  render() {
    console.log(this.type, this.content);
  }
}

class SpecialTooltip extends BaseTooltip {
  type = 'specialTooltip';

  constructor(content) {
    super(content);
  }
}

const newChild = new SpecialTooltip('child');
newChild.render();

П.С. Однако свойство template все же берется из родителя. В обычном наследовании, однако, результат будет аналогичным.

Неожиданный порядок инициализации наследованных классов в JavaScript

del

Неожиданный порядок инициализации наследованных классов в JavaScript

Просто кто-то не знает как работает прототипное наследование. Не буду оригинальным — RFM.

RoadRunner: PHP не создан, чтобы умирать, или Golang спешит на помощь

Цитирую Badoo: Подход из статьи нам близок: при решении своих задач мы тоже чаще всего используем связку PHP и Go, получая преимущества от обоих языков и не отказываясь от одного в пользу другого.

RoadRunner: PHP не создан, чтобы умирать, или Golang спешит на помощь

Затем, что проект размера Badoo, большая часть которого написана на пхп, двумя пальцами на жаве не перепишешь. Это слишком дорогой. Кроме того, зачем ломать то, что работает? Ещё и штат новый набирать? А со старыми что делать?

Каких мы ищем разработчиков для разработки платформы 1С: Предприятие

Не оправдывая DSL, считаю, что основной проблемой платформы является ее монопольность. Если были бы другие интерпрайзные решения по бухгалтерии и складу, особенно опенсорс, то и 1С пришлось бы развиваться. А так… Зачем?

Задача по программированию о розничной торговле

Если честно, то хочется спросить — иии? Где пример реализации и прочий контент?

Цена рефакторинга

Ну так я и написал, что рефакторинг не столько про код-стайл. Однако автор поста кодстайл приравнял к рефаторингу, поэтому я и обратил внимание.

Не соглашусь с Вами по поводу переработки логики программы. Можно оптимизировать алгоритмы, переопределить классы, использовать паттерны, но если у вас на выходе должен быть массив данных определенного формата, то он де должен и остаться после реафкторинга.

Цена рефакторинга

Они влияют на читабельность кода. А читабельность кода влияет на скорость правок, дополнений и тд. Если в команде единый кодстайл, то каждому будет легче читать чужой код. В общем-то рефакторинг не только (и не столько) про «скобки по феншую».

Цена рефакторинга

Осознание цели, в любой ситуации, это необходимость. Однако не согласен, что рефакторинг нельзя оценить в попугаях. Банально — нечитаемый и неправильно спроектированный код увеличивает время разработки новых фич и модули и экспоненциально возрастает риск, что в один момент упадет все. Кроме того, экстренная реанимация также увеличивается во времени, т.к. надо сидеть и разбираться, чё тут написали.

Чтобы сократить эстетического приведения кода в порядок — линтеры. Их можно настроить как хуки, перед комитом/сейвом будет все форматироваться или ругаться. Для похапе (мб и для других) есть кодсниффер, который переоткрывает таск разрабу, который закомитил код не по стилю. Так что некоторые вещи при рефакторинге можно автоматизировать, а другие спасут вашу попу в случае "Мэй Дэй". Но по кодстайлу надо договориться на берегу, чтобы потом не было "так положено".

Классы и фабричные функции в JavaScript. Что выбрать?

Мне кажется тогда проще использовать прототипирование. Иначе какой-то дуализм выходит.

Честно говоря не совсем понимаю Крокфорда. Если в мире сложились стандарты и общие представления ООП для всех языков, то зачем в JS городить свои велосипеды и все усложнять? Основное преимуществ ООП, на мой дилетантский взгляд, легкость обслуживания приложения в дальнейшем. И если в JS ООП будет, как и везде, то жить станет легче.

Архитектура приложения Angular. Используем NgModules

Главное — не останавливаться :)

Ни в коем разе :)

Архитектура приложения Angular. Используем NgModules

Да, когда писал смотрел куда в другую сторону, поправил.

Я, честно говоря, не вижу в данном подходе какой-то сложности. По-моему это типичное решение аля синглтон. Мы имеем один экземпляр сервиса в приложении и в случае обращения нему — обращаемся к этому экземпляру или создаем новый, если он не был создан ранее. Если, конечно, мы не создаем сервис внутри директивы\компонента и т.д.

П.С. Прозвучит как оправдание, но это мой первый опыт перевода.

Docker, как показатель зрелости

Согласен. Тут вопрос в размере проекта.