Точно так же и подумал, то есть команда должна быть монолитом с монотонными гребцами, под копирку 25-35 лет — если вдруг тебе 38 и ты гений github проектов — эх пролетел, если ты молодой гений и тебе 23, а начал ты в 11 — эх тоже мимо =)) А если, вдруг, ты еще и девушка с ярко крашенными волосами или дредами, которая кодит на С/C++ и жарит на Asm-e — не приближайся :trollface:
PS думается у «мелкого начальника» ЧСВ + неистовый страх, если придут гиганты ИТ, то быстро начнут его чмырить и естств получат собственный паритет власти. Так очень часто случается на практике, хотел суверенитет, а получил сюзиренитет ахахаха — pardon ç'est la vi.
Вы угадали мои мысли в MySQL есть например: LOAD DATA INFILE `filePath` INTO TABLE `tableName` выполняется кратно быстрее, как сравнивать O(n^2) с O(n), но заметил, что автор упомянул пункт 2) SELECT INTO OUTFILE `filePath` если быть точным.
Можно рассмотреть как альтернативу легковесной либы server+client, с разбором uri и возможностью создания дочерних процессов github.com/arthurkushman/php-wss
Доброго времени суток, благодарю за напоминание о swagger, собственно теперь OAS = swagger + raml, т.е. 2 группы разработчиков спецификаций объединились и организовали работу над OpenAPI Specification, она и вошла в мою разработку как новый и основной формат ввода данных.
Довольно странное явление, возможно когда-то на уровне модулей метод rules отработал в Middleware, на офф сайте laravel пишут, что правила должны быть размещены в Form Request — laravel.com/docs/5.7/validation#form-request-validation, возможно (а может и обязательно) мне придется рефакторить правила, спасибо за анализ.
Откровенно говоря, думал заюзать swagger, но как мне показалось у них упор был больше сделан все-таки на схемы, а мне нужен был именно yaml. Более того, описание типов и facets в raml показались мне простыми и понятными для восприятия. Учитывая популярность swagger есть возможность его конвертнуть в raml с помощью утилит, которые указаны в readme.
Да просто програйте в Atom под любой OS, у меня под MacOS и Ubuntu поддержка синтаксиса C/C++ type-hint, после просто g++ -std=c++11 -o hello hello.cpp. Для курсов достаточно, даже для мелких проектов на GitHub с Makefile вполне.
PS Страуструп есть его не может не есть
PSS Rust, Python, Go etc — temporary trendy things for fun boys, with fun clubs sometimes.
Микросервисная архитектура оправдывает себя на более высоком уровне, пример:
— сервис авторизации OAuth2
— биллинг
— процессинг
— СХД
— шина
как правило над подобными системами трудятся > 10 разработчиков.
Еще появились вот такие авто-генераторы API — raml-json-api, смысл которых в том, чтобы сцеплять формат описания входных данных и формат описания выходных данных в контексте фреймворка — в частности Laravel5.
Тотально согласен — 2017г и RAML активно развили до версии 1.0
Запрогал авто-генератор для Laravel, с поддержкой JSON API — https://github.com/RJAPI/raml-json-api
(Контрибы и предметная критика приветствуется)
PS Insanity is doing the same thing over and over again, expecting different results. Albert Einstein
По сему коллеги — давайте перестанем «кодить» свои велосипеды и начнем работать с качественными форматами представления входных/выходных данных и их описанием. (нисколько не отменяет попыток изобретать что-нибудь новое, академически весомое)
Привет бывшему коллеге, все верно — в тот период, когда API, в «организации», в которой мы трудились, разрабатывался о RAML-e не могло быть и речи, а swagger знали немногие. Помню даже, что написал авто-генератор, но под него надо было в бд описывать/складывать сущности, а так как всем было лень — никто его так и не заюзал =)
Сейчас прогресс ушел вперед — есть не только форматы описания, но и форматы вывода данных — JSON API например, откровенно говоря, устав от многолетних наблюдений вело-костылей — решил запрогать авто-генератор на основе RAML, с полной поддержкой JSON API (можно отключать) под Laravel5.x, в частности под laravel-module, если кому-нибудь интересно — https://github.com/RJAPI/raml-json-api (буду рад контрибам и предметной критике — развитие наше все).
Данный подход «сцепления» входных параметров на RAML-генератор и на выходе — JSON API сущностей, отлично прижился, в крупной компании (~1500чел.), в которой работаю сейчас, разрабатывали с 3-мя коллегами (программистами-инженерами), но тут пилили под Yii2.
Начну с того, что продукт хороший — наконец-то, на Российском рынке начали производить что-то подобное.
Так же замечу правильный выбор SQL-синтаксиса подобного MySQL — многие знают и долгое время использовали, что безусловно поможет в применении на практике разработчиками любого уровня.
Вопрос — выполнил запрос с загруженными данными в таблице ontime:
SELECT
OriginCityName,
count() AS c,
avg(DepDelay > 60) AS delays
FROM ontime
GROUP BY OriginCityName
HAVING c > 100000
ORDER BY delays DESC
LIMIT 20
У вас этот запрос выполнился с результатом:
20 rows in set. Elapsed: 0.546 sec. Processed 166.63 million rows, 4.36 GB (82.72 million rows/s., 2.17 GB/s.)
На моей машине — Intel® Core(TM) i7-3630QM CPU @ 2.40GHz, 4x2=8 logical cores RAM 16Gb/DDR3/1600, SSD KINGSTON SVP200S:
20 rows in set. Elapsed: 2.014 sec. Processed 166.63 million rows, 4.36 GB (82.72 million rows/s., 2.17 GB/s.)
Первое, что подумалось — может у них запрос был уже в кэше, выполнил повторно — результат такой же, в кэш (память heap/pile) не лезет. Соответственно, можно ли добавить запрос в кэш для достижения такого же результата, как в вашем примере или может конфиг подтьюнить как-нибудь? Все-таки разница ~ х4.
Тут речь как раз, именно, о multi-threading — основанной на самой популярной в *nix/C реализации Posix Threads.
На сколько мне память не изменяет — потоки создаются в контексте процесса и шарят память между собой.
То есть, запустили браузер — пошел процесс, а в нем уже threads.
Разница есть и она существенная, иначе парадигма существования thread-ов была бы обречена.
Так же есть отличные возможности lock/unlock мониторов (по-крайней мере в С), то есть anti-deadlock механики, ожидания завершений других потоков и т.д…
PS думается у «мелкого начальника» ЧСВ + неистовый страх, если придут гиганты ИТ, то быстро начнут его чмырить и естств получат собственный паритет власти. Так очень часто случается на практике, хотел суверенитет, а получил сюзиренитет ахахаха — pardon ç'est la vi.
github.com/arthurkushman/php-wss
должно быть
для удаления объявленного ранее макроса.
PS Страуструп есть его не может не есть
PSS Rust, Python, Go etc — temporary trendy things for fun boys, with fun clubs sometimes.
— сервис авторизации OAuth2
— биллинг
— процессинг
— СХД
— шина
как правило над подобными системами трудятся > 10 разработчиков.
Запрогал авто-генератор для Laravel, с поддержкой JSON API — https://github.com/RJAPI/raml-json-api
(Контрибы и предметная критика приветствуется)
PS Insanity is doing the same thing over and over again, expecting different results. Albert Einstein
По сему коллеги — давайте перестанем «кодить» свои велосипеды и начнем работать с качественными форматами представления входных/выходных данных и их описанием. (нисколько не отменяет попыток изобретать что-нибудь новое, академически весомое)
Сейчас прогресс ушел вперед — есть не только форматы описания, но и форматы вывода данных — JSON API например, откровенно говоря, устав от многолетних наблюдений вело-костылей — решил запрогать авто-генератор на основе RAML, с полной поддержкой JSON API (можно отключать) под Laravel5.x, в частности под laravel-module, если кому-нибудь интересно — https://github.com/RJAPI/raml-json-api (буду рад контрибам и предметной критике — развитие наше все).
Данный подход «сцепления» входных параметров на RAML-генератор и на выходе — JSON API сущностей, отлично прижился, в крупной компании (~1500чел.), в которой работаю сейчас, разрабатывали с 3-мя коллегами (программистами-инженерами), но тут пилили под Yii2.
Так же замечу правильный выбор SQL-синтаксиса подобного MySQL — многие знают и долгое время использовали, что безусловно поможет в применении на практике разработчиками любого уровня.
Вопрос — выполнил запрос с загруженными данными в таблице ontime:
У вас этот запрос выполнился с результатом:
20 rows in set. Elapsed: 0.546 sec. Processed 166.63 million rows, 4.36 GB (82.72 million rows/s., 2.17 GB/s.)
На моей машине — Intel® Core(TM) i7-3630QM CPU @ 2.40GHz, 4x2=8 logical cores RAM 16Gb/DDR3/1600, SSD KINGSTON SVP200S:
20 rows in set. Elapsed: 2.014 sec. Processed 166.63 million rows, 4.36 GB (82.72 million rows/s., 2.17 GB/s.)
Первое, что подумалось — может у них запрос был уже в кэше, выполнил повторно — результат такой же, в кэш (память heap/pile) не лезет. Соответственно, можно ли добавить запрос в кэш для достижения такого же результата, как в вашем примере или может конфиг подтьюнить как-нибудь? Все-таки разница ~ х4.
На сколько мне память не изменяет — потоки создаются в контексте процесса и шарят память между собой.
То есть, запустили браузер — пошел процесс, а в нем уже threads.
Разница есть и она существенная, иначе парадигма существования thread-ов была бы обречена.
Так же есть отличные возможности lock/unlock мониторов (по-крайней мере в С), то есть anti-deadlock механики, ожидания завершений других потоков и т.д…