What do I say?

Itโ€™s been a good while since I made a post. Lots has happened, mostly good things. I found a job and as a result, my “extracurricular” activities have taken more of a back seat.

I find myself wanting to come back to publicly writing things down. For what reason, I don’t know. I don’t write code quite as much outside of work, but that’s normal. However, I have been drawing recently and dropping the occasional masterpiece on my pixel art page.

So like the title suggests, what do I say?

I think for now, I’ll say things about my art path and anything else that comes to mind. Well, I’ll try to. I think itโ€™s good to document things you do. It slows time down a little. In a good way. I enjoy looking back at the things I’ve done and it’d be a shame to lose out on that going forward.

As a start, I recently completed the 250 box challenge on Drawabox. What an absolute project that was! I started on the next lesson from there and I can already tell that 250 boxes is in fact just skimming the surface. The texture exercise in particular has reminded me that getting what you see onto paper is incredibly difficult.

Anyway that’s about it. Hereโ€™s to hoping I can say some more stuff later!

Yes to all

radio room

They say one of the best things you can do is say yes to all kinds of plans. I’ve been doing that for the past month recently and my results say… yes you should. For the most part. But definitely not all the time.

To give some context, I spent the past week and change visiting family and doing the things that comes with visiting family. In that time frame, I had two interviews, a Python code jam to work on (with a video I made for the team’s presentation), and my personal projects.

It was absolutely one of the most productive and fun weeks I’ve had in a good while. That being said, it came at the cost of saying no to a few things in the process because I was just so incredibly busy, whether with code or with enjoying family time. That’s when began to I understand the limits of saying yes to everything, and these limits are not necessarily bad.

The way I see it, you’re going to be saying no to plans regardless of the approach you take. If you’re someone who typically says no to new things, you are denying yourself life experience. If you say yes to everything till you’re full, then saying no to things feels bad, but it’s because you’ve been saying yes to everything else. And that’s good.

That all being said, it’s easy to take the approach of saying yes to everything and then realizing it isn’t physically possible to follow up on all the things because of poor planning. Yeah, try not to be That Guy. I was pretty good at not being That Guy but sometimes certain things slipped through, whether through poor planning or other reasons. That’s part of the learning process though. How much can you handle at once? It’s hard to say ’till you try.

One thing that’s hugely important too, is to occasionally take a break from saying yes to everything. Reflect on it. What yeses did you enjoy? Which ones weren’t worth it? That’s where I am now, and that’s also why I have the time now to write this post.

So in return for a late (by my standards) post, you get some wisdom in addition to the reason for the lateness! We call that a win I think.

That’s about it anyhow. Thanks for reading!

Intermission

Alrighty, so a bit late this post was by my standards, but life throws things at you. You know how that goes. That said, I wanted to at least talk about some of the things I have been working on!

The Python Discord Code Jam

Recently, the Python Discord released a qualifier for their latest code jam! I have never taken part in a code jam, so I felt it was the perfect time to amend that. I successfully submitted my qualifier and while I regret to inform that it was not hyper-optimized, it definitely did the job.

I’m excited to see what sorts of ideas my team and I can come up with for the code jam. It’d be neat to place really well in the contest, but since it is my first one I’m really looking for the learning experience.

A super secret Rust project

Yep, that is indeed a thing I am working on. It may or may not involve Bevy and an additional developer. Stay tuned ๐Ÿ‘€

The media posting app

I still intend to try and Dockerize the Django application I have been working on within the past month and change. I only have some experience using Docker, so it’s gonna take a bit longer there. Once I have it in place though, I may have an easier time incorporating it into a Gitlab CI pipeline that I mentioned in my last post.

And that’s about it

Taking up multiple projects has certainly been an interesting experience for me, as I am still also trying to improve myself in other ways that aren’t just coding. There are even more coding-related plans that I have, but I’ll keep those under wraps because it’s harder to start them if I start talking about them.

