The fan on my aging laptop is dying, so I ordered a new fan and decided to do some upgrades. I've installed SSDs for several people, including my wife's laptop, but I was running an OEM HDD, mainly because the thing just won't die. Well, one of the upgrades is SSD. It's amazing how much faster it is. I'm also doubling my RAM (to 16gb), but it hasn't arrived yet. I'm kind of questioning the need for it now, but I have ran at 80% usage before, somehow. Maybe the upgrades will breathe some new life into some otherwise aging hardware. I should have switched to an SSD a long time ago. I used to always switch out OEM RAM, but when I bought the laptop it was the fastest computer I'd ever owned.
This is the first time in almost a decade I haven't had dual boot with Windows and Linux. I rarely boot to Windows, but I like to have it if I need it. I may just run a virtual machine with Win10 if I need it now.
I bought an external enclosure for my old HDD, mostly intended for backups. No use wasting a drive. If you haven't made the jump to SSD, it's definitely worth it.
Documenting Clay has me thinking about improvements beyond 2.0. I have a while before I get to 2.0, but I like to look ahead; I like to know what I'm writing will eventually look like. Originally 2.0 was supposed to just be front-end updates. I shifted some of the 2.x updates to 1.x because I finished what I had originally wanted to call 2.0 so quickly.
While that all means 2.0 will take a little longer, it gives me an opportunity to make 3.0 even better. For 2.x I will be rewriting a lot of the base classes that make up applications and themes, using their object models more effectively, and recreating a debug layer that will give a developer a better understanding of what is going on behind the scenes. The debug layer hasn't been updated in years and is now only helpful if there is an error. My plan is to give developers a visual demonstration of the data flow and a profiler that gives them insight in how things are working behind the scene.
This will all be possible by moving the data flow out of the current array system and into a central template data object. That move will also shrink the application object and the amount of logic required to determine output. Finally, it aligns better with the features I'm building into 1.x for 2.0 and simplifies template data overall.
I have to finish these docs and 2.0 before I can move on to that, but I should have a good plan when the time comes.
I've been adding documentation to Clay, it's way over due. My goal is to have a readme file in every folder and then a readme file for at least all of the files in the Clay core. I dug up some of my old docs to see if I could use any of them, unfortunately I've rewritten Clay so many times most of them were obsolete.
While documenting Clay I'm also updating code comments and running a generator to document that way as well. I prefer inline comments, which generators don't pick up, so unfortunately it won't replace the need for readme files. It does however give a more verbose view of how Clay works, so I see an advantage to having both.
My goal is to document all of Clay, which will take some time. It'll also give me a thorough code review, so as always, docs are worth the trouble.
I updated ClaySS to use iotaCSS 1.5. I'll probably update to the latest version of iotaplate soon, but that's a little more work so not sure when I'll get to it.
I've converted the Vision theme to ClaySS as Vision2, it looks a little different, but mostly the same. I also updated the ClaySS repo to 1.1, but I then identified an issue because the iotacss enabler flag variables are not included (you can add them or wait for 1.2 next week).
I am pushing Clay 1.4 to a later date, so I can spend some time rounding out 1.3 some more. I want to add some blocks, apps, themes, and work on docs in Clay and ClaySS before I move on to the changes in 1.4. That means I'll probably have some minor 1.3.x builds popping up here.
I also have help working on Clay now so I want them to have a little time working with a stable version before we start changing it too much. The even numbered 1.x versions are unstable builds, so 1.4 won't be live here anyway. I'll declare 1.3 in January, then the next few months I'll have 1.3.x versions here. Clay 1.4 will introduce a new REST API and some features that make applications more powerful, similar to how 1.2-1.3 have been about improvements to the front-end.
I merged the Clay Installer updates into my 1.3 dev branch tonight. That was the last major merge for 1.3, I hope. I have some minor fixes here and there, but 1.3 is almost finished. I'm going to spend some build themes and working in small improvements, but I don't have very much more planned as far as major changes.
I'm very happy with the way this version has turned it. I now have a new CSS framework, written specifically for Clay, and supported by both Clay (the CMS) and Clay Installer; a unified theme system across Clay and Clay Installer; Vue.js support; and built in Markdown support. Not bad for a couple of months of work.
I've decided I'm keeping the 2 new themes I've made, one will be the default in the Installer, but I'm building a new theme for here.
The Clay Installer uses only ClaySS for styling now and supports Clay themes, instead of having its own. JQuery is no longer used in Clay, tonight I began transitioning the installer to Vue.js. It used very little jQuery, but even less vue.js. So far I haven't found anything I used jQuery for that I can't do with Vue and normally it's way less code. There is definitely a performance boost as well.
I upgraded most of the templates in the installer today, it still uses jQuery, but nearly all of the templates now use ClaySS. It's really easy to make a clay theme now, so it shouldn't take long to finish the ctx-2 theme.
I will be adding a few ClaySS components based on things in the installer. I haven't decided if I'll use all of them in Clay, but if I'll try to just extend current components if I can.
One feature I will be adding to Clay as part of this update are base page templates that will go in the Common app. I've noticed ClaySS has kinda standardized page templates, so they will likely be the same across most themes. This will prevent every theme from having a requirement to have the base templates, such as dashboard and app page templates.
Overall I think I'm on the way to a solid 2.0 and a good segway into the planned changes for 3.0.
The final step to complete Clay 1.3 is to revamp the Clay Installer. The installer is it's own CMS within Clay, generally only used to install or upgrade a package (such as Clay itself). Currently it has its own themes and styling, because I never transitioned it to Bootstrap. The revamp will move all of the installer's styling to support ClaySS and it will use the same themes as Clay.
I had considered just changing all of the installer's packages' to use ClaySS styling and make the new Potter theme the default for the Installer. I like the installer's theme though :) so instead I'm upgrading the CTX-1 theme as CTX-2 with ClaySS support so it can be used by both Clay and the Installer.
There are some architectural changes I'd like to make within the Clay Installer, other than themes, but I don't know if they'll all make it into this update. Some of those may affect Clay's framework and thus Clay overall. That is beyond the scope of the roadmap for the 2.0 branch, so those may be saved for an incremental change beyond 2.0.
This is the first of a blogging series I'm starting, Open Source Blogs, where I attempt to use only open source hardware and become as technologically independent as possible.
Over the years, I have become very dependent on Google and their products. I'm not alone, as their email and browser are #2 and #1 in their market share. The email numbers were for 2016, but the 2017 numbers will put Gmail even closer to Apple. I'd guess in volume Google has the lead from email addresses. This is about email clients, so Google hasn't taken control, yet.
More than anything, I'd become extremely reliant on the Google Inbox app for Android. It is a very good email app, I'd even say the best I've ever used. I did some research and came across an open source Android app for email, named K-9 Mail. You can view their Github project here. Now, I'd been using the best email app I'd ever used, so I didn't have extremely high expectations. K-9 isn't Inbox, but it's fully capable and it supports multiple email accounts. I don't want to just get away from the Gmail app, I want to get away from Gmail, but it takes time to migrate 13 years worth of email usage. I've been using K-9 for a week now, for both Gmail and my new email account. It gives me notifications for both accounts and I haven't had a single issue with it. If you have an issue connecting to Gmail, you may have to enable connections to "less secure" clients. It's not less secure, but they label it that way to keep you on their client.
The phone is settled, unless I find another option. Time to replace Gmail in my browser on my laptop. I run Linux Mint, plus I'm looking for an open source desktop client, so I'm not expecting MS Outlook. I used Thunderbird years ago, before I used Gmail, so I thought it would be ironic to use it as my first client away from Gmail. Thunderbird is made by Mozilla, just as the Firefox browser. Years ago, Mozilla had a suite that included a browser and email client. It was originally Netscape and I believe they had one named SeaMonkey after Netscape. Anyway, Firefox and Thunderbird were the standalone (and completely new) browser and email client introduced to replace their suite. Thunderbird came pre-installed on Mint, so I fired it up and added Gmail, along with my new account. For Gmail I'm using POP, so I can download all of my Gmail messages over the years. The last time I checked that is over 3gb of email, so it's going to take a while to get the all. No issues connecting to Gmail (Thunderbird already knows their server info), other than enabling POP access within my Gmail account.
For my new email account, I am using IMAP within Thunderbird, instead of POP like Gmail. IMAP lets you read the emails as they are on the server and whatever you do to the emails generally syncs to the server. POP lets you download the emails and, in most cases, removes the email from the server. Gmail gives you options for what happens when you use POP, including keeping a copy on the server in different forms. I wanted to remove my Gmail message from the server, so I selected to delete them when they are downloaded. We'll see if they are actually deleted. So I have Thunderbird running two email accounts on different connection types and haven't ran into any issues. I also changed the download folder for my Gmail messages, so I can archive them and to also add a bit of security. If someone gained access to my computer (remotely), they would possibly know to check the Thunderbird folder for my messages.
For OSB.1, I'm just listing the 2 clients I am using right now. For other things, I'll probably list more options. I'll also do a follow-up and introduce some other options for email, once I give them a test run. That's it for now, as always, if there's an open source option, use it.