First screencasts: building dashcopy

Building dashcopy

A few days ago I wrote about doing something I never did before, something I’m not particularly good at. As expected, the initial result was poor, but I kept on improving the obvious mistakes and it got better. It’s true what they say: first drafts always suck.

Sharing your progress through screencasts, podcasts, and blog posts is a common practice, so I thought I should give it a go and started a video series on youtube. It’s a great way to keep myself accountable and practice expressing my thoughts and my rusty East-European English.

I knew it will be hard. Talking by yourself, and especially hearing your voice, is super awkward, even more so if your pronunciation is poor, or you’re just bad at talking in general.

But oddly enough, it wasn’t that hard as I thought it will be. The end result is a million miles away compared to your standard Jeffrey Way screencast, but it’s way better than I hoped for. My pace is irregular and I sound like I’m talking from a hole, but overall the videos are bearable.

Although sometimes I got into too much detail, or wasted time running tests knowing they will fail (beating that TDD dead horse), my intent is to move away from the tutorial-like material and turn it into real, unplanned coding sessions where I try to figure out the best approach in doing things. Ideally, I would love to reach a point in which I am able to code and speak my mind at the same time, but I am aware it will take me a long time o master that skill.

Here’s a link to the channel. If you watch programming screencasts regularly, I would love to get your opinion.

Also, if writing is something you wish to get better at, join the list and be the first to know when dashcopy is ready.

February 14, 2019 Add Comment

Do you train for the unexpected?

Do you train for the unexpected?

We all have our “I can do one more” moments in the gym. When we’re super confident we have one rep more in us but we fail miserably.

It doesn’t happen every day or every week (if it does, you really need to slow the f**k down), but when it happens, it can lead to serious injuries.

Most of us know a few things about staying safe. Like, if you don’t have a spotter while you’re bench pressing, you leave the clips off so you can dump the weights to the side in case something goes wrong. Or to make sure you adjust the safety bars when you’re squatting so you can drop the weight if you fail to do that last rep.

If you’re into fitness, like me, you most likely spend a good amount of time looking for new ways to maximize your results. How to overhead press more, what workout splits are better, how many reps, how many sets, how low to squat, how high to press?

We search and try all sorts of training methods, exercises and workout splits.

But… when is the last time you trained for the unexpected?

February 12, 2019 Add Comment

Money is not a prerequisite to start an online business

Sometimes I have these thoughts of how it would be to start my own thing. To work on my own service or product. To chart my own path and call my own shots.

It usually happens when I’m on a long drive. All sorts of ideas cross my mind: fitness instructor platform, event services, cleaning services, homeschooling, and others.

Once I stumble upon a decent one, I start thinking about what would it take to make it real. What tools to use, how it would work, how it will make money, what people would be interested in it.

The problem is never money.

Assuming you have the required skills to build the damn thing, there aren’t any huge costs you need to support. You only need a domain and hosting. That’s it.

Let’s say you have that 100k budget to start with.

What would you do with it? What would you buy? Who would you hire? Will spending that budget turn your business into a profitable one?

Sure, it’s nice to have money, but they are rarely a prerequisite to start an online business.

February 11, 2019 Add Comment

The build cycle of a Laravel application feature

I wrote about having a crossword approach to writing software, but I haven’t given any real-world examples. I only said it’s better because it doesn’t let you wander around and dip your fingers into everything. It keeps you focused on what’s needed now.

Let’s say you’re building a content management system using Laravel. Here are the steps I’d take to build it:

1. Write the code to display the posts in some kind of list. You can get this done by just having a seeder in place and a simple query on the index method. Don’t worry about filtering or anything like that.

2. Write the code to show, store, update, and delete posts. Completely ignore any validation and authorization for now.

3. Notice I haven’t said anything about writing views. No html&css should be written so far. Views can wait.

4. Go back to the create and update methods and add some validation rules.

5. Sprinkle some authorization too. Don’t forget about the delete method.

6. If you need to filter the posts in any way, now is probably a good time to do it. Don’t forget to write tests that cover every filter.

