work:

– getting pmacct <> rabbitmq <> influxdb working, then putting a nice frontend on top of it

– auditing a Palo Alto install the MSP royally boned on the migration. I know BGP is somewhat obtuse on PANOS but…no excuse. in pre-sales you, unprompted, mentioned having one of four experts qualified to configure whatever is after the top of the line 5000 series. c'mon!

– quickly utilizing the last six days of my Azure $200/30 day credit to boot OpenBSD, get IPsec tunnels with BFD running, and do some iperf tests between regions for a PoC

– setup graylog to ingest wireless controller and firewall logs and make nice dashboards for front line support network troubleshooting

fun work:

– continue building class outline and course work for a “python for network engineers” (a working title as it’s already in heavy use by Kirk Byers)

– lots of unikernel stuff. Kafka as a unikernel, pmacct as a unikernel. getting rumpkernels to boot with vmm on OpenBSD. getting ExaBGP into a unikernel, then doing ‘stress’ testing against OpenBGPd

– osm + packet clearing house IXP list + peeringDB + d3js = transform spreadsheet currently sitting at http://peering.exposed/ (after a particularly whiskey-infused discussion @ RIPE73)

– play with a couple of network verification tools I recently read and have been reading about, respectively: Propane and NetKAT

I’m wondering whether they really had to implement everything in order to learn those lessons. The “lessons” are pretty much the widely-known basic definitions of the well defined terms contained within them. It’s not like we’re talking about a chaotic emergent phenomenon that arises due to the complex interactions of the pieces in a complex system.

With the company shutting down, we also wanted to find a new home for our team … We’re excited that the members of our engineering team will be joining Stripe

If they actually went out and found work for the whole engineering team, that’s extraordinary. Bravo.

Meetings meetings meetings :)

Have to interview around a half dozen folks. The most interesting thing is we’re quantitatively measuring our TAMs (technical account managers) on how well they demo and, separately, how they handle some field support situations. While its nice to hire smart folks, it’s good to be able to do something like this to objectively qualify that their skills are staying sharp.

On the down side I have to do a fair amount of glue code / integration work with sales force this week.

Finally i get to start getting some ETL pulls together to start building our customer success measurement analytics (time permitting)

I really wish we had the full dumps from both the Friend Finder and OPM hacks. It’d be very interesting to correlate the data between Ashley Madison, Friend Finder, and OPM. Clearance-holding cheating spouses with kinky fetishes and STDs = no no.

Everything old is new again I suppose. Back in the late 90s when this was the popular approach, the downside was you were effectively limited performance-wise to vertically scaling your database as opposed to being able to horizontally scale your application layer.

Also…with the Hickey quote….it could be argued that you’re keeping things simpler by making the primary function of the database to store data…that placing one’s business logic / transforms within the database is increasing the complexity.

Anyways, like anything else, there’s no one clear answer. It’s always good to revisit assumptions, best practices, etc. as times change to see if there’s anything that is ripe for change / can be done better.

I’ve been a pretty big fan of jq for a number of things: * lots of my logs these days are in json (so they’re machine parseable and human readable). It makes filtering them child’s play. * Some of our ETL pipelines have a decent amount of JSON in them and jq makes it pretty quick / short work to do pre / post processing pretty quickly.

I appreciate the conversation and that assumptions about Scrum are being challenged. And I agree that Scrum is not a silver bullet.

But I’ve seen planning poker work. It does not always go like the author’s anecdote. If some dev just barks “20 points? REALLY?” when the team is trying to come to an estimate, that dev is an asshole and you’ve got larger problems.

And I’ve seen morning standups work too. Someone has to be tasked with keeping the team on task. The conservation needs to be limited to what happened yesterday, what happens today, and what blockers can the PM tackle for the team.

I’ve seen this work in large organizations. I’m not talking about an 8 person start-up. Just because it’s not universally applicable or successful doesn’t mean it needs to die in a fire.

(Nice troll style points for the title and the image of “Visual Studio TFS” branded planning poker cards though.)

Apologies if this formats poorly:

• 1 -> Let the team member determine timing. You don’t want a meeting that is compulsory which is seen as a time sink.
• 2 -> Your job is no longer to code / perform technical things (aside from traffic management). Your job is to make your team members better and let them do their jobs. That means you should be pushing back on product management and helping your team to do what makes sense. You can still do some technical things by (for example) performing code review and design review (to help improve your team); however, it’s probably more helpful to your team to let them do their jobs and eliminate obstacles.
• 3 -> Always be on time to things. If you’re late that means whoever you’re meeting with is not important.
• 6 -> Keep your hiring bar high. Period. Once you let your bar down to just “get things done” you are admitting that you are choosing faster and cheaper over high quality (in the infamous triangle of faster, cheaper, quality…pick two). When you hire to get things done, you are incurring talent debt.
• 7 -> Retention is more important than hiring IMO. The folks you keep are the ones who are determining your culture. The people you hire are the people who change your culture. It’s also typically cheaper to retain people than to hire people.
• 8 -> I don’t believe in once a year formal performance reviews as they commonly exist. I would rather have 360 reviews with my folks every 6 weeks or so. Here’s where I think you’re doing very well. Here’s where I think you can improve. Here are a couple concrete things you’ve done recently and how I feel about them (good or bad). Now let’s talk about how I am performing for you…or how you feel others can improve/are doing well. I like to think of it like the agile world. I’d rather things being iterative as opposed to “Remember that project you worked on 9 months ago…here’s what you did wrong there.”
• 9 -> Increasing whose quality and productivity? Yours? Your team members? Your entire teams? Those all require different tools and appraoches. The only thing I’ve done a lot recently which I feel like most places don’t do is pay down technical debt on a regular basis (be it 1 week per month or 1 out of every N sprints, etc.) Schedule it and do it. Otherwise, I feel there tends to be a lot of lip service to paying technical debt and not enough doing of it (until it becomes much larger than it needs to be)
• 10 -> I like the 20% time but I’ve never been able to do this well. Closest thing was a sprint every N which was “a free sprint”. It wasn’t as successful as I wish it had been. I’d love to hear how people do this well (and not just the 2 day hackathon every quarter like some places do).

I’m embarrassed to say! I’m implementing some really simple automated trading code. And it’s taking me fucking forever because I don’t know Java or automated trading systems.

I don’t get it. Tracky posts all sorts of stuff that is available in the http headers anyway. There are still multiple invisble pixels (at least on the home page).

“One question begged of Big Data has been – is anybody actually handling data big enough to merit a change to NoSQL architectures?”