For go developers, bootstrappers who want to focus on the core of the product and not get bogged down by setting up everything else around it. Using that initial momentum and motivation to work on the thing that matters. It's a small one time fee, you can re-use this template as many times as you like, for as many projects as you like. I'd like to hear about it, the ugly, the bad and maybe some good. You can find me on twitter here, @cijincherian, and the project on gumroad.
Cijin Cherian Cijin
It's a funny thing this one. As you are facing and overcoming one, another is looming right around the corner vying for your attention. Don't get me wrong, not all fears are bad, some keep you alive! I'm talking about and wil only be talking about the one's that kill you before you even get a chance to die.
You'll like this answer! Not really :D. Only you can know, cause your fears are a culmination of avoidance of discomfort in your life over the years. And, they are
Training two to three times a day, resting was almost impossible, could not picture myself not training. Would wake up in the ass crack of dawn before the alarm. The only thing I could think of doing was getting on my bicycle and doing 10 - 20 laps around the lake with each lap around 2.2 km's in circumfrence. This would take an hour or two respectively. All the while maintaing a steady heart rate of 120-150 beats per minute. This shit was easy, I would sweat but never close to my limit, no where near. I never took lunch breaks in between work, eating took 20 minutes but only after a 20 minute kettlebell workout or 10 - 20 minutes of skipping. Then to finish it off an hour in the gym after work or back to the lake.
TDD just works, it's simple to implement. Gives you confidence on the code you are writing. It can be a great form of documentation. Moreover on complex problems it can help you get started by breaking problem down.
It's never to late start including tests. Regardless of the fact that you are scaling your operations, encountering a lot of bugs, lacking documentation, or starting a tight deadline feature, etc. From my humble experience, any time you save by not writing tests is offset by fixing bugs later on, most times more time that it would take to write the test. Plus, ain't nothing more scarier than pushing a change and wondering if something broke while your fixing a bug.
It's no ground breaking finding but an intersting one none the less. Was watching a movie based on a true story, one of my favorite things I took away from it was this; There was a challenging task in front of the kids in the movie, they had to do 12 months of learning in 8. So the teacher says, make life your problem, ask questions solve them, and ask questions of questions.
Now although the problem was aimed at teaching Maths, Science etc. I am a programmer so why not use the same ideology to improve coding skills. So here is one of them.
To be candid I never really understood what select statements did. I understood that they handled values returned from
channels similar to a switch statement, minus the channels.
It wasn't until I went through the Select chapter of TDD with go, that I really understood what they did.
What helped me understand was the the problem being solved in the chapter so I'll use snippets of those as my examples.
The question was the race to url using http.GET and return the faster one. Let's look at the initial approach
Although I find all animals and plants as all the mentors you will need in life. Grit from knucle dragging seeds, persitance from ants, kindness from dogs, selflessness from trees, curiosity from seals... and more
I picked cats cause I have two and I get to observe them more than any of the above as I work remotely from home as a software engineer
You are a child of god, no less than the sun and the stars. So treat yourself that way! Don't go chasing affection, attention
Cijin
/ devblabber-site-story.md
Created
April 12, 2022 03:49
How it took me a year to create the devblabber website
I gave the term "over-engineered" a whole new meaning, when I set out to create the devblabber website.
The goal was to create a simple blog website and learn AdonisJs (v5) which was recently released. Overkill would be an understatement. Took me a couple of weeks to write the UI using React which was totally not neccessary. Then once I headed to the server side. Things got out of hand really quick, I set a postgres server with redis which was the easy part still unnecessary. The project started to get features like people being able to login and comment on blogs. So got sidetracked and looked at how facebook handled comments, likes and etc (I know, I know). This continued for a few more weeks till a couple of months later when I started work and the project just sat there and there was no blogsite.
Cijin
/ negative-nancy-approach.md
Last active
April 11, 2022 04:46
The negative nacy approach to solving logical or programming problems
The idea came to me while I was petting my cat of all times and I remembered an interview question that I was asked once that I royally cocked up. That interview has had the greatest impact on how I think as a developer or person. Why? Let me give more context first.
The interview question was simple, it was a bracket matching question similar to what a linter would do. i.e. Given an input of string, check if an opening bracket is accompanied by a closing bracket and the order matters (I forgot about that "tiny" detail when I started to solve the problem 😁). Ex:
Input : {[( )])}
Cijin
/ buffered-channels-note-to-self.md
Last active
April 21, 2022 10:04
Buffered channels and how they differ from Unbuffered channels
A buffered channel is a channel that can hold one or more values before they are recieved. There are also different conditions when send and recieve will block:
- Recieve will block if there is no value in the channel
- Send will block if there is no space in the buffer for the incoming value
var bufferedChan = make(chan int, capacity) // where capacity is the number of ints the channel can holdNewerOlder