7. Now that all the logic is in place and thoroughly tested, we can start focusing on the views. Style the index and the show views.

8. Add the create and edit post endpoints and style their views too.

9. Sprinkle some javascript where’s needed. Don’t over do it.

10. Pick the next feature. Make sure it touches as few things as possible.

Rinse and repeat.

February 9, 2019 Add Comment

Better, not perfect

I just finished something I’ve been working on for the past week and I am quite dissatisfied with the result. I’m not sad, nor annoyed. It’s something I never did before, so poor results were to be expected anyway.

What brings me satisfaction is that, one week in, and I already found more than a few ways to make it better. They are not ifs or maybes. They are obvious improvements that directly impact the end result.

Don’t waste time, don’t put much thought on it, “Just ship it” they say.

The reason behind “just ship it” is to get as much feedback as possible to help you gradually improve whatever you shipped. The faster you get the feedback the better.

But how do we know when it’s “ship-ready”? It will never be perfect, but when it will be good enough? You can’t just deliver some crappy version of your idea and expect people to like it enough to guide you in the right direction.

It’s good enough when you’re done improving the obvious.

February 7, 2019 Add Comment

More than ordinary

It’s immensely pleasing when the barber doesn’t need to ask how you want your hair done, or when the barista hands your favorite drink the second you sit at the bar, or even when things go wrong and apologies are made.

More than ordinary. We love that.

And we give back. It’s no longer just ‘a barber’, it’s ‘my barber‘. Not a random bar, ‘my favorite bar‘.

We return the favor. Always.

February 3, 2019 Add Comment

Eloquent trick #1: Replace conditionals with “when”

It happens very often that we want to apply certain eloquent query conditions based on what a request sends in. Sometimes it’s a “search by name” thing, other times we just need to filter the records based on a status column.

Usually it looks like this:

public function index(Request $request) 
{
    $posts = Post::newQuery();

    if ($request->term) {
        $posts->where('name', 'LIKE', "%{$request->term}%");
    }

    if ($request->status) {
        $posts->where('status', $request->status);
    }

    return view('posts.index', ['posts' => $posts->paginate()])
}

I recently discovered there’s an alternative to using conditionals. The “when” method executes a callback (second parameter) when the first parameter evaluates to true.

public function index(Request $request) 
{
    $posts = Post::when($request->term, function($q, $term) {
        $q->where('name', 'LIKE', "%{$term}%");
    })->when($request->status, function($q, $status) {
        $q->where('status', $status);
    });

    return view('posts.index', ['posts' => $posts->paginate()])
}

It’s not all that better if you ask me. Yes, it hides the conditionals, but it also makes the code harder to read. Especially if you have more conditions to add.

I’d use this “when” approach for single conditions only.

public function index(Request $request) 
{
    $posts = Post::when($request->term, function($q, $term) {
        $q->where('name', 'LIKE', "%{$term}%");
    });

    return view('posts.index', ['posts' => $posts->paginate()])
}


January 30, 2019 Add Comment

Two thoughts I try to live by

Seeing the full glass
If you’re walking down the street and a thief steals your hat, you probably get real angry real fast. It’s only natural, but I’d like to be able to see it as an opportunity to buy a new hat. The one I had was getting old anyway.

Doing the best yes I can
Don’t make a habit of saying yes to everybody and everything. You won’t be able to please anyone, not even yourself. But when you do say yes to something, you need to take responsibility and do the best yes you possibly can. It would be nice to be able to say “I don’t do much, but I do these few things extremely well“.

I’m bad at following my own advice, in fact, I almost always fail to do so, but I like to think someday I’d be able to stick by these two.

January 29, 2019 Add Comment

Thank you, apple, for letting us know we’re not alone

Feel bad for messing up something at work lately? You’re not alone :). Apple messed up big time.

The bug lets you call anyone with FaceTime, and immediately hear the audio coming from their phone — before the person on the other end has accepted or rejected the incoming call.

Read more here.

January 29, 2019 Add Comment