Skip to main content

Kiai ("key-eye") is a published author, writer, editor, and presentation specialist with advanced computer application, filmmaking, audio engineering, and public speaking experience seeking to advance social equity. Kiai thrives on self-initiation and autonomy, is able to design and develop effective communications, and can enhance the presentation of substantive content.

motorcyclebaby.com

reverbnation.com/kiai

alphadogthebook.com

Kiai Kim

Github.com for Command Line Users

5 min read

Why would anyone who knows how to use git on command line care to use Github? Sometimes, it's not worth cloning an entire project to make a simple change to a project when it's hosted on Github. In such cases, the Github interface makes editing easy.

If you use git on a command line, but have never used Github online, Github.com might seem foreign. This might be the case even if you've used Github Desktop. You could go through the Hello World tutorial to learn how to use Github's web interface, but it doesn't spell out all of its functionality.

Probably the most important thing to note is that the buttons don't exactly do what they say.

Clone git clone

The bright green button on the right side of a project repository's main page -- not to be confused with a Github Page -- says "Clone or download". But there is no local repository when using Github.com, so there is no replicating the remote repo onto your local drive. Rather, files are downloaded onto your computer not including the repository's hidden identification data necessary for a proper clone. Even Github Desktop enables actual cloning and supports local repositories.

No staging

Github.com has an editing interface, which in essence copies files into a web cache as if the text editing box is a staging area. Files can also be downloaded and edited with a favorite editing program. When files are ready for commit, they are uploaded or their contents pasted into the web interface. No add necessary.

A pull request git pull

On the left side of the project page is a "New pull request" button. Normally, git pull runs a fetch and merge. But there is no git fetch, and there is no local branch to merge. Github should call this button "New merge request" since the function is calling for a merge of remote branches or same-branch file edits. Naturally, a merge would call for a comparison.

Compare = diff

It's intuitive that compare is the same as git diff, but it's not intuitive how to get to the function. To compare files, choose "New pull request". There are three types of diffs that can be examined from this page:

  • Branch -- This default view shows buttons that initially appear as base: master and compare:master. Clicking on either of these allows users to choose different branches. Users can also compare files on branches' timelines. For example, base: [email protected]{1day} vs compare: mybranch will show commits on mybranch from 24 hours ago through the latest, or commit marked HEAD.
  • Fork; click on the link compare across forks to compare a project with a copy or fork of itself.
  • Commit; click on the base: branch and compare: branch buttons and a box appears where commit numbers can be inserted. This allows users to compare commits of files on the same or different branches.

Two consecutive commits of a file can also be compared by clicking on the file's History button.

Branching

With command line git, you can use git branch to create your own branches for your work and then commit and push only the branch you want. With Github.com, since there's no local repository, there's no local branching. Though one can simulate branching by simply copying and editing, these branches would have no markers or configurations to identify them.

Instead, branching is done on the Github repository, otherwise known as the remote repo. To create a new branch, create, upload, or edit a file; and then check the radio box under your commit message where it says "Create a new branch for this commit and start a pull request."

Tracking

To track who made changes to files, click on a file's Blame button.

Being a Contributor

You might not be able to push or merge your contributions if you're not the owner of a project. Based on Github documentation, there is one Owner and there are Collaborators, or Contributors. Owners can protect branches and prevent other Collaborators from pushing changes to them. In such cases, a contribuor may only commit and make merge requests (poorly referred to as pull request). Github's documentation is not perfectly clear on which functions are accessible by what type of user. A little digging through a project's settings reveals that users can be designated as Administrators. However organized, accessibility of functions is generally set on the project's Settings page via Branches and under "Protected branches".

Buggy by design

One thing to be careful of is losing work between merges. It's not exactly clear what happens, but Github seems to miss some changes in its diff function. This might have to do with the lack of identification of local files. Or maybe Github.com doesn't automatically point HEAD to the latest commits, like when branches are merged. Whatever the reason, the Github.com user interface seems limited in its functionality. Because of this, beware.

The rest is self-explanatory

Hopefully, the rest is easy to figure out. For example, to use git init, click on the plus symbol on the upper right and choose "New repository". Just remember that the web interface does not support the use of local repositories, and as a result a lot of git functions are not accessible through it.

 

For more about git check out this blog.

Kiai Kim