Short post but we take those. Stay cool friends ๐Ÿ˜Ž

The Hard Part

We all get there at some point; it is an inevitability that precedes your next victory in some cases, or perhaps it precedes The Hard Part II in others. Regardless of the the context, it’s coming for you. For me, it’s here!

The Hard Part involves brick walls. It involves trepidation. It involves self-doubt. I’ve spent a lot of time improving myself now and I’m already aware of the signs. I’ve come to learn a few things and have started to employ methods of working through The Hard Part.

Old me would have said forget this. I’m tired of this. Thankfully, new me is tired of being tired of stuff. Instead, I’m going to type out what’s making things The Hard Part and what I’m doing to work through it.

So what’s makes now the hard part?

Okay, so I’m still dealing with the real-life issues that sparked my post from a few weeks ago. After rereading the post again, I’m glad I wrote it and I feel better after rereading it. That said, I think my personal issues currently reside within the Annoying Chore category, rather than the Hard Part. That’s not to say personal issues are an afterthought. I just think my progress in that regard is not something to be worried about. I know I’ll get there.

That effectively just leaves the things I’ve been working on. The main thing I’m working on is my Python Django web application. For the interested, I posted about it here and here.

Since the last post, I recently made some unit tests. I also set up some Raspberry Pis on my local network to do some things. One of the Pis hosts an instance of Gitlab and the other Pi is hosting a runner that works with the Gitlab instance.

The problem I am currently running into is the dumb little box in the bottom left area called “Gitlab Runner.” I’m trying to run the gitlab-runner service in the background of the OS instead of running it manually in a shell in the foreground. It has proven annoyingly difficult. I tried to use crontab, nohup, and shell scripts to get it to run in the background. All of the approaches did not work and this consumed a lot of trial and error to no success.

Now I’ve spent all this time digging into the technicalities of building a working pipeline, and there’s still tests to be written. There’s still product features that that I set out to do. There’s still a million things to learn just to get this clunker-of-a-learning-experience software in a state that I think is acceptable.

One realization I’m coming to is there’s a reason why software companies hire multiple people. Yes, it’s obvious on the surface. Seeing it in front of you is life experience. It turns out that..

  • Making the project
  • Making the tests for the project
  • Setting up an infrastructure where pipelines can be run against the project
  • Setting up the code environment such that the project can be worked on and tested locally while still being compatible with a pipeline
  • The deployment process and integration into the pipeline
  • Using Docker in general in the process
  • Doing other stuff I definitely forgot about

… all at the same time, is in fact a herculean effort.

I’ve always been someone who’s been indecisive. It annoys people. Ask anyone I know. I have to write posts like this to understand what’s going on. I sometimes wonder how “10x” developers do what they do without going mad. As a result of the challenges I’m facing, my mind is going a mile a minute without any sort of productivity as a result.

In these dilemmas, what do you do? I’ll tell you what.

How to deal with The Hard Part

Deep Breath

“Okay.”

Take a step back. What’s the goal I’m trying to achieve in doing this project? Nobody has expectations of me right now. This is huge. Sometimes, it’s easy to get lost in the details and then throw my hands up in frustration when something doesn’t work. That’s fine. Here, look at this:

“What is that?” you may ask. I can tell you what it’s not. It’s not the big picture. Stare at it too long and you start to conjure things in your head of its meaning and its purpose. “Why is it like that? This doesn’t tell me enough. The colors are cool I guess but they don’t mean anything.” Thoughts about it are inconsistent and erratic at best, based on conjecture and frustration.

This is where you have to step back and look at the big picture.

Big picture time.

What am I trying to do with this project?

What I want to do with my Python Django project is understand the process of going from idea to production. Anything more than that is fluff. Yes, I have some features/tests planned out for the project and that’s great, but I will say that the majority of the remaining features/tests fall more into Annoying Chore territory rather than The Hard Part territory. If I let myself, I could keep adding features/tests to the project ad nauseam and never be done, while The Hard Part is lurking, waiting for me to revisit it.

