Using Match – Bob Revisited

We return to our Bob experiment and increase his version number twice!

TRY AGAIN in Scrabble letter - as I try again with an Exercism task, this time using match.
Wait, “TG”? That’s not a word! Challenge!

Remember Bob from a previous post – our tiniest of AI-responders? I got feedback from the Exercism tutor that I had avoided one of Rust‘s most versatile of operators and I should think about using match. So, not to be a jerk, but just to see if I could replace ALL of the ifs in my method, I quickly came up with this solution.

Switch to Using Match

pub fn reply(message: &str) -> &str {
    let message = message.trim();
    let question = message.ends_with('?');
    let any_alpha = message.chars().any(char::is_alphabetic);
    let is_yelling = message.to_ascii_uppercase() == message;
    let is_empty = message.len() == 0;

    match message.is_empty() {
        true => "Fine. Be that way!",
        _ => match any_alpha && is_yelling {
            true => match question {
                true => "Calm down, I know what I'm doing!",
                _ => "Whoa, chill out!",
            },
            _ => match !is_empty && question {
                true => "Sure.",
                _ => "Whatever.",
            },
        },
    }
}

Come On Bob, Get With the Rust

So, it may be my newness to Rust, but I’m not sure version 2 is “more maintainable” code than what I started with. I had thought this Exercism task was just about learning some string methods. Turns out, it is also about learning the match operator. Of course, you wouldn’t code any parser or AI this way anyway – this IS just for practice.

Another tiny thing the tutor pointed out, I did have let check_message = message.trim() in my earlier code. A more idiomatic way in Rust is to reassign it to the same variable, hence the let message = message.trim() in this version. My guess is: less memory allocation, fewer variables for you to keep track of, and you aren’t able to incorrectly use the wrong variable later in the method. Actually, that probably isn’t a Rust idea – that’s just a good programming tip.




Bob With a Trait

Patterns are, I’m told, very powerful in Rust and that’s a big reason to start using match wherever you can. I’ve also learned a bit about traits and impls which I talked about in an earlier post. And that got me thinking maybe I’d work through the syntax to get it working with a trait instead. That idea led to this code.

pub fn reply(message: &str) -> &str {
    enum Quality {
        Empty,
        YellQuestion,
        YellStatement,
        AskQuestion,
        Statement,
    };

    trait HasQuality {
        fn has_quality(&self) -> Quality;
    }

    impl HasQuality for str {
        fn has_quality(&self) -> Quality {
            let message = self.trim();
            let question = message.ends_with('?');
            let any_alpha = message.chars().any(char::is_alphabetic);
            let is_yelling = message.to_ascii_uppercase() == message;
            let is_empty = message.len() == 0;

            match message.is_empty() {
                true => Quality::Empty,
                _ => match any_alpha && is_yelling {
                    true => match question {
                        true => Quality::YellQuestion,
                        _ => Quality::YellStatement,
                    },
                    _ => match !is_empty && question {
                        true => Quality::AskQuestion,
                        _ => Quality::Statement,
                    },
                },
            }
        }
    };

    match message.has_quality() {
        Quality::Empty => "Fine. Be that way!",
        Quality::YellQuestion => "Calm down, I know what I'm doing!",
        Quality::YellStatement => "Whoa, chill out!",
        Quality::AskQuestion => "Sure.",
        _ => "Whatever.",
    }
}

So here, we come up with the idea of a Quality trait and then we implement that trait for the built-in str primative. We’ve expanded what you can do to a str with our own trait! Version 3 of Bob really helps reveal some of the Rust thought patterns I need to hone.

Of course, I made sure Version 3 still passes all of the Exercism tests for this task. This change was approaching my limit of Rust knowledge to get it working without help from a book – just obeying every compiler complaint. However, I cranked this out much faster than previous Rust code, so I think some of this learning (and blogging) is sinking in! I surprised myself enough, that I posted this solution to Exercism as well. I want to hear what the tutor has to say about this method (no pun intended!). Now, I just need to remember to keep using match, traits, impls, and other Rust-supplied power!

