Каким боком геолокация вообще должна влиять на выбор языка? Если я проездом в Калькутте выхожу в интернет через общественный вайфай — у меня по умолчанию на ноуте должны быть индийские иероглифы с невозможностью даже прочесть пункт меню «настройки»? Или все же стоит сначала прочитать настройку браузера, который даже указывая «en» говорит о том, что я как минимум сориентируюсь в английском сайте/приложении, раз уж интерфейс у меня на нем?
То есть только наличие «времени действия»? Или попыток ввода? Что то это мне напоминает… ах да! Политику паролей. Вот так сюрприз, то есть по сути пароль от кода отличается политикой действия, которую просто можно усложнить. На самом деле пользоваться сервисом который каждый раз для входа будет присылать тебе В СТОРОННИЙ СЕРВИС твой «код», кроме того что сверхнеудобно, так еще и не так уж и безопасно.
Сунуть его на подпись человеку, который не понимает ничего в нём и прикрыть тем самым себе разные места?
Вы удивитесь — суть технического задания не в том чтобы описать себе процессы разработки, а в том чтобы согласовать «задумку» условного заказчика с реально работающим кодом. И ТЗ — это не только про «реализовать контроллеры a, b, и c, используя протоколы x, y, z», но и «В верхней части сайта расположено меню, содержащее следующие пункты:…, в дизайне представленном в приложении (6). При клике на пункт… ». То есть вполне себе сценарий использования, который доступен обывателю.
Теперь вам известно три вещи о вашем сотруднике:
Он знает ваш пароль.
Он хранит ваш пароль в чистом виде, не используя никакого шифрования.
Надо добавить что еще вам следует проверить себя на наличие параноидального синдрома.
Пароль обычно рандомно генерируется системой и ей же автоматически отправляется, и следовательно «сотрудник» про ваш пароль ни сном ни духом. И естественно пароль не хранится в открытом виде, после отсылки в базе останется только хеш пароля. В остальном — отправлять разовый ключ доступа или сгенерированный системой пароль почти одно и то же, разница в том что поведением разового ключа мы можем управлять (например не пускать второй раз, что впрочем можно реализовать и с временным паролем).
PS: В итоге в статье не только не рассказано как (точнее рассказано как не надо) хранить, но и тема где совершенно не раскрыта. Ожидал откровения и хитромудрых подходов, получил тухлый помидор, которым только и можно что пульнуть в автора сего опуса.
В таком случае, скорее всего вы должны написать ТЗ, или ваше непосредственное начальство, буде оно обладает необходимым техническим бэкграундом. Иначе рискуете получить продукт, резко отличающийся от того что хотело начальство и долгие разговоры на тему «Я же ясно объяснил, что сайт должен быть как у ХХХ, а он не как у ХХХ, мне пофиг что они за это время 3 раза сменили стиль и функционал!». В случае конторы условного дяди Коли с 1 «программистом», клепающим сайты на вордпресс, я думаю вопрос ТЗ стоит не настолько остро.
почитайте шикарную книжку про рынки, валюты, акции, откуда есть пошла экономика… Называется Хулиномика(Хулиганская Экономика). Очень четко описано простым языком.
Другими словами, если ничерта не понятно, то описать что именно ничерта не понятно так, чтобы другие люди поняли что именно не понятно — это полезно.
как куратор тега на тостере — готов подписаться под каждым словом, но не все обладают столь полезным скилом, из большинства приходится клещами тянуть что и как «не работает» (
это я в курсе, но неопределенный элемент при вызове в данном коде просто выдаст варнинг, не думаю что это хороший вариант использования. Либо он должен быть задан при добавлении первого элемента в $this->stations, либо иметь явный сеттер. То же относится к
как это относится к гитхабу? Версионирование кода и хранение бэкапа в гит — более чем удобно, никто не отнимает у вас возможности хранить локальный репозиторий же…
Аналитики DRAMeXchange уверены, что до конца 2019 года можно не ждать улучшения ситуации.
Хм, с моей стороны — глобально ситуация вроде как улучшается, так как покупателей гораздо больше чем производителей, и в целом счастливых людей станет больше…
Пароль обычно рандомно генерируется системой и ей же автоматически отправляется, и следовательно «сотрудник» про ваш пароль ни сном ни духом. И естественно пароль не хранится в открытом виде, после отсылки в базе останется только хеш пароля. В остальном — отправлять разовый ключ доступа или сгенерированный системой пароль почти одно и то же, разница в том что поведением разового ключа мы можем управлять (например не пускать второй раз, что впрочем можно реализовать и с временным паролем).
PS: В итоге в статье не только не рассказано как (точнее рассказано как не надо) хранить, но и тема где совершенно не раскрыта. Ожидал откровения и хитромудрых подходов, получил тухлый помидор, которым только и можно что пульнуть в автора сего опуса.
Язык любимый — PHP.
Двулик, как гордый аксакал,
И это то что я искал!
В Друпале код из процедур
Понятен даже и для дур!
Я в ожиданьи 8 с jit,
Он будет мегасуперхит,
Но это не точно…
Извините, вырвалось )
как куратор тега на тостере — готов подписаться под каждым словом, но не все обладают столь полезным скилом, из большинства приходится клещами тянуть что и как «не работает» (
но тут она просто NULL, что не так страшно.
не совсем понял, я туплю или чего-то не знаю о итераторах…
угу, а при неправильной настройке заглавная "" мигрировала в малую h )