Forem: Sam Ringleman

10 Quick Tips that Will Speed Up Your Development

Sam Ringleman — Mon, 08 Jul 2019 14:33:30 +0000

Everyone wants the silver bullet. How do I learn x in 24 hours? Well, I hate to be the bearer of bad news, but coding is hard. You will want to bang your head against the desk, you will want to cry, you will cry. But in time it gets better. And there are ways to speed up learning. Here are 10 quick tips that you can implement right away, not only will it speed up your learning, but it will speed up your development process.

10. Use a debugger.

Some consider this knowledge a basic rule for coding. Just using this tool alone will help you gain a wonderful knowledge of your code. It is not enough to use print statements. You must get comfortable with the execution of your code. That is how you learn. Here is a tutorial on the basic usage of a debugger.

While simple to learn, I believe that debugging should be included in every university curriculum and practiced at every software development company. – Peter Franklin CEO Pryze

9. Be expressive.

In a code review, I love seeing theArrayReturnedFromAnIterator over i. In fact, I won’t approve a review if I see variables like this. Being expressive provides a quick glimpse into your code. Not only for others but for yourself 6 months down the road. What does the variable i mean in this context? Is it an iterator? Is it the count in a for loop? Is i an object (I don’t name all my variables based on what type it is, that what annotations are for)? Be more explicit with your variables. It may seem tedious to write it out now, but you are paying yourself dividends in the long run. Sometimes, those Java devs have the right idea.

8. Communicate with your team.

Always communicate. Express your ideas, no matter how new you are to the code. If you come from a different job, please, express your experience. No, we don’t think you are bragging. You could save the company millions, and your team countless hours. You know more than you think. Feel free to share it. In fact, feel obligated to share it.

7. Use an IDE.

If you let them, your tools will make you a better programmer. Quality in tools is important. The latest text editor is fine, but an IDE will allow you to dive deep into your code. There are free options that are close to more professional routes. VSCode has become the standard for a reason, first off it kicks ass. Second, with a couple simple plugins you can emulate a lot of the features that more expensive IDE’s provide. It will only make refactoring and debugging easier. When you are ready, buy yourself a license to JetBrains. Their tools have taught me more about programming than I can express.

6. Follow coding standards.

Standards are there for a reason. You may not like 4 spaces, or 2, or tabs, or I don’t care. What is the language standard? I want to jump in your PHP class and know that all your properties are declared at the top. That your static methods are below your properties. I want to look at an if statement and be able to jump from block to block. You can automate this using a linter. A linter will keep you up to date with the standards that the community has set. In time, you will follow this blindly. Use it. Love it. Automate it.

5. Keep methods small.

Hey, see that 650 line controller action? That’s how bugs are born.

In most cases, excessively long methods are the root of all evil. – Source Making

If you have a method that has nested conditionals, break that up. Make 15 small methods. You can hop to each method and know that it does one thing. Since you also followed step 9, you will be able to tell exactly what that method does because of the name of the function.


//This is hard to read, and gets messy quick.
if ($date->before(SUMMER_START) || $date->after(SUMMER_END)) {
  $charge = $quantity * $winterRate + $winterServiceCharge;
} else {
  $charge = $quantity * $summerRate;
}



//This is much better.
//Thank you Source Making for the wonderful examples.
if (isSummer($date)) {
  $charge = summerCharge($quantity);
} else {
  $charge = winterCharge($quantity);
}

Trust me, be more explicit, it will make you much faster in the long run.

4. Keep classes single use.

Create new classes, no you are not bloating the code! I suffered from this phobia for far too long. In most modern tools, jumping between classes is a simple keystroke. In PHPStorm for instance, hover over a class name, hit cmd + b.Jumps you right to the class. Like the last tip, I want to read your class name/namespace and know off the bat what this class does. Make a new class with only one or two methods. You will extend it in time, or you will learn what can extend from it. Small is always easier to test, and easier to read. Take a closer look at the SOLID principles if you want a more in-depth explanation.

3. Break things.

