Pull to refresh
50
0
Alex Djachenko @alexdjachenko

Пользователь

Send message

При устройстве на работу вы приносите справку НДФЛ с предыдущего места работы и выписку из трудовой на госуслугах. Там перечислены места работы, должность и зарплата.

"Потерять" электронную трудовую не получится, а без справки НДФЛ вы будете получать оплату больничных по минималке, поэтому убедительно соврать, почему вы этого хотите будет непросто.

TensorFlow и PyTorch - это фреймворки для машинного обучения, а не для чат-ботов. Сделать на них чат-бот, как паравоз до танка напильноком довести.
Dialogflow, Microsoft Bot Framework, Chatfuel, Wit.ai - либо я плохо смотрел, либо все это никакой не Open Source, а закрытые облачные платформы у которых открыты только фреймворки.
BotPress - тоже закрылся и превратился в облачную платформу. Еще продолжает существовать так называемая v12, которую можно поставить себе, но развитие ее прекращено (специально уточнял у разработчиков), бОльшая часть документации с битыми ссылками и вообще сплошная печаль. То есть Open Source, код v12 открыть, можно форкнуть, но на текущий момент живого Open Source проекта нет, а просто разработчики коммерческой версии по инерции добавляют багфиксы.
Rasa - тут да, честный Open Source, хотя и они графический интерфейс разработчика, отладчик и часть функций забрали в закрытую часть, которая "очень платная". С community там все тоже весьма грустно, на форуме 4 вопроса из 5 висят без единго ответа. Да и сам движок своеобразный. Он крут в части адаптации к живому диалогу, но зато такие вещи как "модальный запрос" (когда система в цикле запрашивает, скажем, авторизацию и не дает перейти к другим темам до ее ввода) там невозможно. Да и следование диалогу там всегда происходит на основе предсказаний нейросети, что "из пушки по воробьям" для простых ботов (или части диалогов в простых ботах) и несет некоторую долю непредсказуемости.
Botkit - проект есть на GitHub и, по крайней мере, там есть инструкция по установке на свой сервер. Но по результатам беглого ознакомления, это довольно низкоуровневый фреймворк, упрощающий написание кода чат-бота на Node.JS, но не более того. По впечатлению, в таких нет недостатка для любых платформ.

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

Расскажите, пожалуйста, об этом подробнее

На чем строился отдельный кластер с СУБД? В частности, какую ФС вы использовали (ведь они либо быстрые, либо поддерживают больше одного монтирования не чтение/запись)? Или держали данные в памяти, как это делает MySQL в режиме кластера?

Про сеть, получается, вы не использовали встроенную функцию Swarm для автоматического создания внутренней сети между нодами одного стека? Это строилось на своей инфраструктуре или на арендованных виртуалках в публичной сети?


> ну база находится в отдельном кластере и ноды туда по сети ходят

Даже если БД на отдельном кластере, где статьи про то, как построить кластер для СУБД на Swarm или заметка, что он для этого совершенно непригоден?

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

ну вообще архитектор системы должен знать как строятся такие системы

Зачем тогда вообще статьи писать? Все это есть в официальном руководстве к докеру. Интересна практика, кто как у себя сделал.

вообще масштабирование и параллелизм в СУБД это тема отдельного разговора и docker — это не инструмент для решения этих вопросов

Тогда к чему имеет отношение Docker Swarm кроме поднятия пустых контейнеров без состояния и данных?

У Вас, к примеру, есть полезные кейсы на Docker Swarm, которыми Вы могли бы поделиться? Как у Вас это организовано?

Например, если у вас база на отдельном кластере, на чем он? Как вы обеспечиваете связь контейнеров Swarm с этой базой? Внутренняя сеть Swarm автоматически связывает только контейнеры, получается, вы подключали базу снаружи к каждой ноде?

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

Что касается СУБД: в Docker базу предполагается запускать в том же стеке, в отдельном контейнере. Если запускать ее снаружи, от кластера нет никакого толка, так как надо будет решать вручную и проблему связи по сети, и совместного запуска/остановки, и передачу паролей и вообще все. Единственный выход, который вижу я, это в условиях деплоя жёстко прописывать один хост для базы, жёстко прописывать один хост для nfs-сервера, а "плавающими" оставлять только веб-сервер. При этом запеч прямо в образ монтирование nfs. Но ни в одной инструкции, ни в одном видеоролике об этом не говорят. Это и есть лучшая/единственная практика или есть способы лучше?

Такое ощущение, что по всех статьях даётся вольный пересказ примера из официального руководства и никто не описывает свой реальный опыт практического применения.

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

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

Как писали выше, htdocs можно положить на NFS, а что делать с файлами СУБД?

