Daniel Febles

I tried to complete a full Rails project in two days – it was a disaster and I’m glad I tried it.

dfebs Aug 14, 2025 0 Comments

Sometimes, somehow, a fire gets lit under your butt and your path is clear. All you can think about is the code you’re writing. You turn around and all of a sudden 4 hours pass in what seemed like no time. Textbook flow-state.

This weekend, I attempted to manifest this feeling to no success. These things, as you will see, are not something you can just do on command. But you can make them more likely to happen. Let me explain.

The final step of the 1212 process

To give some context, I’ve been working on something called the 1212 learning process. I wanted to learn Ruby on Rails, so I challenged myself to work on four projects, each with increasingly aggressive deadlines.

✅ Complete a project within 1 month (Bloggington, blogging web app) (~60 hours of focused work)
✅ Complete another project within 2 weeks (Phasmid, bug tracker) (~50 hours of focused work)
✅ Complete another within 1 week (Evenfall, web chat) (~33 hours of focused work)
🚧 Complete a final project within 2 days (This project, Sesh, workout tracker) (~7 hours of focused work)

I normally would leave a checkmark next to my project once the time is over, but Sesh is not complete by any stretch of the imagination. The project timer started on August 9th, and ended August 10th.

Small forewarning

This post will be considerably less technical than my other posts in the 1212 process. This is a reflection on standards I set for myself, how I fell short of them, and why that’s fine.

What happened?

A few things happened.

Coming off of Evenfall, I wanted to get my two-day project started before I lost steam. Knowing that weekends would be the best time to do it, it meant that skipping a weekend was basically skipping a whole week. I decided to do it sooner than later because if not, I could see myself putting it off. This may not have been enough rest time between projects.

In addition, I had the gall to use leisure time during my two days. I knew that I was going to have to do a decent amount of serious, focused work, so I used a good chunk of my time to relax in between sessions. This obviously led to lost time.

The real problem, and the main topic of discussion, was my subconscious desire to step away from my code a lot while I was working on it. It almost felt like my mind was trying to find every possible reason to distract itself. While this wasn’t new territory, is was particularly acute during this project. In short, I found that I was procrastinating a lot.

Pushing past procrastination

Here is my time log for the two days:

8/9 1hr in morning, start 2:15pm. pause 4:00. Start 4:50, stop 6:35 
8/10 start 10:20 pause 11:00. Resume 11:15 pause 12:00. Resume 12:15, pause 12:45, start 1:45, pause 2:45, start 3:15, stop 4:00

By the time 4pm Sunday rolled around, I was already done. I knew that I wasn’t going to have anything resembling a finished project unless I hard grinded through to midnight. But I was already mentally exhausted. Not only because coding is coding, but because I spent so much energy fighting myself.

There’s a helpful chapter in Tiny Experiments by Anne-Laure Le Cunff which talks about procrastination. It describes how procrastination can potentially stem from three parts of you: your head, your heart, and your hands.

• Head – Is this something worth doing?
• Heart – Do I feel good doing this?
• Hands – Is this within my capabilities?

Upon reflection, I realize that each of these things played a role in my subconscious desire to avoid working on this.

Is this something worth doing?

For the most part, yeah. The 1212 process had already shown its value in my first three projects and this seemed exactly like the logical next step. But it does come with a question when you look closer. Is it worth spending as much time as possible grinding out a full project on a weekend? To some, possibly. For me, I think on some level it wasn’t.

I know some people really enjoy hackathons and code jams; I do too. Though perhaps for a longer period than a weekend. Or maybe just a couple days within working hours and I’m getting paid for it.

Is this within my realm of capabilities?

Probably not. I’m still learning Rails and I don’t quite have the speed to do much of anything substantial within such a small amount of time. I think I knew this going into it, and as a result, there was probably a subconscious desire to avoid such a futile effort.

Do I feel good doing this?

