General

Get 100k Followers by Teaching TypeScript, with Matt Pocock, Author of Total Typescript

Published Oct 19, 2023

Updated Oct 19, 2023

2 min read

In this episode of "Just Ship It," Tracy Lee welcomes Matt Pocock, the author of "Total TypeScript," to discuss his journey in the world of development and open source. Tracy and Matt talk about his rise to popularity as the author of "Total TypeScript" and his transition from being a singing voice teacher to a web developer.

Matt's journey into the world of web development began in 2017 while he was working on his thesis. Bored with the thesis writing, he decided to explore JavaScript, marking the beginning of his development adventure. He soon found himself experimenting with ambitious projects like using the Web Audio API to analyze voice quality and other complex web applications. It was during this time that he realized his passion for coding and building things that could change the world.

In 2018, Matt transitioned to full-time web development. He initially worked for a company that created monitoring devices for elderly people, which required him to handle various frontend tasks. Despite leaving the job after just five months due to financial difficulties at the company, Matt's passion for development continued to grow. He went on to work for different agencies, gaining experience in various development environments and technologies.

Matt's journey eventually led him to the world of open source, where he made a significant impact. He became involved with XState, a state machine and state chart library, and even joined its core team. His contributions to XState led to his involvement in the founding of a new company, Stately, which grew out of the XState core team. This transition marked a pivotal moment in his career, as he found himself contributing to a project that later became the foundation for a new venture.

One of Matt's standout accomplishments in the tech community is Total TypeScript. This comprehensive TypeScript course covers advanced topics, such as type transformations, generics, and complex type patterns. Matt's teaching style, which emphasizes practicality and real-world applications, resonated with developers looking to level up their TypeScript skills.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

From Tech Support to Podcasting Pro: The Success of JavaScript Jabber and Ruby Rogues with Charles Max Wood

In this episode, Tracy chatted with Charles Max Wood about his early days in tech support to becoming a podcast host and entrepreneur in the tech industry. Charles’ journey began with a degree in computer engineering. While his educational background was hardware-focused, his passion for programming led him down an unexpected path. Fresh out of college, he found himself working at a company called Mozi, where his role primarily involved tech support and assisting users with their Windows backup issues. It was during his time at Mozi that, faced with the challenge of managing workloads efficiently without adequate software, Charles and his team decided to build their own solution. Charles started developing software in Rails to streamline their operations. While working in quality assurance, a colleague introduced Charles to podcasts. He soon discovered "Rails Envy," a podcast that sparked his interest. He reached out to the host, Greg Pollack, who not only responded but also played a crucial role in Charles' podcasting journey. Charles founded "Ruby Rogues" in 2011. This panel-style podcast became a hit in the programming community. It was followed by several other podcasts, including "JavaScript Jabber," "Adventures in Angular," "React Roundup," and many more. There was an emphasis on genuine enthusiasm for the topics discussed on podcasts, which is what attracts and retains listeners. Podcasters must love what they talk about to keep their audience engaged and build a loyal following. Initially, Charles’ podcasts were passion projects, but as the audience grew, so did the opportunities. Sponsorships became a primary source of income for the shows. However, Charles recognized the need to diversify revenue streams to reduce vulnerability. The decision to transition from a full-time job to entrepreneurship allowed Charles to focus on his podcasts and explore other ventures, including coaching and a mobile app designed to help individuals advance in their careers. Charles emphasizes the importance of passion in podcasting, the potential for monetization, and the value of diversifying income streams. His transition to entrepreneurship allowed him to fully invest in his passions and explore new opportunities, making him not only a content creator but also a tech entrepreneur....

Oct 5, 2023

2 mins

Just Ship It

From Learning to Code to Open Source Advocate: Brian Douglas, First Hire at Netlify and First Dev Advocate at GitHub

