as discussed in slack i've written down my thoughts on a more dynamic config and what it could be good for to open the discussion. depending on the inputs i'd be happy to research more.
as more and more setups use cluster orchestration frameworks (such as e.g. kubernetes), h2o makes an excellent candidate for a loadbalancer / ingress controler. however in this type of setup, whenever a new new service is deployed the loadbalancer needs to be quickly updated
# Maintainer: Yannick Koechlin <yannick.koechlin@tamedia.ch> | |
pkgname=h2o-future | |
pkgver=r3959.4bc17f98 | |
pkgrel=1 | |
pkgdesc="Optimized HTTP server with support for HTTP/1.x and HTTP/2. git version with extra gems" | |
arch=('i686' 'x86_64') | |
depends=('libuv' 'libyaml' 'wslay' 'zlib' 'sqlite3' 'leveldb' 'hiredis' 'librdkafka-git' 'nghttp2' 'curl' 'mbedtls') | |
makedepends=('cmake' 'libtool' 'make' 'pkg-config' 'ruby') | |
url="https://github.com/h2o/h2o" |
#include "module.h" | |
#define MP_SOURCE 1 /* define in a single .c/.cc file */ | |
#include "msgpuck.h" | |
// https://tarantool.org/doc/tutorials/c_tutorial.html?highlight=stored%20procedure | |
// CPATH=/usr/include/tarantool/:/usr/include/ gcc -shared -o hardest.so -fPIC hardest.c | |
char * key_format = "the quick brown fox jumped over the lazy dog the qu %07u ick brown fox "; | |
char * field_2 = "'{\"0\":{\"1234567890\": 320, \"1234567890\": 1303}}'"; |
Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.
My 3 developers team has just developed React.js application with 7668
lines of CSS (and just 2 !important
).
During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.
Here are main principles we use to write CSS for modern (IE11+) browsers:
- SUIT CSS naming conventions + SUIT CSS design principles;
- PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
- Flexbox is awesome. No need for grid framework;
- Normalize.css, base styles and variables are solid foundation for all components;
upstream www { | |
server 127.0.0.1:9999; | |
} | |
upstream redis { | |
server 127.0.0.1:6379; | |
keepalive 1024; | |
} | |
lua_shared_dict srcache_locks 100k; | |
server { |
You don't really need a framework or fancy cutting-edge JavaScript features to do two-way data binding. Let's start basic - first and foremost, you need a way to tell when data changes. Traditionally, this is done via an Observer pattern, but a full-blown implementation of that is a little clunky for nice, lightweight JavaScript. So, if native getters/setters are out, the only mechanism we have are accessors:
var n = 5;
function getN() { return n; }
function setN(newN) { n = newN; }
console.log(getN()); // 5
setN(10);