Update: 2019-07-17 13:30

Woah, I just got some great advice from the Exercism tutor! You can match on a (expression, expression, ...) so check this out!

    impl HasQuality for str {
        fn has_quality(&self) -> Quality {
            let message = self.trim();
            let question = message.ends_with('?');
            let any_alpha = message.chars().any(char::is_alphabetic);
            let is_yelling = message.to_ascii_uppercase() == message;
            let is_empty = message.len() == 0;

            match (is_empty, any_alpha && is_yelling, question) {
                (true, _, _) => Quality::Empty,
                (false, true, true) => Quality::YellQuestion,
                (false, true, false) => Quality::YellStatement,
                (false, false, true) => Quality::AskQuestion,
                _ => Quality::Statement,
            }
        }
    };

It’s Not a Web Application Without a Database

The all important database ORM tooling… a light shining in the dark!

Part of a Series: Designing a Full-Featured WebApp with Rust
Part 1: Piecing Together a Rust Web Application
Part 2: My Next Step in Rust Web Application Dev
Part 3: It’s Not a Web Application Without a Database
Part 4: Better Logging for the Web Application
Part 5: Rust Web App Session Management with AWS
Part 6: OAuth Requests, APIs, Diesel, and Sessions
Part 7: Scraping off the Dust: Redeploy of my Rust web app
Part 8: Giving My App Secrets to the AWS SecretManager

Rack of hard drives perhaps attached to a database server supporting a web application
I think I just skipped a bit!?

What did we even use computers for before the Internet!? How much is your smartphone or laptop worth if you have zero Internet connectivity? What good is a web application without a database? Which is more important, the language or the architecture? The actors or the writing? These… are all questions… but one wouldn’t have a job without the other. Still, a web application needs a strong database layer but with abstractions to hide the raw SQL inside the code. So, we need to pick a database solution as carefully as we choose the programming language. True, that is, if we aren’t talking about the solution for our father’s VHS rental store and its single register (been there before!)

Don’t Spare the Database Layer

As a developer, the idea of Object-relational mapping (ORM) is about decoupling the low-level semantics of data storage and retrieval from the application code. An ORM abstracts database functionality inside your code just like a templating system abstracts HTML or JavaScript in your code. Everyone’s favorite, Stack Overflow, has a really good posted definition of ORMs along with the pros and cons of using one in a project. While you’re there, also check out Stack Overflow’s latest questions tagged [Rust] – maybe you can help someone out!

The ORM tools handle a big responsibility in app development. The Diesel crate has taken on this task for my sample app here at the beginning. With Rust and Diesel both being so new, I need to cut these tools some slack, but I also desperately want them to be fairly mature for the benefit of the language.




Sample Web Application Goals

Let me explain my concept for this sample app first – it likely won’t ever get finished, but that’s ok, it gives me something to practice with. A friend (check out his Kindle book, Seeing in the Dark: A Guide to Night Photography) and I came up with this idea over 10 years ago when we were scouring the local 200 mi radius for great places to shoot photographs. My 500px profile is filled with them – nearly all landscapes, I don’t do portraits or models.

Our idea came to be known as PinpointShooting.com (which isn’t a website yet, duh). Photographers could sign up for free and, using a Google Maps interface, indicate the best places to get some terrific shots. Some might be obvious, but there are some hidden places out there to spice up your photography.

Woman laying on stomach to take photograph, maybe my web application could give her some tips
She seems to be having fun!!

Handy tip: a photograph is often more interesting because it was taken from an angle or a hidden spot that no one else has picked. That way, your picture doesn’t look so much like a “touristy postcard.” That’s a reason photography books tell you to kneel or lay down or climb on things to take a picture. In fact, anything to change the normal viewing angle. What’s more boring than seeing a photo of a flower from 5′-6′ above? That’s the angle we see ALL the time, just walking around! Plus, that’s why photographers often refer to it as “making a shot” rather than “taking a shot.” There’s art involved above pressing the shutter release!