Instead of dreading the Annoying Chores and The Hard Parts at the same time, I’m going to focus on The Hard Parts only. Yes this means some features won’t get done and test cases will not be finished. However, completing those things 100% will not be conducive to a learning experience. Diminishing returns.

Disclaimer: this approach does not work outside the context of learning. The real world unfortunately has its own plans in times like these that are best covered in another post.

I want to learn how to Dockerize my project, run tests against it using a pipeline (even if they are bare bones tests), and deploy it to some local server. Those are the things that matter. I don’t need to think about anything else in the meantime. I have a project and the means to test it. Now it’s time to deal with the operations that work on those means.

Yes, this will involve banging my head on the wall with the previous issue I mentioned. Yes, there will be other challenges to face alongside it. But now that I’ve looked at the big picture again, it can at least be underscored with a sense of purpose.

And anyone who has gained a sense of purpose, however fleeting, will know how powerful that is.

That’s all I’ve got for today. Stay safe friends.

Updates, and when the real world leaks into the technical world

Over the weekend, I got to attend Triangle Code and Coffee! It was pretty exciting and I’m glad that I went. You always hear about how great it is to attend events that have a variety of people with a diversity of backgrounds and ideas. And it’s like, yeah, of course it would be pretty fantastic. However, actually being there for it certainly strengthens that perspective. It’s kind of annoying how often cliches are actually true.

If I were to give advice for anyone attending a networking event, go early. You’ll meet other fellow go-early-ers and by the time the event starts you’ll have people you can reliably approach. It makes meshing with groups a lot easier, especially if your go-early-er group is a decent size. That’s all I have for advice though; I’m still a programmer and you know how cliches go.

“That’s great and all,” you say while pointing at your watch, “but where’s that Python Django progress you were talking about last week? Don’t leave us hanging.” And to that I would say, oh yeah, you’re right just a sec.

shuffles metaphorical papers

The Django stuff

So this week I managed to make some considerable progress on my Python Django application. Admittedly, the size of the things I want to do increased in size faster than I could make the things. I understand if that comes as a surprise.

Last time I mentioned that I had 7 things I accomplished and 5 things I wanted to do. Now, I have…

  • 11 things I accomplished
  • 5 things I want to do as part of completing this project
  • An extra thing I decided to do in the middle of a programming frenzy
  • 5 things I’d like to do but I won’t strictly consider acceptance criteria for the purposes of finishing this within the current decade

To keep it simple, I will talk about the new and most interesting things I accomplished.

Following users and only seeing their posts

Given that the concept of following people is a many-to-many relationship, there was some database-related logic that needed to happen. Simply put, it was this:

Anybody with any amount of database experience will recognize this pattern, which is called a join table. These “following” entries can be created and deleted on the fly without affecting the users.

For those who are interested in the Python/Django representation of this, it is the following:

class User(AbstractUser):
    date_joined = models.DateField(auto_now_add=True)

class UserFollowing(models.Model):
    follower = models.ForeignKey(settings.AUTH_USER_MODEL, 
                                    related_name='following', 
                                    on_delete=models.CASCADE)
    following = models.ForeignKey(settings.AUTH_USER_MODEL, 
                                    related_name='followers',
                                    on_delete=models.CASCADE)

For those who may have noticed, User extends from Django’s AbstractUser class which has all the attributes you’d expect from a user. The attributes that you do not see (but definitely exist) are username, password, and email. For my particular use case, I added a date_joined attribute that allows you to see when the User was created.

The ForeignKey parts in UserFollowing essentially say that we are going to be pointing to a user for each of them. There are 2 entries for it, one for a follower and one for is being followed. Due to how Django allows you to access database info, any User object is capable of accessing their followers and who they follow by using the names described with the related_name parameters. A good example of this is from a function to generate posts based on a user’s following. This also includes the user’s own posts because it’s nice to be able to see your own posts too:

