The first idea that hits is that such a thing could make (very) good use of a mixture of decaying lists and LRU ordering; probably much like tc's ring priority works, a decaying list could rise and fall in ordering based on some measure of recency, and an assessment/overview of the most-recent (most-hit, in this worldview) could be used to extend storm control measures

An idle thought while reading some recent writing from the war-weathered Ivan Pepelnjak: why, in the age of multi-gigabit hash-distribution-capable load balancers (and application routers and openflow and and and) do we still have storm control that turns off a whole port/path instead of just not forwarding a specific type of traffic?

The subject of this stream (and all it relates to) is all pretty damn obvious in retrospect, of course.

Maybe some of these lessons might've been learned by just reading C-based tutorials? Let's think about that...

Allons-y!

Something to aim for is to impart knowledge, not information.

The latter is best found in reference manuals. The former is the thing that will allow a person to use your tool/product/whatever.

"Documentation is where information goes to die", to steal a quote from jerith.

Make sure that you revisit what you write in documentation as often as you revisit the thing you're changing.

jml started a good series with some documentation themes earlier today; I figured I'd contribute another few ideas. The most immediate one comes up as a further point to the reposted card: your documentation should be based on where the other person begins

To clarify that a bit: find the crossover between implicit and necessary knowledge. "Setting up a vhost", for instance, presumes knowing what a vhost is

(this can be catered to the so-called target market consumers of the thing you're documenting)

Writing something out is an immensely valuable mental exercise. I find it clarifies thought, reveals areas of ignorance, and exposes assumptions.

But writing something for someone else? For a total stranger? That is both much more work and a very different kind of work.

Explain the motivation/reasoning. Understanding why a thing is the way it is becomes a powerful stepping stone to using it better

[first update in a while] If you're out to build your own path, and you're still on the way out, you'll likely wonder if you'll be okay. Turns out, you will be. There's a lot of demand for clueful people.

A couple of UNIX "Golden Rules" go a long way to leaving a good legacy. You leave a legacy regardless, though, so it's up to you to choose what you leave.

Institutional memory, by itself, strikes me as somewhat of a sham. As a good friend of mine once said, "documentation is where information goes to die." Institutional knowledge is the far more important structure.

You (often) leave a lot behind. Moreso than you might have thought. The more singular your position (or, perhaps, the lower your bus factor), the more nuanced it becomes.

Lesson 3

Remember to implement the checksums (if there are some)! This will help in the following cases:

• your protocol doesn't have a clearly defined end-of-message marker
• chances are that your message might also have the header in the payload data, in which case our aforementioned findData && badMessage structure would break down

For either of these cases, you could attempt a parse and know whether you have a valid message or not. This would then roughly become like so:

def validate(data):
    messageOffsets = findMessages(data)
    if messageOffsets[1] < messageLength:
        try:
            parseMessage(data[:messageLength])
            return data[:messageLength]
        except badDecode:
            return failure
    else:
        """ validation here """
        if data[0:4] == '\x01\x02\x03\x04':
            return data[:messageLength]

Lesson two

hd(1) is your friend.

elegua% echo hello | hexdump -v -e '/1 "%02X "'   
68 65 6C 6C 6F 0A

elegua% hd -n 32 example      
00000000  05 02 01 01 54 00 75 02  56 00 80 02 28 00 2d 00  |....T.u.V...(.-.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

elegua% hd -s 17 -n 16 example
00000011  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

elegua% hd -s 12 -n 10 example
0000000c  28 00 2d 00 00 00 00 00  00 00                    |(.-.......|

In this way you can read any given file offset you need to, to see what's wrong where (like in the case of data being too short).

Note: hd is an alternate binary name for hexdump

If you forget lesson one, you are in for a whole lot of pain. None of your following data will make any sense whatsoever.

Wrong assumption number one

Validating the start of data, and then reading forward for the fixed packet/data length

Why this is wrong

Corruption comes in all flavours, including too-short messages in the datastream. Validate with a window of n>=2 that reading your normal message length doesn't eat into the start of a next message.

Example

Assuming our first 4 bytes identify a message, and writing some python-esque pseudocode (where function or variable names are not written, consider them already implemented for the example case)

def validate(data):
    messageOffsets = findMessages(data)
    if messageOffsets[1] < messageLength:
        return badMessage
    else:
        """ validation here """
        if data[0:4] == '\x01\x02\x03\x04':
            return data[:messageLength]

Recently having a requirement to do some stuff with a packed/binary protocol, and not being the greatest fan of C (or rather, the effort involved with, and the userland around it), I decided to use Python and the relatively excellent Construct library for this.

pip install construct after initializing a venv, fire up some test data, and so far so good.

Seems @nedbat wrote some related stuff about this. Worth a read.

Generally doing well so far. Minor bits of UI trip-up, possibly due to lack of knowledge. Interacting with something like GMail, that started out shortcut-heavy, is bordering on becoming annoying.

Using Pentadyctal a bit now after it came up in a conversation about browser shortcut hijacking. Why are so many browser shortcuts often hijacked by webapps, and/or why don't we have a way around it?

There's also the so-called half-life of facts to further complicate matters. A correct answer now is not the right one 3 years down the line, requiring the answering party to have time-accurate knowledge, which in turn leads to a requirement to continually keep up with things.

Another side of this is people's ...inability(?) to actually know what they really want, and is some cases a variation of the XY Problem

There's a case of "worth" as well, I suppose. How do you know when "just use apache" will actually be a good enough answer for what someone wants to achieve?

None of these are necessarily good answers, often for reasons that take a lot more detail to understand or explain.

So, in a side discussion with a friend (that came about after he spent 2 hours looking for a missing class in Java), I'm now raging again about what I can only call "common answers". Consider the following questions that newbies might ask:

• "How do I make a website?" -> "install apache"
• "How do I send my code to other people?" -> "use git"
• "How do I monitor things?" -> "use nagios/cacti/munin/..."

And, lastly, it's cool to see the product owners taking care to check up on their brand and help people :)

Further to post editing, it looks like you can't rename a stream..mm

Often been accused of having early-enter syndrome. ThoughtStreams seemed/seems ideal for this.

So, hello there, bronze account :)

Additional impressions:

• card management reasonably decent, but needs the ability to edit a published card
• nice to see bootstrap stuff being used without the default colours taking over the whole site

First impressions on interface:

• generally nice, although somehow it feels left-leaning
• might be a bit more responsive? not sure if that's because I'm on the other side of the planet from the site, or just site
• ...