Всё хорошо, но как только дело доходит до дебага, пиши пропало… И это не «болячка» React-а, это родовая травма JS. Все носятся с этим React-ом как с писаной торбой. А мне не понравилось… Ни React на фронте, ни React Native в мобилках. Наверное, я — не модный динозавр, но мне важен простой дебаг и качественный деплой. И чтоб команде не приходилось делать вывих мозга с этими Вашими Сагами и Редаксами.
Я признаю что я мал и глуп, и не видал, чего там взрослые видали, но я верю, что и в нашей стране можно всё, и ЗП, и задачи, и прорывы. Ждать помощи от государства не стоит (это вообще нонсенс). Нужно работать, чаще задавать вопрос себе «А не херню ли я делаю?», и добиваться от заказчиков ответа на вопрос «Зачем?».
Если «удалёнка» — сама цель, ничего не выйдет. Если цель — стать разработчиком, то путь автора показывает одну из возможностей, «удалёнка» в его случае вынужденная необходимость, т.к. в месте пребывания нет подходящего работодателя. Мы все были когда-то «джунами», и все прекрасно понимаем, что для того, чтобы выйти из этого «состояния» (или войти в него?) надо работать, работать и ещё раз работать. А пока работаешь — учиться, учиться и ещё раз учиться, как завещал дедушка Ленин. По-другому никак, это закон природы, навык надо развивать и тренировать.
Мне тут приходилось объяснять заказчику почему задача сохранения времени пользователя на сервере и построение отчетности в сервисе, расчитаным на весь мир, может занять много времени. А потом ещё разработчикам объяснять, почему мы будем хранить время в UTC, со сдвигом пользователя от UTC. Все (и заказчик, и разработчики) были в смятении, и смотрели на меня как на сказочника. Покажу им эту статью. Это я еще про летнее/зимнее время забыл, блин… Спасибо, что напомнили.
Посмею сделать небольшое замечание, по поводу автовайринга ApplicationContext-а в фабрику. Это, как заверяют евангелисты, признак плохого тона. Не должен отдельный компонент знать про весь контекст. Думаю фабрику можно переписать иначе:
@SuppressWarnings("unchecked")
@Component
public class RequestBuildersFactoryImpl implements RequestBuildersFactory {
@Setter(onMethod = @__(@Autowired))
private List<RequestBuilder> builders;
public <T extends Transfer> BaseRequest<T> transferToRequest(T transfer) {
ResolvableType type = ResolvableType.forClassWithGenerics(RequestBuilder.class, transfer.getClass());
RequestBuilder<T> builder = builders.stream().filter(b -> type::isInstance).findFirst().get();
return builder.createRequest(transfer, stage);
}
}
В части получения билдера из списка могут быть варианты, но основной посыл надеюсь понятен.
По поводу вопроса «Что мы делаем?». Позволю себе не согласиться с Вами. На этот вопрос, как раз таки, есть ответ всегда. Мы пишем код, создаем продукт, удовлетворяем заказчика. Мне кажется, что главный вопрос, все-таки — «Зачем?». Зачем мы это делаем и кому это нужно? Приведенная Вам цель Google, как раз отвечает на вопрос «Зачем?». И только если каждый член команды, сотрудник компании может четко ответить на этот вопрос, только тогда можно говорить, что мы на правильном пути. И это никак не кореллирует со структурой компании или ее методологией управления.
Правильно ли я понимаю, что если структура документа источника, либо назначения поменяется, то придется править код? Если так, то не такой уж и универсальный конвертер получается… Вот если бы пользователь мог загрузить файл-источник, и затем смаппить его на файл-назначение, то универсальность была бы выше. Не пробовали решать такую задачу?
А я Вам скажу, что пошло не так со Scrum-ом.
Никто толком не разобрался в нем, прочитали buzzword-ы — спринты, покер, ретроспективы, демо, и начали лепить как умеем. Народ в панике, еще вчера все работали по плану индивидуальному, а сегодня пришло руководство и объявило «всеконторский Agile». Оценивать никто не умеет, в сроки не укладываются, спринты факапятся, заказчик злится.
«Ну чот не поперло», решило руководство, и придумало новую мульку, вернее откатилось к старой. И проходит некоторое время, а воз и ныне там. Оценивать никто не научился. «Долги» после Agile-а остались. После нескольких пожаров, и тушение их баблом, нормальные разработчики, болевшие душою за проект «сгорели» и решили уйти. А они с самого начала пытались донести до власть имущих позицию по разработке.
Проект вошел в фазу вялотекущего допиливания, докостыливани того, что уже утекло на продакшен. Заказчик немного ворчит, но уже потратил на Вас сотни нефти и искать новых исполнителей ему лень. Поэтому бабки есть и направление в общем на плаву. И нафига там кому-то напрягаться.
Вот так и делается Agile. Хотя, кто мешает поискать информацию, поискать людей знающих, почитать рекомендации, продумать план внедрения, и по-тихоньку претворять в жизнь, сначала в отдельно взятой команде, а затем и во всей конторе.
История является моим сугубо оценочным суждением, все совпадения случайны.
А расскажите, пожалуйста, как там обстоят дела с интернетом, связью? Сколько стоит и какие характеристики? Просто наслышан, что в Европе, да и в США, очень дорого стоит мобильный интернет, а на домашних тарифах нет безлимитных планов.
Спасибо.
Это все может работать нормально только при грамотно организованной инфраструктуре развертывания (оно же DevOps). Если собрать Ваше приложение из отдельно взятой ветки репозитория для Вас проблема, то такой подход к разработке может быть не про Вас.
Скажите, а bugfix у Вас по такому же flow идет? Т.е. обнаружили баг, сделали ветку, поправили, оттестировали сборку из этой ветки, потом влили в основную ветку, оттестировали там на регрессию и в продакшен?
Лично у меня только одна претензия к JS — дебажить его то еще удовольствие. И если на клиентской части у тебя есть DevTools браузера, то на сервере такой радости нет. И только по-этому я с опаской посматриваю на JS в качестве back-end инструмента.
Я не против свободы, но как показывает практика, разработчику лучше ехать по «рельсам». Набрать команду хотя бы из 5 адекватных разработчиков, которые будут делать «все правильно» очень не просто.
Ну и «миллионы мух не могут ошибаться — что-то в этом есть»…
Буквально неделю назад обновилось до Android Wear 2.0. До них пользовался Pebble Steel. Все устраивает, работают как часы. Циферблатов на любой вкус полно. Жаль Google Assistant не умеет в великий и могучий. По поводу NFC согласен, было бы не плохо.
Это хорошо.
И такой еще момент интересует: возможна ли в данный момент, или может планируется поддержка в будущем, обработка компилятором Kotlin compile интсрументирования, происходящего в Java, после компиляции Kotlin? Конкретная проблема это lombok. По возможности классы конвертируются в Kotlin, но не всегда есть такая возможность, и приходится добавлять в Java классы getter-ы и setter-ы, например, руками, если они вызываются в Kotlin файлах.
Если Вам не хватает ЗП, обсудите этот вопрос с руководством. У меня было так. Подошел к руководителю, объяснил все как есть без прекрас. Он меня понял, вопрос с бабками был решен на тот момент и я смог дальше работать, не парясь о денежном вопросе. Стартап я открыть не могу, но на хлеб с маслом и немного откладывать хватает.
А если работодатель откажется, то может стоит задуматься о смене работодателя?
И да, почему камень в огород программистов только? А инженеры, разработавшие подобные дизельные двигатели? Давайте тогда еще рабочих на конвеере упрекнем за то, что устанавливают такие двигатели?
В общем тамошние СМИ ничем не отличаются от наших, скандалы, интриги, расследования…
В части получения билдера из списка могут быть варианты, но основной посыл надеюсь понятен.
Никто толком не разобрался в нем, прочитали buzzword-ы — спринты, покер, ретроспективы, демо, и начали лепить как умеем. Народ в панике, еще вчера все работали по плану индивидуальному, а сегодня пришло руководство и объявило «всеконторский Agile». Оценивать никто не умеет, в сроки не укладываются, спринты факапятся, заказчик злится.
«Ну чот не поперло», решило руководство, и придумало новую мульку, вернее откатилось к старой. И проходит некоторое время, а воз и ныне там. Оценивать никто не научился. «Долги» после Agile-а остались. После нескольких пожаров, и тушение их баблом, нормальные разработчики, болевшие душою за проект «сгорели» и решили уйти. А они с самого начала пытались донести до власть имущих позицию по разработке.
Проект вошел в фазу вялотекущего допиливания, докостыливани того, что уже утекло на продакшен. Заказчик немного ворчит, но уже потратил на Вас сотни нефти и искать новых исполнителей ему лень. Поэтому бабки есть и направление в общем на плаву. И нафига там кому-то напрягаться.
Вот так и делается Agile. Хотя, кто мешает поискать информацию, поискать людей знающих, почитать рекомендации, продумать план внедрения, и по-тихоньку претворять в жизнь, сначала в отдельно взятой команде, а затем и во всей конторе.
История является моим сугубо оценочным суждением, все совпадения случайны.
Спасибо.
Скажите, а bugfix у Вас по такому же flow идет? Т.е. обнаружили баг, сделали ветку, поправили, оттестировали сборку из этой ветки, потом влили в основную ветку, оттестировали там на регрессию и в продакшен?
Спасибо за статью.
Я не против свободы, но как показывает практика, разработчику лучше ехать по «рельсам». Набрать команду хотя бы из 5 адекватных разработчиков, которые будут делать «все правильно» очень не просто.
Ну и «миллионы мух не могут ошибаться — что-то в этом есть»…
Буквально неделю назад обновилось до Android Wear 2.0. До них пользовался Pebble Steel. Все устраивает, работают как часы. Циферблатов на любой вкус полно. Жаль Google Assistant не умеет в великий и могучий. По поводу NFC согласен, было бы не плохо.
И такой еще момент интересует: возможна ли в данный момент, или может планируется поддержка в будущем, обработка компилятором Kotlin compile интсрументирования, происходящего в Java, после компиляции Kotlin? Конкретная проблема это lombok. По возможности классы конвертируются в Kotlin, но не всегда есть такая возможность, и приходится добавлять в Java классы getter-ы и setter-ы, например, руками, если они вызываются в Kotlin файлах.
А если работодатель откажется, то может стоит задуматься о смене работодателя?
И да, почему камень в огород программистов только? А инженеры, разработавшие подобные дизельные двигатели? Давайте тогда еще рабочих на конвеере упрекнем за то, что устанавливают такие двигатели?
В общем тамошние СМИ ничем не отличаются от наших, скандалы, интриги, расследования…