Version control is there for a damn good reason. Make that new branch. Break the shit out of everything! Test your idea.See where it succeeds, and see where it fails. This is how you learn. When I was first hired, I was horrified to try anything different than my seniors. I thought that my code needed to be like theirs. When I finally became confident that, yes I was going to break things, and that it was alright. I started to learn. That is one of the joys of software.You can take the internet out in one misplaced semicolon. It’s alright though, it can always be reverted. After all, it’s just a website .

2. Write tests unapologetically.

If your company doesn’t test, be the change. Lead that charge. Test your code.

You shouldn’t ask to write unit tests for the same reason you shouldn’t ask to do a good job. – Ted Bendixson

There is nothing more liberating than running your unit tests. It may take a little longer up front, but once that test coverage grows, you can refactor to your heart’s desire. You will know that your code works. And best of all, you can blame Chad over there, when he adds code and doesn’t run the testing suite…

1. Build personal projects.

This is the single most important thing you can do for yourself. Learn outside of work. Build that passion project that deep down you know is going to light you on fire. You will gain such a deep understanding of your language, your tools, your processes. It is invaluable. I cannot express in this short post how important this is. I implore you if you want to get good, build outside of work. Chase that passion. Then turn it into something someone else will use. Share it, live it, love it.

Closing

Some of these steps will take you time to learn, unit testing. Others you can implement immediately, using a debugger.The point is, if you use these steps, you will get faster at developing. Let me know in the comments what you think and if you have any other tips that have helped you along the way!

If you would like to join me in along my codeJourney, please come visit, read a few posts and join in on the conversation. I would love to see and hear from more of you!

Stop Using Print and Die Statements

Sam Ringleman — Mon, 24 Jun 2019 22:32:18 +0000

Today we are going to go over debugging 101 tips for using print or die statements. Discussing what you should do & why. The tips presented here are suitable for devs of all skill levels. Simply follow the instructions below to get your code on.

The Traditional Way

The statements below exist in every language & we all rely on them to #debug at some point.

Ruby:

puts "Message goes here"
exit

PHP:

print_f("Message goes here")
die();

Javascript:

console.log("Message goes here");
fail;

You Get the Point

Instead of the above, try using purpose built debugging tools. Believe it or not, using tools can make you a better programmer. A senior engineer once told me (early in my career) that anyone who doesn’t use a debugger is a chump. I could not agree more.

Seeing the Entire Picture

For those who are unfamiliar with debuggers, here is a quick introduction.

Debuggers stop a program mid execution, show the state of it & allow you to take a deep dive in.

A PHP script stopped mid execution using a debugger.

A debugger also allows you to step through your code, so you can see what is happening live.

A PHP script stepped down two lines in the same method.

Without this tool, seeing the entire picture of a program is next to impossible (if I am wrong about that, please show me a different way).

A debugger also allows you to check all current variable values at a specific point in execution. Globals, local variables, even variables buried deep in a private method. You can see it all.

A look at all variables in the current execution context.

An in depth look at the “$request” variable.

Anyone who doesn’t use a debugger is a chump.

Debuggers also show you the call stack leading up to that point of execution. Some even let you jump around in the stack. It shows the file, and method that was executed.

A call stack showed by the debugger.

Engage with It

Not only can you take a look, but you can manipulate as well. Change the value of anything and execute the program based on the values that you have chosen at that time. The power that comes with this can be wonderful. For instance, you want to assure that your data being fed into the method is correct, you can change what is incorrect just to test if your code does what you expect. This is a double edge sword though, the rest of the program executes on the data that you changed. Be careful.

Gain a Deep Understanding

By stepping into the code, you automatically make the source code of whatever framework/library you are working with relatable. You are able to visably see the code change your data. This helps gain a deep understanding of system control flow, especially when using a third party library or framework. I think one of the best ways to learn a framework is to dive into the source. A debugger forces that.

Dive into the source

Up Next

My next article in this series will be a closer look at the finer details of a #debugger. So today I want to leave you with one action item that you can start to implement using Javascript.

debugger;

function someThing(test) {
  test.er = 'howdy';
  debugger;
  test.ing();
}

This keyword in #Javascript allows you to fire a debugger automatically when executed in Chrome or Firefox. Note that you must have your console open in order for the debugger to stop execution. Then you can step through and into methods as needed. No more console.log();