Tracy Lee and Brian Douglas chat about coding, self-learning, open source, and developer relations in this episode of Just Ship IT. Brian's coding journey started in 2013 during a challenging period when his son was born prematurely, requiring a prolonged hospital stay. He sought a way to locate churches near the hospital and realized the need for a church review app. This sparked his determination to learn to code. Brian highlights many successful developers didn't follow the traditional college route but instead found their way through self-learning and unwavering dedication. Brian's path to coding was largely self-guided. He utilized various online tutorials and courses to acquire the skills he needed. His learning adventure led him to the world of Ruby on Rails. Tracy and Brian emphasize the difference between self-motivated learners and those who treat coding as a checkbox item. They discuss the significance of immersing oneself in the learning process to truly grasp the fundamentals. Brian worked at Netlify for about two years, a journey that began when he switched to Netlify for hosting. Eventually, Matt from Netlify reached out, offering Brian a role that would help shape the JAMstack landscape. This diverse role at Netlify involved both front-end engineering and DevRel activities. Brian shares the story of creating OpenSauced.pizza. This tool exemplifies his dedication to empowering the open source community. Brian has made significant contributions in open source. He discusses the importance of mentoring others to contribute to open source projects and foster a culture of collaboration. The evolution of open source metrics is brought up, emphasizing that there's more to success than just star counts. Metrics like commit velocity and issue-to-PR conversion offer deeper insights into a project's health and growth. Brian and Tracy conclude their conversation with a discussion on developer relations (DevRel). They stress that DevRel professionals should prioritize engagement and building relationships over focusing solely on metrics and numbers....

Oct 31, 2023

2 mins

Just Ship It

D1 SQLite: Writing queries with the D1 Client API

Writing queries with the D1 Client API In the previous post we defined our database schema, got up and running with migrations, and loaded some seed data into our database. In this post we will be working with our new database and seed data. If you want to participate, make sure to follow the steps in the first post. We’ve been taking a minimal approach so far by using only wrangler and sql scripts for our workflow. The D1 Client API has a small surface area. Thanks to the power of SQL, we will have everything we need to construct all types of queries. Before we start writing our queries, let's touch on some important concepts. Prepared statements and parameter binding This is the first section of the docs and it highlights two different ways to write our SQL statements using the client API: prepared and static statements. Best practice is to use prepared statements because they are more performant and prevent SQL injection attacks. So we will write our queries using prepared statements. We need to use parameter binding to build our queries with prepared statements. This is pretty straightforward and there are two variations. By default we add ? ’s to our statement to represent a value to be filled in. The bind method will bind the parameters to each question mark by their index. The first ? is tied to the first parameter in bind, 2nd, etc. I would stick with this most of the time to avoid any confusion. ` I like this second method less as it feels like something I can imagine messing up very innocently. You can add a number directly after a question mark to indicate which number parameter it should be bound to. In this exampl, we reverse the previous binding. ` Reusing prepared statements If we take the first example above and not bind any values we have a statement that can be reused: ` Querying For the purposes of this post we will just build example queries by writing them out directly in our Worker fetch handler. If you are building an app I would recommend building functions or some other abstraction around your queries. select queries Let's write our first query against our data set to get our feet wet. Here’s the initial worker code and a query for all authors: ` We pass our SQL statement into prepare and use the all method to get all the rows. Notice that we are able to pass our types to a generic parameter in all. This allows us to get a fully typed response from our query. We can run our worker with npm run dev and access it at http://localhost:8787 by default. We’ll keep this simple workflow of writing queries and passing them as a json response for inspection in the browser. Opening the page we get our author results. joins Not using an ORM means we have full control over our own destiny. Like anything else though, this has tradeoffs. Let’s look at a query to fetch the list of posts that includes author and tags information. ` Let’s walk through each part of the query and highlight some pros and cons. ` * The query selects all columns from the posts table. * It also selects the name column from the authors table and renames it to author_name. * It aggregates the name column from the tags table into a JSON array. If there are no tags, it returns an empty JSON array. This aggregated result is renamed to tags. ` * The query starts by selecting data from the posts table. * It then joins the authors table to include author information for each post, matching posts to authors using the author_id column in posts and the id column in authors. * Next, it left joins the posts_tags table to include tag associations for each post, ensuring that all posts are included even if they have no tags. * Next, it left joins the tags table to include tag names, matching tags to posts using the tag_id column in posts_tags and the id column in tags. * Finally, group the results by the post id so that all rows with the same post id are combined in a single row SQL provides a lot of power to query our data in interesting ways. JOIN ’s will typically be more performant than performing additional queries.You could just as easily write a simpler version of this query that uses subqueries to fetch post tags and join all the data by hand with JavaScript. This is the nice thing about writing SQL, you’re free to fetch and handle your data how you please. Our results should look similar to this: ` This brings us to our next topic. Marshaling / coercing result data A couple of things we notice about the format of the result data our query provides: Rows are flat. We join the author directly onto the post and prefix its column names with author. ` Using an ORM we might get the data back as a child object: ` Another thing is that our tags data is a JSON string and not a JavaScript array. This means that we will need to parse it ourselves. ` This isn’t the end of the world but it is some more work on our end to coerce the result data into the format that we actually want. This problem is handled in most ORM’s and is their main selling point in my opinion. insert / update / delete Next, let’s write a function that will add a new post to our database. ` There’s a few queries involved in our create post function: * first we create the new post * next we run through the tags and either create or return an existing tag * finally, we add entries to our post_tags join table to associate our new post with the tags assigned We can test our new function by providing post content in query params on our index page and formatting them for our function. ` I gave it a run like this: http://localhost:8787authorId=1&tags=Food%2CReview&title=A+review+of+my+favorite+Italian+restaurant&content=I+got+the+sausage+orchette+and+it+was+amazing.+I+wish+that+instead+of+baby+broccoli+they+used+rapini.+Otherwise+it+was+a+perfect+dish+and+the+vibes+were+great And got a new post with the id 11. UPDATE and DELETE operations are pretty similar to what we’ve seen so far. Most complexity in your queries will be similar to what we’ve seen in the posts query where we want to JOIN or GROUP BY data in various ways. To update the post we can write a query that looks like this: ` COALESCE acts similarly to if we had written a ?? b in JavaScript. If the binded value that we provide is null it will fall back to the default. We can delete our new post with a simple DELETE query: ` Transactions / Batching One thing to note with D1 is that I don’t think the traditional style of SQLite transactions are supported. You can use the db.batch API to achieve similar functionality though. According to the docs: Batched statements are SQL transactions ↗. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence. ` Summary In this post, we've taken a hands-on approach to exploring the D1 Client API, starting with defining our database schema and loading seed data. We then dove into writing queries, covering the basics of prepared statements and parameter binding, before moving on to more complex topics like joins and transactions. We saw how to construct and execute queries to fetch data from our database, including how to handle relationships between tables and marshal result data into a usable format. We also touched on inserting, updating, and deleting data, and how to use transactions to ensure data consistency. By working through these examples, we've gained a solid understanding of how to use the D1 Client API to interact with our database and build robust, data-driven applications....