While I am happy to commit a good chunk of my weekend to making stuff, confining a deadline into two days did not elicit a healthy attitude. If I wanted to get anything done, I had to really work on it! And what if I felt like I was done for the day after a couple of hours? I’ll just have to suffer through it.

Normally, for my longer-period projects I could jump into my work even if I wasn’t quite feeling it, because I knew I could consistently get an hour in if nothing else. For this, it was like yeah you’re committed once you start working.

The tough guy in the back of my mind

Even knowing that my expectations were unrealistic, there was a part of me while working on this project that was like “so you’re gonna just give up like that? In the real world, you don’t get to rest. Especially if you want to be self made.”

But you know what? You can rest. My goal is to design my life in such a way that insane deadlines are an absolute last resort. Not the norm. Yes, this requires leverage. You know how you build leverage? You upskill. A lot. You know how you upskill? Consistent, daily practice. You know how to make this easy? Enjoy the process. The moment you begin to resent your process, the more likely you are to abandon it, and the more likely it is to fall apart.

The mere act of falling short of my own unreasonable goal was enough for me to put off writing about this project. I could have just let this failure fade away. I could have let resentment go to a broil and then give up because it felt bad. Look, see, this stuff is stupid and not worth it. Nobody even reads these posts. But nah, I’m tired of doing that. It is worth it, and I am growing. Just because I can’t code something in two days doesn’t mean my efforts are for naught.

Lessons learned

Things to consider when shipping a real project

Disappoint people up front. Give a time period that’s at least twice what you think you’ll take to get it done. Yes, every situation is different, and you may have to make sacrifices from time to time. But those sacrifices need to be the exception, not the rule.

Many might know this already. And I bet good chunk of those people don’t follow it and need a reminder. Let this be your reminder.

Constantly overworking is not scalable

I like to think I learned a ton from Rails since May when I first started the 1212 process.

While I was working on Bloggington, I was on vacation to see family. I spent time out of my day whenever I had the chance to work on the project. I never pushed too hard and I never let it get in the way of quality family time.

When I worked on Evenfall, I worked on it every single day. I still had time for gaming or going out. Frankly, I don’t remember much of my in-between time for Phasmid. I think the project was interesting enough on its own to consume a lot of my time while still being interesting. And that’s perfectly fine too!

A time and a place for code-benders

Recall what I mentioned earlier about several hours passing by in a flash after an intense but satisfying coding session. By no stretch am I discouraging these things from happening. In fact, the act of working on things daily will put you in a much better position for these small miracles to happen.

However, you need know your limits. By working on the 1212 process, I think I found mine.

I created a web chat app in a week: my fastest Rails project yet

dfebs Aug 3, 2025 0 Comments

I gave myself a goal: one week, one Rails project. And that I did. This one is called Evenfall. It is a real time chat application where people can make rooms and type back and forth. Is it reinventing the wheel? Yep. Is it going to make a splash? Nope. Did I learn a lot? Yep. As you’ll see, the biggest challenges did not come from the networking part of the chat, but rather making it not annoying to use.

This project started on July 23rd 2025 and ended July 30th.

Some context

Evenfall is part of a series of projects called the 1212 learning process. For this I am learning Ruby on Rails in an attempt to get past my nasty habit of overthinking everything and instead just get stuff done. You all know that over-thinker. You might even be one of them.

Anyway, to give a high level overview, here are my projects I completed as part of the process:

✅ Complete a project within 1 month (Bloggington) (~60 hours of focused work)
✅ Complete another project within 2 weeks (Phasmid) (~50 hours of focused work)
✅ Complete another within 1 week (This project, Evenfall) (~33 hours of focused work)
🚧 Complete a final project within 2 days

For those who want to see the repository as it was after just the 7 days, refer to the legacy branch of the repository.

The end result

This is a quick 1 minute demo on creating a chat room and doing some simple back and forth chatting. I use two separate browsers on two separate accounts to simulate the interaction.

How it went

Day 0 – Strong start