Use it. Get comfortable with it. It works.

Parents in tech, how do you balance your time between coding and playing with your kids?

Sam Ringleman — Sun, 16 Jun 2019 19:32:15 +0000

First off happy Father's Day to all the dad's out there in tech! As far as I am concerned, parenting is the hardest job on the face of the planet. As well as the most rewarding!

I am highly passionate about coding and I have a side project in the works outside of my normal job. I try to spend as much time on it as my family deems fair.

If you are anything like me, how do you balance your time between coding and your family? Do you pull late nights or super early mornings? Do you ever feel guilty about coding when your kids are around? Or do you just code at work and call it a day?

I used to be an engineer on the railroad, now I engineer software, Ask Me Anything!

Sam Ringleman — Fri, 14 Jun 2019 21:59:23 +0000

Hi! I am Sam. I have had the dream of being in tech since I was little, but different life events happened and I didn't pursue my dream until what I consider late. I tried multiple times to learn to code and failed, I even dropped out of college while I was enrolled for CS.

I eventually went to work for BNSF (the big orange trains) as a conductor, and then became an engineer (the one who drives the train, not the same type of engineer). After 4 years, I got laid off. I decided while I was unemployed that it was time for a change. So I learned to code, and now three plus years later, I am an engineer with the R&D team at RE/MAX.

I keep these in the window above my desk at home. They are there to remind me of where I came from. To remind me that complacency is not ok. To remind me to keep pushing forward every day. I have a motto and it is cliche, but if I can do it, so can you.

I want to be an advocate for others trying to break into our industry. I have been so blessed by this move, and I want nothing more than to see others reach the same goal. So please ask me anything, I would love to get to know you!

Quick API Debugging Tip

Sam Ringleman — Fri, 14 Jun 2019 14:10:18 +0000

I learned this trick a couple years ago and it has saved me so much time that it's only prudent to share.

Say you built an API, and you are working on the front end to consume the awesomeness that is your API. You get your form set up to log your user in. Hit the send button and you get a 400 response. Wait, what the what? I have a very simple starting point that you can use with tools you are probably already using.

This tip involves either Google Chrome, or Mozilla Firefox. There might be more, but these are the two browsers that I use. As well as the Postman app. These are all free to use, so use them. They are awesome!

Open your dev tools.
- Chrome (cmd + alt + i)
- Firefox (cmd + alt + i)
Go to the network tab.
Find the failing request.
Right click and copy as cURL.
Open Postman and select import.
Select the "Paste Raw Text" tab.
Paste your cURL request you copied from your browser and hit Import.
Send your request for much easier debugging.

One thing to take note of, your request is completely imported into Postman. This makes it very simple to debug your request. You can see your data easier and any headers sent in their nice UI.

As a backend dev, I find it handy for the front end dev to send that request to me in chat. This way I can recreate what is breaking in my API with the exact data that they are sending.

I use this trick on a daily basis. I hope that you will too!

How Testing Speeds Up My Workflow

Sam Ringleman — Sat, 25 May 2019 15:10:00 +0000

So I am relatively new to the coding world. I have been a professional engineer now for a little over three years. Happily, I recently accepted a new position as a mid-level engineer, yay! I have learned quite a lot by taking a new position, one of the more prominent items to stand out in my mind is testing.

At a previous job, we were on the mindset that testing would slow us down. There were some strong opponents of testing. The most prominent argument that I heard was that testing took too much time. There is the time investment in writing the tests. There is the time investment running the tests. There is the time investment maintaining the tests. While these arguments have a point, you do spend time setting everything up. I counter this by saying the time investment is minor. The benefits that you gain through testing far outweigh the time invested upfront. I have experienced this first hand through testing my model relationships in Laravel.

