А реализация требуется с нуля или возможен вариант, когда реализация собеседываемого внутри себя содержит Dictionary<,> и, например, List<> ссылок на элементы?
Не знаю как вы, а я прежде чем что-то "бесплатно" взять, всегда узнаю на каких это условиях. Хотя вообще, стараюсь не брать "бесплатные" услуги, тарифы и т.д. А уж бизнес-то должен и платные вещи проверять, т.к. многие программы имеют отдельные прайсы для личного использования и для использования юр лицами.
Что за бред? В чем подлость и наглость? Люди выложили в доступ какой-то материал под какой-то лицензией. В чем проблема прочитать эту лицензию? Тем более, если этот продукт используется не дома где-то, а в полноценном продукте от организации?
Терминалы 50/50 или от симки, или от провода. Провод там обычно тот, что и весь остальной интернет в магазине. Симки в большинство тарифов эквайринга продавец себе тоже сам покупает. Так что в подавляющем большинстве случаев там тот же интернет, что и у всех.
Я не задаю вопросы на форумах ни по каким темам, только гуглю документацию и эти самые вопросы от других. За много лет я дважды хотел задать вопрос на SO, но после того, как подробно расписал проблему, находилось решение, и вопрос публиковать нужда отпадала.
А вот именно при гуглеже по 1С чаще всего возникало или "ты лох, найми разработчика", или "это бесплатная версия документации, оплатите доступ".
Из примеров, которые у вас написаны, вопрос "чем заменить COM коннектор в конфигурациях, которые типо есть под линукс, но типо нет" - это абсолютно валидный вопрос и адекватный вопрос. Если разработчики сделали кроссплатформенное решение с не кроссплафторменными частями, то такой вопрос обязательно возникнет и должен быть хорошо описан.
" заткнитесь кто не хочте помогать " - обычно пишут после того, как написали "автор лох, выпей йаду, найми разраба". И именно "автор лох" - это токсичное поведение. Если не хочется помогать, всегда можно либо пройти мимо, либо кинуть ссылку на нужный раздел документации.
Может покажется странным, но вместе с тем, что я перечислил, я считаю 1С достаточно хорошим в некоторых смыслах продуктом. Есть хорошие конфигурации, которые на порядки лучше, чем непонятные поделия от других фирм (в торговле есть УТ, например, в бухгалтерии та же конфигурация 1С:Бухгалтерия). Я знаю людей, которые много использовались и 1С:УТ и SAP в торговле. И вот 1С вспоминали, можно сказать, с любовью, после опыта с SAP. Так что, имхо, 1С не должно умереть, но вот трансформироваться во что-то более привлекательное им бы не помешало.
По ИДЕ оценивается не язык, а сама экосистема. И ущербные инструменты разработки, как и токсичное сообщество, а также закрытые и не полные материалы сильно снижаю комфортность разработки. Сравните комфортность разработки приложения под .NET Core и приложения под 1С платформу.
Работаю веб-разработчик (фул-стак), иногда занимаюсь связыванием 1С продуктов с моими веб-сервисами. Из-за этого иногда приходится что-то писать под разные конфигурации 1С. Так вот, опишу проблемы, почему я бы никогда не стал быть разработчиком 1С на полную ставку:
1) Устаревшие технологии и подходы, игнорирование архитектурных подходов и т.д. Подавляющее большинство приложений 1С - это монолит с кучей процедур делающих тоже, что и другая процедура, только с розовыми рюшечками.
2) Низкий уровень обучающих материалов. Платная база знаний, неполные материалы, многие учебники начинаются с конкретных примеров как сделать такую-то фигню, без описания концепции и подхода в целом.
3) Очень токсичное сообщество. Это прямо просто жесть - зайдите на мисту и на вопрос "Как сделать фичу N?" вам ответят: "Наймите разработчика." Если сказать, что ты разработчик, то тебя попытаются унизить, хорошо если дадут ответ, но скорее всего только унизят.
4) Проблемы с контролем версий. Отдельный вид, файлы кода в своих форматах, всё зачастую запрятано в бинарные файлы и т.д. Невозможно использовать подходы, применимые в почти любых других областях IT.
К плюсам стоит отнести нередко хорошие конфигурации, которые похоже разрабатывались с диким трудом и потом. Однако, в той же торговли решения сторонних разработчиков обычно и близко не стоит по возможностям с 1С:УТ, например.
В общем, 1С экосистема в целом - это набор хороших и не очень продуктов, построенных на устаревшей технически базе и управляемый слегка невменяемыми менеджерами из 10-х.
UPD: Вспомнил еще один момент. Среда разработки (конфигуратор) - ущербное поделие времен делфи-паскаль. Например, нельзя перенести курсор сдвигом вправо (он будет уходить в бесконечность). И там еще много таких стремных вещей, которые после студии/идеи кажутся пережитками прошлого из 0х-10х.
А вот, кстати, к коду на русском языке привыкаешь очень быстро.
Не надо такое учитывать. Верстальщик должен учитывать то, как выглядит сайт на различных устройствах в современных браузерах. А гадать что там накастомизирует пользователь - странное занятие.
Количество кусков и структурирование - это перпендикулярные параметры. Правильно выбранные слои абстракции, позволят вам описать систему в пару предложений текста и знание всей кодовой базы вам не нужно. А вот если для внесения изменения, вам нужно знать код целиком, то вы приехали. На приложении в 5к+ строк кода это уже будет трудно. На приложениях 100к+ строк - это будет ад, в котором любой улучшение или исправление будет вноситься человеко-неделями разработки и тестов.
napobo3 же написал "Вы сначала решаете какому уровню абстракции это изменение соответствует, потом его там вносите." И вот в хорошо спроектированной системе, где интерфейсы стоят там, где нужно, есть инверсия зависимостей, есть юнит-тесты, там изменения будет вносить не трудно.
Вот это, кстати, наверно самое важное. Опыт сеньора это как раз про то, чтобы писать всегда простой код так, чтобы он и задачу решал, и был расширяемым, и не был перегружен не нужными рюшечками. И так писать реально сложно, нужно не только знать инструмент, но быть еще немного вангой, догадываясь, куда может потом расширяться приложение.
можно провести водопроводы от ливневок и канализации к теплым странам...
Ответ на ваш вопрос - ГУЛАГ.
А реализация требуется с нуля или возможен вариант, когда реализация собеседываемого внутри себя содержит Dictionary<,> и, например, List<> ссылок на элементы?
Ну с июнем попали...
Собеседник был своеобразный...
Не знаю как вы, а я прежде чем что-то "бесплатно" взять, всегда узнаю на каких это условиях. Хотя вообще, стараюсь не брать "бесплатные" услуги, тарифы и т.д. А уж бизнес-то должен и платные вещи проверять, т.к. многие программы имеют отдельные прайсы для личного использования и для использования юр лицами.
Что за бред? В чем подлость и наглость? Люди выложили в доступ какой-то материал под какой-то лицензией. В чем проблема прочитать эту лицензию? Тем более, если этот продукт используется не дома где-то, а в полноценном продукте от организации?
Терминалы 50/50 или от симки, или от провода. Провод там обычно тот, что и весь остальной интернет в магазине. Симки в большинство тарифов эквайринга продавец себе тоже сам покупает. Так что в подавляющем большинстве случаев там тот же интернет, что и у всех.
Подробная инструкция по раздвоению ближнего своего есть в "Преступлении и наказании". В школе, между прочим, проходят.
Если уж пошли странные аналогии, то нанять разработчика = нанять водителя, а отправить в автошколу = отправить читать мануалы в нужном направлении.
Я не задаю вопросы на форумах ни по каким темам, только гуглю документацию и эти самые вопросы от других. За много лет я дважды хотел задать вопрос на SO, но после того, как подробно расписал проблему, находилось решение, и вопрос публиковать нужда отпадала.
А вот именно при гуглеже по 1С чаще всего возникало или "ты лох, найми разработчика", или "это бесплатная версия документации, оплатите доступ".
Из примеров, которые у вас написаны, вопрос "чем заменить COM коннектор в конфигурациях, которые типо есть под линукс, но типо нет" - это абсолютно валидный вопрос и адекватный вопрос. Если разработчики сделали кроссплатформенное решение с не кроссплафторменными частями, то такой вопрос обязательно возникнет и должен быть хорошо описан.
" заткнитесь кто не хочте помогать " - обычно пишут после того, как написали "автор лох, выпей йаду, найми разраба". И именно "автор лох" - это токсичное поведение. Если не хочется помогать, всегда можно либо пройти мимо, либо кинуть ссылку на нужный раздел документации.
Может покажется странным, но вместе с тем, что я перечислил, я считаю 1С достаточно хорошим в некоторых смыслах продуктом. Есть хорошие конфигурации, которые на порядки лучше, чем непонятные поделия от других фирм (в торговле есть УТ, например, в бухгалтерии та же конфигурация 1С:Бухгалтерия). Я знаю людей, которые много использовались и 1С:УТ и SAP в торговле. И вот 1С вспоминали, можно сказать, с любовью, после опыта с SAP. Так что, имхо, 1С не должно умереть, но вот трансформироваться во что-то более привлекательное им бы не помешало.
По ИДЕ оценивается не язык, а сама экосистема. И ущербные инструменты разработки, как и токсичное сообщество, а также закрытые и не полные материалы сильно снижаю комфортность разработки. Сравните комфортность разработки приложения под .NET Core и приложения под 1С платформу.
Работаю веб-разработчик (фул-стак), иногда занимаюсь связыванием 1С продуктов с моими веб-сервисами. Из-за этого иногда приходится что-то писать под разные конфигурации 1С. Так вот, опишу проблемы, почему я бы никогда не стал быть разработчиком 1С на полную ставку:
1) Устаревшие технологии и подходы, игнорирование архитектурных подходов и т.д. Подавляющее большинство приложений 1С - это монолит с кучей процедур делающих тоже, что и другая процедура, только с розовыми рюшечками.
2) Низкий уровень обучающих материалов. Платная база знаний, неполные материалы, многие учебники начинаются с конкретных примеров как сделать такую-то фигню, без описания концепции и подхода в целом.
3) Очень токсичное сообщество. Это прямо просто жесть - зайдите на мисту и на вопрос "Как сделать фичу N?" вам ответят: "Наймите разработчика." Если сказать, что ты разработчик, то тебя попытаются унизить, хорошо если дадут ответ, но скорее всего только унизят.
4) Проблемы с контролем версий. Отдельный вид, файлы кода в своих форматах, всё зачастую запрятано в бинарные файлы и т.д. Невозможно использовать подходы, применимые в почти любых других областях IT.
К плюсам стоит отнести нередко хорошие конфигурации, которые похоже разрабатывались с диким трудом и потом. Однако, в той же торговли решения сторонних разработчиков обычно и близко не стоит по возможностям с 1С:УТ, например.
В общем, 1С экосистема в целом - это набор хороших и не очень продуктов, построенных на устаревшей технически базе и управляемый слегка невменяемыми менеджерами из 10-х.
UPD: Вспомнил еще один момент. Среда разработки (конфигуратор) - ущербное поделие времен делфи-паскаль. Например, нельзя перенести курсор сдвигом вправо (он будет уходить в бесконечность). И там еще много таких стремных вещей, которые после студии/идеи кажутся пережитками прошлого из 0х-10х.
А вот, кстати, к коду на русском языке привыкаешь очень быстро.
Не надо такое учитывать. Верстальщик должен учитывать то, как выглядит сайт на различных устройствах в современных браузерах. А гадать что там накастомизирует пользователь - странное занятие.
Про это даже фильмы есть
Количество кусков и структурирование - это перпендикулярные параметры. Правильно выбранные слои абстракции, позволят вам описать систему в пару предложений текста и знание всей кодовой базы вам не нужно. А вот если для внесения изменения, вам нужно знать код целиком, то вы приехали. На приложении в 5к+ строк кода это уже будет трудно. На приложениях 100к+ строк - это будет ад, в котором любой улучшение или исправление будет вноситься человеко-неделями разработки и тестов.
napobo3 же написал "Вы сначала решаете какому уровню абстракции это изменение соответствует, потом его там вносите." И вот в хорошо спроектированной системе, где интерфейсы стоят там, где нужно, есть инверсия зависимостей, есть юнит-тесты, там изменения будет вносить не трудно.
Вот это, кстати, наверно самое важное. Опыт сеньора это как раз про то, чтобы писать всегда простой код так, чтобы он и задачу решал, и был расширяемым, и не был перегружен не нужными рюшечками. И так писать реально сложно, нужно не только знать инструмент, но быть еще немного вангой, догадываясь, куда может потом расширяться приложение.
Или перестала существовать...
Я так и не уловил связи между тем, что я моюсь пресной водой, а в Судане последние пара тысяч лет точно как ходили с ведром к колодцу, так и ходят...