HN user

cek

3,725 karma

If it moves electrons or makes noises, I dig it.

https://www.kindel.com

Posts210
Comments334
View on HN
github.com 1d ago

Mermaider is a dotnet lib for generating Mermaid diagrams

cek
1pts1
gui-cs.github.io 1y ago

Cancellable Work Pattern in Terminal.Gui

cek
3pts0
github.com 3y ago

Terminal.Gui 1.7 has a multi-step Wizard class

cek
2pts0
aws.amazon.com 5y ago

Amazon Nimble Studio – Build a Creative Studio in the Cloud

cek
14pts0
ceklog.kindel.com 5y ago

Find the Crux by Debating Excellence

cek
1pts0
ceklog.kindel.com 5y ago

How to Be a Secret Agent (Of Change)

cek
2pts0
blogs.windows.com 5y ago

Protected: Making Win32 APIs More Accessible to More Languages

cek
2pts1
www.lookbackquotient.com 5y ago

Look Back Quotient

cek
1pts0
mailchi.mp 5y ago

LIFX Announces World-First Disinfecting Anti-Bacterial Smart Light

cek
1pts0
www.platformonomics.com 6y ago

Follow the Capex: Clown Watch

cek
2pts0
ceklog.kindel.com 6y ago

Broken Windows – Right Idea, Bad Analogy

cek
1pts0
ceklog.kindel.com 6y ago

A FAQ About Frequently Asked Questions

cek
1pts0
blog.cloudflare.com 6y ago

Cloud Computing Without Containers

cek
31pts3
ceklog.kindel.com 6y ago

Path to Green

cek
1pts0
ceklog.kindel.com 6y ago

Tenets

cek
1pts0
ceklog.kindel.com 6y ago

Microsoft shipped a broken DCOM CD-ROM and no-one noticed

cek
23pts5
www.theverge.com 6y ago

There Are Too Many Competing Smart Home Standards

cek
1pts0
sriramk.com 6y ago

Exec 101 – First 30 days

cek
6pts0
hackaday.com 7y ago

Exploring the Raspberry Pi 4 USB-C Issue IN-Depth

cek
3pts0
techcrunch.com 7y ago

SpaceX and NASA detail cause of Dragon test failure

cek
1pts1
ceklog.kindel.com 7y ago

One-Way and Two-Way Doors

cek
1pts0
ceklog.kindel.com 7y ago

Focusing on users is not Customer Obsession

cek
1pts0
medium.com 7y ago

What Is a Smart Home?

cek
2pts0
ceklog.kindel.com 7y ago

Good Intentions Are Never Enough

cek
1pts0
nest.com 7y ago

Google Is Turning Off the Works-with-Nest API

cek
936pts569
ceklog.kindel.com 7y ago

Kindel's Law

cek
4pts0
ceklog.kindel.com 8y ago

Be a Great Reader

cek
3pts0
ceklog.kindel.com 8y ago

Merit Badges – A Mental Model for Success

cek
1pts0
www.pscp.tv 8y ago

SpaceX Periscope of Tesla on Way to Mars

cek
7pts0
ceklog.kindel.com 8y ago

Paying Developers Is a Bad Idea (2012)

cek
2pts0

I know this is HN, and my instincts tell me posters here predominately are either ICs or managers "in the small" (line level, or at the most at the scale of the OP, in which the company is ~300).

That said, asserting that most meetings are either brainstorming or decision making, is naive. When an organization grows beyond ~100-150 people (Dumbar's Number) the org must metastasize into smaller, "self-contained", orgs that are far less than that number. Once this happens, there is need for meetings that drive accountability, closure, and alignment at scale. For example, monthly or quarterly business reviews.

These are NOT brainstorming meetings or decision-making meetings. They are meetings where leadership drives accountability and alignment by ensuring light is shined (in a way visible cross-org) on the right topics for the biz.

Instead of viewing Dunbar's number as a law, I view it as a sometimes useful, mental model. This article is about how Dunbar's number, as a mental model, breaks down when applied to social media. It makes a strong case for that.

Like all mental models, Dunbar's number is not perfect. However, readers who stop after the introduction of this article may be left thinking it's not useful at all.

I find it very useful in helping leaders in early-stage organizations that are growing fast recognize why the tools & techniques they've used to get to 30-80 people are breaking down as they approach 100-150 people. It helps frame why new tools & techniques for organization and communication are required.

This is NOT "literally a port of an older curses lib to the latest .net". It is a complete API for building terminal UI applications using .NET that leverages curses under the covers when running in a non-Windows environment (on Windows it uses the native Windows console APIs).

For completeness, Terminal.Gui is built on top of a "Console Abstraction Layer" (CAL; I just invented that term), via the "ConsoleDriver" base class. There are four subclasses provided:

- CursesDriver: Uses curses and is the default on Linux/Mac.

- WindowsDriver: Uses the Windows console API and is the default on Windows (only works on Windows)

- NetDriver: Uses the .NET console API and works on all platforms

- FakeDriver: Used for unit testing.

NetDriver is the slowest. WindowsDriver is the fastest. CursesDriver is the biggest bugfarm ;-).

Because I (apparently incorrectly) assumed a lot of people would appreciate the fact the mouse works so well.

Also, because getting the mouse to work well (across Windows, Mac, Linux, etc...) is freaking hard and the Terminal.Gui team is proud of their work ;-).

I built a cross platform app to print 'pretty formatted' source code [1]. I didn't want to re-invent the wheel on formatting source code, so looked at all the existing libraries. Originally I figured formatting to HTML, and then building a print-friendly HTML render would work. But this proved super challenging. I tried a dozen HTML engines (including Chromium) but none gave me enough control to render just a single page of the original source file.

Then I noticed Pygments, a Python-based library for pretty formatting source code, has an option to output an ANSI formatted file. I quickly found a bunch of libraries that could render ANSI formatted text to a print canvas.

In the end, I put the original source code file through 'pygmentize -16m -o tempfile.an` (`16m` is the 16M color terminal ANSI formatter) and pipe the `tempfile.an` through a print-optimized renderer to actually print the source code.

ANSI escapes FTW!

[1] WinPrint - https://github.com/tig/winprint [2] https://pygments.org/

It really comes down to the tenets I posted above from Amazon. At MS there was a propensity for folks in these roles to just pontificate. We called them "Architecture Astronauts". As an example, they were rarely practitioners (they rarely wrote code).