def aggregrate_tailored_posts(request):
    follow_relationships = request.user.following.all()
    posts = request.user.post_set.all()
    for relationship in follow_relationships:
        posts = posts.union(relationship.following.post_set.all())
    return posts.order_by('-date')

The posts returned from this function will then be passed to the HTML template represented by the feed. Then, the user will see their own stuff they posted, as well as the posts from people they’re following.

Improving site look with bootstrap

I put this off for a while because I knew that my creative eye can vary from “vaguely resembling insightful” to “trash can incarnate.” For a better idea, take a look at my pixel art section!

Self-deprecation aside, I was able to format the site in such a way that it looked like something a human could use. This not only applied to desktop, but also mobile.

In order to do this, I leveraged the different formatting classes that bootstrap has which allow for adjustments based on different screen sizes. As advice for those that are curious about Bootstrap, read into how containers, rows, columns, and how the 12-column system works. This will provide a solid foundation for picking up the rest of the things bootstrap has to offer.

Seeing a user’s previous posts in their profile (the extra thing I decided to do)

This next feature is very similar to the feed. The main difference is that the posts listed are all posts made by the user. There is currently a restriction where you can’t comment on posts when you’re looking at them from the user page. I may implement the ability to comment while on a user page but it’s not entirely high on my list of things to do.

Much like the feed, this is a mobile-compatible interface. If it sees that the user is on a mobile device, it will actually move the user’s card to the top of the page instead of having it on the left side like the image above.

Testing

Since my focus has been more on picking up the framework, I haven’t written as many tests as I wanted to. That said, I have a working test in Selenium which will login as a user and check that the main page is available.

I am currently running into an issue where I want to have a consistent starting database that would reset back to its original configuration after selenium tests are done. A little bit of work will need to be done there in order to not have to manually reset stuff before running the Selenium tests.

I currently have a Gitlab server set up on my local network, so I will be working towards trying to dockerize this project and set up ways to run the selenium tests in a pipeline. That will be the best time to address the aforementioned problem, as I can have everything running in neat little containers with their own scripts and things. I also need to look into the Gunicorn utility for hosting the site that will be tested against.

And that’s about it

I didn’t cover literally everything that I made in the past week since that’d be a pretty nasty-sized post, but I did want to get the important parts out at the very least. It’s been a pretty neat project so far so I’m hoping I can try and get at least the core parts completed.

‘Till next week!

Basically a devlog

I said I would do a post once a week and doggonit I’m doing it! I realized yesterday that almost seven days passed since the last post and my first reaction was “wow, how do actual professional writers do it?” Time itself decided it was time to be next week and here I am, at the mercy of it.

Jokes aside, it has been an absolute learning experience with Python and Django. Much like when I was learning Bevy, there was an initial phase of “this is confusing and has so many moving parts; how does any human function while working on this?” and then over time I started to think “Okay I want to do these things, so I just need to change this, and this, and this, oh and I gotta remember that. Why doesn’t this work? Oh yeah duh because of this.”

That’s essentially the sound of growth. Anyway, here are the things I recently accomplished so far with creating a sample media posting app in Python and Django:

  • Basic login/logout system
  • Making posts with images
  • Making comments on posts
  • Deleting your own posts
  • Seeing all listed users
  • Seeing user profiles
  • Editing own user profile

Here are the features I plan to add as well:

  • Following users and see only their posts
  • Making reactions on posts (ideally with ajax)
  • Full email authentication
  • Making things look nicer using bootstrap’s layout system
  • Automated testing

There are some additional nice-to-haves like lazy loading and real-time post updates, but we shall see on those. I ideally want to have those things but it won’t be the end of the world if I decide to move on to a newer project by the time I finish adding the things I definitely want to have.

