Я долго пытался найти что-то хорошее опенсорсное в от ERP до CMS и не нашел пока что. Для PHP лучшим выбором по CMS сегодня это по-прежнему Drupal. А на супер-хитовом nodejs вообще нет ничего подобного чтобы работало. Те CMS которые я примерно год назад пытался прспособить как каркас для разработки по функционалу весьма ограничены и по производительности просто нерабочие (на реальныз сайтаз явно блокируется движок JavaScript и сайты нерабочие). Это и не удивительно. наверное прошло время когда могли зародиться такие вот проекты энтузиастов (Drupal, Wordpress). Сейчас в опенсорс попадают продукты немного другим путем — через коммерческие организации (react, go, tarantool, openresty, lapis) и цель насколько я могу понять это получение базы для тестрования и новых идей для разработки. Но что касается готовых коммерческих продуктов на важные для бизнеса темы это уже за отдельную плату.
Ну да это же замена todoapp. Мне сложно представить какой тестовый проект можно создать и привлечь сотню разработчиков чтобы протестить продукт который к моменту окончания проекта утратит актуальность. Кстати что такое разделение приложения на контексты?
github.com/gothinkster/realworld это интересный проект который реализует разными библиотеками и фреймверками фронтенд и бэкенд приложения упрощенного medium.com Там есть готовые примеры в частности и на react/redux. По ощущению от работы мне очень понравился проект на elm но его код слишком сложен и необычен. В issue этого репозитария есть еще больше приложений разной степени готовности (в частности есть и моя реализация react(redux)-hot-universal на стадии ревью кода).
Этот проект как раз ответ бесконечным ToDoApp которые так красиво делать на vanilla backbone.
(«А теперь перейдем к чему-то более практичному. Предположим Ваш марсолет должен ....»)
Спасибо интересная статья. Правда как я понял из контекста это все же не работет на продакшине, а то что работает (как я понял тоже Go только без оптимизации) нет конкретной статистики. Про erlang конкретно я имел в виду исключительно решение с большим количеством сокетов. (см. phoenixframework.org/blog/the-road-to-2-million-websocket-connections ).
По поводу судьбы redux — есть совсем новый доклад от Дэна Абрамов www.youtube.com/watch?v=CWXkcAe_mJA я его даже встрчал на этом сайте с переводом сейчас не могу найти возможно удалили. В свете предстоящих изменений redux вполне может стать неактуальным.
Самая большая трабла с redux/react это асинхронная загрузка данных с сервера то есть то что присутсвует на каждой странице. У Вас фактически есть два возможности реализации
1) Пред-загрузить данные с сервера и после это отристовать компонент (сложновато)
2) Сделать отрисовать компонент-заглушку и после этого реальный компонент с данными (отять же трудоемко в каждом компоненте программировато два стстояния с данными и без данных) И в этом случае страница будет «прикольно» прыгать по мере загрузки данныхв компонент что мы модем наблюдать на сайтах даже на самых авторитетных типа NYTimes.
Новые возможности которые планируются в react должны порешать эту проблемы и как раз в основном на решение этой проблемы и направлены. Но redux в эту схему как-то не вписывается.
Спасибо и за пример и за реальную статистику. Чисто теоретически я вобщем-то был уверен в том что решения на основе Erlang это наиболее удачное решение для веб-сокетов. То что Go показал сравнимую производительность в тестах это еще не гарантирует сравнимую производительность на проде (и не исключает ее). Хотелось бы посмотреть на реальную статистику реальных приложений на Go, если она у кого-нибудь имеется.
Ну я надеюсь что человек которы будет смотреть на репозитарий вполне разбереться с этим всем. Если код в репозитарии плохой то 1) претендент может его не показывать это же не как раньше есть ли у Вас родственники за границей и нужно отвечать правдут т.к. все равно будет проверяться 2) я лично не верю в эти оегенды что тут у меня код плозой т.к. я торопился и все такое а вообще то у меня код белый и пушистый. Да и стиль работы он не меняется от языка к языку, от работы к работе.
Уже второй раз за сегодня читаю мысль о том что создать репозитарий для обучения на github это что-то вроде преступления. Репозитарий на github при оценке сотрудника вполне заслуживает внимания как один из факторов т.к. 1) это реальный код 2) это история коммитов.
Это ещё нужно проверить что будет отставать. Если говорить о php5 + symfony 2 то это так. Но теперь есть
Php7 + symfony 4. И все нужно проверять заново и на реальных задачах и с включенными кэшами и с insert в базы данных. И с 1000 конкурентных обращений. Эта статья мне понравилась не столько цифрами и выводами, сколько самим перечнем cms в которых авторы явно знают толк. Кстати если уже на то пошло не попала базовая cms от сообщества symfony — zulu
Современное состояние react такое что нему уже не нужен next тк с выходом react routee 4 и последних версий webpack для code splitting все можно реализовать на чистом react. В подтверждение этого тезиса я написал несколько сообщений на этом сайте и сделал тестовый проект в рамках проекта reakworld см github.com/gothinkster/realworld/issues/186 примечательно что весь код этого проекта основан на компиляции официальных доков react и webpack
Согласен если говорить о хороших фреймерках. Я же говорю о плохих фреймерках, которых (чужих) только у меня на поддержке в настоящее время четыре. Всен они как один 1. Не документированы 2. Отстали лет на пять 3. Находятся в репозитариях к которым в лучшем случае просто нет доступа на редактирование а в худшем случае вообще нет никакого доступа (то есть проект невозможно развернуть). Я не думаю что это исключитеьная ситуация. Мне даже не так волнует, что при этом страдает поукпатель или ваделец бизнеса (хотя мы же работаем для клиента и на владельца). Мне просто тосклливо вспоминать тот период когда мне пришлось разбираться со всем этим хотя можно было бы более проивзодительно затратить это время на работу с нормальным фреймверком который бы мне обеспечил опыт работы с нормальными технологиями (тем же Vue)
А цмирают порой даже хорошие идеи из-за разных обстоятельств. Например не смог автор собрать вокруг себя сообщество. Или же была неверная маректинговая политика. Из последних крупных таких фейлов — прекращении разработки RethinkDB — и это уже после выхода в подакшн (есть еще надежда что это проект получит развтите как open sorce — хотя весьма слабая надежда).
Спасибо за интересную информацию. Ничего не знал о таком полезном проекте. Честно говоря примеры с ToDoApp меня уже давно перестали интересовать тк порой то что так красиво и элегантно реализовано в ToDoApp не всегда означает что проект из реального мира будет так же лаконичен. Мне чисто по работе больше всего понравился проект на Elm. Хотя его синтаксис сложен для понимания. И не знаю может ли он быть изоморфным а это я считаю основным если делать не админку или внутри корпоративное приложение. Вдохновленный Вашим примера я запилил react hot universal реализацию github.com/gothinkster/realworld/issues/186
Вышла версия 4.1.1 в которой пофикшены баги по code splitting. Например в нулевых версиях его нельзя было отключить или если можно то неясно как это сделать. Сейчас по умолчанию оно отключено. Сейчас я подумал а может быть это даже такой ход был чтобы обратить внимание разработчиков на интересную возможность?
Мне как раз приходится поддерживать (чужой) самописный фреймверк и я знаю что это такое.
1. Полное отсутствие документации.
2. Крайне бедный функцонал и отсутствие гибкости (запилить нову фичу фактически нужно лезть в ядро фреймерка).
3. Куча неотловленных багов.
4. Дикая тормознутость (начальная загрузка страницы на слабых девайсах до 20 сек. хотя на десктопах пару секунд).
5. Отсутствие обновлений — ну естественно все же уже наигрались в мега-разработчиков и свалили и вследствие этого использование библиотек и версий языков 5-летней давности.
6. Самый дикий. Черезмерно честолюбивые разработчики на фоне доверявших им менеджеров раположили фрейм в своих приватных репах вседствии чего по невнимательности ли, по злому умыслу ли некоторые репы удаллились вследствии чего приходилось искать их чуть ли не копии на каких-то списанных компьютерах.
Но конечно любоая разработка настоящего и полезного фрема как например Vue или React начинается со «своего фремверка». Тут наверное важнен правильный менеджмент и оценка возможностей. Т.к. если группа из 3 разработчиков начинает гнуть линию в сторону своего фреймверка скорее всего они не понимают во что ввязываются. Т.к. тут важно три момента что любой фрейм это не просто гениальный код это как минимум
— тысячи человеко-часов работы
— тестирование, документация
— поддержка версий продукта, обновления в связи с выходом новых версий связанных продуктов.
Да я не списую. Реальность такова, что недавно на одной фирме не прошли испытательный срок доктор физ-мат наук и программист разрабатывавший в свое время ПО управлением железом в к-мической тематике. Им было за 50 лет. Хотя я встречал и обратные варианты. Как говорят, исключение это подтверждение правила. 50-60 лет это скорее метафора. Как правило большинство программистов сгорает раньше — к 35. Просто действует парадокс выжившего в катастрофе. Мы общаемся с теми кто остался и ничего не знаем о тех кто сошел с дистанции и даже приблизительно не представляем например коэффициент дожитя в профессии и как он будет меняться в последующее время. Как утверждают некоторые футуристы новый глобальный (не только отечественный) кризис на рынке труда программистов нужно ожидать через 10 лет. Пусть это будет неправильный прогноз. Но за 40 лет будет точно.
Этот проект как раз ответ бесконечным ToDoApp которые так красиво делать на vanilla backbone.
(«А теперь перейдем к чему-то более практичному. Предположим Ваш марсолет должен ....»)
Самая большая трабла с redux/react это асинхронная загрузка данных с сервера то есть то что присутсвует на каждой странице. У Вас фактически есть два возможности реализации
1) Пред-загрузить данные с сервера и после это отристовать компонент (сложновато)
2) Сделать отрисовать компонент-заглушку и после этого реальный компонент с данными (отять же трудоемко в каждом компоненте программировато два стстояния с данными и без данных) И в этом случае страница будет «прикольно» прыгать по мере загрузки данныхв компонент что мы модем наблюдать на сайтах даже на самых авторитетных типа NYTimes.
Новые возможности которые планируются в react должны порешать эту проблемы и как раз в основном на решение этой проблемы и направлены. Но redux в эту схему как-то не вписывается.
Php7 + symfony 4. И все нужно проверять заново и на реальных задачах и с включенными кэшами и с insert в базы данных. И с 1000 конкурентных обращений. Эта статья мне понравилась не столько цифрами и выводами, сколько самим перечнем cms в которых авторы явно знают толк. Кстати если уже на то пошло не попала базовая cms от сообщества symfony — zulu
А цмирают порой даже хорошие идеи из-за разных обстоятельств. Например не смог автор собрать вокруг себя сообщество. Или же была неверная маректинговая политика. Из последних крупных таких фейлов — прекращении разработки RethinkDB — и это уже после выхода в подакшн (есть еще надежда что это проект получит развтите как open sorce — хотя весьма слабая надежда).
1. Полное отсутствие документации.
2. Крайне бедный функцонал и отсутствие гибкости (запилить нову фичу фактически нужно лезть в ядро фреймерка).
3. Куча неотловленных багов.
4. Дикая тормознутость (начальная загрузка страницы на слабых девайсах до 20 сек. хотя на десктопах пару секунд).
5. Отсутствие обновлений — ну естественно все же уже наигрались в мега-разработчиков и свалили и вследствие этого использование библиотек и версий языков 5-летней давности.
6. Самый дикий. Черезмерно честолюбивые разработчики на фоне доверявших им менеджеров раположили фрейм в своих приватных репах вседствии чего по невнимательности ли, по злому умыслу ли некоторые репы удаллились вследствии чего приходилось искать их чуть ли не копии на каких-то списанных компьютерах.
Но конечно любоая разработка настоящего и полезного фрема как например Vue или React начинается со «своего фремверка». Тут наверное важнен правильный менеджмент и оценка возможностей. Т.к. если группа из 3 разработчиков начинает гнуть линию в сторону своего фреймверка скорее всего они не понимают во что ввязываются. Т.к. тут важно три момента что любой фрейм это не просто гениальный код это как минимум
— тысячи человеко-часов работы
— тестирование, документация
— поддержка версий продукта, обновления в связи с выходом новых версий связанных продуктов.