Почему ваш репозиторий не взлетел

07.07.24

Разработка - Групповая разработка (Git, хранилище)

О проблемах новых 1С-проектов в общем океане открытого программного обеспечения.

Эта статья - мое абсолютно субъективное мнение с прицелом на людей, которые уже сейчас занимаются или близки к тому, чтобы начать заниматься своими open-source проектами в сфере 1С. Оно может показаться вам неправильным или неоправданно назидательным. Я это понимаю - возражения в комментариях приветствуются

Open-source медленно, но верно входит в повседневную жизнь 1С-сообщества. И это здорово! Специфика у него, конечно, как обычно, своя: обработки на Инфостарт это тоже некоторого рода Open-source, и вот они-то уже точно в обиходе очень давно, но мы поговорим про другой вид открытого кода - более классический, основанный на репозиториях, распределенной разработке и свободных лицензиях. Т.е. о том, что обычно под этим понятием подразумевается

Обладая статистикой OpenYellow и желтым поясом по Консоли запросов УФ 8.3.7.1., могу поделиться следующей информацией: В 2024 году в 1С-сообществе на Github

  • Появилось 86 новых репозиториев (>=1 звезды)
  • Активно обновляется 330 репозиториев (>=1 звезды)
  • Всего существует 1781 репозиторий (>=1 звезды)

Это не очень много, но они есть и, как отмечено выше, это репозитории >=1 звезды. Получить 1 звезду это не какое-то убердостижение: в конце концов ее можно поставить себе самому, но выходит так, что подавляющее большинство репозиториев не имеют даже ее, а те, которые имеют, в большинстве своем на ней и заканчиваются. Когда-то я уже анализировал состояние "желтого" Github и там была  вот такая статистика:

Сделаем простой запрос с отбором по языку

 

https://api.github.com/search/repositories?q=language:"1C+Enterprise"

 

И получим ответ: 3367 репозитория. Ну, можно сказать, что они есть. Однако едва ли нас сможет заинтересовать каждый из этих проектов. Предлагаю исключить из выборки те, которые собрали к текущему моменту меньше 5 звезд

 

https://api.github.com/search/repositories?q=stars:>=5+language:"1C+Enterprise"

 

Это был отбор только по языку, в статистике OpenYellow же собираются данные про все репозитории, так или иначе связанные с 1С, вне зависимости от языка. К чему я веду? К тому, что ситуация такова: репозитории есть, но о большинстве из них никто не знает и они не собирают ни поддержки, ни обратной связи. От чего скоропостижно и загибаются

 

Немного про звезды

 

"Чего ты докопался до этих звезд, ты что - астроном?" 

Действительно, нужно обозначить значимость показателя, на который я опираюсь и поговорить о мотивационной составляющей занятия открытыми проектами в целом

Звезда на Github (также как и на Gitlab), в практическом понимании, это закладка - подписка пользователя на получение новостей о вашем репозитории в дальнейшем, в частности о новых релизах. Из этого, в свою очередь, напрямую выходит другое, более человечное понимание: количество звезд - это количество людей, которые заинтересованы в вашем проекте

Шило в мешке не утаишь: материальных благ подобные проекты не приносят, а следовательно мотивация держится только на этом - "Мой проект полезен и это здорово". В дальнейшем это может перерасти и в коллективную разработку, когда разрабатывается проект, объемы которого не по силам одному человеку, может перерасти и в буст карьеры - но когда мы говорим про старт, речи о таком, на мой взгляд, идти не может. В любом случае:

 

Звезды есть, значит проект кому-то понравился и пригодился = Мотивация растет

Звезд нет, значит проект никому не нужен = Мотивация падает

 

Это, в целом, довольно интуитивно: на Инфостарте есть плюсы, на Хабре есть карма, а у уличного музыканта есть аплодисменты. И ожидать, что кто-то будет делать нечто за просто так, да еще и без "Спасибо", довольно странно - дело не в звездах и не в карме, но в том, что они собой олицетворяют

 

Почему репозитории не находят пользователей?

 

Из прошлого пункта могло показаться, что я качу бочку на сообщество: мол вы не поддерживаете, вот и не растет. Да, так и есть, до свидания. Нет, на самом деле, огромная часть проблемы находится на стороне разработчиков - это вопрос оформления и продвижения своих разработок

 

 

Когда находишь на Github свежие проекты, снова и снова, невольно складывается впечатление, что большинство разработчиков видят себе ведение репозитория примерно вот так ->

 

Кто-то даже может сказать, что это правильно: большая часть трудозатрат уходит на код, а не на "всякую фигню". Главное же, чтобы софт был хороший, а пользователь, восхищенный задумкой и реализацией, сам должен искать пути, чтобы заполучить столь ценный продукт. Так вот - Нет!

 

 

Есть ли в целом право на жизнь у разработки по такой схеме? Вы знаете, да, такое возможно в двух случаях:

  • Если вы не хотите, чтобы вашим кодом кто-то пользовался и готовы добиваться этого любой ценой но бесплатно
  • Если вы Линус Торвальдс и настолько могучи, что даже имея описание из txt-файла на 300 символов, способны собрать на своем Linux Kernel 150 тыс. +

Если вы кто-то из этих людей, то данная статья не для вас. Я же по умолчанию буду опираться на то, что речь идет о создании проект с нуля и с большой заинтересованностью в его распространении. 1Сный Github - это дикая земля, но благодатная почва, готовая поддержать ваш труд, если приложить к этому достаточно рациональных усилий

 

Что есть ведение репозитория?

 

Первое, что надо понять, если вы решили вести свой проект

 

Посредственный проект, будучи правильно обставленным и обоснованным, станет в сто раз успешнее идеального продукта, разработчик которого так и не удосужился нормально объяснить, кому и зачем он нужен

 

Можно считать это неправильным, нехорошим или несправедливым - особенно часто встречается аргумент вроде "Я что бесплатно раздаю, чтобы потом еще и пользователей самому искать?". Это ничего не меняет. Создание проекта это даже не в половину про сам исходный код продукта и с этим ничего не поделаешь. Для наглядности, по моему субъективному мнению, правильная диаграмма распределения трудозатрат должна выглядеть примерно вот так ->

 