И где брать сам NFS? Как безопасно подключать его к виртуалкам, учитывая, что он не поддерживает авторзацию? Пока, единственная идея, которая пришла в голову - это объявить ноду для хранилища специальным тегом и в каждом стеке объявлять контейнер с nfs-сервером на этой ноде, а в контейнер веб-приложении при сборке сразу прописать монтирование этой NFS (монтировать из драйвера волайма не получится, т.к. внутренняя сеть кластера доступна только контейнерам, и даже если ее вытащить на ноду, это и безопасность ухудшит и проблемы с порядком старта сети и контейнеров возникнут). Внешнее хранилище NFS не поднять без провайдера, или же надо будет решать, как соединить виртулки нод второй сетью)

Очень бы хотелось обо всем этом почитать. Какие есть хорошие практики отработанные. Но пока не нашел ни одного текста, где это бы подробно разбиралась :(

Про определение филисофии - вопрос действительно дискуссионный.

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

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


Про злонамеренность или случайность: я бы как раз не стал недооценивать прозорливость советстких идеологов. Чтобы догадаться, какие науки несут угрозу идеологии, пропаганде и управляемости общества, не обязательно быть гением. Если уж фильмы цензурировали, то здесь все совсем очевидно. Даже в Википедии об этом статья есть: https://ru.wikipedia.org/wiki/Идеологический_контроль_в_советской_науке#Социология

После окончания советсткого периода социальные и гуманитарные науки начали развиваться, но сказывалось отсутствие своей школы, специалистов, а главное, сформированный в советсткий период образ гуманитария, как бесполезного и не очень умного балабола, который оказался неспособен выучить таблицу умножения. К сожалению, это прослеживается даже в комментариях к этому посту. Я и сам так считал, в конце концов, я тоже IT-шник и первое образование у меня инженерное.
Сейчас социальные науки снова оказались в опале - было дело против Еврапейского Университета, из ВШЭ много кого поувольняли, сейчас против ректора Шанинки уголовное дело. Как в известном анекдоте: "Один олень - случайность, три оленя - ненденция" :)

А в тексте нигде нет словосочетания "гуманитарные науки". Есть "гуманитарные дисциплины".

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

То есть, Вы считаете, что сначала случаются изменения в обществе, а потом уже под них подбирают термин и пишется соответствующий труд?

Но разве не противоречит этому то, что сперва был написан "Капитал", а только потом произошла октябрьская революция?
Сперва Джон Милль написал свои "Рассуждения о представительном правлении" и только много позже мы пришли к всеобщему избирательному праву, о чем раньше никто и не помышлял и даже в страшных снах не видел.
Сперва издали "Муму" Тургенева, а потом произошла отмена крепостного права в России... ок, причинность последнего спорна.

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

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

Ну так и в программировании есть Страуструп, а есть никому не известный разработчик вирусов. Есть выдающиеся программисты, а есть посредственные. Все как везде.

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

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

В романе Нила Стивенсона "Лавина" примерно так и есть. В жизни, конечно, всё не так радикально.

Делают, потому же, почему физики изучают атом, а программисты пишут код: работа и самовыражение.

Но влияние их на общество сложно переоценить. Многие вещи, которые нам кажутся совершенно естественными, появились не так давно, как раз под влиянием гуманитарных мыслителей. Например "детство", как самоценный период жизни человека, когда он нуждается в защите от пагубного влияния взрослого общества, некоторой информации, привычек, попыток эксплуатации и т.п. А так же то, что государство должно принимать в этом участие появилось совсем недавно, под влиянием Жан-Жака Руссо. Появилась новая идея, новое понятие, новые семантические связи, которые создали то отношение к детям, которое мы теперь считаем привычным.

Вы не согласны с самой идеей, что гумманитарии, по сути, являются программистами нашего мышления или Вам не нравится форма статьи?

Пишут статьи, которые никто не читает :)))

Вы цитируете введение. Ниже в описаниях виджетов написано подробнее, что именно мне неудобно при работе со стандартными инструментами.
Возможно, предложенные виджеты и не решают проблему. Это только концепция. UI/UX исследований я не проводил.

Я тоже ими активно пользуюсь, но это не делает их удобнее :)
Ого! Как же я так обсчитался-то на 10 лет? Видимо не могу поверить, что уже такой старый :)
Спасибо!
Добавьте это в требования к вакансии и интервьюируйте по ним работодателей: собеседование при трудоустройстве — это же двусторонний процесс :-)
Про Adjourning никто не хочет вспоминать :-)
Про модель командной динамики Брюса Тукманна и так довольно много публикаций.

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

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

Задача лидера здесь — помогать группе, оберегать её от найма «токсичных» участников, следить за сохранением комфортных условий труда, справедливой и своевременной оплатой. Снабдить группу лучшими практиками: стандартом оформления кода, рекомендациями по кодированию и архитектуре, методологией разработки, методикой и процедурами управления кодом, ошибками, требованиями, документацией и т.д., но вводить их не силой и все сразу, а убеждением и когда все почувствуют их необходимость.

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

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

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

Information

Rating
Does not participate
Location
Россия
Registered
Activity