Today started setting up our new #exist server and installing all the dependencies and stuff that we require. I forgot how involved it is to install #scipy — you even need a fortran compiler installed! Crazy. Anyway it’s now at a point where theoretically it should be able to start receiving and completing tasks from the #redis queue, once I’ve configured the firewalls on both servers so that they can share access to Redis and #mysql. This all new to me so I hope I don’t break anything.
Finished all the relevant code for heart rate in #exist, including Withings and Runkeeper now too, but can’t test every service without a means to put fake data in there so I’m putting that off for a little bit. I’ll come back to it when I can make myself care more.
Moving on now to drafting a set of new attributes that we’ll support, things that people can put into Exist even if we don’t have a service that provides them (yet). Things like commits, emails sent and received, time spent meditating. Should hopefully be handy for people wanting to use the API to track stuff themselves.
On a slightly related note, yesterday I discovered that #mysql has just added a #json field type which means I might be able to put off our switch to postgres potentially forever. Woo! That makes my life a lot easier.
- User Stories - I will use #Trello as my agile storyboard / user story management and change management
- Wireframes - I will use #Axure for wireframes and mock prototyping.
- Environment setup - I will use #XAMPP on a local machine with #MySQL as the chosen database and #PHP as my chosen programming language.
- Code Management - I will use #bitbucket to practice the behaviour of managing code branches and merging.
- Other Technologies - I will employ #css but most probably a bit later once the functional aspects have been covered. The likelihood also is, if I find another technology which assists in meeting the use case and it can be implemented I will. i.e. #JSON / #JQUERY.
Thanks #Littlelogs community for the opportunity to share this with you, sorry the post is too long.
No rest for the wicked/only developer. #exist had some uptime issues before which turned out to be a corrupted table in #mysql. I repaired it but couldn’t figure out the cause. And now, was just going to sleep when I saw the same thing happened again — ugh! I’ve fixed the symptom again but I suspect I’ll spend tomorrow trying to find the root cause. Very stressful times. #sysadmin
Wrote some docs about migrating MySQL databases between servers today. It was one of those things that I had been interrupted on repeatedly in the past couple of weeks, so I’m glad to finally have it off my list. I want to get better at avoiding situations like that. When a task or project stalls on me, in my mind it starts to grow and grow into a giant, insurmountable thing, slowing my progress even more. (But once I get passed something like that? Then I’m really moving!)
Lots of other stuff is going on, but I wanted to mention that progress continues on the as-yet-unnamed readme project. I want to express my love for what I’ve been thinking of as “README-only” projects (like this one or that one). It’s heartening to see a middle ground between large, durable documents (i.e., books) and small, ephemeral documents (i.e., blog posts).
Successfully copied a copy of the live #exist database from #mysql to #postgres using
pg_loader. Woo! I still can't quite believe it happened as quickly and smoothly as it did (database is several gigs). I should even be able to switch the live database over without taking the site down. For now I'll just work with making sure postgres is fine on my dev server, and plan my next steps.
Today I'm starting to look at how I can bring the current #exist codebase in line with the functionality I wanted out of the planned exist-core v2, rather than rewriting and being susceptible to the Second System Effect. This involves:
- Migrating from #mysql to to #postgres
- Adding the new event stream table with #json-b metadata field
- Potentially migrating to #python 3 (perhaps relying on
- Pruning away a lot of accumulated cruft that wouldn't have appeared in v2
- Potentially open-sourcing the result
Right now I'm on the first step. I'm looking at using pgloader to migrate data into postgres. In the past I've run into issues migrating to postgres (and so quickly gave up) but I'm hoping pgloader will be my shining light.
Stupid #mysql and its default collation of
latin1. I swear I'd already switched #littlelogs to
utf8mb4, but turns out I hadn't — now rectified. Also annoying that it has a separate collation (the
mb4 bit) needed to handle 4-byte characters, like emoji. Anyway, sorted! Emoji in logs is fixed. 😆🎉
Started working on some #littlelogs paid plan ideas, which revolve around private group/business accounts on their own subdomain (like how Slack does it I guess). I set up a #stripe test account and started looking at #django subdomain handling solutions, and then wrote a proof of concept for creating and migrating a new database on-demand (like when a new group account is created). For now I'm using django-dynamic-db-router to switch between DBs as needed — we'll keep it as one codebase, but logged-in user views will perform queries against the separate group DB.
Trying to finish the web dev course that I started earlier this year. Some of the sections don't interest me (Wordpress, PHP) but i'm determined to get my certificate of completion. Working on the #MySQL component at the moment - using PHP :/ but I finally found a use for the so called back tick, `. I never knew what that key was for