I did the usual day 0 things. Got the Github repository up. Ran the convenience scripts to get things like authentication, ActionText, and the models in order. The database schema was simple this time, and I did my fair share of wrangling models during Phasmid, so it was easy to get a working database skeleton working in short order.

Day 1 – Plot twist

I got real time messaging working. This is huge news given how early it is in the project. I do want to elaborate on this a bit, as it is kind of the core gimmick of the whole project, and yet said gimmick was complete in 2 days.

How was this done so quickly?

This was done using ActionCable. This comes with Rails and makes it incredibly easy to incorporate real time updates pretty much whenever your business logic wants to. I will admit, I did use ActionCable when writing Phasmid so that contributed to my headstart.

Real-time messaging works in 3 major stages

1. A message model instance is created
2. A broadcast is triggered, sending the message’s HTML contents to a subscription
3. The room that has the subscription receives it, and displays it in real time.

Here is the entire Message model in my project (edited slightly for formatting):

message.rb

class Message < ApplicationRecord
  belongs_to :user
  belongs_to :room
  has_rich_text :content

  after_create_commit -> { 
    broadcast_append_to "room_messages_sub_#{self.room.id}",
    partial: "messages/message",
    locals: {
      room: room,
      message: self
    }, 
    target: "messages"
  }
end

The important part is after_create_commit, which essentially does the following:

• After a Message instance is created (AKA anybody sends a message), send a broadcast to all subscriptions associated with this message’s Room. For the purposes of this project, only one subscription exists which I will mention shortly.
• partial refers to an HTML “chunk” which will be appended to a target called "messages". The target refers to the id of a div that is located in the chat room.
• locals passes along the information to be used when appending the message data to the target div.

A moment ago, I mentioned a subscription that will receive the broadcast. This is where the subscription exists:

_messages.html.erb

<%= turbo_stream_from "room_messages_sub_#{room.id}" %>
<div id="messages" data-controller="messages" data-messages-target="messages">
    <%= render "layouts/flash" %>
    <p>--- This is the beginning of the chat ---</p>
    <% messages.each do |message| %>
        <%= render "messages/message", message: message, room: room %>
    <% end %>
</div>

The important part is the beginning, where we define the turbo_stream_from with the same name "room_messages_sub_#{room.id}" that is referred to in the broadcast_append_to line in message.rb. The second important part is the <div id="messages" ...> portion as this defines where the broadcast needs to append to (i.e. the target).

And for reference, this is the partial being broadcast, the HTML “chunk” as it were:

_message.html.erb

<div id=<%= combined_dom_id(room, message) %> class="room_message">
    <span><b><%= message.user.username %>:</b></span>
    <%= message.content %>
    <br>
</div>

I want to note that ActionCable is not perfect. If you are not actively looking at your tab, it’s easy to miss messages when you come back to it. While this can be fixed by refreshing, that’s obviously not very cash money of the application.

There are ways to improve this, such as setting something up to queue messages for you. Or perhaps you can use AnyCable, which is apparently a drop-in replacement of ActionCable with more stability/features. That said, I accepted the limitations of ActionCable in the meantime for the sake of moving my project along and not getting bogged down in trying to get an external library to work.

Day 2 – Making stuff look nice

This day was pretty run of the mill. A bit of HTML/CSS formatting to make things look neater.

Day 3 – Mobile, navbar, and early chat interaction logic

More stuff like day 3, as well as making the site look better on mobile. I made a navbar and edited chat rooms so that they will auto-submit when pressing enter. Chat room interactions start out simple, but the next day will show me that to get them precise is a different story.

Day 4 – Chat rooms are hard

So I did the thing where I underestimated the complexity of handling the intricacies of a chat room. Here is the layout of the chat room:

Here are the problems I had while making the chat room usable:

Scrollable elements in HTML start at the top and not at the bottom

This means that to show the latest messages, I have to auto-scroll the scrollbar to the bottom when the user enters the room. This was the easiest of the issues to solve.

