Прочитал ваш комментарий. Извините, но лично мне все написанное показалось просто красивым набором каких-то заумных концепций. Я не вижу практического решения поставленных задач. Кроме того, я не понимаю откуда берутся такие концепции и выводы. Если графики, которые были приведены в статье являются частным примером, то почему вдруг на их основе делаются какие-то выводы. А ссылки на IDC и Гартнер вообще не вызывают у меня ничего кроме раздражения - эти агентства известны своими пустовысосанными из пальца прогнозами и ни к чему не обязывающей аналитикой.
В общем, проще надо быть. И тогда люди к технологии потянутся. Пока же это все мутная вода, в которой кто-то ловит рыбу.
А чего тут непонятного - просто развитие мысли из вашего же поста. Есть данные, а есть информация. Информация - есть подмножество в данных, поскольку не все данные несут смысл. Я написал, что для разных задач в одном и том же массиве информации информацией будут разные блоки. Простой пример: есть email с полями From, To, Body. Для получателя письма актуальными будут поля From и Body, поскольку поле To ему не нужно, он и так знает, что письма адресованы ему. Поэтому эти данные в хранилище ему не нужны, их можно убить или перенести куда-то вглубь. А для службы безопасности компании, например, важны поля From, To в первую очередь. А поле Body во вторую.
Пример немного притянут, просто с ходу более простого не нашел. Но из него должно быть понятно, что я имел в виду. Таким образом все "данные" по вашей терминологии конечно же содержат "информацию" и "хлам". Вот только непонятно как их делить, хранить и обрабатывать.
Про ИИ - опять же чего тут непонятного? Построение экспертных систем пересекается с разработками в области ИИ. А процесс классификации информации - это типичная область приложения для экспертных систем.
Взять и учить рискуют все компании, у кого мало денег и много работы. А таких большинство. Когда берешь студента без опыта работы и горящих глаз - это неизбежно.
Легко можно. Если вам сейчас 22-23, то через 7-8 лет, когда вам стукнет 30, 2000$ будут стоить так же, как сегодняшние 1119$. Инфляция 7%, можете пересчитать если интересно при других значениях. За 7-8 лет опыта на штуку приобрести вполне себе можно даже если будет очень серьезная конкуренция на рынке труда :).
2К это (субъективно) планка для офигенно крутого специалиста который:
1. Не желает ходить по струнке и валять дурака в крупной западной конторе где его труд никому не нужен но бабла срубить можно.
2. Не желает брать на себя ответственность и подниматься уже не по профессиональной лестнице а по организационной.
То есть это фактически предел для хорошего специалиста во всех смыслах. Я понимаю, что можно привести контрпримеры, но их число (таких людей) не превысит 1%. Оценка моя личная, потому субъективная.
Вы сами говорите - если это интранет. Кроме того, данный процесс (раздача и использование) весьма непрост с организационной точки зрения. Технически же - все достаточно просто. А вот в промышленных объемах чтобы это организовать - это уже проблема и для большинства CIO и большинства сисадминов.
п.2 - решения с виртуальными клавиатурами:
- для обеспечения приемлемого уровня защиты требуют установки ActiveX компонентов или java-апплета или еще чего-нибудь в этом роде, поскольку на чистом Javascript+HTML+CSS это все достаточно ненадежно будет работать. Поэтому это либо интранет, либо терминалы.
- в вебе виртуальные клавиатуры непривычны пользователю. Это тоже минус решению, рассчитанному на массу.
п.3 - проблема заключается в "заблокировать пользователя". В интернет это малоосуществимо, сопряжено с риском отсечь нужных пользователей. Корень проблемы - сложность идентификации конкретного пользователя. Про анонимные прокси вы знаете, про стирание и подделыванию куки тоже. Вариант с идентификацией по железу (номер проца и проч) малоосуществим для массового решения (см. комментарий выше по п.2).
п.5 - вы сами все написали, остался только один шаг - понять, что в крупных компаниях идентичные по настройкам рабочие места - обычная практика. Поэтому идентификация IP+браузер на деле работать не будет.
п.6 - не вижу ничего плохого в том, что какая-то несущественная информация хранится в cookies. Нужны конкретные примеры уязвимостей (они есть в любой литературе), это я как иллюстрацию к недостаткам изложения в статье привел. Напишите конкретнее - вопросов не будет.
п.7-8 - я все нормально понял. Рекомендую четко разделять в статьях идеальное и реальное. В теории вы все правильно написали. На практике работать не будет.
п.10 - да я не спорю что мониторинг нужен. Просто это не метод защиты от кражи пароля или его подделки, к аутентификации отношения не имеет. Это некий комплекс мер по минимизации убытков, то есть опять же процесс во времени происходящий ПОСЛЕ авторизации. Собственно я к тому, чтобы вы более четко фокусировали внимание читателя на какой-то мысли и не мешали все в кучу.
Возможно, мои мысли будут полезны когда будете писать что-то еще.
Часто принимаю участие в собеседованиях при приеме на работу. Часто попадаются студенты с 0 знаний (как такое может быть - я не понимаю, это человек вообще ничего не делал до 22 лет что-ли?) и запросами типа "Ну это, я не знаю сколько денег мне нужно, опыта ж нет, ну вы понимаете. Ну штуку в месяц на испытательный срок бы хотелось. Ну а дальше от 1.5". Так вот, по личному опыту из людей, которые идут работать отталкиваясь от таких заявок никогда ничего путного не получалось.
Самые грамотные спецы знают себе цену. Но сначала они достигли чего-то, а уже потом стали говорить о деньгах. Или вообще молчат про деньги. Но никто никогда им меньше чем они стоят не платил - уйдут в момент.
Это я к слову про "всю жизнь за 2 штуки работать не хочется"...
Да, кстати, показательный пример. Искал уборщицу в микро-офис, друзьям. Работы - 2 часа в месяц. Было 10 заявок. Меньше чем за 200$ никто работать не хотел. После конкретного предложения поработать за 150 (75 баксов в час, э?) отсеялись все кандидаты.
Работать никто не хочет, потому и проблема с кадрами, уважаемый WebByte.
Да, стоит добавить, что в одном и том же массиве данных в разных ситуациях информацию (смысл) могут нести совершенно разные куски. И если как эти блоки дробить еще более менее может быть понятно, то как эту куски потом друг от друга отдельно хранить и чего то с ними дальше делать - непонятно совершенно. С этой задачей мозг человека то справляется с трудом, храня всю (!) получаемую за жизнь информацию по максимуму. Так что всякие экспертные системы и прочие автоматизированные ИИ системы ближайшие лет 200 рядом не будут валяться.
>Мы можем сделать важный вывод: разные классы информации имеют разную ценность для бизнеса, и эта ценность меняется с течением времени.
Из приведенного графика и легенды к нему совершенно непонятно почему вдруг классификация информации была проведена именно так. Я не говорю про методику исследования, которая осталась за кадром - лично я не понимаю как вдруг так получились такие странные графики - мне интересно почему вдруг email стал каким-то особым классом информации? Email, маркетинговые, девелоперские данные - это, если развивать мысль статьи есть классы ДАННЫХ. Те же email могут устаревать через несколько минут или часов, а могут иметь ценность несколько лет или даже десятков лет. В зависимости от того, очевидно, какая информация в email заключена. Таким образом, понятно что основной сложностью является формирование стратегии, или нет - даже просто определение принципов сортировки информации. Тут были упомянуты красивые слова - политики, SLO... Но дальше то что? Где хоть один конкретный пример того, как мы будем фильтровать информацию и решать - что хранить, а что - нет?
При таком подходе есть еще проблема взаимозависимости данных, их взаимосвязанности. Нельзя так просто убить пачку писем - нужно понять что за данные они за собой потянут дальше. Поэтому проблема сложнее и шире - как найти способы рассортировать информацию по актуальности в определенный момент времени да плюс к этому обеспечить более менее приемлемые сроки перевода информации из запасников в оперативное поле принятия решений.
Кстати, посыл насчет необходимости ограничивать объемы хранения информации мне кажется немного надуманным. Средства хранения постоянно развиваются, и мне кажется еще долго возможности хранилищ будут опережать объем информации. Поэтому, нужно думать о том, как уменьшить затраты на обработку информации, которая не нужна. И тут, как ни странно, вывод получается неожиданный - от объема информации (или, если хотите, данных) скорость обработки мало зависит при ПРАВИЛЬНО ПРОДУМАННОЙ АРХИТЕКТУРЕ РЕШЕНИЙ. Таким образом, затраты на процессинг будут пропорциональны не объемам данных, а их СЛОЖНОСТИ.
Честно говоря если Вы пишете о своем личном опыте, то наверное имело бы смысл не абстрактно перечислить возможные методы решения, а описать конкретное решение, реализованное вами. Описать решаемую задачу и архитектуру (подходы) более детально. В данном случае Вы перечислили достаточно очевидные вещи, к тому же малосистематизированные (на мой личный взгляд) и без привязки к конкретным ситуациям. Создается впечатление, что целью топика было притянуть за уши количество методов к числу 10.
Чтобы не быть голословным:
- пункт 2 малоприменим и неудобен в большинстве веб приложений, в то же время в банковской сфере достаточно активно внедряется для защиты пинкодов и прочих банкоматных несложных паролей.
- пункт 3 для защиты приложений в вебе сложноосуществим
- пункт 4 не относится к проблеме аутентификации по логину-паролю, сессия есть следующая фаза работы
- пункт 5 не работает для предприятий с одним IP и типовой настройкой рабочего места (читай "большинства корпоративных юзеров")
- пункт 6 не раскрыт, смысл малопонятен
- пункты 7 и 8 на практике создадут больше проблем, чем повысят защиту. Менеджер Катя будет долго материться в момент демонстрации прототипа системы заказчику находясь в Далласе на слете соучредителей. А требования постоянной смены пароля приведут к записям на липких бумажках и критике системы, что в потенциале приведет к переходу на другой продукт.
- пункты 9 и 10 - фантазия, которая на практике может быть реализована, но не может быть внедрена.
Поэтому еще раз просьба - напишите что же конкретно сделали Вы в рамках своего решения. Тема эта достаточно актуальна и важна для обсуждения в среде профессионалов.
Кстати, есть такая книжка как "Аутентификация", автор Р.Смит. Возможно не лучшая. Но тем, кто интересуется темой но еще не копал - рекомендую. Многие вопросы будут сняты.
Программистам не мешает. Они сразу догадываются, что нужно отключить автоматический "перевод" локали и вызывают его строго когда нужно нажатием на Pause.
Одни люди нормально пытаются зарабатывать бабки. Другие пытаются ничего не делая подтянуть массы энтузиастов и суды чтобы закидать камнями первых, поскольку другими способами заработать у них не получается. Все это нытье в пользу бедных проистекающее от бессилия и зависти.
Пусть МС пишет нормальный софт. Нечего отвлекать людей от решения задач всякими дурацкими претензиями.
По-моему, на втором графике (где продажи CD и скачивания MP3 для малоизвестных исполнителей) все наоборот нарисовано - всплеск скачек есть, а CD как не продавались так и не продаются. Либо графики перепутаны местами, либо выводы из графика прямо противоположны его сути.
В общем, проще надо быть. И тогда люди к технологии потянутся. Пока же это все мутная вода, в которой кто-то ловит рыбу.
Пример немного притянут, просто с ходу более простого не нашел. Но из него должно быть понятно, что я имел в виду. Таким образом все "данные" по вашей терминологии конечно же содержат "информацию" и "хлам". Вот только непонятно как их делить, хранить и обрабатывать.
Про ИИ - опять же чего тут непонятного? Построение экспертных систем пересекается с разработками в области ИИ. А процесс классификации информации - это типичная область приложения для экспертных систем.
1. Не желает ходить по струнке и валять дурака в крупной западной конторе где его труд никому не нужен но бабла срубить можно.
2. Не желает брать на себя ответственность и подниматься уже не по профессиональной лестнице а по организационной.
То есть это фактически предел для хорошего специалиста во всех смыслах. Я понимаю, что можно привести контрпримеры, но их число (таких людей) не превысит 1%. Оценка моя личная, потому субъективная.
- для обеспечения приемлемого уровня защиты требуют установки ActiveX компонентов или java-апплета или еще чего-нибудь в этом роде, поскольку на чистом Javascript+HTML+CSS это все достаточно ненадежно будет работать. Поэтому это либо интранет, либо терминалы.
- в вебе виртуальные клавиатуры непривычны пользователю. Это тоже минус решению, рассчитанному на массу.
п.3 - проблема заключается в "заблокировать пользователя". В интернет это малоосуществимо, сопряжено с риском отсечь нужных пользователей. Корень проблемы - сложность идентификации конкретного пользователя. Про анонимные прокси вы знаете, про стирание и подделыванию куки тоже. Вариант с идентификацией по железу (номер проца и проч) малоосуществим для массового решения (см. комментарий выше по п.2).
п.5 - вы сами все написали, остался только один шаг - понять, что в крупных компаниях идентичные по настройкам рабочие места - обычная практика. Поэтому идентификация IP+браузер на деле работать не будет.
п.6 - не вижу ничего плохого в том, что какая-то несущественная информация хранится в cookies. Нужны конкретные примеры уязвимостей (они есть в любой литературе), это я как иллюстрацию к недостаткам изложения в статье привел. Напишите конкретнее - вопросов не будет.
п.7-8 - я все нормально понял. Рекомендую четко разделять в статьях идеальное и реальное. В теории вы все правильно написали. На практике работать не будет.
п.10 - да я не спорю что мониторинг нужен. Просто это не метод защиты от кражи пароля или его подделки, к аутентификации отношения не имеет. Это некий комплекс мер по минимизации убытков, то есть опять же процесс во времени происходящий ПОСЛЕ авторизации. Собственно я к тому, чтобы вы более четко фокусировали внимание читателя на какой-то мысли и не мешали все в кучу.
Возможно, мои мысли будут полезны когда будете писать что-то еще.
Самые грамотные спецы знают себе цену. Но сначала они достигли чего-то, а уже потом стали говорить о деньгах. Или вообще молчат про деньги. Но никто никогда им меньше чем они стоят не платил - уйдут в момент.
Это я к слову про "всю жизнь за 2 штуки работать не хочется"...
Да, кстати, показательный пример. Искал уборщицу в микро-офис, друзьям. Работы - 2 часа в месяц. Было 10 заявок. Меньше чем за 200$ никто работать не хотел. После конкретного предложения поработать за 150 (75 баксов в час, э?) отсеялись все кандидаты.
Работать никто не хочет, потому и проблема с кадрами, уважаемый WebByte.
Из приведенного графика и легенды к нему совершенно непонятно почему вдруг классификация информации была проведена именно так. Я не говорю про методику исследования, которая осталась за кадром - лично я не понимаю как вдруг так получились такие странные графики - мне интересно почему вдруг email стал каким-то особым классом информации? Email, маркетинговые, девелоперские данные - это, если развивать мысль статьи есть классы ДАННЫХ. Те же email могут устаревать через несколько минут или часов, а могут иметь ценность несколько лет или даже десятков лет. В зависимости от того, очевидно, какая информация в email заключена. Таким образом, понятно что основной сложностью является формирование стратегии, или нет - даже просто определение принципов сортировки информации. Тут были упомянуты красивые слова - политики, SLO... Но дальше то что? Где хоть один конкретный пример того, как мы будем фильтровать информацию и решать - что хранить, а что - нет?
При таком подходе есть еще проблема взаимозависимости данных, их взаимосвязанности. Нельзя так просто убить пачку писем - нужно понять что за данные они за собой потянут дальше. Поэтому проблема сложнее и шире - как найти способы рассортировать информацию по актуальности в определенный момент времени да плюс к этому обеспечить более менее приемлемые сроки перевода информации из запасников в оперативное поле принятия решений.
Кстати, посыл насчет необходимости ограничивать объемы хранения информации мне кажется немного надуманным. Средства хранения постоянно развиваются, и мне кажется еще долго возможности хранилищ будут опережать объем информации. Поэтому, нужно думать о том, как уменьшить затраты на обработку информации, которая не нужна. И тут, как ни странно, вывод получается неожиданный - от объема информации (или, если хотите, данных) скорость обработки мало зависит при ПРАВИЛЬНО ПРОДУМАННОЙ АРХИТЕКТУРЕ РЕШЕНИЙ. Таким образом, затраты на процессинг будут пропорциональны не объемам данных, а их СЛОЖНОСТИ.
Чтобы не быть голословным:
- пункт 2 малоприменим и неудобен в большинстве веб приложений, в то же время в банковской сфере достаточно активно внедряется для защиты пинкодов и прочих банкоматных несложных паролей.
- пункт 3 для защиты приложений в вебе сложноосуществим
- пункт 4 не относится к проблеме аутентификации по логину-паролю, сессия есть следующая фаза работы
- пункт 5 не работает для предприятий с одним IP и типовой настройкой рабочего места (читай "большинства корпоративных юзеров")
- пункт 6 не раскрыт, смысл малопонятен
- пункты 7 и 8 на практике создадут больше проблем, чем повысят защиту. Менеджер Катя будет долго материться в момент демонстрации прототипа системы заказчику находясь в Далласе на слете соучредителей. А требования постоянной смены пароля приведут к записям на липких бумажках и критике системы, что в потенциале приведет к переходу на другой продукт.
- пункты 9 и 10 - фантазия, которая на практике может быть реализована, но не может быть внедрена.
Поэтому еще раз просьба - напишите что же конкретно сделали Вы в рамках своего решения. Тема эта достаточно актуальна и важна для обсуждения в среде профессионалов.
Кстати, есть такая книжка как "Аутентификация", автор Р.Смит. Возможно не лучшая. Но тем, кто интересуется темой но еще не копал - рекомендую. Многие вопросы будут сняты.
Пусть МС пишет нормальный софт. Нечего отвлекать людей от решения задач всякими дурацкими претензиями.