Dec 23, 2024

6 mins

JavaScript

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Building a Stripe App: A Step-by-Step Guide to QR Code Generation Why Build a Stripe App? I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow. I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right! Creating a QR Code Generator App For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools. Why QR Codes? QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches. Project Structure Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project: * .vscode: Contains settings for Visual Studio Code * source/views: Holds the main application views * .gitignore: Specifies files to ignore in version control * stripe-app.json: Defines the Stripe app configuration * ui-extensions.d.ts: TypeScript declaration file for UI extensions * .build: this is where the built Stripe app gets placed. Step-by-Step Implementation 1\. Install Stripe Locally First, you need to install Stripe on your local machine. The documentation provides great instructions for this: * For Mac users: Use Brew to install * For Windows users: Download the package and add it to your environment variables You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool. 2\. Install Dependencies We'll be using an extra package for QR code generation. Install it using npm: ` 3\. Set Up the Main Component Let's look at the home.tsx file, where we'll use Stripe's UI components: ` These components are similar to other UI libraries like Bootstrap or Tailwind CSS. 4\. Create the UI Structure Our app will have: * An input field for the URL * Validation using a regex pattern * Error handling for invalid URLs * QR code generation and display Here is the Home.tsx file that is located in the src/views folder ` * ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View. * Box is how you use Divs. * Banners can be used to show notification errors or any other item you wish to display. * Textfields are input fields. * Everything else is pretty self-explanatory. 5\. Handle Content Security Policy One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null. This is my stripe-app.json file. ` 6\. Configure App Views As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page. By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers. If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!...

Dec 18, 2024

4 mins

stripe

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Get 100k Followers by Teaching TypeScript, with Matt Pocock, Author of Total Typescript

You might also like

From Tech Support to Podcasting Pro: The Success of JavaScript Jabber and Ruby Rogues with Charles Max Wood

From Learning to Code to Open Source Advocate: Brian Douglas, First Hire at Netlify and First Dev Advocate at GitHub

D1 SQLite: Writing queries with the D1 Client API

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Let's innovate together!

You might also like

From Tech Support to Podcasting Pro: The Success of JavaScript Jabber and Ruby Rogues with Charles Max Wood

From Learning to Code to Open Source Advocate: Brian Douglas, First Hire at Netlify and First Dev Advocate at GitHub

D1 SQLite: Writing queries with the D1 Client API

Building a Stripe App: A Step-by-Step Guide to QR Code Generation