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

[Rin]

Не актуально, удалил

 

[Pez!]

Часть рынка предстоит "отвоевать" у eBay, Яндекс-маркета, price.ru, Авито

Хочется пожелать вам удачи.

 

[grigori]

- Профильное в/о технического ВУЗа
- Активная жизненная позиция
не подхожу :~(

А ТС в курсе, что событийно-ориентированное программирование в PHP и JS практически не применяется?

 

[AmdY]

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

 

[флоппик]

в JS практически не применяется?

Ну, с этим не соглашусь, эвенты в клиентском JS очень часто используются.

 

[Krishna]

А ТС в курсе, что событийно-ориентированное программирование в PHP и JS практически не применяется?

А лично я там PHP и не вижу в списке технологий.


Выбор технологий вообще очень "удивительный", имхо.

 

[Rin]

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

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

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

Krishna
Чем Вас "удивляет" выбор технологий?

 

[Krishna]

Rin

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

 

[grigori]

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

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

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

 

[флоппик]

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

 

[флоппик]

Нет классов, небогатая библиотека стандартных методов, нет инклюдов/класслоадеров (без шаманств), сильно кудрявое приведение типов, что я ещё забыл?

Странно ожидать наличие классов в языке у которого основная оо-пападигма это прототипирование вместо классового наследования.
отсутствие инклудов в клиентской версии JS очевидно вытекает из того, что HTTP это протокол запрос-ответ без сохранения состояния. В серверных реализациях они естественно есть. Явное приведение типов там вполне нормальное для ООП — а неявное приведение типов всегда чревато, не только в JS.

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

 

[Krishna]

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

Я и имел ввиду парадигму "прототипирования" под недо-ООП

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

Совершенно неочевидно Более того, никакой связи не вижу.

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

И вероятно они "на раз" опровергаются популярностью JS на серверсайде?

 

[флоппик]

Я и имел ввиду парадигму "прототипирования" под недо-ООП

это не недо-ООП. это просто ДРУГАЯ парадигма.
Прототипное программирование — стиль объектно-ориентированного программирования, при котором отсутствует понятие класса, а повторное использование (наследование) производится путём клонирования существующего экземпляра объекта — прототипа.

Совершенно неочевидно Более того, никакой связи не вижу.

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

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

 

[флоппик]

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

 

[Здыхлик]

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

 

[Rin]

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

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

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

 

[Krishna]

это не недо-ООП. это просто ДРУГАЯ парадигма.

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

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

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

Налицо когнитивный диссонанс - ведь HTML документы с несколькими тегами <script src=".."> это именно инклюды, только управляемые извне самих скриптов. Не вижу никаких принципиальных различий.

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

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

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

 

[Rin]

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

 

[Krishna]

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

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

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

 

[Raziel[SD]]

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

Это на основании теории или практики использования node.js? (масштабирование)