Let’s look at a few ways we can name our database fields. This is mostly subjective, with some personal opinion mixed in for added velocity. Naming tables To me, this is straight forward. All table names should be lower snake_case e.g. account_names or account_email_options. Table names should be plural e.g. accounts, people, emails, settings, etc. This slightly breaks down for words where the plural is the singular, for example series.
Databases are magic from my perspective. They take in queries, find all the information you tasked it to find, and POOF. In the blink of an eye, there it is, all packaged up nice and neat. Or it blows up in your face, but that never happens, right? Let’s take a look at some steps we can take when things are not not returned in the blink of and eye.
I love projects where I’m learning something new, don’t you? When I get in a project, I want to be learning new things on a regular basis, otherwise I grow restless. Lately, I’ve been on a pretty big project for a client designing a backend system (GraphQL + Node.js + Postgres). I can’t go into too much detail, but we’ve leveraged Postgres as our main data store and in the process we’ve had to level up on our Postgres skills.
I love PostgreSQL, always have. I remember, it was easily more than a decade ago, when I first ran into PostgreSQL (PG). It seemed all major open source projects used MySQL. When I learned PG was also open source, plus had more SQL compliant features, I knew it would someday become the defacto open source database. At the time, the client tools, support, and pure speed were not there, but the foundation for a great product existed.
Back in 2012, there was a new way to build web apps fast and packed full of features. It was MEAN. MongoDB, Express, Angular, and Node. I built a number of apps with this technology, and it worked. However, as time passed they began to show their weaknesses. Today we’ll look at a few lessons learned from MongoDB. What MongoDB Kicks Butt At Most technologies cannot be just dismissed outright, even though you read article after article telling you “Why you should not X”.
As a hip, cutting edge developer, you’re using Hugo to generate your blog or website. Wordpress… pssh, you’re way too cool for that. Being cool has its complications though. How and where should you deploy your Hugo app. Should you push it locally using rsync or some other fancy means? Whatever. This simple post is going to show you how to deploy your Hugo app using Gitlab’s Continous Integration feature.
What is Gitlab An alternative to Github with many more features and an increasly better offering Free Private Git Repositories On of Github’s price points is to offer you a limited number of private repositories. You want more, pay more. Then Bitbucket came along and offered free private repositories, but limited the number of people you could share those repositories, it made for some weird accounting at the end of the day.
In recent months I’ve been working to add Apple Pay for Web to a major clothing retailer. One of the requirements for Apple Pay for Web is that the connection must be over HTTPS. Most of the time when I’m developing locally, I do not use HTTPS. Local, meaning the application code is running on my laptop. In most cases, HTTPS is just run in staging and production environments and not handled directly by your app code.
This is the best way I’ve found to set up for a container to contact the host machine. sudo ifconfig lo0 alias 172.16.123.1 Now you can use the IP 172.16.123.1 to contact your local host machine. Might want to store that in an environment variable. Note: I had written a much longer, more indepth post, but a few unfortunate key strokes in Vim obliterated much of the post…