DEV Community: Ray Johy

Measuring floor area when a room has an angled nook

Ray Johy — Fri, 06 Nov 2026 16:17:02 +0000

Draw the boundary first. In this example the main rectangle measures 12 ft by 10 ft, a triangular nook extends past one edge, and a 2 ft by 3 ft fixed cabinet sits inside the main rectangle. We are estimating only the area that will get flooring.

Part	Calculation	Area
Main rectangle	12 × 10	120 sq ft
Cabinet footprint to leave out	2 × 3	−6 sq ft
Triangular nook	4 × 5 ÷ 2	+10 sq ft
Total to cover	120 − 6 + 10	124 sq ft

The 5 ft measurement is the perpendicular distance from the triangle’s 4 ft base to the opposite point. Measuring the sloping side instead will usually overstate the height. Also make sure the nook is outside the rectangle in your sketch, or you will count part of the floor twice.

I work on the square footage calculator. To reproduce this example there, enter the main rectangle, add a 2 ft by 3 ft subtract section, and enter the nook as a second triangle. The measured total does not include any allowance for cuts or rounding to whole flooring boxes.

Subtracting feet and fractional inches without rounding early

Ray Johy — Fri, 06 Nov 2026 16:02:52 +0000

Suppose a wall run is 5 ft 3 1/8 in and an opening is 2 ft 7 3/4 in. You want the length left after subtracting the opening. The inches in the first measurement are smaller, so borrow one foot.

Rewrite the wall run as 4 ft 15 1/8 in. The total length is the same.
Write the fractions with the same denominator: 15 1/8 in − 7 6/8 in = 7 3/8 in.
Subtract the feet: 4 − 2 = 2. The remaining length is 2 ft 7 3/8 in.

To check the result another way, turn both measurements into inches before subtracting. The starting values are 63 1/8 in and 31 3/4 in. Their difference, 31 3/8 in, is the same 2 ft 7 3/8 in. Keeping the fractions through the subtraction avoids errors from treating the inches as decimal feet.

That is a measured length, not an order quantity. If you are buying trim, decide separately how to account for cut ends, usable offcuts, and the stock lengths you can buy.

I work on the feet and inches calculator. Enter the two original measurements and choose Subtract. The app preserves eighth-inch and quarter-inch fractions exactly, so this example can be checked without a rounding approximation.

Keep the handle intact when you style a caption

Ray Johy — Fri, 06 Nov 2026 16:01:13 +0000

If you paste decorative small caps into a plain-text field, you’re copying different characters, not setting a font. That distinction matters when the caption contains something the app needs to recognize, such as a username or web address.

Try this sample:

Hello @alex https://example.com

With link and mention protection on, the tool I maintain produces:

ʜᴇʟʟᴏ @alex https://example.com

Only the greeting changes. The username and URL still have their original characters. It is still worth checking the pasted result in the destination app, since the app decides what becomes a mention or link.

Unicode small caps do not cover every letter uniformly. In this particular mapping, x, digits, and accented letters stay as typed. Capitalization also cannot be reconstructed from the result, since A and a map to the same character. Keep names or instructions in plain text when readers need to search for them or copy them exactly.

I work on the Small Caps Generator. It lets you compare the result against the original before copying.

Area calculators need two unit conversions, not one

Ray Johy — Fri, 06 Nov 2026 15:18:08 +0000

If a room measures 144 in by 120 in, multiplying gives 17,280 square inches. The result in square feet is 120, because each foot contributes a factor of 12 on one axis. Dividing an area by 12 would produce 1,440, which is still the wrong unit.

You can check both paths when building a calculator:

const lengthIn = 144;
const widthIn = 120;
const areaFromSides = (lengthIn / 12) * (widthIn / 12);
const areaFromSquareInches = (lengthIn * widthIn) / (12 ** 2);
console.assert(areaFromSides === 120);
console.assert(areaFromSquareInches === areaFromSides);

The same trap appears in decimal feet. Twelve feet six inches is 12.5 feet, not 12.6. At a width of 10 feet, the correct answer is 125 sq ft. For an L shape, add non-overlapping sections after converting both dimensions of each section. Keep the measurements precise until the final display. If you estimate flooring boxes, round the number of boxes up separately from the area calculation.

Disclosure: I work on Square Footage Calculator. The site has a mixed feet-and-inches example and links to a separate flooring calculator for box coverage and waste.

Use real superscript markup when you control the page

Ray Johy — Fri, 06 Nov 2026 15:13:55 +0000

