DEV Community: Aaron

Reading Serialized PHP

Aaron — Thu, 10 Sep 2020 19:36:20 +0000

Serializing data is simply converting a value into a string. Imagine you had an array in PHP that you wanted to serialize, it would look something like the following...

$arr = [
    'one' => 'val',
    'two' => 'val',
];

$serializedArray = serialize($arr);

/** 
echo $serializedArray;

output:
"a:2:{s:3:"one";s:3:"val";s:3:"two";s:3:"val";}"
**/

Let's dissect it.

a:2 - The proceeding value is an array of length 2
s:3 - This item is a string of length 3 with a value of val
s:3 - This item is also a string of length 3 and value of val

You can imagine how different data types are represented in this fashion.

string - s:length:value
int - i:value
bool - b:value
array - a:size:{key definition;value definition;}
object - O:strlen(class name):object name:object size:{s:length:property name:property definition;(repeated per property)}

Pretty easy to understand once you know the format.

Resources:

Serialize - PHP Docs

Critical Path Rendering

Aaron — Fri, 14 Aug 2020 14:49:31 +0000

Critical Rendering Path

CRP or Critical Rendering Path is an algorithm of sorts that browsers use to display a webpage. When you use your browser to navigate to a webpage, a series of steps have to occur before you will see anything populate the screen. You can think of CRP as a linear top-down process in which the browser reads HTML one line at a time and forms the webpage as it goes.

The CRP process has several phases;

DOM (Document Object Model)
CSSOM (Cascading Style Sheet Object Model)
Render Tree
Layout

In each of these phases a different set of steps occur. Let's go over them individually.

Document Object Model (DOM)

The Document Object Model is a tree structure that represents the HTML on a webpage, by converting each HTML entity into a node object. When each HTML entity is encountered a startTag is generated. The parser then moves to the next token to see if there are any children of the entity. If there is a new node and startTag is generated, and so on and so forth until the end of the entity is found. At that point an endTag is created and that node is closed. These series of startTags and endTags form the tree that makes up the DOM.

As a simplified example, it may help to visualize it.

<div>
    <div>
        <a href="#">
            Some Link
        </a>
    </div>
</div>

Could convert to something like the following. Note that this is a JavaScript flavor and probably not the best way or most accurate way to represent this information.

startTag('div')
  .startTag('div')
    .startTag('a')
      .attribute('href', '#')
      .content('Some Link')
    .endTag('a')
  .endTag('div')
.endTag('div')

The more HTML on a page the longer this step takes. However, don't be fooled into thinking that reducing your HTML by a few or even dozens of elements will make a difference! Browsers are really fast and performance gains from such optimizations are likely to not result in anything significant.

CSS Object Model (CSSOM)

The CSS object model works similar to the DOM except this time CSS is parsed and applied to nodes. When each CSS rule is encountered, the browser performs a lookup on the DOM to make a match to an element.

Both HTML and CSS are render blocking resources. However, using through the use of media queries you can achieve non-render blocking CSS. This is because the CSS is ignored if the viewport size doesn't match the media query, essentially deferring the application of the CSS.

Render Tree

The Render Tree is the phase in which the DOM and CSSOM are combined. Each node in the DOM has it's position and size computed. This phase is when the layout is created. Therefore, any time you modify the DOM such as adding or removing nodes, this phase gets re-triggered.

Here are some common properties that trigger layout.


width	height
padding	margin
display	border-width
border	top
position	font-size
float	text-align
overflow-y	font-weight
overflow	left
font-family	line-height
vertical-align	right
clear	white-space
bottom	min-height

Painting

Finally at the end of the pipeline, the painting phase is when the render tree elements are converted into pixels on the screen.

The complete layout is generated and painted. Then for each node, lays out the elements on the page with their given dimensions and positions. Lastly it applies the remaining CSS to the element.

Just like with the layout there are CSS properties that can re-trigger paint.

The common properties that trigger a re-paint.


color	border-style
visibility	background
text-decoration	background-image
background-position	background-repeat
outline-color	outline
outline-style	border-radius
outline-width	box-shadow
background-size

As a sidenote, this is why with CSS animations it's fairly important you stick to the rules of only animating four things; position, scale, rotation and opacity. These operations allow the animation to run on the GPU instead of the browsers software rasterizer. For a more in-depth explanation of how this works, read the excellent post "High Performance Animations."

Conclusion

This is a nutshell version of the Critical Rendering Path. It is worth diving into how to optimize the CRP but I will save that for another post.

How you decide what to focus on when learning something new?

Aaron — Fri, 14 Aug 2020 12:19:28 +0000

I struggle constantly with this. I want to learn everything. One day I'll wake up and decide I really want to dive into C but as I begin to prep, I talk myself out of it. The thoughts usually go something like this...

C would be really cool to learn
I should find a YouTube video that builds a simple project
(searches for a good video for 30 minutes)
(finds video)
(opens IDE/vim)
Wait, I probably should learn something more relevant to my day job if I'm going to be spending time on this today
(closes video, closes IDE)
goto 1, choose different topic

