Gluttton

Мобильные ci7 от c2d отличает в первую очередь меньшее энергопотребление. И в ноуте оно гораздо важнее, чем всё остальное.

А по производительности любой хороший настольный камень пятилетней давности уделает любой ноутбучный с большим запасом.
И любая хорошая настольная видеокарта пятилетней давности уделает любую мобильную по всем параметрам.
И любой хороший монитор всё-равно приятней глазу, чем любой ноутбучный.
И любая нормальная клавиатура всё-равно удобней. И для маньяков есть даже маленькие клавиатуры с тачпедами.
И при этом оно всё не жарит руки, не гудит турбиной и не завтавляет или держать руки выше головы или сутулиться при обращении к кнопкам.

Ноуты не для высокой производительности делают и не для игр и не чтобы кино смотреть и не для удобства.
А чтобы можно было взять и унести.

Я считаю, менять железо чаще, чем раз в 3-5 лет — это потворство потребительским инстинктам и уплата дани транснациональным корпорациям. В общем, это плохая затея.

Хабрасила
Хабрасила (так же известная как Рейтинг) — ещё один параметр, которым можно хвастаться, помимо кармы и живота. Хабрасила есть у пользователей, компаний, хабов и вообще чего угодно. Секреты её подсчёта хабраредакции открыли пришельцы из созвездия Андромеды (до их прилёта даже хабраредакция не знала, как он рассчитывается). Время от времени пришельцы возвращаются и меняют принципы подсчёта, что может влиять на величину рейтинга отдельно взятых пользователей.

По слухам, Хабрасила пользователей рассчитывается по результатам последних 50 дней (не спрашивайте, почему) и постепенно «тает». Самый верный способ не дать ей растаять окончательно — регулярно проявлять на сайте положительную активность: например, публиковать хорошие топики и полезные комментарии.

Просто поточнее —

typedef unsigned long long ull;

inline ull rdtsc() {
	unsigned int lo, hi;
	asm volatile ( "rdtsc\n" : "=a" (lo), "=d" (hi) );
	return ((ull)hi << 32) | lo;
}

Вместо clock.
Могу написать статью, как мерить небольшие куски си-кода без всякой погрешности.

Они что-то крутят и что то не то.
У меня — Упало количество голосований за карму и комменты. Но рейтинг напротив вырос и значительно.
По моему они изменили функции расчёта того и другого.

Ага, я тоже заметил, но другое — у меня резко упал рейтинг. Как-то странно — он не мог у меня стать таким минусовым

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

Вам скорее на фриланс надо, или хотя изложить свой вопрос подробнее.

А почему именно С++, а не Java например?
Я так понимаю, нужен программист, сделающий инструментарий для нагрузочного тестирования?
Можно на ТЗ посмотреть?

В некоторых случаях использование SQL базы — overkill. Например если надо держать много «плоских» данных, с которыми если не проще, то быстрее работать курсорами, нежели запросами.

Или переход от ORM к объектно-ориентированным БД. получается несколько проще и логичнее, нежели отслеживать соответствие диаграммы классов с схемой БД. Миграции не панацея.

К примеру, многие разработчики предпочитают ORM (Object-relational mapping). NoSQL база (не любая, конечно) предоставляет нативный интерфейс для этой модели, ликвидируя осложнения от реляционной прослойки. В том числе для объектов с нефиксированным набором свойств. Из-за этого упрощается приложение, увеличивается производительность и облегчается шардинг. Естественно, NoSQL не является абсолютной панацеей и заменой SQL, но в некоторых решениях имеет более высокую эффективность и удобство, поэтому и находит там своё применение.

SQL базы данных затачиваются под универсализацию, те стараются предоставить разумный компромисс мжду скоростью записи и чтения. Это удовлетворяет потребности большинства энтерпрайз приложений, так как паттерн их использования как раз и заключается в «пописали/почитали». Плюс sql базы стремятся предоставить защищенноть данных, следуя принципам ACID, что опять же является критичным для ентерпрайза.

С друой стороны, есть задачи которым важно чтото определенное из всего набора. Например мы хотим бысто быстрои много писать, но можем пожертвовать скоростью чтения или свежестью данных. Или у нас объекты пишутся часто разной структуры, и мы хотим получать быструю их фильтрацию. Для всего этого традиционных подход sql создает ненужные обвязки, которые тормозят эти операции. И эти проблемы решают специализированные базы данных nosql

