Я смотрю под углом «решение имеет небезопасный дизайн».
Не важно какого размера отдел, потому, что его деятельность влияет на всю компанию. Как говорится, цепь крепка настолько насколько крепко ее самое слабое звено. Если в одном отделе, для решения одной простой задачи используются открытые порты и авториазция по ip адресу это все равно, что во все компании. Вот такой у меня угол.
Не поймите меня неправильно, но то, что сети у нас построены на tcp\ip протоколе никак не оправдывает использования ip адреса в качестве аутентификации и авторизации. Если я правильно понимаю, на клиенте вы предлагает запускать скрипт слуашющий определенный открытый порт и выполняющий команды.
Также у вас аргументы «нас всего 10» и «делать по-другому сложно».
Все это плохо вписывается в корпоративный аккаунт такой большой компании как Badoo. У вас же полно программистов, если так хочется свой велосипед, с сегодняшними технологиями можно за пару вечеров написать клиент северное решение. Чего-то подобного я ожидал за ходя в эту тему.
PS/ Без обид, у меня просто диссонанс от масштаба компании и решения, если в это реально поверить.
Все мои попытки сделать линукс рабочей системы умирали через пару недель борьбы с tearing. Раздражает до неимоверности.
Нашел такой пост Why is video tearing such a problem in Linux?
Для себя решил, пока этого не будет прямо сразу из коробки, больше пытаться сесть за линукс не буду. Зловещщее «в Windows это все сразу есть, а мне работать нужно» пока побеждает.
ALSO: Если кто-нибудь кого это также раздражало как меня смогли решить проблему, ткните ссылкой, пожалуйста.
Никакие. Самую простую задачу перед собой поставила Nvidia shield — всего то дома по локалке стримить, но даже она не может реализовать комфортную задержку в управлении.
Без революционной технологии задача не решаема.
Взять хотя бы экономию: если человек играет в месяц 15-20 часов через DROVA, то он потратит около 1000 рублей и полностью избавляется от необходимости тратить кучу денег на собственную игровую машину. По нынешним меркам едва ли она обойдется дешевле, чем в 60-80 тысяч рублей без учёта цены монитора и периферии.
Итого ваш сервис актуален для людей играющих до 20 часов в месяц, то есть по часу и то не каждый день. Вы так видите свою ЦА?
Молодое поколение, геймеры, думаю эти люди вполне могут тратить по 2 часа в день на игры. Для них компьютер за 80 тр окупится через 27 месяцев. Еще нужно учесть, что для использования вашего сервиса компьютер все равно нужен.
По моему реально заинтересовать вы можете не молодое поколение геймеров, а наоборот старшее поколение, которые действительно всего пару раз в неделю хотят поиграть со своих условных рабочих ноутбуков без мощного видео.
Само собой. Это я так, чтобы мой комментарий был хотя бы слегка информативным докинул ссылку.
Я не спец в php, но ваша обработка вполне достаточна чтобы понять успешно отправлено сообщение или нет.
if ($line[0] != 'HTTP/1.1 200 OK') die($line[0]);
400 будет в случае если, что-то не так в отправляемом сообщении, 404 если не так с токеном клиента.
Акценты важны.
Но тема очень интересная. Я сам недавно прошел путь отправки пуш сообщений на телефон, но только задача частью написания мобильного приложения и серверного бэкэнда.
Были те же мысли с оттенком паранойи, зачем зависеть от чьего-то сервиса, почему не написать все самому? А еще был вопрос, а из чего собственно выбирать?
Насколько я понимаю практически все мобильные приложения используют FCM. Альтернативой является собственная реализация MQTT, но это задача весьма не тривиальная и требует постоянного бэкграунд процесса, который на андройд потенциально может быть закрыт системой, а на IOS такого понятия как постоянно работающий бэкграунд процесс и вовсе нет.
PS. Наверное, неплохо бы вам еще парсить ответ на отправку сообщения в примере, хотя бы статус.
А вот тут есть описания проверки токена firebase.google.com/docs/auth/admin/verify-id-tokens.
Этот гугло сервис решает ровно две проблемы.
1. Снимает вопрос безопасности, позволяя приложению не иметь открытых портов.
1.1 Большинство мобильных устройств не имеют адресов Internet(белых адресов) и таким образом пуш на них вообще не возможен.
2. Снизить энергопотребление устройств. У сипа пуш весьма условный. Это не сервер что-то шлет на клиент, а клиент с завидным постоянством спрашивает сервер «ну как есть, что для меня?».
Никто не запрещает, бери пиши свой FCM, опрашивай свой сервер каждую секунду. Для этого в андройде есть сервисы. Там есть свои нюнасы, как и в целом во всей мобильной разработке.
Автору тут уже n раз намекнули, что каждой задаче свой инструмент. FCM это исключительно удел разработки под android и кстати ios, тк он и на apple шлет уведомления. И если нет задачи писать свое мобильное приложение, то лучше использовать любой другой более выскоуровневый сервис.
also, забавный нюанс. помимо упомянутых web api, сервис еще и через xmpp может принимать запросы от сервера. У гугла на удивление очень подробная документация с картинками к этому сервису.
Работает из терминала.
Поддерживает почтовые службы.
Совместим с POSIX.
Не требует установки.
Это какая-то бездумная копипаста, в которой вы сделали перевод через гуглтранслейт, причем видимо транзитом через пару мертвых языков, или автор действительно видит смысл в этом?
Еще есть компромиссный вариант, спросить коллегу, что спросить у гугла.
Нередко проблема начинается уже на этапе постановки вопроса.
Неверно заданный гуглу вопрос, может завести сильно в лес.
uPnP — прежде чем включать это где-либо стоит погуглить «uPnP insecure», «uPnP vulnerability». Этот протокол небезопасен by design. Любое устройство, без регистрации и смс может опубликовать себя в интернет.
Jitsi на моем опыте вполне стабилен. Проблемы на которые жаловались пользователи как выяснялось обычно были связаны с микрофонами, качеством инета итп.
Оперативу жрет как не в себя самый существенный недостаток.
Думаю под «корпоративным стандартом» автор имел ввиду, что у него в компании все айтишники договорились использовать один дистрибутив. Это достаточно разумное решение, если в компании есть\планируется разделение труда и делегирование обязанностей.
Вряд ли тут имелось ввиду сравнение Ubuntu с Redhat или Oracle Linux.
Разумность исключения из правил это другой вопрос, который тоже не лишне себе иногда задавать.
Речь не про элитность, а про сложность.
Возможность тестов и приемки ограничена. Слишком много нюансов и вариантов.
Когда вы можете однозначно оценить качество работы численными, формальными параметрами проблем нет.
Грубо говоря если бы у программиста был применим kpi в виде напечатанных символов, разницы с кассиром для которого kpi в виде обслуженные клиентов вполне приемлем, не было бы.
Речь не про элитность, исключительно сложность.
Хороший пример.
Я думаю, что есть профессии в которых можно работать, даже не по призванию.
Это профессии в которых разница между «как-то решить задачу» и «хорошо решить задачу» ничтожно мала.
Вот в ит разница грандиозна, а кассир, если не вдаваться в гиперболы, то лучший от худшего отличается не так уж и сильно.
Не важно какого размера отдел, потому, что его деятельность влияет на всю компанию. Как говорится, цепь крепка настолько насколько крепко ее самое слабое звено. Если в одном отделе, для решения одной простой задачи используются открытые порты и авториазция по ip адресу это все равно, что во все компании. Вот такой у меня угол.
Также у вас аргументы «нас всего 10» и «делать по-другому сложно».
Все это плохо вписывается в корпоративный аккаунт такой большой компании как Badoo. У вас же полно программистов, если так хочется свой велосипед, с сегодняшними технологиями можно за пару вечеров написать клиент северное решение. Чего-то подобного я ожидал за ходя в эту тему.
PS/ Без обид, у меня просто диссонанс от масштаба компании и решения, если в это реально поверить.
ИМХО в 2018 году что-либо делать по ip адресу можно только из ностальгии по 90м.
Нашел такой пост Why is video tearing such a problem in Linux?
Для себя решил, пока этого не будет прямо сразу из коробки, больше пытаться сесть за линукс не буду. Зловещщее «в Windows это все сразу есть, а мне работать нужно» пока побеждает.
ALSO: Если кто-нибудь кого это также раздражало как меня смогли решить проблему, ткните ссылкой, пожалуйста.
Без революционной технологии задача не решаема.
Итого ваш сервис актуален для людей играющих до 20 часов в месяц, то есть по часу и то не каждый день. Вы так видите свою ЦА?
Молодое поколение, геймеры, думаю эти люди вполне могут тратить по 2 часа в день на игры. Для них компьютер за 80 тр окупится через 27 месяцев. Еще нужно учесть, что для использования вашего сервиса компьютер все равно нужен.
По моему реально заинтересовать вы можете не молодое поколение геймеров, а наоборот старшее поколение, которые действительно всего пару раз в неделю хотят поиграть со своих условных рабочих ноутбуков без мощного видео.
Я не спец в php, но ваша обработка вполне достаточна чтобы понять успешно отправлено сообщение или нет.
400 будет в случае если, что-то не так в отправляемом сообщении, 404 если не так с токеном клиента.
Но тема очень интересная. Я сам недавно прошел путь отправки пуш сообщений на телефон, но только задача частью написания мобильного приложения и серверного бэкэнда.
Были те же мысли с оттенком паранойи, зачем зависеть от чьего-то сервиса, почему не написать все самому? А еще был вопрос, а из чего собственно выбирать?
Насколько я понимаю практически все мобильные приложения используют FCM. Альтернативой является собственная реализация MQTT, но это задача весьма не тривиальная и требует постоянного бэкграунд процесса, который на андройд потенциально может быть закрыт системой, а на IOS такого понятия как постоянно работающий бэкграунд процесс и вовсе нет.
PS. Наверное, неплохо бы вам еще парсить ответ на отправку сообщения в примере, хотя бы статус.
А вот тут есть описания проверки токена
firebase.google.com/docs/auth/admin/verify-id-tokens.
1. Снимает вопрос безопасности, позволяя приложению не иметь открытых портов.
1.1 Большинство мобильных устройств не имеют адресов Internet(белых адресов) и таким образом пуш на них вообще не возможен.
2. Снизить энергопотребление устройств. У сипа пуш весьма условный. Это не сервер что-то шлет на клиент, а клиент с завидным постоянством спрашивает сервер «ну как есть, что для меня?».
Никто не запрещает, бери пиши свой FCM, опрашивай свой сервер каждую секунду. Для этого в андройде есть сервисы. Там есть свои нюнасы, как и в целом во всей мобильной разработке.
Автору тут уже n раз намекнули, что каждой задаче свой инструмент. FCM это исключительно удел разработки под android и кстати ios, тк он и на apple шлет уведомления. И если нет задачи писать свое мобильное приложение, то лучше использовать любой другой более выскоуровневый сервис.
also, забавный нюанс. помимо упомянутых web api, сервис еще и через xmpp может принимать запросы от сервера. У гугла на удивление очень подробная документация с картинками к этому сервису.
Это какая-то бездумная копипаста, в которой вы сделали перевод через гуглтранслейт, причем видимо транзитом через пару мертвых языков, или автор действительно видит смысл в этом?
Еще есть компромиссный вариант, спросить коллегу, что спросить у гугла.
Нередко проблема начинается уже на этапе постановки вопроса.
Неверно заданный гуглу вопрос, может завести сильно в лес.
Оперативу жрет как не в себя самый существенный недостаток.
Вряд ли тут имелось ввиду сравнение Ubuntu с Redhat или Oracle Linux.
Разумность исключения из правил это другой вопрос, который тоже не лишне себе иногда задавать.
Возможность тестов и приемки ограничена. Слишком много нюансов и вариантов.
Когда вы можете однозначно оценить качество работы численными, формальными параметрами проблем нет.
Грубо говоря если бы у программиста был применим kpi в виде напечатанных символов, разницы с кассиром для которого kpi в виде обслуженные клиентов вполне приемлем, не было бы.
Речь не про элитность, исключительно сложность.
Я думаю, что есть профессии в которых можно работать, даже не по призванию.
Это профессии в которых разница между «как-то решить задачу» и «хорошо решить задачу» ничтожно мала.
Вот в ит разница грандиозна, а кассир, если не вдаваться в гиперболы, то лучший от худшего отличается не так уж и сильно.
Человеческая мотивация имеет гораздо более сложную механику нежели купюроприемник.