In this portfolio, we'll give a brief introduction to the business owner and creator of the website, then discuss some of the projects and the design desicions, creative aspects, and other details which drive our website and projects.
Brandon Dixon is the owner of Byte This LLC and is an SDE at Amazon in NYC. After graduating with a dual bachelors in Computer Science and Jazz Performance in 2018, he worked as a Software Engineer I, then II, before interviewing at Amazon and accepting an offer as an SDE in 2022. During this time, he dedicated himself to study the various aspects of computer science, software engineering, web development, and software architecture, reading dozens of books on those subjects and applying this knowledge to this workplace, and eventually, the systems implemented for Byte This!. At Comcast, He began as a junior developer but quickly rose to a position where he made major contributions to the codebase, created apps and utilities used by multiple teams which save hours of time across the teams every day, and has become a leader for best practices and code quality standards. In late 2020, he began work on Byte This!, creating the systems for the website which are being used today, creating the first store products, creating the first marketing strategies, creating the business entity, and studying topics of marketing, branding, and others related to entrepreneurship along the way. In July of 2021, Byte This! was officially launched and open to the public, and since then, has been growing in content in terms of dev pages, YouTube content, store products, viewers, customers, and subscribers.
In the sections below, we'll dive into some specifics on different aspects of our systems and business overall.
We have decided to make some of the modules we've developed open source so that others can reuse our solutions and possibly contribute to them. Since our website design has been focused on modularity and reusability from the start, we are able to extract many of our libraries (without any modification in most cases) and publish them in their own repositories and npm packages. Please visit our Github page to view all of our open source projects.
We have built a custom, lightweight search engine for our store catalog and dev pages using our open source library @byte-this/text-process. Our search engine runs searches by tokenizing individual words from queries, then comparing those tokens to tokens which exist in each search subject: store catalog items or dev pages in our use case. We assign weights to different properties of each subject and sum the total score of token matches * weight for each property to assign a search rank to a particular item. Our implementation does not use any indexing or lookup tables; all tokenizing is done at the time of each query. This system is also reused for determining content which is similar to other content. For a more in-depth outline of our approach, please visit the Dev Page shown below.
Each environment of the website can have its own configuration. This enables us to allow different environments to have different behaviors while keeping the codebase exactly the same, or on different versions of the master branch. The configurations are built into our DevOps infrastructure and can be deployed with, or parallel to, other deployments.
Libraries in one repo may refer to libraries in another repo, but there can never be a cycle of repos referring to eachother, even if there is no cycle at the library level. Any @byte-this library cannot access any of the libraries from other repos shown in the diagram.
All visualizations and data processing related to store items are driven by the data which is maintained by our 3rd party's API. The store catalog page, each product listing route, related products, and store search functionality are all driven dynamically based on whatever the current state of the catalog data may be. Therefore, our implementation is, and must be, generic and reusable across any pages and functionalities which require reading and manipulating this data for any number of items and any combination of properties within each item. To provide certain functionality, we add our own tags on top of the properties provided by the 3rd party API, tags such as product categories, default social media images, etc.
In order to make modules in our code base more readable, maintainable, and reusable, we follow the principles of Inversion of Control. Any required dependencies, with the exception of a few low level utilities, are provided via constructor injection. We do not use any type of Service Locator pattern, nor do we use setter injection. This helps make the code's behavior more predictable and unit-testable. It also facilitates our decoupling of the backend's database read/write operations from the rest of the application. One important benefit this provided: when we first started developing this website, we were able to use a reusable temporary database library we created before we made the decision of which database technology we were going to use. When it was time to swap out with the real thing, we did not need to make code changes anywhere except on the database layer itself. For a more in-depth outline of our approach, please visit the Dev Pages shown below.
We've chosen to implement our own scripting to support this process instead of using a prebuilt solution such as GoCD. Our setup involves using scripts on our own development computers to build all of our projects locally, then use automated FTP connections to push all of the output code to the remote servers, except for node_modules, then install node_modules directly on those servers, then launch the new output code. This allows us to utilize our existing resources while keeping production server resource usage as low as possible.
The functionalities of each of these components is encapsulated within the component itself so the consumers do not need to duplicate any code.
Our implementation allows us to dynamically route pages based on configuration settings and will route non-enabled pages to enabled pages, thus preserving url validity. For a more in-depth outline of our approach, please visit the Dev Page shown below.
We've completed the #ProjectEuler100 challenge, which means that we've solved the first 100 problems ons Project Euler, a website which offers hundreds of coding and mathematical challenges. We've published our solutions on Git and are dynamically including them on our website here via Git and Project Euler integrations. Our site shows each problem, our walkthrough video on analyzing and solving it, and all code files + utilities assembled in one place. The solutions and time to execute them are also dynamically evaluated and rendered here.
We are continuously solving LeetCode challenges and are releasing our Java solutions with detailed analysis, outline of implementation strategy, space and time complexity, and YouTube video walkthrough for each problem.
Congrats, you made it to the end of the article! We think one of these articles below might be a good next step along your journey:
Feel free to check out some of our merch while you're here!
Thanks for reading! This page was last updated on 6/13/2022
Follow us on social media for updates and new dev pages and to help support our brand!
Fill out the form below and we'll send you an email reminder to visit this page again:
We've saved your reminder and will send you an email when the time comes.
Unfortunately, there was an error saving your reminder. Please try again.