Виктор П.

Никак.
Ограничения безопасности

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

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

мне понравилась коротенькая книжка
Асинхронное программирование в C# 5.0 | Дэвис Алекс
Там всё разложено по полочкам не только под c#, сама концепция
https://www.ozon.ru/product/asinhronnoe-programmir...

Привет,
Нужно внутри функции sendMessage обработать такую команду:

function sendMessage() {
            var messageField = document.getElementById("message");
            var userNameField = document.getElementById("username");

if(messageField  == '/clear'){
   var chat = document.getElementById("messages");
   chat.value = '';
} else {
   var message = userNameField.value + ":" + messageField.value;
   ws.send(message);
}
            messageField.value = '';
        }

на подобии ментальной карты

Ну и возьмите майнд мап, например, https://www.mindmeister.com/

Привет,
Проблема существует практически на всех предприятиях, но обычно это разные системы, типа 1с на кадры, самописная c# по документам и какая-нибудь готовая опен-сорц система поддержки на php. Ваш вариант, что всё написано на одной технологии благо, используйте это, заворачивайте в нугет библиотеки.
Про esb - все очереди используются для синхронизации данных. То есть, у вас изменился некий сотрудник в кадрах, сохраняется не напрямую в бд, а через очередь. Другие системы так же подписаны на эту очередь и обновление сущности сотрудника идёт во всех системах, которые хранят дубли необходимых им данных. Как вы понимаете, тут куча накладных расходов и нештатных ситуаций. За этим нужно следить и как-то восстанавливать/докачивать данные. Тем не менее, это самый правильный вариант, ибо в противном случае синхронизацию данных делают кастылями через вьюхи/джобы/хранимки и как только отвратительно не делают. В общем, если хватает скиллов - делайте так, будут независимые рабочие приложения.
По общению через апи - там нет проблем с какими-то маленькими и атомарными операциями. Проблемы начинаются когда необходимы _распределённые транзакции_ погуглите про это, как реализовывают и оцените насколько тяжелее будет разработка. Вторая тут проблема - это отчёты, тупо джоины. Вам нужно выгрузить какую-то консолидированную инфу из одной системы, вы делаете, но в ней у вас только айдишники пользователей. Либо вы эти айдишники отправляете в сервис кадров и получаете развёрную инфу по каждому, либо на каждый такой запрос вообще грузите полный список пользователей. А потом ещё говорят, нужно исключить данные по пользователям на время их отсутствия. Опять же эти данные в сервисе кадров и, в общем, нужно лепить какой-то большой снежный ком не из снега. Окей, если прям вопрос с отчётами, можно будет заводить какие-то консолидированные хранилища и все системы будут туда сливать данные, но вот при обычном использовании вам всё равно потребуется делать большие джоины, какие с этим косяки я примерно описал.
По варианту общих сервисов, я за него из-за простоты:
Хранить строки подключений нужно в каждом проекте - это не проблема
Дублировать бизнес-логику не нужно, выносите её так же в общие сервисы
Обновлять будет нужно оба сервера, если в общем сервисе баг. Тут разговор, очевидно, про "баг на проде" - из-за общего кода будет баг на обоих продакшенах. Окей, как часто у вас возникают такие ситуации и насколько долго обновить два прода вместо одного?

Каким образом вы работаете с базой и что за база вообще, ms sql?
Если через sql management studio вы создаёте таблицы, каким образом вы подключаетесь к базе?
Попробуйте подключиться к этому серверу (localdb)\mssqllocaldb с виндовым логином и паролем. Если подойдёт, то используйте его и в строке подключения
Подключение через DataSource было ранее в .net framework через веб конфиг. Я не разбирался с этим особо, возможно, они равнозначны. В .net core строки подключения пишутся в appsettings.json примерно так:
"ConnectionStrings": {
"AppConnection": "Server=(localdb)\\mssqllocaldb;Database=game;Trusted_Connection=True;MultipleActiveResultSets=true"
}
Тут используется виндовый логин/пароль. Если вы создали своего пользователя, то вместо Trusted_Connection=True; вбиваете User ID=root;Password=root;
Дополнительный вопрос, зачем вам вообще ado.net, когда есть entity framework?

Под слово "стартап" подгребают очень много всего.
Ваш случай, принять участие в чьём-то опен-сорц или хобби проекте. Ищите небольшие проекты в соц сетях, каналах телеграмма, которые вам интересны.
Например, мне попался чувак, который делает танк, печатает детали на принтере, закупает оборудование, ведёт блог (в телеге просто). Единомышленники в таких проектах всегда нужны

