чтоб не писать статьи а-ля первый урок php, я специально завел свой блог. Многих переубедить что и как делать в определенных условиях практически не возможно. А бороться с ветряными мельницами — нет времени
на счет говнокода — ты конечно прав. Я сам смотрю на свой код, написанный пару лет назад и ужасаюсь… Но, в статье больше про архитектуру кода, а не его запахи.
Что касается MongoDb — есть опыт внедрения пары проектов. Очень требовательна к ресурсам и много жрет дискового пространства. На виртуальной машине в РАМ 2Гб — на 1М профилях начинает тупить. Для определенного круга задач — идеальное решение. В данном случае — она (монга) значительно проигрывает по скорости.
для большей производительности, я бы реализовал в UDF
поточнее и побыстрее будет
static const double DEG_TO_RAD = 0.017453292519943295769236907684886;
/// Earth's quatratic mean radius for WGS-84
static const double EARTH_RADIUS_IN_METERS = 6372797.560856;
/** Computes the arc, in radian, between two WGS-84 positions.
*
* The result is equal to <code>Distance(from,to)/EARTH_RADIUS_IN_METERS
* 2*asin(sqrt(h(d/EARTH_RADIUS_IN_METERS )))
*
* - d is the distance in meters between 'from' and 'to' positions.
* - h is the haversine function: <code>h(x)=sin²(x/2)
*
* The haversine formula gives:
* h(d/R) = h(from.lat-to.lat)+h(from.lon-to.lon)+cos(from.lat)*cos(to.lat)
*
* http://en.wikipedia.org/wiki/Law_of_haversines
*/
double ArcInRadians(const Position& from, const Position& to) {
double latitudeArc = (from.lat - to.lat) * DEG_TO_RAD;
double longitudeArc = (from.lon - to.lon) * DEG_TO_RAD;
double latitudeH = sin(latitudeArc * 0.5);
latitudeH *= latitudeH;
double lontitudeH = sin(longitudeArc * 0.5);
lontitudeH *= lontitudeH;
double tmp = cos(from.lat*DEG_TO_RAD) * cos(to.lat*DEG_TO_RAD);
return 2.0 * asin(sqrt(latitudeH + tmp*lontitudeH));
}
/** Computes the distance, in meters, between two WGS-84 positions.
*
* The result is equal to <code>EARTH_RADIUS_IN_METERS*ArcInRadians(from,to)</code>
*
* ArcInRadians
*/
double DistanceInMeters(const Position& from, const Position& to) {
return EARTH_RADIUS_IN_METERS*ArcInRadians(from, to);
}
что такое «чистый код» каждый понимает по своему и это хорошая тема для флейма. Я всегда был врагом излишней патернизации в угоду производительности, так как основная специфика — это высоко-нагруженность.
И правильно сказал автор, что Фаулер царь и бог только в своем классе разработки приложений.
По большей части — паттерны нужны, но когда точно знаешь, что проект заточен под MySQL/PgSQL и тип БД меняться точно не будет — нет смысла наворачивать на класс общения с БД Адаптер. Другое дело — коробочный вариант…
Я тут недавно пообщался с некоторыми тимлидами, которые готовы в паттерны завернуть все что угодно. Особенно увлечены ОРМ. Но, если выкинуть 35-45% кода, то он все равно решит эту же задачу. Так зачем платить больше, если ждем диких нагрузок? Хотим производительности от БД на больших объемах — шардим данные… А если шардим данные, то какого черта завязываемся на ОРМ, архитекторы хреновы :(…
сорри — наболело…
concurrency Level: 50
Time taken for tests: 0.745 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 84000 bytes
HTML transferred: 21000 bytes
Requests per second: 1342.95 [#/sec] (mean)
Time per request: 3.723 [ms] (mean)
Time per request: 0.745 [ms] (mean, across all concurrent requests)
Transfer rate: 110.16 [Kbytes/sec] received
спасибо за статью.
когда-то делал музыкальный сайт (и еще применят такой подход в интернет магазине), помню как делал парсер запросов и так же выделял из запроса ядро и прочие. аттрибуты и в соответствии с «формулой запроса» осуществлял поиск. Конечно в поисковике все это сложнее, но основные идеи можно использовать и в сайтостроении.
>На очередной встрече с булочниками…
А на встречи булочников с Главой… ты погон у булочников случайно не заметил? Ну, вообще-то перед телекамерами они их уже успели снять…
в остальном все как бы не печально, но истинно реально… Мои похождения не так обширны, тоже общался с разными бизнес-инкубаторами и ты полностью прав…
булки, не приносящие прибыль вчера — никому не нужны
булки, не имеющие нового сегмента рынка — ни кому не нужны
какой бы ты не был крутым булочником-кулинаром, ты можешь только представлять только интерес, как резерв рабочего на хлебопекарном конвеере.
если есть лишние булки, почему бы себе не урвать лакомный кусок?
Думаю можно поставить хорошую лабораторную по оптимизации участков кода OpenSource или даже сделать курсовик на базе реального проекта.
Только кому это надо… У преподов уже написаны планы лекций и лабораторных и все как по маслу… Все обкатано, а сделать что-то полезное не только студентам — это влом. Возможно в этом виновата система образования или «маленькая» относительно среднего программиста з.п.
Программа Google Summer, как раз нацелена на развитие OpenSource проектов силами студентов и аспирантов.
У меня было желание пойти преподавать или организовать курс практических лекций… только времени уйдет больше, а денег увы… Так что это и осталось идеей. Может быть когда-нибудь (на пенсии)
Я не переводчик, у меня нет ни одной переводной статьи, но есть небольшой опыт написания собственных…
Не надо делать дословного перевода.
В хорошем переводе, нужно понять суть фразы и пересказать её своими словами. Тогда он будет понятен и тебе и всем.
Что касается MongoDb — есть опыт внедрения пары проектов. Очень требовательна к ресурсам и много жрет дискового пространства. На виртуальной машине в РАМ 2Гб — на 1М профилях начинает тупить. Для определенного круга задач — идеальное решение. В данном случае — она (монга) значительно проигрывает по скорости.
поточнее и побыстрее будет
static const double DEG_TO_RAD = 0.017453292519943295769236907684886;
/// Earth's quatratic mean radius for WGS-84
static const double EARTH_RADIUS_IN_METERS = 6372797.560856;
/** Computes the arc, in radian, between two WGS-84 positions.
*
* The result is equal to <code>Distance(from,to)/EARTH_RADIUS_IN_METERS
* 2*asin(sqrt(h(d/EARTH_RADIUS_IN_METERS )))
*
* - d is the distance in meters between 'from' and 'to' positions.
* - h is the haversine function: <code>h(x)=sin²(x/2)
*
* The haversine formula gives:
* h(d/R) = h(from.lat-to.lat)+h(from.lon-to.lon)+cos(from.lat)*cos(to.lat)
*
* http://en.wikipedia.org/wiki/Law_of_haversines
*/
double ArcInRadians(const Position& from, const Position& to) {
double latitudeArc = (from.lat - to.lat) * DEG_TO_RAD;
double longitudeArc = (from.lon - to.lon) * DEG_TO_RAD;
double latitudeH = sin(latitudeArc * 0.5);
latitudeH *= latitudeH;
double lontitudeH = sin(longitudeArc * 0.5);
lontitudeH *= lontitudeH;
double tmp = cos(from.lat*DEG_TO_RAD) * cos(to.lat*DEG_TO_RAD);
return 2.0 * asin(sqrt(latitudeH + tmp*lontitudeH));
}
/** Computes the distance, in meters, between two WGS-84 positions.
*
* The result is equal to <code>EARTH_RADIUS_IN_METERS*ArcInRadians(from,to)</code>
*
* ArcInRadians
*/
double DistanceInMeters(const Position& from, const Position& to) {
return EARTH_RADIUS_IN_METERS*ArcInRadians(from, to);
}
cp /dev/null [filename]
И правильно сказал автор, что Фаулер царь и бог только в своем классе разработки приложений.
По большей части — паттерны нужны, но когда точно знаешь, что проект заточен под MySQL/PgSQL и тип БД меняться точно не будет — нет смысла наворачивать на класс общения с БД Адаптер. Другое дело — коробочный вариант…
Я тут недавно пообщался с некоторыми тимлидами, которые готовы в паттерны завернуть все что угодно. Особенно увлечены ОРМ. Но, если выкинуть 35-45% кода, то он все равно решит эту же задачу. Так зачем платить больше, если ждем диких нагрузок? Хотим производительности от БД на больших объемах — шардим данные… А если шардим данные, то какого черта завязываемся на ОРМ, архитекторы хреновы :(…
сорри — наболело…
может кому пригодится
Производительность на тестовом двухядерном старом сервере
PERFORMANCE
ab -c 50 -n 1000 10.0.0.1:8080/xxx/q2
concurrency Level: 50
Time taken for tests: 0.745 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 84000 bytes
HTML transferred: 21000 bytes
Requests per second: 1342.95 [#/sec] (mean)
Time per request: 3.723 [ms] (mean)
Time per request: 0.745 [ms] (mean, across all concurrent requests)
Transfer rate: 110.16 [Kbytes/sec] received
а так же perl, ruby, python & PHP.
сам являюсь автором модуля PECL PHP pecl.php.net/package/amqp
www.rabbitmq.com/devtools.html
github.com/ruby-amqp/amqp/
pypi.python.org/pypi/amqp
все что нужно покупаю в электронных магазинах,
и у них часто бывают свои акции.
— до 20 ms в среднем 5 -7 на AJAX
— до 40 — 50 ms на отдачу сервером страницы
зачет
увидеть бы модель интерактивно :)
когда-то делал музыкальный сайт (и еще применят такой подход в интернет магазине), помню как делал парсер запросов и так же выделял из запроса ядро и прочие. аттрибуты и в соответствии с «формулой запроса» осуществлял поиск. Конечно в поисковике все это сложнее, но основные идеи можно использовать и в сайтостроении.
ждем продолжения про условные переменные
А на встречи булочников с Главой… ты погон у булочников случайно не заметил? Ну, вообще-то перед телекамерами они их уже успели снять…
в остальном все как бы не печально, но истинно реально… Мои похождения не так обширны, тоже общался с разными бизнес-инкубаторами и ты полностью прав…
булки, не приносящие прибыль вчера — никому не нужны
булки, не имеющие нового сегмента рынка — ни кому не нужны
какой бы ты не был крутым булочником-кулинаром, ты можешь только представлять только интерес, как резерв рабочего на хлебопекарном конвеере.
если есть лишние булки, почему бы себе не урвать лакомный кусок?
Думаю можно поставить хорошую лабораторную по оптимизации участков кода OpenSource или даже сделать курсовик на базе реального проекта.
Только кому это надо… У преподов уже написаны планы лекций и лабораторных и все как по маслу… Все обкатано, а сделать что-то полезное не только студентам — это влом. Возможно в этом виновата система образования или «маленькая» относительно среднего программиста з.п.
Программа Google Summer, как раз нацелена на развитие OpenSource проектов силами студентов и аспирантов.
У меня было желание пойти преподавать или организовать курс практических лекций… только времени уйдет больше, а денег увы… Так что это и осталось идеей. Может быть когда-нибудь (на пенсии)
Я не переводчик, у меня нет ни одной переводной статьи, но есть небольшой опыт написания собственных…
Не надо делать дословного перевода.
В хорошем переводе, нужно понять суть фразы и пересказать её своими словами. Тогда он будет понятен и тебе и всем.