Infinite Undo! RSS


 
 

Hello, I'm Noah Sussman

Sep
3rd
Wed
permalink
The Jenkins Wall display project

This an MVP iteration of a CI / Testing dashboard. I have been working on this idea for several years now, but have only just gotten to a point where any of the code is general enough to be released.

http://github.com/textarcana/jenkins-wall

The screenshot above shows the Jenkins Wall displaying build statuses from the Mediawiki Jenkins instance.

Colors and other display features

White boxes correspond to jobs that are queued, red corresponds failed builds, green is a passing build and the grey box at bottom indicates a job that is building right now.

Clicking anywhere on a box will start the corresponding build, assuming you have permission to start builds on that Jenkins instance. I’ve also provided direct links to job configuration pages (again assumes you have permission to configure builds in the first place).

I’ve got lots more features implemented and will be extracting them on an ongoing basis from now on.

The Jenkins Wall display project

This an MVP iteration of a CI / Testing dashboard. I have been working on this idea for several years now, but have only just gotten to a point where any of the code is general enough to be released.

http://github.com/textarcana/jenkins-wall

The screenshot above shows the Jenkins Wall displaying build statuses from the Mediawiki Jenkins instance.

Colors and other display features

White boxes correspond to jobs that are queued, red corresponds failed builds, green is a passing build and the grey box at bottom indicates a job that is building right now.

Clicking anywhere on a box will start the corresponding build, assuming you have permission to start builds on that Jenkins instance. I’ve also provided direct links to job configuration pages (again assumes you have permission to configure builds in the first place).

I’ve got lots more features implemented and will be extracting them on an ongoing basis from now on.

Aug
22nd
Fri
permalink

WHAT IS YOUR SHARK ATTACK BACKBONE OUTAGE MITIGATION POLICY or do you even have one…

OTOH if you tell me you game day’d this shit then I want to work for you call me

YOU: Yeah so for game days we generally flood the DC and then the CEO gets to release a shark, which can bite any cable but the system will stay up.

ME: This interview is over where is my desk.

Also sharks bite undersea fiber optic cables. It is real. It is a thing.

Aug
3rd
Sun
permalink

Generative drawings done with FlowPaper

Aug
2nd
Sat
permalink
terrysdiary:

NOTHING WORKS

That’s real.

terrysdiary:

NOTHING WORKS

That’s real.

permalink
generative drawing made with FlowPaper

generative drawing made with FlowPaper

Jul
30th
Wed
permalink

Punctuated Equilibrium and Intractable Systems

Punctuated equilibrium is a theory in evolutionary biology which proposes that most species exhibit little evolutionary change for most of their history. When significant evolutionary change occurs, it is generally restricted to rare and rapid (on a geologic time scale) events of branching speciation.

Wikipedia

It is a commonly accepted principle that software systems evolve, much like biological ecosystems. And in general the crossovers between programming and genetics are well-known.

A large system that works is invariably found to have grown from a small system that worked —Anonymous

Erik Hollnagel’s concept of Tractable Systems and Intractable Systems assumes that in general there is a an unknown but relatively discrete inflection point for a simple system beyond which the system has become so complex that it must now be considered intractable.

Large intractable systems evolve from simple, tractable systems. A transition point between tractable and intractable exists somewhere along the timeline of an organization’s life.

Once a system flips over to being intractable, then it stops mattering how “big” the system is — your concept of system complexity on some objective scale stops being relevant once system behavior has become non-deterministic.

One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.

— Fred Brooks

Jul
29th
Tue
permalink

Generative drawings done in the FlowPaper iOS app.

Jul
26th
Sat
permalink
Video feedback drawing, created with iPhone, Apple TV and airplay.

Video feedback drawing, created with iPhone, Apple TV and airplay.

Jul
25th
Fri
permalink

Generative drawings created in FlowPaper on iOS.

Chaos is awesome ;-)

Jul
18th
Fri
permalink

Please stop trying to sell me on management positions while offering a “QA Engineer” title and salary

Recently I was sent a job posting that embodied what I will call the Pernicious Myth of the QA Automation Engineer. Here’s just one line:

Own automated testing capabilities across Web, mobile and production processes.

Um.

An engineer cannot by definition take responsibility (that’s what “ownership” means — right?) for features that cut across multiple groups. In all but the smallest companies, Web and mobile would be managed by different teams. With different MANAGERS.

Engineers don’t take responsibility for the behavior of MULTIPLE managers across different teams.

This is a Director’s job.

Managing software capabilities across multiple teams is the job of a mid-level Engineering manager such as a director or (in larger organizations) a VP.

Why not? Because decades of computer engineering experience show that it never works.

Management (with all its wondrous hierarchical levels) is responsible for behavior of people within and across teams. Engineers and designers are responsible for the behavior and organization of the product. Not the people. People are a management problem. Especially at scale. Organizations that forget this fail.

Takeaway: do not sign on for a director’s job at an engineer’s salary

I’m not saying no one should take responsibilty for the “tests and testability” of an application or service.

What I am saying is that someone should be explicity responsible for testing across the whole organizaiton and that person should be at the director or executive level. Never at the engineer or team lead level. Ever.

Jul
17th
Thu
permalink

Who owns testing?

There is a widespread misconception that QA should own testing. This is false. Not only is it false but it doesn’t even make sense. You cannot have a discrete group that “owns” testing because testing is integral to the activities of both engineers and designers. Organizations often make a choice to ignore this, but the choice is based on cultural inertia rather than science.

Engineering and Product always owns testing because testing is a design process. If QA performs all testing and devises test plans, then that’s an explicit decision by Engineering and Product groups to try not to own testing.

As an engineer-or-designer, you can try not to own testing, but it doesn’t work. Because testing is part of the engineering and design process. Testing is not an activity in itself. Rather it is an aspect of the larger activity of designing and building software systems.

permalink
There is a very deep disconnect in the software industry with regard to QA and Testing.

There is a very deep disconnect in the software industry with regard to QA and Testing.

Jun
1st
Sun
permalink

The problem with asking where testing/qa “fit in” to devops

The problem with asking where testing/qa “fit in” to devops is that testing/qa is part of dev.

It’s a historical mistake that test/qa was marginalized to the point it’s now seen as a separate discipline.

May
30th
Fri
permalink
permalink