How to Move a WordPress Site from one Webhost to Another, like Dreamhost

23 min read

Recently I migrated motorcyclebaby.com from my old webhost to Dreamhost trying to follow Dreamhost's instructions. It wasn't exactly easy to follow.

I tried to keep other computer platforms in mind while writing this, but it's next to impossible to include everything without writing a book. So, I keep it geared toward Mac users and Dreamhost and hope it's still useful for others. This article is still painfully long.

A word about moving a WordPress site

There are two ways to do move a WordPress site:

  1. Build the site from scratch on the new server and import your content through the WordPress interface; or,
  2. Copy over the database and files from the old server into the new server and reconfigure.

The first method is needed if your moving from WordPress.com's server onto a self-hosted site, or from some other corporate-controlled service like Web.com. Detailed instructions for this can be found at move.wordpress.com. The only thing these instructions don't tell you how to do is transfer an edited theme or theme-child. For this you will need FTP or secure shell access to the old host in order to copy the theme-child's files. But if you're able to access the old host's files and their database, you can also use method two.

If you want a new look to your site, going with the first method is easier, since you probably won't need the theme files. But if you want to replicate the old site, the second method is the way to go. And that's what I'm detailing here with special attention to using Dreamhost, my favorite webhost. This article might as well be called:

How to Replicate your WordPress Site onto Dreamhost with a Unix-based Computer, such as Mac

There are multiple ways to replicate a website. While moving my site using the same domain name, I tried to go via the path of least resistance and needed to refer to multiple sources. The following compilation of those sources requires:

  • A hosting account on the new, destination server
  • Access to your website's database via secure shell (SSH) on a command line program like Terminal, or phpMyAdmin with username and password. Command line use is imperative for importing on Dreamhost if your database backup is larger than 64MB.
  • Access to your website's files via SSH, FTP, or other file management interface
  • One-click installation of WordPress on the destination server

Hosting companies like GoDaddy make it easy to reach their database servers or turn on SSH access through easy-to-use interfaces or dashboards, such as cPanel or Plesk. Check the interface for links and buttons labeled with any of the keywords used in this post. On Dreamhost, FTP (file transfer protocol) can be accessed on the Domains panel, and phpMyAdmin (the MySQL database interface of popular choice) on the MySQL Databases panel under Goodies; both require usernames and passwords, which will be different between the webserver and database.

If you're using a host other than Dreamhost, you can probably get away with using only that host's control interface. Hopefully it's intuitive, because this article talks about using command line.

A Note about One-Click Installs and Legacy WordPress Versions

If one-click install of WordPress is either unavailable on your new webserver or your theme is old and incompatible with WordPress's latest release, you will have to manually install the older version. In such cases, you can go to WordPress's release archive, find the version that's compatible with your theme, download it, and then unzip/upload it to the server. For BASH (Bourne Again Shell) users, there are instructions here that don't involve downloading and uploading. Without shell use, follow WordPress's instructions to create a database and update the WP-config file. Note that using old versions of WordPress might be insecure to hackers and worms.

For themes that are compatible with the latest version of WordPress, continue below for method two for migrating a WordPress site.

Step One: Back up your database content in SQL format

When you back up content, you need to store that content somewhere you can access. Your computer is a good location, since you're going to need it to restore your content on the new server.

To make sure your site is replicated exactly the way it appears on the old server, export your content in SQL format. You can export an xml version from the WP interface, but doing so does not always return your content the way you left it since the structure of your data might change in the conversion process. To export your content you can:

  • Use phpMyAdmin or other database interface to make a .sql backup, or
  • Use SSH to export the file

To use phpMyAdmin, after logging in, make sure you are in the correct database. The left column uncollapsed should show the tables of WordPress, which by default has the prefix "wp". See the image below (Figure 1).

Dreamhost's phpMyAdmin export page
Figure 1. The export page of phpMyAdmin.

You're not doing anything special with these tables, so just use the Quick export method and make sure the format is SQL. You will be prompted to give your export a name and choose a location to save it. If you want to use SSH later on, save the file in an easy-to-navigate location, like Desktop.

To export on command line:

  • Log in to the old server with ssh [email protected]
  • Backup using mysqldump -p -h hostname -u username databasename > backup.sql and enter the old database password
  • Exit the server by typing exit and enter
  • Copy the file from the remote server to your computer with scp [email protected]:filepath/backup.sql ~/Desktop

