К сожалению, так оно и есть - сейчас считается, что в состоянии вдохновения человек создаст не тот продукт, который принесёт максимальную прибыль, а тот, который наиболее эстетически приятен автору. Существует же расхожая фраза - "если вы сделаете игру своей мечты, значит только вы в неё и будете играть". Это же касается и всего остального: любой бизнес-проект начинается с определения ЦА и способа монетизации, а уж потом под это подгоняется творчество.
Евгений Захаров: Как вариант, можно использовать Workrave - она OpenSource и кроссплатформенная, в репах основных дистрибутивов Linux должна быть. Там настраиваются интервалы перерывов и способы подсчёта активности, способы блокировки экрана и клавиатуры, возможность или невозможность для пользователя отложить перерыв, автовыключение машины по завершении рабочего дня и даже набор физических упражнений, которые пользователю периодически требуется выполнять, чтоб не засиживался.
Методики "не давания" основаны на том, что на вход в поток требуется значительно больше времени, чем на выход из него. И таких методик уже придумано множество.
Например, специально модифицированное парное программирование, когда два человека за одним рабочим местом вынуждены постоянно взаимодействовать друг с другом.
Или установка на рабочую машину таймера, который раз в 10 мин. на 30 сек. гасит экран, что гарантирует выход из потока.
Артем: Речь идёт не о потрошении утащенных хешей, а о переборе аккаунтов прямо на почтовике.
1. Пишется (или настраивается готовый) парсер тематического ресурса, например игрового форума. С его помощью собирается множество почтовых ящиков. Иногда подобные списки ящиков можно приобрести у спамеров и (в случае MMO-ресурсов) у голдселлеров, которые получают их не только парсингом, но и рядом других, более сложных способов.
2. Приобретается или составляется самостоятельно набор прокси
3. Пишется или берётся готовый бот, который пытается войти под каждым из ящиков с некоторым константным паролем. Бот полностью эмулирует запросы, посылаемые браузером при входе пользователя, и юзает прокси, чтобы не получить бан по IP. Поскольку попытки входа осуществляются на разные ящики (одинаков только пароль) и с разных IP, то почтовик обычно не понимает, что его брутят.
Есть ещё брут с константным паролем, когда перебирают логины. То есть цель атаки - не конкретный ящик, а как можно больше рандомных ящиков.
Вы, наверное, змечали, как трудно бывает зарегистрировать ящик на популярном почтовике? Какое сочетание символов ни введи, оно непременно окажется занято. С паролями там происходит примерно то же самое, практически любой "красивый" пароль кем-то используется. Поэтому берётся десяток-другой самых распространённых паролей - и с их помощью начинает перебираться весь набор ящиков. Логины для этих ящиков предварительно добываются путём парсинга некоторых тематических ресурсов (например игровых форумов или соцсетей), т.к. тогда высок шанс, что к ящику окажется привязан соответствующий аккаунт, с которого уже можно в случае получения доступа чего-то поиметь.
Когда собранных ящиков достаточно много, в процессе их перебора хоть к кому-то ваши пароли да подойдут. К кому подошли, тому не повезло...
ngDoc выглядит довольно привлекательно, определённо стоит его попробовать. Спасибо за наводку.
А вот аннотации в AngularJS, как оказалось, удивительно простые. Там не документируется каких-либо сложных абстракций, и даже иерархии классов не задокументированы.
что в jsdoc такого сложного, что нужно ругаться матом
Кажется, JSDoc плохо приспособлен для документирования мало-мальски сложных абстракций.
Например, как там задокументировать такую простейшую вещь, как передачу namespace'а в функцию?
var LSTree;
(function(ns) {
//...
})(LSTree||LSTree={});
Если так сделать, то документирование объектов внутри LSTree становится весьма мучительным (на stackoverflow уже изобрели тонны костылей на такой случай).
Плюс неадекватное поведение, когда он упорно суёт объекты/методы не в тот namespace в случае вложенных namespace'ов, яростно сопротивляется любым попыткам задекларировать instance-методы (@instance приводит к тому, что коммент к методу вообще не создаётся, @name в связке с @memberof вызывают дикие глюки с документацией класса, когда вообще отваливаются все методы).
Плюс тонны исключений на каждом шагу. Например, можно написать /**@type {string[]}*/, но нельзя /**@type {{a:string,b:string}[]}*/, он не понимает таких объектов, приходится костылить: /**@type {Array.<{a:string,b:string}>}*/
В случае многомерных массивов всё совсем уж мрачно, а когда дело доходит до интерфейсов и виртуальных функций, тут-то и начинается мат, особенно когда WebStorm из-за этих комментариев начинает путаться, выдавая warning'и на пустом месте, при том что неаннотированный код парсит правильно.