Как стать автором
Обновить
9
Карма
0
Рейтинг
Кирилл @EvilBlueBeaver

Пользователь

  • Подписчики 3
  • Подписки 4

6 шагов загрузки Linux на пальцах

Не совсем те же яйца, там еще есть управление зависимостями сервисов, то есть sshd, например, раньше сети не запустится. Это по-моему гораздо удобнее, чем распихивать скрипты по разным папкам с номерами.

Brainfucker-ы замечены среди разработчиков JavaScript

К тому же сравнение double и int тоже может быть весьма веселым. Особенно если дабл был не константый, а получен путем арифметических операций.
... здесь какие-то операции. Мы проверяем подсчет на бумажке и d должно быть равно 2
if(d == 2)
... а вот тут получаем упс и d не равно 2

А весь прикол как вы понимаете в том, что после операций в d может лежать 1.999999999, а не 2. Да к тому же приведение целого к double тоже чревато такики вот неточностями.
В общем нет сравнениям чисел с плавающей точкой как между собой, так и с целыми!

Brainfucker-ы замечены среди разработчиков JavaScript

В любом языке if сам приводит выражение к булевому типу, поэтому писать if(11 == true) могут только долбоё^W похапешники.


Ну положим не в любом. В плюсах можно точно так же писать, да и в сях, даром, что там bool нету. И вы даже ворнинга не получите, поскольку true по сути число. А вот числа с указателями уже сравнивать не выйдет (точнее выйдет, но будут ворнинги). А при сравнении чисел с объектами вы вообще будете получать ошибки.

Вообще неявное приведение типов и есть причина большинства ошибок такого рода.

Brainfucker-ы замечены среди разработчиков JavaScript

В C нет более широких и более узких типов. Вы наверное с C++ путаете.

Если я в C сравниваю int с char*, то компилятор мне по крайней мере напшет warning, что я дурак и что в результате будет непонятно что. Но если я упертый и угнорирую ворнинги, то ССЗБ.

Как уже было написано выше, С все понимает явно, сказали ему сравнить указатели — сравнит указатели, даром, что там строки внутри. Хотите строки сравнивать, так вызывайте функцию сравнения строк. Понимание только одного этого факта уже помогает избежать множества подводных камней и заучивания странных правил.

Хотя с другой стороны низкоуровневость накладывает свои отпетатки и заставляет учитывать множество других факторов.

Формирование данных с помощью шаблонов С++

Ну да, согласен. Сейчас с помощью товарища проверил, в cl.exe такого нет. Но это не повод городить то, что написал автор.

Формирование данных с помощью шаблонов С++

А это тогда как объясните?
#include <iostream>
using namespace std;
int main()
{
        int num = 0b0010010;
        cout << num << endl;
        return 0;
}


beaver@gentoo /home/beaver/1 $ g++ 1.cpp -o 1
beaver@gentoo /home/beaver/1 $ ./1
18

Формирование данных с помощью шаблонов С++

С++ не имеет встроенных средств написания чисел в двоичном виде.

а
 int myBinaryNumber = 0b0110110; 
уже отменили? Или я что-то неправильно помню?

Использование Rebar и GProc

Ну в частности в моем проекте воркеры между собой не общаются. Они общаются либо с именованными процессами, либо с супервайзером. Поэтому я слегка и не понял задумки.

Вообще у меня возникла такая идея — прикрутить эту диспетчиризацию к супервайзеру. Он знает, какие у него дети присутствуют и в качестве идентификатора может быть любой терм. Просто подсознательно идея с глобальным состоянием меня пугает. Единственное — я не вижу в доке способ получения спеки одного дочернего процесса, только which_children. Но думаю, что это можно обойти.

Что вы думаете по поводу этой идеи?

Использование Rebar и GProc

Опять же, я не настолько искушен в этом деле. Наверно просто я сам не встречался с такими задачами. Но в моих задачах есть либо именованные процессы, к которым надо обращаться по имени, либо воркеры, к которым обращение идет через pid либо они первые начинают) Но все равно спасибо, будем знать, что к чему и если возникнет необходимость — использовать.

Реляционные базы данных обречены?

Создание или обновление. Если создание, то понятно. Вот если обновление, то это уже сложнее. Но в любом случае что мешает поднять вторую ноду? У кауча репликация мастер-мастер, то есть вы сможете коннектиться в любой из нод, и таким образом перераспределять нагрузку. Если я не прав — поправьте меня.