Если по пунктам:
 

  • Написание кода, конечно, все еще основной вид деятельности, но точно не "абсолютно превалирующий"
  • DevOps - под ним я здесь имею ввиду написание скриптов и другую работу, нацеленную на автоматизацию и упрощение разработки/выпуска релизов
  • Под материалами имеется ввиду, в первую очередь, документация. Ну и другие тематические материалы, которые вы под свой проект сможете придумать
  • Со статьями и публикациями, думаю, понятно: это всевозможные способы продвижения проекта на различных ресурсах

 

Если еще проще: половина работы разработка, вторая половина - освещение. Сторону разработки я здесь разбирать не буду - рассматривать мы будем именно освещение, так как репозиторий без кода найти невозможно, а вот без нормального Readme и статей - еще как да. Все стороны данного процесса, конечно, в одну статью не поместятся - сегодня мы разберем  лишь подготовку проекта к выходу в свет и его оформление

 

Readme

 

Начать стоит с основного описания репозитория и, в частности, Readme файла

Readme файл - это файл, чаще всего формата MD с ограниченной поддержкой HTML, который отображается на главной странице репозитория (любой платформы для хостинга репозиториев, будь то Github, GitLab, Gitflic и пр.) и служит для того, чтобы рассказать пользователю о проекте, на который он только что наткнулся

 

 

Существуют разные подходы к созданию подобного файла. Но прежде чем мы перейдем к непосредственному его написанию, нужно обозначить два основных момента, достаточно очевидных, при ближайшем рассмотрении, но не всегда очевидных с самого начала:
 

  1. У вас есть очень мало времени, чтобы рассказать пользователю о чем ваш проект. Это не длина всего файла: если пользователь не сможет понять, о чем пойдет речь далее, с первых нескольких строк (либо все описание будет свалено в один громадный пласт текста, который вызывает скуку и отторжение), то с большой долей вероятности он уйдет

    Опять же, можно по разному к этому относится: "Ведь это пользователю нужен мой продукт, он бесплатный - я его не продаю". Проблема заключается в том, что большинство пользователей, попадающих в ваш репозиторий, еще не знают, нужен им этот продукт или нет. Тут и обсуждать особо нечего: часто ли вы сами от корки до корки штудируете полное описание всего что есть на портале/лендинге/файле-описании, когда случайно на них попадаете? Репозиторий, в данном случае, ничем не отличается от коммерческого продукта
     
  2. Нехватка или плохая подача информации может оттолкнуть даже уже заинтересованного пользователя. Если он не найдет на странице простого и доступного объяснения, что ему прямо сейчас нужно сделать для начала работы, то не будет пользоваться вашим проектом. А возможно не будет, даже если это объяснение есть - просто потому, что оно слишком сложное или неуклюжее

    Вы, возможно, захотите сейчас возразить кучей примеров успешных, но абсолютно недружелюбных проектов - эти примеры на фоне нашего (потенциального) проекта будут ошибочны и несправедливы. Apache может в каждом своем новом продукте заставлять меня учить приемы разработки чуждых мне языков программирования, чтобы собирать их релизы из исходников - меня это бесит, но я понимаю, что это огромные проекты с сильным сообществом, именем большой конторы и, зачастую, не имеющие других бесплатных аналогов сопоставимого масштаба. Случайный no-name репозиторий, вышедший позавчера, меня таким заниматься не заставит

    Это может показаться несколько однобоко: вот может у вас действительно невероятно амбициозный проект, закрывающий настолько животрепещущую проблему, что пользователи, распихивая друг друга локтями, будут ложить сервера, в попытках заполучить себе его копию. На самом деле, я даже знаю один такой. С той лишь разницей, что он так и не взлетел: при всем уважении к автору и его огромной многолетней работе - работе, задачу которой я из материалов репозитория так и не смог понять, хотя очень хотел. С другой стороны есть, например, OneScript. ИМХО: Попробовал бы ли я его, если бы мне для пробы, в бытии 1С-нику, вместо "Скачайте и установите .msi" предложили бы разбираться в MSBuild и собирать из исходников? Думаю нет

    Обвинять же "поколение казуальных недопрограммистов" не желающих ни в чем разбираться и не понимающих "всю прелесть сборки из исходников" можно потом сколько угодно - жаль только, что в одиночестве
     

Теперь разберем непосредственно создание приветственного файла. Для этого я сделал пример описания некого условного расширения - самой на мой взгляд очевидной формой ведения проекта на 1С, разве что после внешней обработки

 

 

По классике, Readme файл разбит на различные блоки: они могут быть разные и в разном порядке, в зависимости от проекта, но костяк должен состоять как минимум из:

  • Краткого описания проекта - его сути и решаемых им проблем. Тот самый блок, который должен зацепить пользователя, чтобы он читал дальше
  • Развернутого описания, желательно по пунктам, возможностей расширения
  • Примеров работы, чтобы дать хотя бы приблизительное понимание пользователю о том, что он будет с вашим продуктом делать после установки
  • Варианты поставки (релизов) и способ установки. Желательно с картинками/командами консоли
  • Дополнительные блоки о наличии документации, использовании наработок других проектов и пр.

 

Рассмотрим эти пункты по порядку, а заодно взглянем на некоторые интересные возможности расширенной MD разметки, которые нам доступны:

Краткое описание проекта, как понятно из названия, должно давать пользователю некоторую начальную информацию, чтобы он понял - нужен ему, хотя бы в теории, представленный функционал или нет. Роковая ошибка при написании Readme думать, что при отсутствии краткой и понятной формулировки сути проекта, пользователь полезет глубже дабы узнать, что же там в этом проекте все таки скрывается. Нет, он не полезет. Поэтому, в данном блоке, в одном или нескольких предложениях, обязательно должны быть а) суть реализации б) решаемая проблема или описание функционала, из которого эта проблема и так понятна

 

 

