Там главная причина была не в стоимости, а в том, что Airbas мог выпустить 320neo быстрее, а на доводку нового самолета нужны годы. А еще сертификация...
В марте штат Нью-Джерси запретил большинство типов строго безналичных магазинов. В феврале такой же закон приняла Филадельфия. Массачусетс еще с 1978 года запрещает любую «дискриминацию» против клиентов, использующих нал. Сан-Франциско, Чикаго, Вашингтон и Нью-Йорк собираются присоединиться в этом году.
Ха, вот такая вот рыночная экономика, лол. Казалось бы: если есть спрос на магазины с налом, то они не могут умереть. Чего тогда боится самая рыночная страна в мире?
Сдается мне, у них какие-то проблемы с лицензированием. Потому как есть совсем уж экзотические вещи, а Монга, которую сейчас пихают везде, где только можно — отсутствует
Известный факт – в Google сотрудники 20% рабочего времени могут тратить на побочные проекты. Смысл этого правила прост – так можно повысить продуктивность в остальные 80% рабочего времени.
Google отменила легендарное правило для своих сотрудников
Корреспондент.net, 19 августа 2013, 07:13
Знаменитое правило 20%, которое приводили в пример как эффективный подход к инновациям в Google, было отменено.
Задумайтесь: зачем мы тащим весь этот Docker раньше времени? Потому что считается, что в контейнере удобно и “Ну нормально же все было, работает. Чего ты начинаешь то?”.
Так вот, для таких людей я могу сказать — докер контейнеры это не панацея и не единственная среда, в которой может исполняться ваше приложение.
У нас случай был. Написали код, все тесты прошли, все хорошо. Закинули в CircleCI, а тесты там запускались в докере — и они упали. Начали разбираться и выяснили, что у разработчика и в докере установлены разные часовые пояса, а код это дело не учитывает. А так как прод работает на докере, то это была проблема, которую бы не заметили, если бы не прогон тестов в среде идентичной проду. Так что теперь у нас npm run docker:test стоит на prepush — во избежание
Я вблизи наблюдал несколько подобных конфликтов и всегда, повторяю, ВСЕГДА одна и сторон была женского пола.
В крупных неайтишных конторах и на госслужбе еще бывают ситуации, когда действующие лица таки оба мужики, но есть "болельщицы", которые принимают очень активное участие в "правильной мотивации" товарищей
В данной ситуации он не был начальником ОПа, а то так можно договориться до того, что Джанни — это техлид всея компании. Разные ситуации — разные подходы. Но ни при одном подходе не должно быть истерик и кафкианства.
Поверьте, вас просто не доводили фразами «исправь, это неправильно, я не понял, почему это работает» на вещи из стандарта
Ну да, мы тут с одними розовыми понями и единорогами общаемся. Было кучу раз. И ничего, справился. Просто в офисе нужно иметь нулевой уровень эмпатии, что, понятное дело, сложно для девушек. Не понял? Иди разбирайся. Не разобрался? Тогда что ты тут делаешь? Это не мое дело разъяснять тебе очевидные вещи. Есть история коммитов, есть ревью кода.
Или рекламой менее подходящего фреймворка от незнания более подходящего
Опять же — постоянно. Обычно на такое есть стандартный ответ: сколько нужно времени на интеграцию твоего нового фреймворка? X? Отлично — пили бранчу, рефакторь, но в свободное время, так как таски по основному коду с тебя никто не снимает. Потом сделаешь презентацию, докажешь, что показатели не ухудшились, добавились очевидные преимущества и мы на очередном архитектурном митинге рассмотрим твое предложение. Тут главное — не отказывать :)
Нет, не равны. С родительской веткой работает вся команда, а с фиче-веткой — только ее часть. Потому изменения родительсткой ветки затронут большее кол-во людей и именно поэтому нужно иметь фиче-ветки как можно более готовыми к мерджу.
разве не все конфликты уйдут ровно с тем же уровнем проблем, что и при ребейзе?
Конфликты уйдут, но зато добавится +1 коммит (и он не будет пустым, как при обычном merge --no-fast-forward), а потом еще +1 коммит. Если у вас мастер достаточно часто меняется, то просто за время работы над фичей в пару дней у вас может накопиться солидный ком из таких коммитов, которые по своей сути являются мусором
Если вы работаете в более-менее взрослом проекте, то у вас уже как минимум будет две параллельные ветки: master и develop. А если еще и gitflow применяется, так вообще еще hotfix и release добавляется.
Но даже с маленькими ветками возникает проблема: что делать, если в мастере появился новый коммит? Если вы будете мерджить ветку в мастер с решением конфликтов на месте, то у вас появляется новый неоттестированный коммит и состояние мастера автоматически становится непредсказуемым, даже если на самом деле ничего страшного не произошло.
Там главная причина была не в стоимости, а в том, что Airbas мог выпустить 320neo быстрее, а на доводку нового самолета нужны годы. А еще сертификация...
Если есть расстрел за коррупцию, значит есть и коррупция ;)
А как проверить, что тебе просрочку не сунули? Весь пакет пересматривать?
Ха, вот такая вот рыночная экономика, лол. Казалось бы: если есть спрос на магазины с налом, то они не могут умереть. Чего тогда боится самая рыночная страна в мире?
При этом "желание изучить этот язык" проистекает из денег и спроса на рынке труда
Сдается мне, у них какие-то проблемы с лицензированием. Потому как есть совсем уж экзотические вещи, а Монга, которую сейчас пихают везде, где только можно — отсутствует
Google отменила легендарное правило для своих сотрудников
Корреспондент.net, 19 августа 2013, 07:13
Знаменитое правило 20%, которое приводили в пример как эффективный подход к инновациям в Google, было отменено.
https://korrespondent.net/business/career/1593707-google-otmenila-legendarnoe-pravilo-dlya-svoih-sotrudnikov
У нас случай был. Написали код, все тесты прошли, все хорошо. Закинули в CircleCI, а тесты там запускались в докере — и они упали. Начали разбираться и выяснили, что у разработчика и в докере установлены разные часовые пояса, а код это дело не учитывает. А так как прод работает на докере, то это была проблема, которую бы не заметили, если бы не прогон тестов в среде идентичной проду. Так что теперь у нас npm run docker:test стоит на prepush — во избежание
CircleCI
В контейнерах
кешируется npm i через внутренний механизм кеширования CircleCI
Какие воркеры?
AWS ECR
Шо восьмидесятые, тут мэр европейской столицы считает, что 1/6 > 1/2...
В крупных неайтишных конторах и на госслужбе еще бывают ситуации, когда действующие лица таки оба мужики, но есть "болельщицы", которые принимают очень активное участие в "правильной мотивации" товарищей
… что, в свою очередь, будет вызывать еще большую ненависть, так как "ну что он не понимает, в чем он виноват? Или назло не исправляется??!!"
Рекурсия
В данной ситуации он не был начальником ОПа, а то так можно договориться до того, что Джанни — это техлид всея компании. Разные ситуации — разные подходы. Но ни при одном подходе не должно быть истерик и кафкианства.
Ну да, мы тут с одними розовыми понями и единорогами общаемся. Было кучу раз. И ничего, справился. Просто в офисе нужно иметь нулевой уровень эмпатии, что, понятное дело, сложно для девушек. Не понял? Иди разбирайся. Не разобрался? Тогда что ты тут делаешь? Это не мое дело разъяснять тебе очевидные вещи. Есть история коммитов, есть ревью кода.
Опять же — постоянно. Обычно на такое есть стандартный ответ: сколько нужно времени на интеграцию твоего нового фреймворка? X? Отлично — пили бранчу, рефакторь, но в свободное время, так как таски по основному коду с тебя никто не снимает. Потом сделаешь презентацию, докажешь, что показатели не ухудшились, добавились очевидные преимущества и мы на очередном архитектурном митинге рассмотрим твое предложение. Тут главное — не отказывать :)
Ну, справедливости ради, мы не слышали версию противоположной стороны.
Честно говоря, по тексту статьи и стилю изложения, у меня сложилось аналогичное мнение. Не то, чтобы истеричка, но стрессоустойчивость в районе нуля.
Нет, не равны. С родительской веткой работает вся команда, а с фиче-веткой — только ее часть. Потому изменения родительсткой ветки затронут большее кол-во людей и именно поэтому нужно иметь фиче-ветки как можно более готовыми к мерджу.
Конфликты уйдут, но зато добавится +1 коммит (и он не будет пустым, как при обычном merge --no-fast-forward), а потом еще +1 коммит. Если у вас мастер достаточно часто меняется, то просто за время работы над фичей в пару дней у вас может накопиться солидный ком из таких коммитов, которые по своей сути являются мусором
Если вы работаете в более-менее взрослом проекте, то у вас уже как минимум будет две параллельные ветки: master и develop. А если еще и gitflow применяется, так вообще еще hotfix и release добавляется.
Но даже с маленькими ветками возникает проблема: что делать, если в мастере появился новый коммит? Если вы будете мерджить ветку в мастер с решением конфликтов на месте, то у вас появляется новый неоттестированный коммит и состояние мастера автоматически становится непредсказуемым, даже если на самом деле ничего страшного не произошло.