А если нет фреймфорков? Ну вот нет и все. Есть платформа, есть язык (один или несколько), есть системные API, работающие с какими-то чудными системными объектами (типа *dtaara, *dtaq, *usrq, *usrspc, *usridx и т.п.) и все это крутится хрен знает где куда у вас доступ через эмулятор терминала:
И на все это навешано куча «нефункциональных требований». Что можно а что нельзя «иначе отключим газ».
Нужно решить задачу? А она занимает слишком много времени? Распараллель обработку. Но потоки использовать нельзя т.к. сопровождение их не может контролировать. Т.е. только запуском нескольких задач обработчиков. Но их придется контролировать, придется налаживать между ними межпроцессный обмен. Следить за ними как они работают. прибивать те, что перестали отвечать…
И все это на голимом системном API без никаких фреймворков.
Мир разработки очень многогранен. Одно дело вебразработка. Другое — разработка мобильных приложений. Третье — промавтоматизация (как встроенные системы, так и верхний уровень). Отдельная тема — мейнфреймы (большие коммерческие сервера на разных экзотических платформах типа той же IBM i (или z, хотя она ближе к общераспостраненным системам)
Или геймдев. Или еще что-то…
И в каждой сфере своя специфика. Где-то надо знать фреймворки (и уметь ими правильно пользоваться), а где-то надо вникать в тонкости платформенного API и архитектуры. Где-то придется всякими хитростями выживать максимум производительности из железяки и привыкать мыслить милли- и микросекундами и над каждым циклом думать «а нельзя ли его подсократить, а уложусь ли в таймаут, а что можно вынести за пределы отведенного таймаутом времени?»
А где-то голова болеть будет о том, а насколько вот эта операция нагружает систему? А нет ли тут лишнего переоткрытия файлов? А не закешировать ли прочитанные данные на всякий случай?
Не надо ориентироваться на чьи-то частные случаи. Реальность может оказаться куда более унылой.
Если вы твердо решили идти в программирование, то сразу настройтесь на то, что
— поначалу вы будете никем. с соотвествующей материальной составляющей
— чтобы стать кем-то нужно всегда копать чуть глубже чем требует задача и делать чуть больше чем от вас ждут. и делать это бы будете бесплатно в свое личное время
если вы к этому готовы, «значит вам туда дорога» (с) — вы готовы заниматься программированием потому что вам это действительно интересно. А, значит, вы будете свой интерес постоянно удовлетворять новыми знаниями и навыками и таким образом расти.
Сильно зависит от. Как всегда, как везде.
Хотел бы я посмотреть на человека, пытающегося что-то написать под мейнфрейм «после курсов java».
Все интересное в банке происходит в бекенде. А на фронтах… Там по большому счету что банк что не банк — нужно сделать некий среднеудобный для всех фейс, дергающий предложенный беком набор вебсервисов. Естественно, особого роста в таких условиях трудно ожидать.
Упоминал об этом. Работаю в банке. Для полноценной работы нужен доступ ко внутренней сети банка (которая не имеет выхода наружу — инет с рабочих компов доступен только через «безопасный браузер», который по сути есть удаленный доступ к браузеру, работающему где-то на отдельно выделенном компе), а именно:
доступ к тестовому серверу через эмулятор терминала IBM5250
Jira
Confluence
Bitbucket
Jenkins
Artifactory
внутренняя IP-телефония и привязанный к ней Cisco Jabber
Есть два варианта уделенной работы — через VPN и через «удаленное рабочее место сотрудника». ни тот ни другой вариант не обеспечивают полного доступа ко всем необходимым ресурсам внутренней сети. Т.е. полноценной работы не получится.
Ну у нас совсем до трепа не принято опускаться. Ну, иногда, в виде перерыва минут на 5-10 бывает, но далеко не каждый день.
А что дома дичаешь — согласен полностью. Года три когда-то просидел, потом попросился в контору. Просто чтобы была хоть какая-то видимость «это рабочее время, это нерабочее». Иначе выгораешь быстро…
У разработчиков не бывает вопросов, требующих решения быстрее чем за сутки
Очень индивидуально. Вот одна из задач сейчас в разработке есть. Получил FSD, посмотрел. Алгоритм не нравится, вижу, что могу сделать оптимальнее если немного с другой стороны зайти. Но нужно обсудить тонкости с аналитиком. И что, сутки ждать? Нет. Быстрый созвон и обсуждение тонких моментов.
Бывает и наоборот — аналитику нужна моя консультация по определенным моментам.
А бывают еще дефекты промсреды, когда бросаешь все текущее и делаешь хотфикс. Там вообще все в реальом времени идет — и аналитика и разработка и общение постоянное (вплоть до того, что я под отладчиком сижу, экран рашарен и вдвоем с аналитиком смотрим как оно себя в разных ситуациях ведет).
Я бы не стал рассматривать только граничные варианты. Офис может быть «распределенным» — у нас, например, разработчики распределены межу Москвой, Екатом и Питером. Что совершенно не мешает полноценно общаться в процессе как один на один (обычно это обсуждение задачи с аналитиком), так и в режиме конференции (групповые митапы или обсуждение крупных сложных задач).
Часто общение идет с расшариванием экрана чтобы показать что как где работает или порисовать какие-то схемы.
Есть еще еженедельные доклады разработчиков — что-то типа семинаров на различные интересные темы, своеобразный обмен опытом. Но тут подключаешься когда тема интересна самому.
Живое же общение с коллегами обычно на другие темы — обмен опытом (я что-то у кого-то спросил, у меня кто-то что-то спросил), помощь молодым разработчикам и т.п.
Идеальный вариант для меня — работа в офисе, но что-бы все коллеги были на удалёнке (к примеру, в других офисах)
Ну вот сейчас фактически так и работаю. В большинстве случаев аналититки по задачам, над которыми работаю в Москве. Сам в Екате.
Поскольку коммуникации налажены очень хорошо, то никаких проблем не возникает.
Совсем удаленка в наших условиях сложна, особенно для бэкенд разработчиков, работающих на мейнфрейм. Это уже заморочки УИБа. Да, есть VPN, есть Удаленное Рабочее Место Сотрудника, но ни то ни другое не дает 100% полноценного доступа ко всем информационным сиcтемам (тестовый сервер, Jira, Bitbucket, Jenkins, Artifactory, Confluence, внутренняя телефония + Cisco Jabber...)
На прошлой работе был период когда полностью на удаленке. Выдержал несколько лет, потом попросил рабочий угол в конторе куда мог бы приходить со своим ноутом. Фактически получилось свободное посещение — нужно остаться дома — работаю из дома. Удобнее собраться и пойти в контору — работаю в конторе.
При смене работы в финальный шортлист вышли два места — 100% удаленка на небольшую компанию и 100% галеры в крупном банке. По деньгам было примерно равноценно, в моменте даже первый вариант выглядел привлекательнее.
Но из стратегических соображений выбрал второй (чему до сих пор рад, вот скоро уж три года как) — работа более живая, более интересная, больше нового, больше перспектив роста.
В целом же удаленку рассматриваю как один из вариантов организации рабочего процесса, имеющий свои плюсы и минусы (в большинстве случаев субъективные). Не более того.
Поскольку юношеский максимализм уже давно перешел в вялотекущую фазу :-) за себя не могу сказать что «буду рассматривать только офисную или только удаленную работу». Ни тот ни иной вариант меня не пугает, но и не является исключительно определяющим. Всегда буду рассматривать всю совокупность условий, предлагаемых работодателем.
Ну и однозначно не разделяю
Будущее за удаленной работой и это будущее уже наступило. Теперь умение работать удаленно – компетенция, за которую можно нанимать на работу, а возможность предоставления удаленного рабочего места – конкурентное преимущество, за которое сотрудники выбирают вашу компанию.
Мнение очень однобокое. Наверное, какая-нибудь мобильная разработка такое позволяет. А вот, скажем, банковское IT уже сложнее — там для бэк разработчиков нужен терминальный доступ к тестовому серверу (а он хоть и тестовый, но там много чего всего интересного может быть чего наружу выпускать совсем никак нельзя). Который во внутренней сети. За безопасность которой УИБ очень переживает т.к. из внутренней сети есть и к боевым серверам доступ…
Или с предыдущего места работы пример — разработка софта, привязанного к определенной аппаратуре. Т.е. тестирование на специальном стенде-макете. Который нужно где-то разместить. А если в процессе тестирования нужна еще и отладка, то будь добр приехать туда где стенд и поработать там. Или дорабатывай свой софт так, чтобы иметь возможность удаленно видеть что он внутри себя делает в реальном времени (я к этому пришел в конце концов — это помогло и потом на реальных объектах решать проблемы).
В общем, не так все просто и универсально с удаленкой…
Я, собственно, к тому, что при работе в команде, что в офисе, что на удаленке, рабочее время всей команды должно быть более-менее согласовано на случай возникновения вопросов, требующих быстрого решения.
Тут еще зависит от характера работы. Я работаю не на удаленке (хотя и на ней работал тоже и ничего против не имею, мне по большому счету практически все равно где), но у нас команда разработчиков раскидана по трем городам. Да, при этом отлично налажена связь — почта, мессенджер, видео, телефония, Jira… Но общаться с коллегами приходится постоянно. То у меня к ним вопросы, то у них ко мне, то групповая встреча с обсуждением насущного…
Так вот, а теперь представьте себе ситуацию, когда каждый работает в своем графике. Нужно осудить проблему, а у человека сейчас послеобеденный сон. Или у него ко мне вопросы, а я в настроении погулять прямо сейчас…
Так что вся свобода режима на удаленке работает когда разработчик фактически обособлен в рамках поставленной ему задачи.
В статье Skip Lists: A Probabilistic Alternative to Balanced Trees автор приводит сравнения с деревьями. Время поиска на уровне деревьев, время добавления и удаления кратно меньше.
В целом, в случае когда содержимое списка постоянно меняется (элементы постоянно добавляются-удаляются) SkipList будет предпочтительнее, особенно на больших объемах (я тестировал на полутора-двух миллионах элементов, правда, без сравнения с деревьями и абсолютные цифры не будут показательны т.к. тест проходил на 18-ядерном SMT8 IBM PowerS 924 с 1800 Гб RAM)
Я не очень хорошо представляю себе вашу задачу, посему трудно судить насколько ваш подход эффективен (уверен, что весьма эффективен). Но, допустим, мы вставляем
list.add(42, «Forty two»)
а потом
list.add(42, «another Forty two»)
и предыдущий уже будет ни разу не 42, а уже 43…
У меня задачи обычно связаны с кешированием данных — если с каким-то справочником (на 10-20-30 тысяч записей) приходится работать многократно, то эффективнее один раз втянуть его в память, а потом уже работать с памятью.
Или вот такая была задачка — делалась SQL выборка с необходимостью сортировки по нескольким полям. Проблема была в том, что эти поля не индексированы, а в выборку могло попадать 50 и более тысяч записей.
Выборка без сортировки с занесением результатов в SkipList с ключом по набору нужных полей и последующей обработкой по списку от начала к концу оказалось быстрее в 5-6 раз.
Фактически, SkipList есть двусвязный сортированный список с возможностью быстрого поиска по ключу или положению элемента в списке.
У SkipList есть расширение, описанное в статье A SkipList Cookbook — 3.4 Linear List Operations — фактически это виртуальный индекс, позволяющий быстро искать элемент не только по ключу, но и по его положению в списке.
Другое дело, что это не ваш случай т.к. при добавлении элемента в список «положить» его в нужную позицию не получится — он будет размещен там, где ему положено быть по порядку сортировки относительно остальных элементов.
Не зная всех подробностей вашей задачи, мне сложно что-либо предполагать относитльно ее решения, но складывается впечатление, что вам подошел бы массив + индекс к нему. Ибо операция list.add(42, «Forty two») подразумевает что у вас в списке уже есть как минимум 41 элемент. А если у вас их на момент добавления, скажем, всего 10? что будет между последним (10-м) элементов массива и 42-м (добавляемым)? Пустые узлы?
С производительностью там не так просто. Деревья требуют постоянной перебалансировки иначе они могу выродиться в обычный список (представьте, что вы в двоичное дерево добавляете последовательно 50 узлов со значениями от 1 до 50-ти — как оно будет выглядеть в конце, если его не перестраивать?)
SkipList дает небольшой проигрыш по времени поиска (ибо поиск по дереву, при условии что оно сбалансировано, является двоичным, т.е. самым быстрым из возможных), но выигрывает в добавлении и удалении элементов т.к. не требует никаких дополнительных действий по оптимизации дерева.
Я правильно понимаю, что вам важен порядок следования элементов?
В таком случае я бы делал по классической схеме БД — «хранилище» + индекс.
В качестве хранилища обычный двусвязный список, куда заносятся элементы по мере их поступления, в качестве индекса — ну скажем, SkipList где ключ — параметр, по которому вы этот элемент будете искать, а данные — указатель на элемент двусвязного списка, где хранится информация.
Тогда проходом по двусвязному списку мы может получить элементы в том порядке, в котором они к нам пришли, а по скиплисту всегда может быстро найти элемент по ключу.
Недостаток деревьев в необходимости их балансировки.
Я для подобных задач пользую SkipList, расширенный виртуальным индексом. Неплохой баланс скорости на всем спектре операций — добавление, удаление, поиск.
На нем у меня реализовано:
индексированный список пар «ключ-данные»
сортированный список (когда данные одновременно являются ключом)
набор — множество однотипных элементов с возможностью таких операций над набором как пересечение, объединение, разность наборов.
RDi здесь поставляется всего лишь как IDE для более комфотной разработки. Никто не мешает писать текст прямо на сервере, пользуясь встроенным редактором SEU. Сборка программы в любом случае происходит на сервере. Вне зависимости от того, где пишется ее текст. Если работаем в RDi, то пишем текст, забрасываем его на сервер и там запускаем компилятор.
Самодостаточность — это значит, что покупая сервер мы сразу получаем и железо и ОС, в которую интегрирована и БД и компиляторы и все средства администрирования. Ничего другого для работы нам уже не надо.
БД там является неотъемлемой частью системы. Те же транзакции поддерживаются на уровне ОС. Любая программа может быть использована в качестве встроенной функции БД.
Аналогично с компиляторами — они не поставляются как-то отдельно, они есть в составе ОС.
И на все это навешано куча «нефункциональных требований». Что можно а что нельзя «иначе отключим газ».
Нужно решить задачу? А она занимает слишком много времени? Распараллель обработку. Но потоки использовать нельзя т.к. сопровождение их не может контролировать. Т.е. только запуском нескольких задач обработчиков. Но их придется контролировать, придется налаживать между ними межпроцессный обмен. Следить за ними как они работают. прибивать те, что перестали отвечать…
И все это на голимом системном API без никаких фреймворков.
Или геймдев. Или еще что-то…
И в каждой сфере своя специфика. Где-то надо знать фреймворки (и уметь ими правильно пользоваться), а где-то надо вникать в тонкости платформенного API и архитектуры. Где-то придется всякими хитростями выживать максимум производительности из железяки и привыкать мыслить милли- и микросекундами и над каждым циклом думать «а нельзя ли его подсократить, а уложусь ли в таймаут, а что можно вынести за пределы отведенного таймаутом времени?»
А где-то голова болеть будет о том, а насколько вот эта операция нагружает систему? А нет ли тут лишнего переоткрытия файлов? А не закешировать ли прочитанные данные на всякий случай?
Ну и так далее. И все это «мир разработки».
Если вы твердо решили идти в программирование, то сразу настройтесь на то, что
— поначалу вы будете никем. с соотвествующей материальной составляющей
— чтобы стать кем-то нужно всегда копать чуть глубже чем требует задача и делать чуть больше чем от вас ждут. и делать это бы будете бесплатно в свое личное время
если вы к этому готовы, «значит вам туда дорога» (с) — вы готовы заниматься программированием потому что вам это действительно интересно. А, значит, вы будете свой интерес постоянно удовлетворять новыми знаниями и навыками и таким образом расти.
Хотел бы я посмотреть на человека, пытающегося что-то написать под мейнфрейм «после курсов java».
Все интересное в банке происходит в бекенде. А на фронтах… Там по большому счету что банк что не банк — нужно сделать некий среднеудобный для всех фейс, дергающий предложенный беком набор вебсервисов. Естественно, особого роста в таких условиях трудно ожидать.
Ваяем помаленьку :-) Что-то на RPG, что-то на C/C++, что-то на CL…
Нет, понятно что все можно. Когда другого выхода нет. Но зачем растягивать на сутки решение вопроса, который решается за 15 минут общения.
Я уже работал в таком режиме — не скажу чтобы это было очень продуктивно. Но там команда была небольшая и в целом все было терпимо.
А здесь все достаточно динамично происходит, загрузка большая и временные лаги на решение простых вопросов напрягают ощутимо.
доступ к тестовому серверу через эмулятор терминала IBM5250
Jira
Confluence
Bitbucket
Jenkins
Artifactory
внутренняя IP-телефония и привязанный к ней Cisco Jabber
Есть два варианта уделенной работы — через VPN и через «удаленное рабочее место сотрудника». ни тот ни другой вариант не обеспечивают полного доступа ко всем необходимым ресурсам внутренней сети. Т.е. полноценной работы не получится.
А что дома дичаешь — согласен полностью. Года три когда-то просидел, потом попросился в контору. Просто чтобы была хоть какая-то видимость «это рабочее время, это нерабочее». Иначе выгораешь быстро…
Очень индивидуально. Вот одна из задач сейчас в разработке есть. Получил FSD, посмотрел. Алгоритм не нравится, вижу, что могу сделать оптимальнее если немного с другой стороны зайти. Но нужно обсудить тонкости с аналитиком. И что, сутки ждать? Нет. Быстрый созвон и обсуждение тонких моментов.
Бывает и наоборот — аналитику нужна моя консультация по определенным моментам.
А бывают еще дефекты промсреды, когда бросаешь все текущее и делаешь хотфикс. Там вообще все в реальом времени идет — и аналитика и разработка и общение постоянное (вплоть до того, что я под отладчиком сижу, экран рашарен и вдвоем с аналитиком смотрим как оно себя в разных ситуациях ведет).
Часто общение идет с расшариванием экрана чтобы показать что как где работает или порисовать какие-то схемы.
Есть еще еженедельные доклады разработчиков — что-то типа семинаров на различные интересные темы, своеобразный обмен опытом. Но тут подключаешься когда тема интересна самому.
Живое же общение с коллегами обычно на другие темы — обмен опытом (я что-то у кого-то спросил, у меня кто-то что-то спросил), помощь молодым разработчикам и т.п.
Он, конечно, заблокирован, но HR'ов Российских компаний там предостаточно пасется :-)
Ну вот сейчас фактически так и работаю. В большинстве случаев аналититки по задачам, над которыми работаю в Москве. Сам в Екате.
Поскольку коммуникации налажены очень хорошо, то никаких проблем не возникает.
Совсем удаленка в наших условиях сложна, особенно для бэкенд разработчиков, работающих на мейнфрейм. Это уже заморочки УИБа. Да, есть VPN, есть Удаленное Рабочее Место Сотрудника, но ни то ни другое не дает 100% полноценного доступа ко всем информационным сиcтемам (тестовый сервер, Jira, Bitbucket, Jenkins, Artifactory, Confluence, внутренняя телефония + Cisco Jabber...)
На прошлой работе был период когда полностью на удаленке. Выдержал несколько лет, потом попросил рабочий угол в конторе куда мог бы приходить со своим ноутом. Фактически получилось свободное посещение — нужно остаться дома — работаю из дома. Удобнее собраться и пойти в контору — работаю в конторе.
При смене работы в финальный шортлист вышли два места — 100% удаленка на небольшую компанию и 100% галеры в крупном банке. По деньгам было примерно равноценно, в моменте даже первый вариант выглядел привлекательнее.
Но из стратегических соображений выбрал второй (чему до сих пор рад, вот скоро уж три года как) — работа более живая, более интересная, больше нового, больше перспектив роста.
В целом же удаленку рассматриваю как один из вариантов организации рабочего процесса, имеющий свои плюсы и минусы (в большинстве случаев субъективные). Не более того.
Поскольку юношеский максимализм уже давно перешел в вялотекущую фазу :-) за себя не могу сказать что «буду рассматривать только офисную или только удаленную работу». Ни тот ни иной вариант меня не пугает, но и не является исключительно определяющим. Всегда буду рассматривать всю совокупность условий, предлагаемых работодателем.
Ну и однозначно не разделяю
Мнение очень однобокое. Наверное, какая-нибудь мобильная разработка такое позволяет. А вот, скажем, банковское IT уже сложнее — там для бэк разработчиков нужен терминальный доступ к тестовому серверу (а он хоть и тестовый, но там много чего всего интересного может быть чего наружу выпускать совсем никак нельзя). Который во внутренней сети. За безопасность которой УИБ очень переживает т.к. из внутренней сети есть и к боевым серверам доступ…
Или с предыдущего места работы пример — разработка софта, привязанного к определенной аппаратуре. Т.е. тестирование на специальном стенде-макете. Который нужно где-то разместить. А если в процессе тестирования нужна еще и отладка, то будь добр приехать туда где стенд и поработать там. Или дорабатывай свой софт так, чтобы иметь возможность удаленно видеть что он внутри себя делает в реальном времени (я к этому пришел в конце концов — это помогло и потом на реальных объектах решать проблемы).
В общем, не так все просто и универсально с удаленкой…
Так вот, а теперь представьте себе ситуацию, когда каждый работает в своем графике. Нужно осудить проблему, а у человека сейчас послеобеденный сон. Или у него ко мне вопросы, а я в настроении погулять прямо сейчас…
Так что вся свобода режима на удаленке работает когда разработчик фактически обособлен в рамках поставленной ему задачи.
В целом, в случае когда содержимое списка постоянно меняется (элементы постоянно добавляются-удаляются) SkipList будет предпочтительнее, особенно на больших объемах (я тестировал на полутора-двух миллионах элементов, правда, без сравнения с деревьями и абсолютные цифры не будут показательны т.к. тест проходил на 18-ядерном SMT8 IBM PowerS 924 с 1800 Гб RAM)
Я не очень хорошо представляю себе вашу задачу, посему трудно судить насколько ваш подход эффективен (уверен, что весьма эффективен). Но, допустим, мы вставляем
list.add(42, «Forty two»)
а потом
list.add(42, «another Forty two»)
и предыдущий уже будет ни разу не 42, а уже 43…
У меня задачи обычно связаны с кешированием данных — если с каким-то справочником (на 10-20-30 тысяч записей) приходится работать многократно, то эффективнее один раз втянуть его в память, а потом уже работать с памятью.
Или вот такая была задачка — делалась SQL выборка с необходимостью сортировки по нескольким полям. Проблема была в том, что эти поля не индексированы, а в выборку могло попадать 50 и более тысяч записей.
Выборка без сортировки с занесением результатов в SkipList с ключом по набору нужных полей и последующей обработкой по списку от начала к концу оказалось быстрее в 5-6 раз.
Фактически, SkipList есть двусвязный сортированный список с возможностью быстрого поиска по ключу или положению элемента в списке.
Другое дело, что это не ваш случай т.к. при добавлении элемента в список «положить» его в нужную позицию не получится — он будет размещен там, где ему положено быть по порядку сортировки относительно остальных элементов.
Не зная всех подробностей вашей задачи, мне сложно что-либо предполагать относитльно ее решения, но складывается впечатление, что вам подошел бы массив + индекс к нему. Ибо операция list.add(42, «Forty two») подразумевает что у вас в списке уже есть как минимум 41 элемент. А если у вас их на момент добавления, скажем, всего 10? что будет между последним (10-м) элементов массива и 42-м (добавляемым)? Пустые узлы?
С производительностью там не так просто. Деревья требуют постоянной перебалансировки иначе они могу выродиться в обычный список (представьте, что вы в двоичное дерево добавляете последовательно 50 узлов со значениями от 1 до 50-ти — как оно будет выглядеть в конце, если его не перестраивать?)
SkipList дает небольшой проигрыш по времени поиска (ибо поиск по дереву, при условии что оно сбалансировано, является двоичным, т.е. самым быстрым из возможных), но выигрывает в добавлении и удалении элементов т.к. не требует никаких дополнительных действий по оптимизации дерева.
В таком случае я бы делал по классической схеме БД — «хранилище» + индекс.
В качестве хранилища обычный двусвязный список, куда заносятся элементы по мере их поступления, в качестве индекса — ну скажем, SkipList где ключ — параметр, по которому вы этот элемент будете искать, а данные — указатель на элемент двусвязного списка, где хранится информация.
Тогда проходом по двусвязному списку мы может получить элементы в том порядке, в котором они к нам пришли, а по скиплисту всегда может быстро найти элемент по ключу.
Я для подобных задач пользую SkipList, расширенный виртуальным индексом. Неплохой баланс скорости на всем спектре операций — добавление, удаление, поиск.
На нем у меня реализовано:
индексированный список пар «ключ-данные»
сортированный список (когда данные одновременно являются ключом)
набор — множество однотипных элементов с возможностью таких операций над набором как пересечение, объединение, разность наборов.
RDi здесь поставляется всего лишь как IDE для более комфотной разработки. Никто не мешает писать текст прямо на сервере, пользуясь встроенным редактором SEU. Сборка программы в любом случае происходит на сервере. Вне зависимости от того, где пишется ее текст. Если работаем в RDi, то пишем текст, забрасываем его на сервер и там запускаем компилятор.
Самодостаточность — это значит, что покупая сервер мы сразу получаем и железо и ОС, в которую интегрирована и БД и компиляторы и все средства администрирования. Ничего другого для работы нам уже не надо.
БД там является неотъемлемой частью системы. Те же транзакции поддерживаются на уровне ОС. Любая программа может быть использована в качестве встроенной функции БД.
Аналогично с компиляторами — они не поставляются как-то отдельно, они есть в составе ОС.