![Лого](https://github.com/Bayselonarrend/WorkFlowTest/assets/105596284/30977f89-aa1f-4c4a-9693-ff9953774fc2)

# Экспансия

[![Статус порога качества](https://api.athenaeum.digital/Sonar/api/project_badges/measure?project=OpenIntegrations&metric=alert_status)](https://api.athenaeum.digital/Sonar/dashboard?id=OpenIntegrations)
![Версия](https://img.shields.io/badge/Версия_1С-8.3.9-yellow)

Расширение для работы с расширениями. Позволяет программно управлять вашими расширениями: получать список расширений, обновлять их и многое другое

 

Но, как видно, в моем примере есть не только это: еще тут есть лого и значки

Лого - это необязательная, но очень желательная часть описания. Оно создает некоторый брендинг, который мало того, что придает ему профессионального шарма и серьезности, но и создает у пользователя образ вашего проекта не как какого-то "кода на коленке, который выполняет вот эту функцию" но отдельного законченного продукта, к которому доверия и симпатии всегда больше. Короче, основы маркетинга для технарей

 

Сделать лого и красивый текст не так сложно, как может показаться: я, лично, в работе с графикой сам полный профан, но простого и понятного Paint.NET или Gimp вполне достаточно, чтобы сделать прилично и аккуратно. Для текста я использую сайт textstudio - там вообще ничего даже знать не надо, оно само все сделает

 

Сюда же можно отнести и название: вы можете назвать свой проект "Расширение для работы с расширениями", но нетрудно представить, как пользователь вашего проекта будет рассказывать о нем другому человеку, и с каким шансом последний после этого его найдет

Значки (бэйджи) - хороший способ дать краткую информацию о вашем проекте, не выделяя для этого очередной блок с длинным нудным текстом. При помощи значков обычно определяют такую информацию как: используемые в проекте технологии, версии этих технологий, ссылки на Telegram-каналы или сайты, ссылки на сторонние ресурсы, где проект представлен. Это функционально, при этом просто, красиво и элегантно

Самый простой способ создания значков - shields.io. Там можно легко создать любые статические значки просто из текста, а также получить различные бэйджи по динамическим данным, например о скачиваниях или последнем релизе в репозитории

После краткой формулировки, обычно идет более широкое описание возможностей проекта. Тут уже можно развернуться и по пунктам расписать какие доступны функции, привести примеры решенных задач и все в этом духе. Это, конечно, не значит, что нужно графоманить 10 экранов сплошного текста - сохранять интерес пользователя необходимо и тут, например используя списки, таблицы или диаграммы

 

 

## Возможности расширения

Данное расширение призвано упростить работу с расширениями, управляя процессами их управления прямо из кода 1С, а именно:
- Программно создавать расширения
- Программно удалять расширения
- Программно обновлять расширения
- Программно получать информацию о подключенных расширениях

>[!Important]
> Данное расширение не может работать с данными самого себя

 

Для красоты тут используется блок с примечанием - Important (важно). Тоже отличный способ разбавлять текст. Помимо самого Important, есть еще примечания типов Note (заметка), Tip (совет),  Warning (внимание) и Caution (осторожно). Все они отличаются цветовым выделением

 

> [!NOTE]  
> Highlights information that users should take into account, even when skimming.

> [!TIP]
> Optional information to help a user be more successful.

> [!IMPORTANT]  
> Crucial information necessary for users to succeed.

> [!WARNING]  
> Critical content demanding immediate user attention due to potential risks.

> [!CAUTION]
> Negative potential consequences of an action.

 

Далее порядок уже может отличаться: в моем случае следующим идет блок с примерами, но довольно часто его выносят в конец, уже за блок со способом установки. Также данный блок может полностью отсутствовать, если у проекта есть отдельная документация

Применительно к 1С тут намечается два пути: скриншоты, если ваш проект - внешняя обработка или целая конфигурация, нацеленная на работу через интерфейс, и примеры кода, если это расширение с общими модулями, один общий модуль и тому подобное. В моем случае это примеры кода:

 

 

## Примеры работы с расширением

Поиск расширения по имени

```bsl
   // Возвращает структуру с полями: Имя, Версия, ДатаПодключения, Описание
   ДанныеРасширения = ЭКСП_РаботаСРасширениями.ПолучитьРасширение(ИмяРасширения);
```

Получение массив расширений

```bsl
   // Возвращает массив структур с полями: Имя, Версия, ДатаПодключения, Описание
   РасширенияБазы = ЭКСП_РаботаСРасширениями.ПолучитьРасширенияБазы(ИмяРасширения);
```

Подключение расширения

```bsl
   // Возвращает Истина, если расширение было подключено
   Подключено = ЭКСП_РаботаСРасширениями.ПодключитьРасширение("C:/Расширение.cfe");  
```

 

Для выделения кода в MD используются блоки, определяемые косыми кавычками - по 3 в начале и в конце. Дополнительно, после начальных кавычек, можно указать режим подсветки синатксиса. В данном случае это bsl, что означает подсветку синтаксиса 1С. С полным списком доступных языков можно ознакомится тут

Способ получения и установки - самый важный, после краткого описания, раздел. Идет в конце только потому, что сначала надо объяснить, зачем что-то вообще получать и устанавливать

Если проект написан на самом 1С, то описывается данный блок максимально просто: практически каждый 1Сник по умолчанию знает, как подключить обработку и расширение, а пользователям других языков данные проект не будет интересен в любом случае. Единственное, что необходимо отметить - получение файлов из релиза, если он есть, или каталог, где начинаются уже непосредственно исходники рабочей части вашего проекта - все таки далеко не все 1С-разработчики уверенные пользователи Git-хостингов и если ваш репозиторий - первый подобный проект в их жизни, то "где скачать" может стать серьезным вопросом

 

 

## Релизы и установка

<img src="https://github.com/Bayselonarrend/WorkFlowTest/assets/105596284/2df78e38-10c2-4019-a5e2-1bdb2d7b5e21" align=left width=400>

<br>

Для установки данного расширения достаточно получить `.cfe` файл из последнего релиза, после чего добавить его в список расширений вашей конфигурации. **Минимальная версия 1С - 8.3.9**

<br>
<br>

 

Абсолютно обратная сторона - это проект для 1С, но не являющийся его реализацией: внешние компоненты, консольные утилиты и пр. Тут наоборот необходима максимальная подробность инструкции, особенно если собирать проект надо из исходников. Хотя вообще лучше позаботиться о бинарниках/установщиках в релизах

Про оформление: картинки можно располагать слева и справа от текста, а также менять их ширину и высоту, если вместо стандартного MD варианта их вставки использовать HTML, как на примере выше. Align (выравнивание) может принимать значения left и right, а width и height - число пикселей ширины и высоты соответственно

В принципе, этого уже будет достаточно, чтобы страница проекта не была закрыта в момент открытия в тех случаях, когда на ваш репозиторий натыкаются не при поиске решения конкретной проблемы, а из общего любопытства, которое источником большинства пользователей и является. В качестве же дополнительных блоков, шире раскрывающих ваш проект, могут выступать:

 

  • Блок с описанием сайта или документации - внешнего источника информации о проекте
  • Блок с информацией об использовании разработок из других проектов - как правило хорошего тона
  • Список статей и заметок на других ресурсах
  • В конце Readme также принято указывать список разработчиков, которые участвуют в проекте, но это не обязательно

И также несколько общих советов:

  • Используйте больше картинок и скриншотов
  • Разделяйте блоки с текстом, если они слишком больше - больше чем нормальный абзац в 3-4 предложения
  • Используйте таблицы и списки там, где идет перечисление однотипных данных
  • Следите за обще эстетикой: описание должно быть подробным, но не должно быть похожим на свалку

Полезные ссылки для создания Readme:

 

 
 Полный код разметки файла из примеров

 


 

Про общее описание репозитория

 

Кроме Readme файла, который пользователь видит при заходе в репозиторий, есть еще общее краткое описание проекта, которое используется как на его странице, так и при показе репозитория в каких-либо общих списках, новостных лентах и пр. Оно невелико, но важно, поэтому кратко на нем тоже остановимся

 

Изменить данное описание можно нажав на шестеренку (видно на скриншоте в правом верхнем углу). В открывшейся форме мы можем заполнить следующие данные:
 

  • Краткое описание - сюда отлично подойдет краткое описание из начала Readme, но желательно добавить еще указание технологии, для которой проект разрабатывается
  • Сайт - URL портала или документации, если они есть
  • Темы - это набор тэгов, которые позволяют определить проект в различные наборы вместе с другими репозиториями схожей тематики. Выхлопа из этого не очень много - примерно как у использования хэштегов в социальных сетях, но заполнить совсем нетрудно и занимает от силы пару минут, так что лучше все таки этим озаботиться

 

 

Также в настройках описания можно включить и отключить различные разделы репозитория: Deployments, Packages, Releases. Они включены по-умолчанию, но если вы их не используете, то лучше отключить, дабы не загромождать боковую панель

Для полноты картины остается только сделать и включить обложку. Она скрыта чуть глубже, уже в основных настройках репозитория (кнопка Settings на верхней панели) на главной их странице:

 

На примере OpenIntegrations

 

Обложка, также как и описание, отображается при показе репозитория в различных списках на Github...

 

 

...а также как картинка оформления ссылки репозитория, когда ей делятся во всяких социальных сетях или мессендежрах. Как минимум, это красиво и привлекает к себе внимание, что важно

 

 

 

Примеры хороших Readme из мира 1С

 

Напоследок - примеры хороших Readme из 1С-проектов. Не все они прямо ложатся на шаблон представленного выше примера - но они и не должны. Единственный настоящий критерий качества - красота и понятность. Все остальное лишь методы их достижения

 

 

 

В заключение

 

Публичные репозитории создаются по разным причинам: иногда часть основного проекта в компании решается выложить в открытый доступ, кто-то просто хочет сохранить свой старый код и не против, чтобы им пользовались другие разработчики - к таким случаям вопросов нет

Но я все же склонен считать, что большинство репозиториев, которые мне встречаются, все же являются чей-то персональной инициативой, начиная с "просто хобби", заканчивая неким видом жизненного magnum opus. И в таких случаях для меня очень странно, насколько мало усилий прилагается для того, чтобы эти проекты не просто существовали, но ими еще и кто-то пользовался

Шаги, описанные выше, если и не помогут вам напрямую найти новых "попутчиков" для своего проекта, то, как минимум, очень сильно увеличат шансы заинтересовать тех людей, которые на него уже попали. Не пренебрегайте ими: если цель заключается в том, чтобы сделать "крутой" проект, то игнорирование создания моста между разработчиком и пользователем приведет лишь к грусти и печали, когда написанный код, на который и было потрачено все время работы, окажется никем не востребован и, как следствие, неизбежно брошен

Ну а если вы не мэйнтэйнер, а тот самый пользователь, то не забывайте поддерживать понравившиеся проекты - это очень важно!

 

Спасибо за внимание!

 

Если эта статья оказалась полезной, то вас также могут заинтересовать:

 

Автодокументация модулей: Markdown, Osparser и Docusaurus

Статья Системный администратор Программист Стажер Бесплатно (free) Нет файла DevOps и автоматизация разработки OneScript

Рассмотрим создание самоформирующейся документации через комментарии и соглашения: как это сделать и зачем, с описанием полного цикла от исходников конфигурации до странички в интернете

Обновляемый список последних статей Инфостарт для профиля Github

Статья Программист Стажер Бесплатно (free) Нет файла Групповая разработка (Git, хранилище)

Не знаете, чем бы таким заполнить свой профиль Github? Заполните его своими статьями на Инфостарт! Этот простой workflow сам соберет список ваших последних статей и будет периодически обновлять его для актуализации данных.

Особенности национального Workflow: Github Actions и OneScript

Статья Системный администратор Программист Бесплатно (free) Нет файла Групповая разработка (Git, хранилище) OneScript

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

 


 

 Мой GitHub:    https://gitub.com/Bayselonarrend 
 OpenYellow:    https://openyellow.notion.site
 Лицензия MIT:  https://mit-license.org

 

github open-source репозиторий git открытый код

См. также

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Программист Стажер Платформа 1С v8.3 Платные (руб)

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    11492    94    4    

125

Групповая разработка (Git, хранилище) Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Когда в хранилище одновременно разрабатывают несколько команд, сортировка сделанного и несделанного при формировании релиза и проведение code review по задачам превращаются в непроходимый квест. В таких случаях нужен бранчинг. Расскажем об опыте перехода на новую схему хранения кода для ИТ-департамента.

23.09.2024    2078    kraynev-navi    2    

23

Групповая разработка (Git, хранилище) Программист Бесплатно (free)

Называть Git новой технологией – уже смешно, но для многих 1С-ников это действительно «новое и неизведанное». Расскажем о плюсах и минусах двух главных систем контроля версий в мире 1С: Git и хранилища.

17.09.2024    5805    Golovanoff    69    

25

Групповая разработка (Git, хранилище) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Во многих командах незаслуженно забывают о том, что в базе меняются расширения (как от вендора, так и собственные) и внешние отчеты и обработки. Вплоть до того, что релиз происходит каждый день – меняются печатные формы, отчеты, обработки. Расскажем о том, как выгружать в Git не только изменения конфигурации рабочего контура, но и файлы внешних обработок и расширений.

05.09.2024    1712    ardn    12    

14

EDT Групповая разработка (Git, хранилище) Программист Платформа 1С v8.3 Бесплатно (free)

Заказчики любят EDT+Git за прозрачность и контроль качества. А у разработчиков есть две основные причины не любить EDT – это тормоза и глюки. Расскажем о том, что нужно учесть команде при переходе на EDT+Git.

14.08.2024    7023    lekot    34    

7

Групповая разработка (Git, хранилище) Программист Платформа 1С v8.3 Бесплатно (free)

В «долгоиграющих» проектах стандартный захват объектов 1С в хранилище может привести к длительным простоям других разработчиков. Но и создавать под каждую доработку отдельное хранилище, чтобы использовать технологию разветвленной разработки конфигураций от фирмы «1С» – избыточно. Расскажем о том, как разрабатывать в отдельной базе без ожиданий, а потом с легкостью перенести изменения в хранилище, используя основную идею технологии 1С – конфигурацию на поддержке хранилища.

05.08.2024    3400    sinichenko_alex    16    

24

Групповая разработка (Git, хранилище) Программист Руководитель проекта Стажер Бесплатно (free)

Про изменения и новинки в агрегаторе открытых проектов OpenYellow, которые появились с момента его создания: про портал, Github и Telegram

15.07.2024    2849    bayselonarrend    8    

24

Групповая разработка (Git, хранилище) OneScript Программист Платформа 1С v8.3 Бесплатно (free)

Скрипт для работы с SonarQube и локальным репозиторием Git.<br> Цель проекта – возможность выполнить быструю проверку качества кода перед тем, как помещать доработки в рабочее хранилище. В Sonar и Git выгружается не вся конфигурация, а только объекты из заданного списка.<br> https://github.com/vkrivov/go/

02.07.2024    3118    vkrivov@yandex.ru    8    

18
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 2696 07.07.24 23:36 Сейчас в теме
Это все для глубоких программистов, решающих задачи программистов. Огромная часть 1сников не решает задачи программистов, они решают задачи пользователей.
Например, я пару раз заходил на гитхаб уже зная что продукт мне нужен, меня просто взбесило - пока не работающему на гитхабе найти ссылку на скачивание - oпупеть можно. Я не собираюсь развивать опенсорс проект, мне тупо нужен готовый блок, скачать эту разработку, а вокруг навешано всяких фенек для опенсорса, через которые продираться чтобы просто скачать готовое... Поэтому если сейчас вижу ссылку на гитхаб - пойду туда только в случае острой необходимости...
Может я просто тупой...
Artem.Po; atik; Kalam; ibcxir; ixijixi; PowerBoy; gucci76; zqzq; muskul; +9 1 Ответить
2. bayselonarrend 2033 07.07.24 23:46 Сейчас в теме
(1)
Огромная часть 1сников не решает задачи программистов, они решают задачи пользователей


Это не особенность 1С - в целом справедливо для всех стэков. Проблема скорее в том, что программист на другом языке, не участвующий во всем это опен сорс движе, все равно знаком с git и github - просто по своей основной работе. А 1Сник нет. Отсюда и возникают подобные вопросы

Поэтому если сейчас вижу ссылку на гитхаб - пойду туда только в случае острой необходимости


Эта статья - ровно об этом: Github не традиционен для 1С, поэтому момент подачи информации о проекте в нашей сфере стоит еще острее, чем в других. Думаю, если бы на странице того, нужного вам проекта, все было доступно написано и сделан нормальный релиз, то осадочка такого бы не осталось
20. brr 184 08.07.24 10:49 Сейчас в теме
(2)
Проблема скорее в том, что программист на другом языке, не участвующий во всем это опен сорс движе, все равно знаком с git и github - просто по своей основной работе. А 1Сник нет.

Это уже не совсем так, во многих командах используется едт и, соответственно, гит.
21. bayselonarrend 2033 08.07.24 10:50 Сейчас в теме
4. Поручик 4691 07.07.24 23:53 Сейчас в теме
(1) Что у меня такой реакции нет. Зашёл на гитхаб, скачал, забыл.
Fox-trot; maksa2005; +2 Ответить
7. bayselonarrend 2033 07.07.24 23:55 Сейчас в теме
(4)Это когда в репозитории есть, что скачать. Очень часто встречается, что просто лежит непонятной структуры исходный код
9. tomskiy_proger1c 13 08.07.24 05:52 Сейчас в теме
(1) а что вы понимаете под "не решает задачи программистов"? Разработка ПО, инструментов и тд для самих программистов? Так такого полно, на инфостарте, можно найти почти, что угодно для своих программистических нужд. Просто 1С из-за особенностей платформы больше сосредоточен на своей технологии, так скажем сидим в своей отдельной желтой комнате, но которая так же переплетается с другими. На счет того, того что "решаем задачи пользователей", то какие еще должны решать задачи программисты, которые делают продукты для этих самых пользователей (по моему все этим занимаются, ну от технологии тоже конечно зависит, просто где-то пользователь - это программист, а где-то бухгалтер). А что качается гита, то инфостарт - это "гит" для программистов 1С вот и все, удобная проверенная платформа, да она другая, с другой архитектурой, но с инфостарта на гит 1С не перейдет никогда.
10. bayselonarrend 2033 08.07.24 06:43 Сейчас в теме
(9)
А что качается гита, то инфостарт - это "гит" для программистов 1С вот и все, удобная проверенная платформа, да она другая, с другой архитектурой, но с инфостарта на гит 1С не перейдет никогда.


Извините, но вы вообще не понимаете, о чем говорите
11. tomskiy_proger1c 13 08.07.24 08:22 Сейчас в теме
(10) ну почему же? Инфостарт - площадка для 1С программистов, где все размещают свои разработки, обсуждают это и тд и тп. Где еще найти такое место? Если делать сравнение с гитом, то разница объемов "публикаций" колоссальна, вы даже делали на подобную тему статью, насколько я помню.
Я еще раз говорю, что гит и инфостарт - это две разные площадки, с разной архитектурой. Но именно для 1Сников Инфостарт - это замена гита и я очень сомневаюсь, что 1С сообщество когда-то перейдет на гит полностью, ну или даже на половину того объема, который есть тут.
Поручик; +1 Ответить
14. bayselonarrend 2033 08.07.24 09:26 Сейчас в теме
(11) Ладно, попробую объяснить на пальцах

Git - это система контроля версий. Она по умолчанию не может сравниваться с ИФ - она может сравниваться с хранилищем конфигурации: система для сохранения, отслеживания и управления версиями разрабатываемых продуктов

Github - это сервис, основным функционалом которого является облачное хранение данных Git-репозиториев - хранение данных версий этой системы контроля. Поверх этого существует дополнительный функционал, который делает работу, основанную на Git, более социальной и комфортной

Если мы говорим про open-source, то основной паттерн использования Github таков: автор создает свой проект, после чего любой желающий может внести в него свой вклад - сделать себе копию, поменять в ней код и отправить запрос на слияние. В этом основной смысл: код раздается свободно и бесплатно, с расчетом на привлечение добровольцев к развитию проекта, чтобы решать большие общие задачи усилиями разных, зачастую незнакомых друг с другом, разработчиков

Создание на основе таких проектов релизов, чтобы любой желающий, даже не участвующий в разработке, мог удобно скачать себе его копию - это буквально побочный эффект, добрая воля разработчиков. Но точно не костяк или смысл использования Github. Данный сервис - это не форум и не магазин, но огромный инструмент для совместной разработки

На ИФ нет подобного инструментария - потому что он здесь не нужен. Инфостарт - это вот то, что вы говорите: каталог + профессиональное сообщество. Никто не говорит что Github должен заменить Инфостарт или наоборот - они просто не могут этого сделать, потому что это две несопоставимые сущности. На Github не пишут статьи и не продают разработки, а ИФ это не инструмент разработчика - он не позволяет вносить вклад в чужие продукты, отслеживать версии или создавать ветки

"Для 1СНиков Инфостарт - это замена гита". Нет, Инфостарт для 1Сников это не замена гита, и даже не замена гитхаб - я не могу внести свой вклад в продукт, опубликованный на ИФ, точно также, как не могу написать статью на Github. Не говоря уже о том, что самый частый способ разработки открытых 1С проектов включает в себя и то и другое: Github используется при разработке, потому что это удобный инструмент, а к сформированному там проекту потом создаются статьи на ИФ или даже просто финальный продукт здесь распространяется
24. tomskiy_proger1c 13 08.07.24 10:57 Сейчас в теме
(14) ну я понял про что вы, в целом и понимал это, мысль моя была скорее в том, что мы как 1Сники будем использовать скорее Инфостарт, чем Гитхаб (кстати все это время я имел ввиду Гитхаб, а не Гит - мой косяк :) ), что есть схожесть в том, что и там и там публикация проектов (но она разная), короче, что 1С программер выберет ИФ и будет использовать его, а не гитхаб (глобально).
starik-2005; +1 Ответить
25. bayselonarrend 2033 08.07.24 11:03 Сейчас в теме
(24) Пользователь будет пользоваться тем, что решает его задачи. Если EDT все таки станет де-факто стандартом у большинства компаний - в разработке будет использоваться Github (*Lab, *flic, *verse) также, как и на других языках. Пострадает от этого популярность ИФ? Нет, абсолютно
29. starik-2005 3081 08.07.24 12:00 Сейчас в теме
(24) Вы в принципе говорите об одном. только Вы с точки зрения решения проблемы бизнеса/программиста/пользователя, а ваш оппонент с технической точки зрения.
Инфостарт - площадка с кучей обработок, большинство из которых морально устарели. Есть авторы, которые постоянно дорабатывают свои обработки и выкладывают обновления. Есть авторы, которые болт на это забивают - большинство. То же самое и на гите. И что там, что здесь, любой может скачать что-то, форкнуть и разместить от своего имени - полно таких ситуаций. Только на гите это приветствуется, а на инфостарте такое является не совсем этичным.
Но вообще, с точки зрения здравого смысла, для 1С-негов более удобен, конечно, инфостарт. Но тут совершенно невозможно что-то разрабатывать коллективно, хотя, повторюсь, форкнуть вполне себе можно, и развивать дальше это что-то.
Ну и мотивация разная. На инфостарте стартманей накочегарить, на гите показать, какой ты крутой чувак. Но и там, и сям, репутационно ты растешь. Страница на инфостарте для большинства работодателей не хуже (лучше) страницы в гите.
Поручик; sikuda; ixijixi; +3 Ответить
31. tomskiy_proger1c 13 08.07.24 12:16 Сейчас в теме
(29) ну и тут можно за бесплатно выложить обработочку :)
34. bayselonarrend 2033 08.07.24 12:28 Сейчас в теме
(31) Что тогда мешает выложить её на GH, чтобы можно было как минимум сразу легко в браузере посмотреть код и позволить другим людям её дорабатывать в общем проекте?
35. starik-2005 3081 08.07.24 13:19 Сейчас в теме
(34)
Что тогда мешает выложить её на GH
Лень?
37. bayselonarrend 2033 08.07.24 13:26 Сейчас в теме
45. tomskiy_proger1c 13 09.07.24 05:37 Сейчас в теме
(34)(35) а что если просто хочется поделиться своим инструментом, чтобы люди могли им пользоваться. Зачем мне чужие доработки в моем проекте, если его веду я и развиваю я.
Разные же цели могут преследоваться, поэтому хорошо, что ест и Инфостарт и ГитХуб.
52. Fox-trot 163 09.07.24 16:44 Сейчас в теме
19. starik-2005 3081 08.07.24 10:47 Сейчас в теме
(1)
для глубоких программистов, решающих задачи программистов. Огромная часть 1сников не решает задачи программистов
Это как огромная часть мира не производит самолетов, танков, литографических девайсов, обогащенных уранов, космических аппаратов, ... Давайте сидеть и ничего не делать.
Поручик; +1 Ответить
30. sikuda 677 08.07.24 12:04 Сейчас в теме
(1) Нет вы просто описываете философию потреб..ятсва потребительства ;)
Именно эта философия довела этот продукт до своего логического конца
Прикрепленные файлы:
Поручик; +1 Ответить
33. bayselonarrend 2033 08.07.24 12:26 Сейчас в теме
(30) Вы, наверное, не очень правильный проект выбрали для своего примера)) Начиная с того, что он коммерческий, заканчивая тем, что по нему никто скучать не будет
starik-2005; +1 Ответить
38. sikuda 677 08.07.24 14:02 Сейчас в теме
(33) "никто скучать не будет" 1C системные требования: Microsoft Internet Explorer 11 версия
https://v8.1c.ru/tekhnologii/systemnye-trebovaniya-1s-predpriyatiya-8/operatsionnye-sistemy/
39. bayselonarrend 2033 08.07.24 14:04 Сейчас в теме
(38) Так это же не значит, что обязательно нужен IE - если уже IE, то 11 версии. В любом случае, если кто-то запускает веб-клиент на эксплорере - то это не от большой к нему любви
3. Поручик 4691 07.07.24 23:52 Сейчас в теме
Вот я 1Сник в основном, а с Git и GitHab знаком хорошо. Первый используется на работе в групповой разработке (ansible и прочие джанго), на втором пасусь в основном по вопросам с php.
Я не чистый 1Сник.
5. bayselonarrend 2033 07.07.24 23:54 Сейчас в теме
(3) Это здорово, когда так. Но это скорее исключение на общем фоне
6. CheBurator 2696 07.07.24 23:54 Сейчас в теме
Вот мне по барабану информация по проекту. Меня в первую очередь интересует какую мою потребность перед клиентом закроет эта публикация. Поэтому все эти составы проектов, иссуи и прочие - меня интересуют ч последнюю очередь.
.
Поэтому надо определиться - эти проекты для участия в них других программистов или для решения задач бизнес-пользователей. Это имхо две большие разницы. И подача и оформление этих разных видов - должно быть принципиально разным.
Но я не настаиваю. Гитхаб - монастырь чужой, со своим уставом может лезть и не надо...
8. bayselonarrend 2033 08.07.24 00:06 Сейчас в теме
(6) Это какое-то странное понимание. Вот я веду проект и у него в описании написано «Этот проект - расширение для работы с Telegram, у него вот такие функции, лежат они вот в таких модулях» Это проектное описание или бизнесовое? И как вообще проекты могут делиться на «для разработки» и «для решения»: типо мы тут разрабатываем, но они ничего не решают? Github - это не витрина, там все проекты про совместную разработку для решения задач.