One thing I want to do as well is construct a local Gitlab CI pipeline for the project. This effectively falls under the very broad category of “Automated Testing” that I listed above. The pipeline would ideally run my automated tests, then deploy to some local web server that I have. I’d be using my assortment of raspberry pis for this endeavor. I also want to use the Django unit testing framework as well as Selenium for product level testing. Therefore, “Automated Testing” will most likely take the most time out of the remaining tasks.

Anyway that’s about it. I hope to have at least have the remaining core features done by next week so that I can talk more about them. Thanks for reading and don’t do anything I wouldn’t do!

Tired, but free

Alrighty, so it’s been quite some time since my last post. For what it’s worth, it’s not entirely because I was lazy. There’s slightly more to it. Some good, some bad.

It’s frighteningly easy to go on autopilot sometimes and to think that life is one big routine that never changes. To some degree, it’s definitely true. But, once in a while, you’ll smack right into a brick wall to shift the balance. We tend to forget how tenuous the conditions of maintaining our equilibrium are, then when things are shaken up, we can get shaken up too. We begin to question reality and quickly recall that the universe is actually uncaring.

It’s easy to see that as a bad thing. And a lot of times it is.

In my case, let’s just say I have a lot more freedom now at the cost of stability. Thankfully, knowing the universe, I prepared for a time like this. I’ve been focusing a great amount of energy to figuring myself out and understanding the potential that I have. Guess what? It turns out I learned stuff about myself and the rich possibilities life has to offer.

Programming is still pretty neat

Firstly, I still like software and writing stuff for it. I like the process that goes into the problem solving for it. I like having a sick playlist in the background as I’m slamming out some code to bring an idea of mine to life. Yes, it’s hard some days. But everything worth being paid for is hard some days.

Being lost is fine and in fact encouraged

That’s basically it. I think being lost is the next step to being slightly less lost. From there it’s slowly chipping away at the ground you want to explore next, while mapping the ground you’ve covered.

Results-oriented retrospection is a slippery slope

With any decision you make, there’s almost definitely a better one. Probably. But nobody’s psychic and can come up with that optimal path. What matters is PICKING ONE. Seriously. You’d need all of the world’s information as well as the ability to process it in order to make the most optimal decision. Yes, maybe you’ll regret the decision, but it’s better than doing nothing.

In my case, I started learning the Django library in Python. At the time of writing, it is an absolute work in progress. I didn’t think too much about it when deciding to learn it. I just saw Django a decent amount in job descriptions and I kinda like Python. Plus, I’ve messed around with Flask in the past. Is the choice to learn Django the most optimal? No. Is it a waste of time? Absolutely not. In any case of doing software engineering, there’s something to learn from. What matters is I just pick something and roll with it because otherwise I’ll just sit and overthink things instead.

Maybe I won’t like Django. Maybe I will. Who knows? If I don’t, I definitely learned stuff. If I do, then I win. I’ve done enough overthinking.

It’s not about not failing, but rather increasing chances of success

I previously took the approach of getting by. It’s not sustainable. Yes, you can do it while technically growing, but there’s a lot of potential learning left on the table when you don’t try things that you know you’ll fail at the first time.

Some things, you basically just have to constantly fail over and over. As your failure counter rises up, throw the stupid failure counter in the garbage because who cares? If you learned from previous failures and applied them to future attempts, then you can sleep just fine.

Sometimes, you can do everything perfectly and still not succeed. Refer back to when I mentioned the universe and its relationship with people. All you can do is say, well, I am trying to just increase my chances of success with each new iteration. Sometimes the odds are stacked against you or literally at 0 and you’d just never know.

/ramble

That’s about it honestly. I will be making attempts to post on here weekly to have as part of my routine. I have had a lot of opportunity in the past month to grow as a person and reflect on what I like and what I do. Maybe this can help someone else do the same.

Stay safe; make good choices!

My handy Rust CLI

