go back to 10 years ago

Introducing tags & categories features, $LaTeX$ and 🌈 rainbow banner. Update to experience them! 🆙

Tags & Categories

Tags and categories are now implemented in Theme Cupertino. No further configuration required, just add tags and categories properties to your posts’ front-matter.

$\LaTeX$

Really good news, LaTeX is now supported in Theme Cupertino:

$$
(x^2 + y^2 -1)^3 -x^2 y^3 = 0
$$

Or maybe like this:

$$
\rm
2NaOH + CO_2 \xlongequal{}{} Na_2CO_3 + H_2O
$$

By default, this feature is disabled and optional. You can choose the renderer you like. Check out docs.

🌈 Rainbow Banner

June is coming, if you would like to show your pride and support LGBT, or just simply like the rainbow, you will certainly like this feature. It provides a gorgeous rainbow banner right on your navigation. It’s also customizable, you can change its colors to any colors you want. Check out docs.

Get started now by installing/updating Theme Cupertino, and ⭐star it if you like it!

What I’ve been doing at Accenture for the months of August + September.

Cross posted on dev.to

What I’ve been doing at Accenture for the months of August + September.

What I’ve worked on

• Created dozens of tickets coinciding with new 2 project kick-offs.
  • Feels good to organize a fresh Zenhub project board with clear acceptance
    criteria / patterns for completing and discussing spikes / making goals
    clear and accessible to the team.
  • Team members expressed that they enjoyed getting to work on the initiatives
    because the work was made so clear.
  • Velocity on these new projects is high 📈
• Deployed a suite of data ingestion microservices to Azure with Helm,
  k8s, and Terraform
• Setup Github actions to do static code analysis, image publication, and
  deployment with Terraform.
• Setup boilerplate for a Typescript Express API with CI/CD, Linting,
  automatic increased VSCode support, and Jest class mocking structures
  / patterns

What I’d like to improve

Code Reviews

I’ve read the google eng practices
dozens of times now. I feel like when I start a review I ask myself different
questions every time, leaving me with reviews I don’t feel super confident in,
that are inconsistent in depth. Would like to start documenting questions I
ask myself when beginning a review.

An example to
demonstrate class mocks and modifying methods of an already mocked class
within a single test. I used these patterns to mock classes in an Express
app in test driven development.

Cross posted on dev.to.

TLDR

Example Test

GetANumber.test.ts mocks a class, and further customizes a class method on that
mocked class for a single test.

Improvements

• config object should have only getters, that way you can mock process.env inbetween tests
  • they’ll be sourced every time, not pulled from process.env and held onto

Purpose

It was surprisingly hard to find a recently written article about the
fastest way to setup Jest with some simple class mocks in Typescript. The
following example demonstrates mocking a class and modifying
methods of that mocked class within a single test.

Libraries like jest-ts-auto-mock are not used, cause I was unable to find a way
to get them to work. Could have just been using them wrong but who knows.

I used the following methods to mock classes in an Express app while coding in
test driven development.

Explanation

Comments are all over in this Example Repo,
but some highlights are:

• jest.mock ends up at the top of the file when it’s transpiled.
  Even if you put it under other things, it gets pulled to the top.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

///////////////////
jest.mock("./Class", mockOne);

it("does a thing", () => {
  expect(class).toBe(one)
})

it("does another thing", () => {
  jest.mock("./Class", mockTwo);
  expect(class).toBe(two)
})
///////////////////

// is really

///////////////////
jest.mock("./Class", mockOne); // this mock is useless
jest.mock("./Class", mockTwo); // as it's immediately replaced

it("does a thing", () => {
  expect(class).toBe(one)
})

it("does another thing", () => {
  expect(class).toBe(two)
})
///////////////////

// You might as well always write `.mock` calls at the top of your file.

• The examples mock a class that’s a default export. Named exports can also
  be mocked with some modifications.
• jest.mock('{path_to_custom_class}') will replace that paths default export
  in the runtime with the defined mock in __mocks__ dir defined at the same
  level.
