I gave a presentation on Packet Radio for my club, River City Amateur Radio Communication Society this week, here’s my slides from the presentation:
Why do we need to learn programming concepts?
We write code to solve problems, to be executed by computers, but perhaps more importantly, to be understood by other humans.
Programming paradigms like imperative and declarative programming languages and data structures are abstractions of the real world that help us express the real world in code. We need abstractions because real world problems are difficult and complex, so we model them in programming code with abstractions that help us, humans, put into words (code) what it is that the computer needs to do to solve a problem.
Data structures are another abstraction that help us think about and work with data in the same way. They are a simplification, a categorization of data that helps us group and manipulate data in a way that helps us understand the data we need to be processed, but also to structure the data in way so it can be processed by our code.
Do you need to study and learn things like data structures to be a developer? Maybe not. But having a common set of problem solving tools makes it easier to approach specific types of problems and talk about how to solve these types of problems with other developers when we have a shared understanding and basic set of knowledge that we work with.
Getting started with small team software development projects at school
Interesting question I saw asked on Reddit recently – “what tips do you have for getting started on a software development project with a small team for school?”
The interesting thing about this question is that the recommendations are not much different from practices and approaches you would use for any ‘real world’ development project with a team.
Here’s some things I would recommend:
- Host a shared repo somewhere, for example Github or GitLab. Watch some intro videos on how to use git, how to clone a repo, how to commit and pull changes
- Establish who on the team is working on what, even if it’s just a list of features and then you divide them between the team. This sounds obvious but it will avoid confusion and wasted effort from more than one developer on the team working on the same feature.
- Think about the structure of the app and how you will be implementing different features, Worst case: if you have a single Class with all your logic in a main() method, how are multiple developers going to work on this at the same time (hint: this will make things very difficult)
- If there is a basic skeleton of the app put in place at the start with placeholder empty methods with ‘feature A goes here’, that will make is easier for each developer to go off and work on their part. Even better if using an OO language, thing about your Classes that will represent your solution.
- Encourage everyone on the team to commit their parts back to the repo often, daily, if not more often. You don’t want devs on your team to go away for days and then commit a ton of code in one go. That will lead to unpleasant surprises
- Encourage use of unit tests, they’ll help not only you to understand that your code is working, but allow the whole team to run tests for the parts they’re not working on and confirm that the addition of their changes has not broken something else in the system.
- Think about how you’re going to build your code as a whole, and how/where does it get deployed?
- How are you going to manage your library dependencies? Set up the project at the start using Maven or Gradle. It will make it easier for everyone to pull in the right libraries and the right versions.
For a small team and for a school project this is a good start.
Restructuring / refactoring my Mastodon ZorkBot
Now my ZorkBot is working over at @zorkbot@botsin.space I’ve restructured the 3 Lambdas so it’s easier to follow what calls what.
In it’s current/initial working state, I built it with 3 AWS Lambdas:
mastodon-zorkbot
This Lambda runs every 5 minutes, checking for players messaging the bot
- checks for last replied to messages so it only replies to a message once, using a DynamoDB table
- if a new reply is needed, sends the game move command from the player to the next Lamdba, mastodonbot-aws-sdk2
- replies to the player using the Mastodon APIs
The Lambda is deployed as: mastodonbot-zorkbot-dev-mastodon-reply
mastodonbot-aws-sdk2
This Lambda is called by mastodon-zorkbot, and provides parsing of the text responses from the frotz Custom Runtime Lambda, which is calls next
custom-lambda-zork
This is a Docker image for a Custom Lambda Runtime that invokes the frotz binary. This is the zmachine game runtime that runs the Zork game. It could be updated to run any game supported by frotz. The Custom Runtime has a shell script that pipes echo commands into frotz, captures the response and retuns to mastodonbot-aws-sdk2
The Refactoring
For first steps I’m just going to rename the folders of each of the Lamdbas and the serverless.yml service names so it’s easier to track what calls what in sequence:
mastodon-zorkbot -> zorkbot-1-mastodonreplies
mastodonbot-aws-sdk2 -> zorkbot-2-responseparser
custom-lambda-zork -> zorkbot-3-frotzcustomruntime
Will update later with progress.