DEV Community: Andy Li

Nice tests to run in CI before deploying any website

Andy Li — Sat, 14 Sep 2019 23:50:25 +0000

Since I'm the only dev behind my startup, Giffon 🎁, I've to take care of all the technical things from development to deployment. Though I've been following best practices and be careful about edge cases, still I don't trust the code I wrote very much.

I added a number of tests in CI to check my website before deployment, and they have caught my mistakes many times. The cool thing is, many of those tests are generic enough to be applicable to any website, so you should consider using them too!

1. Markup validation

The first easy low-hanging fruit is HTML (and CSS/SVG) validation. Most HTML templates do not enforce valid HTML, so it's quite easy to output documents with mismatched tags, which can be a pain to spot! Giffon uses ReactDOMServer, which prevents tag mismatches, but the validation still caught me many times about putting block-level elements (e.g. <ul>) in <p>, and also missing alt attribute in <img>.

Giffon's CI uses the html5validator command line tool against a development server. It's basically calling the commands as follow:

html5validator --html http://localhost:3000/every/page
html5validator --css www/css/*.css
html5validator --svg --errors-only www/images/*.svg

2. Detecting browser console error messages

The second generic error detection is to check the browser console. It reports JS run-time errors as well as broken image references and some invalid HTTP respond headers too.

Giffon's way to do it is to use Selenium web driver, navigates to each page and calls driver.get_log("browser"), asserts that there is no log.

3. Detecting horizontal scrollbars

Most websites don't use horizontal scrollbars. It's annoying (especially on mobile) when one appears due to layout bugs.

Again, Giffon's CI makes use of Selenium. The CI navigates to each page and detects the present of horizontal scrollbars by asserting the following code returns zero:

driver.execute_script(
    "document.scrollingElement.scrollLeft = 1;" +
    "return document.scrollingElement.scrollLeft;"
)

4. Spellchecking

Who doesn't make typos? It may not be critical, but having typos in your website does give a bad impression to visitors.

Giffon's CI uses spellchecker npm library. Giffon has its UI text strings isolated when I implement multi-language support, so it's easy for me to iterate over all the strings and call SpellChecker.checkSpelling(str).

If you don't have your strings isolated, you may save the html output as a file and use the good old aspell cli to list all misspelled words as follows:

cat path/to/my.html | aspell --mode=html list

Any others?

Do you run similar tests in you CI pipelines? Let me know if you have any good ones to share!

Do you set up Patreon or other services to accept donation? 💰

Andy Li — Tue, 09 Jul 2019 21:43:51 +0000

On one hand, it sounds great to receive donation for working on projects, and people can dream of having enough donation to quit their day jobs. On the other hand, even the people maintaining pretty popular projects do not receive much money. For example, the Babel maintainer is currently receiving $2,580 per month via Patreon, but I'm pretty sure one can easily make more money in a full time tech job.

Do you think Patreon or similar services (GitHub Sponsor) is helpful to you? Would receiving money contribution motivate you working on projects?

P.S. Feel free to put your donation links in the discussion ;)

What's the connection between Debian and Toy Story?

Andy Li — Sun, 07 Jul 2019 00:24:17 +0000

Debian is a popular Linux distribution. Ubuntu, which is the first choice of many Linux new-comers, is based on Debian.

Debian 10, which was just released today, is code-named Buster. Debian 9 is Stretch, Debian 8 is Jessie, and the earlier ones Wheezy, Squeeze, Lenny... which are all Pixar's Toy Story characters!

But why Toy Story code names?

It turns out, at the time Debian made its first release with a code name, Debian 1.1 Buzz (yes, Buzz Lightyear), the project leader at the time (Bruce Perens) was working at Pixar.

You may find the other Debian code names in A Brief History of Debian.

If you look closer to the Debian 10 wallpaper, which is the cover image of this post, you will notice there is a hidden shape of Buster, Andy's pet dog.

How I stay focused when working at home: live streaming myself

Andy Li — Thu, 04 Jul 2019 22:36:38 +0000

I was a typical procrastinator - not in the mood of working 90% of the time, many excuses for doing unimportant tasks, easy to distract.

When I quit from my previous full-time job to work on my startup, Giffon.io, I was quite worried that I would just spend all time playing League of Legends and burn my saving until I have to find another office job.

I tried to make deadlines for myself. Not fake ones, but I made a "real" deadline by submitting a talk to introduce Giffon in Haxe Summit. It worked, but mostly only for the 2 weeks before the talk. I was even building major features the day before I got on the stage. After I came back from the summit, the productivity burst didn't last.

I came across a Hacker News discussion about live streaming programming (while I was procrastinating, of course). It sounded interesting to me since I kind of like showcasing stuff and meeting people, basically the same reasons I like speaking at conferences.

Once I've decided to give it a try, I dug out my Kinect for Windows and set it up as my camera (just because I don't have a webcam for my PC), tweeted about it such that I will have a few viewers, and started doing it on the next day.

My first stream was me implementing GIF image banners for the Giffon wish pages. There were about 5 viewers, in which 2 of them were my friends from the Haxe team. I couldn't tell how interesting my stream was to my viewers (probably not much), but at least I myself felt pretty good. I got stuck at one point and my friend discussed the problem with me in the chat. I haven't tried pair programming but I guess it would be a similar experience. At the end of my first stream, I had almost finished the feature in just a bit over 2 hours. It was about the maximum coding efficiency I can get.

Not only I was productive during the stream, I was also productive afterwards since I've already kickstarted my work and the inertia allowed me to polish the feature and do some refactoring off-stream.

Since then, I've been streaming every weekdays. From time to time, different strangers come by and chat with me for a bit, sometimes about programming languages, sometimes about career planing, sometimes about the background music I was listening. The amount of chatting is just right for me to have fun and I keep pretty productive through out. Sometimes the same viewer comes by again in the next stream and it's pretty motivating for me to continue.

So, yeah, so far live streaming is the most successful weapon to fight procrastination for me. I do encourage you to try it out if you haven't yet. Leave me a comment if you have a Twitch stream and I will try to raid you if our timing is right :)

My Twitch channel is andyonthewings, streaming development of Giffon as well as Haxe and some Linux packaging etc.

Create 5 real PRs in an hour and win a Hacktoberfest T-shirt

Andy Li — Fri, 26 Oct 2018 03:44:01 +0000

The annual Hacktoberfest, which gives away free T-shirts to people who create 5 or more GitHub pull requests, is about to end in a week.

I have been an active open source contributor for years, so I was pretty confident that I will eventually fulfill 5 PRs without actively working towards it. Turn out I was wrong - because I'm now part of the Haxe Foundation org, in which I contributed most, I don't really make PRs to contribute since I just push my commits, and that doesn't count towards the Hacktoberfest goal.

Luckily, there are plenty of low-hanging fruits around and I have successfully reached the 5 PRs mark quite easily. Note that I didn't make useless PRs that paraphrase sentences or perform minor formatting to code. I made "real" contributions that is beneficial. Here is how.

Maintain packages!

The one thing that people may not realize that needs continuous work and is quite easy to do (even for beginner devs) is to maintain software packages. Every time you use a package manager to install something, it pull the package from a repository. It is often to have thousands of packages in a repository and the packages need to be updated (usually manually) all the time since new versions are coming out continuously.

Homebrew-core is a pretty nice repository to work on since it is maintained though GitHub, which is familiar to most open source contributors nowadays. We simply send them PR to update its packages (which they call them formulae).

Find out what is outdated

We can make use of Repology to find out what is outdated. We look up the Repology homebrew page, and click on the "Outdated" metapackages number link.

From there, we just pick some familiar ones to work on - maybe you've used that software before, or it's a simple one that is built with languages that you're good at. Try to pick the ones that only need minor/patch update, e.g. from 1.2.3 to 1.2.4 or 1.3.0, but not to a major 2.0.0 release. Be sure to check that there is no existing update PRs created already.

Do the update

We can refer to the homebrew-core's CONTRIBUTING.md for how to do the update.

We can either (A) edit the formula file by updating url and sha256, and then send a PR by hand, or (B) use the brew bump-formula-pr command to do the same thing.

For reference, here is one PR that I made with the command as follows.

brew bump-formula-pr --strict bmake --url=http://www.crufty.net/ftp/pub/sjg/bmake-20180919.tar.gz

That's it!

After sending out the PRs, we can wait for the maintainer's feedback. If the package can be built successfully, it is usually accepted right away. Also, you can click on the "Check Your Progress" button in the Hacktoberfest homepage after you've logged in to make sure you've made enough PRs :)