• If you’d like to modify a mock / assert things that happened to a mock, you need to import them from the “real” class.
  • Never manually import from __mocks__, get the exports of __mocks__ “through” a normal import.

1
2
3
4
5
6
7
8
9
10
11
12

import * as MockNumberGen from "./__mocks__/NumberGen";
import * as NumberGen from "./NumberGen"; // __mocks__/CVEPathData

// Give me the mock class i've defined in __mocks__/{classname} and let me
//    name it mock{ClassName}Constructor
// Give me the mock function i've defined in __mocks__/{classname}
const { default: mockNumberGenConstructor, mockGetOne } =
  // Get these things from the NumberGen class, because I know that jest
  //     has secretly replaced it with the contents of MockNumberGen
  NumberGen as unknown as typeof MockNumberGen;
// Tell typescript that these things are really coming from MockNumberGen,
//     so it should type them as such

The full test is available here

Recently, I’ve written a CLI for RSA encryption and decryption - RSA CLI.

RSA CLI is based on Node.js, works perfectly with all the desktop platforms.

If you have Node.js environment on your device, with the help of npm, you can install it by running a single line of command:

1

$ npm install -g rsa-cli

Yarn is also supported:

1

$ yarn global add rsa-cli

Without Node.js environment, it’s still easy to install. Just download the executable for your device in GitHub Releases and execute it.

Now start encrypting:

0x00

1

$ rsa generate [keyName]

Run the command above to generate a new key pair. Modulus length is 2048 by default, and if you want to change it, use -l flag:

1

$ rsa generate [keyName] -l 4096

Remember [keyName], it’s needed for next steps.

0x01

Get your public key by running:

1
2
3
4
5
6
7
8
9
10

$ rsa get [keyName]
Public key of key pair '[keyName]':
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAv1n2RwSVDyfd7wsWo5g9Q3bG2uTU4eLxFFgX4coUSRYQKjVXH2zp
8QUmaRghF3qTumlWzCY6WJUvYQl6alu1/VrLOUCeQCat74nLxlIWI44GCB7vhGrC
ktqTpaVmFxa4aOAXT7WLGA15wcaW7hS4mdgbwehx4Bqisk+SjZqJ017ASBFMz02m
RNpKjQoJgRQWdDsr/VDNEKbAYl2ghVlTT9yidiCBJlLISkhTvLVmMzd2ULPzoa9F
8rXxpWJ/4j+rKJKpOaGJIKYCLTgZOXHLHZE7vPxBNK8L/nAV4XDI0S+QSwqVFR0A
uhXiHquN1Ae7wiyljqbei3vZylIYAaIkywIDAQAB
-----END RSA PUBLIC KEY-----

Copy -----BEGIN RSA ...... END RSA PUBLIC KEY----- and save it to a file, then send this file to your friend.

Your friend should also install RSA CLI, he/she need to download it and import it:

1

$ rsa import [yourFriendsKeyName] --public [path-to-the-file]

The next step is to encrypt a message:

1

$ rsa encrypt [yourFriendsKeyName] '[message]'

Finally, tell your friend to copy the output and send it to you.

0x02

After receiving the encrypted message from your friend, you can now decrypt it:

1

$ rsa decrypt [keyName] '[the-encrypted-message-from-your-friend]'

Done! you got the decrypted message from the output.

I think privacy should be in your control. You should not trust anyone who can’t proof your privacy is encrypted and private. Trust yourself. RSA CLI is an easy way to encrypt and decrypt on your own, which means you can really know your privacy is encrypted. Without private key, no one can decrypt your messages.

But why trusting RSA CLI? Because it’s fully open source.

What I’ve been doing at Accenture for the month of June + July.

Cross posted on dev.to

What I’ve been doing at Accenture for the month of June + July.

Took a break in between jobs during the month of May. Did some contracting to
deploy a small node server + develop a corresponding frontend in AWS Beanstalk.

What I’ve worked on

