Правительству США выгодно иметь тупой народ. Чем тупее народ — тем легче им управлять. В итоге деньги платит государство за оболванивание народа. Вот вам и экономическая выгода для телеканала.
С другой стороны, антиреклама — тоже реклама. В итоге получается скандал и больше народу смотрит этот канал. Как следствие дороже реклама на этом канале.
А что если в радиусе действия одной Wi-Fi точки надо установить более одной ссылки? QR кодами можно облепить хоть всю стену и все они будут ссылаться на разные страницы.
1. kdbx пока не открывает
2. KWallet стандартная программа для управления паролями с интерграцией с приложениями чем KeePassX не может похвастаться. Не делать же Open->Find->Copy->Paste to form, а просто goto form->Login->Profit
Стараюсь писать код как можно короче (<80), но если ради читаемости или удобства восприятия необходимо больше пространства прибегаю к этому.
Из своего опыта я сталкивался с потребностью в длинных строках когда:
1. Много параметров у метода — ртешение: использовать либо структуру для передачи параметров, либо метод выполняет слишком много действий и в итоге требует рефакторинга.
2. Условие из слишком много условий — решение: зарефакторить таким образом чтобы большая часть условий вычислялись заранее и присваивались коротким но осмысленным переменным, либо вынос условий в методы (часто не один метод).
3. Выражение по вычислению чего-либо слишком длинное. решение: разбить на куски и по отдельности вычислить либо вынести кое-что в методы.
4. Вырежение-вызов метода с не большим количеством параметров, но содержащий длинные идентификаторы (10+ символов). В принципе такое можно отрефакторить но не всегда. Вот такие случаи:
— Укоротить идентификаторы невозможно, потому что читабильность уменьшится.
— Вынести расчет параметров в отдельности невозможно потому что они и так записаны как идентификатор на переменную.
В итоге подобная ситуция может вылится в 100-120 символов. Что никогда не была проблемой для меня и моих коллег.
В итоге наличие длинных строк ситуция оооочень редкая, но не критичная с моей точки зрения.
ЗЫ: Пишу на Java.
Вы наверное не поняли основной механизм хранения данных. В системе у вас лежит репозиторий который всегда находится в HEAD ревизии. Этот репозитрий не является вашим рабочим каталогов. В вашем рабочем каталоге вы можете находиться хоть на 1000 ревизий назад, системе это не важно. Она работает только с локальным репозиторием. При обновлении вы получаете данные не от соседей а из этого репозитория.
С учетом этой поправки вышеописанные проблемы решаются также как и в git-е.
Во время коммита выполненые изменения должны распространяться среди всех участников разработки. В результате у каждого разработчика будет одинаковое состояние репозитория.
В случае одновременных коммитов, система должна расчитывать очередность коммитов (возможно это будет в процессе общения между собой инициаторов данных коммитов), и эту информацию распростронять по учасникам, тем самым обеспечивая одинаковость истории и самого репозитория.
Мерджи — также как и сейчас, один выполняет у себя мерж, а потом распростроняет его среди всех остальных. По умолчанию это тот кто вливает ветку в мастер (короче инициатор этого мерджа).
А вы не задумывались, когда в шумной обстановке к вам обращаются, вы слышите каждую букву, каждое слово? Конечно же нет. Если бы вы распознавали также как предлагаете чтобы машина делала, людям бы приходилось разговаривать только в тихих, специально отведеных местах.
Наш процесс распознавания речи собеседника происходит путем подбора текста согласно услышаным звукам от собеседника, контекста разговора (включая предыдущие разобранные слова), обстановки и пр. обстоятельств.
Я считаю что идеальный распознаватель голоса должен бытьименно такой как это делает человек.
Вспомните дело об обмене информацией через камень в сквере (см. science.compulenta.ru/248401/). Интересно как наши ФСБ-шники эту схему вычислили?
Думаю также и тут, обнаружат рано или поздно.
Я задался вопросом, а как же передать большой объем информации второй стороне, и получить ответ не привлекая при этом внимания. Ну представьте что при каждом сообщении двух персон они обмениваются фотографиями своих котов. Подозрително выглядеть будет, не так ли?
И пришла идея использовать видео звонок. Оба абонента сидят и болтают о том как и когда поедут на рыбалку. А в то время каждый кадр с веб камеры и весь поток аудио стеганографируется. В итоге тонны информации передано и получено, подозрений нет.
Тут можно придумать чтобы цвета менялись не крепко, например каждый канал менялся максимум на единицу. Тогда на один пиксель прийдется по 3 бита кодируемой информации и при этом информация вписывалась в каждый первый пиксель. Этот подход конечно не позволит много инфы скрывать (при картинке 1600*1200 получится максимум 700Кб), но при этом визуально почти не заметно будет (конечно кроме одноцветных участков и на переходах).
Статья действительно интересная. Автору респект.
И хочу сказать для тех кто попробует что-то подобное реализовать: Будьте внимательны при выборе алгоритма стеганографии. В зависимости от алгоритма стеганографии и скрываемой информации может получиться что скрытие очевидно.
Вот пример: Здесь я взял столь великодушно предоставленное автором приложение и попытался сокрыть половину статьи. Как видите результат на лицо.
* Кстати, не критикуйте автора, он всего-лишь продемострировал само понятие стеганографии на очень простом примере.
Я бы сказал наоборот. Если ему еще никто не предложил работу, значит основная задача не выолнена. А вот второстепенная задача («обратите на меня внимание») даже перевыполнена.
public class App
{
public static void main( String[] args ) throws IOException
{
Map<String, Holder> words = new HashMap<>(20000);
Pattern p = Pattern.compile("\\w+", Pattern.CASE_INSENSITIVE);
int n = Integer.parseInt(args[1]);
try (BufferedReader in = new BufferedReader(new FileReader(args[0]), 6000)) {
try (PrintWriter out = new PrintWriter(new BufferedOutputStream(System.out, 6000))) {
String line = null;
while(( line = in.readLine()) != null ) {
Matcher m = p.matcher(line);
while(m.find()) {
Holder holder = words.get(m.group());
if (holder != null) {
holder.num++;
if (holder.num == n) {
out.println(m.group());
}
} else {
words.put(m.group(), new Holder());
}
}
}
}}
}
private static class Holder {
int num = 1;
}
}
Команда исполнения:
time java -cp ./target/classes/ com.qitsoft.warandpeace.App /home/serj/Documents/pg2600.txt 5
Винда для всех интуитивна — это все говорят. А спросите поколение по-старше (от 45 и старше), интуитивна ли она для них? Конечно нет. Вы же не скажете что они тупые. Для них интуитивно совсем другое. А вот когда научатся работать на винде, тогда она станет для них интуитивна. Все дело привычек.
Тут явно видна инновация. Которая возможно в скором будущем станет де-факто и интуитивной для всех.
Я могу лишь сказать — Молодцы.
Возможно этот телефон не дотягивает до гигантов-производителей смартфонов, но это на начальном этапе простительно и понятно. Желаю чтобы у них получилось быстро выйти на уровень гуру в области производства смартфонов.
А те кто во всю глотку обсырает этот телефон, задумайтесь вот над чем, Вы умеете танцевать брейк-данс? А когда родились!? И подумайте, сколько времени Вам понадобится научиться этому (если уже умеете, то вспомните сколько времени потратили на обучение).
Вместо высказывания недовольства сделали бы что-нибудь полезное, к примеру обратились в Йота Девайсис с набором предложений о том как улучшить их продукт, а возможно и свою помощь предложили. Тех кто это сделал уважаю, и эти строки не для них.
Критика должна быть. И она должна быть конструктивной, а не «это все плохо и неуобно».
Вполне с тобой согласен. Но с моей точки зрения даже код фрейворка должен быть написан в таком стиле чтобы его потом могли мейнтейнить другие девелоперы (EJB контейнеры ведь не мейнтейнят только создатели, но в процесс разработки подключаются и другие, главное чтоб не ламеры чтобы не плодить макароны)
С другой стороны, антиреклама — тоже реклама. В итоге получается скандал и больше народу смотрит этот канал. Как следствие дороже реклама на этом канале.
2. KWallet стандартная программа для управления паролями с интерграцией с приложениями чем KeePassX не может похвастаться. Не делать же Open->Find->Copy->Paste to form, а просто goto form->Login->Profit
Из своего опыта я сталкивался с потребностью в длинных строках когда:
1. Много параметров у метода — ртешение: использовать либо структуру для передачи параметров, либо метод выполняет слишком много действий и в итоге требует рефакторинга.
2. Условие из слишком много условий — решение: зарефакторить таким образом чтобы большая часть условий вычислялись заранее и присваивались коротким но осмысленным переменным, либо вынос условий в методы (часто не один метод).
3. Выражение по вычислению чего-либо слишком длинное. решение: разбить на куски и по отдельности вычислить либо вынести кое-что в методы.
4. Вырежение-вызов метода с не большим количеством параметров, но содержащий длинные идентификаторы (10+ символов). В принципе такое можно отрефакторить но не всегда. Вот такие случаи:
— Укоротить идентификаторы невозможно, потому что читабильность уменьшится.
— Вынести расчет параметров в отдельности невозможно потому что они и так записаны как идентификатор на переменную.
В итоге подобная ситуция может вылится в 100-120 символов. Что никогда не была проблемой для меня и моих коллег.
В итоге наличие длинных строк ситуция оооочень редкая, но не критичная с моей точки зрения.
ЗЫ: Пишу на Java.
С учетом этой поправки вышеописанные проблемы решаются также как и в git-е.
В случае одновременных коммитов, система должна расчитывать очередность коммитов (возможно это будет в процессе общения между собой инициаторов данных коммитов), и эту информацию распростронять по учасникам, тем самым обеспечивая одинаковость истории и самого репозитория.
Мерджи — также как и сейчас, один выполняет у себя мерж, а потом распростроняет его среди всех остальных. По умолчанию это тот кто вливает ветку в мастер (короче инициатор этого мерджа).
Наш процесс распознавания речи собеседника происходит путем подбора текста согласно услышаным звукам от собеседника, контекста разговора (включая предыдущие разобранные слова), обстановки и пр. обстоятельств.
Я считаю что идеальный распознаватель голоса должен бытьименно такой как это делает человек.
Думаю также и тут, обнаружат рано или поздно.
И пришла идея использовать видео звонок. Оба абонента сидят и болтают о том как и когда поедут на рыбалку. А в то время каждый кадр с веб камеры и весь поток аудио стеганографируется. В итоге тонны информации передано и получено, подозрений нет.
И хочу сказать для тех кто попробует что-то подобное реализовать: Будьте внимательны при выборе алгоритма стеганографии. В зависимости от алгоритма стеганографии и скрываемой информации может получиться что скрытие очевидно.
Вот пример:
* Кстати, не критикуйте автора, он всего-лишь продемострировал само понятие стеганографии на очень простом примере.
Команда исполнения:
Результат:
Тут явно видна инновация. Которая возможно в скором будущем станет де-факто и интуитивной для всех.
Возможно этот телефон не дотягивает до гигантов-производителей смартфонов, но это на начальном этапе простительно и понятно. Желаю чтобы у них получилось быстро выйти на уровень гуру в области производства смартфонов.
А те кто во всю глотку обсырает этот телефон, задумайтесь вот над чем, Вы умеете танцевать брейк-данс? А когда родились!? И подумайте, сколько времени Вам понадобится научиться этому (если уже умеете, то вспомните сколько времени потратили на обучение).
Вместо высказывания недовольства сделали бы что-нибудь полезное, к примеру обратились в Йота Девайсис с набором предложений о том как улучшить их продукт, а возможно и свою помощь предложили. Тех кто это сделал уважаю, и эти строки не для них.
Критика должна быть. И она должна быть конструктивной, а не «это все плохо и неуобно».