thinkersilver

It helps to instrument the journey of your work from jira all the way to build, deployment, run and monitoring (observation).

From that you can get measurements on how long each stage takes and the duration of each transition.

From there you can compare team A and B. The transition times is where the human time cost usually sits.

Just getting the time when a Jira or feature is raised, to the time it is picked up to the time of the first commit to the time of the first test and final build does already give you valuable insight.

The points you raised towards the end can be answered if observability of your CI/CD pipeline is actually in place or at least a place to start a line of inquiry.

Naturally the blockers will be aggregated into some of the values but as you work through the journey, they will start clustering at certain stages and maybe highlight a significant problem that needs to be addressed.

There's a wealth of data being left on the table that can help inform management decisions.

This feels all to familiar to a Java developer and similar to what they do in k8s with the genericapiserver component but not to the full extent described in the article. It's interesting to see how the service container pattern appears in other language ecosystems. The nice thing about go's module system is that it feels like a monorepo without the tooling feeling separate to the language. So splitting up a repo into different repos doesn't come with the versioning hell when working with maven

It's been a while since I've looked at Fabric8 but it had good java -> k8s integration and was great for writing k8s tools.

It appears though that Fabric8 is useful for solo java projects without complex dependencies on non-java projects or small java shop. It overlaps with where jenkins-x is going, which has made major strides in the last 24 months.

The original team that worked on Fabric8 lead by James Strachan all moved on from Redhat and many of them are working on Jenkins-x.

Kubernetes is becoming the lingua-franca of building infrastructure. Through CRDs and the kube api spec I can

- start an single application

- deploy a set of interconnected apps

- define network topologies

- define traffic flows

- define vertical and horizontal scaling of resources

And now I can define AWS resources.

This creates an interesting scenario where infrastructure can be defined by the k8s API resources and not necessarily have k8s build it. For example podman starting containers off a K8S deployment spec. It's an API first approach and its great for interoperability. The only downside is managing the yaml and keeping it consistent across the interdependencies.

I've been a big fan of brain storming tools for a long time so appreciate new tools with different takes on the problem.

I do have one observation and it maybe just me. I have no way of clustering a group of connected thoughts, or a way to 'chunk' the concepts. I see some attempt by using coloured lines but there should be a way to make these ideas hierchical and from that be able to zoom up and down various levels of conceptualisation. It would make managing a large network of ideas a lot easier, possibly a bit more ergonomic. Similar to the way the brain works.

It may just be me but was wondering if there's a way to achieve that with the current tooling or if you think there are workarounds?

Great article. I think you might be taking a subtle point in the article for granted. Namely, the ability to assemble a fairly complex distributed system from open source components.

Democratisation of complex machinery like the raft and consensus algorithms, schedulers, append logs, query optimisers and so on is a superb thing. It is something that has only been possible in the last 3/4 years and would have been devilishly difficult before then without significant upfront work.

Fetishising complexity might be a bit strong here. Seeing more posts like this is a good thing.

If AWS gets you going definitely go for it but if you're looking for existing tools type 'python speaker diarization' in github.'

Most of what you'll find would require downsampling your audio to 16khz and you'll find a combination of NN based diarizer and hmm based models pre-ML.

One thing to note a lot of the systems will work well for interviews, broadcast media and footage taken from a camera because the audio will tend to be clean.

Film and movies will be a challenge because of the background music being identified as a separate voice. It tends to to confuse it.

Haven't used the cloud based systems with audio the background sounds you tend to find in film movies.

iPAAS' are essentially ESBs remarketed for the cloud for organatisations without the in-house expertise to coordinate building their own integration hub with a combination of tools like Kafka and API management gateways. Organizations lacking the * Architectural leadership

* Coordination capabilities

* Engineering resources

* strong comms between teams

tend to go for these solutions to paper over their existing problems. Particularly those around engineering capabilities.

These solutions work great for a while until the edge cases around data arrival and consumption usages resurface.

It's important to note that these solutions shine when it comes to the API discoverability across teams and light data format translations but as soon as that has happened get your data out quick!

Don't be tempted by their in-house solutions that try to solve caching, scaling and the ETL languages provided because they will tend to be half-baked and not as battle tested and will lock you in. The commitment for a large org using these systems is a 5-10 horizon.

By all means check them out and be ready for alot upfront design work to find the sweet spot and alot of engineering effort and frustration (alot).

Yes I was. I've posted the comment to the correct story now. I don't how that happened.

A software architect that can't code or refuses to has no business architecting the system. A software architect who doesn't show up to stand ups really shouldn't be dictating a solution to the team who have to build it. Ideally the software architect should be as hands on as possible with the team leads as the system is built up to the point that the architecture is proven or at least to see if the assumptions around the architecture actually hold up. Really strictly on teams leads to accurately communicate the architecture before it has been proven to hold up is risky.

The snippets feature looks quite powerful and particularly like the enumeration conversion example. Are there any plans of making these kinda of transformations extensible?

I've recently gone into speech assisted video editing and came across Kald about a month ago, was interested specifically in its diarization feature ... it's quite daunting. How did you get up to speed on it ... I've talked to a few people who've worked with it but it took them months to feel comfortable with it.

Well they did qualify with that it was a complex topic. And am not sure he hinted that it was compulsive.

I tend to work in a banking infrastructure environment and it's common practice to take notes,

The number of conversations I have during the day often has me saying, I'm not going to remember everything you've said, could you put that in a email so I can get back to you properly.

It does depend on the environment,