Now that this blog is "finished" (I still have a few things to work on, but I can start switching focus), I need to think more of my social media idea. I left off implementing the content pages, but then I switched to the blog.
Android is weird, so I have to think of weird ways to construct these views. Now, what I want, is to resemble actual pages. The only scrolling you do is in a way fixed between pages, kind of like a book. This is hard, as I'd have to somehow swap content in and out, with a smooth transition, while keeping fluidity. I thought about loading the other pages along with the first page on open, and then pre-constructing a view to swap to. I also wonder if there's anything in Android for technical "pagination". Though I think I will go with the former, as it seems much easier to me, though I don't know if Android has view pre-caching either. So that could be tricky, but I'll find something.
Also, just a heads-up, once I finish this app, you'll be able to sign up for the beta (I don't know where yet, but once I open it, I'll post about it, with information on how the app works). This beta will be Android only (and so will the release, unless iOS demand is high, and provided I have the money and tools), and will work like this. You'd enter your main email into a field on the site. Then, on my server, a random email will be pulled and added to the beta group. Once that occurs, you'll receive an email saying that you have access, and giving instructions on downloading the app. Simple, hopefully I can get the beta release done soon, shouldn't be too hard (famous last words of mine). Also, hopefully tomorrow I'll post about either work on this blog, or my pagination work (provided I beat on it tomorrow).
Even though I've been writing since the day before yesterday, I just now put the blog up! Feast your eyes, and read through my ramblings. As you can see, I just put up the first four initial posts (minus this one), and there will be another tomorrow! What will it be about? I don't know! Will the site have changes by then? Probably a few. Anyway, time to sleep.
Launching something new is always fun though. Even though I had a 500 error for a good hour, solely because I forgot to actually add the tables to the database. Also, this is the first time I've used Gunicorn, and the first time I've had SSL on a site with actual content, so that's a plus.
Also, as a final thing, the projects/portfolio page will come back at some point. So you can see the greatness that is my projects soon enough. But for now, I am just focusing on the blog aspect.
CTML: The Library of an Era
By far, the most popular library on my Github is one that I started one boring afternoon. It was pretty much just a tiny idea I had, because I like web and C++. I had decided to try and make a dynamic document generator for C++. This library is CTML.
It has 14 stars, a 280% increase from my second most starred project, mcv.
This library is a super simple header-only C++ library. In my mind, there’s pretty much no complexity to it, and I really don’t think it’s that useful. But, people think the opposite is the case, evidently. It consists of two header files (technically three header files, and the tests.cpp file, but I don’t think those count, especially since the third header consists of just two includes), and consists of four hundred and forty five lines of code.
Enough summarizing the code, this is a look back from my point of view. So first of all, the styling of this library is god awful in my mind. Almost no line breaks, a comment on almost every line. I used to be in this mentality that if I didn’t comment everything, my code wouldn’t be as good.
An example of one of some of the code, some lines are so long that they are cut off.
The library was pretty fast, considering some of the code I had written. But, another thing I wonder now, is what’s the practical use of this library? I don’t think I had a reason for writing this other than I wanted to see if I could. Like, I don’t know what I would apply this to, other than like, maybe making a really fast web content server, but that’s about it.
Also, I just remembered my hack for HTML documents. First of all, Documents are constructed from a doctype node, a head tag node, and a body tag node, all of which are private. The doctype node is the most hacky node in the whole application. It consists of a Node with no name, but with a content of just “html”. The only single thing that makes it into a doctype, is the special “DOCUMENT_TYPE” NodeType. Then, within the ToString method for Nodes, I have a special case for DOCUMENT_TYPE Nodes. This case is shown below.
As you can see, it pretty much just adds the content into a hardcoded doctype tag. Such superb coding. Also, going back to all of the document children being private. Instead of doing the smart thing and just having the Document class just be a root HTML node, I made a separate class for it, and disallowed it to have any other children other than that. Technically, the doctype isn’t even a child, that’s partially why I made the document a different class at that time, because I was too lazy to find a more correct solution. I might go back to this and make it less simplistic, and much more robust and properly formatted. But for now, my most popular library on Github, is a project that I wrote, that I don’t even know the purpose of.
For this blog, I decided that a markup language was in order. I feel that writing HTML tags in the posts themselves would clutter up the whole view. Of course, I looked at the usual markup languages, like Markdown. Markdown was of course my first choice, as it is the fastest and most widely used markup language out there. But, Markdown has this weird thing where it wraps every single thing on the page with paragraph tags. My CSS depends on the paragraph tags just being text, and only text.
So of course, Markdown wouldn’t cut it. I also don’t really want to install a ton of libraries for a simple little tags for posts. So I decided to make my own, so in comes tinplate. Tinplate isn’t a thing I’m releasing, or a thing that’s really all that great, I just made it out of the want and need for it. There’s not even much in it right now, and it runs pretty much entirely on regex.
There are so far two things in it, images and links. The syntax consists of two brackets that contain the data for the image or link. Like for example, “[“http://example.com” “This is a link”]”, which, when a asterisk is in front of that, it parses it into an anchor link. Pretty simple, and it only took me about fifteen minutes to write. Images are pretty much the same, just with a pound symbol instead of an asterisk.
That’s pretty much all there is to it really. I’ll be adding on more elements as I make more posts that require those elements. But for now, this is all I’ll really need. My next post will probably be a reflection of my most popular library on Github, CTML.
Consistent Image Blurring on Differing Image Sizes
I've been working on a little social media project for mobile, and for the feed page, there are cards with the first page's background image blurred. Blurred images are done server side once the image is uploaded. This blurring also scales the image down by a fraction of the aspect ratio. Creating a fast loading and blurred image as a more engaging background, making the feed pop.
An example of one of these cards (subject to change)
These cards are constructed by the blurred background image having a mostly transparent black view put over, with the title and author name in the top corner. The hardest part of these cards are the blurred background images.
First, the images are uploaded to the Django server. Then, using Pillow, I create a copy of that image for use in burring. Next, I blur the image by the width added to the height, multiplied by a fraction of the aspect ratio, currently that fraction is twenty five thousandths. Next, post blurring, the image is scaled down by five hundredths of the aspect ratio. This creates a very small and easy to load image that acts as the frosted glass background for the card.