Rust

Hi,

Today I will finally go over how I used the lazy_static crate to help the compiler keep regex optimised.

Recently, as I work my way through learning bits of rust, I have been thinking that I should in corporate some form of input validation for domains.

Today I will look at two crates.

In the previous article in this series I went through some basics of documenting your rust code. I had hoped to be able to take advantage of another nice feature of rust. That being the fact that code examples are actually tested by rust. I will go through the changes I had to make for this to work.

Hi.
As with all projects. It’s important to create documentation. This is, as we know, very important when creating code. When we come back to a project after a break, or if someone new takes over. Documentation will help you remember or learn what the code does. The thinking that was behind certain decisions.

This is a quick followup on my progress in deconstructing SPF using Rust.
Today I was able to implement both A and MX mechanisms.

Hi. In my previous article Looking at Regex in Rust. I covered some basics. Today I will go over some new things that I have learned, as I expanded on things that my regex expression needs to handle. In particular the need to handle the possible existence or none existence of qualifiers +,-,~,?.

If you have been following this series, you might know that I am playing with SPF records. I have turned my eye to a and mx mechanisms. As I started looking at the a mechanism. I noticed that my current approach using the standard string functions would probably be fairly difficult to implement. So I started to think about using the Regex crate. So this will be a look at how that went. The challenges and the things that I took away from the experience.

As I work through learning rust, I figured it was time to to start doing actual testing.

Why Test

Simple, it’s really essential when building anything beyond a few lines of simple code. Being able to run a series of reproducible tests as you develop; allows you to ensure that changes you make are not breaking exisiting code. You also have the option to develop using TDD.

Of course I have not adhered to any of this as I explore the basics of working with rust. But things are progressing and I should now see how testing basically works in the world of rust.

We often start small coding projects, and we often tend to start them off in a single file. But sometimes, the project naturally grows larger and more complex. The code thus becomes more difficult to manage in a single file.

At these times we often need to break the code up across multiple files so that we can focus on a particular functionality. This is where I found myself as I am toying with my SPF code.

As I mentioned in my previous article Deconstructing SPF Records with Rust. There is a case for using generics given the amount of overlap between the different mechanisms.