So you think you want a website.

I have been helping some people set up websites recently and thought it would be good to explain the basic elements to putting up a website.

Domain registration.
This is done by GoDaddy, Namecheap, etc. It is where you pick your domain name. You can have multiple domain names for your site. That’s especially useful if your company has a long name, but you want an easier to remember website name. So if your name, is Old Towne Bike Shop and Brew, you might want to also register BikeAndBrew, Note that domain names are not case sensitive, so you can use caps like WellGolly.com to make them more readable. Be careful when you pick you name so that there isn’t something bad in the middle. My brother-in-law got a license plate for his Wild Horse Ranch but could only use 8 letters. WILDHORS just doesn’t cut it. Likewise, Dr Goode, Physical Therapist shouldn’t pick, GoodeTheRapist.com.

DNS – Domain Name Service
This is where you point the domain name to a specific IP address. Every device on the internet that communicates to the outside world has an IP address. The modem in your house has an IP address that is assigned by your Internet Service Provider (ISP). When you visit a website, you send along your IP address. When the website responds, it sends information to your IP address and your router then sends it to the device in your house or office that requested the information. Same thing happens with your phone when you are out and about. The IP address can change but you don’t want your websites address to change.

So when you buy a domain you need to point it to a fixed IP address so the world knows how to find you. You get that from whoever provides your server. Then you tell the DNS where to find the IP associated with your domains. My server 173.255.194.220. You can reach my server at this address and it sends you to the default site. There are many websites on my server and the webserver that I use (Apache2) sees that WellGolly.com is being asked for and redirects traffic to a folder on the hard drive.

You can use your registrar for DNS but I use the server provider—Linode.

Server
You can have GoDaddy host your website if you want. Lots of people I work with do that. Or you can have your own PC. I used to do that but now it is much cheaper to use the cloud. I share a machine with others but to me it looks like I have the machine all to myself. Some of my domains are at Linode and some are at Digital Ocean. Large companies use Amazon AWS, Google, or Microsoft. There are many many alternatives for all budgets and loads.

SSL Certificate
The lock button on the website means that traffic is encrypted from my server to your computer. It assures that the traffic is not messed with and no one knows what you were reading. All they know is that you visited a site. You used to have to pay a lot for SSL certificates but now you can get them from Cloudflare or Certbot for free. I use Certbot. This doesn’t verify that you are a legitimate company, just that the traffic is encrypted. Banks and big retailers use other services that also verify the identity of the company.

The actual website.
I use a combination of code and WordPress for my sites. The nice thing about WordPress is that I can set up people to use it and they can’t do anything else on the server.

You can get all five of these services as a bundle from lots of companies—GoDaddy, Squarespace, Wix, WordPress, etc.

WordPress site health
I am running the server on Ubuntu 18.04.4 LTS which means that I can update it regularly until 2023 and nothing will break. There is a new Long Term Service version that just became available and I am testing it on one of my servers. It updates PHP but I don’t need any new features so I haven’t updated it on this server yet.

On one of the sites that I host the user was concerned that the WordPress Health Check flagged imagick PHP module as a recommended performance improvement. Apparently one of the plug-ins that they are using for uploading images works better with it. I installed it from the command line using sudo apt-get install php-imagick.

It also noted that there were plug-ins that weren’t updated. I don’t have automatic updates enabled (I actually don’t know how to do that.) but you can update the plugins by looking for the red number next to the Plugins tab.

They also got a few Critical Issues. The REST API encountered and error and Could not complete loopback request. These errors are due to either a problem with a plug-in or conflict between plug-ins. If the site works, just ignore them. Otherwise, disable plug-ins until the error goes away and then figure out how to fix it.

Site Metrics
If you want to use Google to track the site, there are plug-ins that let you do it or you can copy the code and I can out it on the site. One benefit of using Google for tracking is that you know they have indexed your page.

You can Google how to do it, this page seems reasonable.

Matomo also has a plug-in that avoids having Google spy on all of your traffic.