Step Two: Update your current site to the latest version of WordPress, or the version used by the new webhost

On the WordPress dashboard, on the Updates page, check to see if your version is the latest. If not, the Dashboard will tell you that a newer version is available. It will also tell you to back up your content, which you have already done if you followed step one. If your backup is saved in an accessible location, go ahead and update WordPress.

Hopefully, the new installation won't require an update to the database. WordPress will alert you and provide a link if an update is required. If so, update the database too to make sure everything works. Worst case scenario, at least your content is backed up. (Note: when a database is updated in this case, it means the software used to operate the database engine are updated. Nothing should happen to your content.)

Check your site to make sure everything looks as expected. You might want to check with the theme developer to see if there are any red flags with your theme or its parent. If it looks good and seems to work well, move on to step three.

Step Three: Save your current WordPress files locally

If your theme has been edited, i.e., is the child of a theme, you will need a copy of those files. You will also need your favicon (the little icon in the title bar on your brower) if you have one, and any other customized files. To make sure you get everything, select all of the files in your domain's folder on old server and compress it into a zip file. Do not select the main folder to compress but select the items inside the folder.

Download the zip archive to a place you can access later. If you need to use SSH later on and are a novice at it, save the file in an easy-to-navigate location. If you're using a Mac, save the archive under your Home folder. Desktop is a handy place. I saved my files in a folder called Sites, which used to be there by default in older versions of Mac OS, when it was more common for users to test websites locally on their home computers. As of OS 10.12, the sites icon will still appear for a newly-created Sites directory.

Step Four: Set-up WordPress on the new server

Hopefully at this point you will already have your new webhost set up. If you're new to this indie webhosting stuff, chances are you are using a shared server. (I tried to find a good article on "what is a shared server" and "how does shared hosting work," but couldn't find anything worth linking. I guess that can be another article.) Make sure you understand the file structure of your server space. As of the time of this writing, GoDaddy stores files under one hosting account under a single public_html file, its top level being the main domain's web storage location and subdirectories being additional domains' storage locations. Dreamhost files are organized based on the username associated with the domains under an account, which helps make domain management flexible and manageable. Though you're going to need two domains for this migration if you're using Dreamhost.

A note about using Dreamhost: Even if you are using a domain name on your old server, go ahead and add your domain to Dreamhost's Manage Domains panel. All this does is create a directory for your files. It will not be visible to the public until you either create a mirror of it or point your domain via DNS to Dreamhost. Also add a second domain using Dreamhost's dreamhosters.com. You can give it any subdomain name that isn't already being used. I used motorcyclebaby.dreamhosters.com. This second domain will be used to access your files.

If you want to use Cloudflare, do not enable it at this time. I learned this the hard way. Enable it during Step Ten or you may run into DNS redirect problems.

Once your domain's file location is created, navigate to the webhost's software installation utility. This is where you use one-click installation. On Dreamhost, it's under Goodies -> One-Click Installs. Click on the WordPress icon, choose your domain (but not the dreamhosters domain), have it automatically create a database, and click Install it for me now!. This should do three things:

  1. Install WordPress's files within your domain's folder
  2. Set up a MySQL database, accessible via phpMyAdmin or SSH
  3. Set up the WP-config.php file located in your domain's folder with all the needed database information

If one-click install is not available on your new server, refer to the links in the paragraph above under the heading A Note about One-Click Installs and Legacy WordPress Versions.

When the installation is complete, your new webhost should contain WordPress files with ready-to-go configuration in your server chunk's folder and a new database with WordPress tables like those in Figure 1. Unfortunately, you won't be able to look at the website yet.

At this point, nothing should work. Just kidding. At this point, WordPress on the new server will be ready for someone to log in and write a first post. But you're not going to do that. Instead, go to step five.

Step Five: Import your database content

If the site you are migrating is your first website on a Dreamhost server, you need that second domain mentioned in paragraph two in Step Four in order to log in via SSH or access the WordPress files via FTP. You won't be able to access your new server space with [email protected] since the domain is still pointing to your old webhost. More on this later. Next:

  • Retrieve the new database's username and password set up by the installation script. On Dreamhost, you can find these under Goodies -> MySQL Databases. In the middle of the page, under "Database(s) on this server", click on the username associated with your new database to retrieve the password.
  • Also make a note of the database name Dreamhost created. You will need this.

