Спасибо за ссылку, хотя 50 неоднородных компонент на странице — это редкий случай.
Пример: есть панель со списком вложений. Рядом с именем файла крестик (удалить). Передать компонентам нужно свойство readOnly, контейнерную функцию (clickOnKrestik) и что-то статичное. Зачем здесь redux?
Я не против сторе, я против того, чтобы делать ВСЕ на редюсерах.
Задача: нужно сделать 6 панелей с однотипными компонентами и наваять из них около 20 форм для работы с БД. Связь родитель/ребенок, все просто и понятно, никаких mapDispatchToProps и mapStateToProps.
SPA вовсе не означает, что все должно быть на одной странице в одном контейнере.
При вашем подходе проектом легче управлять, есть ТЗ на модуль, есть ответственный.
Что внутри не так и важно, лишь бы работал.
Мне лично более симпатичен подход, когда в команде есть несколько спецов, которые пишут инструмент, а остальные его применяют. Но здесь требуется более тесное взаимодействие.
Это не критика, наверняка у вас все продумано. Так, рассуждения.
Есть вопрос по поводу redux: какой смысл использовать mapStateToProps? Умный контейнер прекрасно передает глупым компонентам свое состояние и каллбэки, setState вызывает цепочку рендеров. Реализация через редюсеры — это еще один уровень сложности. Зачем?
Я понимаю, когда нужно отправить команду на самый верх, чтобы она сверху вниз взбодрила кого надо, но в отношении родитель/дети redux лишний (имхо). Простое лучше сложного.
Спасибо.
Я не случайно написал «наберется опыта и поймет...».
Я сам по юности лет, получив в Питере хорошее образование и поработав пару лет программистом, был послан в Уфу в качестве гуру поучать местных спецов (интернет только зарождался). Через пару часов общения я понял, что мои башкирские ровесники разбираются в проблеме и в программировании лучше меня :)
Пришлось самооценку скорректировать.
Не согласен с Вами. Некомпетентность не вызывает завышенную самооценку. На мой взгляд завышенная самооценка формируется при работе в слабом коллективе. Короля создает свита.
Согласен с Вами, но не судите автора строго: он наберется опыта и поймет, что главный дракон любого программиста (любого человека) — это некомпетентность, и ее не вылечишь советами типа «нельзя создавать путаницы».
За совет спасибо, статью почитаю.
Проясните до выхода статьи пару вопросов: у меня задача сделать видео чат на сайте для зарегистрированных пользователей. Я беру библиотеку SipJS, в которой реализован WebRTC на основе SIP (...full SIP signaling stack to their WebRTC applications).
Мой сайт передает браузеру страницу с сип-логинами тех, кто в онлайне.
Я с любым могу войти в видео чат. Все просто и понятно (точнее, до конца непонятно, потому что все внутри библиотеки, но работает).
А каков алгоритм без СИП? Что мне должен прислать сайт, чтобы браузер снюхался с нужным абонентом через STUN?
Какие библиотеки Вы используете?
Какие STUN?
В практической области это означает, что наиболее опытным программистам следует поручать разработку инструментальной части, т.е. создание проблемно-ориентированного фреймворка
Я думаю, дело не в моде.
Толстые клиенты умирают, а толстые программисты нет. Не найдя на веб горизонте привычных классов, делают свой инструментарий. Добавьте хорошую документацию и вот вам фреймворк.
Можно на CSS сделать так, чтобы секунды на экране не пересчелкивались, а плавно прокручивались?
Что-то типа барабана с цифрами.
В JS я могу один раз вызвать прокрутку (задать атрибут, для которого в CSS прописаны padding-top и transition).
Вопрос, как ее взбодрить потом?
3 протокола. 1 наш и 2 для смежных систем. Синхронизации данных нет (не считая обновление системы и справочников по тому же протоколу). Есть отправка задания и получение ответа.
Вопрос терминологии. Я это называю распределенной системой.
Взаимодействие с внешними системами: 2http, smtp, imap4, smpp(не используется).
Зачем для EAV 2 таблицы? У нас 1.
Монго, основные понятия:
база: список документов с уникальными id
коллекция: список документов внутри БД (список id)
документ: словарь (объект) «ключ-значение»
связанность/подчиненность документов: поля со списком id
На мой скромный взгляд EAV и никакой магии
По поводу распределенности:
есть несколько автономных систем, которые обмениваются информацией. Каждая система обрабатывает свою информацию и информацию от других систем. И возвращает результаты. Это можно назвать распределенной системой?
Мы положили в основу EAV, отсюда упор на ДОБД. Json-поля для этого хорошо подходят. В ссылке, которую вы мне дали, автор пишет о них, как об альтернативе mongoDB (про недостатки я тоже прочитал). Все зависит от задачи. Почему использовать в качестве хранилища mongDB — это хорошо, а postgres — это плохо?
Ваше незнание ДОБД принимает агрессивный характер. Lotus Notes и mongoDB имеют собственное хранилище, мы используем SQL-сервер. Мы не врем, чесслово. То, что вы не знали, что на SQL-сервере можно хранить любые данные и даже реализовать ДОБД, — не страшно, не надо из-за этого нервничать. Может вас успокоит, что это не мы придумали (json-поля в Postgres и пр).
Вам девочка не дает покоя, потому что для разворачивания системы ваши глубокие знания ОС бесполезны? А вас не напрягает то, что на телефонах девочки сами устанавливают приложения? Я светлое будущее вижу так: отметил галочками перед установкой ОС нужное, нажал кнопку и ОС готова. И никаких сисадминов. Простое лучше сложного.
Забавно обсуждать ДОБД с человеком, который в этом ничего не понимает. «Не используете функционал» говорит о том, что вы функционала ДО сервера не знаете. Почитайте mongoDB-API, — там весь функционал описан (кстати, основы позаимствованы у Lotus Notes, который вы тоже не знаете). Мы написали аналогичный API, получили ДО-сервер с тем же функционалом. Что не понятно?
Про наши серверы повторюсь: система распределенная. В каких-то подразделениях работают десятки человек — там сервер под Linux или WinServer. Где-то 1 чел. Там мини-сервер с SQLite. Исходники одни и те же. Клиентское ПО: MFF/GH. Если мини-сервер включен, коллеги имеют доступ к системе по чтению. Красивое решение с минимальным привлечением технарей. Или вам за технарей обидно: то, что должен делать админ, знающий 100 команд, у нас делает девочка, умеющая лайкать няшки?
Причем тут Сова? У вас в голове все смешалось. Сова — это примитивная локальная CRM, написана давно для конкретного человека и выложена в сеть бесплатно.
Не надо приписывать мне то, чего я не говорил и оправдываться. И не придирайтесь к опечаткам — это мелочно.
Почему бы вам не переключиться с критики нашей системы на критику MongoDB и ДОБД вообще. Мы всего лишь по требованию заказчика повторили монгоДБ с хранением данных в РБД. Поиск у нас работает быстрее, чем в монго, запись медленнее. Аналитические отчеты в любой ДОБД будут тормозить. Монго компактней, но это не принципиально. Вложения занимают террабайты, а на размер базы никто не смотрит.
Да, изобрели велосипед. Но:
1. нам за это заплатили
2. велосипед получился удобным: не нужен север mongoDB. Мини-сервер стартует как служба виндовс и может хранить данные в SQLite. Рразвернуть такой сервер может девочка, которая (ужас) даже не знает, какая у нее ОС.
Система не идеальна, список TODO не мал, но вы же ее не видели. Почему ДОБД в РБД это цирк, а ДОБД в mongDB это не цирк?
Насчет откатов вы больший специалист, чем я.
Я больше 10 лет работаю с госструктурами и не разу с ними не сталкивался. За последние 2 года больше 30 договоров и все через эл. торги. С реальными конкурсами (бывало и с демпингом, бывало и проигрывали). Кому и за что откатывать? Я не ангел, но участвовать в мутных схемах — себе дороже.
IBM интегрировало Lotus Notes и DB2 в 2008.
В Postgres поддержка Json (т.е. возможность реализовать ДОБД в РБД) появилась в версии 9.2. (кажется 2014).
Что касается уровня ваших знаний, то я про них говорить не хочу.
Странный комментарий. Как это реализовано вы не знаете, о задаче не знаете, но при этом намекаете на плохое качество и откаты. Клиенты как страшный сон вспоминают старую систему на РБД и по функционалу и по интерфейсу и по быстродействию. Когда наш программист конвертировал их базу, он конечно ворчал, но в целом нормальная нормализованная БД вполне сносно спроектированная.
Когда мы применили документориентированный принцип хранения стало лучше: быстрее и гибче.
Кстати ДОБД в РБД не мы придумали. IBM в свое время интегрировало Lotus Notes и DB2. Записи из документориентированной системы (Lotus Notes) хранились в РБД. Почитайте статьи на эту тему, а то у вас взгляд однобокий.
Пример: есть панель со списком вложений. Рядом с именем файла крестик (удалить). Передать компонентам нужно свойство readOnly, контейнерную функцию (clickOnKrestik) и что-то статичное. Зачем здесь redux?
Я не против сторе, я против того, чтобы делать ВСЕ на редюсерах.
Задача: нужно сделать 6 панелей с однотипными компонентами и наваять из них около 20 форм для работы с БД. Связь родитель/ребенок, все просто и понятно, никаких mapDispatchToProps и mapStateToProps.
SPA вовсе не означает, что все должно быть на одной странице в одном контейнере.
Что внутри не так и важно, лишь бы работал.
Мне лично более симпатичен подход, когда в команде есть несколько спецов, которые пишут инструмент, а остальные его применяют. Но здесь требуется более тесное взаимодействие.
Это не критика, наверняка у вас все продумано. Так, рассуждения.
Есть вопрос по поводу redux: какой смысл использовать mapStateToProps? Умный контейнер прекрасно передает глупым компонентам свое состояние и каллбэки, setState вызывает цепочку рендеров. Реализация через редюсеры — это еще один уровень сложности. Зачем?
Я понимаю, когда нужно отправить команду на самый верх, чтобы она сверху вниз взбодрила кого надо, но в отношении родитель/дети redux лишний (имхо). Простое лучше сложного.
Спасибо.
Я сам по юности лет, получив в Питере хорошее образование и поработав пару лет программистом, был послан в Уфу в качестве гуру поучать местных спецов (интернет только зарождался). Через пару часов общения я понял, что мои башкирские ровесники разбираются в проблеме и в программировании лучше меня :)
Пришлось самооценку скорректировать.
А зачем столько STUN серверов?
Вы используете MDN. На G.Chrome Ваш софт работает?
Проясните до выхода статьи пару вопросов: у меня задача сделать видео чат на сайте для зарегистрированных пользователей. Я беру библиотеку SipJS, в которой реализован WebRTC на основе SIP (...full SIP signaling stack to their WebRTC applications).
Мой сайт передает браузеру страницу с сип-логинами тех, кто в онлайне.
Я с любым могу войти в видео чат. Все просто и понятно (точнее, до конца непонятно, потому что все внутри библиотеки, но работает).
А каков алгоритм без СИП? Что мне должен прислать сайт, чтобы браузер снюхался с нужным абонентом через STUN?
Какие библиотеки Вы используете?
Какие STUN?
Толстые клиенты умирают, а толстые программисты нет. Не найдя на веб горизонте привычных классов, делают свой инструментарий. Добавьте хорошую документацию и вот вам фреймворк.
Что-то типа барабана с цифрами.
В JS я могу один раз вызвать прокрутку (задать атрибут, для которого в CSS прописаны padding-top и transition).
Вопрос, как ее взбодрить потом?
Спасибо.
Вопрос терминологии. Я это называю распределенной системой.
Взаимодействие с внешними системами: 2http, smtp, imap4, smpp(не используется).
Зачем для EAV 2 таблицы? У нас 1.
Монго, основные понятия:
база: список документов с уникальными id
коллекция: список документов внутри БД (список id)
документ: словарь (объект) «ключ-значение»
связанность/подчиненность документов: поля со списком id
На мой скромный взгляд EAV и никакой магии
Комментарии действительно…
По поводу распределенности:
есть несколько автономных систем, которые обмениваются информацией. Каждая система обрабатывает свою информацию и информацию от других систем. И возвращает результаты. Это можно назвать распределенной системой?
Мы положили в основу EAV, отсюда упор на ДОБД. Json-поля для этого хорошо подходят. В ссылке, которую вы мне дали, автор пишет о них, как об альтернативе mongoDB (про недостатки я тоже прочитал). Все зависит от задачи. Почему использовать в качестве хранилища mongDB — это хорошо, а postgres — это плохо?
В чем на ваш взгляд бардак?
Он, конечно есть, точнее они. Локальные бардачки, помеченные TODO. Мне интересно ваше мнение.
Вам девочка не дает покоя, потому что для разворачивания системы ваши глубокие знания ОС бесполезны? А вас не напрягает то, что на телефонах девочки сами устанавливают приложения? Я светлое будущее вижу так: отметил галочками перед установкой ОС нужное, нажал кнопку и ОС готова. И никаких сисадминов. Простое лучше сложного.
Про наши серверы повторюсь: система распределенная. В каких-то подразделениях работают десятки человек — там сервер под Linux или WinServer. Где-то 1 чел. Там мини-сервер с SQLite. Исходники одни и те же. Клиентское ПО: MFF/GH. Если мини-сервер включен, коллеги имеют доступ к системе по чтению. Красивое решение с минимальным привлечением технарей. Или вам за технарей обидно: то, что должен делать админ, знающий 100 команд, у нас делает девочка, умеющая лайкать няшки?
Причем тут Сова? У вас в голове все смешалось. Сова — это примитивная локальная CRM, написана давно для конкретного человека и выложена в сеть бесплатно.
Почему бы вам не переключиться с критики нашей системы на критику MongoDB и ДОБД вообще. Мы всего лишь по требованию заказчика повторили монгоДБ с хранением данных в РБД. Поиск у нас работает быстрее, чем в монго, запись медленнее. Аналитические отчеты в любой ДОБД будут тормозить. Монго компактней, но это не принципиально. Вложения занимают террабайты, а на размер базы никто не смотрит.
Да, изобрели велосипед. Но:
1. нам за это заплатили
2. велосипед получился удобным: не нужен север mongoDB. Мини-сервер стартует как служба виндовс и может хранить данные в SQLite. Рразвернуть такой сервер может девочка, которая (ужас) даже не знает, какая у нее ОС.
Система не идеальна, список TODO не мал, но вы же ее не видели. Почему ДОБД в РБД это цирк, а ДОБД в mongDB это не цирк?
Я больше 10 лет работаю с госструктурами и не разу с ними не сталкивался. За последние 2 года больше 30 договоров и все через эл. торги. С реальными конкурсами (бывало и с демпингом, бывало и проигрывали). Кому и за что откатывать? Я не ангел, но участвовать в мутных схемах — себе дороже.
IBM интегрировало Lotus Notes и DB2 в 2008.
В Postgres поддержка Json (т.е. возможность реализовать ДОБД в РБД) появилась в версии 9.2. (кажется 2014).
Что касается уровня ваших знаний, то я про них говорить не хочу.
Когда мы применили документориентированный принцип хранения стало лучше: быстрее и гибче.
Кстати ДОБД в РБД не мы придумали. IBM в свое время интегрировало Lotus Notes и DB2. Записи из документориентированной системы (Lotus Notes) хранились в РБД. Почитайте статьи на эту тему, а то у вас взгляд однобокий.