Разнылись все как малые дети. Fl, upwork и т.п. делают бизнес их задача максимизировать прибыль. Делают все в рамках закона. Осуждать этическую сторону их действий в эпоху капитализма и империализма, ну такое себе занятие. Не устраивает fl — выбирайте другую платформу, не нравятся биржи — вложите денег в собственный маркетинг (и сравните потом расходы), мир фриланса суров — устройтесь на работу. Ну, вот только не нойте, вы же взрослые дяди и тети :)
А на сколько этот рынок готов к внедрению различного софта? Т.е. с точки зрения поставщиков соответствующего ПО или интеграторов там вообще есть рынок? Или надо подождать пока грубо говоря все начнут понимать, что вводить пароль 12345 на камеру это плохо :)?
По-моему тематика «Без ТЗ — ад, зачем вы так?!» немного вывернута на изнанку.
Компания или фрилансер предоставляет услуги. ТЗ — это лишь часть общего бизнес-процесса. Какая разница как бизнес работает с ТЗ, если в итоге это ведет к удовлетворительным для бизнеса результатам? Т.е. идти ведь надо от целей бизнеса, а не от хотелок бизнес-аналитика.
Другой момент, если отсутствие или плохая работа с ТЗ накладывает дорогие второстепенные проблемы, все эти печальные случаи и истории о которых знает каждый разработчик. Но если без ТЗ вам плохо, то логично, что тогда стоит обратить больше внимания на работу с ТЗ? А на сколько глубоко подойти к вопросу опять же зависит от целей бизнеса и конкретной ситуации.
Вариант «Без ТЗ мы страдаем, но все равно делаем все без ТЗ» — если вы все еще на рынке, то значит не так уж и страдаете :)
Все маячки по сути просто шлют широковещательные пакеты по bluetooth.
Формат пакетов может быть ibeacon, eddystone и др.
У формата eddystone есть режим вещания URL.
Андроид с определенных версий (по-моему с 4.4, но с 5-ой точно) сам ловит eddystone пакеты и реагирует только на те, которые работают в режиме вещания URL, ну и показывают уведомления с этим URL (если конечно включены службы, я брал несколько разных телефонов у знакомых и в целом у всех все было включено).
На ios заявлено, что это работает если установлен Chrome (он собственно как приложение просто ловит пакеты), но я не смог добиться, чтоб это заработало.
Вот ну и т.к. Андроид больше не реагирует сам по себе на другие типы пакетов, то для их обработки надо писать свою логику в виде приложения.
Безусловно при частых пушах маяки будут садиться быстрее, но конкретно этот маяк я не настраивал, у него были дефолтные заводские настройки. Удивил не очень большой срок жизни батареи, т.к. обычно рекламируется срок больше года.
Но стоит признать, что я был не прав в этом конкретном случае (с маяком iBeacom), специально еще раз нашел спецификацию маяка и там действительно указано «до 6 месяцев», так что все честно.
Только https урл (если речь про eddystone маяки и режима URL, для всех остальных вариантов на телефон надо ставить приложение, которое будет нести логику для обработки маяков)
На всё про всё было около 30 секунд, далее маячок опять блокировался. Понять, это фича или бага, мне не удалось. Это нигде не описывалось
У меня был маячок от этого производителя и это не баг, а фича. Действительно нужно вытащить батарею и на 30 секунд устройство переходит в Dev mode. Потом можно включить этот режим, чтоб не возиться с батареей, а после полной настройки устройства, отключить. Это описывается в документации к маячку. Было много неясных моментов с маячком, но момент с батареей был вполне понятен.
Ваши комментарии достаточно несостоятельны и эмоциональны, хотя это вы попросили привести недостатки вашего способа организации файлов. Складывается ощущение, что вы не желаете слушать аргументированные «за» и «против» и слепо верите в свой подход. Что ж, могу пожелать вам только удачи, надеюсь недостатки метода не коснутся вас, проекта, бизнеса. Иногда нужно пройтись и по граблям, чтобы накопить бесценный опыт.
Хранение методов в файлах подходит только для методов-хелперов, которые обычно являются static методами в static классах (если ЯП поддерживает static для классов). Архитектурно разницы нет хранить ли такие методы в файле или в подобном классе.
Плюсы:
1. Некоторая наглядность
Минусы:
1. Сложности с PSR (если речь про пых)
2. Усложняется рефакторинг (недостаточно просто изменить имя метода, надо менять и имя файла)
3. Хранить в комментариях старую версию кода неправославно, для этого есть git и иже с ним
4. Появляется невольное желание создавать методы-гиганты
5. Если не используете namespace, то все методы будут глобальными, что совсем нехорошо.
6. Если используете namespace, то доп. сложности с рефакторингом.
7. Нестандартный подход → дополнительное обучение новых программистов
Если ваш проект небольшой, то вы вряд ли столкнетесь с большой болью от минусов.
Если вы храните в этих методах логику, т.е. это методы, которые должны быть в сервисе или модели, то дополнительно будут и архитектурные минусы (отсутствие состояния, невозможность наследования, невозможность DI, IoC и др.)
Не уверен, там есть исключения (в частности про шифрование credentials, это типа делать можно). Так же если вы используете средства операционной системы, то лицензии вам не нужны. Т. е. если например вы используете openssl или mcrypt библиотеки, который как бы установлены в ОС, то все ок. А вот если вы сами реализуете криптоалгоритмы, тогда попадаете под действие закона
Есть ряд формальных требований для того, чтобы получить лицензии на разработку (например, требования к помещению, сотрудникам в штате с нужным образованием). А лицензия нужна, чтобы разрабатывать ПО с криптографией (есть несколько исключений, когда лицензии не нужны, например, если длины ключей меньше 56 бит).
Вообще, вся ситуация достаточно запутанная, одни эксперты инфобеза говорят, что лицензии нужны всегда, если есть криптография (о чем собственно и написано в законе), другие утверждают, что лицензии необходимо получать, если вы хотите лицензировать свой продукт, т.е. как бы официально доказать, что у вас все в порядке (ну и госы могут использовать только лицензированные продукты).
Более детально в «Положение о лицензировании деятельности по
разработке, производству, распространению шифровальных (криптографических)
средств, ...)» (утв. постановлением Правительства РФ от 16 апреля 2012
г. N 313)
Как разработчики менеджера паролей для компаний могу сказать, что решений на рынке (по менеджменту корпоративных паролей) в целом немало, где-то 10-15 решений. Практически все решения созданы зарубежными компаниями и их стоимость может достигать десяток тысяч долларов, хотя есть и вполне доступные для российского рынка.
Мы общались с несколькими десятками технических директоров, и ни для кого из них проблема хранения паролей не была актуальной (а где-то треть вообще не понимали зачем это надо).
Еще один нюанс характерный для российский компаний — это зона ответственности, т.е. кому сделают атата за забытый пароль от доменного сервера. Пожурят админа или лишат премии, а начальники как лица принимающие решения при этом не страдают.
Плюс разработчикам необходимо иметь лицензии ФСБ на разработку продуктов с криптографией. Вообще, вся тема с лицензированием достаточно запутанная, не говоря уже про внедрение таких решений госам.
Поправьте меня, если я не прав, но по-моему считается, что Коран написан богом и передан людям (в отличии от библии, которая является сборником объединенных историй записанных из уст людей). Поэтому описание характеристик «автора текста» вполне может быть оскорблением чувств верующих.
Но на месте автора статьи, мне кажется, не стоит беспокоиться, ведь в РФ можно оскорбить чувства только православных. Абсурд в абсурде.
Правило, что заказов всегда должно быть больше, чем бизнес может обработать.
Вот это очень интересный момент, хоть и из другой оперы.
Тут такие варианты:
1. В краткосрочной момент времени все заказы не могут быть обработаны, поэтому они попадают в очередь, в план. Клиент этого может даже и не узнать. В этом случае все хорошо. Но и формулировка, что заказов столько, что бизнес не может их обработать неверная. Бизнес может обработать все, со всем справляется, никто не сходит с ума. А опция посылания нахер особенно хорошо себя чувствует :) В моем понимании это и есть состояние стабильности.
2. Бизнес находится в постоянном аврале, ресурсов не хватает, все и всё работает на износ.
К сожалению, такая ситуация намного более распространенная, чем кейс описанный выше. Ну и думаю понятно почему. На мой взгляд это как раз описывается тем, что бизнес не может обработать заказы и это обычно плохо. Бизнес начинает свое путешествие в другое состояние, а вечно в движение он быть не может.
Так получается, что вы признаете, что услуга все же имеет по факту уникальный характер (если хотите не является неуникальной), но просто в силу некоторых обстоятельств некоторые конкретные клиенты видят услугу как неуникальную?
p.s. мне кажется мы уже на гране вопроса «А мы собственно вообще о чем говорим?» :) особенно учитывая поздний час
В РФ есть аналог, тоже on-prem, менеджер паролей Пассворк, входит в реестр, но не опенсорс.
Компания или фрилансер предоставляет услуги. ТЗ — это лишь часть общего бизнес-процесса. Какая разница как бизнес работает с ТЗ, если в итоге это ведет к удовлетворительным для бизнеса результатам? Т.е. идти ведь надо от целей бизнеса, а не от хотелок бизнес-аналитика.
Другой момент, если отсутствие или плохая работа с ТЗ накладывает дорогие второстепенные проблемы, все эти печальные случаи и истории о которых знает каждый разработчик. Но если без ТЗ вам плохо, то логично, что тогда стоит обратить больше внимания на работу с ТЗ? А на сколько глубоко подойти к вопросу опять же зависит от целей бизнеса и конкретной ситуации.
Вариант «Без ТЗ мы страдаем, но все равно делаем все без ТЗ» — если вы все еще на рынке, то значит не так уж и страдаете :)
Формат пакетов может быть ibeacon, eddystone и др.
У формата eddystone есть режим вещания URL.
Андроид с определенных версий (по-моему с 4.4, но с 5-ой точно) сам ловит eddystone пакеты и реагирует только на те, которые работают в режиме вещания URL, ну и показывают уведомления с этим URL (если конечно включены службы, я брал несколько разных телефонов у знакомых и в целом у всех все было включено).
На ios заявлено, что это работает если установлен Chrome (он собственно как приложение просто ловит пакеты), но я не смог добиться, чтоб это заработало.
Вот ну и т.к. Андроид больше не реагирует сам по себе на другие типы пакетов, то для их обработки надо писать свою логику в виде приложения.
Но стоит признать, что я был не прав в этом конкретном случае (с маяком iBeacom), специально еще раз нашел спецификацию маяка и там действительно указано «до 6 месяцев», так что все честно.
У меня был маячок от этого производителя и это не баг, а фича. Действительно нужно вытащить батарею и на 30 секунд устройство переходит в Dev mode. Потом можно включить этот режим, чтоб не возиться с батареей, а после полной настройки устройства, отключить. Это описывается в документации к маячку. Было много неясных моментов с маячком, но момент с батареей был вполне понятен.
Плюсы:
1. Некоторая наглядность
Минусы:
1. Сложности с PSR (если речь про пых)
2. Усложняется рефакторинг (недостаточно просто изменить имя метода, надо менять и имя файла)
3. Хранить в комментариях старую версию кода неправославно, для этого есть git и иже с ним
4. Появляется невольное желание создавать методы-гиганты
5. Если не используете namespace, то все методы будут глобальными, что совсем нехорошо.
6. Если используете namespace, то доп. сложности с рефакторингом.
7. Нестандартный подход → дополнительное обучение новых программистов
Если ваш проект небольшой, то вы вряд ли столкнетесь с большой болью от минусов.
Если вы храните в этих методах логику, т.е. это методы, которые должны быть в сервисе или модели, то дополнительно будут и архитектурные минусы (отсутствие состояния, невозможность наследования, невозможность DI, IoC и др.)
Вообще, вся ситуация достаточно запутанная, одни эксперты инфобеза говорят, что лицензии нужны всегда, если есть криптография (о чем собственно и написано в законе), другие утверждают, что лицензии необходимо получать, если вы хотите лицензировать свой продукт, т.е. как бы официально доказать, что у вас все в порядке (ну и госы могут использовать только лицензированные продукты).
Более детально в «Положение о лицензировании деятельности по
разработке, производству, распространению шифровальных (криптографических)
средств, ...)» (утв. постановлением Правительства РФ от 16 апреля 2012
г. N 313)
Мы общались с несколькими десятками технических директоров, и ни для кого из них проблема хранения паролей не была актуальной (а где-то треть вообще не понимали зачем это надо).
Еще один нюанс характерный для российский компаний — это зона ответственности, т.е. кому сделают атата за забытый пароль от доменного сервера. Пожурят админа или лишат премии, а начальники как лица принимающие решения при этом не страдают.
Плюс разработчикам необходимо иметь лицензии ФСБ на разработку продуктов с криптографией. Вообще, вся тема с лицензированием достаточно запутанная, не говоря уже про внедрение таких решений госам.
Почему?
Но на месте автора статьи, мне кажется, не стоит беспокоиться, ведь в РФ можно оскорбить чувства только православных. Абсурд в абсурде.
Вот это очень интересный момент, хоть и из другой оперы.
Тут такие варианты:
1. В краткосрочной момент времени все заказы не могут быть обработаны, поэтому они попадают в очередь, в план. Клиент этого может даже и не узнать. В этом случае все хорошо. Но и формулировка, что заказов столько, что бизнес не может их обработать неверная. Бизнес может обработать все, со всем справляется, никто не сходит с ума. А опция посылания нахер особенно хорошо себя чувствует :) В моем понимании это и есть состояние стабильности.
2. Бизнес находится в постоянном аврале, ресурсов не хватает, все и всё работает на износ.
К сожалению, такая ситуация намного более распространенная, чем кейс описанный выше. Ну и думаю понятно почему. На мой взгляд это как раз описывается тем, что бизнес не может обработать заказы и это обычно плохо. Бизнес начинает свое путешествие в другое состояние, а вечно в движение он быть не может.
p.s. мне кажется мы уже на гране вопроса «А мы собственно вообще о чем говорим?» :) особенно учитывая поздний час