This summer, one of the development teams at the Ed-Fi Alliance has been hard at work building Project Buzz: "When school shutdowns went into effect across the country as a result of COVID-19, much of the information teachers need to support students in the new online-school model had become fragmented across multiple surveys and the Student Information System." (Fix-It-Fridays Delivers Project Buzz, A Mobile App to Help Teachers Prepare for Back-to-School).

As project architect, my role has been one of support for the development team, guiding technology toolkit choices and supporting downstream build and deployment operations. The team agreed to develop the applications in TypeScript on both the front- and back-ends. My next challenge: rapidly create TeamCity build configurations for all components using Kotlin code.

While the Ed-Fi Alliance has made investments to improve the installation processes for its tools, it is still a time–consuming task: easy to get wrong, you must have the right runtime libraries, and it is problematic to have multiple versions running on the same server.

What if end-users could quickly startup and switch between ODS/API versions, testing out vendor integrations and new APIs with little development cost and with no need to manage runtime dependencies? Docker containers can do that for us.

Continue reading on ed-fi.org…

Letter to the City Council of Austin, Texas, in appreciation for action taken this week in response to both the killings of George Floyd and others at the hands of police, and the heavy-handed tactics employed against peaceful protestors.

13 June 2020

Dear City Council Members,

Thank you for passage this week of measures to limit police use of force and begin re-prioritizing the city budget. I strongly support these actions as meaningful steps toward a future where the intrinsic oneness of humanity is fully reflected in our words, our ordinances, and all of our actions.

Systemic inequities require systemic, systematic, and continuous attention through careful study of patterns, consultation on remedies, thoughtful action, and humble evaluation. Without doubt, these steps move us forward on a path. Naturally, questions arise about what next steps may be taken. Further demilitarization of policing, adoption of national standards for use of force, and appropriate funding for social services that reduce the risk of police encounters and escalation should be in the conversation. And, lest one crisis drive us to forget another, continued review of police handling of domestic abuse and rape cases must remain a priority.

Sincerely, Stephen A. Fuqua

Should bugs and spikes receive story points to aid in sprint capacity planning? Some teams will estimate all work items by time during sprint planning in order to find the right commitment. Many teams hate this and/or spend an inordinate amount of time arguing about time. Those that abandon time may be tempted to put points on these unplanned, non-productive items, but there is a cost: the completed velocity will overstate the projected release timeline for the remainder of the release backlog.

Possible solution: track the ratio of story to non-story points and use that to pad out the release projection estimate.

Motivation​

I don't like having a single large file for a TeamCity project, which is the default when exporting a project. It violates the Single Responsibility Principle (SRP). For maintenance, I would rather find each element of interest — whether a sub-project, template, build step, or vcs root — in its own small file, so that I don't have to hunt inside a large file. And I would rather add new files than modify existing ones.

Is This a Good Idea?​

This note about non-portable DSL explains the basic structure when you want to use multiple files. And yet I never noticed it while hunting in detail for help on this topic a week ago; only just stumbled on it while writing this blog piece. It seems to imply that using multiple files is "non-portable," but apparently I have been using the portable DSL: "The portable format does not require specifying the uuid", which I've not been doing.

There is a small risk that I could do something drastic and lose my build history without a uuid. Since I also have server backups, I'm not too worried. And in all of my experiments I've not been able to find any problems with this approach so far.

Infrastructure-as-code (IaC) is the principle of configuring systems through code instead of mouse clicks (cf Packer Tips and Lessons Learned for another example). TeamCity, the popular continuous-integration (CI) server from JetBrains, enables IaC through writing scripts to interact with its REST API, or by storing projects settings in version control. This article will share some lessons learned in using the Kotlin DSL for project settings. These will include:

1. What is Kotlin?
2. Benefits of using Kotlin
3. Learning Kotlin from TeamCity
4. Debugging before committing
5. Managing secure data
6. Connecting to forks

Soon the Ed-Fi Alliance will release version 2.0 of our Analytics Middle Tier, welcoming it to the "big kids' table" as a fully supported add-on to the ODS database.

When we started this project in 2018, it was with the aim of creating a production-ready proof-of-concept (a seeming oxymoron, we know) for simplifying the Ed-Fi Data Model, thus making the ODS more useful for reporting and ad hoc analytics exploration (see From Diagrams & Definitions: Solving the Analytics Reporting Gap). As such, it was released on the Ed-Fi Exchange instead of being bundled into the core ODS/API platform.

Continue reading on ed-fi.org…

Spurred on by the goal of giving a brown bag tech talk on the subjects of test-driven development and SOLID object oriented design principles, I've finally collected all of the "wisdom" I've learned over the years into one place: Best Practices in Test-Driven, Object Oriented, Green- and Brownfield Development. I plan to keep this as a living document, adding or modifying as I continue to deepen my knowledge through feedback, study, and further experiments.

Entity Framework Core has a few changes that impact unit testing, particularly with respect to EntityEntry.State management. My previous unit testing techniques also did not take into account the use of async methods. In this article I'll present a few techniques used in the context of a POC exploration of IdentityServer4. Although .NET Core 3 is now fully available, these examples are based on .NET Core 2.2.

Background​

IdentityServer4 has a ConfigurationDbContext that provides access for managing Client entities, along with an interface IConfigurationDbContext. While IdentityServer4's infrastructure handles all of the OAuth processing, CRUD operations for clients is left up to us. Therefore I created a ClientsController and a ClientRepository, and injected the interface into the repository.

The most popular request at the 2018 Ed-Fi Summit’s tech town hall was for an option to run the Ed-Fi ODS / API on an open source database solution. Historically, the Operational Data Store (ODS) database has been developed on Microsoft SQL Server, matching the preference of educational agencies that rely on heavily discounted licensing terms for on-premises operation of SQL Server. The advent of cloud-based hosting has changed that dynamic, especially since Microsoft ended the "bring your own license" (BYOL) practice.

One implication of that change is that educational agencies wishing to use SQL Server may need to pay full price when using non-Azure managed services for SQL Server; however, even with BYOL, managed services with SQL Server does cost more than other database platforms. So, with the help of an Ed-Fi Special Interest Group, we narrowed the field to one alternative database platform (for now…).

continue reading on ed-fi.org...