> Если у бухгалтеров нижнего уровня мозги находятся в двух полушариях верхнего отростка, то у бухгалтеров, выдающих инструктивные материалы – ближе к центру тяжести, также разделенному на два полушария.
В гамме До-мажор после До идет Ре и никак иначе. Посему вероятность перехода из ноты До в Ре в цепи Маркова будет равна единице. Тут уж ничего не поделаешь. Поэтому анализ гаммы через цепь Маркова даст ту же самую гамму.
> Отсюда второй вопрос, допустим я хочу подзаработать и у меня есть 2 млн. валюты. Я один из них удаляю, т. е. у меня остаётся 1 млн. Будет ли он стоить (например в долларах США) в два раза больше оставшийся миллион или курс не измениться от моих действий?
А зачем удалять свой миллион? Просто припрячьте его и не делайте по нему никаких движений. Резко окажется что валюты в системе меньше, и она поднимется в цене, правда сомневаюсь что цена увеличится в два раза от этого действия. При выпущенных 11 млн. надо хотя бы половину денежной массы придержать, т.е. 5-6 млн., чтобы получить теоретический рост стоимости биткоина в два раза.
Как только биткон вырос в два раза, вы становитесь потенциальным обладателем суммы в два раза больше. Потенциальным потому, что вам еще их надо продать, а «эмитирование» ваших биткоинов обратно в экономическую систему будет приводить к инфляции.
К тому же изъятие половины биткоинов из системы (даже временное) приведет к застою системы, потому что когда денег мало, мало что развивается — и услуги и продажи идут вниз.
Коль пошла такая пьянка, хочу снова попробовать обратиться к экспертам, если здесь такие присутствуют.
Есть такая OpenSource программа MyTetra. Данные пользователя могут храниться на открытых для всех на чтение бесплатных Git-репозитариях, например на GitHub.com. Приватные данные шифруются с помощью самописной библиотеки RC5Simple.
Схема шифрования следующая:
Данные шифруются по алгоритму RC5-32/12/16 c CBC-режимом сцепления (библиотека RC5Simple), ключ генерируется на основе пароля с солью, пропущенного через алгоритм PBKDF2 на 1000 раундов с длиной ключа 160 бит. Для генерации ключа шифрования в 128 бит, от результата берется MD5 сумма. Каждая запись шифруется с уникальным инициализирующим вектором.
Хотелось бы оценить две вещи:
1. Правильность реализации RC5. Сама библиотека RC5Simple имеет всего 20Кб C++ кода. Хотелось бы провести ревизию кода/алгоритма специалистом, который разбирается в вопросе.
2. Оценка стойкости данного метода шифрования. Меня беспокоит тот факт, что открытый текст всех зашифрованных записей одинаковый — обычный HTML заголовок. В принципе, он конечно перемешивается за счет инициализирующего вектора (другими словами — соли), но вектор хранится ведь в открытом виде. Поэтому, сверху накладывается PBKDF2. Достаточно ли этого всего для того, чтобы при хорошем пароле на современных средних мощностях невозможно было подобрать пароль ну пусть в течении 100 лет?
> Первое что меня удивило — это отсутствие ТЗ в каком-нибудь твердом виде — все на словах, соответственно сложности с внезапными изменениями проекта в дальнейшем
Так это же прекрасно!
В такой ситуации надо самому разрабатывать техзадание, чтобы в нем было нормальное техническое решение, и подписывать его. Это нужно сделать обязательно перед началом разработки. Напрячся, сделать, подписать, и положить рядом с собой. Обычно, «заказчик» не хочет писать техзадания, совершенно спокойно подписыват ТЗ, составленное «подрядчиком». В этот момент «заказчик» попадается на крючек.
Причем это хороший, прекрасный крючек. Вы обезопасиваете себя как разработчика, что завтра требования поменяются. Вы всегда, при любых попытках поломать сложившуюся модель, ткнете носом кого угодно в ТЗ и скажете — мы делаем всё по ТЗ! Хотите менять — разрабатывайте изменения к ТЗ. Обычно никто не вникает и не понимает, что ТЗ вы написали сами под себя и проект. При фразе «выпустить изменения к ТЗ» феерические желания переделать концепт волшебным образом исчезают.
Сам неоднократно пользовался этой схемой в атомной индустрии, а в этой отрасли бюрократии и идиотизма не меньше, уж поверьте (у вас начальники-военные, а у нас начальники-строители, неизвестно что хуже). Схема работает, пользуйтесь и не жалуйтесь на жизнь.
Ну это же неэргономично. Любой разрыв отвлекает внимание. Это издевательство над пользователем, и напоминает навязчивую рекламу. Неужели вы этого не видите?
Хотите иметь тематические блоки — имейте, но не разрывайте ими поисковую выдачу. Не бойтесь, что вашими блоками не будут пользоваться. Будут, если они сделаны по-уму. Сделайте же логично:
1 Строка запроса
2 Остров «Поисковая выдача»
3 Остров «Плеер» (по необходимости)
4 Остров «Картинки» (по необходимости)
5 Остров «Видео» (по необходимости)
6 Остров «Какая-то неведомая хня» (по необходимости)
Отдайте сортировку островов на откуп пользователям. Сделайте инструменты перемещения на заголовке острова, с понятными иконками. Тогда у аудиофилов вверху будет плеер, у дизайнеров вверху будут картинки, а у техтврайтеров вверху будет поисковая выдача в виде текста.
Умоляю, делайте что хотите, НО ТОЛЬКО НЕ РВИТЕ ПОИСКОВУЮ ВЫДАЧУ!
Если убрать ключевое слово var из строки var title = 'internal', то запустив код, в результате дважды получим сообщение «internal». Это происходит из-за того, что при вызове функции мы объявляли не локальную переменную title, а перезаписывали значение глобальной переменной!
Потом далее приводите пример:
var title = «external title»;
function example(){
title = «changing external title»;
alert(title);
…
example();
Если закомментировать строку title = «changing external title»;, то при первым сгенерированным сообщением станет «undefined» — локальная переменная title уже была инициализирована (существует), но значение (на момент вызова alert-а) не было присвоено.
Вопрос. Почему в этом примере переменная title толи не вида внутри функции, то ли еще не проинициализирована, хотя это делается в первой же строке программы?
> «Тонкий клиент» у 1С только называется тонким, по сути же, это самый обычный толстый клиент.
Эээ… Даже нет слов. Вы бы хоть пакеты посниффали в режиме тонкого и толстого клиента 1С между клиентом и сервером. Это совершенно разные режимы работы.
Тонкий клиент 1C — это настоящий тонкий клиент, который отправляет серверу команды в XML формате, получает от него готовые XML данные и представляет их на экране. Внутрях все XML-данные раскладываются в DOM-модель используя libxml2. Веб-клиент делает то же самое, только с помощью браузера, разгребая всё ява скриптом и активно работая с DOM средствами браузера.
Никакого отношения тонкий и веб-клиент не имеют к толстому клиенту.
Эта пять, ржал как конь!
2, 15, 36,
10, 18.
47 / 5,
20, 20, 20…
48, 0, 1,
5 / 9…
18! 37!
89!
2 + 2, 15, 6,
1012…
28 — 5
20, 20, 20!
В гамме До-мажор после До идет Ре и никак иначе. Посему вероятность перехода из ноты До в Ре в цепи Маркова будет равна единице. Тут уж ничего не поделаешь. Поэтому анализ гаммы через цепь Маркова даст ту же самую гамму.
А зачем удалять свой миллион? Просто припрячьте его и не делайте по нему никаких движений. Резко окажется что валюты в системе меньше, и она поднимется в цене, правда сомневаюсь что цена увеличится в два раза от этого действия. При выпущенных 11 млн. надо хотя бы половину денежной массы придержать, т.е. 5-6 млн., чтобы получить теоретический рост стоимости биткоина в два раза.
Как только биткон вырос в два раза, вы становитесь потенциальным обладателем суммы в два раза больше. Потенциальным потому, что вам еще их надо продать, а «эмитирование» ваших биткоинов обратно в экономическую систему будет приводить к инфляции.
К тому же изъятие половины биткоинов из системы (даже временное) приведет к застою системы, потому что когда денег мало, мало что развивается — и услуги и продажи идут вниз.
Вы дали ссылку на гамму. Если вы проанализируете гамму, то цепь Маркова будет вам генерировать только ту же самую гамму.
Лицензию на XnView покупали? Наверняка нет. А он бесплатен только для домашнего пользования и учебных заведений!
Есть такая OpenSource программа MyTetra. Данные пользователя могут храниться на открытых для всех на чтение бесплатных Git-репозитариях, например на GitHub.com. Приватные данные шифруются с помощью самописной библиотеки RC5Simple.
Схема шифрования следующая:
Данные шифруются по алгоритму RC5-32/12/16 c CBC-режимом сцепления (библиотека RC5Simple), ключ генерируется на основе пароля с солью, пропущенного через алгоритм PBKDF2 на 1000 раундов с длиной ключа 160 бит. Для генерации ключа шифрования в 128 бит, от результата берется MD5 сумма. Каждая запись шифруется с уникальным инициализирующим вектором.
Хотелось бы оценить две вещи:
1. Правильность реализации RC5. Сама библиотека RC5Simple имеет всего 20Кб C++ кода. Хотелось бы провести ревизию кода/алгоритма специалистом, который разбирается в вопросе.
2. Оценка стойкости данного метода шифрования. Меня беспокоит тот факт, что открытый текст всех зашифрованных записей одинаковый — обычный HTML заголовок. В принципе, он конечно перемешивается за счет инициализирующего вектора (другими словами — соли), но вектор хранится ведь в открытом виде. Поэтому, сверху накладывается PBKDF2. Достаточно ли этого всего для того, чтобы при хорошем пароле на современных средних мощностях невозможно было подобрать пароль ну пусть в течении 100 лет?
Я уже обращался к экспертам на Хабаре:
http://habrahabr.ru/post/124090/#comment_4089407
но в ответ была только отписка.
Так это же прекрасно!
В такой ситуации надо самому разрабатывать техзадание, чтобы в нем было нормальное техническое решение, и подписывать его. Это нужно сделать обязательно перед началом разработки. Напрячся, сделать, подписать, и положить рядом с собой. Обычно, «заказчик» не хочет писать техзадания, совершенно спокойно подписыват ТЗ, составленное «подрядчиком». В этот момент «заказчик» попадается на крючек.
Причем это хороший, прекрасный крючек. Вы обезопасиваете себя как разработчика, что завтра требования поменяются. Вы всегда, при любых попытках поломать сложившуюся модель, ткнете носом кого угодно в ТЗ и скажете — мы делаем всё по ТЗ! Хотите менять — разрабатывайте изменения к ТЗ. Обычно никто не вникает и не понимает, что ТЗ вы написали сами под себя и проект. При фразе «выпустить изменения к ТЗ» феерические желания переделать концепт волшебным образом исчезают.
Сам неоднократно пользовался этой схемой в атомной индустрии, а в этой отрасли бюрократии и идиотизма не меньше, уж поверьте (у вас начальники-военные, а у нас начальники-строители, неизвестно что хуже). Схема работает, пользуйтесь и не жалуйтесь на жизнь.
Ребята, ну неужели вы не понимаете, что разрывать поисковую выдачу нельзя?
У вас получилось:
* Плеер
* Поисковая выдача
* -=-=-=-=-=-=- Разрыв картинками -=-=-=-=-=-=-
* Поисковая выдача
* -=-=-=-=-=-=- Разрыв видеороликами -=-=-=-=-=-=-
* Страничная навигация
Ну это же неэргономично. Любой разрыв отвлекает внимание. Это издевательство над пользователем, и напоминает навязчивую рекламу. Неужели вы этого не видите?
Хотите иметь тематические блоки — имейте, но не разрывайте ими поисковую выдачу. Не бойтесь, что вашими блоками не будут пользоваться. Будут, если они сделаны по-уму. Сделайте же логично:
1 Строка запроса
2 Остров «Поисковая выдача»
3 Остров «Плеер» (по необходимости)
4 Остров «Картинки» (по необходимости)
5 Остров «Видео» (по необходимости)
6 Остров «Какая-то неведомая хня» (по необходимости)
Отдайте сортировку островов на откуп пользователям. Сделайте инструменты перемещения на заголовке острова, с понятными иконками. Тогда у аудиофилов вверху будет плеер, у дизайнеров вверху будут картинки, а у техтврайтеров вверху будет поисковая выдача в виде текста.
Умоляю, делайте что хотите, НО ТОЛЬКО НЕ РВИТЕ ПОИСКОВУЮ ВЫДАЧУ!
Потом далее приводите пример:
Вопрос. Почему в этом примере переменная title толи не вида внутри функции, то ли еще не проинициализирована, хотя это делается в первой же строке программы?
Роулинг? Гарри Поттера?? Из любви к искусству??? Сериал из 7 книг за 9 лет!!! Боже, как она любит искусство то…
Сравнение с Пушкиным и Толстым выглядит особенно феерично.
Слегка… Он просто не видел ЛОР!
www.youtube.com/watch?v=lVXmfFtZLwc
Эээ… Даже нет слов. Вы бы хоть пакеты посниффали в режиме тонкого и толстого клиента 1С между клиентом и сервером. Это совершенно разные режимы работы.
Тонкий клиент 1C — это настоящий тонкий клиент, который отправляет серверу команды в XML формате, получает от него готовые XML данные и представляет их на экране. Внутрях все XML-данные раскладываются в DOM-модель используя libxml2. Веб-клиент делает то же самое, только с помощью браузера, разгребая всё ява скриптом и активно работая с DOM средствами браузера.
Никакого отношения тонкий и веб-клиент не имеют к толстому клиенту.
Сразу возникает вопрос — с какой такой первой молекулы магний получил 5 электронов?
Может быть, чтобы было понетнее, написать так:
«Как видим, Mn первой молекулы получил 5 электронов, а S второй молекулы отдал 2 электрона».