Вакансия: ищу профессионалов в команду нового стартапа (поиск товаров и услуг)

Rin

*
Не актуально, удалил
 
Последнее редактирование:

AmdY

Пью пиво
Команда форума
О. ждал пока начнут флеймить. Ещё из оффтопика, вы действительно применяли где-то Fossil? Мне интересно, можно ли его как-то сделать многопользовательским?
 

Rin

*
grigori
>не подхожу :~(
У каждого правила есть исключения, у вас могут быть глубокие знания по другим пунктам.

Выполнение большинства клиентского JS кода в браузере запускается именно событиями.
В NodeJS асинхронность и управление событиями есть, в PHP этого нет.

AmdY
Fossil "в бою" не использовал, написал его "до кучи", т.к. важен опыт использования какой-либо VCS.
Почему Вы решили, что он не многопользовательский? :)

Krishna
Чем Вас "удивляет" выбор технологий?
 
  • Like
Реакции: AmdY

Krishna

Продался Java
Rin

Удивляет тем, что мне абсолютно не понятно, какие преимущества могут быть у событийно-ориентированной парадигмы на сервер-сайде HTTP приложения.
Ибо в HTTP события отсутствуют (разрыв соединения, разве что?), по определению протокола, работающего по принципу "запрос-ответ".
Зато, мне понятно, что писать приложение с развитой логикой на "бесклассовом недоООП" - не лучшая затея. Я не знаю, чем там отличаются серверные реализации JS, но имхо его клиентская реализация весьма ущербна, когда дело доходит до попыток создания сложных приложений.
Нет классов, небогатая библиотека стандартных методов, нет инклюдов/класслоадеров (без шаманств), сильно кудрявое приведение типов, что я ещё забыл?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
> Выполнение большинства клиентского JS кода в браузере запускается именно событиями.
> эвенты в клиентском JS очень часто используются.
поправлю: пишется обработка события, каждого в отдельности последовательно, а событие - просто входящие данные,
кто-то пишет циклы для обработки множества событий параллельно на автоматах? на JS это невозможно!

в NodeJS на сервере надо самому писать обработку fcgi-запросов?? в одном приложении, в одном потоке и окружении, можно обрабатывать много параллельных запросов со стороны nginx?

в PHP СОП встречается только в двух местах - неблокирующие сокеты и CURL Multi
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Я не специалист по ноде, но насколько я знаю, она полноценная асинхронная система управляемая событиями.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Нет классов, небогатая библиотека стандартных методов, нет инклюдов/класслоадеров (без шаманств), сильно кудрявое приведение типов, что я ещё забыл?
Странно ожидать наличие классов в языке у которого основная оо-пападигма это прототипирование вместо классового наследования.
отсутствие инклудов в клиентской версии JS очевидно вытекает из того, что HTTP это протокол запрос-ответ без сохранения состояния. В серверных реализациях они естественно есть. Явное приведение типов там вполне нормальное для ООП — а неявное приведение типов всегда чревато, не только в JS.

Поэтому твои претензии несколько... беспочвенны.
 

Krishna

Продался Java
Странно ожидать наличие классов в языке у которого основная оо-пападигма это прототипирование вместо классового наследования.
Я и имел ввиду парадигму "прототипирования" под недо-ООП

отсутствие инклудов в клиентской версии JS очевидно вытекает из того, что HTTP это протокол запрос-ответ без сохранения состояния.
Совершенно неочевидно :) Более того, никакой связи не вижу.

Поэтому твои претензии несколько... беспочвенны.
И вероятно они "на раз" опровергаются популярностью JS на серверсайде? :)
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Я и имел ввиду парадигму "прототипирования" под недо-ООП
это не недо-ООП. это просто ДРУГАЯ парадигма.
Прототипное программирование — стиль объектно-ориентированного программирования, при котором отсутствует понятие класса, а повторное использование (наследование) производится путём клонирования существующего экземпляра объекта — прототипа.
Совершенно неочевидно :) Более того, никакой связи не вижу.
Классический HTTP отдает один документ на один запрос. И одна HTML страница это просто набор НЕЗАВИСИМЫХ документов. Состояние выполнения (показа) этих документов никак не хранится и не передается — для того что бы реализовать честные инклуды нужно 1 — мочь запросить другой документ в процессе исполнения первого, 2 — поскольку инклуды могут быть условными (зависимыми от переменных) код в запрошенном документе должен исполнятся в определенное время относительно других документов, что тоже невозможно.

