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!
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.
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.
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.
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 the anxious and the ravenously impatient, here is a link to the game. For more info, it can also be found in the Games and Experiments part of the website.
Whew! What an absolute experience it was getting this one out the door. I would say great strides were made in early March, with diminishing returns coming in towards the end of march and into April. I had hoped to have this done before my trip in mid-April, but sadly that was not the case. Thankfully I was able to still knock things out after and all is well!
My main goal here was to learn about Rust/Bevy while making something that seemed fun, no matter how basic and unoriginal it may be. I’ve found that waiting on the perfect idea is for people who never act on it, so I just went with my gut when starting production.
For me to consider this small project complete, the game needed to be fully functional with the ability to pause, resume, die, retry, and even win the game. Some of those features were vastly easier than others, but we got there.
Things I learned
While I am glad I finished this, it was definitely starting to get the rot of ignorant technical choices towards the end of development. This is fine. Making mistakes is a fact of life when doing complicated stuff. A lot of this stuff will echo what I have in the readme in the github repo for this game, but will go into a bit more detail.
Listeners and state changes
In Bevy, you can have systems listen for change of state and for events. These are two distinct things.
At the beginning, I thought the change of state was not something you can listen to. So, in some cases, when there was a change in application state I would also include an event that occurred alongside it. This did work, but it was inefficient. Once I figured out that change of application state could be listened to, I did not need to use events for those particular cases.
There is another distinguishing feature that events have however. They can carry data along with them. For example, there’s two ways the game can end. It can end with the player dying, or the win condition of the game being met. Depending on what causes the game to end, that is what the “end” screen will say.
If the player loses, the end screen will say something like “you died press these buttons to restart”
If the player wins, the end screen will say, and I know this may come as a surprise, it will say “you won”
So functionally, winning and losing is the same. This hits a bit too close to home but we’ll just not think about that for now. The only difference between the two is the string that is presented at the end state. Therefore, we can carry that string alongside the endgame event and just slap whatever we want on the end screen based on what occurred beforehand.
Here are some links for more technical info on events and state-based stuff. The latter is based on Bevy 0.10 which is the latest stable version as of writing.
Asset handling
Early on I wanted to just get my assets into the game without thinking about it too much. It turns out that people include loading screens in games for a reason. A more reasonable approach is to load up the assets by the asset server at the beginning and then pull upon them when the game is running.
What I did instead was pass the asset server into effectively any system that may or may not need to utilize an asset. That’s pretty goofy since passing it around everywhere is not only just a waste of performance if the game were scaled up, but also because it just created code clutter.
The solution to this, like I mentioned earlier, is next time to load the assets at the beginning, then refer to them using a resource.
I actually just don’t know how cargo works
When I read the Rust book, I may or may not have glossed over the cargo system since I figured it would be pretty straightforward. While in many regards it is simple to use when using other people’s libraries it’s a bit more intricate when you’re working with creating your own modules.
I’ve made it a point to learn more about the logic behind setting up my own modules, as this may also help with the architecture of future projects, too.
The biggest problem with this that I had was that I had to basically copy a function a couple of times because I could not get two files to share it. My code comment here kind of explains it some more. Definitely not one of my proudest moments but that’s why I’ll be reviewing how cargo and modules work.
Other things
The github repo readme has more points on things I should consider in the future. However, I think the above things are the things that stuck out to me the most, so I shall leave it at that for now.
And that’s about it
I’m looking forward to future projects. I have reason to believe my next stop will be the rapier physics engine. But first I’ll want to learn more about cargo and modules. ‘Till next time!
dfebs