Some weekends I'll spend hours doing this with no progress. Most of the time I can convince myself that learning anything is always relevant, but it's hard some days.

I think my problem boils down to something quite simple. If I don't have a clear goal or project, it's hard for me to focus.

Does anyone else suffer from this problem and if so, how do you navigate it?

TypeScript Generics Simply Put

Aaron — Thu, 13 Aug 2020 19:32:43 +0000

Generics are a really cool feature of any language that supports them. They allow you to write more abstracted code while maintaining the type safety/hinting that you CRAVE.

If you've used TypeScript at all, you've likely already encountered Generics through Arrays. When you create a variable that is of type array, it looks like this.

const arr: Array = [];

However, this isn't valid on its own, as TypeScript is expecting to know what type will populate this array. We denote this type using angle brackets <>.

const arr: Array<any> = [];

Of course, using any just tells TypeScript to expect all types of data.

But now let's say you are expecting to fill this array with strings so that you can call the indexOf method on any element. You can change any to string and TypeScript will then know what methods will be available.

const arr: Array<string> = ["some", "strings"];
arr[0].indexOf("s");

Using the same angle bracket syntax, you add the Generic type to a function signature, class or interface. The convention is to use a capital T, that simply abbreviates "type." Then you typically pass this type as an argument type in a constructor, method or function.

The Array interface in its simplest form could be written this way...

interface Array<T> {
    (arg: T): T;
}

This allows any type to be associated with an Array type. We could store Objects, Maps, Atomic, Proxy, Numbers, anything!

Generics are a really powerful way of abstracting code so that it's not super specific to one type of data.

How Cryptographic Randomness with Entropy Vaguely Works

Aaron — Thu, 16 Jul 2020 18:06:33 +0000

Random number generators are everywhere in computing. From hardware, to operating systems, kernels, games, you name it. You often hear how pseudo-random number generators (PRNG) like those typically used in programming languages (like JavaScript's Math.random for example) are not cryptographically secure (CSPRNG). But what does that mean?

First you need to understand how PRNG's work. As Yang Guo elegantly puts it...

"As with all PRNGs, the random number is derived from an internal state, which is altered by a fixed algorithm for every new random number. So for a given initial state, the sequence of random numbers is deterministic. Since the bit size n of the internal state is limited, the numbers that a PRNG generates will eventually repeat themselves."

In his quote, deterministic means that given some specific input you can always expect the same output. You can almost think of it as a pure function.

In the V8 implementation of the xorshift128+ algorithm you can see the underlying logic of Math.random().

uint64_t state0 = 1;
uint64_t state1 = 2;
uint64_t xorshift128plus() {
  uint64_t s1 = state0;
  uint64_t s0 = state1;
  state0 = s0;
  s1 ^= s1 << 23;
  s1 ^= s1 >> 17;
  s1 ^= s0;
  s1 ^= s0 >> 26;
  state1 = s1;
  return state0 + state1;
}

Even if you don't know C this example should be pretty clear about two things.

The state is global.
n can never be larger than the largest bit size the platform supports. For C uint64_t that would be 9223372036854775807.

Cryptographically Secure

Now it's very easy to see why a PRNG would be a non-starter for cryptographic applications. Crytographically secure means that a random number you receive has been generated using a non-deterministic algorithm/function. If the previous example won't work, then how do we create these CSPRNG's?

Enter entropy. Entropy has somewhat ambiguous meaning in our field; it can describe how software projects begin to rot as more complexity is introduced over time. In the context of this article however, it essentially is the environmental noise in device drivers.

In Linux for example, the noise is captured into two files /dev/random and /dev/urandom. These files can then be accessed and consumed by the CSPRNG. When this data is consumed it is removed from the pool, that way the next number generated isn't using the same seed. These files naturally replenish themselves but it is important to note that since these are pools after all, they can be depleted if there has been no activity to replenish them.

I don't want to divert into a whole deep dive into these pools but an interesting side note is that on Linux servers this can be a problem, since there are usually no mice/keyboards directly hooked up to the machine, thus reducing the amount of noise it can generate.

Now you may be wondering, if Math.random is insecure why don't we just use the Cryptography API for everything instead? The answer is, like everything, there are trade-offs and in most cases you don't need a CSPRNG.

The primary trade-off is that this method is slower than using a PRNG, and in most cases that's usually what we need anyway. Here is a benchmark showing the stark differences in the speed of these functions.

The MDN docs also make it perfectly clear that unless you know exactly what you are needing and how to do it, you probably shouldn't be using the Cryptography API as it is easy to get wrong. That shouldn't stop you from experimenting and learning about it though, just be careful!

Conclusion

Really there is no conclusion here, I had randomly (pun intended) stumbled across entropy and found this whole dive into it really interesting. I'm sure there is something I missed or maybe got some details wrong so your feedback is welcome.

Special shout-out to my co-worker David Pagan for the edits/feedback.