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

On July 13, a new statue was placed in the U.S. Capitol: Mary McLeod Bethune. Reading the news, I knew that I had heard this name - yet knew nothing about her. Who was this woman, the first African American to be so honored in the Hall of Statues?

Born into a large family on her parents' farm in 1875 (she was the fifteenth child), she was taught early to look to the Bible for guidance and comfort, despite the family's illiteracy. With help from a benefactress, she enrolled in school at the age of ten and eventually went on to collegiate study. Oft quoted as saying, “[t]he whole world opened up to me when I learned to read,” she went on to live an exceptional life of courage and action on behalf all people, most particularly her fellow African Americans and especially women of color.

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...

Prompted by a class I'm taking, I decided to try running Python from Windows Subsystem for Linux (WSL; actually, WSL2 to be specific). Installing Python in Ubuntu on Windows was relatively easy, though I did run into a couple of little problems with running poetry. Bigger challenge: running graphical user interfaces (GUIs) from WSL. Here are some quick notes from my experience.

"Reacting to religious fanaticism and the challenges of advancing and sustaining a more equitable civilization, a global interfaith movement has sprung from the grassroots of religion and spirituality. InterfaithNews.Net (INN) seeks to chronicle this movement by focusing primarily on positive interfaith and religious news, events, and resources."

That was the mission of a little newsletter and website that Joel Beversluis and I started, with support from the North American Interfaith Network (NAIN) and the United Religions Initiative (URI), in 2002. Would that I could remember where he and I first met; perhaps at the URI North America summit of 2001 in Salt Lake City. Regardless, our time of collaboration was all too short.

Goal: setup PowerShell Core and .NET for development in Ubuntu running in Windows subsystem for Linux (WSL). And a few other tools.

Motivation: porting PowerShell scripts for .NET development on Linux, thus enabling more programmers to develop on a certain codebase and enabling use of Linux-based containers for continuous integration and testing.

Author Neal Stephenson, in his essay "In the Beginning... Was the Command Line," memorably compares our graphical user interfaces to Disney theme parks: "It seems as if a hell of a lot might be being glossed over, as if Disney World might be putting one over on us, and possibly getting away with all kinds of buried assumptions and muddled thinking. And this is precisely the same as what is lost in the transition from the command line interface to the GUI. (p52)

With new programmers whose experience has been entirely mediated through an

IDE like Visual Studio or Eclipse, I have sometimes wondered if they are understanding the "buried assumptions" and suffering from "muddled thinking" due to their lack of understanding of the basic command line operations that underlie the automation provided in the IDE. I still recall when I was that young developer, who had started with nothing but the command line, and realized that Visual Studio had crippled my ability to know how to build and test .NET Framework solutions (setting up an automated build process in Cruise Control helped cure me of that).

"Infrastructure as Code", or IaC if you prefer TLAs, is the practice of configuring infrastructure components in text files instead of clicking around in a user interface. Last year I wrote a few detailed articles on IaC with TeamCity (1, 2, 3). Today I want take a step back and briefly address the topic more broadly, particularly with respect to continuous integration (CI) and delivery (CD): the process of automating software compilation, testing, quality checks, packaging, deployment, and more.