Age | Commit message (Collapse) | Author |
|
It now contains Hasp, so the extension should be changed.
|
|
These space-indented lines were copied from the web browser's dev
inspector. I forgot to change the whitespace.
|
|
Forgot to update this link when I renamed the video files.
|
|
* Homebrew install tested and working
* Checkout tested and working
Ready for prime time.
|
|
Lets folks know where these files should be.
|
|
|
|
|
|
Now that `bin/setup` has been moved outside of `license-generator/`.
|
|
Makes more sense to run `./bin/setup` from the root.
|
|
* Move the `make run` target into the project root's Makefile
* Update paths in lighttpd.conf to correspond to its new location
|
|
I want to be able to run `make run` from the project root.
|
|
|
|
Needs the project root in order to access `production-config/env`.
|
|
Include the new step 2 of installation, starting the program with `brew
services`.
After the license has been added, the daemon must be restarted in order
for the license to be recognised.
|
|
Now that it takes two commands to install the program, make it easier
for visitors to copy-paste the commands into their shell by preventing
selection of the '$' prompt character.
This allows us to keep the prompt to indicate that these are shell
commands and still make copy-pasting easier.
As a side note, decided not to add the `brew services` command to the
instructions on the thank-you page because if DomeKey is already
running when you license it, you need to restart it for the license to
take effect.
|
|
Since the program doesn't work unless the daemon is launched, it makes
sense that this should be an installation step in order to actually use
the program.
|
|
|
|
License the software with the GNU AGPLv3+ with the exception of the
'aquatic-prime' and 'paddle' libraries and 'aquatic-prime' binary, which
are licensed under the GNU GPLv3+.
|
|
Forgot to change this when I changed the function signature.
|
|
Published my local fork publicly with the base64 format change.
|
|
When I removed the environment variables from the `.htaccess` file in
7d7ac8d747be198088664e45e5423919d9876651, it no longer needed a
corresponding `production-config` counterpart. Use the one tracked in
the repository instead.
|
|
Apparently, Safari doesn't support h.264-encoded video with a frame size
larger than 640x480. Learned about it from this Stack Overflow answer:
https://stackoverflow.com/questions/20347352/html5-video-tag-not-working-in-safari-iphone-and-ipad/31247386#31247386
According to Apple's documentation:
> The following compression standards are supported:
>
> * H.264 Baseline Profile Level 3.0 video, up to 640 x 480 at 30 fps.
> Note that B frames are not supported in the Baseline profile.
> * MPEG-4 Part 2 video (Simple Profile)
> * AAC-LC audio, up to 48 kHz
(https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW9)
Seems a bit odd to me, but I don't know video, so sure, why not?
Since I want to keep my atypical video dimensions, encode it in MPEG-4
following this guide:
https://trac.ffmpeg.org/wiki/Encode/MPEG-4
Unfortunately, this gives us a 12 Mb video file (compared to the h.264's
~3 Mb). Reducing the quality just didn't produce a decent-looking
output.
Deciding to keep the h.264 version, just in case it's supported
somewhere, because it's the version with the smallest file size.
|
|
At small screen widths, the video's height would stay fixed at the pixel
value defined in its `height` attribute. Ensure that when its width
becomes dependent on the window width, the height follows accordingly.
|
|
For whatever reason, the environment variables in my `.htaccess` weren't
getting passed to my FastCGI executables on my production server.
Wasn't sure how to get them passed to the programs, so decided instead
to compile the env variables into the binaries.
To do that, we source the environment file before building the release
builds in the Docker container.
|
|
My production server is on Ubuntu 14.04, but I was building the FastCGI
executables with Debian Stretch.
Discovered the problem like this:
$ ./fulfillment.fcgi
./fulfillment.fcgi: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
$ ldd fulfillment.fcgi
linux-vdso.so.1 => (0x000003a94301e000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x000003a94273d000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x000003a942535000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x000003a942317000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000003a942101000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000003a941d38000)
/lib64/ld-linux-x86-64.so.2 (0x000003a942dfe000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000003a941a32000)
In order to link against the right dynamic libraries, build on Ubuntu
Trusty. To do that, I downloaded the Dockerfile at:
https://github.com/rust-lang-nursery/docker-rust/blob/c34d6993e8f9403c18f348de85787f1585fd3375/1.30.1/stretch/Dockerfile
and changed the first line to:
FROM buildpack-deps:trusty
I then built an image from the Dockerfile and tagged it:
$ docker image build .
$ docker image tag IMAGE_ID rust:1.30.1-trusty
|
|
|
|
Got this error from the production MySQL server:
(details: Error 1235: This version of MySQL doesn't yet support
'multiple triggers with the same action time and event for one table')
Change our triggers so we only have one for `BEFORE INSERT`.
|
|
Ended up with this error when running my migrations against the
production server:
error: migration failed in line 0: BEGIN;
CREATE TABLE purchasers (
id INT AUTO_INCREMENT PRIMARY KEY,
name VARCHAR(255) NOT NULL,
email VARCHAR(255) NOT NULL,
secret VARCHAR(255),
created_at DATETIME NOT NULL DEFAULT UTC_TIMESTAMP(),
updated_at DATETIME NOT NULL DEFAULT UTC_TIMESTAMP()
);
CREATE TRIGGER purchasers_updated_at
BEFORE UPDATE
ON purchasers FOR EACH ROW
SET NEW.updated_at = UTC_TIMESTAMP();
COMMIT;
(details: Error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'UTC_TIMESTAMP(),
updated_at DATETIME NOT NULL DEFAULT UTC_TIMESTAMP()
);
CR' at line 6)
Using MySQL 5.6.34 in production and MariaDB 10.3.10 locally. Guess you
can't use `DEFAULT UTC_TIMESTAMP()` there.
To use `UTC_TIMESTAMP()`, create a couple new triggers to set the
timestamp in the `created_at` and `updated_at` columns.
|
|
Otherwise it gets rendered small when the page first loads, then expands
to the correct dimensions after the page has loaded. This removes the
jump-cut effect.
|
|
The scroll position is now kept when the modal overlay opens.
|
|
Holds production `.htaccess` and `env` files.
|
|
This line was causing a server error. Happily, the corrected version
looks even nicer.
|
|
To deploy, run
$ make deploy
This checks prerequisites and runs `scripts/deploy.sh`.
Makefile:
Include a new target that builds the Rust binaries for Linux using
Docker.
The script `rsync`s the website files to the server, moves some files
around on the server, and runs the database migrations.
Currently I'm getting an error at the database migration stage, as it
seems I can't use `UTC_TIMESTAMP()` as a default column value. Need to
correct that to get a clean deployment.
|
|
This directory will store archives of program releases.
|
|
Renames the binary. The name "license-generator" no longer seems apt at
this point. That binary doesn't actually generate a license, it serves
as the webhook endpoint for Paddle's license fulfillment. Our `license`
binary handles the actual license generation.
The URL I'll be using for the webhook is `/fulfillment`, so this also
makes sense from that perspective.
|
|
Add the instructions we put in the fulfillment email to the
thank-you/license download page. Want to make sure buyers know how to
license the software after purchasing it.
Rephrase the install text to be simpler and more to the point.
|
|
Include install and license instructions in the purchase fulfillment
email.
|
|
Paddle will take the text from the response of this endpoint and include
it in the purchase fulfillment email to a customer.
Include the URL for the purchaser to download their license. Use the
'url' crate's parser to build the URL in order to URL-escape special
characters.
Honestly I'd rather have had a system where the license file gets
included in the receipt email. Unfortunately, with the Paddle
fulfillment mechanism I'm using, we can only send text. I learned after
building the download endpoint that I could manage fulfillment myself.
This would require me to listen to an "alert"-type Paddle webhook, and
send the email myself (which would include the license file). Since I
already built the license download page, I decided to just use it
instead of doing the emailing. Also, my web host limits my SMTP usage,
so there could be issues there. I'd have to do the emailing in a
separate batch process instead of in the webhook handler to ensure that
no emails would get dropped.
|
|
These are the commands I used to convert the demo video into
HTML5-suitable video formats.
The commands are copied from guides I found on the net looking for
`ffmpeg` HTML5 video conversion. I did add the `-b 275k` setting on the
WebM video to sort of match the bitrate I saw on the MP4 video.
Otherwise it ends up being horrible quality without the flag, or around
14 Mb with the `-b:v 1M` flag (this version results in ~4 Mb).
|
|
Move the existing thank-you page to `thank-you-license-download.html`.
Use `thank-you.html` as the final page of the purchase flow. Paddle will
redirect to this page at the end of purchase. Allows us to retain some
branding during purchase.
Using the existing HTML file for a better URL.
|
|
Do this on all pages that aren't the home page.
|
|
Done already.
|
|
|
|
Doesn't make sense to me to have this page be tracked by search engines.
|
|
|
|
When the screen width gets small enough to clip the video, reduce the
width of the video to the content width.
Couldn't use the same larger-than-content-width layout, at least not
easily, because the percentage would need to be dependent on the window
width, not the width of the video element's container.
|
|
Not committing the video files. They're only 3 & 4 megabytes each, but
that still seems a bit too much to keep in version control.
Add the video to the home page and center it in the content area. We
give it a negative margin to center it since it's wider than the
container.
|
|
|
|
Just tested the program on 10.8 and it didn't work. It ran just fine,
but didn't run map actions, and I'm not sure why. Used the release
build, so I didn't debug it at all.
Since I'm planning an imminent public release, just set the minimum to
an OS version that we know for sure works.
In the future, I'd still like to get the program working on 10.8. We can
always bring down the minimum OS version.
|
|
Turns out this doesn't work very well. It activates the application
switcher, but doesn't deactivate it, so it doesn't go away. Bad example.
Oh well.
|