Тумблер
Тумблер используется для выбора одного значения из перечисленных. Аналогичен Переключателю, но с некоторыми особенностями. Подробнее - в карточках.
Больше в Дизайн гайде по 1С
#Design
Тумблер используется для выбора одного значения из перечисленных. Аналогичен Переключателю, но с некоторыми особенностями. Подробнее - в карточках.
Больше в Дизайн гайде по 1С
#Design
👍40🔥9❤2
Попробовать новый интерфейс 8.5
Вот здесь можно попробовать новый интерфейс в вебе (ничего устанавливать не нужно) -
https://platform.demo.1c.ru/demo85
Инфописьмо про 8.5 - №32567 от 25.12.2024
Платформа на релизес - 8.5.1.189
Обратите внимание, что есть приложенная демонстрационная конфигурация
Лендинг - 1С:Предприятие 8.5: новый дизайн
Вот здесь можно попробовать новый интерфейс в вебе (ничего устанавливать не нужно) -
https://platform.demo.1c.ru/demo85
Инфописьмо про 8.5 - №32567 от 25.12.2024
Платформа на релизес - 8.5.1.189
Обратите внимание, что есть приложенная демонстрационная конфигурация
Лендинг - 1С:Предприятие 8.5: новый дизайн
👍18🔥9🍾3👏2🤮1
Деньги - ничего не значат
- Богатые люди -
Внешность - ничего не значит
- Красивые люди -
Предупреждения - ничего не значат
- Программисты -
😁26🔥5👍2
Загадка
Вам, как техлиду, нужно перенести на следующий спринт Критичную ошибку, Джуна и Релиз.
За раз можно тащить только одного.
При этом:
- Критичную ошибку и Релиз нельзя оставлять вместе - Релиз упадет из-за Критичной ошибки
- Джуна и Релиз тоже нельзя оставлять вместе - Джун поломает Релиз
Ваши действия?
Решение:
1️⃣ Берем релиз и переводим в новый спринт. Джун с Критичной ошибкой занимается, ничего страшного не происходит
2️⃣ Возвращаемся и берем с собой Джуна. Тащим его в новый спринт
3️⃣ Откатываем Релиз обратно, так как нельзя Джуна наедине с Релизом оставлять - разломает
4️⃣ Дальше перевешиваем Ошибку на следующий спринт, чтобы она не разломала текущий Релиз
5️⃣ Возвращаемся и в одного тянем Релиз..
6️⃣ Выгораем…
Вам, как техлиду, нужно перенести на следующий спринт Критичную ошибку, Джуна и Релиз.
За раз можно тащить только одного.
При этом:
- Критичную ошибку и Релиз нельзя оставлять вместе - Релиз упадет из-за Критичной ошибки
- Джуна и Релиз тоже нельзя оставлять вместе - Джун поломает Релиз
Ваши действия?
Решение:
2️⃣ Возвращаемся и берем с собой Джуна. Тащим его в новый спринт
3️⃣ Откатываем Релиз обратно, так как нельзя Джуна наедине с Релизом оставлять - разломает
4️⃣ Дальше перевешиваем Ошибку на следующий спринт, чтобы она не разломала текущий Релиз
5️⃣ Возвращаемся и в одного тянем Релиз..
6️⃣ Выгораем…
😁40👍15🔥6🤣4👌2
С Наступающим Новым 2025 годом
🎄💻 С Новым годом, друзья!
Пусть в 2025-м:
✨ ваши проекты взлетают с первого раза,
🐛 ошибки устраняются быстрее, чем появляются,
⚡️ дедлайны не настигают,
📈 а жизнь обновляется до версии “Успех 2.1”!
С Новым годом, новым кодом, новым счастьем и бесконечным количеством радостных проектов! 🎉🥳
P.S. Писать на каникулах не буду, чтобы не отвлекать Вас от салатов и своих домашних проектов
У самого тоже Грандиозные планы :)
🎄💻 С Новым годом, друзья!
Пусть в 2025-м:
✨ ваши проекты взлетают с первого раза,
🐛 ошибки устраняются быстрее, чем появляются,
⚡️ дедлайны не настигают,
📈 а жизнь обновляется до версии “Успех 2.1”!
С Новым годом, новым кодом, новым счастьем и бесконечным количеством радостных проектов! 🎉🥳
P.S. Писать на каникулах не буду, чтобы не отвлекать Вас от салатов и своих домашних проектов
У самого тоже Грандиозные планы :)
🍾24🎉16🎄10❤3👍2🔥1
Ближайшие планы
Всем привет!
Надеюсь Вы шикарно отдохнули и набрались сил!
Считаю отдых одним из самых важных составляющих успешной работы. Это, кстати, отдельное искусство - правильно отдыхать. Выходить из длительного отдыха стоит плавно, чтобы не сжечь в первые дни все свои накопленные силы
Чтобы Вас не нагружать, сегодня коротко поделюсь своими планами на ближайшее время:
📆 4-5 февраля - Конференция Новые информационные технологии в образовании
Готовлю два выступления и вернисаж по 1С:Бухгалтерия некоммерческой организации
📆 24-25 февраля - Конференция Infostart Teamlead & CIO Event
Готовлю выступление по AI-агентам для проверки кода
📆 1-2 марта - Конференция Весенний семинар партнеров 1С в Космосе
Готовлю выступление и вернисаж по 1С:Бухгалтерия предприятия и 1С:Бухгалтерия некоммерческой организации
📆 Февраль - Бесплатный вебинар по разработке на developer.1c.ru
Точная дата не анонсирована. Подробности позже
📆 Февраль - Преподавание в МФТИ
Пригласили попробовать себя в роли преподавателя. Это что-то новое и от того очень интересное!
🔜 Серия статей по этапам разработки проекта
🏝️ В отпуске до 24 января
Это приятная новость для меня, а для Вас уже подготовлены посты
Всем желаю приятной и продуктивной недели!
Потихоньку вкатываемся в 2025 год
Всем привет!
Надеюсь Вы шикарно отдохнули и набрались сил!
Считаю отдых одним из самых важных составляющих успешной работы. Это, кстати, отдельное искусство - правильно отдыхать. Выходить из длительного отдыха стоит плавно, чтобы не сжечь в первые дни все свои накопленные силы
Чтобы Вас не нагружать, сегодня коротко поделюсь своими планами на ближайшее время:
📆 4-5 февраля - Конференция Новые информационные технологии в образовании
Готовлю два выступления и вернисаж по 1С:Бухгалтерия некоммерческой организации
📆 24-25 февраля - Конференция Infostart Teamlead & CIO Event
Готовлю выступление по AI-агентам для проверки кода
📆 1-2 марта - Конференция Весенний семинар партнеров 1С в Космосе
Готовлю выступление и вернисаж по 1С:Бухгалтерия предприятия и 1С:Бухгалтерия некоммерческой организации
📆 Февраль - Бесплатный вебинар по разработке на developer.1c.ru
Точная дата не анонсирована. Подробности позже
📆 Февраль - Преподавание в МФТИ
Пригласили попробовать себя в роли преподавателя. Это что-то новое и от того очень интересное!
🔜 Серия статей по этапам разработки проекта
🏝️ В отпуске до 24 января
Это приятная новость для меня, а для Вас уже подготовлены посты
Всем желаю приятной и продуктивной недели!
Потихоньку вкатываемся в 2025 год
👍19🔥10⚡1
Культурные особенности обратной связи
В 2018 году мы делали проект по интеграции 1С:БизнесСтарт с amoCRM и рассказывали о нем на amoCONF в Олимпийском.
В процессе подготовки к выступлению познакомились с Михаилом Токовиным (сооснователь amoCRM). От него узнал много фишек для выступлений: вопросы, паузы, телесуфлер, хлопальщики и так далее.
И он поделился наблюдением по поводу обратной связи в разных культурах. Михаил обратил внимание, что русские всегда стараются найти что-то плохое, что можно улучшить в проекте и очень охотно этим делятся.
Например, просишь дать обратную связь по началу работы и получаешь вот такую обратную связь от наших:
А вот американцы - наоборот, говорят только хорошее. Из них практически невозможно вытянуть что-то плохое:
Чтобы получить конструктив нужно потратить силы и время на расспросы.
Вот такие культурные особенности обратной связи :)
Здесь писал как правильно давать обратную связь, а здесь как работать с негативной обратной связью.
P. S. Вот тут само видео про интеграцию. Выступает Олег Фогель, но если присмотреться к экрану, то в правом верхнем углу - я
Никита Арипов | 1C. Подписаться
В 2018 году мы делали проект по интеграции 1С:БизнесСтарт с amoCRM и рассказывали о нем на amoCONF в Олимпийском.
В процессе подготовки к выступлению познакомились с Михаилом Токовиным (сооснователь amoCRM). От него узнал много фишек для выступлений: вопросы, паузы, телесуфлер, хлопальщики и так далее.
И он поделился наблюдением по поводу обратной связи в разных культурах. Михаил обратил внимание, что русские всегда стараются найти что-то плохое, что можно улучшить в проекте и очень охотно этим делятся.
Например, просишь дать обратную связь по началу работы и получаешь вот такую обратную связь от наших:
У Вас плохо сделана начальная страница, я не смог с первого раза зарегистрироваться. Еще поля не очень выровнены, стоит их подровнять. Можно еще цвет фона поменять и подсказку добавить
А вот американцы - наоборот, говорят только хорошее. Из них практически невозможно вытянуть что-то плохое:
- Как Вам начало работы?
- Нам все понравилось, все сделано супер круто! Вау!
- А удалось зарегистрироваться?
- Да, конечно!
- С первого раза удалось?
- Нет, только с четвертого, но все равно все потрясающе
Чтобы получить конструктив нужно потратить силы и время на расспросы.
Вот такие культурные особенности обратной связи :)
Здесь писал как правильно давать обратную связь, а здесь как работать с негативной обратной связью.
P. S. Вот тут само видео про интеграцию. Выступает Олег Фогель, но если присмотреться к экрану, то в правом верхнем углу - я
Никита Арипов | 1C. Подписаться
👍14😁6🔥2❤1🤯1
Этапы проекта
Я рассказывал о том, как у нас двигаются задачи от идеи до релиза. Если раньше я описывал это скорее с точки зрения технологий, то сейчас посмотрим на процесс в целом.
📝 Любая задача состоит из:
1. Проговаривание задачи
Убеждаемся, что одинаково понимаем проблему, которую хотим решить
2. Согласование требований
Договариваемся, какими новыми качествами будет обладать программа после реализации проекта
3. Обсуждение идеи
Смотрим, как такие задачи решали другие, обдумываем, как примерно решать эту задачу
4. Выработка проектных решений
Выбираем конкретный подход для решения задачи
5. Проработка интерфейса
Придумываем, как будет выглядеть наше решение, чтобы оно было удобным и понятным
6. Обсуждение архитектурных решений
Прорабатываем, как это все будет работать с точки зрения метаданных и существующих решений
7. Согласование готового решения
Проверяем, что получилось то, что мы задумывали и ничего не упустили
8. Проведение код-ревью
Смотрим, понятный и хороший ли код
9. Тестирование
Проверяем, что не осталось ошибок и непродуманного поведения
10. Выпуск в релизе
Выпускаем наше решение в правильном релизе
🌀 Движемся слева направо, но иногда можем и откатиться назад, если столкнулись с проблемами, чтобы их обойти новым путем
🔍 Каждый этап имеет свои особенности и ключевые точки. В следующих постах рассмотрим каждый этап отдельно, а в конце соберем большую статью!
// Если интересно, то прожмите реакции, пожалуйста
#Процесс #Разработка
Никита Арипов | 1C. Подписаться
Я рассказывал о том, как у нас двигаются задачи от идеи до релиза. Если раньше я описывал это скорее с точки зрения технологий, то сейчас посмотрим на процесс в целом.
📝 Любая задача состоит из:
1. Проговаривание задачи
Убеждаемся, что одинаково понимаем проблему, которую хотим решить
2. Согласование требований
Договариваемся, какими новыми качествами будет обладать программа после реализации проекта
3. Обсуждение идеи
Смотрим, как такие задачи решали другие, обдумываем, как примерно решать эту задачу
4. Выработка проектных решений
Выбираем конкретный подход для решения задачи
5. Проработка интерфейса
Придумываем, как будет выглядеть наше решение, чтобы оно было удобным и понятным
6. Обсуждение архитектурных решений
Прорабатываем, как это все будет работать с точки зрения метаданных и существующих решений
7. Согласование готового решения
Проверяем, что получилось то, что мы задумывали и ничего не упустили
8. Проведение код-ревью
Смотрим, понятный и хороший ли код
9. Тестирование
Проверяем, что не осталось ошибок и непродуманного поведения
10. Выпуск в релизе
Выпускаем наше решение в правильном релизе
🌀 Движемся слева направо, но иногда можем и откатиться назад, если столкнулись с проблемами, чтобы их обойти новым путем
🔍 Каждый этап имеет свои особенности и ключевые точки. В следующих постах рассмотрим каждый этап отдельно, а в конце соберем большую статью!
// Если интересно, то прожмите реакции, пожалуйста
#Процесс #Разработка
Никита Арипов | 1C. Подписаться
👍78💯18🔥15❤2
Проговаривание задачи
Представьте, что задача звучит как «улучшить проведение документов» или «развить отчеты руководителю». От такой постановки задачи разработчик может быть в ступоре: «Что конкретно делать? Куда копать?»
Поэтому самый первый, самый простой и самый важный этап работы над проектом - это проговаривание задачи.
🔍 Что это?
5-10 минутный созвон тимлида, разработчика и ответственного за продукт.
Цель: объединить понимание задачи и наметить план решения.
Например, «Развитие отчетов руководителю» после проговаривания может трансформироваться в «Добавить быстрые настройки (оформление, округление, варианты) в общую форму отчетов руководителя».
Причем этот этап полезен даже если задача сформулирована понятно - «Указывать основание финансирование в документе Расход материалов». На встрече можно подсказать куда посмотреть и к кому обратиться за помощью, чтобы сделать быстрее.
❓ Какие вопросы задать?
Чтобы встреча прошла продуктивно во первых стараемся жестко держать тайминг, а во-вторых не превращаем созвон в проектное совещание. Поэтому основные вопросы могут быть такие:
1️⃣ Какую проблему решаем? («Руководители тратят 2 часа на настройку отчетов»)
2️⃣ Что должно получится в конце? («Быстрые настройки для оформления отчета»)
3️⃣Для каких объектов или документов? («Давай начнем с Продаж и Задолженности по контрагентам»)
4️⃣ Какие ограничения? («Стандартные отчеты не трогаем»)
5️⃣ Есть ли какие-то идеи? («Хвалят как сделано в УНФ»)
Таким образом, разработчик на следующий этап «Согласование требований» уже приходит с пониманием что делать и куда копать. А значит может сформулировать четкие требования к программе и донести их до заинтересованных лиц.
💣 Что будет, если пропустить этап?
Представим, что разработчику выдали задачу «Улучшение проведения документов» и проговаривания не было.
Обычно следующие действия такие:
▫️Самостоятельно исследуем контекст - что сейчас не так с документами?
▫️Ищем конкретику - в каких документах и что улучшать?
▫️Выясняем, кто может подсказать - может быть кто-то решал подобную задачу?
Добавим еще деталей. В описании задачи еще есть «Перевести торговые документы на новый режим проведения».
Появляются новые вопросы:
— Что это за новый режим проведения?
— Кто его сделал и как с ним работать?
— Делаем для всех торговых документах (даже для комиссии?) или только для частотных?
Хорошо, если разработчик знает к кому обратиться с этими вопросами.
А если нет?
📌 Лучше потратить 10 минут на старте, чем 10 часов на переделки.
💡 Итог
Проговаривание задачи - это «рытье канала с двух сторон»:
👉 Разработчик задает свои вопросы
👉 Тимлид и ответственный за продукт добавляют деталей
Итог: все на одной волне, а требования согласовываются в разы быстрее.
#Процесс #Разработка
Никита Арипов | 1C. Подписаться
Представьте, что задача звучит как «улучшить проведение документов» или «развить отчеты руководителю». От такой постановки задачи разработчик может быть в ступоре: «Что конкретно делать? Куда копать?»
Поэтому самый первый, самый простой и самый важный этап работы над проектом - это проговаривание задачи.
🔍 Что это?
5-10 минутный созвон тимлида, разработчика и ответственного за продукт.
Цель: объединить понимание задачи и наметить план решения.
Например, «Развитие отчетов руководителю» после проговаривания может трансформироваться в «Добавить быстрые настройки (оформление, округление, варианты) в общую форму отчетов руководителя».
Причем этот этап полезен даже если задача сформулирована понятно - «Указывать основание финансирование в документе Расход материалов». На встрече можно подсказать куда посмотреть и к кому обратиться за помощью, чтобы сделать быстрее.
❓ Какие вопросы задать?
Чтобы встреча прошла продуктивно во первых стараемся жестко держать тайминг, а во-вторых не превращаем созвон в проектное совещание. Поэтому основные вопросы могут быть такие:
1️⃣ Какую проблему решаем? («Руководители тратят 2 часа на настройку отчетов»)
2️⃣ Что должно получится в конце? («Быстрые настройки для оформления отчета»)
3️⃣Для каких объектов или документов? («Давай начнем с Продаж и Задолженности по контрагентам»)
4️⃣ Какие ограничения? («Стандартные отчеты не трогаем»)
5️⃣ Есть ли какие-то идеи? («Хвалят как сделано в УНФ»)
Таким образом, разработчик на следующий этап «Согласование требований» уже приходит с пониманием что делать и куда копать. А значит может сформулировать четкие требования к программе и донести их до заинтересованных лиц.
💣 Что будет, если пропустить этап?
Представим, что разработчику выдали задачу «Улучшение проведения документов» и проговаривания не было.
Обычно следующие действия такие:
▫️Самостоятельно исследуем контекст - что сейчас не так с документами?
▫️Ищем конкретику - в каких документах и что улучшать?
▫️Выясняем, кто может подсказать - может быть кто-то решал подобную задачу?
Добавим еще деталей. В описании задачи еще есть «Перевести торговые документы на новый режим проведения».
Появляются новые вопросы:
— Что это за новый режим проведения?
— Кто его сделал и как с ним работать?
— Делаем для всех торговых документах (даже для комиссии?) или только для частотных?
Хорошо, если разработчик знает к кому обратиться с этими вопросами.
А если нет?
📌 Лучше потратить 10 минут на старте, чем 10 часов на переделки.
💡 Итог
Проговаривание задачи - это «рытье канала с двух сторон»:
👉 Разработчик задает свои вопросы
👉 Тимлид и ответственный за продукт добавляют деталей
Итог: все на одной волне, а требования согласовываются в разы быстрее.
#Процесс #Разработка
Никита Арипов | 1C. Подписаться
👍30🔥11💯3