Что касается желания или не желания участия - это, конечно, все добровольно, но было бы странно вообще не говорить об этом в рамках проекта. Думаю, потерпеть в описании обращение к потенциальным участникам - это не большая цена, когда проект по умолчанию бесплатный и открытый, решающий чужими руками вашу проблему за просто так. Issues же вообще нужен пользователю не меньше, чем разработчику - там можно задать вопрос, если что-то не работает или непонятно
krapin; starik-2005; Viktor_Ermakov; infosoft-v; KirillZ44; +5 Ответить
12. rokhin 147 08.07.24 08:49 Сейчас в теме
Было бы полезно упомянуть российский аналог от Сбербанка.
https://gitverse.ru/
Нехорошие примеры ограничений с импортными ресурсами уже есть.
romanichenko; brr; +2 Ответить
13. bayselonarrend 2033 08.07.24 09:10 Сейчас в теме
(12) Вообще, статья не привязана к конкретному хостингу - оформление Readme и описания + - одинаковы для любых подобных сервисов

Если говорить в целом про российские аналоги, то, при всем к ним уважении: на Github есть какая-никакая база проектов и сообщество, + это крайне известная платформа, о которой даже в 1С сообществе более менее знают. Так вот даже на нее вытащить пользователя бывает крайне проблематично. Что говорит про, без относительно к стране производства, появившиеся позавчера платформы без кодовой базы и заинтересованных пользователей.

