82 posts tagged with "programming"

GitHub Copilot Coding Agent is an impressive and powerful tool for "autonomously" completing development tasks running in GitHub's environment. Like any tool, there is a learning curve ahead before any of us become truly high functioning, beginning with the statement of a well crafted prompt.

⚠️ But I have a concern: lack of commit signing. Should that stop us from adopting Coding Agent? TL;DR conclusion: time to relax the commit signing requirement.

GitHub CoPilot recently promoted Agent mode as a full feature in VS Code. Many writers and commenters in the blogosphere think competitors are still better; perhaps they're right. But this is the one I have, and Microsoft is innovating rapidly - seeing that first hand at Microsoft Build even as I type this. So in recent days I've performed three initial experiments that I want to share. Not because I'm doing anything brilliant: just trying to find tasks that might be a good fit, learn how to interact with the tool, and share a bit to help others in my proximity.

Lesson: be patient, and be in a learning mode. Not just waiting for it to finish (might take several minutes), but also in getting the right results. I remarked on a failure (below) to my colleague Jason Hoekstra; he suggested that I simply undo and try again. It was the right advice. Experiment and build an intuition.

Below I describe three experiments and outcomes.

Containerization of an application benefits operations of the application by solving the problem of "it works on my machine" (at least, for the application itself). The container holds the operating system and all needed components. Once you have Docker on a host - whether localhost, on-prem data center, or in the Cloud - you can run the application with greater confidence, knowing that the application will execute the same in all environments.

But the benefits of containerization can also shift left in the development lifecycle. For example: have you ever needed to revisit an older application, and realized that you don't have the SDK on your machine? Instead of installing the SDK locally, you may be able to run the SDK in a Docker container.

Following up on Grudgingly Accepting AI Coding Assistants, I have a small win from my first experiment with GitHub Copilot: a Python script for converting portions of an Open API specification file to a CSV. There is nothing revolutionary in this small win; countless programmers have doubtlessly done much more. But a reluctant engineer has to start somewhere.

As a software engineering director building open source products, I have prohibited my teams from using AI coding assistants due to concerns about intellectual property and questions about the risks and real world effectiveness of AI coding assistants. It is now time to allow and even encourage AI coding assistants, with guardrails.

In reaction to all of the "agile is dead" articles, I am cleaning up old posts about Agile, re-reading them, contemplating lessons learned but forgotten, and asking myself if some practices have outlived their usefulness. That is the spirit of agility: the interplay of action and reflection.

"Agile" is not a silver bullet for improving software productivity, reliability, and simplicity. But "Agile" continues to give us tools that can foster improved software engineering.

The Agile Manifesto was a distillation of certain trends that the authors had noticed in their successful projects. On balance, they ring true to my twenty-five year career in software.

It did not offer guarantees and it did not offer to solve world hunger. Through prescriptive frameworks such as Extreme Programming and Scrum, and common practices such as development of story cards and short cycles (aka sprints), the Agile "revolution" broke us free from the confines of gigantic requirements and design documents that were always at least slightly wrong, and frequently very difficult to change. It helped us embrace the uncertainty of software development, empowering us to find our way out of that wrongness more quickly and productively.

"For the past two years, the Ed-Fi Alliance software development team has been listening to community members through its Technical Advisory Group, Special Interest Groups, and at our annual events. We have been hearing that the pace of change in the Ed-Fi ODS/API Platform needs to accelerate, shifting to a cloud-native architecture that can better support large-scale deployments while offering greater cost and performance flexibility. To do so, we need a reboot."

→ Full article at New Cloud-Native Functionality Coming to the Ed-Fi Alliance Technology Suite

Though barely mentioned in the article, the work to create a production ready system has been dubbed Project Tanager, the third bird-related project name in my tenure with the Ed-Fi Alliance (Roadrunner, Meadowlark).

In Unpopular Opinion: It’s harder than ever to be a good software engineer, author Juraj Malencia opines that "good engineering" equates to "bring[ing] maximum value in achieving a goal." This is a comforting thought for those of us periodically wondering if we're still good software or data engineers, though we might not be up-to-date on the latest hype.

Pointing out that "engineering does not equal programming", implying that we can bring great "engineering" (solutioning) value without writing a line of code, he presents a modified version of a venn diagram on how people in various roles spend their time between programming, alignment, people, and "other". I was bemused to note I currently sit squarely in the category labeled "beware" 🤨. A position that may continue throughout this year, but will need to change over time.

Motivation​

The Ed-Fi ODS/API is a REST API that support interoperability of student data systems. The API definition, via the Ed-Fi Data Standard, is extensible: many large-scale or specialized implementations add their own local use cases that are not supported out of the box by the Ed-Fi Data Standard (Extensions). Furthermore, the Data Standard receives regular updates; sometimes these are merely additive, and from time to time there are breaking changes. These factors make it impossible to create a one-size fits all client library.

But, not all is lost: the ODS/API exposes its API definition using OpenAPI, and we can use Swagger Codegen to build a client library based on the target installation's data model / API spec. The basic process of creating a C# code library (SDK) is described in Ed-Fi documentation at Using Code Generation to Create an SDK (Note: this link is for ODS/API 7.1, but the instructions are essentially the same for all versions).

Design document describing an event-driven approach for offline cascading updates in the Ed-Fi Meadowlark project's document storage system: Design for Offline Cascading Updates