Did you know that files with the extension .docx are really just .zip packages?
#LibreOffice #Word #Office
Author and full stack web developer experienced with #PHP, #SvelteKit, #JS, #NodeJS, #Linux, #WordPress, and #Ansible. Check out my book at sveltekitbook.dev!
Do you like these posts? Consider sponsoring me on GitHub!
Did you know that files with the extension .docx are really just .zip packages?
#LibreOffice #Word #Office
On this website, I normally only write about solutions I’ve come up with to problems I’ve encountered (pertaining to web development). I recognize that’s not entirely authentic because I can’t solve every problem I come across. Sometimes, I’ll come across an issue where the solution isn’t immediately clear to me. Sometimes, it festers for long enough that I’m driven to take drastic action. Sometimes, I’m forced to write an entire post about it. This is post about one of those festering, unsolved problems.
It started while working on the Svelte Work:Rest Timer component I wrote about a few months ago. You see, the timer was intended to be a static Single Page Application (SPA)/Progressive Web Application (PWA) without a back-end server component. That is, once served to the client and installed via the browser PWA installation process, it would be usable on mobile devices whether or not they had an internet connection. I thought surely, this will be easy enough for me to tackle since I’ve already built something similar with helth app. The only major difference being that this timer application would utilize the SvelteKit static site adapter instead of the Node.js adapter.
The Problem
During development, everything ran smoothly. It wasn’t until deployment to production that I noticed issues.
SvelteKit uses Vite to deliver that buttery-smooth development experience, and Vite uses esbuild to bundle an application during development. However, when building the production version of an application, Vite uses Rollup to bundle the app. I believe this discrepancy; coupled with my obvious lack of understanding of the underlying technologies behind SvelteKit (Vite, esbuild, and Rollup), is why I ran into any issues in the first place.
When I attempted to deploy my static files to a static host, I noticed the app was missing several key features, like some of the actual code that made the logic in the application run and the CSS included in each component. After checking the network requests in my developer console, I noticed the development version was making 3-5 more requests than my production build. Why?
When deployed, the production build was very broken.
Troubleshooting
Since I had built the application to be static, it was safe to prerender the HTML on the one and only page. Any two users should see identical HTML, CSS, and JS on the site when they open it for the first time. To accomplish this, I simply needed to add the following code to the file src/routes/+layout.js:
export const prerender = true;
export const ssr = false;
I figured since there wouldn’t be a back-end component of the application, it would be fine to disable Server-Side Rendering (SSR) while I was at it. My thought was that this would force SvelteKit to prerender and it would skip generating any server-side code for that route.
I discovered that if I removed the line that disabled SSR, I would get a different index.html located at .svelte-kit/output/prerendered/pages/index.html.
Left: index.html included in “build/”Right: index.html included in “.sveltekit-output/prerendered/pages/” when option that disables SSR is removed
This file contained links to resources that were not being loaded in my production version of the app. This file was also not included in my production build folder (build/). I don’t fully understand why disabling SSR and enabling prerendering generates a different version of the index.html file. I also don’t understand why the version of index.html I needed wasn’t included in my build directory. For now, I’ve simply overwritten the file build/index.html with the file .svelte-kit/output/prerendered/pages/index.html and the application works as expected.
If you or someone you know has some insight as to why this is, please drop a comment below, reach out to me via my contact form, or message me on various social media platforms. I would love to understand what I assume I’m doing wrong.
I know its cliché to ask it but I’m going to anyways; where did the year go? It feels like just yesterday, I was writing about setting up a Node & MongoDB with Docker Compose.
#2022 #Recap #FullStack #WebDev
I was recently approached by a friend to build an app. Now, I’ve been cornered and pitched far too many half-brained apps in my day but it is refreshing to hear a good pitch. This pitch was for a timer, but not just any timer or stopwatch app that comes preinstalled on your phone. Rather, it was a workout timer that would also time your rests. As someone who often takes too long to rest between sets, I thought this sounded like a decent idea. I was told “nothing like this exists!” but a quick search of the web proves that false; it’s definitely been done. But I could do it as a Svelte component! And it’d be a fun coding challenge!
The Setup
If you’ve read any recent posts of mine, you know I’ve been working with SvelteKit lately. To get started with SvelteKit, I ran a few commands in the project directory:
npm create svelte@latest timer
cd timer
npm install
npm run dev
From there, I created the file /src/routes/+page.svelte as the entry point page for the app. I also created the file /src/lib/timer.svelte which is where all of the magic happens and included it in the aforementioned +page.svelte like so:
+page.svelte
<script>
import Timer from ‘$lib/timer.svelte’;
</script>
<div class=’content’>
<Timer />
</div>
<style>
div.content {
text-align: center;
width: 100%;
background-color: #130d0d;
position: absolute;
top: 0;
left: 0;
right: 0;
bottom: 0;
color: #d9d9d7;
}
</style>
$lib is an alias to /src/lib/ that is supported by SvelteKit out of the box.
The Markup
Most timers have a display of the running time, a start button, a stop button, and reset button so I went ahead and included those right away in /src/lib/timer.svelte. I also gave it some rough styling so it wasn’t awful to look at while testing. The basic structure of the component looks something like this:
<script>…</script>
<h1>Work+Rest Timer</h1>
<div class=’time’>{hr}:{min}:{s}.{ms}</div>
<div class=’controls’>
<button class=’start’ on:click={start}>{running ? `rest` : `start`}</button>
<button class=’stop’ on:click={stop}>stop</button>
<button class=’reset’ on:click={reset}>reset</button>
</div>
<style>
h1 {
text-align: center;
}
.time {
margin: 1.5rem;
font-size: 4rem;
}
.controls {
display: grid;
grid-template-columns: 1fr 1fr 1fr 1fr;
grid-template-rows: 1fr 1fr;
}
button {
padding: 1.1rem 1.4rem;
margin: 1.1rem;
font-size: 1.5rem;
border: none;
background-color: #496bf0;
color: white;
transition: all .4s ease-in-out;
cursor: pointer;
grid-column: 3 / 4;
grid-row: 2 / 3;
}
button:hover {
background-color: #2047df;
}
button.stop {
background-color: #df3d2c;
grid-column: 2 / 3;
grid-row: 2 / 3;
}
button.stop:hover {
background-color: #a81303;
}
button.start {
background-color: #408e2a;
grid-column: 2 / 4;
grid-row: 1 / 2;
}
button.start:hover {
background-color: #245e14;
}
</style>
Yup, that’s a timer alright.
Eagle eyed readers likely noticed that there are some variables used in the markup that were not declared in the script tag. Lets get to that part now.
The Logic
This timer needs to be able to start, stop, reset, and display the running time. It also needs a “rest” feature which counts down to zero from whenever the “rest” button was clicked. To prevent users from starting another timer, I decided to turn the start button into the rest button while the timer is running. A quick rundown of how this ought to work:
clicking “start” starts the timer (duh)
the time since start is displayed in hours, minutes, seconds, and milliseconds
after clicking “start,” the “start” button becomes the “rest” button
clicking the “rest” button will reverse the time, counting down to zero
when the timer reaches zero, it will start counting up again until stopped or until “rest” is clicked again
clicking “stop” will stop the time
clicking reset will set hours, minutes, seconds, and milliseconds back to zero
That all seems fairly straightforward, right? Oh, but dear reader, you don’t know this (how could you have?) but when it comes to code, I hate programming anything related to time. And I’m really bad at math.
So why did I think this was a good idea? 🤔 Who knows? Maybe I just hate myself.
Side note: When working with computers and time, there’s all sorts of problems that can arise. It’s a lot easier to do math with time when you convert time to a regular number.
About those missing variables…
<script>
let interval = null;
let running = false;
let elapsed = 0;
let oldElapsed = 0;
$: ms = pad3(0);
$: s = pad2(0);
$: min = pad2(0);
$: hr = pad2(0);
// pad2/3 exist to format the numbers with leading zeros
const pad2 = (number) => `00${number}`.slice(-2);
const pad3 = (number) => `000${number}`.slice(-3);
const start = () => {
…
}
const stop = () => {
…
}
const reset = () => {
…
}
</script>
You’ll notice some that weren’t mentioned the markup; you can ignore those for now. The times (hr, min, s, ms) are all declared as reactive because I want the timer display to update as the those values change. Now all of this keeps the component from throwing errors but it doesn’t do anything. To make it do the things, let’s look at start() first.
const start = () => {
if(!running) {
countUp();
}
else {
countDown();
}
}
There! That was easy. Lets move on to the stop() and reset() functions:
const stop = () => {
clearInterval(interval);
oldElapsed = elapsed;
}
const reset = () => {
s = min = hr = pad2(0);
ms = pad3(0);
elapsed = oldElapsed = 0;
running = false;
clearInterval(interval);
}
Wait a minute, this doesn’t make any sense without looking at what’s actually going on in start(). Let’s back up. Here’s countUp() which is called by start() when running is false.
const countUp = () => {
let startTime = Date.now();
running = true;
interval = setInterval(() => {
elapsed = Date.now() – startTime + oldElapsed;
ms = pad3(elapsed);
s = pad2(Math.floor(elapsed / 1000) % 60);
min = pad2(Math.floor(elapsed / 60000) % 60);
hr = pad2(Math.floor(elapsed / 3600000) % 60);
});
}
The secret sauce here is setInterval(). Since it has not been provided the optional second argument, it loops on the function passed to it every millisecond. In that loop, the time since the counter began counting upwards is calculated by subtracting the start time from the current time. Then, each “section” of the timer display is calculated based on that elapsed time (and padded with extra leading zeros). Since the interval is assigned to the variable interval, I can clear it later on in stop() and reset() to stop the code.
Now for the part that I spent way too long on; countDown().
const countDown = () => {
stop();
const end = Date.now() + elapsed;
interval = setInterval(() => {
elapsed = end – Date.now();
ms = pad3(elapsed);
s = pad2(Math.floor(elapsed / 1000) % 60);
min = pad2(Math.floor(elapsed / 60000) % 60);
hr = pad2(Math.floor(elapsed / 3600000) % 60);
if(elapsed <= 0) {
clearInterval(interval);
reset();
countUp();
}
});
}
The first thing I want to do here is stop the timer where it’s at. That way, I can clear the value inside the interval variable. Once that’s done, the end time of the new timer needs to be calculated. That’s done by taking the amount of time elapsed and adding it to the current time. Once the end time has been calculated, the loop that runs every millisecond begins, where the amount of time elapsed is recalculated by subtracting the current time from the end time. It is then all shown in the timer display, and when the amount of elapsed time reaches zero, the interval is cleared, values are all reset to zero, and the count back up begins again.
If you were confused during any of that, that’s fine. You’re probably a sane, well adjusted human being that gets along perfectly well in social interactions. Congratulations 🥳!
All Together Now!
<script>
let interval = null;
let running = false;
let elapsed = 0;
let oldElapsed = 0;
$: ms = pad3(0);
$: s = pad2(0);
$: min = pad2(0);
$: hr = pad2(0);
const pad2 = (number) => `00${number}`.slice(-2);
const pad3 = (number) => `000${number}`.slice(-3);
const countUp = () => {
let startTime = Date.now();
running = true;
interval = setInterval(() => {
elapsed = Date.now() – startTime + oldElapsed;
ms = pad3(elapsed);
s = pad2(Math.floor(elapsed / 1000) % 60);
min = pad2(Math.floor(elapsed / 60000) % 60);
hr = pad2(Math.floor(elapsed / 3600000) % 24);
});
}
const countDown = () => {
stop();
const end = Date.now() + elapsed;
interval = setInterval(() => {
elapsed = end – Date.now();
ms = pad3(elapsed);
s = pad2(Math.floor(elapsed / 1000) % 60);
min = pad2(Math.floor(elapsed / 60000) % 60);
hr = pad2(Math.floor(elapsed / 3600000) % 24);
if(elapsed <= 0) {
clearInterval(interval);
reset();
countUp();
}
});
}
const start = () => {
if(!running) {
countUp();
}
else {
countDown();
}
}
const stop = () => {
clearInterval(interval);
oldElapsed = elapsed;
}
const reset = () => {
s = min = hr = pad2(0);
ms = pad3(0);
elapsed = oldElapsed = 0;
running = false;
clearInterval(interval);
}
</script>
I put together a repository of this code so you can read it in all of its glory there. If you follow the development, you’ll see new features like “beeps”, fun colors, and buttons that allow you to multiply the rest time by a factor of 1.5, 2, or even 3! If you like tracking calories as well as working out, then keep a watchful eye out for this new feature coming to your favorite health tracking application.
I’ve been writing on this blog for nearly 9 years and I’ve learned so much since I started. The style and the content have come a long ways and I cringe every time I read old posts thoroughly enjoy seeing how I’ve grown as a developer. I’ve interacted with people that I never would have had the chance to otherwise. It’s been a wonderful learning experience.
While my intentions have always been for this site to exist as a sort of journal/wiki/knowledgebase/playground, I’ve always secretly wanted to become a billionaire tech influencer. And now you can help me achieve that goal by buying my merchandise!
BUY! BUY! BUY!
By purchasing merchandise from my shop, you can support this site financially, by giving me real money that you’ve earned for your “hard work.” While donations are always appreciated, I understand that you may want something in return; something tangible, something you can see and smell, something to keep you comfortable while you cry yourself to sleep. And since nobody actually donates to strangers on the internet, I opened a shop.
All of the designs are completely original and there are many, many more to come. The pricing is affordable for all budgets and will only expand with more options. Be sure to check posts here often by following the social media channels or the RSS feed. There may just be coupon codes hidden in future posts 😉.
So if you’re ready to showcase the fact that you know what HTML is and like the look of monospaced fonts, then you should go checkout the new closingtags merch shop. Once you’ve got the closingtags swag (closingswag 🤔), be prepared to have people you barely know ask if you “work with computers” or to tell you about their genius new app idea.
Don’t forget to buy, buy, buy!
I know that I just wrote a post about using Svelte Stores with localStorage but very shortly after writing that (and implementing it in my own app 🤦), I came across this blog post from Paul Maneesilasan which explained the benefits of using IndexedDB:
So, the primary benefits to using a datastore like indexedDB are: larger data storage limits (50MB), non-blocking operations, and the ability to do db operations beyond simple read/writes. In my case, the first two alone are enough to switch over.
https://www.paultman.com/from-localstorage-to-indexeddb/
Since I had some fresh ideas for my own app about storing lots of data that could potentially would definitely go over the Web Storage 5-10MB limit, I dug even deeper into the research. In the end, I too decided to make the switch.
Sexy Dexie
The documentation for IndexedDB can be overwhelming. It’s great how thorough it is, but I found it difficult to read. After spending a few hours trying to understand the basics, getting bored, looking at memes, and finally remembering what I was supposed to be doing, I came across a package called Dexie. Dexie is a wrapper for IndexedDB, which means that it will make calls to the database for me; for instance Table.add(item) will insert the item object on the specified table. This greatly reduced my need to build that functionality myself. Since I hate reinventing the wheel (and my brain can only learn so many things in a day), I opted to use this package to manage the database. Plus, Dexie has a handy tutorial for integrating with Svelte and makes managing database versions a breeze.
While the Dexie + Svelte tutorial is great, including Dexie in each and every component that gets and sets data (like the tutorial does) would be cumbersome. It would be far simpler to use Svelte stores across components, and have the stores talk to IndexedDB via Dexie.
Custom Stores
Since IndexedDB; and therefore Dexie, utilize asynchronous APIs, a few things need to be done differently to integrate with Svelte stores. Firstly, we can’t just “get the values” from the database and assign them to a writable store (like we did in the localStorage example) since we’ll be receiving a Promise from Dexie. Secondly, when the data is updated in the store, we also need to update the data in the database; asynchronously.
This is where custom stores come in. In a custom store, we can create our very own methods to manage getting and setting data. The catch is that the store must implement a subscribe() method. If it needs to be a writable store, then it also needs to implement a set() method. The set() method will be where the magic happens.
To get started, follow Dexie’s installation instructions (npm install dexie) and create a db.js file to initialize the database. I’ve added a couple methods to mine to keep database functionality organized:
Note that is generic code sampled from helth app so references to water, calories, and sodium are done in the context of a health tracker.
import { Dexie } from ‘dexie’;
// If using SvelteKit, you’ll need to be
// certain your code is only running in the browser
import { browser } from ‘$app/environment’;
export const db = new Dexie(‘helthdb’);
db.version(1).stores({
journal: ‘date, water, calories, protein, sodium’,
settings: ‘name, value’,
});
db.open().then((db) => {
// custom logic to initialize DB here
// insert default values
};
export const updateLatestDay = (date, changes) => {
if(browser) {
return db.journal.update(date, changes);
}
return {};
};
export const getLatestDay = () => {
if(browser) {
return db.journal.orderBy(‘date’).reverse().first();
}
return {};
};
export const updateItems = (tableName, items) => {
if(browser) {
// .table() allows specifying table name to perform operation on
return db.table(tableName).bulkPut(items);
}
return {};
}
export const getItems = (tableName) => {
// spread all of the settings records onto one object
// so the app can use a single store for all settings
// this table has limited entries
// would not recommend for use with large tables
if(browser) {
return db.table(tableName).toArray()
.then(data => data.reduce((prev, curr) => ({…prev, [curr.name]: curr}), []));
// credit to Jimmy Hogoboom for this fun reducer function
// https://github.com/jimmyhogoboom
}
return {};
}
I won’t go over this file because it’s self explanatory and yours will likely be very different. After you have a database, create a file for the stores (stores.js).
import * as dbfun from ‘$stores/db’;
import { writable } from ‘svelte/store’;
// sourced from https://stackoverflow.com/q/69500584/759563
function createTodayStore() {
const store = writable({});
return {
…store,
init: async () => {
const latestDay = dbfun.getLatestDay();
latestDay.then(day => {
store.set(day);
})
return latestDay;
},
set: async (newVal) => {
dbfun.getLatestDay()
.then(day => {
dbfun.updateLatestDay(day.date, newVal);
});
store.set(newVal);
}
}
}
function createNameValueStore(tableName) {
const store = writable({});
return {
…store,
init: async () => {
const items = dbfun.getItems(tableName);
items.then(values => {
store.set(values);
})
return items;
},
set: async (newVal) => {
dbfun.updateItems(tableName, Object.keys(newVal).map((key) => {
return {name: key, value: newVal[key].value}
}));
store.set(newVal);
}
}
}
export const today = createTodayStore();
export const settings = createNameValueStore(‘settings’);
Here’s break down what this does:
Import the db.js file and any extra functionality added to it.
Import { writable } from svelte/store since we’ve already established that I hate reinventing the wheel.
Create 2 functions; createTodayStore() and createNameValueStore(). Both functions are mostly identical except for the logic they call on the database.
Each function then creates their own store from writable with an empty object as the default value.
Both functions return an object that adheres to the store contract of Svelte by implementing all the functionality of writable, overriding set(), and adding a custom method init().
init() queries the database asynchronously, sets the value of the store accordingly, then returns the Promise received from Dexie.
set() updates the data within the database given to the store and then proceeds to set the store accordingly.
Export the stores.
Accessing the stores
Now that the stores have been created, accessing them isn’t quite as simple as it was when they were synchronous. With a completely synchronous store, svelte allowed access to the data via the $ operator. The stores from localStorage could be accessed or bound simply by dropping $storeName wherever that data was needed. With the new asynchronous stores, calling the custom init()method is mandatory before accessing the data; otherwise, the store won’t have any data! Here’s a simple Svelte component showing how to access the settings store data in the <script> tag and binding to the today store in the markup.
<script>
import { onMount, afterUpdate } from ‘svelte’;
import { today, settings } from ‘$stores/stores’;
import Spinner from ‘$components/Spinner.svelte’;
$: reactiveString = ‘loading…’;
onMount(() => {
settings.init()
.then(() => {
if(‘water’ in $settings) {
reactiveString = `water set to ${settings.water.value}`;
}
});
</script>
{#await today.init()}
<Spinner />
{:then}
<input type=”number” bind:value={$today.water} />
{:catch error}
<p>error</p>
{/await}
<p>{reactiveString}</p>
<Spinner /> source can be found here.
This instance of a reactive variable doesn’t make much sense unless it were tied to another value but the logic remains the same.
Accessing the today store value in the markup is made possible by use of Svelte’s {#await}.
el fin
Is this the best way connect Svelte stores to IndexedDB?
I have no idea. Probably not.
But it does seem to work for me. If you’ve got ideas on how it could be improved, leave a comment. I’m always open to constructive criticism. If you’re curious about the app this is taken from, I’ve previously written about it here. The source code for it can be found on GitHub.
And lastly, if you’ve enjoyed this post or found value in it, consider sponsoring me on GitHub.
Svelte stores are great for managing state in an application but when combined with modern browser features. they really shine. Let’s take a look at how I implemented localStorage in a recent project with an annotated sample file:
$stores/local.js
import { browser } from ‘$app/environment’;
import { writable } from ‘svelte/store’;
// it works with readable stores too!
// create an object w/default values
let goals = {
goal1: 2000,
goal2: 50
};
// ensure this only runs in the browser
if (browser) {
// if the object already exists in localStorage, get it
// otherwise, use our default values
goals = JSON.parse(localStorage.getItem(‘goals’)) || goals;
}
// export the store for usage elsewhere
export const goalStore = writable(goals);
if (browser) {
// update localStorage values whenever the store values change
goalStore.subscribe((value) =>
// localStorage only allows strings
// IndexedDB does allow for objects though… 🤔
localStorage.setItem(‘goals’, JSON.stringify(value))
);
}
Throughout the rest of the app, the “goalStore” (and therefore, the localStorage object) can be accessed by importing in components like so:
<script>
import { goalStore } from ‘$stores/local’;
import { browser } from ‘$app/environment’;
</script>
<!– prevent issues with SSR by only rendering dependent components in browser based environment –>
{#if browser}
<!– use ‘$’ for reactivity and ‘bind:’ to keep data upstream in sync –>
<Component bind:count={$goalStore.goal1} />
{/if}
As mentioned by Marc Rodney Tompkins in the comments, it may be necessary to wrap your code in browser checks as well. Svelte makes this easy with conditional {#if} blocks.
I hope this helps someone! If you’d like to see how I implemented this in its entirety, you can view the source code here.
Dear Vagrant,
You’ll always hold a special place in my heart but there comes a time when we have to put the past behind us. We grow, change, and you and I aren’t what we used to be. We’ve grown apart and become so different. There is no doubt that someone out there will love you, but for me; well I’m done with the days of an upgrade to VirtualBox breaking my virtual environment. I’m saying goodbye to your virtual machines taking a whopping 7 seconds to start. Vagrant, I’ve found someone else, and yes; it is Docker.
💔
If you’ve read any recent posts of mine, you’ll have noticed a distinct lack of information regarding WordPress. It’s not that I dislike WordPress now but given the option of developing with WordPress or not-WordPress, I’d choose not-WordPress. Remembering all of the hooks, the cluttered functions.php files, and bloated freemium plugins has all become so tiresome. That’s not to say that I’ll never work with it again, after all; this blog is powered by WordPress as is more than 1/3 of the web as we know it. Since I’ll never officially be done with WordPress, I should at least find some more modern ways to manage development with it.
Dockerize It
To get WordPress development environment up and running quickly, I use docker-compose. I’ve written about it before over here. It’s incredibly simple since the docker community maintains a WordPress image.
docker-compose.yml
services:
db:
image: mariadb:10.6.4-focal
command: ‘–default-authentication-plugin=mysql_native_password’
volumes:
– db_data:/var/lib/mysql
restart: always
environment:
– MYSQL_ROOT_PASSWORD=somewordpress
– MYSQL_DATABASE=wordpress
– MYSQL_USER=wordpress
– MYSQL_PASSWORD=wordpress
expose:
– 3306
– 33060
wordpress:
depends_on:
– db
image: wordpress:latest
ports:
– “8000:80”
restart: always
volumes:
– ./:/var/www/html
– ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
environment:
– WORDPRESS_DB_HOST=db
– WORDPRESS_DB_USER=wordpress
– WORDPRESS_DB_PASSWORD=wordpress
– WORDPRESS_DB_NAME=wordpress
volumes:
db_data:
For the most part, this file is the same as the one taken from the docker quick start example. Here are couple directives that I made changes to:
ports: I changed these around as I had some other services running from different programs
depends_on: Telling WordPress not to start until the DB has started also prevented some issues where I was seeing the famous “white screen of death”
volumes: set the current working directory to be the WordPress instance as well as created a custom PHP ini file to fix upload size restrictions
uploads.ini
file_uploads = On
memory_limit = 1024M
upload_max_filesize = 10M
post_max_size = 10M
max_execution_time = 600
Placing this uploads.ini file in a directory accessible by the docker-compose.yml let me fix problems with large file uploads.
I got 99 problems and they’re all permissions
This is all well and good but there are some issues when trying to develop locally. For instance, after running docker-compose up -d, I noticed that all files belong to www-data:www-data. This is necessary for the web server in the container to serve the files in the browser at http://localhost:8000. But then I didn’t have write permission on those files so how could I manage them?
I came across a couple of solutions but they each have their drawbacks. For instance, if I set the entire WordPress instance to be owned by my user, then the web server won’t have permission to read or write to files. I could also add my user to the group www-data but even then, I won’t have write permissions until I run something akin to sudo chmod 764 entire_wordpress_dir which isn’t desirable (but is probably the best option so far). The compromise I came up with was setting myself as the owner for all of the WordPress install, and giving WordPress ownership of the uploads directory. It seems that for now, I’ll just have to flip permissions via the CLI.
If you have ideas on how to resolve the permissions issue with WordPress and docker-compose, leave a comment below!
If you’ve been following along with any of my recent posts, you’ll likely have noticed that I’ve been working on something. It hasn’t been a secret but I also haven’t advertised it until now. In this post, I’d like to share with you a little bit about that project. If you’d like to see or use it for yourself, you can visit helth.closingtags.com. Yes, that’s how I intended to spell it but on the off chance you accidentally spell it correctly, that will should work too.
Why?
In the past, I’ve used apps like MyFitnessPal or Jawbone to track calories in, physical activity, and water consumption. I liked those apps but MyFitnessPal became a bloated mess and Jawbone went out of business 😢. I’m sure there are other fitness and health related apps out there that are just fine but I wanted to build something tailored to my needs. I’ve got experience as a web developer, so why shouldn’t I? It would also be a good excuse to learn a new technology like Svelte and SvelteKit.
helth app sodium and protein tracking
But, what does it do?
tracking
Helth app is intended to be simple. While it still has a long ways to go, it does already have some cool features. For instance, tapping the camera icon in the bottom right corner will open the camera on your device, and allow you to scan a barcode. Once scanned, if the item is found; helth app will automatically add calories, sodium, and protein to daily totals. Potentially, the app could track cholesterol, sugars, carbohydrates, fats, and even ingredients. It’s simply a matter of adding those components.
history
The app can then show the history tracked and will reset each day at midnight to allow you to start tracking the next day. The graphs still need work and are very limited but I’m hoping to make more progress towards implementing better charts soon.
goals + limits
If you’d like to set custom goals so you can be alerted when you’re approaching a limit or have exceeded your own expectations, the app allows you to do that as well, albeit, the functionality isn’t quite limited. Again, I hope to implement more of this functionality soon.
All your data are belong to… you? 🤔
Privacy and security are important to me. That’s why all data generated in the app is stored locally on your device. Due to security protocols implemented in most modern browsers (CORS), the barcode scanner does have to make calls to a custom API but other than that, all data entered should stay on your device. This can be a double edged sword in that if you clear your browser’s cache, all recorded data will be lost. An import/export feature is planned but is still a ways off.
The Project
Until today, I’ve been developing this project in a private Github repository but as of the publishing of this post, that repository is public. You can find it at https://github.com/Dilden/helth. I’m welcoming pull requests and issue submissions. If you’d like to add functionality, I’d love to work with you. If you want to run your own de-meme-ified version of helth app, go right on ahead. While the app is still a hobbled together mess, the more people are interested in it, the better off it will be.
It’s still missing quite a few features I’d like to see. For instance, I’d love for helth app to be installable as a progressive web app (PWA). But since SvelteKit is still in beta, the plugin I intended to use for adding PWA support has run into some compatibility issues. Once those are resolved, I believe it will be trivial to add PWA support. I’d also like to improve the overall styling of the app, add more data sources, build a text based item search and the appropriate user interfaces, and allow users to save “meals” so that they can be quickly added to the daily total without having to scan/search each item all over again.
If you would like to see a feature or notice a bug, you can report it in the project repository. If you don’t want to sign up for an account on Github, you can also fill out the contact form on this website describing the issue.
fitness can be our passion
‘Automating’ comes from the roots ‘auto-‘ meaning ‘self-‘, and ‘mating’, meaning ‘screwing’.