Prototyping With Rails #

About a year ago I had to step back into my family business due to a death. During that time I was operating the business while trying to figure out a new owner I was looking at trying to stream line a process that had a pain for many years. It was a fairly simple problem to solve and I had used multiple CRMs geared towards our industry, but none of them had this one feature. So what did I do? I decided prototype an application to see solve my frustration. As a business owner…terrible idea, but as a programmer..typical! Normally, I would reach for my normal dotnet stack, but I wanted to try out the new Rails 8. This has been the inspiration for the recent Rails posts, and now I want to share the project.

Query Performance #

As Dotnet developers it’s very common to use ORMs like Entity Framework to work with databases. While it’s not the most performance tool, it’s extremely useful and flexible to use. With that it’s important to remember that the methods we use can change the performance of the query. Whether to use a Where followed by a FirstOrDefault or should we just use the FirstOrDefault? And what kind of query statement will either of these make?

It’s optional name parameters…thank you for coming to my Ted Talk

Here’s why #

While there are many features I would like to be added in Typescript there is one major one that needs to make it’s way over from C#. That would be optional named parameters. At this point I’m not sure how this hasn’t been added into the language. Personally, I used it a lot when writing in C# and I’ve ran into a few self inflicted bugs that named parameters would have prevented. For those who don’t program in a language that has named parameters it allow you to specify the parameter when calling a function or method.

Introduction #

After coding for a while and making more mistakes then anyone wants to admit we as programmers tend to create a spidey-sense of potential issues when doing code reviews. This is one of the primary reason we as an industry do code reviews. It’s commonly called “code smell” - when we see a pattern or code usage that seems off. A few months ago I ran into one of these and wanted to highlight the usage, because I see even experienced software engineers fall into this common practice. I would like to highlight that while good practice in theory is commonly agreed upon, people get lost in the details. That’s ok as long

Keeping data clean #

One important aspect of managing data coming in through our api(s). Of course this is what data types and validation is for, but an easily overlooked aspect is handling strings and how we want store them in the database. It’s an easy oversight for anyone who hasn’t handle a large amount of data that is being used by multiple teams. An easy example is when two systems are comparing an email, but one system didn’t trim any white space and the user inputed their email with a space at the end. Sounds simple, right? It happens much more often then you’d think. We don’t want to add a lot of extra logic every time we compare strings to ensure there isn’t any white space unless absolutely necessary. Which is why it’s important to add logic to handle this on every request - which is pretty easy with Dotnet.

Catching Up #

It’s been a couple years since I started this blog and there hasn’t been much progress. There is a couple different factors but the main one has been focus. I’ve been working Ritter Insurance Marketing since 2017. I started there a junior front end developer and in 2020 I moved over as a back end developer. Working primarily on back end services written in Dotnet. I started this blog a couple of years ago to try write down my thoughts and some experiences, but obviously didn’t keep up on that.

My Experience Building A Rails App As A Dotnet Developer #

I use to write a lot of rails applications when I was newer as a developer. Fast forward almost a decade later with professional experience, I thought I would look into rails again. I’ve slightly followed the progression of rails over the years and agree with some points of DDH’s. Main about JavaScript and how it’s become overly complex for web apps. Although, I personally love static type languages. I know shocker - coming from a dotnet developer.

Connecting your Rails application to a database #

Rails default setup uses sqlite which is a great way to get starting building applications, but at some point we will need to connect to a real database. Whether you need functionality that is specific to a certain database, or you want to simulate your production environment more. Connecting to a database is pretty easy with Rails. The first thing you will need is a database installed on your computer. For my apps I primarily use Postgres and pgAdmin as my GUI.

Handling CORS with Gorilla Mux #

In an earlier post I talked about create an API with golang using a few packages. One of the main ones packages many people use is mux for routes. This makes it easier handles routes within our application. Now we need setup our application to allow certain sites to talk with our api. Luckily Gorilla has another package that integrates seamlessly with Mux.

Golang First API #

I have been following Golang for a little bit. It seemed interesting to me for a few reasons. One major one was the speed of it. Another was it’s syntax is similar to python. I am no python developer, but I have made a few side project with it. SO I decided to update and an aging Rails application. It’s just a simple crud application that displays martial arts rings at tournaments. While I could write the entire website with Go I opted in to make an api. The reason is I want to make a React site and mobile apps made with React Native. It’s a pretty simple rest API that needed to connect to a database. I used a few packages to make development practical