I've been using a pomodoro app that provides a REST API. Through this API, you can query past pomodoros using parameters such as ended_before and ended_after. The response data also contains started_at and ended_at fields.

The values for these fields all look like this: 2022-01-01T07:18:59.000Z. And they are UTC time strings suffixed with a Z. Correctly so, because it indicates this timestring is UTC.

There are fields named local_started_at and local_ended_at. Although those values are clearly not UTC, they are all suffixed with a Z. This confused me a bit at first. (And it seems quite common for people to suffix Z at the end of a time string, regardless of which timezone that time string actually is.)

The default timezone in a Docker container is UTC. The default timezone of AWS is also UTC. (I wrote a script to check just to be sure. But it's actually written somewhere in the documentation.)

Interestingly, Python does not support the letter Z when you try to parse a timestring using datetime.fromisoformat. But if you use +00:00 to mark a zero offset from UTC, it works and a datetime object with timezone info is returned.

 1>>> datetime.fromisoformat('1989-06-04T08:11:25.000Z') # ❌
 2Traceback (most recent call last):
 3  File "<stdin>", line 1, in <module>
 4ValueError: Invalid isoformat string: '1989-06-04T08:11:25.000Z'
 5
 6>>> datetime.fromisoformat('1989-06-04T08:11:25.000+00:00') # ✅
 7datetime.datetime(1989, 6, 4, 8, 11, 25, tzinfo=datetime.timezone.utc)
 8
 9>>> datetime.fromisoformat('1989-06-04T08:11:25.000+02:00') # ✅
10datetime.datetime(1989, 6, 4, 8, 11, 25,
11    tzinfo=datetime.timezone(datetime.timedelta(seconds=7200)))

Now I digress.

Z apparently stands for Zulu in “military timezones”. 25 letters are used to indicate the time difference from UTC. Although the Z timezone means UTC, the timezone where the actual Zulu people live has a offset of +02:00.

There are also India, Lima and Quebec in these military timezone names. Only Quebec indicates the actual timezone used in Quebec as daylight saving time.

This is how useCallback works.

In the callback defined on line 🙄, the function body increases the count by 1. We set the dependency list to be shallChange. This way, the count will not increase unless shallChange gets a different value.

If you click Count+ multiple times, the count will only increase once. It will increase again after you click Shall Change? butotn.

 1import { useCallback, useState } from 'react';
 2
 3function App() {
 4  const [count, setCount] = useState(0);
 5  const [shallChange, setShallChange] = useState(0);
 6
 7  const setCountCallback = useCallback( // 🙄
 8    ()=> {
 9      setCount(count+1)
10    }, [shallChange]
11  )
12  
13  const onPlusBtnClick = () => {
14    setCountCallback();
15  }
16
17  const onShallChangeClick = () => {
18    setShallChange(shallChange+1)
19  }
20  
21  return (
22    <div>
23        Count: {count}<br />
24        shallChange: {shallChange}<br />
25        <button onClick={onPlusBtnClick}>Count+</button><br />
26        <button onClick={onShallChangeClick}>Shall change?</button>
27    </div>
28  );
29}
30
31export default App;

Here are a few things I noticed in week 7.

I was creating a React app using create-react-app and ran into this error:

You are running 'create-react-app' 4.0.3, which is behind the latest release (5.0.0).

After googling around I saw a workaround by installing v5 locally.

Yet a better workaround is:

npx [email protected] app-name

Update on Feb 24

Should have read the thread more closely, because clearing npx cache should do: npx clear-npx-cache.

I was reading Ace the Data Science Interview and there's a chapter about coding.

One easy coding problem reads:

Given two arrays, write a function to get the intersection of the two.

I guess to show your ingenuity, you are not supposed to use sets, which are native to Python.

The most naïve idea is to run a doubly nested for loop to check each item in arr_n against each item in arr_m. That way, the time complexity would be O(n*m).

A twist on this idea is to run a for loop to iterate through the shorter array (arr_n) and check if arr_n[i] exists in the longer array (arr_m). By doing so, the time complexity is also O(n*m) because the average case time complexity to find an item in arr_m is O(m). (I had mistakenly thought checking existence of an item costs O(1).)

A simpler solution is using sets. The official solution given in the book first converts the two arrays to sets. Then checks which items in the shorter set exist in the longer set by doing this:

[x for x in set_n if x in set_m] (time complexity O(n))

The time complexity of this solution in total is O(n) + O(m + n), because converting lists to sets costs O(n) too, and we have two arrays here. Less than O(n*m).

At first I wondered why they didn't directly use set intersection. I guess that's because converting the resulting set back to a list would cost another O(len(intersection)).

The more I program, the more I find myself realizing the why of some of the basics.

You can use either a method or a function to sort or reverse a list in Python. One works in-place, meaning the order of items in the original list is changed. The other works on a copy of the list and returns an ordered version of that copy as a new list.

list.sort() and list.reverse() are methods of the list class. They are both verbs, suggesting they take actions on an instance of the list class. And as methods that are internal to a list, they are understandably “allowed” to change the internal order of list items.

sorted() and reversed() are functions external to the list class. They are both adjectives. If a function tampers with the data passed in as an argument, that makes it not a pure function. So in functional programming terms, they are both pure functions.

I spent some time last week to get myself more familiar with TypeScript.

Although I'd known the syntax, how to type things (props, components, etc) was at times still confusing. I probably saw more than a bunch of errors thrown at me.

Hopefully I'd love it when I get the hang of it. People on the internet say, all pros and cons considered, it's worth the while.

A few things:

Handling date and time is more complicated than I expected. python-dateutil is quite helpful when you need to parse a datetime string.

A pitfall

I tried updating a field in a MongoDB document using MongoEngine. The value of that field was an embedded document that contained four sub-fields. I intended to change the value of subkey2. But the entire embedded document was overwritten.

 1{
 2    key1: value1,
 3    key2: value2,
 4    key3: {
 5        subkey1: subvalue1,
 6        subkey2: subvalue2,
 7        subkey3, subvalue3
 8    }
 9
10    # After updating, this field instead became this...
11    # ...and this is not what I wanted
12    key3: {
13        subkey2: newvalue
14    }
15}

I'm quite glad I caught this potential bug early on. And indeed, smart people out there have figured it out.

Baffling decimals

I was trying to check if the submitted value and the value found in MongoDB are the same. This field was defined as a decimal.

In order to try it out, I artificially submitted a JSON object that contained a number with two decimal places (69.30) and the value I saved in MongoDB was 69.3 of decimal type (or I thought so).

But Decimal(submitted_value) == Decimal(mongodb_value) returned False.

Printing out the two values, I got:

1# submitted_value
269.30 
3# mongodb_value
469.299999999999997157829056...

The reason of this turned out to be: Although I defined this field to be a DecimalField with precision=2 in MongoEngine, the value actually stored in MongoDB was still a Double.

And a float number is supposed to do this.

These are the fun I had in week 45, 2021.

Djongo

I ended up in a situation where I decided to use Djongo to bridge MongoDB and Django.

MongoEngine team made a Django connector. But it does not seem to be actively maintained. So they pointed to Djongo and described it as “promising”. (Spoiler: If something is “promising”, the universe hasn't decided whether to resolve it or reject it.)

It seemed as if the only thing you needed to do is go to settings.py and change the database engine to Djongo like so.

 1DATABASES = {
 2    'default': {
 3        'ENGINE': 'djongo',
 4        'NAME': '<db_name>',
 5        'ENFORCE_SCHEMA': True,
 6        'CLIENT': {
 7            'host': '<conenction_url>'
 8            }
 9    }
10}

If you set enforce schema to True, you'd need to run migrations like dealing with a relational DB. Setting this parameter to False would save you some hassle.

Then an error popped up saying a certificate was required. (SSL: CERTIFICATE_VERIFY_FAILED) Djongo's documentation mentioned in passing that you could use arguments allowed in pymongo.MongoClient().

In this case, useful arguments were ssl, ssl_cert_reqs and ssl_ca_certs. But Djongo doc did not tell you how exactly you could do that.

After some trial and error, I did the obvious by directly adding query params to the URL.

• 'ssl=true&ssl_cert_reqs=CERT_NONE'
• 'ssl=true&ssl_ca_certs=' + certifi.where()

The first one is less secure. To use an actual certificate, you need to install certifi and go with the second. (There were more trials and errors. And a lot of times, doing the obvious didn't work.)

Maybe I'm overthinking, but...

At some point I wrote this code for an endpoint that expected a JSON object with keys username and password. (Remember destructuring assignment from JavaScript? LOL!)

1def auth_login(request):
2    username, password = json.loads(request.body.decode()).values()
3    # Surely this will work right?

I soon realized nothing prevented the client from uploading something like this:

1{
2    "password": "pa$sw0rd",
3    "username": "lexie"
4}

And since this was not JavaScript, we'd end up with username being pa$sw0rd and password being lexie.

And git ignores case by default

It seems quite a few people don't know git by default ignores case.

I learned this because I once mistakenly named the file for a React component in lowercase then imported it using the capitalized filename.

This could be a problem if you misname a Procfile or a Dockerfile. And you actually don't need to recreate the entire repository like Matt did in this video.

Set ignorecase to false like this and rename the file. A learn this solution (of course) from a note on StackOverflow.

1git config --local core.ignorecase false