С одной стороны было бы правильно поддержать их, внеся свой вклад в наполнение, но если разговор идет в рамках создания проекта с целью его популяризации - выбирать GitVerse или Gitflic в противовес Github означает просто застрелить его на самом старте. Они скорее подойдут для хранение рабочих конфигураций компании - там эти аналоги будут уместны
15. sikuda 677 08.07.24 10:07 Сейчас в теме
(12) Было бы еще полезнее упомянуть https://hub.mos.ru/
16. bayselonarrend 2033 08.07.24 10:10 Сейчас в теме
(15)Что в этом полезного? Это вообще пустой локальный минихост, маленький даже по меркам импортозамещения. Еще и с регистрацией через mos.ru
17. sikuda 677 08.07.24 10:36 Сейчас в теме
(16) Вот есть повод вообще поговорить об Open Source, о логике построения и о результате , что на основе Open Source сможет возникнуть проприетарый проект типа GitHub(git-Microsoft), 1C Bitrix(php-bitrix), 1C-Предприятие(1С Софт) (56 открытых пакетов) а вот обратно никак!
И о том что в большинстве случаев логика использования - чистое потребительство (1)
18. bayselonarrend 2033 08.07.24 10:45 Сейчас в теме
(17) Ну, самое смешное, что вот как раз в 1С-то процент перехода из проприетарного в открытое как раз небывало высок: многие проекты из первой сотни, вроде YaxUnit, PinkRabbitMQ - это как раз вынос внутренних инструментов в Open-source