• Managed deployments in multiple AWS k9s environments with Terraform
• Introduction to elixir
• Learning how to work in an open source organization
• Presented on code review standards + practices
• Utilized the Helm Terraform provider to manage helm deployments in k9s
• Configured Strimzi to deploy a kafka cluster
• Pair Programming in a remote environment. We typically pair for 4+ hours a day.
• Deploying Prometheus and Grafana alongside our data pipeline using public helm charts
• Combining several of our teams custom helm charts into one configurable mono chart
• Coming up with fun + not awkward bonding activities for our team to participate in despite our distance from one another

What I’d like to improve

• Learning so much technology has left me feeling burnt out when I could be taking on new cards / tech debt. I’d like to more effectively use my time when not actively pairing.
• Making new cards when discovering potential improvements
• Continue to practice creating very organized and condensed technical presentations

I haven’t updated my blog for a long time. Recently, I found some unkind comments here, but they are not allowed. So, I removed them then. I think I have to make some changes.

From now on, I will check comments more frequently and will deal with the unkind comments I found. If you found any unkind comments, feel free to tell me to remove them.

Plus, comments area is not for testing, it’s for sharing and exchanging amazing ideas about the post with others. So, test comments will be removed, too.

What I’ve been doing at Vail Systems for March + April.

Cross posted on dev.to

What I’ve been doing at Vail Systems for March + April.

Writing for both March and April in this post, so it’s a bit longer. I spent much
of the last month getting ready for a new Software Engineering position at
Pillar Technologies in Des Monies, as well as working through the loss of a
family member. My start date at Pillar is May 19th, and I can’t wait to begin.

Currently I’m taking time off to relax + travel, as well as to do some
contracting for a friend’s business.

What I’ve worked on (Technical)

• Using ffmpeg-fluent and ffmpeg to convert user-uploaded audio to universal
  formats. How to convert and manage codecs and conversion
• Updating our application to support uploaded audio in addition to in-app
  generated audio. (Database -> GraphQL -> Client)
• Using PlantUML as a way to communicate abstract ideas concretely, and iterate
  on design in a traditional code-based merge request process
• Learning how to negotiate salaries, and how to respectfully exit a company
• Presented on how to organize GraphQL schema inside a NestJS based application

Let GraphQL abstract the Database

Often my impulse is to have an app’s GraphQL schema mirror the database 1:1.
Recently, we added a new database table, and it made much more sense to instead
abstract under an existing GraphQL type.

It allowed for flexibility since the resolver now would pull data from more than
one database source. It helped me realize that unless you’re willing to make
constant changes to your schema each time the database is altered, having your
schema align 1:1 with your database makes you miss out on the abstraction
opportunities offered by GraphQL.

I think we could have promoted this idea by only resolving the fields that were
in use on the client. We had resolvers that resolved every field of a table,
even if it wasn’t in use client-side. If instead, we only added fields when the
need on client arose, we’d have a much slimmer + more readable GraphQL schema,
and it’d be less tempting to make every database field available by default.

Using type predicates

Type Predicates are cool! Our resolver was handling two possible interfaces, and
it was nice to find a type-safe way to handle either interface. Earlier in my
career I would have resorted to any so it’s exciting to start reaching
further to see how TypeScript can help. I’d like to take an advanced TypeScript
course sometime soon.

Using Type Predicates

Sometimes you can break tests

One sprint I was working on a ticket, and when I finished the AC, some existing
tests broke. These broke because the ticket was part of a large new
feature, and without the remaining tickets completed, tests were going to stay
broken.

I assumed “don’t let tests break”, and took on two more tickets simultaneously,
in an effort to implement all of the features necessary to make tests green.

In retrospect, I don’t think this was the way to go. In the event you’re merging
to a feature branch and not mainline code, I think it might be okay to break
tests.