When a user sends or receives a message, the scrollbar does not adjust

If the chat box has a new message, the position of the scroll bar stays the same. The message is “hidden” until the user scrolls down. This is of course really bad user experience.

Now, this could be solved by auto-scrolling to the bottom when any message is entered into chat. This creates a new problem though. If you’re looking through the chat history, you will get rudely interrupted every time someone in the chat posts a message. I could have invested time in a fancy thing that notifies you of new messages at the bottom, but the whole 1-week deadline said “no sir you’re keeping it simple.”

As a result, my simple solution was this: if your scroll bar is low enough in the container when any message comes in, then it will auto scroll down. This “low enough” value was definitely based on vibes. I settled at 200 pixels. This was eventually done on day 7.

Pressing return on the message editor does not send messages

This is an understandable problem. The Trix editor has no business auto-submitting forms when pressing return for a multitude of reasons. However, my app certainly has that kind of business. Fast paced messaging is the name of the game.

But of course, we still want people to be able to create newlines. As a result, I needed to account for shift + enter.

It all needed to work on mobile

I made it a point to try and make this site mobile compatible. So all of the problems above needed to be solved for mobile too. Most solutions transferred over, but pressing return was the only way for someone to realistically create a newline on mobile, so I had to code a workaround for that on day 7.

Time to learn Stimulus

I realized that regular Javascript inside of the HTML was not going to cut it, especially when you have stuff constantly changing around in a chat room. Using Stimulus controllers made it far easier to keep track of the state of the page, and act upon those changes.

I don’t like how my controllers came out, and as a result I will not be going into too much detail about them in this post. The good news is I think the next time I write a stimulus controller, it will be far more organized. And perhaps more worthy of writing about.

Day 5 – Centering some divs

I spent the session centering the forms so they look good on desktop and mobile. You heard that right gamers, I centered some divs.

Day 6 – UX improvements

I made the login/register forms a bit more informative if the application has any issues with form submissions. like mismatching passwords and cases where username/email are already taken.

Oh I also added the favicon.ico

Day 7 – Cleanup

A lot of this was a continuation of Day 4: Chat rooms are hard. I got around to fix the remaining issues I ran into that day. The rest of the time was spent cleaning up formatting, applying max character restrictions on forms/models, and stopping the chat box from taking any drag-and-drop files other than images.

The numbers and conclusions

The time spent on Evenfall was past my initial expectation of about 25 hours, which instead landed at about 33 hours.

Interestingly, even though I spent a considerable amount of time during the week, I didn’t burn myself out. There was plenty of time for me to do other things most evenings like gaming or going out. Having a remote job also helps.

Given my practice on the first two projects, it is reasonable to say I was able to do just a little more in less time. Plus, I’ve found it’s more enjoyable to code using Rails now that I’m getting the hang of things. Great news overall.

The two day project will be coming soon. It will need to be on a weekend where I don’t have much plans, so it may be some time. But it will happen, and it will be the toughest challenge yet. My projects sequentially halved my available time. This final one is the outlier, cutting my time by more than half. I described it as such in my initial post about the 1212 process:

“Project 4: The Crucible (2 days): Your ability to very quickly get something out the door will be forcibly squeezed out of you. The shortest path to success is the only path.”

Time for The Crucible. Stay tuned.

I created a Rails web app in two weeks: what I learned and what I will bring into my upcoming one week project

dfebs Jul 18, 2025 0 Comments

In my last post, I created a web application in one month as part of a series of Ruby on Rails projects designed to increase my speed of output for software prototypes. I halved the available time to two weeks with this most recent project, Phasmid. As of Monday, July 14th, Phasmid is complete and now I can say I’m officially halfway done with my goal of making four Rails projects.

Progress on the 1212 train

✅ Complete a project within 1 month (Bloggington) (~60 hours of focused work)
✅ Complete another project within 2 weeks (Phasmid) (~50 hours of focused work)
🚧Complete another within 1 week (Start day TBD)
🚧Complete a final project within 2 days (Start day TBD)

