jueves, 27 de abril de 2017

Pipeline arquitectures

Lately I've been developing a real time stream application, that delivers content via http long poll requests.

The details of the inner parts are not important, but overall, you can see it as many other applications, which transform, filter and distribute individual pieces of datastructures.  On the macro level, different components are connected via ZMQ or rabbitMQ, or any queuing system you like. Heck, you could use resque/sidekiq for that also.

Inside the components, although I like to use CLOS OOP (for it's inspection capabilities, and sometimes multiple dispatch), there's the idea of pipelines (or streams) which I like very much.

Here are some pointers for this approach I'd like to review:

-  Rob Pike talks. I love this one, which tells the difference about concurrency and parallelism. Also go concurrency patterns. I guess this one is also cool, but I haven't actually seen it, it just has a cool name.
- Talk about pipes in OCaml. This one isn't particularly enligthening if you have some knowledge of streams, as in SICP streams, but it gives a vision for functional programmers.
- Anything you find about pipeline arquitecture is ok.
- Thanks to native coroutines, lua provides nice uses and docs for pipelines. Also picolisp has support for coroutines.
- Full on functional. Coroutines for streaming in haskell.
- HighScalability article about disqus architecture.
- Also, using just active objects is a nice approach to, at least split responsabilities, and make the producer-consumer dance work. Kudos to the great CTM book that explains them super nicely.

martes, 25 de abril de 2017

debugging dns with dnsmasq

I'm not specially gifted at debugging network issues, but I try my best, and lately it seems I have to fight networks quite often.

This is how to debug dns queries using dnsmasq. Dnsmasqhas many many flags and options, but  with this I could log when requests are done, and their responses, so it gives you an understanding of what's happening under the hood.

  dnsmasq -k -q -h -R --server=8.8.8.8 --log-facility=-


Speaking about dns, here's a recent post by spotify, with more than you ever wanted to know about dns :)


sábado, 22 de abril de 2017

Tcl, Red, Nim, Spry, Wren and Gravity

On random walks around the internet, I'm always looking for a language that can provide me the easiness of use of shell languages (and pipes, don't forget pipes), but with more flexibility. I'm still using zsh (and trying to sneak picolisp and factor), but here are the new contenders/discoveries.

I found Red, which looked super interesting. Very smalltalkish, and with very good support for windows GUI programming and interacting with the outside world. I haven't done anything beyond the classical "hello worlds", "factorials", "guess number"... It looks very cool though. It probably has 0 libraries, but well, you can't have it all.  Refinements look very cool. no idea how they are implemented, but it's a really nice idea.

Tcl, which you usually read that is something like a 'bad joke', because everything is a string.  But since I read that antirez's article I think it has something to it.

Nim, is probably the language with more share of all the ones listed here. It's nice and cute, and compiles to native, or js (multiple backends always look cool). Although I'm learning C myself because it's one of the fundamental languages one has to know, nim looks like a useful alternative for more practical purposes. It supports lots of modern idoms (map, filter,.. reduce...) and practices (channels, etc..). And also has support for macros (shown in the link to convert a bf interpreter to a compiler).

Spry, is a language created by Goran Krampe, that smalltalk wizard. It's implemented in Nim, and has ideas from Lisp, Rebol, Forth and Smalltalk. It looks very nice, but it's just a toy for now.

Wren and gravity, both small, with ideas from Lua/smalltalk/erlang.

And in wren performance page, there's this paragraph:

"Tested against Lua 5.2.3, LuaJIT 2.0.2, Python 2.7.5, Python 3.3.4, ruby 2.0.0p247. LuaJIT is run with the JIT disabled (i.e. in bytecode interpreter mode) since I want to support platforms where JIT-compilation is disallowed. LuaJIT with the JIT enabled is much faster than all of the other languages benchmarked, including Wren, because Mike Pall is a robot from the future."


Mike Pall is a robot from the future.

jueves, 20 de abril de 2017

Logs, metrics and what to log.

Lately I've had to decide (and give some advice)  on logging and metrics.  I'm learning a lot as I go, but I think I'm starting to get some kind of grip of what should be what, and on what level.

Here's this link about logs vs metrics, which makes lots of sense. 

And also, a post about logging levels, and how a very basic rule serves for it deciding which level means what. Very useful info in the associated reddit thread.

  • DEBUG: information that is useful during development. Usually very chatty, and will not show in production.
  • INFO: information you will need to debug production issues.
  • WARN: someone in the team will have to investigate what happened, but it can wait until tomorrow.
  • ERROR: Oh-oh, call the fireman! This needs to be investigated now! 
Also, tools: lnav , oklog.

miércoles, 19 de abril de 2017

k/Apl info

  • APL self hosted compiler https://news.ycombinator.com/item?id=13797797
  • APL self hosted compiler screencast https://www.youtube.com/watch?v=gcUWTa16Jc0 
  • q manual http://code.kx.com/q4m3/
  • ok manual https://github.com/JohnEarnest/ok/blob/gh-pages/docs/Manual.md
  • k main page http://kparc.com/
  • kona https://github.com/kevinlawler/kona

domingo, 16 de abril de 2017

quote a day, some factor code and some bash+pup+jq

For todays hack, I wanted to have some tiny app that would display a quote/sentence/link at random. Basically, the same as the "fortune" unix command.

In principle it should be trivial, it's just picking a random quote from a huge file.

The idea of doing it in factor was, well... to be able to do anything at all in factor, as most of my previous attempts failed to produce anything that even did what I expected. The tiny repo is in github.

What made Xerox PARC so special?

Via Hacker News, I found this cool answer by Alan Kay about "What made Xerox PARC so special?"

Very nice, and I got a couple of book references I'm already pushing in my to-read.

EDIT: I just read that Bob Taylor has died today at 85. :(

sábado, 1 de abril de 2017

TIL: Amazon Nat Gateway drops your connections after 5 mins idle

Yes, after many hours of head scratching, I found out that if you're inside an amazon VPC, and use a NAT gateway or a NAT instance as your internet gateway, silent connections for more than 5 minutes will be dropped, or, even "better", just silenced, but you won't notice anything, just silence.

For long streaming connections going 'mute' for maintenance, you won't recover automatically.


WOW: Is it possible that in 2024, I just hit this again?


I found the info here of what I hit back on 2017:
https://repost.aws/knowledge-center/vpc-troubleshoot-nat-gateway-connection
https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html

text:

IdleTimeoutCount error to release capacity

If a connection that uses a NAT gateway is idle for 350 seconds or more, then the connection times out. You also will see a spike on the IdleTimeoutCount metric. When a connection times out, a NAT gateway returns an RST packet to any resources behind the NAT gateway that attempt to continue the connection. The NAT gateway doesn't send a FIN packet.

To resolve or work around the IdleTimeoutCount error, complete the following tasks:

  • Use the IdleTimeoutCount metric in Amazon CloudWatch to monitor for increases in idle connections. Make sure that you configure CloudWatch Contributor Insights to get visibility on the top contributors of clients with processes in the Idle state.
  • Close idle connections from clients to release capacity.
  • Initiate more traffic over the connection.
  • Turn on TCP keepalive on the instance with a value that's less than 350 seconds.