Frontend focussed developer and designer. With a background in design, I have a good eye for what works. Expansive experience of libs and frameworks including Lit, React and Angular with Typescript, CSS et al. along with UX Development and Graphics Suites. I'm a firm believer in "using the platform".
UI development with web-components built in lit.dev. Building a bespoke component library and implementing those components accross Rippl sites and with the help of a brilliant team. Later joining a separate team working on modernising an AngularJS project.
UI development with React in Typescript, incorporating functional programming with RamdaJS, occasionally contributing as a graphic designer. My contributions were various, and included visualisations with D3 and helping to refactor our sites to use React. The team was very gifted and I learnt a great deal. We strived to a fault for best practices and would always make time for stand-ups, retros and hackathons.
Full stack role building UIs and a new company website with Angular, Shopify and a Sagepay. The site was originally written in Jekyll and later rewritten in Hugo.
Unsuccessful start-up venture with a team of one. I built the frontend of web.cv with AngularJS with the hope of partnering with a backend engineer. Working by myself was good for discipline, though I certainly lacked the feedback I needed to either move the project forward or understand when to stop.
Contract work as a front-end dev. Clients included several big names from ebay to facebook. Deadlines were tight and I was hardworked but fully enjoyed my time with the team.
In-house developer for a yacht company based in Monaco. My role within the company was diverse. I mostly worked autonomously, managing projects and building tools for charter destinations and another for charter yacht selections. Whilst at the company I learnt to speak French. Voilà.
If you can accept that ten binary digits 1111111111 represents 1023 in decimal, we can of course use our ten fingers to represent any number counting up to it.
+
+
This is a brief whistle-stop tour of a JS project that converts a number to it's handy binary representation. In building it I learnt a little about JS Bitwise Operators and their application. This post covers the utility of those operators and might interest any JS devs who are curious about their usage.
+
Let's start with a single closed fist as our 0, you can click the fingers or adjust the input to change the value.
+
+
I'm sure you're getting the gist. Wherever a finger is extended we count the digit in our calculation. Let's represent that most rock-and-roll of numbers, 18.
+
+
Translating the decimal value "18" to it's binary value "10010" looks like this:
So our tenth finger will represent the number 512 but this isn't our maximum as we've yet to count all the fingers that came before it and doing so gives us our maximum value 1023.
Another thing we need to know is the value of each finger from right to left. Just as 2 ** 10 gave us the value of our 11th finger. We can use 2 ** n to calculate each finger's binary value.
As we loop through the value of each finger we can use the AND(&) bitwise operator to determine if a value is included in our total and therefore the applicable finger extended. This is completely different to the logical AND represented by "&&". We'll explore this problem for our most knarliest of numbers 17.
+
+
To get our Result in the following examples we use our operator "&" against each finger's corresponding Value. In decimal this would look like:
+
+
1 & 17
+
2 & 17
+
4 & 17
+
8 & 17
+
16 & 17
+
+
Here are the same calculations visualised in binary.
I hope you can see what's happening here, wherever a 1 appears in the same bit position for both the Input and the Value the result Input & Value gets a 1 in the same position. If the result matches the input we know that a finger should be extended. Let's run that calculation in JS to prove we're right.
Our last task is closing and extending fingers or taking away and adding values. Let's say that we have a single hand with all of it's fingers extended, giving us the number 31 or 11111 in binary. Let's close that most British of digits, the pinky finger, represented by the number 16 or 10000.
+
Our operator in this case will be XOR(^), this returns a 1 for every bit position where the values differ.
Because XOR is only interested in the difference between the two binary values, we can use the same operator to extend our pinky finger, adding it back to the hand.
We've proven that an array of boolean values can equally be represented by a single number. Whilst Bitwise operators provide a powerful toolset for manipulating that number it is not without its limitations. The biggest limitation is the number of elements (or fingers) we can represent. Because of JS's implementation we are restricted to a maximum safe value of 9007199254740991, retrievable with the MAX_SAFE_INTEGER constant:
These 52 1s represent 53 elements in an array, meaning we can safely operate on no larger number.
+
Finally I'd be doubtful that anyone would thank you for the inclusion of bitwise operators in source code, their usage is certainly a little obscure but they've been fun to play around with.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/posts/steganography-in-js/index.html b/posts/steganography-in-js/index.html
new file mode 100644
index 0000000..e21dd65
--- /dev/null
+++ b/posts/steganography-in-js/index.html
@@ -0,0 +1,201 @@
+
+
+
+ Steganography with Zero Width Characters (Z-Chars) | robstarbuck.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Steganography with Zero Width Characters (Z-Chars)
+
+
+
Steganography the practice of hiding a message in something that is not secret. Certain unicode characters are zero-width, meaning that they won't be printed and can't be seen. Using these character we can encode characters and hide messages.
+
In this post I'll provide a quick explanation of some of the key aspects of Z-Chars. The post might interest Javascript devs who are curious about unicode and the bidirectional algorithm.
+
POLITE NOTICE There's enough trash on the web without hidden characters gumming up our messages, please don't use this in the wild.
+
Hiding characters in text
+
Wherever text is represented digitally, it's likely to be encoded using Unicode. Some Unicode characters are intentionally invisible, a carriage return for example (↵) can't be seen although we can see it's effect. Such characters are known as control characters.
+
Because not all languages read from left to right, some require special mark-up to ensure they run from right to left. Take the word "Egypt" as an example.
+
+
+
Egypt
+ ⟶
+ Latin characters read left to right
+
+
+
مصر
+ ⟵
+ Arabic characters read right to left
+
+
+
Computers need to know which direction these characters run in and one way to indicate this is with control characters.
I'm not going to be digging much into the details but hopefully the names alone provide some indication of their use. Let's explore how they'll print in the browser. We'll be using the UTF-16 reference listed above. In JS we can access these characters with '\uCODE'. The letter "A" for example is '\u0041'.
+
'\u0041'
+// "A"
+
+'\u0041\u0042\u0043'
+// "ABC"
+
+'\u2066\u2067\u2068\u202A\u202B\u202D\u202E\u202C\u2069'
+// "" [Nothing is visible]
+
+
As you can see, our nine characters print as an empty string "". Now let's try to insert these characters between other letters.
Again the control characters between the letters can't be seen.
+
Because the assumed use for this is hiding characters in the latin alphabet, we know the text will always run left to right, to guarantee this it's safest to limit ourselves to the three left-to-right control characters:
We now have the means to hide characters, all we need now is a way to encode them to other characters.
+
Encoding and Decoding
+
So we have our three characters with which we can encode our hidden letters and this is great because if you have an understanding of binary, you'll know that we only need two 0 and 1. Let's see how we can use these two characters to represent the letter "X".
charCodeAt gives us the unicode character reference for our letter, toString(2) then converts this to a binary string or a number with a base of 2. To get back to our "X" we can use fromCodePoint to reverse the process.
+
parseInt("1011000",2)
+// 88
+String.fromCodePoint(88)
+// "X"
+String.fromCodePoint(parseInt("1011000",2))
+// "X"
+
+
Because we know we can represent "X" using 0 and 1, it's a short step to swapping these characters out to the control characters that can't be seen.
Because we have three characters however, it makes sense to use them all. This changes our base (or radix) to three. Encoding and decoding three characters look like this:
+
// ENCODING
+
+"X".charCodeAt(0)
+// 88
+"X".charCodeAt(0).toString(3);
+// "10021" [Comprises three characters 0,1 and 2]
+
+// DECODING
+
+parseInt("10021",3)
+// 88
+String.fromCodePoint(88)
+// "X"
+String.fromCodePoint(parseInt("10021",3))
+// "X"
+
+
Let's take another example by hiding "HIDDEN" within the word "VISIBLE". Because our z-chars fit between our visible letters, the number of characters we can encode is the number of visible letters minus one. So our visible letters demark our hidden ones.
Other than a few functions to split strings and interpolate the hidden characters, this all but covers the core concepts behind Z-Chars. Pray you never use them to this effect.
+
Please take a look through the source code if you're curiouser still.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/posts/treact-recursive-components-in-react/basic-screenshot.png b/posts/treact-recursive-components-in-react/basic-screenshot.png
new file mode 100644
index 0000000..be03c40
Binary files /dev/null and b/posts/treact-recursive-components-in-react/basic-screenshot.png differ
diff --git a/posts/treact-recursive-components-in-react/employboy-demo.html b/posts/treact-recursive-components-in-react/employboy-demo.html
new file mode 100644
index 0000000..ae6ac8f
--- /dev/null
+++ b/posts/treact-recursive-components-in-react/employboy-demo.html
@@ -0,0 +1,26 @@
+
+
+ Treact - Recursive Components in React | robstarbuck.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/posts/treact-recursive-components-in-react/index.html b/posts/treact-recursive-components-in-react/index.html
new file mode 100644
index 0000000..f340228
--- /dev/null
+++ b/posts/treact-recursive-components-in-react/index.html
@@ -0,0 +1,287 @@
+
+
+
+ Treact - Recursive Components in React | robstarbuck.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Treact - Recursive Components in React
+
+
React is ideally suited to the task of creating trees, being at its core, a tree of functions that call one another. In this demo we’ll look at creating a tree using a data set containing trees (of the Kingdom Plantae). So the theme is trees.
Whilst this seems a natural fit it has many disadvantages.
+
+
1. The shape of the data is hard to work with, finding a leaf node (a tree) requires recursion.
+
2. Each datum has no idea of its context, eg a species only knows its genus by knowing its parent.
+
3. The hierarchy is very rigid, if we only want to look at everything beneath families we still need to go through the root Plantae.
+
+
A more flexible approach is to keep our data flat. In this instance we already know the levels of our tree (the taxonomic ranks we’ll be using), this might not be true for other trees. A family tree for example could span any number of generations. Here however our levels are known to us in advance (those being Kingdom, Order, Family, Genus, Species)
Certainly much easier to grok from my point of view and I’ll demonstrate further advantages later on. With our data model agreed upon (well I’m happy with it), let’s render it out in React.
+
A Basic Implementation
+
We can get a basic implementation working in 50 or so (readable) lines of Typescript.
+
+import"./App.css";
+import { FC } from"react";
+import allTrees from"./data.json";
+
+// Types
+type Tree = typeof allTrees[number];
+type TaxonomicRank = keyof Tree;
+type TaxonomyProps = { children: Array<Tree>; rank: TaxonomicRank }
+
+// This is only a subset of - domain, kingdom, phylum, class, order, family, genus, species
+consttaxonomicRanks: Array<TaxonomicRank> = [
+ "Kingdom",
+ "Order",
+ "Family",
+ "Genus",
+ "Species"
+];
+
+constrenderTaxon = (taxon) => {
+
+ // We are only passing the taxa of this rank to the next Taxonomy
+ // Without this filter, the component will call itself indefinitely
+
+ const childrenOfTaxon = children.filter(
+ (t) => t[rank] === taxon[rank]
+ );
+
+ const subRank = taxonomicRanks.at(taxonomicRanks.indexOf(rank) + 1);
+
+ return (
+ <detailsopen>
+ <summary>
+ {taxon[rank]}
+ </summary>
+
+ {/* Here the element now calls itself */}
+
+ {subRank && <Taxonomyrank={subRank}>{childrenOfTaxon}</Taxonomy>}
+ </details>
+ );
+}
+
+// Our recursive taxonomy which calls itself where child taxonomies exist
+constTaxonomy: FC<TaxonomyProps> = (props) => {
+ const { children, rank } = props;
+
+ // Find the unique taxa in our child taxonomies
+ // EG unique taxa with a key of "Genus"
+ const taxaInRank = children.reduce<Array<Tree>>((a, c) => {
+ if (a.find((v) => v[rank] === c[rank])) {
+ return a;
+ }
+ return [...a, c];
+ }, []);
+
+ return (
+ <div>
+ {/* Loop through the taxa in the rank */}
+ {taxaInRank.map(renderTaxon)}
+ </div>
+ );
+};
+
+functionApp() {
+ return (
+ <divclassName="App">
+ {/* Our initial call to our Taxonomy */}
+ <Taxonomyrank={taxonomicRanks[0]}>{allTrees}</Taxonomy>
+ </div>
+ );
+}
+
+exportdefaultApp;
+
With minimal CSS we already have our tree rendering every level of our taxa up to the tree itself, our leaf node.
+
+
Improvements
+
Because we’ve kept our schema flat by abstracting the keys (in this case taxonomic ranks) we can modify which taxonomic ranks we view. Currently we are recursing through "Kingdom", "Order", "Family", "Genus", "Species”. If we only want to observe the “Species” though, this can easily be achieved by passing it in to our initial Taxonomy.
With this in mind, it’s easy to see how rank may be stateful, allowing users to limit the ranks being viewed.
+
We can also opt to observe different keys of our trees, for instance Species is probably not all that useful to most people who know trees by their common names.
The complete source code for this project can be found in the repo.
+
Summary
+
Even when everything in your repo is screaming “TREE!” keeping data flat can may prove more flexible. In this instance we knew our groups in advance, where this might not be the case extra keys might indicate relationships between nodes.
Of course in an ordinary family tree there is more than one parent, I’ll skip over that.
+
Owing to React's nature Recursive Components are a good use case for the language and implementations that I’ve seen in Vue and Angular aren’t quite as comprehensive.
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/posts/treact-recursive-components-in-react/master-screenshot.png b/posts/treact-recursive-components-in-react/master-screenshot.png
new file mode 100644
index 0000000..965d57e
Binary files /dev/null and b/posts/treact-recursive-components-in-react/master-screenshot.png differ
diff --git a/posts/web-components-and-slotted-element-interactions/employboy-demo.html b/posts/web-components-and-slotted-element-interactions/employboy-demo.html
new file mode 100644
index 0000000..0932f8a
--- /dev/null
+++ b/posts/web-components-and-slotted-element-interactions/employboy-demo.html
@@ -0,0 +1,52 @@
+
+
+ Web-components and slotted element interactions | robstarbuck.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/posts/web-components-and-slotted-element-interactions/index.html b/posts/web-components-and-slotted-element-interactions/index.html
new file mode 100644
index 0000000..615e984
--- /dev/null
+++ b/posts/web-components-and-slotted-element-interactions/index.html
@@ -0,0 +1,246 @@
+
+
+
+ Web-components and slotted element interactions | robstarbuck.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Web-components and slotted element interactions
+
+
Back in 2010 one of my first websites Employboy featured a parallax effect applied to a floating head. It used JS to explicitly set the position of the inner and outer shapes. Here I'm going to do a run-through of how I modernised this approach using web-components and SVGs.
+
First of all let's take a peek at what we're working towards, please welcome into the public domain our little friend "Mockey". Moving your mouse cursor over around the image should produce a parallax effect.
The three circles have ids of #outer, #inner and #center. By targeting those ids we can make the svg interactive with the use of a web-component name lib-mouse-parallax.
+
+
+
+
I see why Nurofen uses this as branding, it's headache inducing! Just take Ibuprofen, it's identical.
+
So how does our web-component make the SVG behave in this way, let's take a look at the mark-up.
As mentioned our three properties "foreground", "middleground" and "background" are just css selectors. The circles could equally be targeted with nth-child(n):
Lastly, the component accepts a speed setting to determine how fast the foreground (top layer) travels in relation to the mouse. Here we have it set to 1 meaning the centre circle will track the mouse exactly.
+
The component acts in three stages.
+
+
Applies a css transform to svg elements matching a selector
+
On mousemove update the --mouse-x and --mouse-y variables
+
On mouseleave reset the position of the image
+
+
Similar instruction occurs for touch events.
+
It's important to know that whilst web-components with a shadow-dom do encapsulate style there are some inherited properties. I believe the complete list is:
+
+
color
+
direction
+
font-* (eg font-family)
+
letter-spacing
+
line-height
+
text-* (eg text-align)
+
visibility
+
word-spacing
+
+
As well as these, css variables (--var-name: value;) are also inherited and that's something we'll be harnessing.
+
To move our shapes around we are using the css translate(x, y) function.
Multiplying by 1px ensures our translation is applied in pixels. In the CSS we have included the value three times. Multiplying by 0.25px, 0.5px and 1px representing background, middleground and foreground respectively.
+
As we don't know what the css SELECTOR will be, we instead set the transform as a variable and apply it in JS later on.
All that's left now is to set --mouse-x and --mouse-y whenever mousemove fires within the component. We will also need to reset the values on mouseleave to restore the image to it's previous state.
Things get a little more complicated from here but this is really where the walk-through stops. In brief the complicated elements are:
+
Transform Correction Because we're moving between absolute values (the position of our mouse) and relative values (the viewport of our SVG) we need to correct for how much we adjust our --mouse-x. Without this adjustment the parallax effect would vary when the size of the svg changes. Adjusting for the SVG's viewport corrects this.
+
Easing To avoid the position of elements snapping as when triggered, we are gradually easing in the effect on each movement.
+
The web-component itself was rolled in Google's Lit, and developed using Storybook as an environment. Lit is a joy to work with as I imagine are many of the libraries available for developing web-components.
+
What I like about Lit is it's goal to align the api with that of native web-components. Oftentimes I found the documentation I needed on MDN rather than in the Lit docs. I'm a real advocate of using the platform, developing in Lit doesn't feel like bending to someone else's model (eg "Thinking in React"). I'm yet to try out other libraries, though many seem to share the approach of class based declarations with decorators for added functionality. I imagine porting from one to another would be relatively pain-free.
+
Summary
+
In dedication to the Rob of 2010, here's that the floating head of employboy marked up by our web-component.
Web-components are yet to take off in the way that I'd hoped. Whilst big orgs are using them, frameworks and libraries like React and Angular already determine how components are created and creating native web-components in these environments has little value.
+
It appears libraries like Lit are yet convince devs that it offers a complete solution for developing a site. Whether that's down to a lack of awareness or simply because other frameworks are so firmly ensconced I couldn't say. I hope we see a shift soon.
