Хорошее замечание. Если активити падает в процессе работы, но мы уже что-то в бд сохранили, то при повторном запуске активити можем дубль сохранить. Допишу позже в статью, спасибо
По моему опыту ничего такого на собесе не было. Может у вас какой-то уникальный опыт?
У меня было несколько крутых собесов, когда ведущий все круто вел:
В первом случае минут 40 болтали про текущий проспект и его архитектурные решения + вопросы теоретические связанные с этим. В общем, не было тупых вопросов из воздуха, большинство по практике.
Во втором случае собес состоял не из теоритических вопросов, а вопросов на подумать - почему выбрали какой-то подход в библиотеке или фреймворке.
Вместо развития экспертизы в написании кода вы предлагаете развивать экспертизу в бизнесе. Не беда, что код станет из говна и палок.
Контакт с бизнесом и пользователями - очень удобно, когда разработка, поддержка и колл центр в одном флаконе.
Коммуникация с пользователями - это маркетинг.
Какая несусветная чушь. Если вы готовы платить за такого спеца 1.5+ млн, то ок. А за +50к к ЗП это ж насколько нужно быть отбитым, чтобы такое предлагать.
сделать метро у газа эффективным можно только если напротив газа застроить хорошими жилыми кварталами. Но этож сколько денег нужно... Зато метро у дома будет)
В этой архитектуре есть один существенный изъян: при большой нагрузке авто вакуум будет сильно ресурсов кушать. Лучше модернизировать архитектуру так: добавляем интерфейс, в дефолтной реализации которого удаляем по одному, а при необходимости пользователь библиотеке переопределит этот интерфейс с использованием партиционирования
Про bases - плюсую. В рабочем хранилище использую их. С dataview прям видно, как прогружаются при открытии заметки. Про синк через телефон интересная идея. а как это настраивается в самой программе. Есть фильтр на папки или только новые / обновленные файлы? Много примеров bases у тебя? В моих заметках не сильно много их
У меня личная база синкается через syncthing. В целом все гуд, но есть пара нюансов: если синкаешь сразу 3 и более устройств, то где-то могут перезаписаться обновления. В таком случае создается конфликтующая заметка и ты не потеряешь записи.
Рабочую базу я не синкаю и пользуюсь ей только на рабочем ноуте.
Таск трекер я синкаю через гит просто руками. Есть плагин и можно это настроить автоматически.
Я не понял статью, на мой взгляд большинство проблем просто высосаны из пальца:
что нет единой ценности — никто не понимает, что делать
Это вообще не связано с таск трекером. Не беда, если какая-то инфа лежит на конфлюенсе. Человек умрет что-ли, если в конфлюенс перейдет?
сталкиваются со сложностями приоритезации и определения, что правда важно;
а что статус задачи уже убрали из джиры? blocker, critical, normal...
сталкиваются с проблемами при синхронизации нескольких команд;
А чем менеджер занимается, который управляет этими командами? Почему нельзя просто завести один эпик и в него кинуть 3 разных задачи? В джире же можно на одной дочке поддоски создавать. Тут мб можно поспорить, но мне кажется тоже высосано из пальца.
Вообще не понял, зачем эта статья. Можно же генерить сваггер автоматически на основе контроллеров в коде - таким образом будет всегда актуальная версия и не нужно это руками делать. Пользуйтесь) Для более продвинутых существует api first подход. Только тсс, никому не говорите
Соглашусь с человеком выше, статья похожа на сгенерированную нейросеткой.
В самых первых абзацах уже что-то странное:
Коммуникация упрощается - нифига! Межкомандная коммуникация намного хуже внутрикомандной. Автор никогда не работал в большой бюрократической компании. Бывает такое, чтобы заставить все работать нужно несколько раз созвониться и все проговаривать.
Тестировать как раз намного проще: у тебя есть контракты сервисов и просто описываешь в тесте все варианты.
Плохо если много связей - это не микросервисы, а распределённый монолит. Ну настолько непонимание - это жесть.
Версионирование - тут тоже особо проблем нет. Как люди версионируют библиотеки? Тот же спринг: сначала помечают depricated, потом удаляют в следующей мажорной версии. Так же и в версии апи: поддерживаешь старую и новую какое-то время, потом старую удаляешь.
Статья очень сомнительная. Зачем ровнять между собой TS и Java. Для фронта это все может быть и актуально, а я посмотрю, как вы напишете бэк на java без фреймворка. Нет ничего плохого, что мы привязываемся к фреймворку. Не на сервлетах голых же писать? Рынок бэка на джава - это 90% spring, оставшиеся проценты - это микронавт, кваркус, кора. Мигрировать с одного на другое все равно не будет в большом проекте. Поэтому ничего плохого в этом нет.
Далее, если вы юниты не пишете, это не значит, что их никто не пишет. У меня был проект только из интеграционных тестов (95%). Так вот все тесты проходили за 20-25 минут. Очень эффективно.
В некоторых тезисах описание слишком абстрактное, не хватает примеров, из-за этого вообще сложно согласиться или не согласиться с тезисом.
Привлекла аватарка Сатору Годжо) Мне повезло войти в java, немногим позже после ковида и тогда я первую работу нашел за еду. Эх, сейчас джуны получают в 3-4 раза больше, а наиболее удачливые залетают на мидла на первую работу. Нужно резюме грамотно составлять, и по сути быть способным подтвердить навыки, указанные в резюме
Хорошее замечание. Если активити падает в процессе работы, но мы уже что-то в бд сохранили, то при повторном запуске активити можем дубль сохранить. Допишу позже в статью, спасибо
что-то введение не заметил, а где такая комбинация может понадобиться?
По моему опыту ничего такого на собесе не было. Может у вас какой-то уникальный опыт?
У меня было несколько крутых собесов, когда ведущий все круто вел:
В первом случае минут 40 болтали про текущий проспект и его архитектурные решения + вопросы теоретические связанные с этим. В общем, не было тупых вопросов из воздуха, большинство по практике.
Во втором случае собес состоял не из теоритических вопросов, а вопросов на подумать - почему выбрали какой-то подход в библиотеке или фреймворке.
Вообще непонятно о чем статья:
Какие продукты вы продаете другим кампаниям
Почему рост в 3 раза не астрономический, с каких показателей росли
Что вообще лента может предложить для it?
Вы лучше скажите, почему на хх у эйчара только один из вариантов по опыту:
Без опыта
1-3 года
4-6 лет
Более 6 лет
Почему hr не может сам задавать границу или выбирать несколько вариантов?
Подытожим статью:
Вместо развития экспертизы в написании кода вы предлагаете развивать экспертизу в бизнесе. Не беда, что код станет из говна и палок.
Контакт с бизнесом и пользователями - очень удобно, когда разработка, поддержка и колл центр в одном флаконе.
Коммуникация с пользователями - это маркетинг.
Какая несусветная чушь. Если вы готовы платить за такого спеца 1.5+ млн, то ок. А за +50к к ЗП это ж насколько нужно быть отбитым, чтобы такое предлагать.
сделать метро у газа эффективным можно только если напротив газа застроить хорошими жилыми кварталами. Но этож сколько денег нужно... Зато метро у дома будет)
В этой архитектуре есть один существенный изъян: при большой нагрузке авто вакуум будет сильно ресурсов кушать. Лучше модернизировать архитектуру так: добавляем интерфейс, в дефолтной реализации которого удаляем по одному, а при необходимости пользователь библиотеке переопределит этот интерфейс с использованием партиционирования
Про bases - плюсую. В рабочем хранилище использую их. С dataview прям видно, как прогружаются при открытии заметки.
Про синк через телефон интересная идея. а как это настраивается в самой программе. Есть фильтр на папки или только новые / обновленные файлы?
Много примеров bases у тебя? В моих заметках не сильно много их
У меня личная база синкается через syncthing. В целом все гуд, но есть пара нюансов:
если синкаешь сразу 3 и более устройств, то где-то могут перезаписаться обновления. В таком случае создается конфликтующая заметка и ты не потеряешь записи.
Рабочую базу я не синкаю и пользуюсь ей только на рабочем ноуте.
Таск трекер я синкаю через гит просто руками. Есть плагин и можно это настроить автоматически.
мощное резюме)
Кто-то реально вставляет в резюме айтишника курсы бариста? На кого этот кринж рассчитан?
Я не понял статью, на мой взгляд большинство проблем просто высосаны из пальца:
Это вообще не связано с таск трекером. Не беда, если какая-то инфа лежит на конфлюенсе. Человек умрет что-ли, если в конфлюенс перейдет?
а что статус задачи уже убрали из джиры? blocker, critical, normal...
А чем менеджер занимается, который управляет этими командами? Почему нельзя просто завести один эпик и в него кинуть 3 разных задачи? В джире же можно на одной дочке поддоски создавать. Тут мб можно поспорить, но мне кажется тоже высосано из пальца.
Вообще не понял, зачем эта статья. Можно же генерить сваггер автоматически на основе контроллеров в коде - таким образом будет всегда актуальная версия и не нужно это руками делать. Пользуйтесь) Для более продвинутых существует api first подход. Только тсс, никому не говорите
Мне нужно было написать статью про тестирование для онбординга ребят в нашей компании, мне ИИ почти такую же статью сгенерил :)
Соглашусь с человеком выше, статья похожа на сгенерированную нейросеткой.
В самых первых абзацах уже что-то странное:
Коммуникация упрощается - нифига! Межкомандная коммуникация намного хуже внутрикомандной. Автор никогда не работал в большой бюрократической компании. Бывает такое, чтобы заставить все работать нужно несколько раз созвониться и все проговаривать.
Тестировать как раз намного проще: у тебя есть контракты сервисов и просто описываешь в тесте все варианты.
Плохо если много связей - это не микросервисы, а распределённый монолит. Ну настолько непонимание - это жесть.
Версионирование - тут тоже особо проблем нет. Как люди версионируют библиотеки? Тот же спринг: сначала помечают depricated, потом удаляют в следующей мажорной версии. Так же и в версии апи: поддерживаешь старую и новую какое-то время, потом старую удаляешь.
И это я ещё только начал ...
А что конкретно не так? Можно примеры с деталями
Статья очень сомнительная. Зачем ровнять между собой TS и Java. Для фронта это все может быть и актуально, а я посмотрю, как вы напишете бэк на java без фреймворка. Нет ничего плохого, что мы привязываемся к фреймворку. Не на сервлетах голых же писать? Рынок бэка на джава - это 90% spring, оставшиеся проценты - это микронавт, кваркус, кора. Мигрировать с одного на другое все равно не будет в большом проекте. Поэтому ничего плохого в этом нет.
Далее, если вы юниты не пишете, это не значит, что их никто не пишет. У меня был проект только из интеграционных тестов (95%). Так вот все тесты проходили за 20-25 минут. Очень эффективно.
В некоторых тезисах описание слишком абстрактное, не хватает примеров, из-за этого вообще сложно согласиться или не согласиться с тезисом.
Мне кажется, что в этой статье не хватает информации про сам temporal. Ну или хотя бы ссылки на другие статьи, где это самому можно почитать
Привлекла аватарка Сатору Годжо) Мне повезло войти в java, немногим позже после ковида и тогда я первую работу нашел за еду. Эх, сейчас джуны получают в 3-4 раза больше, а наиболее удачливые залетают на мидла на первую работу. Нужно резюме грамотно составлять, и по сути быть способным подтвердить навыки, указанные в резюме