A week or two ago I started on creating a rust program that would accomplish two things:

  1. Improve my understanding of the package management system for Rust. More specifically, I wanted to understand how to organize modules a little bit better
  2. Create something that I could use to create challenges for myself using an automated and randomized method

I worked on it for a while and then get hung up on the specifics for parsing command line arguments. The approaches I thought about either seemed way too complicated, or were way too hacky to really be proud of writing them. I let the project for a sit for a little bit.

After some time, I realized that I could probably just outsource the parsing logic. Given that I was, at the time, the furthest from the first person ever needing to parse command line arguments, there had to be a library for it.

I was indeed correct and found clap. This library turned my project from a headache into a neat little organized oasis. More on that later. First, I’m gonna describe how the program works.

How the program works

The utility will look at a set of text files that you give it and create a set of challenges. For example, you could have some text files that describe pixel art challenges you can try.

theme.txt

Draw a house
Draw a mountain
Draw a bear

size.txt

at 128x64 pixels
at 256x128 pixels
at 64x64 pixels

palette.txt

with Midnight Ablaze Palette
with Oil 6 Palette
with Apollo Palette
with Spanish sunset palette

With these files in the root directory, you can run something like this:

cargo run -- -f theme.txt size.txt palette.txt -c 5

This will…

  1. Look through the listed files indicated by -f
  2. Print out the challenges’ details in the order they were listed, randomly picking an entry in each file. This will be done five times, as indicated by the -c 5 argument. --count can also be used instead.

One example output could be the following:

Draw a house at 64x64 pixels with Midnight Ablaze Palette 
Draw a mountain at 256x128 pixels with Oil 6 Palette
Draw a house at 128x64 pixels with Apollo Palette
Draw a bear at 128x64 pixels with Midnight Ablaze Palette
Draw a mountain at 256x128 pixels with Midnight Ablaze Palette

Now I have 5 challenges for pixel art I can work with! This is great for generating ideas, especially if you fill a text file with a million different ideas, then also fill another text file with a million other ideas to combine with it.

This could also be good for quizzing yourself, learning a new language, inspiration, you name it.

Anyway, so on the topic of my code being a neat organized oasis, Here is the parser and how it is used by my main program:

Parser & friends

cli.rs

use clap::Parser;

#[derive(Parser, Debug)]
#[command(author, version, about, long_about = None)]
pub struct Args {
    #[arg(short, long, num_args = 1.., required = true)]
    pub files: Vec<String>,

    #[arg(short, long, default_value_t = String::from(" "))]
    pub separator: String,

    #[arg(short, long, default_value_t = 1)]
    pub count: i32
}

main.rs

use chalgen::{file_processor, cli};
use clap::Parser;

fn main() {
    let args = cli::Args::parse();
    file_processor::output_challenges(args);
}

The code above does the following:

  1. Define the command line arguments for the library to look for and what characteristics they should have (cli.rs)
  2. Pass configuration that was gathered from command line arguments to the program doing the actual work (main.rs)

To provide some context for cli.rs, the following keywords are important:

  1. short: the flag can be represented by the first letter of the property name. e.g. files can be referred to as -f when calling the command line utility
  2. long: Effectively the same sort of option as short, except the flag is able to be represented by its full name. e.g. count can be represented as --count when calling the command line utility
  3. default_value_t: Essentially, this is what the flag will be set to if it is not mentioned when calling the command line utility
  4. num_args: How many arguments that are expected from the flag. In this case, I use it once with files and the number of arguments is represented by 1.. which essentially means “at least 1.” I specify it like this to provide the user the ability to provide any number of files they want
  5. required: The flag must be used. In this case, the files flag is required