Back to the Database Chat

Anyway, enough about that – I need to store some data!! I’m sure this will expand and evolve, but this is what I’m thinking for tables so far:

  • Users – to store the free user profiles, passwords, email address
  • Locations – to store the address and/or lat/long of the good spot to shoot from that a user has shared
  • Photos – by users to store the pictures (or links to pictures) taken from a location in the database
  • Ratings – by users of the locations they have been to and if the agree
  • Likes – by users of the photos uploaded or linked to
  • Visits – to the location linking together a User/Location when they share a good spot, or a User/Photo when they upload/link one, or a User/Rating when they leave one

I start the DB design with some Enum types inside Postgresql. Most of these tables are going to have a status field with just a few possible choices. The enums turn out to be something that Diesel doesn’t seem to handle well (yet). In fact, I found a crate because of that fact. Wait… I take that back… I found 3 crates. Diesel-derive-enum has, by far, the most downloads, so I download that one. However, I only fooled with it a short time before I gave up. This is just a silly practice app, so I will switch to charfields. Well, they don’t work right away for me either, and it is getting late. I’ll just use some varchars which I already have a ton of.

A database was not the first thing to migrate, here are some birds headed south
Databases were not the first things to migrate!

Diesel Database Migration Tool

Diesel has a database migration tool to allow your project to record (and store in the repository) the entire path of changes the database undergoes during the product lifetime. It seems that tool name may have come from Rails – or there are only so many synonyms to choose from. I have used (and beat my head against) Sqitch and I’m just becoming aware of Skeema. Database schema management turns out to be a somewhat complex and fragile flow when you work with over 100 other developers in a fast-moving codebase. Because of the field issues I had (and because this project is ONLY me and is just starting), I reset my database to start over several times. In the end, I have a successful compile of the above DB structure abstracted into my code.

Diesel, btw, has a wonderfully impressive website to introduce you to the available functionality. I use the DBIX::Class module (often referred to as DBIC) with Perl, and it is as complicated as DB queries can become! But those are mostly the exception; DBIC generally abstracts the SQL nicely into some OO code to get me the data I need from the database. Most importantly, the Diesel Getting Started Guide is a great introduction to what using this crate is like. Plus, in addition to the normal crate API-style documentation, there are several other guides – some diving deep into the mechanics and benefits of Diesel.

I need to really get into some code to see how Diesel will be, but I have high hopes from what I’ve seen so far. A systems programmer (which I’m not) probably has far less need for the tools and add-ons that I’ve been playing with these past three posts. However, for big-scale web application development, most of these are key requirements!

More to come…

I hope all of these tools continue to develop with the pace of Rust itself, and I hope to get good enough with Rust that I can help out with some of the modules in the future! Once again, here’s the repository link to my code (at whatever state it exists when you read this post). I expect to have more to share about the PinpointShooting web application soon.

Edit: Meanwhile, go check out this fantastic post that looks at using Rust on both the front-end AND back-end of a web application! Web Assembly is hot right now, so this is a great read!

My Next Step in Rust Web Application Dev

Part II: I am impressed with Rocket and the add-ons and pile things into my sample web application

Part of a Series: Designing a Full-Featured WebApp with Rust
Part 1: Piecing Together a Rust Web Application
Part 2: My Next Step in Rust Web Application Dev
Part 3: It’s Not a Web Application Without a Database
Part 4: Better Logging for the Web Application
Part 5: Rust Web App Session Management with AWS
Part 6: OAuth Requests, APIs, Diesel, and Sessions
Part 7: Scraping off the Dust: Redeploy of my Rust web app
Part 8: Giving My App Secrets to the AWS SecretManager

Bridge Day 2017, New River Gorge, WV – a framework is important!

