Двенадцать разработчиков на постоянной основе для одного сервиса аренды недвижимости?
Используя эту архитектуру можно почти все модули взять из сторонних решений. То есть вам придется запилить всего 2-3 модуля, а не все 5.
Даже при желании можно взять несколько сторонних сервисов и объединить в один проект, по сути так и работают различные агрегаторы. Используют API сторонних проектов как микросервисы и работают с ним, чтобы предоставить единый инструмент.
Хабр — не твиттер. Сделайте рассылку вашим клиентам. Напишите в свой персональный блог небольшую новость.
Сюда кидайте дайджест. 1-2 раза в неделю не более.
Подробнее рассказывайте и т.д. А не одну картинку и пол странички текста.
Может поменьше постов? Вчера 2, сегодня один. Даже прописано ведь, в среднем 2 поста в неделю, если вы конечно не Google или Microsoft.
У вас 9 материалов за месяц. 4 на этой неделе.
И большая часть статей на 1-2 странички. Может стоит подождать недельку и сообщить о всех новостях сразу в одной статье?
Я скорее всего в дополнении еще сделаю вариант с сокетом и сделаю дополнения с сокетом для других платформ, ну либо буду использовать их пуш сервисы.
В общем то пока производители не пришли к общему мнению, думаю я могу пока что все эти решения интегрировать у себя и предоставлять общий API для всех браузеров и смартфонов. Да и когда придут к новому протоколу — я просто у себя все обновлю, а владельцам сайтов не придется ничего менять.
«Условный Петя создал папку. Теперь он ее владелец и имеет право менять разрешения. От безделья он запрещает доступ к папке непонятной ему группе usersCEO. Таким образом он еще запрещает доступ к подпапкам и файлам, владельцем которых он может и не быть.»
Что мешает условному Пете, создать там зашифрованный раздел в виде файла?
С другой стороны я соглашусь с тем, что для общей папки владельцем должен быть вледелец этой самой общей папки. Т.е. люди создающие внутри объекты не должны быть их владельцами.
«Причина в том, что согласно реализованной в Windows концепции discretionary access control (DAC), владелец имеет право на чтение и изменение разрешений. И даже явно указанный запрет для учетной записи не имеет приоритета над правами владельца. „
Разве это не логично? Я владелец — что хочу то и делаю. Иначе выходил бы казус — запретил сам себе доступ к файлу и не можешь его никак вернуть. В линукс системах все также, если ты владелец — ты можешь менять разрешения, даже если у тебя нет никакого доступа.
Просто если уж запрещаешь доступ к объекту, логично и владельца изменить, разве нет?
Тут проблемы есть — один то протокол ест энергию. А если запилить туда сразу все 3-4 то будут проблемы.
Вообще я вижу решение проблемы в некотором мосту. К примеру такой мост представляет Google на iOS.
Будет неплохо, если GCM будет вообще везде, но главное. чтобы он нормально работал. И опять таки, будет неплохо, если гугл его частично откроет хотя бы, я например хотел вообще на WP писать с использованием GCM, на что мне ответили в Google+ — что гугл меня забанит, если я буду использовать GCM в обход правил гугла.
На телефонах то еще ладно, можно поднять сокет в случае проблем, самому получать пуши от своего сервера. А в случае с браузерами эта возможность была ограничена. Воркер дохнет, закрывая сокет.
Так это же фреймворк. Вы не поняли сути, вы можете подключить теги как библиотеки.
Нужен ютуб плеер? Подключил его и все интегрируется тегом, нужна карта? Тоже самое. Причем можно будет обновлять потом эти библиотеки вместе с кодом плееров, карт, аналитики и т.д.
Сам по себе код выглядит чище, чем куча айфреймов и
Личный кабинет моего проекта с каталогом 2.4 мега.
2.1 мегабайт картинок — они достаточно крупные. Около 90 штук.
137 килобайт скриптов.
6 кб стили.
Все что выше — кэшируется.
Сам сайт 4.6 килобайта.
Где то 35 килобайт перезагрузка с учетом кэша выходит.
При этом весь сайт на AJAX. Как итог пользователь один раз грузит где то 2.4 мега при загрузке личного кабинета. Потом при повторых заходах уже 35 КБ, а при переходах по сайту в районе 1-10 килобайт за страничку.
Так что, я даже не знаю хуже стало или лучше. Если раньше каждый сайт грузил кучу контента повторно без сжатия и т.д. загружая каждый раз снова весь сайт. То сейчас грузится все один раз, а потом все работает достаточно шустро.
Было бы еще неплохо, если бы все библиотеки были разделенные для всех сайтов. К примеру тот же jQuery, браузер будет кэшировать несколько основных версий, и если грузится jQuery на новом сайте — он будет использовать выбранную версию. И так для всех библиотек основных. Как итог 10 мегабайт кэша на стороне клиента позволят экономить на них несколько гигабайт суммарно. Т.к. сотня сайтов загружаемых каждый день с практически одинаковыми библиотеками думаю вполне этими библиотеками за месяц гигабайт могут и набить.
Забыл небольшую деталь. У меня RSS интеграция целиком зависит от числа подписчиков. У Feedly к примеру обновление RSS лент длится где то 3 часа. Я даже для каналов с одним подписчиком даю обновлять ленту каждый час. А от 10, раз в 30 минут.
От 100 подписчиков, обновление идет уже раз в 10 минут, что вполне уже в районе мгновенного.
Ну, а если кому то захочется еще быстрее — если более 500 подписчиков, лента будет обновляться раз в минуту. Это ну никак не сравнимо с 3 часами в Feedly.
Начнем с того, что Twitter и RSS это чисто глобальный метод рассылки — один контент всем. Новости например и т.д. Мой сервис вообще изначально нацелен именно на личные пуши: написали вы мне на хабре сообщение — бац я получил пуш. Я ответил вам на комментарий — вам пришел пуш.
И это может сделать абсолютно любой сайт бесплатно. Отправлять мгновенные уведомления сразу на устройства без создания каких либо приложений.
Но сейчас внешне пока что приходится наполнять сворее некой вариацией конвертера Pull в Push. Например тот же RSS надо сканировать постоянно, чтобы получать обноления. На телефоне это означает, что заряд будет сжираться больше.
В плане RSS мой сервис адаптирован не на чтение статей и ленты, а на получение фильтрованных данных. К примеру я разрабатывая свой проект интересуюсь обновлениями хрома, андроида, гуглом и пушами. Подписался на нужные мне каналы и настроил фильтр. В случае если какая то важная новость проскочит — я сразу получу пуш.
И еще отличие от RSS — для большенства пользователей RSS это дремучий лес. Т.е. это какая то волшебная ссылка с метаданными. Мало кто понимает что это такое вообще. Мой сервис дает понятный каталог, похожий на привычные каталоги приложений с каналами, где можно посмотреть ленту, прочитать название, описание, увидеть иконку, и посмотреть ленту.
Push-уведомления должны по сути содержать, что то важное. Если ты отфильтруешь RSS-ку по каким то важным данным (например тебе нужно быстро в случае чего узнать, появилась новая технология или решение) то это будет просто мегаполезно.
Как примеру еще решение с сериалами — серий выходит просто мегамного. До того, как я создал сервис единственным решением следить за этим была подписка на группу вконтакте. Но у многих число групп переваливает за пару сотен. В итоге, к примеру, даже лично я пропускал иногда 2-3 сериала, и только через пару дней, когда уже не было времени их смотреть, я узнавал, что они переведены.
А сейчас я получаю пуш, через канал используя фильтр. Там каждый день идет где то около 20-50 пушей о выходе серий от различных студий различных сериалов. Я получаю 2-3 пуша в сутки по сериалам, которые я смотрю. И эти пуши именно полезны. Я увидел — я узнал что вышла серия. Пришел домой — скачал.
Да более продвинутые вообще через RSS настраивают автоскачивание и т.д. у них еще NAS дома и т.д. Но 90% этого не умеют.
Ну и не совсем понимаю, почему на хабре столько разработчиков и т.д. и мало кто понимает, что через эту штуку можно пушить различные алерты о состоянии работы сервисов, сервера и т.д. Эта информация приватна и нужна только вам. Никакой твиттер или rss вам тут не поможет. Ну а почта — чистить потом эти алерты, да и почту тоже надо обновлять. А пуш прилетел — ты его увидел и стер. На почту разве что можно присылать например потом сводку раз в сутки. Для быстрых каких то уведомлений, когда нужно решить это сейчас это мало подходит.
Я сейчас буду делать упор на создание плагинов к различным CMS. Можно будет поставить плагин и пользователи смогут получать уведомления о различных действиях с этого сайта.
Не совсем так. Даёшь разрешение на отправку уведомлений для PushAll.
А дальше все управление разрешниями ведётся внутри самого PushAll.
Это позволяет к примеру сесть за новый компьютер, разрешить доступ и сразу получать все уведомления от каналов на которые ты подписан со всеми настроенными фильтрами и т.д. то есть можно даже сказать что мой сервис в облаке (в духе современных тенденций)
Именно поэтому есть фильтры. К примеру у меня есть канал СоХабр в системе. Я ввёл в фильтры ключевые слова и по ним получаю уведомления. Это те темы по которым я хочу сразу получать информацию. И каждый для себя может отфильтровать как хочет. А лента канала общая.
RSS же тут только как источник.
Странно, друг кидал инфу — у него где то раз в час обновления шли с RSS-канала.
Вообще официально у него на бесппатном тарифе от 1 до 8 часов может быть.
Для синхронизации ленты это еще неплохо (хотя 3 часа для новости возможно уже критично) Для уведомлений же критично как по мне не более часа. Поэтому даже канал с двумя подписчиками будет сканироваться раз в час.
Если бы я делал Feedly — я бы вообще сделал так, что если кто то заходит в веб-интерфейс или мобильное приложение, то у каналов этого пользователя бы чуть повышался приоритет. Нагрузка от обновления ленты не сильно больше нагрузки от самого пользователя, загружающего страницы сайта. Сжатые ленты многих сайтов весят не более 1 килобайта. Исплользуя кэширование можно существеннно уменьшить любые затраты на проверку.
Кстати хорошая тактика: сделай плохо, а потом все исправь, чтобы тебя хвалили.
Сначала лаги, много занимаемого места и т.д. а потом убери мусор и оптимизируй и тебя все будут любить, хотя оно может быть даже по скорости и весу хуже чем еще более старая версия
Вся прелесть во времени. Они покупают оборудование и сразу продают его вам — сразу имеют прибыль. У вас же прибыль будет через несколько месяцев. Грубо говоря они имеют прибыль сейчас, т.к. уже продали мощности и для них это куда выгоднее. На эти деньги они могут и зарплату раздать и купить новое оборудование для новых заказов.
Единственное что от них требуется — поддержание работы. Причем они могут сдавать и старое оборудование, которое уже мало окупается, но кто то по дешевке будет брать :) И у них могут быть договора на поставку нового оборудования по более низким ценам и сбыт старого железа по выгодным ценам.
К слову если опять таки взять те же Apple и Google — я не думаю, что они расчитывали на такой рост. Скорее всего Стив Джобс думал, что продаст несколько хороших компьютеров и дальше будет понемногу расти и получать просто прибыль, но не думаю, что он ожидал, что эпл станет самой дорогой компанией в мире. Ну и тот же гугл — на момент создания уже были некоторые поисковики, они и не могли предположить, что это принесет им денег вообще.
Проще сразу гугл гласс носить и все. И руки свободные, причем его вроде как можно к зарядке подключить при работе прямо. А для ввода данный вручную да — мобильник использовать.
Возможно тут принцип: работает не трогай. Но теперь то да, либо они это пофиксят, либо сейчас все будут красть данные. К слову статья мягко говоря вредительная. Яндекс еще ничего не исправил, а статья есть. Если раньше мало кто знал, то сейчас любой школьник может получить базы и продавать их кому нибудь менее осведомленному.
Используя эту архитектуру можно почти все модули взять из сторонних решений. То есть вам придется запилить всего 2-3 модуля, а не все 5.
Даже при желании можно взять несколько сторонних сервисов и объединить в один проект, по сути так и работают различные агрегаторы. Используют API сторонних проектов как микросервисы и работают с ним, чтобы предоставить единый инструмент.
Сюда кидайте дайджест. 1-2 раза в неделю не более.
Подробнее рассказывайте и т.д. А не одну картинку и пол странички текста.
У вас 9 материалов за месяц. 4 на этой неделе.
И большая часть статей на 1-2 странички. Может стоит подождать недельку и сообщить о всех новостях сразу в одной статье?
В общем то пока производители не пришли к общему мнению, думаю я могу пока что все эти решения интегрировать у себя и предоставлять общий API для всех браузеров и смартфонов. Да и когда придут к новому протоколу — я просто у себя все обновлю, а владельцам сайтов не придется ничего менять.
Что мешает условному Пете, создать там зашифрованный раздел в виде файла?
С другой стороны я соглашусь с тем, что для общей папки владельцем должен быть вледелец этой самой общей папки. Т.е. люди создающие внутри объекты не должны быть их владельцами.
Разве это не логично? Я владелец — что хочу то и делаю. Иначе выходил бы казус — запретил сам себе доступ к файлу и не можешь его никак вернуть. В линукс системах все также, если ты владелец — ты можешь менять разрешения, даже если у тебя нет никакого доступа.
Просто если уж запрещаешь доступ к объекту, логично и владельца изменить, разве нет?
Вообще я вижу решение проблемы в некотором мосту. К примеру такой мост представляет Google на iOS.
Будет неплохо, если GCM будет вообще везде, но главное. чтобы он нормально работал. И опять таки, будет неплохо, если гугл его частично откроет хотя бы, я например хотел вообще на WP писать с использованием GCM, на что мне ответили в Google+ — что гугл меня забанит, если я буду использовать GCM в обход правил гугла.
На телефонах то еще ладно, можно поднять сокет в случае проблем, самому получать пуши от своего сервера. А в случае с браузерами эта возможность была ограничена. Воркер дохнет, закрывая сокет.
Нужен ютуб плеер? Подключил его и все интегрируется тегом, нужна карта? Тоже самое. Причем можно будет обновлять потом эти библиотеки вместе с кодом плееров, карт, аналитики и т.д.
Сам по себе код выглядит чище, чем куча айфреймов и
2.1 мегабайт картинок — они достаточно крупные. Около 90 штук.
137 килобайт скриптов.
6 кб стили.
Все что выше — кэшируется.
Сам сайт 4.6 килобайта.
Где то 35 килобайт перезагрузка с учетом кэша выходит.
При этом весь сайт на AJAX. Как итог пользователь один раз грузит где то 2.4 мега при загрузке личного кабинета. Потом при повторых заходах уже 35 КБ, а при переходах по сайту в районе 1-10 килобайт за страничку.
Так что, я даже не знаю хуже стало или лучше. Если раньше каждый сайт грузил кучу контента повторно без сжатия и т.д. загружая каждый раз снова весь сайт. То сейчас грузится все один раз, а потом все работает достаточно шустро.
Было бы еще неплохо, если бы все библиотеки были разделенные для всех сайтов. К примеру тот же jQuery, браузер будет кэшировать несколько основных версий, и если грузится jQuery на новом сайте — он будет использовать выбранную версию. И так для всех библиотек основных. Как итог 10 мегабайт кэша на стороне клиента позволят экономить на них несколько гигабайт суммарно. Т.к. сотня сайтов загружаемых каждый день с практически одинаковыми библиотеками думаю вполне этими библиотеками за месяц гигабайт могут и набить.
От 100 подписчиков, обновление идет уже раз в 10 минут, что вполне уже в районе мгновенного.
Ну, а если кому то захочется еще быстрее — если более 500 подписчиков, лента будет обновляться раз в минуту. Это ну никак не сравнимо с 3 часами в Feedly.
И это может сделать абсолютно любой сайт бесплатно. Отправлять мгновенные уведомления сразу на устройства без создания каких либо приложений.
Но сейчас внешне пока что приходится наполнять сворее некой вариацией конвертера Pull в Push. Например тот же RSS надо сканировать постоянно, чтобы получать обноления. На телефоне это означает, что заряд будет сжираться больше.
В плане RSS мой сервис адаптирован не на чтение статей и ленты, а на получение фильтрованных данных. К примеру я разрабатывая свой проект интересуюсь обновлениями хрома, андроида, гуглом и пушами. Подписался на нужные мне каналы и настроил фильтр. В случае если какая то важная новость проскочит — я сразу получу пуш.
И еще отличие от RSS — для большенства пользователей RSS это дремучий лес. Т.е. это какая то волшебная ссылка с метаданными. Мало кто понимает что это такое вообще. Мой сервис дает понятный каталог, похожий на привычные каталоги приложений с каналами, где можно посмотреть ленту, прочитать название, описание, увидеть иконку, и посмотреть ленту.
Push-уведомления должны по сути содержать, что то важное. Если ты отфильтруешь RSS-ку по каким то важным данным (например тебе нужно быстро в случае чего узнать, появилась новая технология или решение) то это будет просто мегаполезно.
Как примеру еще решение с сериалами — серий выходит просто мегамного. До того, как я создал сервис единственным решением следить за этим была подписка на группу вконтакте. Но у многих число групп переваливает за пару сотен. В итоге, к примеру, даже лично я пропускал иногда 2-3 сериала, и только через пару дней, когда уже не было времени их смотреть, я узнавал, что они переведены.
А сейчас я получаю пуш, через канал используя фильтр. Там каждый день идет где то около 20-50 пушей о выходе серий от различных студий различных сериалов. Я получаю 2-3 пуша в сутки по сериалам, которые я смотрю. И эти пуши именно полезны. Я увидел — я узнал что вышла серия. Пришел домой — скачал.
Да более продвинутые вообще через RSS настраивают автоскачивание и т.д. у них еще NAS дома и т.д. Но 90% этого не умеют.
Ну и не совсем понимаю, почему на хабре столько разработчиков и т.д. и мало кто понимает, что через эту штуку можно пушить различные алерты о состоянии работы сервисов, сервера и т.д. Эта информация приватна и нужна только вам. Никакой твиттер или rss вам тут не поможет. Ну а почта — чистить потом эти алерты, да и почту тоже надо обновлять. А пуш прилетел — ты его увидел и стер. На почту разве что можно присылать например потом сводку раз в сутки. Для быстрых каких то уведомлений, когда нужно решить это сейчас это мало подходит.
Я сейчас буду делать упор на создание плагинов к различным CMS. Можно будет поставить плагин и пользователи смогут получать уведомления о различных действиях с этого сайта.
А дальше все управление разрешниями ведётся внутри самого PushAll.
Это позволяет к примеру сесть за новый компьютер, разрешить доступ и сразу получать все уведомления от каналов на которые ты подписан со всеми настроенными фильтрами и т.д. то есть можно даже сказать что мой сервис в облаке (в духе современных тенденций)
RSS же тут только как источник.
Вообще официально у него на бесппатном тарифе от 1 до 8 часов может быть.
Для синхронизации ленты это еще неплохо (хотя 3 часа для новости возможно уже критично) Для уведомлений же критично как по мне не более часа. Поэтому даже канал с двумя подписчиками будет сканироваться раз в час.
Если бы я делал Feedly — я бы вообще сделал так, что если кто то заходит в веб-интерфейс или мобильное приложение, то у каналов этого пользователя бы чуть повышался приоритет. Нагрузка от обновления ленты не сильно больше нагрузки от самого пользователя, загружающего страницы сайта. Сжатые ленты многих сайтов весят не более 1 килобайта. Исплользуя кэширование можно существеннно уменьшить любые затраты на проверку.
Или же 3 часа вас вполне устраивают?
Сначала лаги, много занимаемого места и т.д. а потом убери мусор и оптимизируй и тебя все будут любить, хотя оно может быть даже по скорости и весу хуже чем еще более старая версия
Единственное что от них требуется — поддержание работы. Причем они могут сдавать и старое оборудование, которое уже мало окупается, но кто то по дешевке будет брать :) И у них могут быть договора на поставку нового оборудования по более низким ценам и сбыт старого железа по выгодным ценам.