Programming Languages are tools. Learning a tool doesn’t make you a developer.

If you learn how to use a saw and a hammer, that doesn’t mean you are able to build a house. Saws, hammers, screwdrivers – these are all tools. How you apply them to solve a problem (when and where) are techniques. There are multiple techniques you need to learn in order to understand how to build a house. While you still need to know how to use your tools, there’s fundamental concepts that you need to learn first, such as carpentry, masonry, and plumbing. Similarly, learning a programming language like JavaScript does not make you a programmer. You need to learn techniques for how to apply the tool to solve problems, not just learning the tool.

Tools can help you apply techniques and concepts, usually either in saving time or effort, or making a task easier than performing the task with your bare hands. Without a knowledge of these fundamental concepts you could certainly attempt to build a house (“I know what a house looks like so I know how to build one, right?”) and while you might end up with an end result that looks like a house, it will probably won’t be safe to live in. After the first winter storm you’ll probably find your roof leaks and you’ll be lucky if it’s still standing after being subject to strong winds.

Practice Makes Perfect

Knowledge of tools, concepts and techniques still does not mean you can apply them competently. Following with the house building analogy, if you read a book on house construction, could you successfully (and safely) build a house? Maybe. If you get your first job on a construction site and get some experience in house building and learn how to apply the techniques you’ve picked up from studying your house building book, it’s more likely for your next construction job you’ll be able to apply the knowledge and skills you’ve learned. Over time you’ll get advice, see what works and what doesn’t work, pick up tips and techniques that can save you time, growing your experience and competency.

Software development is no different. To improve your skills you need to get feedback on your work, you need to get advice on areas where you can improve, but just as importantly you need to practice your skills.

There’s commonly quoted advice that it takes 10,000 hours of practice to become and expert at anything. This has to be deliberate practice with the goal of improving your skills. For software development, spending 10,000 hours writing the same line of code over and over is not going to help you at all in becoming a better developer.

Don’t get caught up in comparing the pros and cons of different languages, or wanting to learn a specific language because you read it’s the ‘best’. Once you’ve learnt one you can more easily learn others. Spend time learning techniques and approaches to solve common problems. Learning a tool can be beneficial, but it’s not particularly useful if you don’t know how to apply it effectively.

Debugging is a key skill – spend time learning how to debug

All too often I see new developer focusing on learning how to write code, but not spending as much time learning how to debug code. Knowing approaches to help you find why code is not working is just as important as knowing how to write the code in the first place.

There a too many questions posted online that look like this:

“I’ve written this code but it’s not working and I don’t know why”

My first question is always “have you stepped through the code to understand what the code is doing?”. Many of these types of question and issues can easily be resolved just by using a debugger, stepping through the code and validating that each step does what you expect. As you are learning development skills, a lot of issues in code are from assuming the code is doing one thing but the way you’ve implemented it you have a subtle difference somewhere where you didn’t initialize something, you referred to the wrong variable, or the logic in an if statement is incorrect. Stepping through the code will help you find the point where everything’s working up to the point where there’s an issue.

Spend time learning how to use your debugger in your IDE of choice. There are of course many other complementary techniques to debugging code, like logging and trace statement, unit testing etc, but don’t overlook the usefulness of your debugger.

[Top tip series: rather than spending time writing lengthy articles over several days I’m going to try and post shorter, hopefully useful tips more frequently]

Connecting APRS apps to a software TNC over your network

A useful feature of Direwolf is that it exposes an AGWPE port on your local network that you can connect to across your local network. I use this feature to run an APRS app on my laptop elsewhere in the house with Direwolf running on a Raspberry Pi beside my 2m radio in my office upstairs.

With the YACC APRS app, this is as easy as adding an AGWPE port in the app and pointing it to the IP and 8000 port of the Raspberry Pi where Direwolf is running:

Revisiting Packet Radio on a Raspberry Pi with Direwolf: part 2 (minimal installation)

This is a continuation of part 1 here. To summarize the required steps to setup ax25 and Direwolf for software based packet radio, here’s the minimum steps need to get up and running:

Install libasound2-dev and libudev-dev:

sudo apt-get install libasound2-dev
sudo apt-get install libudev-dev

Clone the source for Direwolf, then build and install:

git clone https://github.com/wb2osz/direwolf.git

Compile and install Direwolf (build steps changed recently):

cd direwolf
mkdir build && cd build
cmake ..
make -j4
sudo make install
make install-conf

Plug in a soundcard device like a Signalink or Rigblaster, run ‘aplay -l’

Get the device number, in this case my Rigblaster is 2,0:

card 1: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: Audio [RIGblaster Advantage Audio], device 0: USB Audio [USB Audio]
Subdevices: 1/1

Configure ~/direwolf.conf – change ADEVICE to refer to the device number from the previous step:, and then set your call sign:

ADEVICE plughw:2,0
MYCALL KK6DCT-5

Run alsamixer, select your soundcard attached to your radio, and make sure playback and capture sound levels are around 70% and not muted:

Install ax25 apps and tools:

sudo apt-get install libax25 ax25-apps ax25-tools

Add 1 line in /etc/ax25/axports – the number in the first column is the port number, you’ll need this in the next steps:

1 KK6DCT-1 1200 255 2 2m packet

Run:

direwolf -t 0 -p

Look for the last line for /dev/pts:

Ready to accept KISS client application on port 8001 ...
Virtual KISS TNC is available on /dev/pts/0
WARNING - Dire Wolf will hang eventually if nothing is reading from it.
Created symlink /tmp/kisstnc -> /dev/pts/0

Run kissattach:

sudo kissattach [/dev/pts/value here] [ax25 port value here]

e.g.

sudo kissattach /dev/pts/0 1

You should see:

AX.25 port 1 bound to device ax0

Now you’ll set to use the ax tools to connect to other nodes, for example, run:

axcall [ax25 port number] [nodename]

Done!