All of the restrictions and allowances defined above are automatically enforced by the clap library. This is a huge weight off my back and allowed me to focus on the actual program (AKA the file_processor::output_challenges(args) part of the code that I don’t show.

Anyway, that’s about it. Here is the repository for the curious! Stay safe and make good choices.

Pixel art, its community, and my findings

I never was a huge creative. I made my attempts but it was easy to go back to old habits. Within the past few months I’ve been doing pixel art and it was kind of an accident. I started out with trying to make a game with Rust and Bevy (see Games and Experiments, namely the Avoider Game) and then realized that in addition to programming, pixel art is actually pretty neat.

After just trying to get some basics down for the sake of making something that looked functionable, I started to jump down the rabbit holes and eventually I could only think…

huh.

Now I’ve got a gallery and I can’t stop! This revelation made me realize that I had deprived myself of a creative outlet for quite some time. While I have tried creative endeavors in the past and didn’t care for them as much, I didn’t give myself the opportunity to continue looking. Thankfully, I’ve found a method of expression that wasn’t just typing at people or sending sick Rocket League clips.

Another surprise I’ve run into is that the community is pretty supportive. I’ve done some posting on twitter myself and it’s nice to see people sharing and liking each other’s work. Plus, hang around there long enough and you start to see the same people after a while; it feels like a wholesome little neighborhood of sorts.

I’ve also joined a pixel art discord that has a variety of channels, including one where you can post your work for feedback. In my time spent there, people have been surprisingly helpful as well.

Initially, my subconscious perception of the art community as an outsider seemed like it was a difficult-to-penetrate sphere where only the highly skilled dwell. That could not be further from the truth. People in the community understand the amount of work that goes into something that actually looks good and all the difficulties that you inevitably find along the way. Plus, looking at the work of others helps to inspire yourself. A little bit of support goes a long way when you want your favorite artists will keep making more stuff.

Overall, it’s just nice to be heard. If I make something, really enjoy how it came out, and others feel the same, it’s really validating. Sometimes I’ll make things that I’m not exactly excited about and some people people may still enjoy it nonetheless. Much like in the “real world,” people can still like what you do in spite of, or because of, your blemishes. I’m learning how much better it is to put your ego to the side and just create, instead of being afraid and doing nothing. As long as the process and the rewards after are worth it, That’s what matters. If you share your experiences or creations, there will be like-minded people out there that would like to see what you’re doing, or at the very least, help make it better.

‘Till next time. Make good choices.

Low times

It’s been a bit of a tough period since my last post. I had been dealing with some work stuff and thankfully that’s over, but it’s been really difficult to create on my free time.

I started on a small Rust program recently to learn a bit more about how Cargo works. In addition, the tool was supposed to help me with some of my other hobbies. After some days of spending time on it, I noticed that it was increasingly harder to press my fingers on the keyboard and make the code do stuff. I did learn more about Cargo, but I just couldn’t be bothered. I think it’s temporary, but we’ll see. I’m thinking of greatly down-scaling the project to make things easier. I may have also recently ran out of coffee but surely that can’t be related.

Pixel art has been more of a consistent interest for me at least. Even though I am still having a hard time producing stuff there too, it’s at least because it’s novel and I don’t have it figured out yet, and not because I’m just like ugh. It’s hard to explain, but it may be because I regularly code at my normal day job. It’s much more difficult to work on code stuff on my free time when I’m also spending 5 days a week programming at my job.

I don’t really have much of a point to the post. I think sometimes it’s good to reflect on accomplishments when you’re down. I’ve done a lot of stuff the past couple months! That’s neat. We take those. It’s easy to beat yourself up when you want to push yourself at low times, but honestly it’s not worth it. People who do that to themselves end up pushing themselves away from their interests.

I think what helps too is that I don’t plan to make money with what I do or make on my free time. There doesn’t need to be good enough writing, good enough art, good enough whatever. I finish and submit whatever I think is presentable. The void I’m filling with all this stuff I am doing is a creative one. I’ve kinda deprived myself of a creative outlet for long enough, so the fact that I have many of them now is worth its own celebration.

For anyone reading, thanks and stay cool ๐Ÿ˜Ž