Могу оценивать со стороны MySQL и MongoDB. Помимо комментария выше, так хочу добавить, что MySQL очень медленно развивается в горизонтальном масштабирование. В монге же наоборот, это их сильная сторона — удобный, продуманный шардинг с failover репликацией в формате Replica Set. Это основной упор в высоконагруженных проектах.
Так же монга работает на js движке и всякие процедуры писать на много проще нежели в MySQL.
У монги самый адекватный и удобный PHP драйвер по сравнению с mysql, mysqli, pdo.
И да, инъекцию не реально сделать в монге из-за её формата BSON и адекватного драйвера (если, конечно, у вас весь запрос не берётся из урлы, например).
Так же важным плюсом в монге — её курсоры, которые действительно курсоры, а не имитация как в MySQL. Они (курсоры) действительно шагают по записям тогда когда поросят и могут жить столько сколько попросят, в мускуле, как правило, же всё сразу выгружается в память (поправьте меня, если это проблема драйверов).
Простота в использовании монги доставляет и подкупает.

Но есть «ложка дёгтя». У монги нет join-ов (хотя это может быть плюсом). И она ооочень прожорлива (дискового пространства). У неё операции над группировкой делается через map reduce, что не очень просто.

У SQL серьезные проблемы с действительно большими проектами: они очень тяжело кластеризуются как раз из-за реляционности.
Т.к. все таблицы БД пронизаны связями друг с другом, то распределение одной большой БД по узлам кластера ничего не дает, потому что любой запрос к такой системе приведет к тому, что данных, расположенных в одном узле, всегда будет недостаточно для формирования ответа, т.е. для выполнения каждого запроса у вас будет задействован весь кластер.

У NoSQL проблемы с консистентностью данных (т.е. отсутсвие тех самых ограничений, накладываемых реляционными БД), поэтому обеспечение консистентности ложится на уровень приложения. Но кластер для NoSQL — это органичная форма использования, для которой эти БД и создавались.

Каждый выбирает для своего проекта тот инструмент, преимущества которого перевешивают недостатки в данном конкретном случае.

NOSQL БД не становятся популярными, а занимают свою нишу.

NOSQL никогда не заменит реляционные SQL. Есть направления, в которых NOSQL эффективны, и есть другие направления, в которых SQL эффективна. Сейчас идёт процесс перераспределения сфер применения этих решений.

А почему они становятся популярными: они PRят себя (NoSQL компании как CouchBase, MemDB и т.п.), устраивают мероприятия (каждую неделю в Santa Clara какая-нибудь NoSQL конференция), но по-моему, немного «раздувают». И сейчас, как я вижу, это уже стало небольшим трендом. Но интересно, что до последнего момента Oracle очень консервативно не поддерживал NOSQL(прям как Microsoft с HTML5), а буквально полгода назад они обьявили на конференции в Сан Франциско(open world), что за NoSQL будущее.

SQL -реляционная БД. У них есть проблема с работы с очень большими объёмами данных при высокой нагрузке. Вот вроде и NOSQL будет решать подобные проблемы в том числе.

имхо препод неверно сформулировал вопрос, либо вы его неверно поняли. В SQL есть понятие синонимов, используемых в запросах вида SELECT. (Когда вместо таблички «это_самая_суперская_табличка» в запросах участвует упрощенное наименование. Больше мой опыт не подсказывает мне использования слов «полностью идентичный» в отношении оператора «SELECT». SQL — простой язык и спецификацию по нему нагуглить достаточно просто.

Это не резюме. Это сочинение на тему «Как я провел жизнь, и хочу рассказать об этом людям»
Вы спрашиваете — нормальная ли форма изложения? Имхо для резюме недопустимая. Складывается ощущение, что у Вас большие проблемы с самоутверждением и с помощью данного резюме Вы пытаетесь отыграться.

На какую должно вообще претендуете?

«Опыт работы с надежными \ высоконагруженными приложениями » это что? Умеете почтой на gmail`e пользоваться? Здорово.

Ну и очевидные вещи в минусы писать — моветон.

Я понимаю почему Вы сделали именно такое резюме, ибо для 20 лет трудового опыта умений и навыков — маловато. Или Вы их тщательно скрыли. Но я бы на Вашем месте сделал резюме «по канонам» — и разбавить его «авторскими моментами». А простыню эту прибрать для собеседования.