То есть сервис должен быть ориентирован на организаторов, автоматизировать какую-то рутину. Участникам туда ходить я не понял зачем, например бот должен в чат напоминать или выдавать голосовалку на следующее мероприятие.
И почти все рассказывали похожую историю
Не читал весь цикл статей, но вы сами подобные мероприятия организовывали? Откуда пришла идея какие проблемы нужно решать и как?
В остальном как говорится печаль, но истина. Хороший код и красивый интерфейс ещё не гарантия успеха, какой-то простенький кривенький инструмент для решения даже небольшой проблемы может легко найти своих пользователей. И кажется желательно на старте иметь 1 конкретную понятную функцию, а не комбайн в котором надо разобраться. Например "бот публикует голосовалку в чате сообщества за неделю до игры, за 2 дня до игры рассылает напоминание каждому кто отметился и выводит организатору ответы кто подтвердил кто не сможет".
Благодаря всем этим движениям по дайверсити и тд даже с парализованными ногами можно занимать горным велосипедом. Например Мартин сломал спину, но сейчас продолжает кататься на специальном е-мтб трайке https://ru.wikipedia.org/wiki/Эштон,_Мартин Из российских паралимпийцев например "без рук и ног" https://ru.wikipedia.org/wiki/Асташов,_Михаил_Евгеньевич Да и так на одном форуме есть человечек потерявший ногу в ДТП начал кататься, на контактных педалях это делать проще.
Точных цифр у меня тоже нет, так что вероятно вы и правы и инвалидов-велосипедистов действительно меньше (смотря как считать).
Да, вероятно я не правильно понял доводы "почему руководитель лезет в разработку". Или неправильно понимаю термин "душнила". Проблема в моих неправильных ожиданиях, начало мне понравилось, приведена хорошая методика для структуризации мыслей и идей с понятным примером. Жаль конечно если действительно программисты аргументируют условный рефакторинг просто "потому что мне не нравится как написано" а не хотя бы минимальным "облегчит дальнейшую поддержку и заодно тестами покрою чтобы снизить время на смоук тесты".
Так хорошо начиналось со STAR а потом в каждом пункте ни одного обоснования зачем это нужно кроме "оптимизировали на 30%". Особенно мне было бы интересно услышать какой результат ожидается от внедрения ИИ, бизнес же хочет сокращения издержек или роста прибыли, так? Просто "мы стали генерить больше шаблонного кода" не сильно обрадует финансового директора?
Должен признать у автора есть узнаваемый стиль подачи новостей. Абсолютно бессмысленный текст начиная с заголовка. Впрочем и новость в итоге не соотвествует заголовку ("репозитории опенсорца не справляются" => "реестры пакетов ищут способ монетизации") и заканчивается ещё каким-нибудь притянутым фактом.
То есть вы в итоге смогли сформировать рабочий DoR. Это здорово когда скрам начинает действительно работать, а не просто отнимать время на ритуалы никому ненужные.
Угол отражения равен углу падения, угол пирамидок расчитан так что сигнал отражается в соседнюю пирамидку и так многократно, а не обратно в камеру. Как пирамидки в катафоте, только с обратной задачей.
Что за отдельные MVP в отдельном подразделении RnD? То есть можно за 2 дня. только не будем считать 4 месяца которые потратило подразделение RnD на согласование, исследование и тестирование на стейджинге? Или выкидываем критерии 2 и 3 которые указаны в начале статьи?
Анализ какой-то будет кроме слова в в подзаголовках? И насколько понимаю после того как гугл объявили что смогли оптимизировать потребление памяти, опенАИ отменили предзаказ "на всю память на годы вперёд" https://habr.com/ru/companies/ru_mts/articles/1019720/
Да, взрослеть это не статья с красивыми эпитетами про борьбу жабы с гадюкой, а описание с конкретными примерами и сложностями. Пусть даже это будет серия статей по каждому из пунктов выше, какие трудности для каких сценариев были с ХМРР пример кода замеры трафика и тд. Почему выбран самый неудобный дизайн телеграма, а не предыдущий "как у всех". Как организована борьба за УИН какие варианты были опробованы и почему не сработали. Мне было бы интересно читать реальные примеры с объяснением выбора какие преимущества какие недостатки. И довольно странно выглядят просьбы оценить архитектуру и прочее когда нет никакого описания этой самой архитектуры и "за код стыдно" хотя насколько я вижу код клиента даже не минифицирован и доступен только инспектор открой.
Насколько я понимаю, GPL не обязывает публиковать код "большого продукта" просто обязаны предоставить этот код пользователю (клиенту, покупателю) вместе с правом его изменять как ему угодно. И бонусом для вашего случая есть отдельная лицензия для библиотек https://ru.wikipedia.org/wiki/GNU_Lesser_General_Public_License
Понятное дело что можно по-разному считать чтобы получить разные результаты. Вот в статье привели пример расчёта налоговой нагрузки работника без жены и детей (и видимо без недвижимости и личного транспорта) который тратит всю зарплату на товары. И насколько тут вообще уместно считать отчисления работадателя в фонды соц страхования? Тем более было указано что есть штаты без НДС, и таже ставка налогов в России на имущество разная по регионам.
там на каждый коммит нужен тикет, чтобы его начать, да code review, да прогон тестов (который может занимать массу времени)
У вас запрещено разработчикам заводить баги (об опечатках) чтобы ИДишники не закончились? В большой корпорации не работал, но не вижу проблемы завести тикет на небольшое исправление и сделать отдельный коммит и ПР чтобы и тесткейсы поправили, если там проверяется текст с опечаткой и может быть в документации пользователя обновили скриншоты. Да и если другой багфикс откатят то эти небольшие изменения останутся. А тесты обычно в пайплайнах гоняются автоматические смоук и ночные подробные. Делать небольшие правки "паровозиком" зло, пару раз сам так делал, потом отдельно копируешь эти исправления потому что фича не пошла в релиз, а опечатки поправить оказалось норм идеей.
Вы можете взять даже процессор 5-летней давности, и он спокойно потянет едва ли не любую видеокарту.
Сразу зацепило и стало понятно что статья будет интересная! Я конечно ничего не понял, но вроде бы после подзаголовков следует подробное объяснение почему "миф" это правда. Допускаю что местами есть некоторые неточности, например про контроллер памяти и звуковой чип на материнках. Насколько понимаю контроллер памяти давно уже в процессор встраивают, начали АМД а тепер и интел также делают, про звук тоже хорошо, особенно интересно его вляние на звук в блютуз наушниках.
Тут неправильное имя или всё остальное? https://vibemuvik.ru/person/1074
Спасибо вам за вклад в ОСМ! По Карелии кататься здорово и для навигатора органик.мапс использую, да и у гармина карты на основе ОСМ.
То есть сервис должен быть ориентирован на организаторов, автоматизировать какую-то рутину. Участникам туда ходить я не понял зачем, например бот должен в чат напоминать или выдавать голосовалку на следующее мероприятие.
Не читал весь цикл статей, но вы сами подобные мероприятия организовывали? Откуда пришла идея какие проблемы нужно решать и как?
В остальном как говорится печаль, но истина. Хороший код и красивый интерфейс ещё не гарантия успеха, какой-то простенький кривенький инструмент для решения даже небольшой проблемы может легко найти своих пользователей. И кажется желательно на старте иметь 1 конкретную понятную функцию, а не комбайн в котором надо разобраться. Например "бот публикует голосовалку в чате сообщества за неделю до игры, за 2 дня до игры рассылает напоминание каждому кто отметился и выводит организатору ответы кто подтвердил кто не сможет".
Хорошая шутка, но позвольте подушнить.
Благодаря всем этим движениям по дайверсити и тд даже с парализованными ногами можно занимать горным велосипедом. Например Мартин сломал спину, но сейчас продолжает кататься на специальном е-мтб трайке https://ru.wikipedia.org/wiki/Эштон,_Мартин Из российских паралимпийцев например "без рук и ног" https://ru.wikipedia.org/wiki/Асташов,_Михаил_Евгеньевич Да и так на одном форуме есть человечек потерявший ногу в ДТП начал кататься, на контактных педалях это делать проще.
Точных цифр у меня тоже нет, так что вероятно вы и правы и инвалидов-велосипедистов действительно меньше (смотря как считать).
Интересное заявление. И что именно они оттуда тянут и зачем? Картография это их основная специализация, судя по иписанию.
Да, вероятно я не правильно понял доводы "почему руководитель лезет в разработку". Или неправильно понимаю термин "душнила". Проблема в моих неправильных ожиданиях, начало мне понравилось, приведена хорошая методика для структуризации мыслей и идей с понятным примером. Жаль конечно если действительно программисты аргументируют условный рефакторинг просто "потому что мне не нравится как написано" а не хотя бы минимальным "облегчит дальнейшую поддержку и заодно тестами покрою чтобы снизить время на смоук тесты".
Так хорошо начиналось со STAR а потом в каждом пункте ни одного обоснования зачем это нужно кроме "оптимизировали на 30%". Особенно мне было бы интересно услышать какой результат ожидается от внедрения ИИ, бизнес же хочет сокращения издержек или роста прибыли, так? Просто "мы стали генерить больше шаблонного кода" не сильно обрадует финансового директора?
Должен признать у автора есть узнаваемый стиль подачи новостей. Абсолютно бессмысленный текст начиная с заголовка. Впрочем и новость в итоге не соотвествует заголовку ("репозитории опенсорца не справляются" => "реестры пакетов ищут способ монетизации") и заканчивается ещё каким-нибудь притянутым фактом.
То есть вы в итоге смогли сформировать рабочий DoR. Это здорово когда скрам начинает действительно работать, а не просто отнимать время на ритуалы никому ненужные.
Угол отражения равен углу падения, угол пирамидок расчитан так что сигнал отражается в соседнюю пирамидку и так многократно, а не обратно в камеру. Как пирамидки в катафоте, только с обратной задачей.
Что за отдельные MVP в отдельном подразделении RnD? То есть можно за 2 дня. только не будем считать 4 месяца которые потратило подразделение RnD на согласование, исследование и тестирование на стейджинге? Или выкидываем критерии 2 и 3 которые указаны в начале статьи?
Анализ какой-то будет кроме слова в в подзаголовках? И насколько понимаю после того как гугл объявили что смогли оптимизировать потребление памяти, опенАИ отменили предзаказ "на всю память на годы вперёд" https://habr.com/ru/companies/ru_mts/articles/1019720/
Да, взрослеть это не статья с красивыми эпитетами про борьбу жабы с гадюкой, а описание с конкретными примерами и сложностями. Пусть даже это будет серия статей по каждому из пунктов выше, какие трудности для каких сценариев были с ХМРР пример кода замеры трафика и тд. Почему выбран самый неудобный дизайн телеграма, а не предыдущий "как у всех". Как организована борьба за УИН какие варианты были опробованы и почему не сработали. Мне было бы интересно читать реальные примеры с объяснением выбора какие преимущества какие недостатки. И довольно странно выглядят просьбы оценить архитектуру и прочее когда нет никакого описания этой самой архитектуры и "за код стыдно" хотя насколько я вижу код клиента даже не минифицирован и доступен только инспектор открой.
На тему как автор умудряется выкроить время на хобби. Полезно будет если вы автор и сможете применить некоторые идеи в своей жизни.
Насколько я понимаю, GPL не обязывает публиковать код "большого продукта" просто обязаны предоставить этот код пользователю (клиенту, покупателю) вместе с правом его изменять как ему угодно. И бонусом для вашего случая есть отдельная лицензия для библиотек https://ru.wikipedia.org/wiki/GNU_Lesser_General_Public_License
Какую реальность вы хотите высчитать?
Понятное дело что можно по-разному считать чтобы получить разные результаты. Вот в статье привели пример расчёта налоговой нагрузки работника без жены и детей (и видимо без недвижимости и личного транспорта) который тратит всю зарплату на товары. И насколько тут вообще уместно считать отчисления работадателя в фонды соц страхования? Тем более было указано что есть штаты без НДС, и таже ставка налогов в России на имущество разная по регионам.
У вас запрещено разработчикам заводить баги (об опечатках) чтобы ИДишники не закончились? В большой корпорации не работал, но не вижу проблемы завести тикет на небольшое исправление и сделать отдельный коммит и ПР чтобы и тесткейсы поправили, если там проверяется текст с опечаткой и может быть в документации пользователя обновили скриншоты. Да и если другой багфикс откатят то эти небольшие изменения останутся. А тесты обычно в пайплайнах гоняются автоматические смоук и ночные подробные. Делать небольшие правки "паровозиком" зло, пару раз сам так делал, потом отдельно копируешь эти исправления потому что фича не пошла в релиз, а опечатки поправить оказалось норм идеей.
Вот этот вот навык?
Чтобы разобраться в таблице коэффициентов видимо надо открыть не изменения, а сам закон, в частности шапку где столбцы расписаны https://www.consultant.ru/document/cons_doc_LAW_156832/fa680b07af423adb3a41d702b10b38386564470d/ В целом ничего сложного, "до 3 лет" и "старше 3 лет" + с какой даты будет актуален какой коэффициент.
Сразу зацепило и стало понятно что статья будет интересная! Я конечно ничего не понял, но вроде бы после подзаголовков следует подробное объяснение почему "миф" это правда. Допускаю что местами есть некоторые неточности, например про контроллер памяти и звуковой чип на материнках. Насколько понимаю контроллер памяти давно уже в процессор встраивают, начали АМД а тепер и интел также делают, про звук тоже хорошо, особенно интересно его вляние на звук в блютуз наушниках.