Updating WordPress from the dashboard.

I have a bunch of old WordPress installs that I manage. I have been updating them from the command line and updating plug-ins by dragging them from my desktop to the plugins folder using Cyberduck. There is an easier way but it requires a few tweaks to your install.

First you need to change the ownership of each file to www-data. I also change the group to the users group.


sudo chown -R www-data .
sudo chgrp -R user .

Then you need to add a line to the wp-config.php file. I added it to the last line of the file.


/* Sets up direct method for updating without FTP */
define('FS_METHOD','direct'); 

Now anyone with a dashboard login can update the site.

Perl Date and Concatenation

I’m working with a legacy script that needs the date in YYYY,MM,DD format and the original programmer went through some contortions to get MySQL to calculate the date and report it out. It seemed to me that perl should be able to do that easily. In fact, it can.


my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime();
my $perl_month = $mon + 1;
my $perl_year = $year + 1900;
my $perl_today = "$perl_year,$perl_month,$mday";
my $perl_today2 = ($year + 1900) . "," . ($mon + 1) . "," . $mday;

if ($DEBUG) { print STDOUT "\n Perl thinks today is: $perl_today, $perl_today2  \n"; }

Perl thinks today is: 2019,12,13, 2019,12,13

Perl can do the arithmetic, but you need to put the calculations in parentheses. If you don’t it gets confused and outputs 2020,13. Note that localtime() gives the year as an offset from 1900 and the month starting with January as 0—much like array notation.

wget

Occasionally I run across a site that has a bunch of PDFs that I want to read. This wget lets me download them for later reading.


wget -r -np -l 1 -A pdf http://example.com/pagewithpdf.html

If you want to use the downloaded website for local browsing, you will need to pass a few extra arguments to the command above.

wget -m -k -p https://example.com

Understanding User Requests

bobwaycott at ycombinator made a comment that summarizes my thoughts on developing software for end users.

Always. I’ve been practicing this for 10 years, most of which I’ve been working as a consultant building custom software for internal business processes, as well as customer-facing software for clients’ users. My typical process looks something like this when a feature/change request or random idea is asked for—which almost always comes in along the lines of, “Can we get X added in that does Y and looks like Z?”:

1. I never say yes to any request immediately. I always tell a client, “Anything is possible that doesn’t violate the laws of physics, but let’s dig into this more.”

2. Ask what they’re trying to accomplish. What problem are they trying to solve? What mistake are they trying to prevent? What is the end goal? I ask questions until I can explain back to the customer what they’re really wanting to do and why.

3. I the push back on why I think we should not do what they’re asking for in the way they’re asking for it. When doing this, I always try educating them on the tech behind the scenes, potential pitfalls, how adding something (especially if it’s visible to people) will make it nearly impossible to ever remove it once users get used to it, when they’re asking for something that would be more effort the way they’re asking for it to be done than it’s worth when it’s trying to solve for a rare edge case, etc.
4. After explaining the problems with their idea as given by non-experts, I start suggesting ways we could accomplish their goals with a simpler UX, or even no UX at all, relying on the ability to automate things if we have enough information, or hide all the complexities of a process behind a single button once we have the right info to intelligently take action.

5. I give a couple of recommendations for potential ways forward that solve the real problem in a way I’ll enjoy building it out. Then I let them make the choice.

Following this pattern has pretty much never failed me. What feels best about it is when I see clients actually learn how their software works when I’m working for them. I love it when they remember the discussions we’ve had, internalized it, and recall it when we talk 6 months later about their new idea. Over time, their ideas improve because their understanding of how their software works improves. They also become increasingly invested in our working relationship as their trust in my concern for solving their problems—and not just doing their bidding—increases.

Never shy away from challenging your customers’ ideas—but always do it in a respectful manner that gets to the heart of their real problems and educated them along the way. They’ll appreciate it, and will keep coming to you for more. I don’t think this is unique to being a consultant, either—the same sort of process can be followed with direct users of your own product