The raised 2 in x² is a different Unicode character from the plain 2 in x2. That makes it convenient in a plain-text message. It also means a search for the exact string x2 does not necessarily find it.

When I write HTML, I prefer markup where the text represents an exponent or an index:

<p>The area is x<sup>2</sup>.</p>
<p>The molecule is H<sub>2</sub>O.</p>

The browser can position the numbers while the source keeps ordinary digits. For longer equations, use the notation your document or platform already supports. Decorative Unicode has gaps in its alphabet, and font coverage can differ between devices.

If a chat box takes plain text, it can be useful to copy a raised digit. For example, type 2 into a Unicode superscript tool and place the resulting ² after a normal x. The same idea works for the lower digit in H₂O. Check the result in the app where you will paste it.

Disclosure: I work on the Small Text Studio superscript generator, which shows supported and unchanged characters. You can use it to inspect the output before copying a character.

A GIF can fit the layout and still miss the upload limit

Ray Johy — Fri, 06 Nov 2026 15:12:55 +0000

Suppose a 480-pixel reaction looks right in a chat preview, but the upload rejects it. The layout is fine. Check the file's bytes and the destination's limit before changing the width.

Here is one result from our GIF tool's release test. A four-frame GIF was 847,960 bytes. With a 250 KB target, the browser produced a 248,947-byte GIF that decoded successfully. That's about 71% fewer bytes for that file. A different image can land above the target, especially when it needs many colors or frames.

Try the same workflow on a file you can share:

Keep the original and note its dimensions and size.
In the Discord GIF compressor, choose a target that leaves a little room under the limit.
Download the output. Compare the actual bytes and watch a complete loop.
If it is too large, trim idle frames or reduce the palette. If the preview is too wide, open the GIF resizer and set the dimensions first.

It's easy to mistake the number in the target field for the size of the finished file. The downloaded bytes tell you whether it fits. And a file that fits can still be hard to read, so check the preview after every aggressive change.

I work on GifLoom. The tool runs in the browser, and you can reproduce the workflow with your own GIF.

Feet, Inches, and Flooring Waste: A Practical Square Footage Workflow

Ray Johy — Thu, 17 Sep 2026 11:12:05 +0000

When a flooring estimate goes wrong, the arithmetic is rarely the only problem. The common failures are mixing feet and inches, measuring overlapping sections twice, and rounding boxes before the total area is final.

Keep the measurement units honest

A tape reading of 12 feet 6 inches is 12.5 decimal feet, not 12.6. Convert each complete measurement before multiplying. For metric rooms, keep meters or centimeters consistent throughout the calculation, then convert the final area only when comparing product coverage.

Break irregular rooms into non-overlapping pieces

For an L-shaped room, divide the floor plan into rectangles, calculate each rectangle, and add the results. Subtract a closet or cutout only once. The same rule works for several rooms: keep a room-by-room list, then total the areas after checking that no section overlaps another.

Add waste after the net area

Waste depends on material, pattern, room shape, and installer. Add the chosen allowance to the combined net area, then round up using the product's coverage per box. A box rounding step should not replace the waste calculation, and an online estimate should be checked against the product label and installation plan.

I maintain Square Footage Calculator as a free browser tool for feet-and-inches, metric, L-shaped, and multiple-room planning. It is designed for early comparisons and shopping preparation, not as a substitute for a contractor or manufacturer quote.

The most reliable workflow is simple: measure twice, label every section, calculate with one unit system, add waste once, and round boxes at the end.

A failed status request should not erase a working job

Ray Johy — Thu, 17 Sep 2026 07:29:44 +0000

A browser tool can lose its connection while the server is still doing useful work. That sounds obvious, but it is easy to accidentally turn a temporary network failure into a much worse user experience: forget the job, invite another submission, and leave the user with two conversions and no clear result.

I maintain Sonify, a small browser-based audio tool. This is a design note from its connection-recovery work, not a claim that its backend is always available. The same reasoning applies to exports, report generators and other asynchronous jobs.

Separate service knowledge from job state

A failed status request tells the browser that it does not currently know whether the service is reachable. It does not prove that a previously created job disappeared.

Keep those facts separate:

Service availability can be unknown, available or unavailable.
A job can be queued, processing, ready, failed or expired.
A network error while reading a job is an observation failure, not automatically a new job state.

This distinction changes the recovery path. Retain the job reference during a temporary connection failure and resume checking it when connectivity returns. Clear it only when the server supplies the appropriate terminal result, such as not found or expired, according to the API contract.

Retry the observation before repeating the operation

Reading a job and creating a job have different consequences. Repeating a read usually costs a request. Repeating creation can consume quota and server capacity.