И о том что в большинстве случаев логика использования - чистое потребительство


Использования открытых проектов? Ну, это, на мой взгляд, абсолютно естественно - ситуация, когда разработчиков абстрактного проекта было бы больше, чем людей, проблемы которых этот проект решает, даже звучит как-то странно. + пользователи, не участвующие в разработке, все равно полезны для проекта - они могут давать обратную связь по багам или недоработкам
22. starik-2005 3081 08.07.24 10:52 Сейчас в теме
(16)
Что в этом полезного?
Ваша критика напоминает критику вас же в первом сообщении. Мне показалось это токсичным.
23. bayselonarrend 2033 08.07.24 10:56 Сейчас в теме
(22) Если формулировка похожа, это не значит, что вопрос равносилен. Я не хотел показаться токсичным, но вот уж точно МосХаб это труп трупом, даже на фоне Gitflic и GitVerse, которые тоже не без вопросов
26. starik-2005 3081 08.07.24 11:10 Сейчас в теме
(23) Этот как с гитхабом - если никому ничего ни о чем не рассказывать, то, как говорит Дробышевский, мы станем неандертальцами и вымрем. Вот товарищЪ из первого сообщения говорит, что нафиг это не надо никому рассказывать. Ну и вы туда же. Этодругинчик?
27. bayselonarrend 2033 08.07.24 11:17 Сейчас в теме
(26)Чуть выше я отмечал, что поддержать какой-нибудь из ведущих отечественных хостингов, в принципе, было бы правильно. Но один, самый хороший, победивший в конкурентной борьбе. Если теперь каждый поселок городского типа захочет сделать свой хаб, паршиво слизав под копирку 20% от функционала GitLab, то его нужно будет тоже поддерживать?


