Кстати, да. Если бы в Яндекс.Сторе у каждого приложения была бы оценка энергопотребления, то я бы всегда начинал поиск приложения оттуда, а не с плеймаркета. А если бы я оказался бы таким не одним, то разработчики стали бы учитывать при разработке своих программ влияние энергопотребления на рейтинги и популярность приложения.
Теперь всё это хорошенько смешать, и получится отличный инструмент для игроделов.
Можно будет сгенерировать сотни персонажей, и отобрать лучших для своей игры.
А если будет удобный инструмент создания правил генерирования, то персонажи разных игр даже не будут похожи друг на друга.
Это мышь. В игре это не важно, главное быстро отличить один образ от другого. И эта странная ухмылка, делающая мышь не похожей на себя, очень хорошо помогает находить мышей на игровом поле.
В целом согласен, но…
Однажды, lastpass меня защитил от фишинга, когда он не стал заполнять поля ввода на подставном сайте.
Если бы я помнил свой 20ти-буквенный пароль, то просто ввёл бы его сам. А так, пришлось разбираться, почему пароль сам не подставляется. Уж больно хорошо был скопирован сайт и подобран домен, что подмены я заметить не смог, а у lastpass'а не было для этого домена паролей.
Менеджер паролей позволяет иметь отдельный пароль для каждого сайта, поэтому компрометация пароля на одном сайте, не угрожает другим сайтам.
Поэтому где-то безопасность повышается, а где-то понижается.
Сегодня я попробую проанализировать, что именно плохого в паролях (короткий ответ — всё), что можно с этим сделать
Так, что же можно сделать?
В статье про это не слова. Написано, что делается и что это не лучше, чем пароль, хотя бы по тому, что сложнее в использовании.
Пароли просты в обслуживании. Задача сервисов — зарабатывать деньги. Если сервис предупредил пользователя о высокой вероятности потери чего бы то не было, в результате использования слабого пароля, хотя бы с использованием красно-жёлтой-зелёной индикации, а пользователь проигнорировал предупреждение, то это уже его проблемы. Заставить поменять пользователей пароли и выплатить компенсации особо упёртым в случае утечки значительно дешевле, чем потерять клиентов из-за сложной системы аутентификации.
Google до конца этого года намерен допилить проект Abacus, идентифицирующий пользователя по поведению
Не знаком с абакусом, но по описанию из этой статьи очевидно, что его предназначение прямо противоположное — обеспечить вход без ввода пароля. Но если пользователь только что приобрёл новое устройство, или заблокировал на какое-то время доступ, то ему нужно плясать с бубном у телефона с риском того, что телефон его не узнает. Зато если телефон разблокирован, то любой получивший к нему доступ, имеет доступ ко всему.
Звучит логично, хотя в статье это сказано по другому
Но в далёком прошлом было время, до того, как все эти объекты сформировались и незадолго до Большого взрыва, когда Вселенная была заполнена светом.
а ещё
И там энергия, присущая самому пространству, преобразовывается в реальные частицы. Из-за того, что плотность энергии пространства была такой высокой во время инфляции и появляется большое количество частиц, античастиц и фотонов, созданных по окончанию инфляции.
Т.е. начинается с утверждения, что свет был до материи. Но в объяснении сказано, что материя (частицы) возникли одновременно со светом.
В терминах энергии, инфляция происходит, когда вы медленно спускаетесь в потенциальную яму, но когда вы уже спустились в долину внизу, инфляция прекращается и преобразовывает эту энергию
Что на самом деле спускалось в потенциальную яму? И почему медленно?
Попробую сформулировать, то что я смог понять.
Сначала была вселенная до большого взрыва.
Потом произошло её разрушение и вселенная начала разлетаться в виде фотонов (инфляция). Материи пока нет.
Фотоны набирают кинетическую энергию, как в колайдере и достигают такой величины, после которой уже не могут лететь через пространство и начинают его «повреждать» выбивая из него материю и антиматерию.
Почему и как энергия фотонов увеличивалась? Что за потенциальная энергия превращалась в кинетическую?
Хорошо. Вот я админ и могу скопировать все данные с сервера из своей серверной. Узнать об этом может только другой админ, но его нет.
Но что мне мешает делать тоже самое в облаке? Как облака повышают безопасность в этом плане? По моему — ни как.
Зато открытые в облачные сервисы становятся доступны для попыток взлома каждому.
К примеру, меня мало беспокоят слабые пароли пользователей в 1с в локальной сети, т.к. на сервере терминалов нет интернета, а на локальных машинах доступа к данным. Но если я вынесу 1с в облака, то мне в помощь придётся нанять толкового безопасника, который будет контролировать сложность паролей, обучать безопасности пользователей, мониторить с утра до вечера логи доступа и т.д. и т.п.
Что касается логов, то в моём распоряжении есть какие угодно инструменты. А вот в облаках всё зависит от провайдера и не факт, что по имеющимся логам можно будет определить факт утечки. Это если мы говорим об облачных услугах, а не выделенных серверах. А если говорить об выделенных серверах, пусть даже облачных (с динамическими характеристиками), то они просто дороже чем стойка у себя.
А ещё есть вопрос доступности, когда тупо нет интернета несколько часов.
И самое главное, чтобы не потерять данные я делаю бэкапы, защищаюсь антивирусами и фаерволами, ставлю систему пожаротушения и подымаю оборудование над полом, чтобы не затопило. Т.е. вероятность, что я не смогу восстановить данные в случае аварии свожу к минимуму.
А вот с облаками может получиться так, что восстановить будет просто не возможно.
Только что вы показали направление движения для мессенджеров. Сначала текст в ответ на текст, потом видео в ответ на текст, потом мессенджеры превратятся в подобие ОС со своей виртуальной машиной, как это уже было с офисными приложениями и браузерами.
Но пока у чатботов есть одно не оспоримое преимущество, они не используют ресурсы мобильных устройств. В отличии от приложений, которые я уже не могу устанавливать, т.к. дисковое пространство исчерпало лимит.
Поэтому расклад сил пока такой: чатботы там, где хватает текстовых ответов и ссылок. Веб для более сложных случаев. И приложения там, где первые два способа не эффективны, например для рисования.
Предложенные колеса явно для людей, и то не для всех, а только испытывающих сложности с парковкой (так сказано в статье).
Роботизированному автомобилю проще управлять четырьмя колёсами с нормальными протекторами, без причинения вреда автомобилю, чем человеку, даже если у каждого колеса будет свой руль и возможность поворачивать каждое колесо на 90 градусов.
Учитывая неэффективность гладких покрышек, дороговизну колёс и не слишком большой период времени, в который люди обучаются парковке, надобность в таких колёсах вряд ли появится.
Мы точно говорим о десктопном приложении? «Куча экранов» — это не совсем то, что хотелось бы в продолжении. Интересует, может ли хабропользователь напрограммировать своё и если может, то как?
Я понимаю, что Вы хотели написать, какой большой дизайнерский труд вы проделали, и как применить MD к десктопным приложениям, но если не будет понятно как это сделать в реальном приложении, то весь рассказ становится не интересным. Пока даже не ясно, какой язык программирования будет использоваться и будет ли это десктопный html (electron, nw.js), чистый натив (.exe, dotNet), или веб-приложение с собственным сервером.
Не понятно, за что DeLuxis получил минусы. Ведь Material Design (MD) это действительно экономия, но не потому что квадрат с тенями проще, а потому что его проще отобразить на любом размере экрана. Поэтому все последние графические стандарты для мобильных устройств стали плоскими. А дизайны с натуральными текстурами исчезают.
Плохо то, что MD — это стандарт для мобильных устройств и совсем не подходит для десктопа. Обратите внимание на огромные пустые пространства между элементами интерфейса. Они просто необходимы для пальцетыкательных экранов, но доставляют массу проблем в энтерпрайзе. Там где информации много, и нужно охватить глазом максимум из возможного.
В первую секунду при взгляде на дизайн кажется, что всё в порядке. А потом...:
Почему в блоке «Контакты» — контакт, а не список контактов?
Почему в карточке контакта, кнопка «Добавить контакт» и могу ли я окинув взглядом список контактов убедиться, что добавляемого контакта ещё нет в списке?
Что это за жёлтый блок, в правом верхнем углу? Почему у него нет названия как у других блоков?
Можно ли свернуть боковую панель?
Строка поиска совсем не там, где ожидается, но хотя бы на виду, а не как у хабра
Какой смысл в не интерактивных уведомлениях? Если уведомление о сообщении, то нужно перейти к отправке ответного сообщения. Если уведомление о событии в системе, то должен быть переход к связанному объекту системы. Например, переход к только что добавленному контакту, если об этом было уведомление.
Мне, не дизайнеру, предложенный дизайн тоже кажется не продуманным. Но, в любом случае, меня интересует техническая реализация, потому что даже при наличии гайдлайнов и подробного описания дизайна в картинках, его редко можно применить к своему проекту, а вот техническую реализацию или некоторые идеи повторить всегда можно. Поэтому жду продолжения.
> В данной заметке мы не будем говорить о теории, поговорим больше о практике
А где практика? Одна теория, которая сводится к "Результат рисования процессов важнее и ценнее процесса рисования процессов".
> А если процесс не является «настольной книгой» людей ...
Вот и рассказали бы как сделать так, чтобы процесс стал «настольной книгой». В большинстве случаев, даже процессы соответствующие всем критериям хорошести, перечисленным в статье, остаются уделом узкого круга лиц. Потому что начальнику цеха не важно, что там нарисовали умники из заводоуправления, которые в цеху почти ни когда не бывали. Он и без процессов разрулит любую ситуацию.
А для ITIL уже все программы написаны, зачем ещё нужны процессы?
[теория заговора]
Как-то слишком вовремя кто-то создал проблемы в работе Teamviewer и стал пугать всех, что угнали пароли.
Как раз в тот момент, когда Microsoft собирается раздать всем владельцам винды свой аналог, причём бесплатно: msoffice-prowork.com/microsoft-rabotaet-nad-analogom-teamviewer-dlya-windows-10
[/теория заговора]
А если серьёзно, то пароли стоит поменять в любом случае.
Насколько я помню, автор fb2 высказался про fb3 следующим образом (не дословно): «fb3 уже придуман и называется он xhtml».
Другими словами, xhtml обладает и строгостью и гибкостью необходимой для электронной книги.
Только нет ни приложений, ни книг в формате xhtml.
Можно будет сгенерировать сотни персонажей, и отобрать лучших для своей игры.
А если будет удобный инструмент создания правил генерирования, то персонажи разных игр даже не будут похожи друг на друга.
Однажды, lastpass меня защитил от фишинга, когда он не стал заполнять поля ввода на подставном сайте.
Если бы я помнил свой 20ти-буквенный пароль, то просто ввёл бы его сам. А так, пришлось разбираться, почему пароль сам не подставляется. Уж больно хорошо был скопирован сайт и подобран домен, что подмены я заметить не смог, а у lastpass'а не было для этого домена паролей.
Менеджер паролей позволяет иметь отдельный пароль для каждого сайта, поэтому компрометация пароля на одном сайте, не угрожает другим сайтам.
Поэтому где-то безопасность повышается, а где-то понижается.
шрифтамичислами о получить совершенно разные настроения:От сидячего образа жизни умирает до 433 тысяч человек в год, а остальные 5 от стоящего! (О ужас!)
или
От сидячего образа жизни умирает до 433 тысяч человек в год, а остальные 5 миллионов от стоящего! (Ну и мелочь)
Вот ещё из этой же категории:
Недавно исследователи открыли факт загрязнения наших водопроводных систем опасным химикатом. Этот химикат бесцветный, безвкусный и не имеет запаха. Он убивает бесчисленное множество людей каждый год. Правительство не предприняло никаких попыток регулирования этого опасного заражения. Данный химикат называется «дигидрогена монооксид»
… а остальные от стоящего!
Так, что же можно сделать?
В статье про это не слова. Написано, что делается и что это не лучше, чем пароль, хотя бы по тому, что сложнее в использовании.
Пароли просты в обслуживании. Задача сервисов — зарабатывать деньги. Если сервис предупредил пользователя о высокой вероятности потери чего бы то не было, в результате использования слабого пароля, хотя бы с использованием красно-жёлтой-зелёной индикации, а пользователь проигнорировал предупреждение, то это уже его проблемы. Заставить поменять пользователей пароли и выплатить компенсации особо упёртым в случае утечки значительно дешевле, чем потерять клиентов из-за сложной системы аутентификации.
Не знаком с абакусом, но по описанию из этой статьи очевидно, что его предназначение прямо противоположное — обеспечить вход без ввода пароля. Но если пользователь только что приобрёл новое устройство, или заблокировал на какое-то время доступ, то ему нужно плясать с бубном у телефона с риском того, что телефон его не узнает. Зато если телефон разблокирован, то любой получивший к нему доступ, имеет доступ ко всему.
Т.е. начинается с утверждения, что свет был до материи. Но в объяснении сказано, что материя (частицы) возникли одновременно со светом.
Что на самом деле спускалось в потенциальную яму? И почему медленно?
Попробую сформулировать, то что я смог понять.
Почему и как энергия фотонов увеличивалась? Что за потенциальная энергия превращалась в кинетическую?
Но что мне мешает делать тоже самое в облаке? Как облака повышают безопасность в этом плане? По моему — ни как.
Зато открытые в облачные сервисы становятся доступны для попыток взлома каждому.
К примеру, меня мало беспокоят слабые пароли пользователей в 1с в локальной сети, т.к. на сервере терминалов нет интернета, а на локальных машинах доступа к данным. Но если я вынесу 1с в облака, то мне в помощь придётся нанять толкового безопасника, который будет контролировать сложность паролей, обучать безопасности пользователей, мониторить с утра до вечера логи доступа и т.д. и т.п.
Что касается логов, то в моём распоряжении есть какие угодно инструменты. А вот в облаках всё зависит от провайдера и не факт, что по имеющимся логам можно будет определить факт утечки. Это если мы говорим об облачных услугах, а не выделенных серверах. А если говорить об выделенных серверах, пусть даже облачных (с динамическими характеристиками), то они просто дороже чем стойка у себя.
А ещё есть вопрос доступности, когда тупо нет интернета несколько часов.
И самое главное, чтобы не потерять данные я делаю бэкапы, защищаюсь антивирусами и фаерволами, ставлю систему пожаротушения и подымаю оборудование над полом, чтобы не затопило. Т.е. вероятность, что я не смогу восстановить данные в случае аварии свожу к минимуму.
А вот с облаками может получиться так, что восстановить будет просто не возможно.
Но пока у чатботов есть одно не оспоримое преимущество, они не используют ресурсы мобильных устройств. В отличии от приложений, которые я уже не могу устанавливать, т.к. дисковое пространство исчерпало лимит.
Поэтому расклад сил пока такой: чатботы там, где хватает текстовых ответов и ссылок. Веб для более сложных случаев. И приложения там, где первые два способа не эффективны, например для рисования.
Роботизированному автомобилю проще управлять четырьмя колёсами с нормальными протекторами, без причинения вреда автомобилю, чем человеку, даже если у каждого колеса будет свой руль и возможность поворачивать каждое колесо на 90 градусов.
Учитывая неэффективность гладких покрышек, дороговизну колёс и не слишком большой период времени, в который люди обучаются парковке, надобность в таких колёсах вряд ли появится.
Я понимаю, что Вы хотели написать, какой большой дизайнерский труд вы проделали, и как применить MD к десктопным приложениям, но если не будет понятно как это сделать в реальном приложении, то весь рассказ становится не интересным. Пока даже не ясно, какой язык программирования будет использоваться и будет ли это десктопный html (electron, nw.js), чистый натив (.exe, dotNet), или веб-приложение с собственным сервером.
Плохо то, что MD — это стандарт для мобильных устройств и совсем не подходит для десктопа. Обратите внимание на огромные пустые пространства между элементами интерфейса. Они просто необходимы для пальцетыкательных экранов, но доставляют массу проблем в энтерпрайзе. Там где информации много, и нужно охватить глазом максимум из возможного.
В первую секунду при взгляде на дизайн кажется, что всё в порядке. А потом...:
Мне, не дизайнеру, предложенный дизайн тоже кажется не продуманным. Но, в любом случае, меня интересует техническая реализация, потому что даже при наличии гайдлайнов и подробного описания дизайна в картинках, его редко можно применить к своему проекту, а вот техническую реализацию или некоторые идеи повторить всегда можно. Поэтому жду продолжения.
А где практика? Одна теория, которая сводится к "Результат рисования процессов важнее и ценнее процесса рисования процессов".
> А если процесс не является «настольной книгой» людей ...
Вот и рассказали бы как сделать так, чтобы процесс стал «настольной книгой». В большинстве случаев, даже процессы соответствующие всем критериям хорошести, перечисленным в статье, остаются уделом узкого круга лиц. Потому что начальнику цеха не важно, что там нарисовали умники из заводоуправления, которые в цеху почти ни когда не бывали. Он и без процессов разрулит любую ситуацию.
А для ITIL уже все программы написаны, зачем ещё нужны процессы?
Как-то слишком вовремя кто-то создал проблемы в работе Teamviewer и стал пугать всех, что угнали пароли.
Как раз в тот момент, когда Microsoft собирается раздать всем владельцам винды свой аналог, причём бесплатно: msoffice-prowork.com/microsoft-rabotaet-nad-analogom-teamviewer-dlya-windows-10
[/теория заговора]
А если серьёзно, то пароли стоит поменять в любом случае.
Другими словами, xhtml обладает и строгостью и гибкостью необходимой для электронной книги.
Только нет ни приложений, ни книг в формате xhtml.