For an uncertain creation response, an idempotency key gives the server a way to recognize the same operation. Keep that key associated with the same submission when retrying; generating a fresh key on every retry defeats the purpose. A deliberately new submission should have its own identity.

Also give users a clear recovery action. A disabled Convert button with no explanation leaves them guessing. A short connection message, automatic retries with backoff, and a Retry now control explain what is happening without pretending to know more than the browser does.

Test the uncomfortable transitions

A successful end-to-end conversion is necessary, but it does not exercise the recovery behavior. Useful scenarios include:

The initial service check times out, then succeeds.
The user refreshes a ready result while offline, then reconnects.
A gateway returns HTML when the client expects JSON.
The server accepted creation, but the browser did not receive the response.
The job actually expired while the browser was disconnected.

The expected outcomes differ. Temporary failure should preserve recoverable context; genuine expiry should explain why the old download can no longer be used. Neither should be displayed as an endless spinner.

Explain the remaining limit

Client recovery cannot repair an unavailable backend or recreate an expired file. Sonify currently offers individual permitted YouTube-to-MP3 conversions with a 30-minute source limit and a 15-minute download window. Those limits belong beside the workflow so that users can decide whether it fits their task.

The small lesson is to model uncertainty explicitly. A connection error is often a reason to preserve state and check again, not a reason to erase the user's progress.

Disclosure: I maintain Sonify. This article was prepared with AI assistance from the project's implementation and verification notes.

Designing honest progress states for a browser audio tool

Ray Johy — Thu, 10 Sep 2026 04:16:11 +0000

A job can be accepted, queued, processing, ready on the server, and still not be saved on the user’s device. Those are different facts. A single animated percentage can hide all of them.

I am the developer of Y2MP3 Convert, a browser tool for converting one permitted YouTube recording to MP3. This note explains the progress-display decisions in the project and a few rules that also apply to export jobs and media processing. It was prepared with AI assistance from the project’s current code and published constraints. It does not present a speed benchmark or an independent product review.

Separate the stages users can act on

The interface distinguishes finding the source, receiving source audio, and encoding the MP3. Waiting for an encoding slot is different from waiting for source access: the audio may already have arrived.

A useful status message answers two questions: what is known to have happened, and what is the job waiting for now? “Audio received; waiting to encode” communicates more than a progress bar stuck halfway through. It also avoids implying that all waiting is a failed download.

Unknown progress is a valid state

If the source has not reported a total size, a meaningful byte-based percentage is unavailable. The UI can still report the bytes received and show indeterminate activity. It should not convert elapsed time into invented completion.

In the project, unknown progress has its own representation. A numeric progress value appears only when the current stage has a finite measurement. Estimated totals are described as approximate. This keeps “we do not know the total yet” separate from “nothing has happened.”

The same distinction should reach accessibility text. The interface removes the current numeric ARIA value while progress is indeterminate, and describes the stage in text. An animated bar’s visual position is not evidence of a measured percentage.

Leave room for final validation

A worker finishing its main loop is not necessarily the same as a usable output file being ready. The current progress display caps an active measured stage below 100 percent. Completion comes from the job advancing to a later stage or reaching the ready state, rather than from a browser timer.

This avoids a misleading “100%” while a job is still being finalized. It also makes the terminal state responsible for declaring success.

Keep “ready” separate from “saved”

When the server has a file ready, the browser still has to transfer it. The frontend cannot infer that the user has saved the complete file merely because they clicked the download button.

The project therefore tells users to check their browser’s download progress and keep the server copy until the download finishes. A click is an interaction event, not proof of a completed transfer. This distinction matters even if ordinary conversions work: a slow or interrupted final transfer is a separate failure mode.

Explain the limits before a long wait

Published limits are part of the workflow. For this tool, they include a 4.5-hour duration ceiling, 512 MiB source audio, 700 MiB output, one job per browser session and five attempts per source connection per hour, including failed and cancelled attempts. A shared connection can share that allowance. Ready files expire after 15 minutes.

These figures describe limits, not guarantees that every source will work. Playlists, live streams, restricted videos, trimming and MP4 are outside the tool’s scope. A higher MP3 bitrate also cannot restore information missing from the original audio.

Review the awkward transitions

When reviewing a similar interface, inspect cases where the source total is unknown, an estimate changes, a job waits between stages, the user cancels, the output expires, or the final browser transfer is interrupted. Check what the screen claims at each transition.

The question I find useful is: what observation makes this message true? If the only answer is that a timer elapsed or a button was clicked, the message probably claims too much.