Привет, ну, например, подчинённый хочет увеличения з/п. У него есть непосредственный руководитель (обычно это тимлид), который, так же обычно, не имеет прямого доступа к фонду оплаты, он лишь может давать рекомендации вышестоящему руководству, что данному сотруднику необходимо выдать повышение. В статье как раз про это идёт акцент, что под рукой сразу будут доступны какие-то достижения сотрудника, если фиксировать их по факту поступления (приведённые в статье примеры мне самому не нравятся, но смысл достаточно передан). Если таких заметок нет, то надо будет что-то доставать из памяти, и, опять же, это указано, за всеми не запомнишь, что-то забудешь, да и на восстановление истории событий при отсутствии заметок уйдёт какое-то лишнее время.
Тут, на самом деле идёт торговля, тимлид торгуется за своего подчинённого и должен делать это хорошо, тогда, несомненно, авторитет будет расти. Видно, что у такого тимлида есть команда, за которую он переживает и решает подобного рода вопросы.
Так же, практически в каждой компании есть какие-либо подведения итогов. Пусть даже раз в год перед новым годом. Не надо тратить время на сбор информации, достаточно бегло оглядеть такие записи и можно сказать несколько приятных слов, какие ребята молодцы, выделив наиболее интересные или сложные решения, которые удалось реализовать. Таким образом видно, опять же, что этот менеджер печётся о своих подчинённых, ничего не забывает, то есть они работают не напрасно. Это приятно и это, несомненно, увеличивает авторитет.
Так же и увеличивает авторитет тимлида в глазах руководства, так как может сказать коротко и по делу, с аргументами, чем занимается его команда и почему они молодцы, в сравнении с другим тимлидом, который обычно скажет что-то вроде «год был тяжёлый, кто дожил до конца, тот молодец».
Эти довольно простые советы всего лишь вести своевременные заметки очень полезны в первую очередь тимлидам, которые вышли из технических специалистов и даже не задумываются, что теперь всё то, что я написал выше, лежит на их хрупких плечах, так как в явном виде они никогда и нигде не прописаны, но через какое-то время всегда всплывают. И если новоиспечённый руководитель будет к ним готов, это показатель, что он справляется со своей работой на отлично, что так же повышает авторитет )
Не знаю, что так в комментариях агрятся на автора. Да, ребята, вы можете считать, что тимлид обязан иметь определённый набор функциональных обязанностей. Но по факту, в разных компаниях обязанности сильно различаются. Обычно, чем меньше компания, тем больше функций ложиться на плечи тимлида. И вот недавний технический специалист, отработав полгода тимлидом (повторяю, он может называться архитектором, руководителем разработки или отдела, оно всё тимлид), в общем, начинают прилетать разного рода вопросы, типа кто-то хочет з/п себе поднять из подчинённых, либо начальник говорит: «мне вышестоящий начальник сказал отчёт дать, что там в вашем проекте творится (не придирайтесь только к словам, пожалуйста, тут надо читать так: пришлите наиболее интересные моменты, что вы реализовали за пол года)», и это нормально, что вышестоящий не разбирается во всех аспектах и тонкостях. Да, надо лезть в жиру, пробегаться, фильтровать задачи, достать всё можно, но при наличии таких записей на оформление письма уйдёт 20 минут, а при ковырянии хистори потратится несколько часов.
И с зарплатой подчинённого, с такими заметками сразу есть аргументы для вышестоящего руководства, какие важные/полезные штуки реализовал этот самый подчинённый и почему ему необходимо повысить зарплату. Вместо мычания «ну он там работал что-то норм, делает свои задачи», 10 минут беглого осмотра и есть ясные факты, которые с последнего грейда за всех ребят запомнить невозможно
В общем, советы в статье даны дельные, вести заметки по таким вещам заблаговременно не составит труда, но даст много реальной пользы и поднимет профессионализм тимлида в глазах вышестоящего руководства.
Привет, есть стартап акселератор, как они себя называют ФРИИ, у них есть продукт как раз на тему статьи edu.iidf.ru — несколько раз получал рассылку, идеи там были откровенно убогие
Мне тоже приходило аналогичное сообщение от сослуживца, с которым перестали общаться пару лет, но в контакте висим. Достаточно спросить о чем-то специфичном, о чем знаем только мы вдвоём. В моём случае я спросил «как ротного звали?», писать сразу перестали. С неофициальными кличками должно работать почти всегда, к примеру, какая кликуха(прозвище) у Валентиныча? Или, наоборот, как зовут «Косого»?
Действительно, раньше я вчитывался в статьи на хабре, теперь уже просто пробегаюсь глазами, хватает. Практически все наступают на одни и те же грабли и создают (или пытаются создать), как вы говорили, «более совершенные каменные топоры». Возьмем, к примеру, чат. В примитивном виде алгоритм общения с ботом выглядит так: есть набор готовых фраз (к примеру, 20 штук) и на любую вашу фразу приводится рандомная из этого набора. Далее алгоритм усложняется, появляется 100 фраз и добавляется некая логика, что если присутствует какое-то слово, то берется фраза из первого десятка, если другое слово, то берется фраза из второго десятка. Фактически, это аналог китайской комнаты, вы сидите, вам под дверь просовывается фраза из китайских иероглифов, а у вас есть словарь китайских фраз. В первом случае вы отвечаете рандомной фразой. Во втором случае у вас появляются свои записи, что, вот если такой иероглиф есть, то нужно выбирать фразы из конца книги. Что же дают нам нейронные сети? По сути они пропускают через себя терабайты информации. Вместо одного китайского разговорника их будет много. А в журнал подсказок будет записываться куча информации о статистических зависимостях (корреляциях) между иероглифами. Таким образом, нейронные сети лишь выполняют работу по второму алгоритму более качественно. Но сам алгоритм не усложняется и не меняется, а проблема как раз в том, что алгоритм изначально неверный.
Невозможно описать язык, используя слова из этого языка. К примеру, возьмем толковый словарь — мы не можем прогнать его через нейронные сети и надеяться, что сеть сама выделит смысл слов, этого не будет никогда, получится лишь имитация. Может получиться хорошая, но это не то, что нужно.
Первое, что нужно сделать, это научить машину выделять смысл слов. Можно это представить, когда мы (русскоговорящие и мыслящие на русском) начинаем изучать другой язык, к примеру, английский. Нам говорят, что стол — table. После этого факта, когда в тексте встречается слово table, я вспоминаю, что эти буковки значат на моём родном языке, представляю себе мысленно этот стол, и вместе с этим вытаскивается вся физическая информация об этом физическом объекте — диапазоны длины, ширины, высоты и другие свойства. Поэтому человек и не путает слова-омонимы. Именно они и разбивают в хлам стратегию нейронных сетей. Пример, который я нашел в другой статье, «он видел их семью своими глазами». Слово «семью» можно воспринять как число или как слово семья. И, чтобы разобрать эту фразу через нейронные сети, требуются огромнейшие вычислительные мощности, анализ кучи зависимостей, статистики и прочего. Всё это крайне неэффективно и, с некоторой точки зрения, даже глупо и вредно. Так что же делать? Необходимо машине понимать смысл слов. Из вышесказанного должно быть понятно, что для этого нельзя использовать естественный язык. А значит, требуется записать смысл каждого слова на другом языке, понятном компьютеру. Как вариант, за основу можно взять объектно-ориентированное программирование. Приведу определение из справочника c# Герберт Шилдт: «Класс представляет собой шаблон, по которому определяется форма объекта. В нем указываются данные. По существу, класс представляет собой шаблон, по которому определяется форма объекта». Добавим сюда наследование — «создание иерархических классификаций». По сути, можно таким образом описать весь наш физический мир и получится математическая модель мира. Для простого общения достаточно такого уровня, где лишь общие характеристики. То есть достаточно описать фиалку в ообщем и не описывать все их 157 видов с размерами и цветами лепестков у каждого вида. Можно даже добавить некоторое схематичное обозначение каждого объекта. Детализация будет влиять на потребляемые ресурсы. При наличии такого смоделированного мира и привязки слов на естественном языке к объектам классов, слова-омонимы больше не будут тревожить. Каждая фраза сможет быть смоделирована (даже отрисована в виде мультфильма, прям как в нашей голове). Вернемся к предложению «он видел их семью своими глазами». Вместо синонимов подставляются объекты, берем за основу человека. У него есть в свойствах количество глаз. И так как их не семь, то этот вариант отпадает. Так же в модель нашего мира нужно заложить физику. Только тогда будет некое мышление у машины, она сможет моделировать ситуации в своём виртуальном мире, но так как слова на естественном языке привязаны к объектам виртуального мира, то и общение будет возможно на естественном языке. Если будут ошибки в общении, то сразу ясно, что они идут из-за неполноты виртуального мира и правятся только необходимые куски, без исправления всей системы. Соответственно, в эту модель будет легко включить наше «долгосрочное планирование», что отличает людей от машин.
Пока это не выполнено, можно даже не переходить к моделированию личности, толку не будет.
Резюмируя:
Пункт 1. Создать модель реального мира в компьютере. Процесс похож на создание игровых движков. Задача объемная и сложная, одному человеку неподъемная, хотя кто знает ) Для работы с ней достаточно мощности обычного игрового компьютера. (на самом деле, в игровых движках очень много ресурсов отъедается на визуализацию, а ей пока можно пренебречь, то есть компьютера хватит не очень мощного), это к вашему первому затыку. Моллекулярная биология и устройство клетки, на данном этапе уж точно не нужно. Это ко второму затыку.
Пункт 2. Только после реализации первого пункта и возможности примитивного предметного общения — моделирование личности. Это тоже большая и сложная задача. Сюда нужно впихнуть всю психологию. То есть из тонны мусора, противоречий и, что вы там говорите, на текущий момент есть в психологии необходимо построить четкую и ясную систему. Так как мы взяли за основу ООП, то, значит, нужно описать в терминах ООП, а именно, определить базовый класс и наследовать от него. К примеру, взять за основу боль и через неё описать чувства — страх, любовь, инстинкты. Я не говорю, что это именно так, но для моделирования этого будет достаточно. Построили модель, проверили, если немного не укладывается, то подправить, если совсем беда — то искать другую модель. Все цели человека нужно описать через какую-то базовую величину, можно взять эндорфин. Я не буду спорить, он ли первичен, или из-за него получается радость, меня это не интересует. Мы лишь моделируем, и я могу в своей модели сказать, что для человека всё идёт от уровня эндорфина в крови. К примеру, катанию на велосипеде соответствует 3 еденицы, а занятию сексом — 27 едениц. Цель у искусственной личности будет получение этого эндорфина. Тогда и возможно будет «долгосрочное планирование», ведь можно три дня кататься на велосипеде, а можно три дня уламывать подружку и получится намного больше этого самого эндорфина. Усложнять систему и проверять свои модели можно лишь при наличии математической модели. Если вы думаете, что со всеми этими психологическими заморочками построить такую систему невозможно, то пообщайтесь с цыганами или гадалками. Они за короткий промежуток времени строят такую систему. Достаточной сложности.
Очень интересная статья. Прям завораживает, действительно раньше функциональное программирование пугало, а после этой статьи почитал про него еще. Сидя в своей уютной visual studio с уютным c#, разумеется, начал копать в сторону языка f#. И вот что я понял, поправьте меня, если ошибаюсь: являясь дотнетовским языком у f# остался лишь «лаконичный синтаксис». То есть, один из озвученных плюсов — что легко распараллеливать код, на самом деле, один и тот же код на разных языках, c# await/async и f#, со своим подходом, компилируется в один и тот же промежуточный IL. То есть какого-то выигрыша производительности нет и разница только в синтаксисе? Другими словами, f# не является чистым функциональным языком, поэтому в нём нет никаких других преимуществ или плюсов?
Очень классная статья. Действительно, сложно найти что-то подобное на просторах интернета. Первое, что мне подумалось, что Шелдон Купер — аутист, и живёт себе неплохо и многие хотят быть на него похожим ) Второе, в контексте развития искусственного интеллекта: на данном этапе можно сделать узконаправленного специалиста (читай, робота-аутиста) способного справляться с какой-то специализированной задачей, к примеру экспертные системы или обработку фотографий. В общем, не в том направлении развивается ИИ, хотя, несомненно, такие специализированные помощники крайне полезны. Точнее, требования разработки строятся для решения узконаправленных задач, что и определяет вектор развития всей отрасли.
Привет, да, именно этой технологии я уделил один абзац. Я увидел её у хостера 1gb.ru, у них не хватает нескольких пунктов, например базы данных, а, самое главное, нет облачной службы. Так же нет и синхронизации со студией. А портал похож на старый
про WCF vs WebAPI perfomance цифр так же очень много. Поверх HTTP webAPI работает быстрее, чем wcf на, примерно, 10%.
Внутри wcf я привел пример теста на разных каналах и цифры показывают, что по tcp работает в два раза быстрее. Не нужен отдельный тест, чтобы понимать, что wcf на tcp работает быстрее, чем webAPI, и даже можно грубо сказать, что быстрее, примерно, на 40%.
Про эффективность я теперь совсем не понимаю, то есть вы просто указываете на недостатки текущей системы. Я предложил варианты решения недостатков. Для постоянных измерений мне нужно вначале сделать несколько реализаций, а я всего лишь спрашиваю, как сделать распределенную систему правильно. Это чётко поставленная цель, она подразумевает максимальную производительность (которая включает в себя скорость передачи данных) и удобство разработки.
Еще вы постоянно начали повторять, что я неправильно понимаю ваши высказывания, давайте разложим по полочкам:
сам WCF (который, в общем-то, весьма тяжелый) дает мне избыточный оверхед.
Все взаимодействие у меня синхронное. Много ресурсов бессмысленно теряется на блокировках.
Кроме WCF есть много других технологий для распределенных систем.
Отклик, из-за использования wcf, уже за границей восприятия и его влияние на отклик на три порядка больше (это в тысячу раз?).
Я правильно понимаю ваши доводы, хотя вы и говорили их в форме вопросов, ничего не перепутал? Из этого я могу сделать вывод о том, что моя реализация неэффективна, что нужно переходить на другие технологии. Каких-либо стандартов реализации распределенного сервера не существует, можно только воспользоваться чьими-то разработками, например thrift, Akka.net и Orleans.
Поправьте, если ошибаюсь.
Моя статья рассказывает как правильно и без лишних телодвижений настроить wcf по tcp в азуровском проекте. Я обязательно дополню её, как только разберусь во всех вопросах. И так как у меня были сложности с поиском информации по этой теме и то, что уже несколько людей добавили эту статью в избранное говорит о том, что её место тут. В любом случае я не знаю как перенести её и не хочу об спорить о местоположении.
Про скорость я вам сказал, тестов много, они гуглятся легко, вот пример wcf-relative-binding-speeds. В два раза быстрее.
Согласен про мои некорректные фразы про wcf, я лишь хотел сказать, что такая реализация делается проще и быстрее (из возможных реализаций именно на wcf), чем то, что гуглится вначале по таким запросам.
Вы говорите, что моё решение неэффективно, потому что транспортные расходы сводят на нет все преимущества распределенной системы. Это и есть именно та мысль, что не нужно использовать такое решение. Что можно с ним сделать?
1. Вернуться на монолитный сервер. Это сразу нет.
2. Доработать, а именно добавить асинхронность на запросы. Либо вовсе уйти от wcf и написать прямые вызовы по сети. Что вы думаете о таком решении?
3. Воспользоваться сторонними библиотеками. Я их посмотрю, но пока во всём разберусь, будет не быстро. Если вы говорите, что это самый правильное решение, я посмотрю гораздо внимательнее и, если всё получится, то остановлюсь на этом решении.
Создать как отдельные проекты в решении. Это я и спрашивал. Так как я много не знаю, то могло оказаться, что есть другой способ, уточнить стоило. С этим ладно.
Про отладку, если это отдельные проекты, то при пошаговой отладке при вызове удаленного метода, курсор не будет проходить в него, а студия будет выдавать информационное сообщение, что вызван удаленный метод и вернулся такой результат. А чтобы попасть внутрь, нужно вручную заходить в этот метод и ставить точку останова. Это неудобно. И про это стоило спросить, быть может как-то можно создать такое решение не отдельными проектами, чтобы таких неудобств не было.
А самое главное, когда я арендую у хостинга два vds, то между ними нет локальной сети. По этому вопросу я вообще ничего не могу сказать, я таким не занимался. Тут хочу услышать, что либо нет возможности настроить локальную сеть, и тогда моё решение вообще нельзя будет перенести на обычные хостинги. Либо можно сделать через поддержку хостинга. Либо можно настроить самому руками и что нужно будет для этого сделать.
Сергей, я не знаю, чем вам так насолил.
Тут я не использую избыточность от wcf, к ней я отношу контракты, автоматически генерируемые файлы и сериализацию/десереализацию в xml и подобные форматы. Быстрее можно сделать, написав взаимодействие серверов напрямую через сетевые сокеты, я не готов сейчас этим заниматься.
Скорость влияет на отклик системы, который важен для пользователя. Всегда важен.
Конкретные измерения http и tcp? При одной и той же реализации wcf можно установить способ передачи данных (NetTCPBinding, HttpBinding). От меня вы чего хотите, чтобы я вам цифры привел? посмотрите сами. Могу другими словами: при net.tcp идёт sender -> net.tcp -> receiver. По HTTP идёт так sender -> http -> tcp -> http -> receiver. Я не буду ставить тесты, моя реализация будет быстрее реализации через WebAPI. Вы чётко говорите не использовать моё (стандартное решение от Microsoft), а взамен предлагаете WebAPI (другое стандартное решение от Microsoft).
С вами обсуждение началось, потому что вы несколько раз сказали «у вас всё неправильно», я услышал предложение использовать три сторонних библиотеки, и обязательно их посмотрю. На это нужно время, а, возможно, будет проще и быстрее сделать взаимодействие серверов через сокеты.
На самом же деле, мой основной вопрос был как правильно создать в студии эту «неправильную» архитектуру" распределенного сервера для обычного хостинга, где есть возможность только арендовать vds, а не для азуры. Отлаживать и публиковать.
Спасибо, посмотрю. На самом деле очень удивлен, что необходимо пользоваться сторонними библиотеками. Когда-то в голове отложилось, что есть монолитное решение и можно сделать распределенное решение, которое обладает рядом преимуществ. Разговоры ведутся давно, надеялся, что есть уже всё готовенькое и стандартное. Вот теперь коснулся этой темы и какой-то ужас.
Уже какая-то конкретика, за это спасибо.
Дальше начала мы с вами и не продвинулись. На ваши «весьма конкретные вопросы» я ответил, но могу еще раз. Скорость — всегда важна. Я не говорил, что мой вариант самый быстрый, наоборот, хочу узнать как делать такие вещи правильно. Синхронные вызовы можно заменить на асинхронные. Тяжелый wcf — что в моих трёх строчках вы увидели тяжелого? Создание каналов через ChannelFactory?
Про передачу данных еще был вопрос, транспортные расходы всегда будут. Я знаю только два канала передачи данных — это http и tcp. Http — медленнее и решения, основанные на этом канале будут медленнее (предложенные WebAPI и ServiceStack).
Вообще, стандартные решения от майкрософт для сервисов — это WebAPI и wcf. С одной стороны вы говорите не использовать стандартные решения, с другой стороны самих их предлагаете, ладно.
Thift, как видно из описания, фреймворк для облегчения взаимодействия между кодом написанным на разных языках. По описанию мне не подходит. Он использует tcp канал, вопрос вам, сильна ли разница этой избыточной библиотеки и стандартного ChannelFactory?
Про Akka.net я почитаю, спасибо.
А еще вы пытаетесь язвить тем, что умнее, хотя я пришел за помощью и сразу сказал, что у меня немного опыта. Не очень приятно слушать вашу желчь.
Это я и пытаюсь выяснить. Я понимаю, что есть другие технологии для распределенных систем, но я о них не знаю.
В третий раз вы мне говорите, что так, как я делаю, делать не надо. Но не говорите как переделать? Я же не требую от вас готового решения для меня, но хоть что-то можете сказать? какой подход использовать? Какую технологию? Чем можно заменить мой подход?
Если вы действительно хотите мне помочь, то критика должна быть конструктивной, а вы просто говорите: «так делать не надо, есть много других технологий». Мне такие фразы никак не помогут и не приблизят ни на шаг к правильному решению.
Ну это само собой. Но этот вариант — самое быстрое, что я могу предложить. Я правда хочу понять и разобраться как сделать правильно. Вы говорите мне: «так делать нельзя». Я не отрицаю, но этого мало. Подскажите, как можно сделать? Естественно, если я делаю распределенные функции у меня появятся задержки на передачу. Но так я разгружаю основной сервер, что при большой нагрузке может дать и отклик быстрее.
Что не так с чатом? Можно и под чат выделить сервер. У меня нет задержки на отклики из-за того, что нет сериализации/десериализации и вызовы происходят по локальной сети, очень быстрому каналу передачи. Это я как пример и возможность: таким способом я выношу затратные функции обсчета поединка в браузерной игре и обсчета подземелий. Но и для чата не вижу проблем и неудобств, поясните? Очень хочу сделать всё красиво и изящно, вынося чат на отдельный сервер я уменьшаю нагрузку с основного, подскажите как это можно сделать более правильно?
Тут, на самом деле идёт торговля, тимлид торгуется за своего подчинённого и должен делать это хорошо, тогда, несомненно, авторитет будет расти. Видно, что у такого тимлида есть команда, за которую он переживает и решает подобного рода вопросы.
Так же, практически в каждой компании есть какие-либо подведения итогов. Пусть даже раз в год перед новым годом. Не надо тратить время на сбор информации, достаточно бегло оглядеть такие записи и можно сказать несколько приятных слов, какие ребята молодцы, выделив наиболее интересные или сложные решения, которые удалось реализовать. Таким образом видно, опять же, что этот менеджер печётся о своих подчинённых, ничего не забывает, то есть они работают не напрасно. Это приятно и это, несомненно, увеличивает авторитет.
Так же и увеличивает авторитет тимлида в глазах руководства, так как может сказать коротко и по делу, с аргументами, чем занимается его команда и почему они молодцы, в сравнении с другим тимлидом, который обычно скажет что-то вроде «год был тяжёлый, кто дожил до конца, тот молодец».
Эти довольно простые советы всего лишь вести своевременные заметки очень полезны в первую очередь тимлидам, которые вышли из технических специалистов и даже не задумываются, что теперь всё то, что я написал выше, лежит на их хрупких плечах, так как в явном виде они никогда и нигде не прописаны, но через какое-то время всегда всплывают. И если новоиспечённый руководитель будет к ним готов, это показатель, что он справляется со своей работой на отлично, что так же повышает авторитет )
И с зарплатой подчинённого, с такими заметками сразу есть аргументы для вышестоящего руководства, какие важные/полезные штуки реализовал этот самый подчинённый и почему ему необходимо повысить зарплату. Вместо мычания «ну он там работал что-то норм, делает свои задачи», 10 минут беглого осмотра и есть ясные факты, которые с последнего грейда за всех ребят запомнить невозможно
В общем, советы в статье даны дельные, вести заметки по таким вещам заблаговременно не составит труда, но даст много реальной пользы и поднимет профессионализм тимлида в глазах вышестоящего руководства.
Невозможно описать язык, используя слова из этого языка. К примеру, возьмем толковый словарь — мы не можем прогнать его через нейронные сети и надеяться, что сеть сама выделит смысл слов, этого не будет никогда, получится лишь имитация. Может получиться хорошая, но это не то, что нужно.
Первое, что нужно сделать, это научить машину выделять смысл слов. Можно это представить, когда мы (русскоговорящие и мыслящие на русском) начинаем изучать другой язык, к примеру, английский. Нам говорят, что стол — table. После этого факта, когда в тексте встречается слово table, я вспоминаю, что эти буковки значат на моём родном языке, представляю себе мысленно этот стол, и вместе с этим вытаскивается вся физическая информация об этом физическом объекте — диапазоны длины, ширины, высоты и другие свойства. Поэтому человек и не путает слова-омонимы. Именно они и разбивают в хлам стратегию нейронных сетей. Пример, который я нашел в другой статье, «он видел их семью своими глазами». Слово «семью» можно воспринять как число или как слово семья. И, чтобы разобрать эту фразу через нейронные сети, требуются огромнейшие вычислительные мощности, анализ кучи зависимостей, статистики и прочего. Всё это крайне неэффективно и, с некоторой точки зрения, даже глупо и вредно. Так что же делать? Необходимо машине понимать смысл слов. Из вышесказанного должно быть понятно, что для этого нельзя использовать естественный язык. А значит, требуется записать смысл каждого слова на другом языке, понятном компьютеру. Как вариант, за основу можно взять объектно-ориентированное программирование. Приведу определение из справочника c# Герберт Шилдт: «Класс представляет собой шаблон, по которому определяется форма объекта. В нем указываются данные. По существу, класс представляет собой шаблон, по которому определяется форма объекта». Добавим сюда наследование — «создание иерархических классификаций». По сути, можно таким образом описать весь наш физический мир и получится математическая модель мира. Для простого общения достаточно такого уровня, где лишь общие характеристики. То есть достаточно описать фиалку в ообщем и не описывать все их 157 видов с размерами и цветами лепестков у каждого вида. Можно даже добавить некоторое схематичное обозначение каждого объекта. Детализация будет влиять на потребляемые ресурсы. При наличии такого смоделированного мира и привязки слов на естественном языке к объектам классов, слова-омонимы больше не будут тревожить. Каждая фраза сможет быть смоделирована (даже отрисована в виде мультфильма, прям как в нашей голове). Вернемся к предложению «он видел их семью своими глазами». Вместо синонимов подставляются объекты, берем за основу человека. У него есть в свойствах количество глаз. И так как их не семь, то этот вариант отпадает. Так же в модель нашего мира нужно заложить физику. Только тогда будет некое мышление у машины, она сможет моделировать ситуации в своём виртуальном мире, но так как слова на естественном языке привязаны к объектам виртуального мира, то и общение будет возможно на естественном языке. Если будут ошибки в общении, то сразу ясно, что они идут из-за неполноты виртуального мира и правятся только необходимые куски, без исправления всей системы. Соответственно, в эту модель будет легко включить наше «долгосрочное планирование», что отличает людей от машин.
Пока это не выполнено, можно даже не переходить к моделированию личности, толку не будет.
Резюмируя:
Пункт 1. Создать модель реального мира в компьютере. Процесс похож на создание игровых движков. Задача объемная и сложная, одному человеку неподъемная, хотя кто знает ) Для работы с ней достаточно мощности обычного игрового компьютера. (на самом деле, в игровых движках очень много ресурсов отъедается на визуализацию, а ей пока можно пренебречь, то есть компьютера хватит не очень мощного), это к вашему первому затыку. Моллекулярная биология и устройство клетки, на данном этапе уж точно не нужно. Это ко второму затыку.
Пункт 2. Только после реализации первого пункта и возможности примитивного предметного общения — моделирование личности. Это тоже большая и сложная задача. Сюда нужно впихнуть всю психологию. То есть из тонны мусора, противоречий и, что вы там говорите, на текущий момент есть в психологии необходимо построить четкую и ясную систему. Так как мы взяли за основу ООП, то, значит, нужно описать в терминах ООП, а именно, определить базовый класс и наследовать от него. К примеру, взять за основу боль и через неё описать чувства — страх, любовь, инстинкты. Я не говорю, что это именно так, но для моделирования этого будет достаточно. Построили модель, проверили, если немного не укладывается, то подправить, если совсем беда — то искать другую модель. Все цели человека нужно описать через какую-то базовую величину, можно взять эндорфин. Я не буду спорить, он ли первичен, или из-за него получается радость, меня это не интересует. Мы лишь моделируем, и я могу в своей модели сказать, что для человека всё идёт от уровня эндорфина в крови. К примеру, катанию на велосипеде соответствует 3 еденицы, а занятию сексом — 27 едениц. Цель у искусственной личности будет получение этого эндорфина. Тогда и возможно будет «долгосрочное планирование», ведь можно три дня кататься на велосипеде, а можно три дня уламывать подружку и получится намного больше этого самого эндорфина. Усложнять систему и проверять свои модели можно лишь при наличии математической модели. Если вы думаете, что со всеми этими психологическими заморочками построить такую систему невозможно, то пообщайтесь с цыганами или гадалками. Они за короткий промежуток времени строят такую систему. Достаточной сложности.
Всё в ваших руках — дерзайте )
Внутри wcf я привел пример теста на разных каналах и цифры показывают, что по tcp работает в два раза быстрее. Не нужен отдельный тест, чтобы понимать, что wcf на tcp работает быстрее, чем webAPI, и даже можно грубо сказать, что быстрее, примерно, на 40%.
Про эффективность я теперь совсем не понимаю, то есть вы просто указываете на недостатки текущей системы. Я предложил варианты решения недостатков. Для постоянных измерений мне нужно вначале сделать несколько реализаций, а я всего лишь спрашиваю, как сделать распределенную систему правильно. Это чётко поставленная цель, она подразумевает максимальную производительность (которая включает в себя скорость передачи данных) и удобство разработки.
Еще вы постоянно начали повторять, что я неправильно понимаю ваши высказывания, давайте разложим по полочкам:
сам WCF (который, в общем-то, весьма тяжелый) дает мне избыточный оверхед.
Все взаимодействие у меня синхронное. Много ресурсов бессмысленно теряется на блокировках.
Кроме WCF есть много других технологий для распределенных систем.
Отклик, из-за использования wcf, уже за границей восприятия и его влияние на отклик на три порядка больше (это в тысячу раз?).
Я правильно понимаю ваши доводы, хотя вы и говорили их в форме вопросов, ничего не перепутал? Из этого я могу сделать вывод о том, что моя реализация неэффективна, что нужно переходить на другие технологии. Каких-либо стандартов реализации распределенного сервера не существует, можно только воспользоваться чьими-то разработками, например thrift, Akka.net и Orleans.
Поправьте, если ошибаюсь.
Про скорость я вам сказал, тестов много, они гуглятся легко, вот пример wcf-relative-binding-speeds. В два раза быстрее.
Согласен про мои некорректные фразы про wcf, я лишь хотел сказать, что такая реализация делается проще и быстрее (из возможных реализаций именно на wcf), чем то, что гуглится вначале по таким запросам.
Вы говорите, что моё решение неэффективно, потому что транспортные расходы сводят на нет все преимущества распределенной системы. Это и есть именно та мысль, что не нужно использовать такое решение. Что можно с ним сделать?
1. Вернуться на монолитный сервер. Это сразу нет.
2. Доработать, а именно добавить асинхронность на запросы. Либо вовсе уйти от wcf и написать прямые вызовы по сети. Что вы думаете о таком решении?
3. Воспользоваться сторонними библиотеками. Я их посмотрю, но пока во всём разберусь, будет не быстро. Если вы говорите, что это самый правильное решение, я посмотрю гораздо внимательнее и, если всё получится, то остановлюсь на этом решении.
Создать как отдельные проекты в решении. Это я и спрашивал. Так как я много не знаю, то могло оказаться, что есть другой способ, уточнить стоило. С этим ладно.
Про отладку, если это отдельные проекты, то при пошаговой отладке при вызове удаленного метода, курсор не будет проходить в него, а студия будет выдавать информационное сообщение, что вызван удаленный метод и вернулся такой результат. А чтобы попасть внутрь, нужно вручную заходить в этот метод и ставить точку останова. Это неудобно. И про это стоило спросить, быть может как-то можно создать такое решение не отдельными проектами, чтобы таких неудобств не было.
А самое главное, когда я арендую у хостинга два vds, то между ними нет локальной сети. По этому вопросу я вообще ничего не могу сказать, я таким не занимался. Тут хочу услышать, что либо нет возможности настроить локальную сеть, и тогда моё решение вообще нельзя будет перенести на обычные хостинги. Либо можно сделать через поддержку хостинга. Либо можно настроить самому руками и что нужно будет для этого сделать.
Тут я не использую избыточность от wcf, к ней я отношу контракты, автоматически генерируемые файлы и сериализацию/десереализацию в xml и подобные форматы. Быстрее можно сделать, написав взаимодействие серверов напрямую через сетевые сокеты, я не готов сейчас этим заниматься.
Скорость влияет на отклик системы, который важен для пользователя. Всегда важен.
Конкретные измерения http и tcp? При одной и той же реализации wcf можно установить способ передачи данных (NetTCPBinding, HttpBinding). От меня вы чего хотите, чтобы я вам цифры привел? посмотрите сами. Могу другими словами: при net.tcp идёт sender -> net.tcp -> receiver. По HTTP идёт так sender -> http -> tcp -> http -> receiver. Я не буду ставить тесты, моя реализация будет быстрее реализации через WebAPI. Вы чётко говорите не использовать моё (стандартное решение от Microsoft), а взамен предлагаете WebAPI (другое стандартное решение от Microsoft).
С вами обсуждение началось, потому что вы несколько раз сказали «у вас всё неправильно», я услышал предложение использовать три сторонних библиотеки, и обязательно их посмотрю. На это нужно время, а, возможно, будет проще и быстрее сделать взаимодействие серверов через сокеты.
На самом же деле, мой основной вопрос был как правильно создать в студии эту «неправильную» архитектуру" распределенного сервера для обычного хостинга, где есть возможность только арендовать vds, а не для азуры. Отлаживать и публиковать.
Дальше начала мы с вами и не продвинулись. На ваши «весьма конкретные вопросы» я ответил, но могу еще раз. Скорость — всегда важна. Я не говорил, что мой вариант самый быстрый, наоборот, хочу узнать как делать такие вещи правильно. Синхронные вызовы можно заменить на асинхронные. Тяжелый wcf — что в моих трёх строчках вы увидели тяжелого? Создание каналов через ChannelFactory?
Про передачу данных еще был вопрос, транспортные расходы всегда будут. Я знаю только два канала передачи данных — это http и tcp. Http — медленнее и решения, основанные на этом канале будут медленнее (предложенные WebAPI и ServiceStack).
Вообще, стандартные решения от майкрософт для сервисов — это WebAPI и wcf. С одной стороны вы говорите не использовать стандартные решения, с другой стороны самих их предлагаете, ладно.
Thift, как видно из описания, фреймворк для облегчения взаимодействия между кодом написанным на разных языках. По описанию мне не подходит. Он использует tcp канал, вопрос вам, сильна ли разница этой избыточной библиотеки и стандартного ChannelFactory?
Про Akka.net я почитаю, спасибо.
А еще вы пытаетесь язвить тем, что умнее, хотя я пришел за помощью и сразу сказал, что у меня немного опыта. Не очень приятно слушать вашу желчь.
В третий раз вы мне говорите, что так, как я делаю, делать не надо. Но не говорите как переделать? Я же не требую от вас готового решения для меня, но хоть что-то можете сказать? какой подход использовать? Какую технологию? Чем можно заменить мой подход?
Если вы действительно хотите мне помочь, то критика должна быть конструктивной, а вы просто говорите: «так делать не надо, есть много других технологий». Мне такие фразы никак не помогут и не приблизят ни на шаг к правильному решению.