Pull to refresh
235
0
Timur Shemsedinov @MarcusAurelius

Chief Technology Architect at Metarhia

Send message
Ну это же ужасно, в 2 раза больше памяти, а вдруг будет наложение, так что 3 раза хранить. А потом когда разлипнет процесс, то что, эту память нужно синхронизировать между процессами, она же изменится.
Что с того, что им можно немного управлять и немного мониторить. Ну это ни как не устраняет неэффективность дефолтного сборщика мусора и менеджера памяти в целом для задач с большими данными.
Не могу выразить, насколько этого понимания не хватает широкой общественности.
Нельзя сводить все к REST, там, где мы оперируем цельными ресурсами и файлами, там можно использовать Stateless подход, а где явно есть множество глаголов, то нужен RPC. Основное преимущество REST — ответ на вопрос «зачем?» это масштабирование. Потому, что RPC обычно имеет состояние, более того, состояние прямо в памяти сервера, да еще и долговременное соединение (вебсокеты, SSE, long polling). Но это не значит, что RPC не может масштабироваться, ему просто нужен другой балансировщие, не раундробин, а приклеивание по IP или по Cookie, а если RPC происходит через двунаправленный и долгосрочно открытый вебсокет, то и прилипание не нужно, потому, что сам вебсокет и есть состояние, к сокету состояние на сервере или сессия и приклеивается, и сервер не меняется пока не разорвется связь.

Вполне хороший подход, когда вся статика работает через REST, это же файлы их так и обрабатывает с отдельного домена, а вся динамика работает через RPC и вебсокеты (с другого домена), а урлы идентифицируют не ресурсы, а методы (глаголы). Более того, когда на клиенте развивается направление байндинга данных и GUI (тот же React), то байндить же можно и дальше сквозь сокет прямо на сервер и это прекрасно. При чем, синхронизацию состояний можно оптимизировать, чтобы не передавать все изменения мгновенно, а накапливать буфер или за малый временной промежуток и пересылать пачкой. В базу или на диск сервер может читать/писать исключительно в отложенном режиме, состояние нужно конечно персистать, но это же не нужно делать прямо во время запроса, можно отдать ответ и уже неспешно сохранить, да еще и склеить изменения за определенное время.

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

