Нужно ставить весь стак компонентов и приложений локально?
Не обязательно. Разрабатывать можно как тебе удобно. Докер даёт возможность запустить приложение в конфигурации "как в продакшене". Для запуска нескольких связанных контейнеров используют Docker Compose
Насколько проблематично поддерживать контейнеры в актуальной версии?
Такая ситуация мне не понятна. Как можно понять, что код работает, если он не протестирован? На мой взгляд, писать код без тестов — это просто не профессионально.
Трудности — это не только личностный рост. Это, например, получение обратной связи после запуска проекта. Понимание, сработали ли подходы, работа над ошибками.
Мой опыт взаимодействия с поддержкой Тинькофф Банка.
За границей мне нужно было снять с карточки деньги, а ПИН код я забыл. Написал в чат из приложения, мне перезвонили и помогли сбросить ПИН.
Карта перестала читаться, а мне нужно на следующий день ехать в другой город. Звоню через приложение, объясняю ситуацию. Утром следующего дня в другом городе ко мне приезжает курьер с новой картой.
Какой вообще смысл в т.н. NoSQL? Это все равно, что в mysql будет 2 поля: первичный ключ и каша из данных. Выборка по первичному ключу и вставки, так как больше нету индексов, должны летать. :)
Или я в чем-то ошибаюсь?
У разных NoSQL БД есть свои особенности, которых может не быть в SQL базах данных. Например, в Redis есть тип данных сортированное множество (sorted set, zset), позволяющий решать специфичные задачи (например, кэширование) или HyperLogLog — вероятностная структура данных, потребляющая фиксированное количество памяти для подсчёта количества уникальных элементов.
Не нужно думать о NoSQL как о чём-то, что нужно использовать вместо SQL баз данных. Их можно использовать вместе.
Кроме того, сознательно занижение точности оценки (например, не бывает задач которые можно сделать быстрее чем за день), в итоге позволяет скомпенсировать переоценки/недооценки.
Не нужно ничего прописывать — смысл в том, чтобы давать грубую оценку и постоянно сравнивать эту оценку с результатом. Через некоторое время появляется навык давать достаточно точные оценки без анализа мелочей.
Чтобы хорошо оценивать сроки, нужно постоянно тренироваться это делать. То есть перед началом каждой задачи или спринта, нужно потратить минимум времени на то, чтобы понять о чём задача и оценить сколько времени на неё потребуется. Очень важно записать свои оценки.
После выполнения задачи, нужно сравнить оценку с реальным временем выполнения и проанализировать с чем была связана неверная оценка. При подходе к следующей задаче учесть свои наблюдения.
При этом не нужно стремиться оценить задачу с точностью до минуты. Я предпочитаю оценивать задачи с гранулярностью в четыре часа.
Если регулярно так делать, то через месяц-два таких упражнений, можно научиться давать точные оценки сроков.
Не расскажите немного о победителе? Какой он сделал вклад в развитие технологий и развитие сообщества руби?
Не обязательно. Разрабатывать можно как тебе удобно. Докер даёт возможность запустить приложение в конфигурации "как в продакшене". Для запуска нескольких связанных контейнеров используют Docker Compose
Не проблематично, если деплой выглядит так:
[1, 2, 3].reverse.each_with_indexиarray.each_with_index.select { |number, index| index < 10 }!numbers.dup.uniq!— не знаю откуда ты эту срань скопировал. Но на руби этот код должен выглядеть такnumbers.length == numbers.uniq.lengthИзбавление от астигматизма дорогого стоит. Я больше не ищу на ощупь очки, еще не открыв утром глаза.
Не обязательно обманывать работодателя. Можно выкладывать в опен сорс, код представляющий ценность, но не являющийся know how компании.
Мой любимый метод там https://github.com/mperham/sidekiq/blob/5de3ef43535148e304c07f80f479d68213c0d20b/lib/sidekiq.rb#L31
Такая ситуация мне не понятна. Как можно понять, что код работает, если он не протестирован? На мой взгляд, писать код без тестов — это просто не профессионально.
Трудности — это не только личностный рост. Это, например, получение обратной связи после запуска проекта. Понимание, сработали ли подходы, работа над ошибками.
Мой опыт взаимодействия с поддержкой Тинькофф Банка.
За границей мне нужно было снять с карточки деньги, а ПИН код я забыл. Написал в чат из приложения, мне перезвонили и помогли сбросить ПИН.
У разных NoSQL БД есть свои особенности, которых может не быть в SQL базах данных. Например, в Redis есть тип данных сортированное множество (sorted set, zset), позволяющий решать специфичные задачи (например, кэширование) или HyperLogLog — вероятностная структура данных, потребляющая фиксированное количество памяти для подсчёта количества уникальных элементов.
Не нужно думать о NoSQL как о чём-то, что нужно использовать вместо SQL баз данных. Их можно использовать вместе.
Из каких шагов состоит деплой RoR и PHP приложений?
Кроме того, сознательно занижение точности оценки (например, не бывает задач которые можно сделать быстрее чем за день), в итоге позволяет скомпенсировать переоценки/недооценки.
Не нужно ничего прописывать — смысл в том, чтобы давать грубую оценку и постоянно сравнивать эту оценку с результатом. Через некоторое время появляется навык давать достаточно точные оценки без анализа мелочей.
Думаю, стоит отметить, что я говорю о не долгосрочной перспективе — планирование на несколько недель.
Разработчик
Нет, такая методика приводит к тому, что посмотрев на задачу я могу довольно точно оценить, сколько времени на неё нужно, даже не вникая в детали.
Чтобы научиться принимать правильные решения, нужно принять много неправильных решений. В обзщем-то так и происходит обучение.
Чтобы хорошо оценивать сроки, нужно постоянно тренироваться это делать. То есть перед началом каждой задачи или спринта, нужно потратить минимум времени на то, чтобы понять о чём задача и оценить сколько времени на неё потребуется. Очень важно записать свои оценки.
После выполнения задачи, нужно сравнить оценку с реальным временем выполнения и проанализировать с чем была связана неверная оценка. При подходе к следующей задаче учесть свои наблюдения.
При этом не нужно стремиться оценить задачу с точностью до минуты. Я предпочитаю оценивать задачи с гранулярностью в четыре часа.
Если регулярно так делать, то через месяц-два таких упражнений, можно научиться давать точные оценки сроков.