The grand goal at the end of this four-project process is to be more comfortable publicly shipping Rails web apps without the worry of burning myself out from lack of technical skill.

So what is Phasmid?

Phasmid is a simple bug tracking application. To be clear, it is a blatant reinvention of the wheel and is not meant to help anyone but myself. The features are as follows:

• Users can create projects which have sets of bugs
• Each project has a pool of tags that can be attached to bugs
• Tags have a weight value, and bugs can have any number of tags
• The multiplied weight of all tags attached to a bug determines the bug’s score
• A higher bug score indicates a more concerning bug with (ideally) a higher priority

Having completed the one-month project, I went into Phasmid with valuable knowledge. I found that I was writing out code snippets before having to reference online sources for clarification on syntax and function parameters. Sure, it still took me some time to figure things out. However, the burden of learning the fundamentals was considerably lighter this time around; this gave me more bandwidth to learn new things.

As a side note, I shared this project with my public discord server. It was great to have others test it in a call and get real feedback!

Here is a simple demo video where I click around a bit. Note, there is no sound.

How it all went

Making the database

Starting out, I had issues wiring together relationships using join tables. I suspect that database wrangling will be easier next time, especially since I can use Phasmid as reference when I work on my next project. Part of my issue was generating scaffolds for models without considering that some models would be nested under each other. This led to a bunch of backtracking before I got things right where they needed to be.

The teeny smidge of testing

All good software should be released out the gate with testing. While I had a feeling I would not have time for a full test suite, I did want to get system tests running. After some messing around with my WSL instance, I was able to get it working. I made a simple system test where a project is created and then it asserts that the project was indeed created. It’s not much, but at least now I have a starting point when I test more in the future.

Freedom to format

I spent a decent amount of time writing the HTML and CSS of the web app. It was surprisingly fun and I felt far more in control of how things fell into place than how I did with Bloggington. I got my hands dirty with designing the web page using a simple grid system and a custom color palette.

When I was in the weeds of the last stretch, being able to work on something a tad more straightforward like HTML/CSS had huge returns on morale. It felt great to have a web app that had its own style and did not look like a complete disaster.

The wonderfully dense hour

On July 4th I saw the greatest evidence of my improvement. In the course of an hour, I implemented two features which took me multiple days to figure out the first time around with Bloggington. This was a huge win, and represented a speed boost by an order of magnitude. For the curious, it was these two commits (1, 2). They both involve real time updates on form submissions using Turbo and Action Cable.

The last stretch

It’s crazy how wide the gap gets between the size of a to-do list and your true velocity. This became readily apparent towards the end. There were also times where I was not sure what the priority should be.

I tried to deal with the difficulty through this lens: if there were an audience of just me, what would that audience want that would help the most with bug tracking? Even as myself, it was hard to know what I wanted. It turned out I had no idea what I wanted other than “thing that tracks bugs.” This does give me a little bit of a peek into what building for a customer would be like.

My takeaway was this: get a solid core out there and don’t worry about the rest. Remember, people don’t know and don’t care about what features were cut in your first iteration.

Cut features

Memberships

My original goal was to have users be members of projects with specific sets of permissions. The database had the pieces in place for it, but I never got around to it.

Instead, people can see all projects/bugs but can only edit things they own. If this was being monetized, people may not even want that if it became a platform that was more focused on transparency. In that case, not having done it may have been better. You can always adjust later if the opposite is true.

Fancy flash messages using Stimulus

When things were created, deleted, or something failed, I wanted a fancy bubble to show up describing said things. Sadly, that also did not make it. It was more of a nice-to-have, and I settled for the default Rails way of logging flash messages on the screen, a good ol’ paragraph tag.

Improved UI

The UI is vastly improved compared to Bloggington. For example:

Bloggington

Phasmid

Room for improvement