Тут подробнее http://habrahabr.ru/post/204958/
Ладно, если бы не совпадало с научным определением, так это понимание еще и препятствует эффективной разработке, порождая лишние сущности, ничего не дающие ограничения и непонимание между специалистами. Если клубок ниток запутан, то его можно использовать только как смешной балабон для шапки, но чтобы связать саму шапку, все же придется распутать нитки.
Проблема в том, что ракета летит какое-то время, вот пока она летит — живет состояние, т.е. первая команда может прислать ей цель, остальные корректировать и уточнять цель, типичный случай для RPC, даже, если команда одна — стартовая, то состояние сохраняется до конца полета и можно, как минимум, проверять состояние процесса, прогресс, координаты.
Не нужно стараться впихнуть невпихуемое, REST не везде подходит: habrahabr.ru/post/204958/
Только недавно обсуждали варианты реализации, Ваш хорош лаконичностью и альтернативными механизмами (передача данных через кукизы и использованием событий закрытия вкладок/окон), но есть и минусы: если вкладки виснут, или залипают на время (что не редкость) то мастеров станет несколько, поэтому без heartbeat для каждой вкладки не обойтись. Надеюсь, кто-то слепит все вместе, уже почти-почти.
О, еще такая штука, я написал, что за приоритет лучше брать время создания вкладки, но теоретически, оно может и совпасть у нескольких вкладок. В своем примере я сначала использовал время последнего хартбита (сигнала об активности) от этой вкладки, записанного в localStorage — тут я ошибся, оно совпадало уже чаще и я перешел на приоритеты по id вкладки, чем больше id, при условии, что время не просрочено, тем выше приоритет. Есть, конечно, слабая вероятность, что вкладки неправильно выберут мастера из-за того, что localStorage не имеет локинга, т.е. мы теряем преимущества однопоточности JavaScript при доступе к разделяемым данным, и пока одна вкладка читала последовательно несколько ключей в localStorage, то другая могла изменить один из них. Мы не можем сделать локинг или транзакцию тут. Но в реальности мне не удалось запутать эту реализацию. Приведу скриншот того, как выглядит localStorage при работе программы: image
Тут видно, что я пишу хартбит для каждой вкладки, старые хартбиты удаляются мастером, как только время хартбита устаревает, вкладка или закрыта или зависла. Новые вкладки занимают место (слоты) старых. Работает это по принципу «один за всех, и все за одного», т.е. мастер следит за каждым, а за мастером следят все. Отдельно пишется impress.rpc.master — id текущего мастера и impress.rpc.newtab — id последней созданной вкладки. Писать impress.rpc.master нужно потому, что это создает событие изменения localStorage и все клиенты быстрее понимают, что новый мастер уже выбран, а impress.rpc.newtab так же создает событие изменения localStorage для того, чтобы мастер быстрее отправил свой хартбит, это ускоряет подключение новой вкладки при старте. В общем, вышло нетривиальное решение. Надеюсь, это поможет при реализации кода.
Ну «Клиентская оптимизация» потому, что позволяет сократить кол-во операций, соединений и других ресурсов в браузере. То, что дублировалось в 10 вкладках, может делаться в одной и использоваться в остальных через механизм межвкладочного взаимодействия, например, автор использует это для снижения кол-ва comet соединений, но дать ясные пояснения по этому поводу не мешало бы. Вот использование Comet в то время, как можно было бы применить более современные Server-Sent Events или WebSocket — это для меня загадка. И хаб «ajax» тоже непонятно к чему тут.
Вниманию Levhav, как Вы сами знаете, если зависшая вкладка отвисает, то становится 2 мастера, и как обнаружил beliyadm, больше одного мастреа становится не только в этом случае. В общем, механизм выбора нового мастреа работает через раз. Попробуйте сами, создайте 30 вкладок, выводить master/slave в заголовок, чтобы проще ориентироваться прямо по вкладкам, и закрывайте их по одной или пачками по 2-3, там еще один эффект. В общем, я когда-то сталкивался с этой проблемой и уже решал ее, сейчас нашел старое решение в коде приложения и перенес его в пример клиентского приложения в своем сервере приложений Impress для node.js. Код открыт, можете взять идею тут, я выделил 150 строк.
Ну и по модульности, я вот не понял, по какому принципу код разделен на две части, одна внутри страницы, а другая в файле. Между этими двумя частями высокая логическая связанность (обе знают друг о друге и по отдельности не работают), лучше объединить все в один модуль.
100%, я когда-то реализовывал подобное, столкнулся с той же проблемой, в результате нужно делать выборы нового главное, проще всего это сделать через приоритеты, например, при старте каждой вкладки писать в localstorage время ее создания, а при выборах, например, самая последняя вкладка будет иметь приоритет, если она не взяла на себя роль нового главного за N миллисекунд, то берет более старая и т.д.
Ради всего святого, выберите один стиль для кода, и пройдитесь по нему jshint-ом, мне было больно читать.
Да, но дело в качестве преподавания и в нанизывании этих знаний на общий скелет инженера. Зачем мне все эти предметы: теория информации и кодирования, теорвер, ТАУ (теория автоматизированного управления), СМО (системы массового обслуживания), численные методы, системный анализ, планирование эксперимента, я понял много позже выпуска, после практического опыта программирования поднял книги, и теперь основой вдохновения для написания своего кода, я вижу как раз эти дисциплины, а не расхожие паттерны из популярных книжек.
Законы управления едины, что в технических, программных, экономических и социальных системах. Есть конечно особенности, но фундаментальная наука об управлении — это кибернетика, и она содержит все обобщения, теорию и подходы даже для управления коллективами людей, а менеджмент не содержит фундаментальной научной базы и является всего лишь устным народным приданием, передаваемыми из уст в уста легендами о том, как когда-то у кого-то что-то сработало.
1. Имеет смысл больше уделить внимание разным парадигмам программирования: функциональному, декларативному, императивному, ООП, автоматному, реактивному, метапрограммированию ( habrahabr.ru/post/227753/ ) и т.д. По этому поводу советую почитать письмо Дейкстры habrahabr.ru/company/hexlet/blog/248921/
2. Моделирование данных, как по мне, это более важная дисциплина, даже чем теория алгоритмов, и вот структуры данных, лучше поместить именно в моделирование данных, (а не в теорию алгоритмов), рядом с реляционной, иерархической, сетевой и др. моделями данных.
3. Жаль, что не увидел в этой схеме место кибернетики (науки об управлении), за то управлению командами разработки, по сути менеджементу (лженауке об управлении) место нашлось.
То что эта схема чем-то хороша, следует не из того, что автор учился программировать именно по ней, это следует из самой схемы. Она не идеальна, конечно, но ни что не идеально.
По поводу промисов, я планирую их реализацию в 0.3 уже, потому, что это изменит многие вещи, а хотелось бы ответвить уже 0.2 и держать ее в стабильном виде для ежедневной разработки. Быстрое развитие — это конечно хорошо, но в 0.1 все страдали от того, что каждые 10-15 минорных версий обязательно что-то критическое менялось и нужно было рефакторить приложения, а отказаться от обновлений тоже нельзя, потому, что в них и ошибки же закрываются.

Одна из основных фич в том, что на одном порту можно сделать все, мультиплексируется по урлам, на одном урле SSE, на другом WebSocket, и тех же событийных каналов много можно одновременно на разных урлах держать, ну и на том же порту API и стриминг и статика и контент и все остальное. На ноде же обычно много портов открыто для каждой задачи специфический порт, и так выходит, что даже для не очень сложных приложений уже 2-5 портов открыто. А потом какой-то маршрутизатор рубит все кроме 80 или CORS не пропускает или еще что-то, в общем мультиплексирование в ноде не развито совсем.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity