Пользователь
«Effective Kafka: A Hands-on Guide to Building Robust and Scalable Event-Driven Applications», «Kafka: The Definitive Guide» и другие издания.
В этой статье я расскажу, как изучал Apache Kafka и с какими трудностями столкнулся. Я очень надеюсь, что мои наблюдения помогут тем, кто ещё только приступает к знакомству с платформой. Здесь мы обсудим полезные ресурсы, в основном, книги, которые я прочитал, и мой опыт с платформой#nbsp;— до чтения книг и после.
Маркеры — дело полезное. Полезное в разумных количествах. Когда их становится слишком много, польза улетучивается. Как поступить, если требуется отметить на карте поисковую выдачу, в которой десятки тысяч объектов? В статье я расскажу, как мы решаем эту задачу на WebGL-карте без ущерба для её внешнего вида и производительности.
Это короткая, но достаточно полезная статья для продолжающих разработчиков о итераторах в Javascript.
/*
* @include triangle within a pseudo element and add positioning properties (ie. top, left)
* $direction: up, down, left, right
*/
@mixin triangle($direction, $size: 6px, $color: #222){
content: '';
display: block;
position: absolute;
height: 0; width: 0;
@if ($direction == 'up'){
border-bottom: $size solid $color;
border-left: 1/2*$size solid transparent;
border-right: 1/2*$size solid transparent;
}
@else if ($direction == 'down'){
border-top: $size solid $color;
border-left: 1/2*$size solid transparent;
border-right: 1/2*$size solid transparent;
}
@else if ($direction == 'left'){
border-top: 1/2*$size solid transparent;
border-bottom: 1/2*$size solid transparent;
border-right: $size solid $color;
}
@else if ($direction == 'right'){
border-top: 1/2*$size solid transparent;
border-bottom: 1/2*$size solid transparent;
border-left: $size solid $color;
}
}
Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.
doSomething().then(function () {
return doSomethingElse();
});
doSomething().then(function () {
doSomethingElse();
});
doSomething().then(doSomethingElse());
doSomething().then(doSomethingElse);
Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.
