если они хорошо платят, в том числе сверхурочные, то многим это подойдет.
2. Работа кажется простой, но они настаивают, что она будет сложной
Тут возможно вы просто переоцениваете глубину своих навыков в том или ином вопросе.
3. «Нам нужна рок-звезда!» (Или любое другое подобное слово, от которого уже тошнит).
Они предлагают соответствующую зарплату? почему бы и не поучавствовать в концерте?
4. «Нужно знать 10+ языков и все возможные инструменты»
зачастую это значит надо знать 1 язык хорошо и не боятся открыть код на 30 строчек на незнакомом языке.
5. Вы проходите только техническое собеседование
когда я был джуном - мое первое собеседование оказалось таки. Компания была сильно ниже среднего, однако че жаловаться когда ты джун?
6. Ваше собеседование похоже на викторину
прошел викторину - молодец, не прошел - просто подумай про человека плохо и забудь.
7. «Другие разработчики слишком заняты, чтобы присоединиться»
не сталкивался с такой ситуаций, но возможно бывает. Если компания не ай-ти, но в то же время предлагает нормально денег и есть понимание что придется чуть ли не одному все у них там поднимать и разруливать - почему бы и нет? Быть незаменимым для многих сильный мотиватор и такие компании более чем подходят.
8. Отсутствие видения, цели или разумных задач
Это становится весомым аргументом для разработчика далеко не сразу. На старте впринципе может быть все равно абы направление было то, что интересует.
9. Десятилетняя компания, которая все еще является «стартапом».
не важно, как они себя называют. Если ожидания совпадают с предложением - почему бы и нет?
10. Сотрудники со стеклянными глазами и без искры
Интервью во вторник в 11 или в пятницу в 16.00 - это не то же самое. Может у сотрудника до этого было 4 часа встреч и он немного устал. Глаза стеклянные но вопросы и темы интересные - может стоит подумать присоединиться?
Отличный пример как можно разосраться в команде еще на стадии проектирования, а через 5 месяцев когда продукт будет разваливаться - сказать "это все потому что вы ничего не понимаете".
Так то подобные вещи нужно обсудить внутри команды, если будет одобрение - тогда вперед. Если нет - ну можно попробовать в следующем проекте предложить.
Таких "хороших практик" десятки и сотни, но надо их не насаживать своим дутым авторитетом, а доказать примером что они полезны.
Автор пишет о 2006 годе, когда ему было 14, как о глубокой древности с мамонтами и одеждами из шкур. Обе приставки из статьи к тому времени уже даже не выпускались. Про тетрис я вообще молчу.
Это время мощных компьютеров на двухядерных процессорах. Некоторые даже с вистой на борту. ЖК экраны. Два года как вовчик вышел. Ну или первый релиз убунты те же 2 года назад, кто о чем.
Интернет? Он давно как был высокоскоростным.
А что с программированием? Про гейм дев не скажу, а вот Java 6 как раз зарелизилась в этом году. PHP уже получил свою новую объектную модель и был на пороге революционных изменений.
гайд как делать не надо, тем более в 2021 году. Запустить все тоже самое, только правильно можно несколькими командами и конфигами в том же докере. А так этим даже пользоваться невозможно из за не настроенных прав.
наверное по этому тема меня не зацепила по настоящему. А вот два или три года позже по настоящему зацепила одна тема, которую и вспоминать стыдно. К счастью родители сказали что я дэбил и не дали денег, а то бы закончилось как обычно.
зы. если моя карма поднимиться до -10 в течении месяца, то напишу не самую интересную про аналоги биткойна в 90-х
Спустя три недели после нападения сторонников Дональда Трампа на Капитолий американские спецслужбы установили личности 400 человек, причастных к этой акции. Об этом во вторник, 26 января, заявил исполняющий обязанности начальника вашингтонского бюро ФБР Стивен Д'Антуоно. По его словам, 130 человек уже задержаны.
Недавно видел статью что их все еще задерживают по немногу. Причем они сидят в ожидании суда, а не отпускают сразу. Выходя на несогласованный митинг нужно понимать что об ответственности.
сразу видна позиция программиста в крупной компании (может даже корпорации). Сверху сказали не использовать плюс в рассчетах — значит не использовать плюс в рассчетах.
Про DRY можно поспорить, но это скорее всего бессмыслено.
Что касается примера. Оба this в данном случае указывают на класс сервиса (даже не на экземпляр). JS гибкий язык, можно конечно вызвать метод с контекстом компонента (чего не было в примере выше), но это еще то извращение. Хотя внедрять api и vuex еще бОльшее извращение (но тут на любителя извращений)
Думаю использование mixin-ов — наиболее близкий путь к вашей идее если судить по имплементации. Хотя саму идею сервисов можно реализовать иначе. А делать как вы не стоит — оно или не будет работать или это будет ужасный код.
Не совсем понятно, чем <user :user=«user» /> отличается от предложенного решения.
соединение имени происходит внутри компонента. Это сразу дает следующие приемущества в сравнении с вашим примером — не надо использовать дополнительный класс и мапить в него, в будущем изменения можно вносить централизованно (например добавить линк на пользователей или добавить иконку / стили).
Какие именно проблемы с this вам встречались
Вы просто до конца реализуйте этот пример static delete (collage) {
// ЛОГИКА УДАЛЕНИЯ КОЛЛАЖА
}
<user :user="user" />
и не надо никаких классов и конвертаций. В конце концов компоненты для того и существуют.
ну и в глаза бросились статичные методы сервиса (а как же this из оригинала, что с ним делать). И getList который так то вернет promise и все сломается. Ну да еще мапить лучше без мутаций, ну да ладно, это мелочи
уже больше месяца сижу на альфе 21.04 из за нового компа. Поддержка zen 3 появилась в 5.10, к тому же в нужная версия поприетарного драйвера для мобильного GF RTX 3070 из коробки появилась только там же совсем недавно.
архитектор из первой истории к тому же дал правильное определение — костыль. Система таких костылей в долгосрочной перспективе превратиться в ад, а этому жалеть ресурсы сейчас совершенно не стоит, потом выйдет только дороже эти костыли почистить.
у вас слишком однобокое мнение об альтернативном мнение. Там западнее RT, Anna News и прочие — альтернативное мнение, которое подвергается прессингу, в том числе и со стороны ютуба.
Мексиканцы уже отказываются работать в США?
1. «Хаха, да, мы много работаем»
если они хорошо платят, в том числе сверхурочные, то многим это подойдет.
2. Работа кажется простой, но они настаивают, что она будет сложной
Тут возможно вы просто переоцениваете глубину своих навыков в том или ином вопросе.
3. «Нам нужна рок-звезда!» (Или любое другое подобное слово, от которого уже тошнит).
Они предлагают соответствующую зарплату? почему бы и не поучавствовать в концерте?
4. «Нужно знать 10+ языков и все возможные инструменты»
зачастую это значит надо знать 1 язык хорошо и не боятся открыть код на 30 строчек на незнакомом языке.
5. Вы проходите только техническое собеседование
когда я был джуном - мое первое собеседование оказалось таки. Компания была сильно ниже среднего, однако че жаловаться когда ты джун?
6. Ваше собеседование похоже на викторину
прошел викторину - молодец, не прошел - просто подумай про человека плохо и забудь.
7. «Другие разработчики слишком заняты, чтобы присоединиться»
не сталкивался с такой ситуаций, но возможно бывает. Если компания не ай-ти, но в то же время предлагает нормально денег и есть понимание что придется чуть ли не одному все у них там поднимать и разруливать - почему бы и нет? Быть незаменимым для многих сильный мотиватор и такие компании более чем подходят.
8. Отсутствие видения, цели или разумных задач
Это становится весомым аргументом для разработчика далеко не сразу. На старте впринципе может быть все равно абы направление было то, что интересует.
9. Десятилетняя компания, которая все еще является «стартапом».
не важно, как они себя называют. Если ожидания совпадают с предложением - почему бы и нет?
10. Сотрудники со стеклянными глазами и без искры
Интервью во вторник в 11 или в пятницу в 16.00 - это не то же самое. Может у сотрудника до этого было 4 часа встреч и он немного устал. Глаза стеклянные но вопросы и темы интересные - может стоит подумать присоединиться?
Отличный пример как можно разосраться в команде еще на стадии проектирования, а через 5 месяцев когда продукт будет разваливаться - сказать "это все потому что вы ничего не понимаете".
Так то подобные вещи нужно обсудить внутри команды, если будет одобрение - тогда вперед. Если нет - ну можно попробовать в следующем проекте предложить.
Таких "хороших практик" десятки и сотни, но надо их не насаживать своим дутым авторитетом, а доказать примером что они полезны.
А тем кто хочет камеру - они будут продавать чехол со встроенной камерой за отдельную сумму денег.
Автор пишет о 2006 годе, когда ему было 14, как о глубокой древности с мамонтами и одеждами из шкур. Обе приставки из статьи к тому времени уже даже не выпускались. Про тетрис я вообще молчу.
Это время мощных компьютеров на двухядерных процессорах. Некоторые даже с вистой на борту. ЖК экраны. Два года как вовчик вышел. Ну или первый релиз убунты те же 2 года назад, кто о чем.
Интернет? Он давно как был высокоскоростным.
А что с программированием? Про гейм дев не скажу, а вот Java 6 как раз зарелизилась в этом году. PHP уже получил свою новую объектную модель и был на пороге революционных изменений.
гайд как делать не надо, тем более в 2021 году. Запустить все тоже самое, только правильно можно несколькими командами и конфигами в том же докере. А так этим даже пользоваться невозможно из за не настроенных прав.
наверное по этому тема меня не зацепила по настоящему. А вот два или три года позже по настоящему зацепила одна тема, которую и вспоминать стыдно. К счастью родители сказали что я дэбил и не дали денег, а то бы закончилось как обычно.
зы. если моя карма поднимиться до -10 в течении месяца, то напишу не самую интересную про аналоги биткойна в 90-х
Отличная возможность добавить себе проблем в жизни.
Недавно видел статью что их все еще задерживают по немногу. Причем они сидят в ожидании суда, а не отпускают сразу. Выходя на несогласованный митинг нужно понимать что об ответственности.
Дело было так, пришел новый chief architect в компанию и сказал «У нас на прошлой работе плюсов небыло». Ну все и завертелось.
Что касается примера. Оба this в данном случае указывают на класс сервиса (даже не на экземпляр). JS гибкий язык, можно конечно вызвать метод с контекстом компонента (чего не было в примере выше), но это еще то извращение. Хотя внедрять api и vuex еще бОльшее извращение (но тут на любителя извращений)
Думаю использование mixin-ов — наиболее близкий путь к вашей идее если судить по имплементации. Хотя саму идею сервисов можно реализовать иначе. А делать как вы не стоит — оно или не будет работать или это будет ужасный код.
соединение имени происходит внутри компонента. Это сразу дает следующие приемущества в сравнении с вашим примером — не надо использовать дополнительный класс и мапить в него, в будущем изменения можно вносить централизованно (например добавить линк на пользователей или добавить иконку / стили).
Вы просто до конца реализуйте этот пример
static delete (collage) {// ЛОГИКА УДАЛЕНИЯ КОЛЛАЖА
}
<user :user="user" />и не надо никаких классов и конвертаций. В конце концов компоненты для того и существуют.
ну и в глаза бросились статичные методы сервиса (а как же this из оригинала, что с ним делать). И getList который так то вернет promise и все сломается. Ну да еще мапить лучше без мутаций, ну да ладно, это мелочи
Это такая фишка писать простыни кода с сомнительным форматированием и комментариями?
Код по ссылке новичок не осилит тем более.