Now that I’m on my way in actually building the first version of the news harvest tool, I thought I’d say a bit about the software development process itself.
We’ve decided to build this web application using the Laravel application framework. Created in 2011, Laravel is written in the PHP programming language and used around the world for building everything from personal websites to SaaS applications to mission-critical business tools. It’s also a very stable framework with a large community of open source contributors and developers for hire, which means that finding people to add and maintain Laravel functionality is relatively easy compared to more specialized or proprietary tools. All of these things combined set it up as a good choice for the Bloomfield folks to build on in the long term.
In February, I wrote on my personal technology blog about the tools I use for Laravel-based projects, and the list remains applicable here:
To organize and track the work itself, since I’m the only developer working on the project, I’m mostly referring to the mockups, data model and then using a simple text file broken down into “DONE,” “TODO,” and “LATER” sections:
If I were collaborating with other developers, I would be using a shared tool like a Trello board, a GitHub issue list or project, or something similar.
But, I am also building the software with future developers who are not me in mind. This includes writing code that follows Laravel best practices and code standards, setting the new functionality up as a self-contained “package” so that it can be installed easily in a new Laravel application for easy development, writing documentation that fills in the gaps of what is happening in the code, and “tests” that help a developer know when changes to the software breaks existing functionality.
Here’s an example of what part of the tests look like in code:
it('has a publish timestamp that is created at timestamp', function () {
$t = '2022-01-01 05:00:00';
$n = NewsItem::factory()->create(['feed_timestamp' => null, 'created_at' => $t]);
$this->assertEquals($t, $n->publish_timestamp);
});
it('has a relative publish timestamp', function () {
$t = Carbon::now()->subDays(5);
$n = NewsItem::factory()->create(['feed_timestamp' => $t]);
$this->assertEquals('5 days ago', $n->publish_timestamp_relative);
});
it('has source info with feed relationship', function () {
$f = Feed::factory()->create();
$n = NewsItem::factory()->for($f)->create();
$this->assertEquals($f->source->name, $n->source_info->name);
});
it('has source info with direct source relationship', function () {
$s = Source::factory()->create();
$n = NewsItem::factory()->for($s)->create(['feed_id' => null]);
$this->assertEquals($s->name, $n->source_info->name);
});
So, when I run the tests, I know everything is working correctly with the software logic related to “news items” along with other test results:
All of this is important foundational work that helps ensure the software project has the potential to be used and expanded by other local news organizations that might want to adopt and adapt the “news harvest” workflow.
Within that thinking, it’s of course good to find a balance between building for the future and getting a usable tool out into the world to be used in real production situations. But it’s also way too easy to throw together some software that appears to work and then is very hard to maintain, which almost always results in it being replaced or left behind sooner than later.
In any case, I’m working hard on software development and the next real milestone will be to have an initial “alpha testing” version of the tool ready for Simon and team to take a look at and play around with for initial feedback.
