Автор правильно указал, что начинаются проблемы с выделением непрерывных блоков памяти из-за фрагментации. Блоки 500-700 МБ — компромиссный размер на подобных задачах (недавно разговаривал с парнем, работающим в HP — они софт для промышленных принтеров пишут, и сталкивались с подобными проблемами).
практически все умные программисты, которых я встречал — нормальные «индивиды» с отличными навыками общения. Из пары сотен человек было ну буквально пара, которые умные программеры, но в общении неадекватны :-) так что это — стереотип, типа «тупых блондинок»
Не все так просто… недавно читал где-то статью про нагруженный сервак, переехавший с кауча на монго из-за того, что создание таких вьюх на их объемах данных занимало по несколько часов.
Проблема (очевидная) со складыванием JSON в CLOB заключается в том, что с этим текстом ничего нельзя сделать, только прочитать весь целиком. Тогда как в документно-ориентированном хранилище можно по полям делать выборки, сортировки и т.п.
1. Тем, что структура данных не жесткая — каждая запись может иметь собственный набор полей. Реализация этой фичи в реляционной базе данных громоздка и неудобна (как раз сейчас с этим возимся)
2. NoSQL или SQL? SQL в сравнении с NoSQL является супер-стандартным. Каждая NoSQL база данных имеет собственный API, собственный язык запросов, собственные правила работы с индексами, и кучу ограничений и особенностей.
3. без комментариев
4. ИМХО, очень частный и достаточно трудоемкий случай
Судя по вашему комментарию, у вас на собеседовании вопросы будут еще интереснее, и отсев кандидатов будет на порядок выше… или вы собираетесь учить людей, не знащих про существование rwlock, «правильному» многопоточному программированию?..
Вопросы, описанные в статье, очень примитивны, и любой программер их должен знать (server-side, по крайней мере, а GUI формочки можно и без этого лабать)
Я себя ловлю временами на том, чтобы написать еще что-нибудь в резюме… недавно в c Python в Ruby пришлось скрипт на пару сотен строк переписывать, зная оба очень поверхностно… скрипт-то работает, а вот в скиллы не запишешь — несерьезно слишком для полноценного знания платформы.
Я лично крайне редко последние 5 лет сталкивался с разработкой GUI на С++… всё либо .NET, либо Java (для кросс-ллатформенного GUI). А C/C++ только на server-side или для системного программирования. Но это, наверное, просто кому как повезёт :)
Про QT я, естественно, знаю… чтоб не соврать только… первый раз ее году в 93-ем пробовал — такая куча дискет и суперские демки были…
Я обычно давал простейшую задачку на реверс строки… как только ее не решали — в одном случае четырьмя вложенными циклами, в другом двумерным массивом, в третьем перевыделяли строку на каждой итерации (теряя все содержимое).
Вторая задачка, которую я всегда давал С++ программерам, это написание оператора присваивания шаблонного класса-контейнера (вектора) — сразу все видно — часть просто не знала, что это, еще часть понятия не имела, как выделять память, еще часть не проверяла входной параметр на нули, подавляющее большинство забывало освободить старый указатель. Зато были единицы, с кем можно было поговорить про оптимизацию инициализации копий по умолчанию и обработку исключительных ситуаций в процессе копирования.
Собственно, это не значит, что мы принимали только последних. Если человек писал хотя-бы простой вариант решения, и при обсуждении адекватно реагировал на намеки на недостатки, то это уже был неплохой кандидат (обучаемый, по крайней мере).
1. бенчмарки на debug build делать бессмысленно, он не для скорости предназначен, а для максимума проверок
2. отключать проверки в debug build крайне нежелательно
Это не панацея, но всяко лучше ручной проверки пост-фактум.
Если есть инструменты лучше (и такие-же простые в установке/настройке) — делитесь опытом.
2. NoSQL или SQL? SQL в сравнении с NoSQL является супер-стандартным. Каждая NoSQL база данных имеет собственный API, собственный язык запросов, собственные правила работы с индексами, и кучу ограничений и особенностей.
3. без комментариев
4. ИМХО, очень частный и достаточно трудоемкий случай
Вопросы, описанные в статье, очень примитивны, и любой программер их должен знать (server-side, по крайней мере, а GUI формочки можно и без этого лабать)
Да, уже читаю про РРА… пожалуй, подождем…
Про QT я, естественно, знаю… чтоб не соврать только… первый раз ее году в 93-ем пробовал — такая куча дискет и суперские демки были…
А про GTK# не в курсе, забавно…
Вторая задачка, которую я всегда давал С++ программерам, это написание оператора присваивания шаблонного класса-контейнера (вектора) — сразу все видно — часть просто не знала, что это, еще часть понятия не имела, как выделять память, еще часть не проверяла входной параметр на нули, подавляющее большинство забывало освободить старый указатель. Зато были единицы, с кем можно было поговорить про оптимизацию инициализации копий по умолчанию и обработку исключительных ситуаций в процессе копирования.
Собственно, это не значит, что мы принимали только последних. Если человек писал хотя-бы простой вариант решения, и при обсуждении адекватно реагировал на намеки на недостатки, то это уже был неплохой кандидат (обучаемый, по крайней мере).