Забыл совсем. Что при первой публикации, что спустя 5 приложений (первой 3 года назад публиковал) всегда все проходило идентично. Никаких бонусов от того, что эти приложения в сторе не ощущаются при очередном рассмотрении. Всегда 4-7 дней занимала публикация… пока...
Мне кажется, что на vpn они смотрят иначе…
По своему опыту следующие моменты могу отметить по AppStore:
1) reject'ы были по след. причинам: замена системных звуков на свои — недостаточно оснований, фоновые процессы — вечная проблема с указанием типа (с геолокацией — у вас не по этой теме приложение, с музыкой — у вас не плеер и не для фитнеса), новая версия приложения — недостаточно изменений, чтобы пользователь это мог ощутить (им до фонаря, что клиент напутал с цветом фона иконки приложения и это надо поправить), права на использование товарного знака — если заказчик является крупной компанией и публикация производится не под аккаунтом компании, то потребуется предоставить юр. документы на право использования знака.
2) проблем с авторизацией на входе не испытывал, давал тестовый аккаунт и всегда это устраивало
3) на днях вот публикация с оплатой банковской картой физического товара через робокассу… Вот посмотрим как пройдет все )
4) из того с чем постоянные траблы… несущественные, но раздражает: при удалении, создании, перевыпуске сертификатов из цепочки, что требуются для подписывания приложения, постоянно возникают какие-то несоответствия одного с другим. Всегда решается одним приемом подождать пару часов. Один раз пришлось ждать сутки и ещё один раз почти неделю. При этом писал, жаловался во все инстанции, но ответили только после того как само починилось. ))
Я вот все прицеливаюсь в своих продуктах на конференции для корпоративной связи. Понимаю, что достаточно сервисов, но так сложилось, что почти всегда идёт интеграция с локальной софтварной АТС. То бишь с аудиочастью проблем нет, но вот видео иногда требуется. Так вот из того что понравилось больше всего для этой цели — это FreeSwitch Verto. Можно долго рассказывать, но рекомендую всем. Очень не дурно реализовано.
Поверьте, вот все по мануалу из: www.npmjs.com/package/ws
Там банальный небольшой скрипт процедурный. Никакого специализированного фреймворка. Все время/трудозатраты в основном на тесты и отладку ушли. Те же event`ы различных диалпланов Астериска парсить. А лимиты такие сугубо из показателей мониторинга. Как только PM2 начнет ребутить, то будет повод посмотреть логи, подумать о том, что надо ресурсы увеличить, или увидеть очередной объект, который надо за`delete`ить.
socket.io — смотрел, пробовал. Это было чуть раньше, когда он был незаменим в связи со слабой поддержкой сокетов браузерами. Сейчас все и так хорошо.
Сам большой поклонник PHP, но сдался в связи в удобством реализации на Node.
Могу сказать только что socket.io многократно больше потребляет траффика… или я «котов не умею готовить» :)
Приветствую всех!
Ws действительно интересная тема. Недавно была задача для crm-bpm системы сделать event-сервер. Я остановился на node.js. У меня, служба работающая под pm2, является клиентом ws для asterisk. Ловит и обрабатывает все события АТС и раздает авторизованным пользователям системы, подключенным по wss, уведомления о входящих звонках, проверяя соответствия номера клиента с наличием в базе данных. Также от пользователей приходят комманды на уведомления других пользователей при постановке задачи, состояние он-лайн, офф-лайг, а также работа по API с сайтами при поступлении POST запросов. То есть, одновременно это клиент и сервер.
Пользователей он-лайн около 200, события от АТС идут постоянно (один только звонок порождает около 6000 тыс. строк), их около 400 в день. С сайтов приходят запросы, но немного, один-два в час.
Так к чему я это все рассказывал. Честно говоря не могу понять как протестировать нагрузку, чтобы можно было смело говорить о каких-то конкретных цифрах.
Я конечно понимаю, что видимо знаний мало, но тут и запросы к базе и активность клиентов системы очень варьируется, и данные по API разный объем имеют. Плюс-минус километр если, то на 200 пользователей при 400 звонках в день и 300 задачах в системе + 40 отправленных сообщений по API в сутки, пиковая нагрузка по RAM была 81mb. По процессору не более 10%. Можно смело об этом говорить, что эти показатели не превышались никогда, так как PM2 в этом случае перезапускал бы службу (ну должен это делать во всяком случае) и фиксировал это событие.
Интересно было бы узнать о каких-то системах расчета нагрузки, потому как мои средние наблюдения и "простые чаты" это как-то из разряда средней температуры по больнице…
За статью спасибо! Я, к сожалению до Go не дошел в этом вопросе, а PHP отмел по причине неудобной, ИМХО реализации по работе с сокета и.
Я думаю, что у многих людей, кто в программировании длительное время, значимое по отношению к прожитой жизни, эта статья вызвала отклик. Я помню, как программируя под z80, я упивался тем, что вот он мой маленький мирок, изученный почти полностью и я тут могу все. Сейчас же знаний столько, что их не объять ни измерить толком и эту данность необходимо принять. Все знать невозможно — раньше говорили начитанные люди, а сейчас это можно сделать слоганом на главной странице GitHub. )
Автору, от сердца.
Был на Вашем месте, главная опасность такой степени увлечённости (в моем случае необходимо было ещё обеспечивать супругу и двоих детей) — это не выгореть эмоционально (иногда освоение профессии боем даётся нервными срывами если быть обязательным человеком), никогда не сдаваться, беречь себя (психологические риски "выгорания" очень серьезны. Тогда Вас ждёт неизбежный успех. Эти качества, эмоции, о которых Вы пишите, все это было свойственно олдскул разработчикам, да простит меня хабр и коллеги за это слово )
Добрый день!
Очень хорошо работает в таких решениях как Node, но по-прежнему страшновато использовать в браузерах. Раньше я боялся IE,… теперь Safari, который вроде все поддерживает, но как-то со своими нюансами. )
Больная тема для многих, кто занимается разработкой интерфейсов.
Причем это все можно стандартизировать.
Или может быть уже есть таковые стандарты?
Сколько раз сталкивался с проблемами padding и margin, особенно когда несколько человек делают front-end. Впору брошюру делать )
Хочется поддержать автора… Действительно, все решения уместны, но в разных ситуациях. Если говорить о фреймворках, да тем паче таких как laravel, то они не для ресуроемких приложений. Последним был пример — проект федерального масштаба (не буду называть). Делали его ребята по всем канонам текущих тенденций. По итогу это привело к тому, что быстродействие приложения стало… просто никаким, объем правильного кода стал непомерным, как и издержки на его обслуживания. (грубо говоря вместо 1 разработчика 5 надо). И я лично видел много раз такие примеры. Люди видимо думают, что сейчас возьмут composer, и соединив вместе половину интернета :) обретут счастье. Выходит немного не так, точнее это приводит тому, что работает все критически медленно, а себестоимость обслуживания проекта серьёзно увеличивается. И вот тут могу сказать, что прилично сделанное самописное решение с вменяемой логикой, которая эффективно подходит для конкретной задачи — в 100 раз лучше. Как по мне, то пусть все будет, мир прекрасен своим многообразием. Адепты типовых фреймворков почему-то очень навязчивы. Надо с уважением относится к тем, кто пишет свой код. Всем удач!
Забыл совсем. Что при первой публикации, что спустя 5 приложений (первой 3 года назад публиковал) всегда все проходило идентично. Никаких бонусов от того, что эти приложения в сторе не ощущаются при очередном рассмотрении. Всегда 4-7 дней занимала публикация… пока...
Мне кажется, что на vpn они смотрят иначе…
По своему опыту следующие моменты могу отметить по AppStore:
1) reject'ы были по след. причинам: замена системных звуков на свои — недостаточно оснований, фоновые процессы — вечная проблема с указанием типа (с геолокацией — у вас не по этой теме приложение, с музыкой — у вас не плеер и не для фитнеса), новая версия приложения — недостаточно изменений, чтобы пользователь это мог ощутить (им до фонаря, что клиент напутал с цветом фона иконки приложения и это надо поправить), права на использование товарного знака — если заказчик является крупной компанией и публикация производится не под аккаунтом компании, то потребуется предоставить юр. документы на право использования знака.
2) проблем с авторизацией на входе не испытывал, давал тестовый аккаунт и всегда это устраивало
3) на днях вот публикация с оплатой банковской картой физического товара через робокассу… Вот посмотрим как пройдет все )
4) из того с чем постоянные траблы… несущественные, но раздражает: при удалении, создании, перевыпуске сертификатов из цепочки, что требуются для подписывания приложения, постоянно возникают какие-то несоответствия одного с другим. Всегда решается одним приемом подождать пару часов. Один раз пришлось ждать сутки и ещё один раз почти неделю. При этом писал, жаловался во все инстанции, но ответили только после того как само починилось. ))
Книга — это всегда здорово. Куплю и почитаю. 15 лет уже не читал на бумаге ничего кроме тех. литературы. Но вот это стоит! Потом повешу в рамку. )
Я вот все прицеливаюсь в своих продуктах на конференции для корпоративной связи. Понимаю, что достаточно сервисов, но так сложилось, что почти всегда идёт интеграция с локальной софтварной АТС. То бишь с аудиочастью проблем нет, но вот видео иногда требуется. Так вот из того что понравилось больше всего для этой цели — это FreeSwitch Verto. Можно долго рассказывать, но рекомендую всем. Очень не дурно реализовано.
:)
www.npmjs.com/package/ws
Там банальный небольшой скрипт процедурный. Никакого специализированного фреймворка. Все время/трудозатраты в основном на тесты и отладку ушли. Те же event`ы различных диалпланов Астериска парсить. А лимиты такие сугубо из показателей мониторинга. Как только PM2 начнет ребутить, то будет повод посмотреть логи, подумать о том, что надо ресурсы увеличить, или увидеть очередной объект, который надо за`delete`ить.
Сам большой поклонник PHP, но сдался в связи в удобством реализации на Node.
Могу сказать только что socket.io многократно больше потребляет траффика… или я «котов не умею готовить» :)
Приветствую всех!
Ws действительно интересная тема. Недавно была задача для crm-bpm системы сделать event-сервер. Я остановился на node.js. У меня, служба работающая под pm2, является клиентом ws для asterisk. Ловит и обрабатывает все события АТС и раздает авторизованным пользователям системы, подключенным по wss, уведомления о входящих звонках, проверяя соответствия номера клиента с наличием в базе данных. Также от пользователей приходят комманды на уведомления других пользователей при постановке задачи, состояние он-лайн, офф-лайг, а также работа по API с сайтами при поступлении POST запросов. То есть, одновременно это клиент и сервер.
Пользователей он-лайн около 200, события от АТС идут постоянно (один только звонок порождает около 6000 тыс. строк), их около 400 в день. С сайтов приходят запросы, но немного, один-два в час.
Так к чему я это все рассказывал. Честно говоря не могу понять как протестировать нагрузку, чтобы можно было смело говорить о каких-то конкретных цифрах.
Я конечно понимаю, что видимо знаний мало, но тут и запросы к базе и активность клиентов системы очень варьируется, и данные по API разный объем имеют. Плюс-минус километр если, то на 200 пользователей при 400 звонках в день и 300 задачах в системе + 40 отправленных сообщений по API в сутки, пиковая нагрузка по RAM была 81mb. По процессору не более 10%. Можно смело об этом говорить, что эти показатели не превышались никогда, так как PM2 в этом случае перезапускал бы службу (ну должен это делать во всяком случае) и фиксировал это событие.
Интересно было бы узнать о каких-то системах расчета нагрузки, потому как мои средние наблюдения и "простые чаты" это как-то из разряда средней температуры по больнице…
За статью спасибо! Я, к сожалению до Go не дошел в этом вопросе, а PHP отмел по причине неудобной, ИМХО реализации по работе с сокета и.
Я думаю, что у многих людей, кто в программировании длительное время, значимое по отношению к прожитой жизни, эта статья вызвала отклик. Я помню, как программируя под z80, я упивался тем, что вот он мой маленький мирок, изученный почти полностью и я тут могу все. Сейчас же знаний столько, что их не объять ни измерить толком и эту данность необходимо принять. Все знать невозможно — раньше говорили начитанные люди, а сейчас это можно сделать слоганом на главной странице GitHub. )
Автору, от сердца.
Был на Вашем месте, главная опасность такой степени увлечённости (в моем случае необходимо было ещё обеспечивать супругу и двоих детей) — это не выгореть эмоционально (иногда освоение профессии боем даётся нервными срывами если быть обязательным человеком), никогда не сдаваться, беречь себя (психологические риски "выгорания" очень серьезны. Тогда Вас ждёт неизбежный успех. Эти качества, эмоции, о которых Вы пишите, все это было свойственно олдскул разработчикам, да простит меня хабр и коллеги за это слово )
Очень хорошо работает в таких решениях как Node, но по-прежнему страшновато использовать в браузерах. Раньше я боялся IE,… теперь Safari, который вроде все поддерживает, но как-то со своими нюансами. )
Причем это все можно стандартизировать.
Или может быть уже есть таковые стандарты?
Сколько раз сталкивался с проблемами padding и margin, особенно когда несколько человек делают front-end. Впору брошюру делать )
Есть вполне понятный debug json, когда он возвращает ошибку. Она имеет документацию http://php.net/manual/ru/function.json-last-error.php
Хочется поддержать автора… Действительно, все решения уместны, но в разных ситуациях. Если говорить о фреймворках, да тем паче таких как laravel, то они не для ресуроемких приложений. Последним был пример — проект федерального масштаба (не буду называть). Делали его ребята по всем канонам текущих тенденций. По итогу это привело к тому, что быстродействие приложения стало… просто никаким, объем правильного кода стал непомерным, как и издержки на его обслуживания. (грубо говоря вместо 1 разработчика 5 надо). И я лично видел много раз такие примеры. Люди видимо думают, что сейчас возьмут composer, и соединив вместе половину интернета :) обретут счастье. Выходит немного не так, точнее это приводит тому, что работает все критически медленно, а себестоимость обслуживания проекта серьёзно увеличивается. И вот тут могу сказать, что прилично сделанное самописное решение с вменяемой логикой, которая эффективно подходит для конкретной задачи — в 100 раз лучше. Как по мне, то пусть все будет, мир прекрасен своим многообразием. Адепты типовых фреймворков почему-то очень навязчивы. Надо с уважением относится к тем, кто пишет свой код. Всем удач!