Никто вас не будет заставлять вставать по гудку если вы не согласитесь с этим поступая на работу в фирму как удалённый сотрудник. Просто пытаются разработать закон облегчающий наём на работу таких сотрудников.
И ещё, часть заработка — т.е. налоги, платить надо. Медицина, армия, полиция — всё это должно быть хорошим, но часть заработка вы конечно же при этом не хотите отдавать государству.
Проблема есть. Она заключается в необходимости модульного описания определённого элемента веб-интерфейса. Чтобы для него был механизм описания разметки, стилей и логики.
И тут начинаются нюансы. С одной стороны хочется чтобы оно было «в одном месте», с другой стороны когда оно в одном месте, не так уж и радует потому что «как-то в кучу».
Это «новое от гугла» похоже одна из попыток решить проблему. У меня в процессе чтения возникло как-раз ощущение «как-то в кучу всё».
Возмётесь писать реалтайм web-приложения на node.js и о третьем подумывать начнёте. Хотя это перебор уже, двух достаточно… Если плюс ко всему торговлей в EVE-Online не увлекаетесь, конечно…
Если клиент отказывается отвечать на мои вопросы и продолжает требовать «просто сделать сайт и всё!», я с вероятностью 99.999(9)% отказываюсь от такого предложения.
Также и вашему клиенту, не нужен сайт, ему нужно повышение продаж, представление продукции, раскрутка бренда.
Обычно как раз наоборот:
— Здравствуйте, мы фирма XXXX и нам нужен сайт!
— Зачем он вам нужен? Какие задачи вы хотите решить? Чем занимается ваша компания? Ваша ЦА?
— Нам вас порекомендовали, вы же делаете сайты?!!!
«против»: я переписал бы или удалил Backbone.sync. Он построен для протокола HTTP и плохо приспосабливается к особенностям WebSocket.
В своё время, переопределив Backbone.sync для приложения использующего Socket.io я окончательно проникся мощью этого фреймворка. Сменой одного метода, меняется взаимодействие с бекэндом, без изменения архетиктуры фронтэнд-кода.
в последствии, в веб-приложениях реального времени вообще отказался от обмена данными через Backbone.sync, там каждая модель или коллекция работает в своём неймспейсе по Socket.io самостоятельно. Backbone.sync там как таковой становится просто не нужен.
Я на два монитора перешел как начал писать на node.js веб-приложения реального времени с использованием socket.io.
Специфика такова, что необходимо иметь перед глазами минимум 3 вещи: открытую IDE, браузер с клиентской частью приложения и консоль с «потоком сознания» бекенда. После 3-х дней мучений с одним 24" монитором, пошёл купил второй 19" монитор устанавливающийся портретно.
Нагрузка на нервную систему снизилась многократно.
Может оно конечно и не техническое усовершенствование рабочего места, но для меня например очень важна возможность дневного сна. Мою производительность это очень даже повышает.
У меня тоже в своё время такое было. Работая в одной компании, считал что самый лучший день недели для работы это суббота. А потом меня что-то осенило и я уволился…
Довольно часто, те кто реально что-то делает, потом не пишут о своих решениях на ресурсах подобных хабру. Почему-то такие люди часто так себе публицисты.
На счёт «выгодности» платформы. Стоимость решения определяется не сколько платформой, сколько степенью продуманности решения. В своё время стал очевидцем ситуаций, когда ставка на и на дешёвых «PHP-шников», и на дешёвых «1С-ников» приводила к бардаку в проекте при неспособности решить основные задачи.
Выгодна та платформа, которая наиболее полно решает конкретную задачу. Причём часто это симбиоз платформ и сложность возникает в области интеграции веба и 1С. В связи с этим, связка 1С + веб-разработчик которые понимают другдруга с полуслова — на вес золота.
При одновременной торговле с одного склада розницей и ИМ, в вопросе что будет первичной базой, 1С или CMS мы для себя пришли к противоположному мнению:
На сайте отображается состояние каталога и делается заказ, который появляется в журнале заказов 1С. В дальнейшем, оператор ведёт все продажи в 1С. Веб-интерфейса он вообще не видит. Товар резервируется централизовано в первичной базе.
У нас уже был магазин с кассами на 1С, соответственно пришлось прикручивать ИМ так, чтобы он был интегрирован в текущую розничную схему продаж и не дублировал функции первичной базы веб-интерфейсом.
И ещё, часть заработка — т.е. налоги, платить надо. Медицина, армия, полиция — всё это должно быть хорошим, но часть заработка вы конечно же при этом не хотите отдавать государству.
Считаю, вам надо повзрослеть.
И тут начинаются нюансы. С одной стороны хочется чтобы оно было «в одном месте», с другой стороны когда оно в одном месте, не так уж и радует потому что «как-то в кучу».
Это «новое от гугла» похоже одна из попыток решить проблему. У меня в процессе чтения возникло как-раз ощущение «как-то в кучу всё».
Обычно как раз наоборот:
— Здравствуйте, мы фирма XXXX и нам нужен сайт!
— Зачем он вам нужен? Какие задачи вы хотите решить? Чем занимается ваша компания? Ваша ЦА?
— Нам вас порекомендовали, вы же делаете сайты?!!!
В своё время, переопределив Backbone.sync для приложения использующего Socket.io я окончательно проникся мощью этого фреймворка. Сменой одного метода, меняется взаимодействие с бекэндом, без изменения архетиктуры фронтэнд-кода.
в последствии, в веб-приложениях реального времени вообще отказался от обмена данными через Backbone.sync, там каждая модель или коллекция работает в своём неймспейсе по Socket.io самостоятельно. Backbone.sync там как таковой становится просто не нужен.
Специфика такова, что необходимо иметь перед глазами минимум 3 вещи: открытую IDE, браузер с клиентской частью приложения и консоль с «потоком сознания» бекенда. После 3-х дней мучений с одним 24" монитором, пошёл купил второй 19" монитор устанавливающийся портретно.
Нагрузка на нервную систему снизилась многократно.
«146%»?
На счёт «выгодности» платформы. Стоимость решения определяется не сколько платформой, сколько степенью продуманности решения. В своё время стал очевидцем ситуаций, когда ставка на и на дешёвых «PHP-шников», и на дешёвых «1С-ников» приводила к бардаку в проекте при неспособности решить основные задачи.
Выгодна та платформа, которая наиболее полно решает конкретную задачу. Причём часто это симбиоз платформ и сложность возникает в области интеграции веба и 1С. В связи с этим, связка 1С + веб-разработчик которые понимают другдруга с полуслова — на вес золота.
На сайте отображается состояние каталога и делается заказ, который появляется в журнале заказов 1С. В дальнейшем, оператор ведёт все продажи в 1С. Веб-интерфейса он вообще не видит. Товар резервируется централизовано в первичной базе.
У нас уже был магазин с кассами на 1С, соответственно пришлось прикручивать ИМ так, чтобы он был интегрирован в текущую розничную схему продаж и не дублировал функции первичной базы веб-интерфейсом.