Today at #QConPlus , @girba shows graphs that reveal hidden dependencies in code.
Somehow this code reveals its own properties and relationships in custom-made developer experiences
Glamourous toolkit: gtoolkit.com
"empowering developers to create their own tools for every one of their problems" @girba#QConPlus
This is a superpower of developers: we can craft our own work environment.
For example, when viewing build logs: as you find a new problem, add some custom highlighting so that next time it jumps right out at you.
Browsing through code is a very expensive activity. I'm trying to use my eyes as a data mining tool. @girba#qconplus
@girba When you have a question about a problem
Rather than looking at the problem through the lens of tools
Mold the tools to fit the problem.
This is moldable development.
"what kind of visualization would make the problem simpler to graph?" then whip that up.
the system changes too often to rely on memory.
A generated view can show us what we need to know.
Maybe this view that you're creating will only be used once.
The economic benefit: make a decision based on reality.
Build into the environment the ability to quickly change the shape of the tool to match the current focus of development.
"Five years from now, you'll be hiring for storytellers of systems." @girba#QConPlus
Given a legacy system in an undocumented language ("They gave us documentation, it was wrong"), given a few weeks to create custom lenses, @girba tells the customer things they didn't know about the software they've been living in for years.
Rescue and revive opaque software.
This reminds me of @honeycombio, where people who dig into graphs and see traces for the first time immediately find surprises in their own system.
There is a growing wasteland of uninhabitable software that businesses depend on.
@girba aims to make it habitable again, by enabling us to casually build the custom tools of rehabilitation for each problem. #QConPlus
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@PhillipaAvery@netflix In the Startup and Growth phases, it's all about velocity. In Maturity, it gets interesting. We need stability without killing velocity.
@PhillipaAvery@netflix In renewal/decline, parts of the software need stability while other parts need velocity.
(I missed the cool picture, it was pretty great)
Anyone who says to you “this architecture is universally applicable”
is probably selling something,
and not doing a very good job at selling something.
Don’t use event-driven architecture for a small system or for an exploratory spike.
“learn what you’re trying to do before you elaborate your architecture.” @tlberglund#DevoxxPL
Databases don’t go away when you’re using events.
If nothing else: when you need lookup by multiple keys, databases are necessary views on the system of record (which is the event log).
Adding people scales at best linearly upward, at worst geometrically _downward_.
Two things you must constantly seek in order to get more done with more people:
1. "Constant pursuit of force multipliers"
Instead of adding more people to the same task, change the task to be done.
Develop more-complex internal structures, such as tooling teams that facilitate many development teams.
It's a holiday, I get to do what I want, so let's see what else is in the CSS 2.1 Spec!
It's time for backgrounds and fonts...
background-color is a friendly property. Use it even when you also specify the image, in case the image doesn't load/hasn't loaded.
Defaults to 'transparent' so the stuff behind it shows through.
The background fills the margins and the borders. (It shows under dashed borders)
background-image: url("where-is-it.jpg")
makes a picture show.
How big the picture is depends on the intrinsic properties of the image (width, height, ratio). Anybody know how to find out whether an image file has these?