что нафиг это не надо никому рассказывать. Ну и вы туда же.


Надо рассказывать, но не по принципу просто существования, а по принципу перспектив развития. Если в данном случае у нас действительно есть 2 более менее нормальных проекта и еще пачка распила - да, я считаю, что про пачку распила рассказывать не нужно (во всяком случае в просветительском ключе), чтобы новый человек по дурости не решил, что это сервисы сопоставимого качества, а начал свой путь в наиболее жизнеспособном из них
KirillZ44; Volchock; +2 Ответить
28. starik-2005 3081 08.07.24 11:51 Сейчас в теме
(27)
начал свой путь в наиболее жизнеспособном из них
Проблема 10%?
Вообще, далеко не все, что кажется распилом, им является. Есть проекты, которые плохо стартанули. Например, не было маркетинговой поддержки. хомячков надо направлять - сами они никогда не узнают, что им действительно надо. Об этом, в частности, первый комментарий.
32. bayselonarrend 2033 08.07.24 12:24 Сейчас в теме
(28) Это справедливо, когда несколько сервисов выходят примерно в одно время и о них в начале ничего не известно. Сегодня всем этим проектам по году +, думаю все уже достаточно понятно

Например, не было маркетинговой поддержки. хомячков надо направлять - сами они никогда не узнают, что им действительно надо