А что до популярности — она вообще никак не коррелирует с качеством языка — пхп тому хорошее подтверждение.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Я заметил, это частое явление: «Купил айфон — все остальные телефоны полное гавно, выучил яву — других парадигм программирования не существует»
 

Здыхлик

Kohaner
Команда форума
Впервые вижу участие в OpenSource обязательным требованием к кандидату :)
 

Rin

*
grigori, для того, чтобы сделать сервер, достаточно только NodeJS.
В связке Nginx (frontend) + NodeJS (backend) как минимум проще и быстрее раздавать статику.

Изучите немного nodejs, не пожалеете!
Рекомендую ещё эту отличную презентацию!

Кстати, обсуждение идёт совсем не по теме.
 

Krishna

Продался Java
это не недо-ООП. это просто ДРУГАЯ парадигма.
Вот эта "ДРУГАЯ" парадигма, в моём представлении, не подходит для создания крупных приложений. Она подходит для небольшого клиент-сайда, где критичен объём исходного кода, в чистом виде.

Приложение-конкурент яндекс-маркета - крупное.

Классический HTTP отдает один документ на один запрос. И одна HTML страница это просто набор НЕЗАВИСИМЫХ документов. Состояние выполнения (показа) этих документов никак не хранится и не передается — для того что бы реализовать честные инклуды нужно 1 — мочь запросить другой документ в процессе исполнения первого, 2 — поскольку инклуды могут быть условными (зависимыми от переменных) код в запрошенном документе должен исполнятся в определенное время относительно других документов, что тоже невозможно.
Налицо когнитивный диссонанс - ведь HTML документы с несколькими тегами <script src=".."> это именно инклюды, только управляемые извне самих скриптов. Не вижу никаких принципиальных различий.

А что до популярности — она вообще никак не коррелирует с качеством языка — пхп тому хорошее подтверждение.
В данном случае коррелирует. PHP при всех его незначительных недостатках вполне справляется с ставящимися перед ним задачами.
JS очевидно нет, т.к. присутствие в вебе количестве сопоставимом с погрешностью измерений имхо говорит о негодности решения.

З.Ы. Про яву - вообще какой-то нелепый переход на личности, никак не связанный с темой разговора.
 

Rin

*
Говоря про СОП нужно говорить и о асинхронности.
Если блоки большой html-страницы собирать асинхронно, а не последовательно, то целая страница в ряде случаев отдается быстрее.
К тому-же такой подход проще и лучше масштабируется.
 

Krishna

Продался Java
Говоря про СОП нужно говорить и о асинхронности.
Если блоки большой html-страницы собирать асинхронно, а не последовательно, то целая страница в ряде случаев отдается быстрее.
К тому-же такой подход проще и лучше масштабируется.
У Вас есть реальный опыт извлечения преимуществ в масштабировании из асинхронной сборки страницы? Честно говоря, больше похоже на увлеченность теоретическими изысканиями.
Мало что лучше масштабируется, нежели чистый PHP, который, если говорить о приложении без учёта работы с СУБД масштабируется строго линейно. Надо в 2 раза больше запросов обработать - удвой количество серверов.
Основные проблемы масштабирования веб-приложений на PHP лежат в области взаимодействия с базой и как тут поможет эта асинхронная сборка страницы - я не очень понимаю. Уверен, что о качественном превосходстве говорить в любом случае не придётся.

А вот как серверный JS помешает реализации и поддержке логики сложного приложения - я понимаю вполне.
Может быть Вам известны опровергающие меня примеры крупных и в достаточной степени нагруженных логикой ресурсов на server-side JS?
 

Raziel[SD]

untitled00
Говоря про СОП нужно говорить и о асинхронности.
Если блоки большой html-страницы собирать асинхронно, а не последовательно, то целая страница в ряде случаев отдается быстрее.
К тому-же такой подход проще и лучше масштабируется.
Это на основании теории или практики использования node.js? (масштабирование)
 
Сверху