If your database backup is larger than 64MB, you need to use SSH to import your content onto Dreamhost's database. On other webhosts you might be able to use phpMyAdmin. GoDaddy's phpMyAdmin can import files up to 1.073GB; just log in to it and choose Import.

Next, for Dreamhost, you will need that second domain. Make sure the user for your two domains is the same. Dreamhost organizes your files according to User, and you will be able to access files for both domains with the same user. This is how to get around having your domain name on Dreamhost and uploading files for it even though DNS points your domain to your old server.

The following is how to import via SSH from a Mac and Ubuntu (sorry, I'm Windows-shell illiterate). Open Terminal, under Applications/Utilities. Then:

  • Navigate to the location where your backup is saved. If you've followed my suggestion at the end of step one, on a new line enter cd ~/Desktop. The tilda (~) is the notation for Home on a Mac and on Ubuntu
  • Secure copy (scp) the SQL file to the new server's database. Enter scp yourbackup.sql [email protected]:.. The ":." indicates location and the dot means here. The password is the same as your webserver password, but not the database. If the copying command is successful, a new blank line with $ will appear with no error messages before it.
  • Access the webhost's server with secure shell using ssh [email protected] and use the same password as the previous step
  • And here's the importing step... assuming your command line is where you uploaded the SQL file, enter mysql -h mysql.yourdomain.com -u username -ppassword yourdbname < databasefile.sql where mysql.yourdomain.com is the server name of your database. Dreamhost automatically creates the database with mysql as a prefix. Note that here you can use your domain name instead of dreamhosters, because at this point your command line is operating through the Dreamhost server. Also note that there is no space between -p and the database password. Ask Oracle why. IDK. Again, a blank line with $ and no error messages indicates success.

Step Six: Fix the WP-config.php file on the new server and save it

In an ideal scenario, the new WordPress installation would automatically connect to the your content. However, switching webhosts doesn't naturally present ideals. Chances are, unless you had a hand in its configuration, each database has tables with a designated prefix attached to their names. In Figure 1 (under Step One), the first several tables listed on the left have "wp_8494cc" as the prefix. This was auto-generated by Dreamhost's one-click installation scripts. Below those tables are ones with prefix "wp_" which incidentally was how I had set it up on the old server. (This pared down prefix is not recommended if you plan to use one database for multiple WordPress sites.) If your old server automatically created your database, it too will probably have some extra characters in the tables' prefix. These prefixes need to be matched.

  • On your computer, unzip, or uncompress, the WordPress archive you downloaded in Step Three and look for the wp-config.php file. Mac will create a new folder and place the contents of the archive there. On Linux, designate a folder with -d as in unzip yourarchive.zip -d foldername/.
  • Open wp-config.php with a text editor such as TextEdit and locate the line containing $table_prefix =. Make a note of the value. It should be or start with wp_.

For the next fixing steps, you can use your new host's file management interface if you want. On Dreamhost, log in to WebFTP as yourdomain.dreamhosters.com. Find wp-config.php and open it with Source Editor. Otherwise, on your command line:

  • Navigate to the folder where the WordPress files are located on your new server. On Dreamhost, it will be in a directory with your domain name. If you're not sure, enter ls for list to view the names of the files available. If you see a bunch of filenames with wp, you are in the right place. Otherwise if you see your domain name in the list, enter cd yourdomain.com. Hopefully, the WordPress files will be there. (Try ls again.)
  • If you see wp files, open the wp-config.php file using nano. On Dreamhost, simply enter nano wp-config.php. On other webhosts, you might need to add sudo as in sudo nano wp-config.php for which you need your server admin password. Nano is a text editing program recommended for newer command line users.
  • Once in editing mode, use the arrow keys to navigate down the file until you find: $table_prefix near the bottom. You can also use CTL + W and search for "table_prefix".
  • Replace the value after = with the value in your original WordPress configuration file, found in the second bullet of this step. (If the values are the same, then the site should already be working.) You will need to use the arrow and delete keys to edit it.
  • Use keys Control + X to exit and type Y for Yes to save changes.

You will need to preserve this configuration for the new server. So that this file does not get overwritten in Step Eight, type exit and hit enter to leave the server and use the command line locally. On a Mac, the line will contain your computer Home name and maybe the name of your hard drive. If your command line is not already in a good location to save the file, navigate to a good location, like cd ~/Desktop. Then enter scp [email protected]:domainfolder/wp-config.php . .

Step Seven: Prepare the saved WordPress files

For the sake of simplicity, let's prepare the entire WordPress folder so that you can copy the whole thing and put it on the new server. You will need to use the files that you uncompressed in Step Six.

  • Overwrite the old wp-config.php file that you unzipped in Step Six with the one you downloaded in the last paragraph of the previous step. To do this on command line type cp ~/Desktop/wp-config.php ~/yourUnzippedWPdirectory/wp-config.php.
  • Select all of the files in your unzipped local WordPress folder including the newly-replaced configuration file. Do not select the folder containing the files, but select the actual files and sub-directories. Otherwise, Step Eight won't work properly.
  • Compress the selection and make sure it's in an easy-to-locate directory. You can do this with command line. Use cd ~/yourUnzippedWPdirectory to go where these files are and then use zip -r Archive.zip ~/Desktop to compress the files and save the archive on your Desktop. (I don't actually use my Desktop for this stuff. I'm just trying to make these instructions easier to follow.)

Step Eight: Copy the WordPress files on the new server

Now let's get the whole thing working.

  • From command line, or Terminal, change directory (cd) to where your newly-archived set of WordPress files are located. If you need to go back a level, use cd ../. Two dots means back one level.
  • Upload the archive to the new server using scp Archive.zip [email protected]:domainfolder.
  • Log on to the new server using ssh [email protected] and enter your webhost's password (not the same as your database password).
  • Change directory to your domain folder using cd domainfolder/. You don't really need the slash; it's there to indicate that it is a directory and not a file.
  • Uncompress the archive using unzip Archive.zip. Doing this will unpack all of your files. Make sure that you overwrite what is already there. If the server computer asks you if you want to overwrite All, type A for all.

If for some reason you only want to copy the files necessary for your site to look the same, on the new server overwrite the images folder, the favicon.ico and favicon.gif. The wp-config file should already have been updated in Step Six. Copy in your theme folder located in wp-content/themes.

Step Nine: Check for problems before going live

Unless you've used a domain that's different from your original site, you can't just visit the domain to check if the new installation works. Some webhosts provide a way to view the files, like provide a server address to which you add your site's root directory or your username. But not Dreamhost. Dreamhost provides the ability to mirror your site and an article on how to do it. But these instructions don't tell you how to mirror a WordPress site which involves changing wp-options entries and database URLs. I don't think mirroring on Dreamhost is necessary. I tried it and eventually ran into WP problems. Instead, I updated my hosts file.

Edit your computer's hosts file to view your site on the new server before changing DNS records. What this does is direct your computer to whatever IP address you list for the domain you are relocating. To get this to work with WordPress, there are a few steps:

  1. Temporarily change your new WordPress configuration so WordPress doesn't point your browser to the old server. Using the source editor via WebFTP or SSH, edit wp-config.php adding define('RELOCATE',true); before the comment line that says "That's all, stop editing!" Since you are going to edit your computer's hosts file and not your server's hosts file, this is necessary.
  2. Temporarily edit your hosts file. To do this on Terminal, make sure your command line is connected to your computer and enter sudo nano /private/etc/hosts using your computer's administrator password. Add three lines to the bottom:
    111.111.111.111 yourdomain.com
    111.111.111.111 www.yourdomain.com
    222.222.222.222 mysql.yourdomain.com
    You can find the actual IP addresses on Dreamhost's Manage Domain's panel by clicking on DNS for your domain. These lines will need to be removed after you get to Step Ten. For now, go ahead and Control + X and type Y for Yes to save and exit.
  3. Flush your DNS cache with sudo killall -HUP mDNSResponder;sudo killall mDNSResponderHelper;sudo dscacheutil -flushcache. For flushing DNS in Mac OSs older than Sierra and Linux, check Dreamhost's article.

After the above three steps are complete, visit your domain. Hopefully it will all work. Something that I did to make sure I was on the new server was go into phpMyAdmin and make changes to the content. I removed fake subscribers from the Users list, and then checked through the WordPress Dashboard on the Users panel to see if they were gone. But you can make any simple change and check it.

Step Ten: Go live

If everything looks good, go to your domain's registrar and add custom DNS entries to your domain's configuration. For Dreamhost, add:

ns1.dreamhost.com
ns2.dreamhost.com
ns3.dreamhost.com

Don't forget to remove the RELOCATE line in your wp-config.php file, or else your site might end up in a redirect loop. Also remove the three lines added to your hosts file in Step Nine and flush your cache again. It might take several to 48 hours for the DNS changes to propogate.

Finishing up and adding SSL

Now is the time when you can activate CloudFlare, which helps your site respond faster, and SSL (Secure Sockets Layer), which can protect your password when you log in to WordPress but can also slow down connection. Oh well. Full instructions for this is another article, though maybe not as long, but here is a bucket list of requirements for activating these on Dreamhost:

  • Make sure on your WordPress dashboard that you have www on your URLs for both your WordPress and Site addresses under Settings -> General. This can also be checked through phpMyAdmin under the table wp_options under column option_names with values "home" and "siteurl". This is necessary for activating SSL on all of your WordPress installation and having it work with CloudFlare.
  • Edit your .htaccess file located at the root level of your WordPress installation. The dot before the filename indicates that it's a hidden file. From Terminal, in your WordPress directory on the webhost's server, enter ls -a to view all the files including hidden ones. Use nano .htaccess and add the following lines after </ifModule>:
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%(REQUEST_URI} [L,R=301]
    Control + x and save your changes.
  • Edit your wp-config.php file again. In the same place where you had added RELOCATE to view your new site in Step Nine, item one, add:
    define('FORCE_SSL', true);
    define('FORCE_SSL_ADMIN',true);
  • Turn on SSL. On Dreamhost, this is done on the Manage Domains panel. Choose Let's Encrypt, because CloudFlare won't work with WordPress if you use a self-signed certificate. Let's Encrypt provides a free company-backed certificate. You can also import a certificate or buy one from a verifiable vendor. Dreamhost offers Comodo-verified certificates.
  • Add CloudFlare. If you don't already have a CloudFlare account, you will be prompted to open one.
  • Log in on CloudFlare.com, choose your domain, and click Crypto. In the SSL box, the default encryption level is "flexible". Choose Full. Scroll down to where it says Always use HTTPS and turn it on. This is important because WordPress content appears in multiple ways and may link to multiple locations. These settings help keep it uniform.

One source said to change all instances of http:// to https:// in the WordPress database, but I'm not sure this is necessary. A source also said to add s to make https:// in wp_options through the dashboard. I did this but it didn't stick. I don't know what happened and at this point I don't care. This took me two days to work through all of the problems that came up, which is why I wanted to write it all down.

There's a good chance that there are still edits required to competely replicate the site from the old server. Differences include file paths in the database, which can be searched and replaced with MySQL, and available fonts. Motorcyclebaby.com still needs updating. It might mean using a different theme or editing the theme files to make it compatible with WordPress's updates.

I hope this article helps and that using command line makes it seem less lengthy. Please give me feedback. I'm happy to make changes to improve it.

The sources are numerous to list, but here are links to some of them:
Dreamhost's "How to manually migrate WordPress to DreamHost"
Another article on migrating WordPress
Dreamhost's article on editing the hosts file
WordPress's article, "Changing The Site URL"
StackOverflow.com; I don't remember what I looked up, but it's a good resource for problems not addressed here.
How to change URLs in a WordPress database

Kiai Kim

FCE Work in Progress

1 min read

In 2012, I learned about the Great Pacific Garbage Patch, became an anti-disposable-plastics activist, and joined the organization Trash Patch in New York City. To raise awareness, we planned on a video mashup, which I would create.

Final Cut Express on Mac OS 10.6.8

In the middle of obtaining permissions to use video and image clips, I realized through therapy that I had been affected by the 9/11 tragedy and took a break. It was a five-year break.

A revision of the video is available on Vimeo privately. To request to see it, find me at vimeo.com/kiai. As of the time of this post, there are about 25 seconds left to fill including credits.

Kiai Kim

Database GUI Wireframe

1 min read

There are innumerable ways to make wireframes from images to applications. Some wireframe builders will even add scripts to make them appear to function; anything short of a prototype. I made one in Photoshop for a company that wanted an easy way to keep track of their documents. It was for their own built-from-scratch content management system.

The layers in Photoshop make it easy to "page through" the scenes as if an animation. These days you can export them to create an animation. Once I built a wireframe for a plugin proposal with InDesign CC 2014 that was interactive within a DPS (Digital Publishing Suite) app. For the presentation, I ended up using InDesign's Preview function since I had technical troubles getting the presentation screen to mirror my iPad.

Below are images of the CMS wireframe, a database interface. The final product looked nothing like it, sadly, except for the color of the buttons. Had I been the developer, I would have used the Photoshop files to create the buttons and other objects.

Kiai Kim

How to Install the Known platform on a Dreamhost shared server

3 min read

Installing Known on Dreamhost is super easy. The prerequisite is having a hosting account. To host Known on Dreamhost, a domain or subdomain for the installation must exist. If not, add one to your Dreamhost account. Make sure you know the user for the domain. Dreamhost defaults to a user the server creates.

  1. Download the Known .zip archive from withknown.com.
  2. Upload the Known files to your Dreamhost server's domain directory. There are two ways to do this:
    • Unpack the Known .zip locally and then copy the files through Dreamhost's WebFTP utility, Pydio. This is very slow, however.
    • Upload the .zip to your domain's directory and use secure shell (SSH) to upzip the contents. First make sure the user for your domain has shell access. This can be changed on the Manage Users panel. Then go into Terminal or a command prompt and login to Dreamhost's server as [email protected] and use the password associated with your web hosting username. The command looks like this: ssh [email protected]. Terminal will prompt you for the password. Use the password established on the Dreamhost dashboard for your domain. Navigate to the folder using cd yourdomain/ and then unpack the archive using unzip known-0.9.9.zip. (Cd means change directory.) Note that the version number for the Known archive might be different. Using unzip via SSH should unpack the contents in the domain's directory with the index.php file at the top level. Enter exit to leave Dreamhost's server.
  3. Set up a MySQL "server" under Goodies on the Dreamhost dashboard by adding a hostname. On a shared Dreamhost server, MySQL is already set up. You just need to have a hostname associated with your account to point to your blocks of data on it.
  4. Create a new database. You can call it whatever you want. Just be sure to remember what it's called, because you will need that information the first time you access the main page. You will also need the database username that you set up when you created the database and the password . You can find the password by clicking on the database username in the middle of the MySQL Databases page under Goodies, and then clicking Show. Don't create any tables. Known does it for you.
  5. Now you are ready to go to your website domain. When you visit the domain in your browser, the clean copy of Known will prompt you to fill in the necessary data. One thing to note is instead of using localhost for your database server name, you will need the MySQL hostname set up in step 2.

That's it!

A few more notes:

If you already have a hosting account and want to use a domain registered with another company, you can use the same domain and have the DNS changed with the registrar. You can also create a sub-domain such as anyname.dreamhosters.com and then forward a domain to it.

[EDIT: added some more instructions based on Jeremy's comment.]

Kiai Kim

The Good Men Project Movie Poster

1 min read

The Good Men Project movie poster

The Good Men Foundation made a documentary about the lives of ten men, "The Good Men Project: Real Stories from the Front Lines of Modern Manhood". This is the poster for the movie from 2010. Very heartwarming documentary.

Kiai Kim

Promotional Video

1 min read

These are promotional videos I made from storyboard to YouTube upload in one week for my first book. The first one is a 30-second teaser. The second, the full-length version of just under 7 minutes, was shown as a silent movie at my book launch party. It was a fun project shot on a mini-DV camera. The resolution of these videos aren't so great having been on YouTube since 2009, years before Retina displays.

 

Kiai Kim

Nonprofit Website Do-Over

1 min read

When Love Brooklyn Libraries, Inc. had to slash their budget, I helped them get rid of a ridiculous service that charged $200 a month for this:

Yes, it's WordPress. For $200 a month, the nonprofit had this site hosted on the service provider's servers. Included in the cost was a Facebook page and a limited number of updates. Granted, it's really not very expensive compared to hiring a WordPress developer to build it and continue updating it. But with this subscription service, both the website and the Facebook page were filled with stock photos, and the site was rarely updated. Not very enticing.

For the price of a tax-deductible receipt, I had the domain pointed to my Dreamhost server and built this, also in WordPress:

Nonprofit to save the Brooklyn Heights Library

The Howard Johnson's color scheme had to go. Well, it had red not orange, but it was still ugly.

Kiai Kim

Resurrecting an HTML4 Website

2 min read

In 2009 Adobe CS4 was relevant software with some of the best desktop publishing tools available, back when "desktop publishing" referred primarily to creating printed documents from a laptop or desktop computer and HTML4 was sexy markup. With the suite came Dreamweaver, Flash, and Fireworks – shiny software originally by Macromedia. Adobe soon would integrate functions within Flash and Fireworks into their own Photoshop application, though integration was not entirely successful; Flash's animation ability would later become the focus of Edge Animate.

Back then Dreamweaver was less than perfect. It had a graphical user interface that allowed users to drag and drop elements onto a page while the program created the markup in the background. The markup was sloppy, containing complicated-looking classes and IDs that made simple text changes to the HTML document a visual nightmare. I tended to stay away from the GUI and create websites from the text console, making use of Dreamweaver's preview and tag-closing functions. One of those websites is still alive at kiai.us.

Note the black background; looks sleek and saves energy. :D

Screenshot of Kiai.us as of October 2017

As of today's date (October 8, 2017) many of the links don't work. At some point, the site had been migrated and its secondary pages got lost. (There must be a backup somewhere...)

The fun side to this website is that it was built in HTML4. The pink page links were created in Fireworks, which automated the production of mouseOver, onClick, and mouseOut images. The GIFs are encased in a table, Internet Explorer–friendly. The comments at the top and music player at the bottom are linked to Revernation.com and require a Flash plug-in to operate. One of these days, I'll replace the comment widget with something on my own server, maybe javascript-based.

For simple websites, I still like typing out HTML. It's a little like knitting: meditative but still requiring thought and planning. Though it's hard to keep up with developments in styles and tags, at least W3.org does a good job and keeping its content updated. I'm thanking Adobe for giving us Brackets to help out. And Dreamweaver has been greatly improved since CS4. I still rely on console windows.

Kiai Kim

This is a Known website

3 min read

I don't mean this website is known. If that were the case, I'd probably be making a living off of ad revenue or more book sales. Rather, the platform on which this website is built is called Known, co-founded by Ben Werdmuller. Like WordPress, Known allows website owners to post their content in a feed. But one of Ben's goals with the platform is to enable content owners to keep their content without the risk of losing it to a corporate shutdown a la Geocities in 2009 or MySpace Blog in 2013. He and other independent web pioneers breathe life into IndieWeb.org, a website and community aimed at promoting independent web content ownership everywhere.

Why use Known to blog instead of WordPress?

The interface is extremely simple. Installation, as easy as WordPress; maybe even easier. Some webhosting services offer one-click installation, like WordPress. Standard installation, however, is still simple even for novice developers: Create a database, unpack the Known zip file in your web server's root or designated directory, and then visit your domain or directory on the domain. Known walks users through the set up process, also like WordPress. Posting is done right on the main page with a WYSIWYG panel. No Dashboard visits to post.

Look and feel can be edited through the Site Configuration portal with functions appearing on separate pages. Site configuration is a little more friendly for the less tech-savvy user than WordPress. On WordPress it's very easy to break the site since WordPress enables PHP edits to templates' core files from its dashboard. Fine for developers; not fine for non-developers. With Known, users must know how to access the server in order to mess with templates.

Also like WordPress, Known is open-source. Improvement and development of plug-ins, themes, and core files is welcome as long as developers follow coding standards and guidelines.

Perhaps best of all, Known is young and Ben and other developers involved in the project are reachable by email. Maybe not for long though. But isn't that true for all great developments? Well, I'm still trying to figure out if Known is great. So far, so good.

Known's default theme

The default theme is ready to color – it's simply black on white:

I didn't use the default theme, but the Tabula rasa theme is pretty close to it:

I prefer black, grays, and darker backgrounds and have tended to make the margins of my webpages black in the past. Cuts down energy use. For the sake of time, I've made minimal changes to this theme's CSS, just enough for me to be happy to publish. I do have the ability to make more drastic style changes, but I prefer to keep it simple.