Январский фуршет
-
Разработчик высоконагруженных веб-сервисов на C++. Отклик за микросекунду рулит! Алгоритмы, структуры данных, внутренности СУБД, noSQL, распределённые системы, BigTable, MapReduce, нейросети, немного другое машинное обучение, C++, Python, JavaScript, Go... Хорошо и доступно умею отвечать что-то на эти темы человеку, который вообще ни в зуб ногой.
-
На go небольшую систему сделать быстрее. Микросервис какой-нибудь. Плюс, есть модные фичи: например можно в коде описать структуру и напротив каждого поля структуры подписать как это поле уйдёт-придёт из JSON. Потоки, каналы и т.п. Быстро компилируется в самодостаточный бинарь. Писать небольшие микросервисы на Go, кажется, самое то. Но в силу большей взрослости, у C++ мощнее оптимизатор - говорят в машинном коде Go редко увидишь векторные инструкции и т.п. Когда захочется написать на Go код посерьёзнее, то очень захочется шаблонов и другого, что есть в C++ и чем он так известен - супермощная система абстракций, крайне эффективно выражающаяся в машинном коде. Иногда захочешь переиспользовать в Go-коде структуру, но поменять одно поле на другое. Тут бы подошёл шаблон (или "генерик" из Java) - но в Go придётся копипастить. В Go специально занижена мощность супермегакосмических абстракций, чтобы у хипстера не было соблазна упороться, а он делал свою работу ровно. C++ с точки зрения среднего наблюдателя даст не столько прирост в скорости исполнения кода (хотя где-то за счёт более совершенного оптимизатора это и скажется), сколько является гарантией что эта скорость будет максимальной при неограниченных возможностях выражать любые высокоуровневые сто-этажные опердени, т.е. вопрос в размерах и сложности логики разрабатываемой системы. Если надо получить микросервис, который жрёт JSON-ы в много потоков через HTTP, то Go вполне рулит.
-
Крайний случай - торговая платформа - одним концом она смотрит на 150 мировых электронных бирж, а с другого конца пользователь присобачивает свой модуль. Этот модуль реагирует на какие-то события на рынках и эту ракцию система должна доставить как можно быстрее. И модулей много. Система стоэтажная в смысле сложности - там внутри много всяких потоков данных и она должна быть расширяемой. Счёт там идёт на микросекунды. Менее суровый пример - всякие программы, дающие информацию для рисования главной страницы одноклассников: пока страницу нарисуешь нужно собрать много инфы: список постов, к каждому посту сколько у него лайков, какие комменты, сколько просмотров, сбоку нарисовать рекламу и список друзей, нарисовать число новых сообщений в личке и т.п. Каждая такая порция информации - это обращение к какой-то программе или базе данных. Страницу надо отдать максимально быстро, поэтому каждая из этих фоновых программ должна ответить за время стремящееся к нулю.
-
c++ может давать очень эффективный код в умелых руках, и очень неэффективный в неумелых. некоторые альтернативно одаренные граждане умудряются написать на c++ код, проигрывающий по скорости питону. ключ у "успеху" в этом направлении - использовать побольше разных всяких паттернов и позаботиться о том, чтобы программа на каждый чих делала несколько выделений/освобождений памяти на куче. беда в том, что путь с нуля до состояния "умелые руки" в случае c++ - очень длинный. про отклик за микросекунду я, кстати, не верю. микросекунда - это полторы-две тысячи ассемблерных команд. пара системных вызовов, необходимых, чтобы получить запрос и послать ответ, сожрут половину этого бюджета. остального не хватит, чтобы распарсить запрос, при нынешней моде делать запросы и ответы синтаксически сложными.
-
Как может быть индивидуальной скорость компилирования? В два раза - не очень понятно. Плюсы в два раза быстрее данные из апишек тянут? Или из базы? Или в два раза быстрее строят/фильтруют/группируют дтошки? Очевидно, что плюсы нужны в каких то особых задачах, в которых они дадут прирост скорости (и это явно не про дтошки). Я вот все пытаюсь понять - в каких задачах, в контексте веба, плюсы дадут профит? В контексте, например, геймдева мне все ясно. Но не с вебом, в котором задачи довольно специфичны, и под задачи которого го и был создан. Нужно признать, что тот же php на некоторых задачах, не уступает go по скорости отдачи. Правда уступает по памяти и максимальным коннектам (последнее не столь существенно, как правило). А, например, написать веб-сервер сравнимый с го на плюсах - это сама по себе не самая тривиальная задача.
-
Добавлю, что, например поиск авиабилетов у нас прекрасно работал на nodejs при нагрузке в 2 600 000 запросов в сутки. Каждый запрос порождает запрос в 5 гдс (систем бронирования). Дальше результаты подвергались разруливанию по 19000 правилам расчета комиссии, фильтрации, группировке и сортировке по ценам (один и тот же перелет в разных гдс мог стоить по разному) и черт знает чему еще. Все это добро жило на одном средненьком сервере в хецнере. На го хватило бы впс за 10$ на ДО и работало бы все раз в 5 быстрее. Хотя и на ноде очень шустро все вертелось. Зачем плюсы то?
-
Вопрос был о времени разработки или о скорости компилирования? Скорость разработки определяется скоростью разработчиков, и мало связана со скоростью компилятора. Два раза - это когда программа чего-то думает. Например, когда сам компилятор go переписали с C на go, он стал тормознее раза в два (хоть и все равно остался очень быстрым). Если же программа чего-то берет в одном месте и кладет в другое, и большую часть времени проводит в ожидании, пока это чего-то ей дадут или у нее заберут, совершенно все равно, на чем такая программа написана; ее вклад в общую скорострельность - около нуля.
-
Трудно сказать, надо знать изнутри конкретный проект. Греф лицо слишком высокого уровня, чтобы из его слов выцеплять что-то конкретное. "Обучение" в программах - это тоже реальность, скажем есть системы, которые находят признаки людей, которые не будут платить по кредиту или слишком быстро его закроют. Причём система найдёт такие признаки, о которых никакая тётенька не догадается. Система ищет закономерности только в тех данных, которые у неё есть. Например у неё могут быть ваши посты в соцсетях, история всех платежей с кредитки, история болезней и обращений в ментуру )
-
Про историю платежей с кредитки уже реальность) впринципе банки в основном и выдают кредиты на основе имеющихся у них данных : счетов, карт, справок, поступлений на счет, расходов. Про анализ соцсетей читал, даже микрозаймы какие-то внедряли. Про скоринг все понятно, там регулярно внедряют новое, но я все таки спрашивал про ИИ в юриспруденции,
-
Думать программы не могут. И обучаются они весьма специфически. Программа действительно работает по шаблонам, просто шаблоны изменяются полуавтоматически или совсем автоматически, и, конечно, сложность этих шаблонов зашкаливает. Плюс шаблоны применяются за очень короткое время к очень большим объемам информации (все посты во всех соцсетях, история платежей по всем кредитам/счетам/карточкам, история болезней ваша и всех близких, обращения в ментуру вас и ваших близких - обрабатывается за секунды).
-
Подмножества невозможны. Подмножество хоть как-то заметно отлючающееся от изначального языка будет сразу же признано отдельным языком, несовместимым с оригиналом. Например между python 2.7 и python 3.0 вагон срачей, хотя там никакой не отдельный диалект и невооружённым глазом даже отличий можно не заметить.
-
Курить надо понемного отовсюду что плохо лежит. Постепенно сложится своя общая картинка. Единого рецепта нет, по щелчку пальцев за 21 день не делается. Главное в процессе познания пытаться хотя-бы пересказывать познанное, пытаться делать мелкие эксперименты по мотивам познанного. Постепенно сложится в критическую массу и настанет просветление в один день - это будет резко и круто.
-
1. Как часто на продакшене / на тесте ловите segmentation fault и подобные крэши ? 2. Используете умные указатели или по старинке new / delete ? 3. Пользуетесь фишками шаблонов c++ чтобы в compile time что-нибудь преподсчитать (или сделать аналитику), или проект и без того нереально долго собирается ?
-
1. Ловятся регулярно, ну например раз в месяц или чуть реже. Особенно какая-то новая необкатанная софтина. Есть репликация - одна голова упала - на другую переключились, например. 2. Часто заворачиваем, где-то осталось незавёрнутое наследство. Где-то вообще наследство из malloc(). Где-то не заворачиваем из-за простоты и очевидности кода - мол "вот new вот рядом delete, чё ещё надо?" 3. Есть пара наших библиотек, который в compile time делают охрененные выстраивания всяких структур. Весь проект целиком мало кто собирает, собирают какой-то конкретный кусок для релиза. Есть разве что какие-то общие библиотеки, который юзаются в разных кусках. Пример куска - софтина для приёма и отдачи лайков (сердечко такое) - запоминает что и кто лайкнул, отдаёт число лайков для объекта, список лайкнувших.
-
Монга на наших нагрузках вроде как помрёт, но сама по себе реализует прикольную концепцию "JSON-это документ, который можно на лету менять". Для хипстеров хорошо подходит - наваять что-то на коленке и посмотреть как взлетит. Это прекрасная штука для прототипирования. Монга + Питон - это как лего для детей. Хипстеры любят когда можно в документ добавить новое поле, про которое не подумали раньше. Во многих SQL-базах добавить колонку в таблицу - это много времени, опасно, сложно и всё такое. Другое дело, что реальные данные в реальной жизни всегда имеют некую структуру и SQL применим в принципе абсолютно всегда и к нему можно свести любую уже работающую устоявшуюся базу в монге. Да и колонку добавить в некоторых решениях - ничего не стоит. У монги крутой движок хранения данных недавно стал - wired tiger. Lock-free там где-то понапихано, говорят быстрый на запись. Сам с монгой никогда плотно не работал, не могу назвать конкретных чисел. Cassandra не юзаем, возможно не было лишнего жиру посмотреть-потестить, своих таких велосипедов хватает видимо. Если сказать о себе, то люблю фиксированные структуры и статические типизации. Но если надо ради прикола писать ботов для форумов - возьму питон и либа PostgreSQL, либо монгу.
-
Нет шагов. Я вообще человек не рациональный, шагов никогда нет, есть сумбурное облако действий. Надо написать что-то на питоне - берём тупо и пишем. Если что-то не пишется - смотрим в доках/гугле/чатиках как оно по-пацански должно писаться. Можно почитать ужой код на этом языке, желательно выложенный на гитхаб серьёзной шарагой типа гугла (т.е. оно там прошло core review). Есть цель, а как я к ней прихожу я не запоминаю - просто интенсивно верчусь всеми способами одновременно)
-
Часто - хотим юзать несколько ядер в одном процесса - запускаем несколько потоков. Один поток принимает коннекты, расшифровывает протокол, извлекает команду, отдаёт свободному потоку. Есть готовый костяк для этого, но часто он не подходит под конкретное очередное решение. Но с потоками в C++ всё просто для грамотного разраба, некая примитивная хрень типа printf. Потоки вошли в станданртную библиотеку уже - std::thread, std::mutex, std::atomic - вот это всё.
-
Совершенно насрать как и на любые другие вирусы. Система типа гугла или вконтакта - довольно изолированная от внешнего мира, вы не можете заслать ей кусок кода, который она будет выполнять - даже JS. Она выполняет только то, что понаписали сами разрабы этой системы и выкатили в продакшн. Есть подразделения гугла, которые предоставляют виртуалки, в которых юзер может что угодно запустить, но там как я понял есть простые решения для этих херней типа рандомного перемещения адресов ядер и т.п. и это подразделение само по себе изолировано бетонной стеной от остальных систем.
-
То у вас перед сервером стоит балансировщик, то у вас нет фронтенда. Вы уж как-нибудь определитесь. Речь не про смену ЯП, а про то, что разделение сервера и бизнес-логики позволяет использовать в них разные ЯП. Ну, как, например, Apache, написанный на Си, может запускать программы, написанные на чем угодно, от баша до Си. В случае запуска внешнего процесса для обработки логики, если в нем, в этом рабочем процессе, произошла ошибка, то она будет перехвачена сервером, и в браузер вернется 500, остальные клиенты этого даже не заметят, и сервис продолжит обслуживать остальные запросы. В вашем же случае упадет весь сервер целиком и больше не поднимется. Это значит, что надо круглосуточно держать программиста, который в случае ошибки сможет ее найти и оперативно исправить. В это время ваш сервис будет недоступен. Чувствуете разницу?
-
Это всё слишком абстрактно из учебников по строительству сервисов. Про фронтэнд и балансировщик я ничё не понял. Есть у нас куски на php работающие под apache, куски на чём-то ещё под nginx и есть вот такие сервисы на C++, которые сами себе апач. Иногда C++ сервис принимает не HTTP-запросы из дикого интернета, а запросы по нашему бинарному протоколу от PHP-логики - есть разные варианты. Клиенту глубочайше пофигу вернулось ему 500 или потерялся коннект потому что всё упало - у него степень жопы одинакова - "нифига не работает". Да, падение одного скрипта и падение всего сервиса - разные вещи, но C++ код совсем уж дураки не пишут, просто больше требований по надёжности кода и умности разрабов. Он просто никогда не падает, а начал падать - откатили на предыдущую версию и основательно разобрались кто nullptr разыменовывает и где. Есть разные стадии тестирования и т.п. Короче, всегда имеется бинарь, проверенный годами, на который можно откатиться без разраба - типа как бинарь самого апача - нам же не нужен разраб апача.
-
Фронтендом я называю то, куда попадают клиентские запросы - на чей сокет браузер открывает TCP. Допустим, я заказал у вас веб-сервис, который кроме всего прочего обслуживает и мобильные приложения по HTTP. Вы его мне сделали на своем монолитном плюсовом движке. Дальше я хочу его поддерживать и развивать своими силами. Опубликованное мобильное приложение откатить быстро нельзя. Если на сервере возникла ошибка, затрагивающая API, то единственный способ поднять целиком упавший сервис, это исправить ее на сервере. Значит мне нужны как минимум три С++ программиста, не делающих ошибок и хорошо умеющих gdb, которые будут дежурить круглосуточно. Вы, как человек имеющий в штате подобного уровня специалистов, подскажите, пожалуйста, сколько сегодня они стоят?
-
Ну можно сделать по-разному. 1. Допустим мы понимаем, что наш бинарь очень безглючный и его одного хватит на всех - тогда мы можем выставить этот бинарь в дикий интернет. Можем пошардить несколько бинарей за nginx. 2. Мобильное приложение я бы проектировал так, чтобы оно работало с любой версией сервера - если сервер начал падать и его откатили на стабильный, то приложение пишет "сорян, данный подраздел фич временно недоступен". 3. Стоят они дофига, тыров 150-200 в месяц. А зачем три? Одного хватит. Да и нет такого, что в том же гугле какой-то C++ разраб что-то там оперативно исправляет и катит в прод. Систему надо проектировать и тестировать так, чтобы минимум радикальных нововведений в каждом релизе, чтобы физически она не умела разваливаться на куски сразу вся (поэтому сервисы - они "микро"-сервисы). Есть core review, когда один разраб может другому сказать "э слышь, чё это ты тут понаписал". В жизни, короче, мы видим что написанные на C++ сервисы гугла и яндекса годами нормально работают как-то.
-
Ну, 24 часа в сутках, 3 смены по 8 часов. Хайлоад он же не для домашней странички, тут простой денег стоит. А у вас вообще весь сервис лежит, а не какой-то кусочек. Ждать когда один программист проснется, проспится или вернется из отпуска мы не можем. Даже если взять вашу оценку, по которой приплюснутый сеньор стоит $3k, то за вашу экстравагантность я, как клиент, должен платить ежемесячно $10k. Плюс еще надо доплачивать за крутых мобильщиков, которые тоже без ошибок поддерживают обратную совместимость. А что взамен-то, ради чего все это?
-
Я не буду вам третий раз задавать вопрос про преимущества монолитного бинарника. Очевидно, ответ на него я не получу. Это и понятно - тот, кто может такое написать, писать не станет. Так как это все равно, что дрочить пасатижами: неудобно, опасно и, если люди узнают, то будут считать такого программиста мудаком. И я вижу, что быть в роли мудака вам не зазорно: - отсутствие логов; - программисты, пишушие безошибочный код; - падение сервиса целиком; вы готовы отстаивать какой-угодно бред, готовы выглядеть смешным и жалким, но не признаетесь, что лабание сайтиков на пхп, это единственный ваш опыт в сетевом программировании, и что вы просто по незнанию вляпались в этот монолитный бинарник, и теперь не представляете как из этого дерьма выбраться, не потеряв лица.
-
Чё-то у чувака взбомбировало. Сам apache не монолитный бинарник? У него, из-за его монолитности что, нет логов? А если у вас система nginx -> fastcgi -> daemon, то ошибки в daemon не приводят к простою сервиса? А если у вас ошибки в java или в php, реализующие бизнес-логику, то что, нет простоев сервиса и не нужен программист, который эти ошибки пофиксит?
-
Я ж говорю, что вы невежда. Апач не монолитный бинарник. Приходит запрос, апач его разбирает, определяет какую внешнюю программу запустить. Выставляет переменные окружения, запускает ее, на стандартный ввод этой программе отправляет параметры, со стандартного вывода читает заголовки и тело. Программа завершается. Это называется CGI. Еще апач умеет запускать программы на своем хосте через fastCGI. В этом случае внешняя программа запускается апачем при старте. Но она не умирает при каждом запросе, а в цикле обслуживает запросы. Но это тоже внешняя программа, она может быть написана на чем-угодно. С апачем ее связывает только то, что она работает в дочернем процессе апача. Кепочку мерять будете? (с)
-
Апач монолитный бинарник. Ну возьмите nginx, если множество .so делает бинарник у вас не монолитным. Апач монолитный. Я не говорил ничего про программы, которые эта монолитная программа "апач" умеет запускать. Из того, что апач монолитный, не следует, что он не умеет писать логи, страшнее глючит и чаще падает. А что если ваша внешняя программа под fastCGI падает при каждом запросе по причине той же ошибки, которую вы ждёте от быдлокодера монолитного бинаря? Что, в этом случае сервис прекрасно доступен и программист для фикса не требуется? А что, если та внешняя программа, написанная допустим на java, которую апач запускает для обработки запроса, падает при каждом запросе? Что, сервис доступен и программист для фикса не требуется?
-
Давайте-ка вы не будете теперь крутить хвостом. Вы "монолитом" называли логику обработки запросов, вкомпилированную в сам веб-сервер. Апач пишет логи от тех программ, которые он запускает, но не свои, в случае, если падает сам апач. Допустим, во внешней программе, запущенной через CGI, есть ошибка, которая при некоторых условиях кладет процесс, в котором эта вшеняя программа работает. Скажем, передали id=0, а программист не обработал подобную ситуацию. В этом случае манагер процессов увидит падение, запишет в лог, и поднимает эту программу снова во вновь порожденном процессе или потоке. Таким образом сервис остается работать. И даже этот же запрос но немного с другими параметрами будет обслужен. В вашем же случае упадет весь сервер целиком. Упадет и больше не поднимется. Получится, что запросы от злоумышленника обслужены не будут, а добросовестные клиенты будут обслужены как обычно. Не очень красивая ситуация, но такая "ошибка" может и подождать с фиксом. А у вас в такой же ситуации весь сервис будет недоступен.
-
Вы сказали что апач - не монолитен. А он монолитен. Почему-то я теперь кручу хвостом? Что мешает монолитной программе писать любые логи в каких угодно количествах? Почему мой сервис упадёт и больше не поднимется? Что мешает админам написать авто-подниматор, который запускает всё упавшее так же быстро, как бы это делал апач?
-
Про монолитность апача я вам уже все объяснял. Повторяться не интересно. Упавший процесс ничего уже писать не может. И к чему этот вопрос, если у вас вместо логов core dump. Забыли? Вы не понимаете разницы между отказом в обслуживании одного единственного запроса и всех выполняющихся в данный момент запросов (а на хайлоаде таких очень много), а потом еще поднятии целого сервиса - префорки, предварительное порождение потоков, коннекты к внешним сервисам, запуск интерпретаторов, если это скрипты, и т.п. С вашим профессиональным уровнем это не удивительно.
-
Я вам напомню. Я сказал, что при вашей схеме, когда не используется CGI, а логика пишеся прям внутрь сервера, нет логов. А вы ответили, что у вас вместо логов корка. Вот такая схема без CGI называется монолитной. И вы утверждаете, что у вас именно монолит. То есть, в контексте нашего разговора есть две схемы: CGI и монолит. И вы спросили "как же апач пишет логи, если он такой же монолитный?" Так вот: апач в данных терминах не монолитный, у него нет никакой логики приложения, вкомпилированной в сервер, у него CGI. Поэтому он и может писать логи от упавшего дочернего процесса, а нафантазированный вами сервер не может. Я вижу, вы уже начали косить под полного идиота. Вам идет.
-
А, ну логи-то есть. Но вместо логов у нас корка в критический момент. Чё там по этим логам поймёшь-то? Ну будет там URL запрошенный, этого часто мало. Мы привыкли брать кору и тупо смотреть. Логи есть, но при наличии коры они нам по барабану практически. "Апач в данных терминах монолитный" - это логическая задница. К апачу относится только httpd и всё вот это, а что он там для обработки запускает уже не входит в территорию "апач" и не относится к апачу. Т.е. апачу, будучи монолитной софтиной, которая умеет слушать http и запускать какие-то внешние приложения почему-то ничего не мешает работать круглосуточно и его мастер процессу ничего не мешает не падать в кору, а нашему приложению почему-то что-то должно помешать.
-
У апача только контрибуторов 70 человек хорошего уровня, обрабатывает он протокол, которому уже четверть века и пара релизов в год. У вас: пара упоротых джунов по $3k, ежедневно возникающие новые задачи и спринт максимум в неделю. Поэтому вероятность возникновения ошибок на сайте на несколько порядков выше. Про "CGI" и "монолит" я вам устал объяснять. Кажется, уже ребенок бы понял. У меня появляются сомнения в том, что вам даже на пыхе хватит мозгов писать. Такое ощущение, что вот вы вышли выступать в Большой Интернет, а уроки не сделаны.
-
У вас CGI? - нет. У вас логика в бинарнике веб-сервера. У апача CGI? - да. У него логика не в бинарнике веб-сервера. Витамины вам пить надо. Когда Сысоев начинал, это был примитивнейший сервер. Сейчас у него целая команда, и он нанимает сотрудников за очень приличные деньги, совсем не за $3k. Кроме количества я вам представил еще аргументы, главный из которых - постоянно возникающие новые задачи. То есть, постоянно пишется новая бизнес-логика, которую старые тесты не покрывают. В чем преимущества логики в бинарнике? Очень интересен ответ на этот вопрос. А-то вы каждый раз уходите от него, и делаете вид что у вас рожа не дерьме, а в повидле.
-
как вкатиться в подобного рода разработки? занимался программированием всякой всячины давным-давно, с тех пор занимался другими вещами. Есть вообще шанс переползти на программирование вот этого вот всего на фулл-тайм при наличии талантов? очевидно, что если даже сразу, с улицы примут на работу джуниором (или как там называется начальный ранг программиста), зарплата будет тысяч 20 максимум. При наличии семьи и прочих кредитов такой прыжок фиг удастся.
-
Либо через джуниора, правда джуниорам дают тысяч 50 а не 20 (в этом смысле я постоянно удивляюсь, почему все водители трамваев и дворники до сих пор не стали джуниорами), либо взять и сделать свой проект. Взять свою идею и тупо её делать. Например небольшая соцсеть для обмена ненужными вещами между людьми - и решать все сопутствующие задачи - регистрация, хранение сообщений, поиск и т.п.
-
Начиная со школы понемногу (в школе компа не было, первый комп купил себе курсе на первом). Это вопрос увлечённости, можно быстро вьехать при наличии человека у которого можно спросить и кто способен простыми словами изложить сложное. Высшая математика вообще никак не связана с программированием, примерно как наука о градостроении с программированием. Есть какие-то термины, понятия, которые из разных предметов вошли в программирование - типа там "архитектура". Вообще в умной голове границ между науками мало. Высшая математика понятна тому, кто хорошо умеет абстрактно мыслить (т.е. "конкретно и живо" думать о неосязаемых или невозможных вещах) и то же самое абстрактное мышление полезно в высшей математике, но освоение матана никак не гарантирует освоение программистского инженерного дела и наоборот.
-
Во всех этих местах код, который работает постоянно и много - это C++. Во вконтакте много голого С, ибо его упоротые олимпиадники писали - незнаю разгребли ли это наследие. В одлоклассниках Java вместо С++, видимо денег завались на лишнюю память и ЦП. Много юзают Python, Go, PHP и др. для разных сопутствующих вещей все эти конторы наверное. Python-создатель в Google работал, потом его выперли и заюзали Go, но Python остался. В яндексе тоже всё вперемешку - C++, Java, Python, Go - яндекс это просто не компания, а огромный набор как-бы маленьких компаний, там у каждого своё.
-
Сорри, NASDAQ - американская биржа, специализирующаяся на акциях высокотехнологичных компаний (производство электроники, программного обеспечения и т. п.). Одна из трёх основных фондовых бирж США. Наверное не очень удачный пример. А за eBay знаете? Если да, то вот про подобный сервис что можете сказать по поводу стека? Что бы вы использовали при создании с нуля?