My previous workflow for testing relationships was a bit awkward and clunky. I would do the database migration first, and in our situation, that was a straight SQL query to a testing db. Then go in the models and create the relationship (hasOne, hasMany, etc). Then to make sure the relationship is built right, I write a test controller. This controller has a test endpoint, oh and let's not forget a test route. The test controller action was simple enough, I don't need input from a user, but I do need a model ID. If that ID exists in the database I jump over to the database find an id for each model and join them in the controller action... If there was no ID I create a model and grab that ID. Then after I get my test controller action set up, I hop over into Postman fire off the request. Low and behold my test action borks. Hmm, I must have screwed something up in the models. Jump into bug tracking mode. I hop around the models, look at the db schema, back to routes file, and oh shoot, there it is, a mistake in my test action. Fix the small issue, then back into Postman, and yay it works. Now to finish hooking up the relationship in the code that matters. Then delete the test controller and routes and be on my merry way. This is a slow and clunky workflow, that is very error prone.

Fast forward to the new job, new lead. We do a lot of testing, unit, integration, feature, even UAT!

My new workflow goes like this. I design my schema and write a migration. Then I write a test for the relationship I want between the models. I then go into the model, and code the relationship. And I run my test. That's it.

Pretty lame post huh? Nah, let's go through an example together. I am using Lumen in this example. All the code is here, so if you want to follow along, install a fresh Lumen project and let's build some guitars!

Start off with the models schema and migrations. Run these two commands in your projects directory:

php artisan create:migration create_brands_table
php artisan create:migration create_guitars_table

Here is what our migrations are going to look like.

class CreateBrandsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('brands', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('brands');
    }
}

class CreateGuitarsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('guitars', function (Blueprint $table) {
            $table->bigIncrements('id');
            $table->string('name');
            $table->string('type');
            $table->unsignedBigInteger('brand_id');
            $table->foreign('brand_id')->references('id')->on('brands');
            $table->timestamps();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('guitars');
    }
}

Two very simple models and the relationship that we are designing here is a one to many. A guitar has one brand, and a brand can have many guitars.

Let's create our models now. Our Brand model looks like this:

class Brand extends Model
{
    /**
     * @var string
     */
    protected $table = 'brands';
    /**
     * @var array
     */
    protected $fillable = ['name'];
}

And our Guitar model looks like this:

class Guitar extends Model
{
    /**
     * @var string
     */
    protected $table = 'guitars';
    /**
     * @var array
     */
    protected $fillable = ['name', 'type'];
}

Again, nothing complicated, but now we get into the fun part. I like to write my tests before I write out my logic. So let's get started by writing the test for the Guitar to have one Brand.

Create the file GuitarTest in your testing directory. And add the first test it_should_have_one_brand:

class GuitarTest extends TestCase
{
    /**
     * @test
     */
    public function it_should_have_one_brand()
    {

    }
}

We need to have a guitar instance to run our tests. When it comes to testing Eloquent models it makes sense to use them with the database. So let's create a factory for the Guitar and Brand models.

In our ModelFactory file insert this:

$factory->define(App\Models\Guitar::class, function (Faker\Generator $faker) {
    return [
        'name' => $faker->name,
        'type' => $faker->randomElement(['acoustic', 'electric']),
    ];
});

$factory->define(App\Models\Brand::class, function (Faker\Generator $faker) {
    return [
        'name' => $faker->name,
    ];
});

Great! Now we can start the testing! So jump back to the GuitarTest that we started earlier and let's create our models.

    public function it_should_have_one_brand()
    {
        $guitar = factory(\App\Models\Guitar::class)->create();
        $brand = factory(\App\Models\Brand::class)->create();
    }

If you run your test here you are going to get an SQL error.

Illuminate\Database\QueryException : SQLSTATE[HY000]: General error: 1364 Field 'brand_id' doesn't have a default value (SQL: insert into `guitars` (`name`, `type`, `updated_at`, `created_at`) values (Jaydon Daugherty, acoustic, 2019-05-23 22:59:12, 2019-05-23 22:59:12))

Uh oh, turns out that we cannot create a Guitar at this point without first having a Brand. That is good news, we know that our schema is working. There are a few options available to use here. We can implement a factory state which will create a Brand for us. We could change the schema and make the foreign key nullable. Or we can not create the model and instantiate it.

Let's choose the latter and and leave our schema alone.