Next time, I want to build with a mobile-first approach. Phasmid is a bit awkward on mobile, though it is still reasonably usable. I also want to make sure that the web app works just as well without any of the fancy Hotwire SPA-like features.

Findings

So what did I learn? In 2 weeks, I can construct a project that at least resembles something useful. I picked up these topics while making Phasmid:

• Action Cable and redis
• Getting system tests to run with WSL
• Grid layout basics
• Adding a new font
• Simple time zones
• CSS

That’s 6 things I didn’t know much about in my first project.

Expectations for the one-week project

While I improved my input by roughly 10 hours during the 2-week project, my available time is going to be cut in half. To give some perspective:

Even if my efficiency improves where it takes 10 fewer hours to get the same output as I did with Phasmid, I would still need 40 hours in theory. And I’m not going to have those hours. 25 hours is 3.5 hours every day of the week if I want to at least maintain same the ratio from Phasmid.

Whatever my next project is, it will need to be incredibly laser focused if I want to make something of value. I have some ideas.

Project 3 is where real challenge begins.

I’m giving myself increasingly aggressive deadlines to learn Rails fast. Here’s what I built in the first month.

dfebs Jun 21, 2025 0 Comments

I did the first step of a challenge I set out to face in a previous post! As a quick summary, I planned to do the following to learn Ruby on Rails:

• Complete a project within 1 month (The thing I did)
• Complete another project within 2 weeks (To begin June 30th 2025)
• Complete another within 1 week (Start day TBD)
• Complete a final project within 2 days (Start day TBD)

For this first month, I kept it simple and made a “blogging” social app called Bloggington. The goal was not usefulness or complexity, but rather just implementing something straightforward to flush out the garbage that comes with learning something new. And oh my, was garbage flushed.

This project began on May 14th 2025. I stopped all work on the project on June 15th, 2025. You might find that this was technically a month-and-a-day project. That would in fact be correct. The reason for that is because I can’t count.

I published this server on the internet and shared it with people I know in my public Discord. It was surprisingly fun. For now, I am keeping my web server locked out from the public because image posting is a sensitive thing that I don’t intend to deal with currently. Anyone who previously made an account on it still has access.

The web application is open source though, so anyone is free to pull it and run it on their own!

For all the perfectionists out there

Like many, I’m historically bad when it comes to sticking to projects. Getting this first project out has been super gratifying, especially when I was finally able to deploy it and simply see it out there on the internet!

Separating something I made from how I perceive my value as a person is a skill I am currently learning. This project made it a lot easier, especially when looking at it from an experimental point of view, and with an actual deadline.

Yes, it looks terrible and that’s totally fine. The fact that I shipped an actual web app to the internet and had the courage to share it is what’s great! Now I can iterate on whatever information I gather.

My experience and the time I spent learning

I am a software engineer who specializes in QA automation using NodeJS. I’ve been doing that for roughly 7 years. I have basic knowledge of Python (having created only a couple things with Django and Flask). Both Ruby and Rails are brand new to me, but I do have some previous knowledge of model-view-controller frameworks.

I know the basics of html/css. I used Bootstrap for the frontend, but I can definitely see an argument that it probably wasn’t necessary. I do plan to improve my ability to use raw html/css at some point but that may be a little while.

For the purposes of this project, I spent a week on the Getting Started with Rails guide and then spent the aforementioned single month working on Bloggington. That is all of my exposure to Ruby and Rails.

How it went

Much of the first 2 and a half weeks was getting acquainted with the core navigation of a Rails application (The initial stretch). This includes learning to leverage the usual suspects in a model-view-controller framework. The next 1.5 weeks (The big hump) had a huge spike in difficulty which slowed me down a lot due to learning the Turbo framework, and then there was a decent uptick in productivity a few days before the end (The weirdly productive scramble).

The above is my commit graph. You’ll notice that the week of June 9th has a huge number of commits. This is due to 2 things:

• There was a ton of experimentation during the big hump that I eventually got working; as a result, I committed a ton of stuff within a short time period.
• Some of that week also includes the weirdly productive scramble at the end of the project.

