It took me way longer than I expected to sit down and write this, but now that I have a bit of downtime before my next flight, I'd like to continue my summary of Minna no Go Gengo.
How to build multi-platform tools for your workplace
Author: @mattn
This chapter encourages readers to build multi-platform tools (Windows, Mac, Linux, etc) to support different devices coworkers use and gives some guidelines on how this can be done effectively in Go. Here is a bit of a break down of what each of the sections are and what kind of info they cover:
2.1 Why build internal tools in Go
Go makes it possible to statically build a runnable module for various OSes, so there is no need to ask users to install the Go runtime on their machines. Thanks to this, there is no worry that a different runtime implementation on a different OS will behave differently. Distributing a single binary file is all that is needed to let others use a Go program. Both of these things make Go a really good choice for internal tooling.
2.2 Implicit rules to follow
Rule one is use path/filepath to interact with the filesystem and not the path package. These two packages might be confusing to new users of Go: while path/filepath is pretty explanatory, path is a package meant for resolving relative paths in a http or ftp context. Because the path package does not recognize "\" as a path separator even on Windows, accessing a url like http://localhost:8080/data/..\main.go on a web server that makes use of the path package to locate static files could be used to expose the raw contents of other files on the filesystem
Rule 2 is to use defer to clean up resources. This is pretty well documented elsewhere, so I don't think I really need to elaborate.
The next recommendation is of particular concert to anyone who deals with Japanese or languages containing multibyte characters. Anyone interacting with programs that make use of the ANSI API in Windows to produce output will have to make use of an appropriate encoding package like golang.org/x/text/encoding/japanese to convert the input from ShiftJIS to UTF-8.
2.3 Using TUI on Windows
Linux based Text-based User Interfaces use a lot of escape sequences, many of which don't display properly in Windows. In Go you can use a library called termbox to make the process of making multi-platform TUI applications easier. Another recommended program is one of the author's own tools: go-colorable which can be used which can help produce coloured text in log output, etc.
2.4 Handling OS Specific Processes
Use runtime.GOOS to determine the OS from within a program.
This section also covers build constraints, but this topic is already well covered in English in the documentation, so I won't go into detail here.
2.5 Rely on existing tools instead of trying too hard
While it is technically possible to daemonize processes in Go by using the syscall package to call fork(2), the multithreaded nature of Go makes this a bit tricky. So it is generally recommended to use external tools to handle the daemonizing of a Go program. For Linux for example check out daemonize, supervisord and upstart and for Windows check out nssm
For Unix a regular user can't listen on port 80 or 433 so a lot of unix servers are configured to start as root and use setuid(2) to demote the permissions. However it's not recommended that you use setuid(2) in Go because it only affects the current thread. Instead use nginx or another server to reverse proxy requests from 80 or 433 to another port that Go can listen on.
2.6 Go likes its single binaries
Go makes deployment as easy as placing a single binary file on a server, but in the case of larger programs like web applications (for example) sometimes templates, pictures and other files are necessary. Try using go-bindata to pack static files as assets in a binary so that you don't have to sacrifice ease of deployment.
2.7 Making Windows applications
This section covers how to toggle whether or not your Go program displays a command prompt or not using the -ldflags="-H windowsgui" with go build and also how to link resource files (like the application's icon) using IDI_MYAPP ICON "myapp.ico"
And here are some recommended packages for building multi-platform compatible GUIs:
2.8 Configuration files
The first part of this section covers different file formats like INI, JSON, YAML, TOML and covers their strengths and weaknesses.
Aside from file format, file location on each platform can also be a source of confusion when configuring applications. On UNIX systems the standard was to place each file in the home directory like $HOME/.myapp originally, but more recently the XDG Base Directory Specification recommends that config files be placed under $HOME/.config/.
Similarly on Windows it's no problem if you use %USERPROFILE%\.config\, but the author mentioned he often places config files under %APPDATA%\my-app\.
Well that's the gist of it. I haven't really built software for Windows before mostly just because it seemed like too much trouble, but this chapter sure made it look like Go is making that whole process much easier for those of us who are used to developing for Linux.
For anyone who missed my (much briefer) summary of chapter 1, you can find it here.
No comments:
Post a Comment