Сарафанное радио да, дает эффект, когда хороший проект не может получить силами создателей достаточного освещения. Для данных проектов это не заработало, что меня, лично, не удивляет. Не говоря уже о том, что тот же МосХаб, извините, не независимый проект безсеребрянников, который существует на воле голодных энтузиастов
36. starik-2005 3081 08.07.24 13:24 Сейчас в теме
(32)
существует на воле голодных энтузиастов
У Столлмана было на эту тему пространное большое и красивое текстовое нечто. Там про землю, кстати. Но индейцев никто не считал в стародревние времена землянами. С другой стороны, а какие там терки на голой территории свободного ПО? А... Эта территория давно же перестала быть голой. Вот ведь, сэр... (с)
40. bayselonarrend 2033 08.07.24 14:36 Сейчас в теме
(36) Столлман и сам по себе большой и пространный
41. starik-2005 3081 08.07.24 15:31 Сейчас в теме
(40)
сам по себе
Краткая биография
Ричард Столлман родился 16 марта 1953 года в Нью-Йорке, в семье Дэниэля Столлмана и Элис Липпман[4]. В 1974 году окончил Гарвард и поступил в Массачусетский технологический институт. Вскоре отказался от планов получения дальнейшего научного образования, но остался в МТИ работать программистом в лаборатории искусственного интеллекта. В январе 1984 года оставил работу в МТИ, чтобы посвятить себя работе над проектом GNU, который он основал в сентябре 1983 года.

Лауреат премии имени Грейс Мюррей Хоппер (1990).

В 2019 году покинул пост руководителя FSF после того, как критике подверглись его высказывания по делу Джеффри Эпштейна, в том числе в виде опубликованных блогерами и журналистами вырванных из контекста и искажённых отдельных фраз из этих высказываний. В марте 2021 года объявил о своём возвращении в совет директоров FSF[5].
Западная свобода во всей полноте и красоте )))
42. SergeyMordvin 1977 08.07.24 22:34 Сейчас в теме
Добрый день!
Крутая статья, спасибо

А где же найти репу про Экспансию?))
43. bayselonarrend 2033 08.07.24 22:37 Сейчас в теме
(42) Нигде, она выдумана для статьи)
SergeyMordvin; +1 Ответить
44. SergeyMordvin 1977 08.07.24 23:58 Сейчас в теме
(43) очень жаль =)))
я уже хотел сделать гит клон)))
46. Kalam 105 09.07.24 10:41 Сейчас в теме
Учитывая специфику 1С, всё это бессмысленно, может от единицы проектов и будет толк, но это скорее исключение.
1С это про сделал и забыл, завтра уже нужно другое, а вот эти тысячи строк кода можно в помойку ибо не актуально.
47. bayselonarrend 2033 09.07.24 10:50 Сейчас в теме
(46) Это просто оправдание отсутствия структуры и архитектуры в своей работе. Во всех языках доступен подход "сделал и забыл, завтра нужно другое", но почему то только в 1С это принято выставлять, будто бы так и должно быть. Что может стать неактуальным, если сначала сделать/взять готовым с того же Github какой-нибудь продуманный инструментарий, приводящий повторяющуюся работу к общему знаменателю (создание форм, http, проверки значений, обмены и пр), а потом всегда использовать его, не плодя кастыли-дубли с одинаковым функционалом каждый раз, когда эта работа всплывает в новом месте?
KirillZ44; +1 Ответить
48. ixijixi 1904 09.07.24 14:11 Сейчас в теме
(47)
завтра уже нужно другое
Скорее всего, Kalam имел в виду код, изменяющийся под требования законодательства. А продуманный инструментарий, приводящий повторяющуюся работу к общему знаменателю - для этого есть БСП =)
49. bayselonarrend 2033 09.07.24 14:18 Сейчас в теме
(48) Мое мнение, 1Сный GH и должен быть похож на коллективный БСП - быть различными модулями, покрывающими то, что настоящий БСП не покрывает (или покрывает плохо). Думаю, это очень немаленький пласт потенциально хороших проектов, которые могли бы на такой идее вырасти
50. starik-2005 3081 09.07.24 15:37 Сейчас в теме
(49)
немаленький
90% того, что делает 1С-нег, гугля, решается за условное время его гугления без оного..
51. ixijixi 1904 09.07.24 15:51 Сейчас в теме
53. kalyaka 1100 10.07.24 12:09 Сейчас в теме
В общем, коллеги, давайте всегда писать README.md в своих проектах. И чтоб не пара строк, а развернуто, с примерами, структурировано :)
54. sikuda 677 10.07.24 13:09 Сейчас в теме
(53) Точно! А в профиле на месте неиспользуемого skype - профиль github (типа https://github.com/sikuda)
55. bayselonarrend 2033 10.07.24 13:35 Сейчас в теме
(53)Ну вообще - да, посыл таков)
56. kalyaka 1100 10.07.24 13:42 Сейчас в теме
(55) Предлагаю модераторам Инфостарта добавить в требования к публикации статей со ссылкой на проект в github также структурировано оформленный README.md )
57. bayselonarrend 2033 10.07.24 13:45 Сейчас в теме
Оставьте свое сообщение