Хочу обратить внимание на аналог MacBook Pro для любителей Linux: https://puri.sm/librem-15/
Хороший металлический корпус, экран (3840x2160), хороший процессор (i7-5557U), хороший вес (2.0kg), великолепный объем ОЗУ (32GB, господи, наконец-то в нормальных ноутбуках). И заметьте, цена всего этого — аналогична цене на макбук, так что про задранность цен Apple — сильное преувеличение.
Но вполне подходит под «умышленное распространение информации, позволяющей осуществлять выпуск „денежных суррогатов“ и /или/ операции с их использованием.».
Автора, как не гражданина России врядли это должно заботить, но боюсь хабр, в связи с последними веяниями, статусом электронного СМИ и «организатора распространения информации» не самое подходящее место для таких постов.
Весьма полный обзор, хотя врядли я когда-нибудь пересяду со столь привычного gmail. Трудолюбивость автора в замазывании своей почты на скриншотах сразу была воспринята, как вызов :) Уважаемый волейболист, вы все-таки кое-что кое-где пропустили.
В феврале встретил в твиттере упоминание про hashchallenge, где было соревнование по поиску минимального sha512 хэша, написал простенький брутфорсер на си и внезапно выиграл. В качестве приза был как раз этот браслет, но оказалось, что призы вручаются только очным участникам хакатона PennApps, жалко было, давно хочу подобный девайс. Выглядит приятно и совмещает в себе весь самый нужный функционал.
на канале #habrahabr в RusNet 46 человек сейчас. И уже более трёх лет мы там сидим. Не обольщайтесь количеству пользователей :) они приходят после упоминания в постах, а потом уходят или замолкают.
Отлично обраруживает:
Вообще, статический анализ там на высоте, крайне редко бывают ложные срабатывания, да и то, они часто связаны с неявными предоложениями о коде, которые знает программист (что иначе не будет), но которые не может знать анализатор.
Хотя сам уже увидел недостаток — в данной схеме у издательства нет мотивации тратить деньги на дополнительную рекламу книги, так как все излишки прибыли получит автор. Но может возможно найти какой-то компромисный вариант вроде предложенного выше, но с разделением излишек прибыли между автором и издательством.
Всё отлично расписано, спасибо за статью. Мои размышления могут показаться несколько наивными, но почему бы не сделать модель финансирования более прозрачной? Вы сам описываете, что расходы издательства состоят из двух частей — непосредственно работа над книгой и её публикация и страховая часть на случай возможных рисков. Кажется логичным, если издатель будет брать с доходов книги фиксированную сумму, состоящую из двух частей — затраты на публикацию, которую они предоставляют автору в виде подробной сметы на услуги корректоров, типографии и т.д., и страховку, сумма которой высчитывается по модели страховых фирм — из оценки рисков, насколько книга хороша, насколько рынок готов её принять. Автор же получает фиксированный гонорар, обеспеченный страховой частью, плюс все доходы от книги, которые превысили затраты на публикацию и страховую часть.
Если книга не продаётся — значит издатель неверно оценил риски, и как страховая фирма, несёт потери на издательство и фиксированный гонорар автора. Если продаётся — компенсирует затраты на издательство, и страховая часть прибыли идёт на компенсацию других, менее успешных проектов и в чистую прибыль.
Сумма страховки может колебаться в зависимости от желаемого автором фиксированного гонорара — он может вообще от него отказаться, снизив сумму страховки, и получить деньги только в случае, если книга окупится достаточно, чтобы покрыть затраты на издательство и сумму страховки.
У автора будет больше мотивации писать хорошую книгу — если она превзойдёт ожидания издателя, он получит сверхприбыль за все превышенные продажи. А у издателя будет более качественная оценка собственных рисков.
1. А никак не гарантируется, если объект никто не держал и его собрал GC — значит ему не нужно получать ивенты, и он при первом же ивенте убирается из listener'ов.
2. Аннотации обрабатываются GlobalEventManager'ом в метода registerListeners и unregisterListeners.
Использовал подобный подход на android — он там имеет дополнительные плюсы, так с UI можно работать только из основного потока, и реализован функциона передачи ивентов между UI-потоком и тред-пулом. Используется Roboguice для dependency injection.
Реализация: GlobalEventManager https://gist.github.com/naphaso/c9dbb8a4d4035d1f0584
умеет регистрировать/разрегистрировать обработчики сообщений с определённым типом TP — обрабатывать в тредпуле, UI — обабатывать в UI-потоке, IN — обрабатывать синхронно в потоке, пославшем сообщения (значительно быстрее, если обработчик сообщения отрабатывает очень быстро и не взаимодействует с UI).
Отнаследованы и подкручены тред-пулы, чтобы назначали красивые имена тредам, которые обрабатывают сообщения, чтобы было видно в логах, к обработке какого сообщения отновится каждая запись там. EventTask https://gist.github.com/naphaso/69de1a51ad383035dd04
Собственно, он и назначает красивые имена тредам. EventListener https://gist.github.com/naphaso/cc6d7b5da4de4c301f8d
Хранит WeakReference не объект и метод для обработки сообщения. WeakReference — чтобы, в случае, если объект забыл или физически не может (не знает, когда) отписться от приёма сообщений, это не приводило к трагическим последствиям в виде удерживания этого объекта в памяти.
Используется примерно так:
В любом объекте при его старте подписываемся на сообщения:
globalEventListener.registerListeners(this);
Когда уже не нужно принимать сообщения, отписываемся:
globalEventManager.unregisterListeners(this);
Как уже сказал, отписываться не обязательно, но желательно.
Обрабатываем сообщения в методах, аннотиованных следующим образом:
@Event(ThreadType.UI)
public void onSomeEvent(SomeEvent event) {
// some UI work
}
Ну, и полный пример:
@Singleton
public class SomeBackground {
@Inject
private GlobalEventManager globalEventManager;
@Inject
public void init() {
globalEventManager.registerListeners(this);
}
@Event(ThreadType.TP)
public void onStartBackgroundWork(BackgroundTaskEvent event) {
// some work
globalEventManager.fire(new PublishResultsEvent(results));
}
}
public class SomeActivity extends RoboActivity {
@Inject
private GlobalEventManager globalEventManager;
@Override
public void onCreate(Context context) {
super.onCreate(context);
globalEventManager.registerListeners(this);
}
@Override
public void onDestroy() {
super.onDestroy();
globalEventManager.unregisterListeners(this);
}
public void onButtonClickListener() {
globalEventManager.fire(new BackgroundTaskEvent(...));
}
@Event(ThreadType.UI)
public void onShowResults(PublishResultsEvent event) {
// show results in GUI
}
}
За ошибки не ручаюсь, писал код прямо в комментарии. Потом, правда, этот подход пришлось немного переработать, но было весьма удобно.
К слову, DES так и остаётся одним из самых неуязвимых шифров, на него до сих пор практически ничего не нашли, все известные атаки на него либо незначительно снижают его сложность, либо требуют космических объёмов данных. Единственная его проблема — 56 бит ключа, по сегодняшним мощностям компьютеров, это очень мало, легко перебрать хоть все 2^56 возможных ключей.
> Стандартные средства инкапсуляции IPv6 в IPv4 требуют, чтобы как сервер, так и клиент имели публичный IP-адрес. Однако, в настоящее время многие устройства присоединены к Интернету IPv4 через одно или несколько устройств NAT, как правило из-за нехватки IPv4 адресов. В такой ситуации единственный доступный IPv4 адрес принадлежит устройству NAT. Протокол Teredo даёт возможность доступа к IPv6 сетям при такой конфигурации сети.
Читайте не наискосок. Если сократить фразу, получится «Стандартные средства инкапсуляции требуют, а Teredo — не требует.»
А, собственно, чем не устраивает teredo? Запускается в один клик, работает. У большинства и так уже есть IPv6, потому что uTorrent незаметно для пользователей поднимает IPv6 teredo-интерфейс.
Реализовывал подобную систему на java, основываясь на crawler4j — правда пришлось его полностью переписать, слишком он был ограничен на тему сложной логики поведения, для выборки контента использовал boilerpipe, данные хранил в hsqldb+hibernate для полнотекстового поиска использовал lucene, модули для анализа контента и сайт-специфичной логики писались на DSL, основанном на groovy. Кластеризация инстансов на базе hazelcast. В случае необходимости разбора страницы с выполнением js-кода, это производитлось headless-браузером, управляемым через Geb. Вообще для такой задачи мне java кажется куда более привлекательной, чем node.js — лучше проработана многопоточность, есть множество инструментов для распараллеливания и кластеризации.
Мне кажется, у вас на схеме слишком сильно разделены модули, которые по логике будут сильно связаны и не видно места для какой-то более сложной логики поведения чем «есть список задач, прошёлся, получил каждую, разобрал, сохранил». Поведение бота на сайте — поведенческий алгоритм, ему далеко не всегда нужно грести всё подряд.
Хороший металлический корпус, экран (3840x2160), хороший процессор (i7-5557U), хороший вес (2.0kg), великолепный объем ОЗУ (32GB, господи, наконец-то в нормальных ноутбуках). И заметьте, цена всего этого — аналогична цене на макбук, так что про задранность цен Apple — сильное преувеличение.
Автора, как не гражданина России врядли это должно заботить, но боюсь хабр, в связи с последними веяниями, статусом электронного СМИ и «организатора распространения информации» не самое подходящее место для таких постов.
Вообще, статический анализ там на высоте, крайне редко бывают ложные срабатывания, да и то, они часто связаны с неявными предоложениями о коде, которые знает программист (что иначе не будет), но которые не может знать анализатор.
Если книга не продаётся — значит издатель неверно оценил риски, и как страховая фирма, несёт потери на издательство и фиксированный гонорар автора. Если продаётся — компенсирует затраты на издательство, и страховая часть прибыли идёт на компенсацию других, менее успешных проектов и в чистую прибыль.
Сумма страховки может колебаться в зависимости от желаемого автором фиксированного гонорара — он может вообще от него отказаться, снизив сумму страховки, и получить деньги только в случае, если книга окупится достаточно, чтобы покрыть затраты на издательство и сумму страховки.
У автора будет больше мотивации писать хорошую книгу — если она превзойдёт ожидания издателя, он получит сверхприбыль за все превышенные продажи. А у издателя будет более качественная оценка собственных рисков.
2. Аннотации обрабатываются GlobalEventManager'ом в метода registerListeners и unregisterListeners.
Реализация:
GlobalEventManager
https://gist.github.com/naphaso/c9dbb8a4d4035d1f0584
умеет регистрировать/разрегистрировать обработчики сообщений с определённым типом TP — обрабатывать в тредпуле, UI — обабатывать в UI-потоке, IN — обрабатывать синхронно в потоке, пославшем сообщения (значительно быстрее, если обработчик сообщения отрабатывает очень быстро и не взаимодействует с UI).
Отнаследованы и подкручены тред-пулы, чтобы назначали красивые имена тредам, которые обрабатывают сообщения, чтобы было видно в логах, к обработке какого сообщения отновится каждая запись там.
EventTask
https://gist.github.com/naphaso/69de1a51ad383035dd04
Собственно, он и назначает красивые имена тредам.
EventListener
https://gist.github.com/naphaso/cc6d7b5da4de4c301f8d
Хранит WeakReference не объект и метод для обработки сообщения. WeakReference — чтобы, в случае, если объект забыл или физически не может (не знает, когда) отписться от приёма сообщений, это не приводило к трагическим последствиям в виде удерживания этого объекта в памяти.
Используется примерно так:
В любом объекте при его старте подписываемся на сообщения:
Когда уже не нужно принимать сообщения, отписываемся:
Как уже сказал, отписываться не обязательно, но желательно.
Обрабатываем сообщения в методах, аннотиованных следующим образом:
Ну, и полный пример:
За ошибки не ручаюсь, писал код прямо в комментарии. Потом, правда, этот подход пришлось немного переработать, но было весьма удобно.
Читайте не наискосок. Если сократить фразу, получится «Стандартные средства инкапсуляции требуют, а Teredo — не требует.»
Мне кажется, у вас на схеме слишком сильно разделены модули, которые по логике будут сильно связаны и не видно места для какой-то более сложной логики поведения чем «есть список задач, прошёлся, получил каждую, разобрал, сохранил». Поведение бота на сайте — поведенческий алгоритм, ему далеко не всегда нужно грести всё подряд.