Вся прелесть как раз вот в таких преиндексированных вьюхах. Иначе весь смысл пропадает. Я не знаю, как у этим с монго.

Реляционные базы данных обречены?

Каждый раз запрос будет обрабатываться заново, пусть по индексам, но заново. Можно конечно закешировать, но что делать при обновлениях, вешать триггеры, а потом судорожно искать баги? А вот в кауче написав однажды вьюху при обновлении данных она будет обновляться автоматически, причем весьма быстро.

Использование Rebar и GProc

Я возможно не совсем понял, но зачем в принципе давать имена процессам, которые не являются долгоживущими? Можете пояснить на каком-нибудь примере?

Реляционные базы данных обречены?

Ага, щаззз
Если есть индексы по нужным полям. это раз.
Два, если таких запросов по разным полям у вас много, то индексов будет дофига. Соотвественно вставка у вас будет «весьма быстрой».
И 3 для аналитики надо использовать OLAP в связке с другим хранилищем с регулярной выгрузкой данных из него в OLAP. Да, мы не сможем получить мгновенный отчет на данную минут, но это чаще всего и не требуется, зато запросы будут действительно мгновенные и вставка не будет тормозить.

Реляционные базы данных обречены?

1. А люди думают, что NoSQL — это только простейшие хешмапы, а map/reduce — деление одного английского глагола на другой :)
2. Про то, что для запросов в map/reduce вообще не нужно специального языка (например в монго и кауче используется совершенно обычный javascript) они тоже не в курсе. И то, что это не тупой перебор всех документов по очереди, тоже не подозревают
3. Про то, что аналитика на SQL при огромных хранилищах — самоубийство, тоже не в курсе. Нормальные люди используют OLAP.
4. Я не знаю, что это такое, поэтому промолчу

Реляционные базы данных обречены?

Ну прощу прощения тогда. Не совсем правильно вас понял значит.

Реляционные базы данных обречены?

Ну так key-value семейство и предназначено для хранения key-value. Если вам нужна выборка по полю, то делайте дублирование и добавляйте записи у которых ключом будет это поле, а значением — набор объектов. Ну либо используйте что-то более подходящее.

Реляционные базы данных обречены?

Скажу я. Не могу сказать за все СУБД, потому буду про кауч.

В NoSQL нет джойнов. соответсвенно если у вас большое число разнотипных и больших оьъектов, связанных между собой, то хранение их в кауче (а точнее выборка) будет не слишком эффективно и вот почему.

Если хранить с полем, содержащим идентификатор связанного документа, то можно будет сделать квази-джойн на 1 уровень в глубину (на самом деле это не джойн, а просто сахар, для связанного id уже после мапа прогружается документ). Обсуловлено это тем, что функция map (в которой собственно происходит выборка) явяется чистой и для получения результата может пользоваться только переданным ей документом. Это нужно для оптимизации автоматического построения и обновления индексов.

Есть вариант хранения многоуровневой иерархии в одном документе, но это содержит ряд недостатков.
1. Документу нельзя только обновить поле. Надо загрузить документ, исправить поле и залить документ. Отсюда получаем, что для больших документов будет неэффективно.
2. Если требуется часто менять вложенные подобъекты, то вам придется самому озаботиться обновлением этих подобъектов во всех документах. Кстати аналогично будет и при денормализации БД в РСУБД.

Поэтому для себя делаю вывод, что в частности кауч подходит для хранения плоских или почти плоских моделей, без глубоких взаимосвязей. Причем оптимально его использовать для моделей с нечеткой структурой. НУ и само собой, когда нужна или планируется горизонтальная масштабируемость.

Реляционные базы данных обречены?

Ничего вам не придется. По крайней мере не во все NoSql СУБД. Это как раз в SQL субд вам надо озаботится о наличии индексов, а кауч все сделает наиоболее оптимальным образом для конкретного запроса. Естественно запрос должен быть описан во vew.

Реляционные базы данных обречены?

Например Couch для каждого view(считайте что это запрос) атоматически строит B+ дерево. То есть выборка будет оптимальна. Да и обновление этого дерева будет так же быстро за счет чистоты функции map. То есть для нового документа достаточно посчитать ключ и воткнуть в нужное место дерева.

[Вебинар] Представление иерархических структур в реляционных БД

См. выше вопрос по поводу индексов в частности.

Информация

В рейтинге
Не участвует
Откуда
Волгоград, Волгоградская обл., Россия
Дата рождения
Зарегистрирован
Активность