My previous post on working towards a shell of a Rust web application covered global, static application settings and logging. There is still, probably, a change to come to allow for structured logging. However, this time lets start with the actual framework I’m using. First I download Iron, but it doesn’t feel right and I notice it hasn’t been worked on for two years. That’s an immediate clue to keep looking, so I move on to another I have heard mentioned: Rocket.

Check out the podcast archives!

I’ve been listening to the archives of the mostly-discontinued podcast New Rustacean by Chris Krycho and, even though they are a couple of years old now (which is pretty old considering the pace of Rust), I still get an idea of where Rust started and how far it has come. Two episodes I just listened to – a 2016 episode about Diesel and a 2017 episode about Rocket – even helped me with this web application example I’m working on. It’s impressive these two Crates have continued getting updates and support after a couple of years. I’ll talk about Diesel in the next post, but for now let’s look at Rocket, plus some add-ons for templating, static web serving, web security, and interactive communication.

Rocket – Rust Framework

The Rocket crate received some high praise from Krycho in his “Crates You Should Know” episode and it seems the maintainers have continued with what impressed him. Rocket has a fantastic website and documentation guide making it a breeze to get started. The built-in route handling reminds me of perl Catalyst (how different could it be?). This feels very familiar. Here is my (simplified at this early point) implementation of getting Rocket started in my web application. The global static CONFIG I talked about last time continues to help here:

pub fn start_webservice() {
    // start rocket webservice
    let bind_address = &CONFIG.webservice.bind_address;
    let bind_port = &CONFIG.webservice.bind_port;
    let version = include_str!("version.txt");

    rocket::ignite()
        .attach(Template::fairing())
        .attach(SpaceHelmet::default())
        .mount("/", routes![routes::index])
        .mount("/img", StaticFiles::from("src/view/static/img"))
        .mount("/css", StaticFiles::from("src/view/static/css"))
        .mount("/js", StaticFiles::from("src/view/static/js"))
        .launch();

    warn!(
        "Listening on {}:{} as version {}",
        bind_address, bind_port, version
    );
}

Just as important as Rocket, in my view, are the capabilities added with the rocket_contrib crate. You can see some of them referenced in the chain of functions getting Rocket configured and running in my code above. So far, I already pull in the handlebars_templates, serve, helmet and JSON features.




rocket_contrib::handlebars_templates

I am pretty familiar with Template::Toolkit for use with Perl, but I’m only getting started with handlebars. Also, there is another rocket_contrib::templates option called tera templates. I mostly picked one of the two at random. I’m not yet to the point of working in HTML templates for this sample app, so this choice might change in the future. Who knows – maybe we need the option of a Template::Toolkit add-on as well!?

rocket_contrib::serve

Since Rocket builds-in the webserver funcionality (and I’m not sure I like this – I think I can front the web application with Nginx or some other service, so I need to look into that), I need it to serve local, static files (like CSS, Javascript, and images) as well. Rocket_contrib::serve handles this job for me with just some mount calls in the Rocket chain (see above). Again, I’m just getting set up, but this seems a good first step to get me going.

rocket_contrib::helmet

Security needs to extend past the coding language, of course, and rocket_contrib::helmet gives you a start at just a couple of HTTP concerns. The web is an absolutely crazy place – having read The Tangled Web by Michal Zalewski, I’m even more acutely aware of the convoluted and contentious history of web servers, web browsers, and the web languages we’ve ended up with, and I’m surprised things work at all! If helmet stops even one or two classes of those dangers, in it goes.

rocket_contrib::JSON

JSON is convenient to let the client browser (with Javascript) communicate back and forth with the server via (ahem) AJAX calls. I’ve included rocket_contrib::json just for this eventuality. Maybe there a more Rustic device or maybe this is still just “one way to do it”. I’ll learn more when I get to that point.

Ok, next up, we talk about the all-important ORM piece. I’m really impressed with Diesel so far, especially with the guide and documentation… but we’ll get to that with the next post.