The create method on the factory creates your model and persists it to the database. The make method instantiates it and fills it with data leaving you to do the persisting. The reason that we got the SQL error is because of the create method. At that point we were trying to save the model, without giving a value to the foreign key that we created. We also did not specify that it was nullable. It does not make sense to me to have a Guitar without a Brand in this process (homebuilders, I feel you). So we get an error without supplying a value.

So what do we do? This:

    public function it_should_have_one_brand()
    {
        $guitar = factory(\App\Models\Guitar::class)->make();
        $brand = factory(\App\Models\Brand::class)->create();
        $guitar->brand()->associate($brand);
        $guitar->save();
    }

Please note that we changed the Guitar factory call from create to make.

Now to finish the test, add an assertion to make sure that we have the correct data, and this is a good test!

    public function it_should_have_one_brand()
    {
        $guitar = factory(\App\Models\Guitar::class)->make();
        $brand = factory(\App\Models\Brand::class)->create();
        $guitar->brand()->associate($brand);
        $guitar->save();
        $this->assertInstanceOf(\App\Models\Brand::class, $guitar->brand);
    }

Now run your test, you should get an error.

BadMethodCallException : Call to undefined method App\Models\Guitar::brand()

Which makes perfect sense, we haven't implemented the relationship yet. Let's do that. Head back into the Guitar model and add:

    /**
     * @return \Illuminate\Database\Eloquent\Relations\BelongsTo
     */
    public function brand()
    {
        return $this->belongsTo(Brand::class);
    }

And run the test again. You should be all green now!

We can go a little further with our assertion if we want to make sure that the guitar did save the same model. Note that this is optional, this test is fine as is.

The completed test looks like this:

    /**
     * @test
     */
    public function it_should_have_one_brand()
    {
        $guitar = factory(\App\Models\Guitar::class)->make();
        $brand = factory(\App\Models\Brand::class)->create();
        $guitar->brand()->associate($brand);
        $guitar->save();
        $this->assertInstanceOf(\App\Models\Brand::class, $guitar->brand);
        $this->assertEquals($brand->id, $guitar->brand->id);
    }

Great so we have our relationships tested right? Wrong. We have one way of a two-way relationship tested. Let's hook up our Brand model to their many Guitar models.

Create the BrandsTest in your testing directory and write the first test.

class BrandsTest extends TestCase
{
    /**
     * @test
     */
    public function it_should_have_many_guitars()
    {

    }
}

Remember that we have a one to many relationship here, so a brand can have many guitars. And that is what we are going to test for. Let's make our models:

    public function it_should_have_many_guitars()
    {
        $brand = factory(\App\Models\Brand::class)->create();
        $guitars = factory(\App\Models\Guitar::class, 5)->make();
    }

Then we need to associate them and run our assertions against the relationship. So our final test is going to look like this:

    public function it_should_have_many_guitars()
    {
        $brand = factory(\App\Models\Brand::class)->create();
        $guitars = factory(\App\Models\Guitar::class, 5)->make();
        $brand->guitars()->saveMany($guitars);
        $this->assertCount(5, $brand->guitars);
        $this->assertContainsOnlyInstancesOf(\App\Models\Guitar::class, $brand->guitars);
    }

Now when we run this test, like last time, we are going to get the error:

BadMethodCallException : Call to undefined method App\Models\Brand::guitars()

Again, it makes perfect sense, we haven't implemented that logic in our model yet. Add the guitars method to your Brand model.

    /**
     * @return \Illuminate\Database\Eloquent\Relations\HasMany
     */
    public function guitars()
    {
        return $this->hasMany(Guitar::class);
    }

Now run your tests, and if you followed along with everything, you should have two passing tests!

These tests to me are worth their weight in gold. Your application is going to grow and get more complex. Stick with adding your factories and then testing the relationships. You have tests to make sure that things are never failing. Once you get into a good flow, it takes 10 minutes to set up a factory, then build your test, and the relationship. Once your tests pass, you are good to write any logic surrounding these relationships.

You are going to thank yourself when you build a more complex relationship. Polymorphic many to many relationships are difficult to grasp but easy to test. The tests however, are the same as above. You now know that you set up your database schema right. You get the peace of mind knowing that the code you wrote, and are going to push to production on Friday, is at least tested. 😉