Майнд мап тема прикольная, когда есть какие-то идейки и ещё не до конца понятно как и что будет. Если у вас уже завершённая мысль, можете просто составить ТЗ по ГОСТу, этот нудный документ должен быть понятен не только вам, но и другим участником (а когда вы через полгода смотрите на своё творение, вы уже как будто другой человек)
Так же можно просто нарезать задач, например в диаграмму ганта

Если текущие решения устраивают, то надо брать их. Свой движок в любом случае будет делать дороже (ну а по времени вообще не сравнить).
Битрикс изначально идёт как црм для продажников. Да, теоретически, туда можно впихнуть таски для программистов, но я такого не встречал. Облачное решение стоит довольно дёшево. Коробочное чуть подороже, там идёт лицензия на 1 или 2 года, затем эту лицензию можно не продлевать просто. Продлить, при необходимости. Если у вас никаких кастомизаций нет, тогда и поддержка будет не нужна.
Другое дело, что для управления командами разработки есть специализированные решения, из крупных Jira и Microsoft TFS (сейчас Azure что-то там). Есть и пиратские версии для tfs какого-нибудь 2014 года (неподдерживаемые), есть разного рода хитрости, например, регистрироваться в жире по студенческой почте и продлевать. Менее крупных проектов очень много, цены у всех достаточно лояльные.

Привет, понимаю, что пост древний, но всё же интересный.
Видел, что хотели один из комментариев ответом сделать, хотя ответа до сих пор нет.
Как в итоге поступили, как получилось?

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

Либо вы платите себе зарплату как наёмному сотруднику по рыночной цене, если есть бюджет на зарплату, либо вместо зарплаты выдаёте себе "долговую расписку", если бюджета на зп нет. Это классический вариант, когда у вас есть несколько инвесторов, вы на берегу составляете план, что надо столько денег, через столько времени компания будет приносить столько прибыли, которая будет делиться между инвесторами в соответствии с первоначальными вложениями. Тут есть много классических проблем, которые начинаются, когда через запланированное время вы не выходите на ожидаемую прибыль или, что ещё хуже, нужны ещё инвестирования и всякие пересчёты долей с обидами и скандалами. Что-то вроде, я тебе дал 2 миллиона, ты обещал 50% прибыли. Проект до сих пор не запущен, ты говоришь, что нужно найти где-то ещё 2 миллиона для запуска и у меня будет 25% прибыли. Мы так не договаривались, ищи дополнительные средства где хочешь, это не мои проблемы, за мной должно остаться 50%. Ну вроде такого.
Второй вариант, эджайл. Когда не нужно искать сразу всю сумму на разработку, достаточно докидывать необходимые суммы на какие-то определённые работы. Надо купить стулья - купил Петя, оплатить работу фрилансера - оплатил Вася. Ежемесячная оплата труда сотрудников - платит Игорь. До выхода на точку самоокупаемости все эти расходы копятся в одном месте. После выхода на самоокупаемость фиксируется себестоимость продукта. Считаются доли в процентах, согласно вложению всех участников. Чистая прибыль пилится в соответствии с долями. Довольно логично, как по мне.

Вот тут ещё было подобное обсуждение Нормальная ли у меня теория по оценке вклада участников в стартап?

Привет, не вижу ответа.
Что в итоге решили делать?
До чего договорились?

Скептиков всегда будет много. Кого-то обманули, кто-то обжёгся на подобном.
Забавляют ответы, типа "руководитель может нанять кого-то вместо вас" и подобные. При этом в соседних ветках задаются вопросы "где найти такого человека с горящими глазами" - ответом в этих ветках звучит "нигде".

Привет, вопрос старый, но всё ж таки, что в итоге решилось?
Нормальная ли у меня теория по оценке вклада участников в стартап? - вот тут есть ответ на этот вопрос (который с карточками), ваш случай

Ну как, сделали что-нибудь?
Не надо придумывать сложные вещи. Вам нужно остановиться на первой части - "Есть пользователи, чей характер нам известен(в той или иной степени)" - вы можете предоставить пользователю разжёванную информацию, как и из чего он складывается и на что влияет. Какие у пользователя ценности в жизни.
И дальше давать некие полезные советы, какой тип работы больше подходит пользователю
Какие недостатки у него есть, которые он не замечает и что нужно подтянуть
Какие больные точки есть, чтобы избегать примитивного манипулирования (противопоставить себя гаданию и колдунам)
В том числе, научить пользователя самому определять характер/цели партнёра, чтобы выбрать себе пару самостоятельно.

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