Overall though, I was able to consistently work on the project almost daily.

The initial stretch (2.5 weeks)

This was definitely just picking up the fundamentals and understanding how they work. I didn’t generate any scaffolds using the command line, but I did generate some models. This meant that I had a very thin skeleton to work with and I had to manually wire together a lot of the simple CRUD operations around blog posts and users.

I have reason to believe that in my next project, this will be drastically shortened. This is made apparent by how much easier it was to make changes to the project during the weirdly productive scramble.

The big hump (1.5 weeks)

It all started when I wanted to add comments to posts. I even had the gall to desire comment threads. This little maneuver cost me a week, and I didn’t get to implement comment threads. Just top-level comments. I did gain some sweet knowledge though.

When I made the sweet-summer-child attempt at throwing a bunch of forms onto a comments page using a for-loop, I quickly realized that the page had no idea what to do with the forms. And turns out, neither did I. After fighting with form submissions for a good while and some looking around, I was reminded of Turbo’s existence.

You see, Turbo is briefly mentioned in the Rails Guide, but it’s definitely not a core component in the learning material itself. When I saw it alongside Stimulus I made the assumption that they were libraries just kinda used by Ruby behind the scenes with no need of your interference. That is in fact incorrect.

While Turbo is used behind the scenes in a lot of cases, a lot of it is definitely used by you, the developer.

After spending multiple days trying to understand Turbo Frames and Turbo Streams, it slowly began to make sense. Many times, I would have an assumption of how it worked, and then find out I was dead wrong and I was set back quite a few places. Even when I began to truly understand them, I found that I was still struggling to grasp why they are useful.

Basically, they make it so that it’s easy to turn a standard multi-page web app into one that updates on the fly like a single-page app. This can be done in a hybrid fashion, where some stuff is dynamic and other things will take you to a dedicated page. Or, you can theoretically use it to create a full on single page web application.

By the end of this phase, I was able to get Turbo frames and Streams working, where you can add/edit posts and comments without needing to go to a separate page. I did not have time for implementing nested comments though, as time was running short and I did not want to open another potential can of words as time was running out.

The weirdly productive scramble (0.5 weeks)

So once I knew enough about Turbo related things to survive and understand why it exists, the last few days were a lot easier. Part of it had to do with the relative ease that CRUD operations and model restraints are compared to Turbo stuff.

Most of this period, I picked up some things here and there without too much difficulty. I implemented profile pictures, learned about model helpers, used functions for validating models, and accounted for empty comments/blog posts. I also made some attempt at making the web application look visually parsable, though to a very limited degree.

The web app

This only shows some of the features of the web app. You can also register/login, edit posts, add/edit your profile picture, and look at people’s profiles where all of their blog posts are located. Ideally, less time will be spent on figuring things out in my next project, and perhaps more time can be spent polishing it.

Additional things

• Any edits I make to the repository in the future will be on branches outside of main, to maintain the historical integrity of this fine (and crumbling) monument.
• The repository had 56 commits total.
• Roughly 60 hours were spent on the project.
• There are no automated tests, aside from what was auto-generated by Rails.

My predictions and plans for the two-week project

• Wiring up models, views, and controllers will take considerably less time.
• Using Turbo Frames and Streams is a bit more natural now, and will take less time.
• I know nothing about Stimulus yet, though I hope a situation arises where I can learn it and feel good about it. If it does occur, it may eat up some time.
• I plan to use test automation for the next project, even if it is a little slim. I may do a little bit of reading and practice using automation on Bloggington (on a separate branch of course) before starting the 2-week project.
• The actual project itself is unknown at the time of writing. I do have some ideas though.

And that’s it!

If you made it this far, then thanks for reading! While the process of making this first web app was definitely tough, it was absolutely worth it after I finally got it online.

The 1212 learning process

dfebs May 25, 2025 0 Comments