If it’s documented (// will be green in TTPSP-189), I think letting them fail
will help code review stay small + keep the team moving faster. The expectation
remains that these tests will be green before reaching mainline code, so if this
happens again, I’d like to bring it up to my team to see what they think of the
approach.

What I’ve Learned (Personal)

Working from home -> move around the house

While I like my desk setup, I find I’m most productive when I move around the
house. Room, living room couch, kitchen table. Moving around has helped my brain
stay a lot more focused.

Why is the house a mess

After a day of work, I’d look at the kitchen or my room and think “why is it
such a mess here”, and start feeling pretty down. I was home all day, I really
didn’t have time to clean? I was home all day, yet there’s nothing ready for
dinner?

I was at work! Of course the house is a mess, I haven’t been “home”, I’ve been
at “work”. Reminding myself of that line has helped me feel better when I end
work for the day. Still looking forward to being at an office soon to have a
physical representation of that line.

Realistic estimates, not best case

It can be tempting for me to give “best case estimates” during standups as a way
to push myself to get something done as quickly as possible. I’d like to find
other ways to motivate myself that don’t result in flakey estimations from my
team’s perspective.

Going forward I’d like to practice giving more likely estimates and working
to complete them a bit sooner than originally expected, instead of finishing
right down to the wire or late.

What I’d like to improve

Creating tickets for experimentation efforts

I’m privileged to be on a team where we’re able to take time and experiment
with new ideas. I’ve found that I sometimes give myself too many things to
juggle: improving a Jenkins step, adding a new cypress improvement,
experimenting with a new build tool. It became difficult to track all of these
initiatives. I’d like to ticket ideas for refactors / features and make sure
to note why I find them valuable. Then it’d be a bit more motivating to return
to existing ideas during free time, instead of endlessly creating new ideas,
and never completing any.

26 files changed, pump the breaks.

That’s an indication that you might need to slow down and reassess your design.

Resources found / Articles I liked:

• React Bundles and Code Splitting - Emma Goto
• Using type predicates
• Capable + Fast UML

What I’ve been doing at Vail Systems for the month of February.

Cross posted on dev.to

What I’ve been doing at Vail Systems for the month of February.

What I’ve worked on

• Custom theming: Account specific client theming in Material UI
• Custom terminology in AWS Translate
• Using Kibana to create dashboards with KQL to analyze API performance.
• Using Nock with Cucumber to programmatically mock external calls
• Started learning about the advantages of Snowpack and ESModules

What I’ve Learned (Technical)

Mocking external API calls

Nock is a great library, but I’m looking forward to
MSW growing. I’d be curious how they handle node
API mocking + recording. I don’t think Nock is as full of a replacement of VCR
for ruby.

What I’ve Learned (Personal)

Break down problems into a confined example

We had an issue using decorators with nestjs modules, and in order to ask for
help, I made a smaller reproducible example of the issue. This ended up being a
sort of “rubber duck”, and helped me arrive at the solution myself. I’d like
to continue approaching problems with this style.

Company Technology Channels

Being distributed, it’s hard to have conversations about specific
software and tooling when I’m not sure who to talk to. I’d like to help
implement specific channels dedicated to specific tools. a “cypress” channel
and a “rust” channel, anything anyone can think of. This way devs can pick and
choose what to be a part of, and share knowledge across teams. I suggested this
and will be following up to see if there’s anything I can do to help.

What I’d like to improve (Technical)

sorry-cypress

I want to investigate using sorry-cypress for better metrics +
parallelization in our k8s setup. The developer experience of cypress is
fantastic, but our build time is reaching an average of 30 minutes 😔

Stop reading + start trying

Often I’m reading about new tools / figuring out how something could work,
but not as often do I add the dependency to a throwaway branch and experiment.
I’d feel a lot more confident breaking down new technical challenges if I
had previously experimented more.

What I’d like to improve (Personal)

Write as you learn

I hoped to put up two smaller blog posts about some TS examples I found
interesting and wanted to share, but I can’t remember half of what I wanted to
note down now that it’s been a few weeks. Going forward I’d like to a small
technical post as I’m finishing it up.

Pace yourself (Pomodoro)

I find myself working intensely for hours, and feeling burnt out toward the end
of the day. I’d like to work on restricting myself to blocks of time so that
I still have the energy to take on new things at the end of the day.

Resources found / Articles I liked:

• https://www.snowpack.dev/tutorials/react
• https://twitter.com/dan_abramov/status/1368277175598735366?s=20

Posts of Mine

Accessing private values of a class within a method decorator

https://repl.it/@bmitchinson/decorator#index.ts

In June of 2020, I started as a full-time Web Software Engineer at
Vail Systems. Here are highlights of what I’ve
learned, and what I’ll be working on going forward. The plan is to do one of
these a month as quick bullet points, starting in March.

Cross posted on dev.to

In June of 2020, I started as a full-time Web Software Engineer at
Vail Systems. Here are highlights of what I’ve
learned, and what I’ll be working on going forward. The plan is to do one of
these a month as quick bullet points, starting in March.

What I’ve worked on

Our team of 5 made a full-stack app for translating text and generating corresponding audio.
Large quantities of text are imported inside CSVs and then edited
further inside the client React app.
A NestJS API then resolves translations and audio generation with AWS services,
stores resulting audio in S3, and maintains transaction data in a Vail MSSQL
database.

Technology used:

• React (CRA) / Yarn
• Typescript (monorepo shared typings)
• Node / NestJS / GraphQL
• Cypress / react-testing-library
• Nock / CucumberJS
• DataGrip + KnexJS
• Jenkins + k8s
• Docusaurus

What I’ve Learned (Technical)

Make TDD work for you

I’ve found that TDD is intimidating for some developers, especially in
client-side testing. I used to think that to do TDD, I had
to have every single assertion down ahead of time. That’s not the case. Just
make a test case with a proper title, and if you’re stuck, write out assertions
in a comment:
// when clicked, the button will turn blue

Don’t let assertions distract you from the purpose of TDD: to have a clear
achievable goal while coding + making decisions. You can still fulfill that purpose
without syntax perfect assertions. After writing enough tests, assertions
will come more naturally.

Starting an app from scratch

I’ve been fortunate to start working on a product from its start and
it’s taught me more than I can write here, but some days I wasted time by trying
to add as many new + exciting tools as possible. After focusing on core
framework functionality and less added tooling, we were able to K.I.S.S
(keep it simple stupid 💋). Now, we have many more options and choices for what
we’d like to add when implementing new features because we’re not limited by
1000x external dependencies. Shout-out to my team lead Nav for helping set those
restraints.

Jenkins + Docker

Maintaining / configuring a mono repo in Jenkins with dynamic tests for linting,
component + integration at both the UI and API layers, and e2e.

Auth

We implemented auth several times looking for a technology we liked. Was good to
understand why auth solutions work the way they do and what they protect against
(XXS, HttpOnly, Secure, Localstorage vs cookies, etc…), as opposed to just how to
configure PassportJS.

What I’ve Learned (Personal)

Pairing remote

It’s been good to practice:

• giving a pairing partner space to consider a problem while on a call. It’s
  easy to accidentally interrupt.
• Working off a shared to-do list helps keep efforts focused when new ideas pop.
• Gathering resources / searching online to help solve a problem, while someone
  is actively working on it.

Work balance while working from home

• How to take a 30-minute mind break to prepare something for dinner, without
  it derailing your entire afternoon.
• Taking breaks away from screens. Video games aren’t the best break for the
  mind or the eyes.
• How to work async: Send updates + check in on others. Grateful that my
  teammates are always up for a call / question.
• Creating a work environment: Move your desk into a space dedicated for 9-5
  and change the scenery every once and a while.
• Communicate with others when struggling! It’s easy to forget you’re not in
  it alone.

Taking notes

• When someone says “how do we do that again”, it feels great to fire off a
  document / confluence page with a breakdown + meeting summary. Meetings become
  2x as valuable when an artifact exists afterward, especially in a remote
  setting. I’m a big fan of docs and making creating documentation part of the
  development process.

What I’d like to improve (Technical)

Client-side performance metrics (web.dev)

We don’t have metrics for many of our operations. I’d like to find ways to
incorporate things like “time to interactive” and “first paint” in our test
suite so that we can find regressions.

Nock

Some of our tests interact with AWS and cause conflicts when running tests on
multiple branches. I’d like to work on understanding “Nock” and using it to
replace AWS calls.

Docs

Areas of our app like authentication and simple things like our implementation
of recaptcha would benefit strongly from a docs page. I’d like to practice
writing things up on new features as they’re being implemented. Instead of
trying to force myself to do them after they’ve been completed.

What I’d like to improve (Personal)

Following through on new ideas + making tickets

Often I think “oh we could improve X by doing Y” or “Hmmm X seems like it’s performing strangely”.
If those ideas aren’t related to the task at hand, it’s easy for me to throw
them to the wayside. I’d like to build a better habit of making actionable
tickets for those thoughts, or at the bare minimum, noting them down.

Resources found / Articles I liked:

• Atlassian on Remote Work research findings - link

I found that GitHub has published its own dark mode and that’s pretty cool.

At GitHub Settings - Appearance

I’m currently enjoying using the official dark mode.

This means, GitHub Dark Mode Extension is useless now…

So, GitHub Dark Mode Extension will add more features to improve your experience like blur effects, smooth transitions and more.

…Don’t fix it.

For the last view months during covid, I’ve had a ton of ideas. Fun things I could make / try. But at the front of my mind I say

“But first I should redo my website”

“Blockers”

I haven’t updated this site in too long, and this post is somewhat of a resolution.

If it ain’t broke don’t fix it

• Is the javascript bundle of this portfolio / blog website larger than it needs to be? Probably.
• Am I using google analytics instead of the more ethical Plausible, yeah.
• Should future static sites of mine be written in something cool lightweight and new like e11nty, maybe.
• Is my lighthouse score 110%, no. (It’s not toooo gross tho).

For the last view months during covid, I’ve had a ton of ideas. Fun things I could make / try. But at the front of my mind I say

“But first I should redo my website”

The purpose of this website is for me to be able to post projects I’m proud of
and track tech related goals.

Whether this site is fully optimized to Rich Harris standards or not, it gets the
job done, and it gets it done well.

While twitter is great for learning about new tools, it can be easy to be bogged
down into an endless cycle of “you should checkout and use this neat new thing”.

If you attempt to use every tool designed to make launching a product “easier” and “efficiently”, you’ll never launch a product.

Now that the barrier of “redoing my website” has been solved with instead 50
lines of markdown, I’m looking forward to smaller more frequent posts. Hopefully
hints that others can find valuable about KnexJS, GraphQL, NestJS, React
and more.

I’m currently learning rust basics outside of work, to work on this, and i’d love to know what you think of it.

Feel free to comment / share on dev.to

Stay safe wear a mask and please vote.

Apple updated their Newsroom’s UI 2 weeks ago. I’ve updated the UI of theme Cupertino recently.

This new UI is still based on Apple Newsroom’s design. It’s post list cards have rounded corners and hover animation just like this:

Theme Cupertino is Updated

This new design is also available in archives page. You can even create one, right in your post in Markdown:

1
2
3
4
5
6
7
8
9
10

<div class="container">
    <div class="card">
        <div class="cover-img">
            <img src="/img/000015.png" alt="A screen shot of theme Cupertino">
        </div>
        <div class="content">
            <p class="title">Theme Cupertino is Updated</p>
        </div>
    </div>
</div>

Unlike Apple Newsroom, theme Cupertino also supports dark mode which is not supported by Apple.

If you contact me, I can’t respond just on weekdays.

Apple updated Apple Newsroom’s UI.

Acrylic Reader project is launched.

yang991178/fluent-reader #86 and yang991178/fluent-reader #88 are closed by yang991178.

I read things by RSS.

Welcome to my new blog!

Quick highlight of three web apps I developed this semester using React, Preact, and Ruby on Rails.