Privacy Policy

Last updated: 5 November 2026

This Privacy Policy explains how The Practical Developer (practicaldevblog.blogspot.com) collects, uses, and protects information when you visit this blog.

Information we collect

When you leave a comment on this blog, the name and profile information you provide, along with the content of your comment, are stored and displayed publicly with the comment. If you contact us by email, we use your email address only to reply to you, and we do not share it with anyone else.

Like most websites, this blog is hosted by Blogger (Google), which may collect standard log information such as your IP address, browser type, the pages you visit, and the time and date of your visit.

Advertising and cookies

This blog may display ads served by Google AdSense. Third-party vendors, including Google, use cookies to serve ads based on your prior visits to this website or other websites.

Google's use of advertising cookies enables it and its partners to serve ads to you based on your visit to this site and/or other sites on the internet. You may opt out of personalized advertising by visiting Google Ads Settings. You may also opt out of a third-party vendor's use of cookies for personalized advertising by visiting www.aboutads.info/choices.

Cookie settings can also be controlled through your web browser.

Links to other websites

This blog contains links to external websites, such as LinkedIn and a published resume document. We are not responsible for the privacy practices of those sites, and we encourage you to read their privacy policies.

Children's privacy

This blog is not directed at children under the age of 13, and we do not knowingly collect personal information from children.

Changes to this policy

We may update this Privacy Policy from time to time. Any changes will be posted on this page.

Contact us

If you have any questions about this Privacy Policy, please contact us through the Contact page on this blog.

Comments

Post a Comment

Popular posts from this blog

Rust Explained: Memory Safety Without a Garbage Collector

You run a small command line tool that parses a daily export file, and twice a month it crashes on a row nobody expected. The file is fine on Monday, a supplier adds a column on Tuesday, and by Wednesday your tool has died at 3 a.m. with a message nobody on call can explain. The crash is a memory or data handling mistake that a stricter language would have caught before the program ever ran. That is the problem Rust is built to solve: programs that are fast and also refuse to compile when they mishandle memory. Rust gives you C level speed without a garbage collector pausing your program. The trick is a set of rules, checked by the compiler before your program ever runs, called ownership. Every value has exactly one owner, the variable that holds it, and when the owner goes out of scope the value is cleaned up automatically. Move the value to another variable, and the first one can no longer use it. fn main() { let line = String::from("A1,2,120.50"); let moved = lin...
Read more

Jest Explained: Testing JavaScript Without the Setup Headache

A customer buys a notebook and two pens, and the shop charges them 29.28. Then one changed line in the basket code makes the same order come to 29.27, or to zero. Nobody notices until a customer complains, because nobody rechecked the maths after the change. That is the job a test does: a small program that runs your code, checks the answer, and tells you the moment the answer changes. Jest is the tool most JavaScript developers use for that job, and it is popular because it removes the setup that used to put people off testing. Install it, write a test that reads like a sentence, run one command, and you get a pass or a precise failure. What I would check before using it My judgement, from writing and reviewing JavaScript for years, is this: use Jest when the behaviour you are protecting is worth more than the few minutes it takes to write the test, which is true for almost any code that handles money, user data, or anything a customer will see. I would not write a test suite for a ...
Read more

Three.js Explained: 3D Graphics in the Browser

An online shop sells a water bottle, and the product page shows one photo from the front. Customers cannot see the back, cannot judge the size, and cannot tell how the cap works, so they ask questions, or they buy elsewhere. A spinning 3D model would answer all of it, but the web is flat by default: HTML and CSS lay out rectangles, and the browser's low-level 3D API, WebGL, takes hundreds of lines to draw a single cube. That is the gap Three.js closes. It wraps the graphics pipeline in friendly concepts, scenes, cameras, lights, and meshes, so a developer can build a 3D product viewer or a data visualisation in an afternoon instead of a month. A minimal scene follows the same pattern every time: create a scene, add a mesh, add a light, point a camera at it, and animate it in a loop, each frame rotating the mesh slightly so it appears to move. That loop is the heartbeat of every Three.js app. What I would check before using it My judgement, from building web pages and watching 3D...
Read more