Without any ado, I’m going to discuss a new theoretical method, the 1212 learning process. The process is simple. Trying to learn new a new software stack quickly? Do four projects, each of which are your own choosing. They will be ugly, they will be painfully unoriginal, and they will be wonderful little troves of knowledge. You will spend decreasing amounts of time on each project:

• 1 month on the first project
• 2 weeks on the second project
• 1 week on the third project
• 2 days on the final project

These projects will most likely not see the light of day, but you will learn a bunch of things. They will also be distinct projects from one-another to encourage variety in your day-to-day problem solving.

Project 1: The Warm-Up (1 month)

This gives plenty of time to trip over yourself constantly at the beginning and not feel the immediate doom of a close deadline. Every mistake can be seen as a learning experience, and the time spent on hitches will be a smaller percentage of the total time you have.

Project 2: The Build-Up (2 weeks)

By this point, the small things should be easier to navigate around. More significant steps need to be made per day but there is still a bit of time to iron out any unexpected issues. It is possible that some polish may be foregone.

Project 3: The Refinement (1 week)

Efficiency combined with consistency will be paramount here. Some simple workflows may be second nature at this point, but now things are more serious. A bad enough setback could put you behind, but your skills from the previous two projects will help to understand the intricacies and work around the issues.

Project 4: The Crucible (2 days)

Your ability to very quickly get something out the door will be forcibly squeezed out of you. The shortest path to success is the only path.

What this is, and what this isn’t

This process flushes out the bad projects you will inevitably make when taking on a new tech stack. By setting progressively shorter deadlines, you’re pushing yourself to move. We want to see through the things that don’t matter and get to the core of what we want to get out of the door.

This process does not intend to produce any software of value. While happy accidents are always a nice possibility, they are not the intention.

Some last things

So you might be wondering, does this process actually work? No clue; I just made it up. The good news is that I’m currently working on my 1-month project, so I am on my way to understanding the viability of the approach.

The project is an aggressively simple one, create a simple blogging application using Ruby on Rails. It needs to be a straightforward, possibly ugly, but functional MVP. In theory, it would be something I’d use if I wanted to sell to the totally-niche subgroup who desperately needs yet another blogging software. My hard deadline is June 15th.

For the ultra curious, the project is available to look at on Github. At the time of writing, lots of stuff is (justifiably) missing, but stay tuned for progress on future posts!

We’re so back

dfebs May 11, 2025 0 Comments

A year went by and I ended up not writing much! So it goes. For what it’s worth, I definitely can’t complain about anything that has gone on since then. Even now, things have been pretty good.

And I think that’s why I’ve considered writing again. While things have been going well, there’s the gnawing sense that perhaps, things could be even better. I want to improve my existence through means other than my usual gaming/exercise hobbies. What might that entail, you ask? To that I say, lots of coding and talking to people. Perhaps even at the same time. But not exactly in the same way as my day job. It’s a bit much to explain, and I hope it will make more sense when I elaborate in a future post.

On the creative side of things, I did my share of drawing last year but I found it wasn’t quite what I enjoyed doing. Pixel art is still pretty fun though; I see myself coming back to it here and there.

As an update, I’m currently learning Ruby on Rails. I’m working through the Getting Started guide at a relatively decent-ish speed (took about a week to work through it). I’m towards the end of it, but of course we all know that’ll only be the beginning.

I intend to start iterating quickly on project prototypes. Then I will write about those too. My goal is to get really good at throwing together solid proof-of-concepts and getting them in front of people very quickly. I spend a lot of my time overthinking, and it’s about time that I practice not doing that. I have the experience to pick things up and work through them, but I have been in a comfortable position for so long that it’s easy to get complacent.

So hopefully it’s a tad easier to see why I’m writing this now. Until next time!

What do I say?

dfebs May 13, 2024 0 Comments

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

dfebs Sep 18, 2023 0 Comments

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

dfebs Aug 24, 2023 0 Comments

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

dfebs Aug 15, 2023 0 Comments

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.