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.
Balcones National Wildlife Refuge, December 2024, by Stephen A. Fuqua
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.
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
Design document describing approaches and appropriateness of in-memory and distributed caching for improving the performance of referential integrity checks in the Ed-Fi Meadowlark API: Resource Caching for Performance Improvements
Full write-up of experiments in MongoDB connection string tuning with Ed-Fi Project Meadowlark: RND-380: MongoDB Connection Pooling
As education agencies increasingly look for cost-savings and scalability benefits through adoption of hybrid or cloud-only IT infrastructures, it is natural to ask: what should an ideal Ed-Fi installation look like in the cloud?
Originally posted on www.ed-fi.org
The Ed-Fi Tech Congress in Phoenix, of April 2018, was a sink or swim moment for me, as I had just started working for the Ed-Fi Alliance. Among the first people I met was a representative from one of the big technology companies. The conversation quickly turned to the question of how to deal with data when the vendor would not send it directly into the Ed-Fi ODS/API. He asked me, "why not just put it in a data lake?" To which I had no reply. Nearly four years later, at last I can give a reasonable reply.
Continue reading on wwww.ed-fi.org...
