Category: Uncategorized

Software is not a product. Unlike that chair you’re on, or that phone you have, software is useless outside the platform it’s built for.

Not only that, software is time-bound. That version of software you have on your phone needs to keep up with your OS version, or else will it break. It is slave to the relentless march of technology.

Thus, software is really a service. It has to be built but more importantly, it has to be maintained to be truly useful and fruitful. Sure you can use it for a couple of years, maybe, but when the platform it’s on gets abandoned or one of its more important features breaks, people will quickly flock to another alternative.

But who can maintain software? It’s certainly not your tech support team and definitely not the customer service people. You need software engineers to keep software serving as it should.

So if you are in the business of software, you need to do a few things to make sure it keeps running:

• Retain developers. Keep them motivated and productive. It’s less about perks and more about growth. Build a culture where developers are valued and heard.
• Focus on code quality. Make a case to stakeholders that this is practical and lowers costs even if it can be difficult at the start. This will also lead to happier devs since they spend less time fixing and more time building.
• Make sure knowledge about the inner workings of your software lives in more than one developer. This is not only pragmatic in the business sense, but also makes sure that at least two people can work on bugs and features. There’s a reason the buddy system works in large institutions like the police.
• When developers leave (and they will, it’s as sure as gravity), there needs to be a process in place for them to transfer their knowledge about your software. Best if this is actually part of their routines, but if not, having a knowledge transfer process is critical.
• Keep hiring. The cycle of developers leaving also benefits you since there are other developers leaving other companies you can snatch up as well.

This was a problem I had recently. My Ubuntu install is very customized so I wanted to copy everything and just update the files in place

1. Boot using Ubuntu USB Installer
2. Install Ubuntu into the new machine. Choose the barebones installation.
3. Reboot into the new installation, then reboot into the USB installer again.
4. Choose Try Ubuntu
5. Open Gparted
6. Copy source partition into the partition in the new device where Ubuntu is installed. It might be a partition within a partition, and is usually the largest one.
7. Wait
8. Reboot. Should boot okay now.

Hiya! The Tech Lead Roadmap is a continuation of the Senior Developer Roadmap

Clone it on Github! https://github.com/glennsantos/tech-lead-roadmap

I also added a checklist version of the roadmap, with a few links to resources.
TIP: Go to File > Make a Copy so you can have your own checkable copy of the checklist.

Got questions or thoughts about the map? Please leave me a comment, any feedback is welcome! ⤵️

Some areas where this can help you upskill towards leading teams:

#Motivation 🤩

> How to align team goals with personal member’s goals.

#TechnicalVision 🔭

> Cast the tech strategy so people can work independently while still staying aligned.

#Visualization 📊

> Diagramming is important for conveying ideas quickly to stakeholders and team members alike.

#Delegating 🤲

> Cascade tasks down without being heavy-handed.

#TeamProductivity ⚽

> Ensuring the team works well while still growing in their respective roles.

#DealingWithConflict 🗯️

> Devs sometimes rub people the wrong way. Here’s help how you can show the others to get along better with teammates and others in the org.

Need a mentor? Join our mentorship program: https://tally.so/r/3leK5w

Want to become a senior dev? I’ve made this Senior Developer Roadmap 🗺️ just for you!

This is my take on what skills and traits you need to grow into a senior position. It’s still a work in progress, so expect some improvements in the future.

TIP: Click on the image to load the full resolution version.

Here’s a quick rundown of the content included:

Prerequisite: Previous Role’s Roadmap

You need to have gone through the previous roadmap for your role as outlined in roadmap.sh. This is important since your team will look to you for technical guidance in your specific stack.

Code Quality

As a senior developer, you need to uphold quality not just for your own work, but in the work of your team. This means creating standards, doing reviews and documenting as needed.

Decision Making

A senior role is characterized by making good decisions. There are many technologies we can use to create products so choosing the right one for the project is important.

Technical Solutions

Another task of a senior dev is turning ideas into practical solutions. Not only do you build new features, but you also have to fix and improve existing ones with an eye towards reliability and performance.

Communication

It’s a misconception that the senior dev sits behind closed doors coding all day. You also need to be able to convey your ideas well, both to dev teammates and nontechnical colleagues.

Project Planning

Sure you might think this is a PM’s job, but remember that you’re also tasked to create solutions, which is part of the project planning process. So know how your company’s project planning process works so you can work effectively within it.

Technical Mentorship

One of the most gratifying tasks of a senior dev is improving the technical capability of the team. This happens through mentorship.

Leadership

Finally, the best trait of a senior dev is being a good leader of the team. This is also the toughest part of the journey, since you need to cultivate new patterns of thinking that involve raising up others more than yourself.

Got comments, feedback and questions about it? Just email me or comment below!

I also put it up in Github so you can clone it easily: https://github.com/glennsantos/senior-developer-roadmap/

There’s also a checklist version of the map there, if that’s more to your liking.

Stay tuned for the Tech Lead Roadmap coming soon!

If you want to get a sense of which level you’re on in your engineering career, here’s a chart made by Mozilla of how their career ladder for individual contributors work. Click here for the hi-res version

Source

Once a webpage leaves your servers, anything can happen to it. Sometimes, the client’s browser tries to execute scripts against your page that range from the benign changing of font colors to nastier XSS attacks that manipulate and steal user data.

This is where a Content Security Policy comes into play. It basically instructs the browser what kinds of content is allowed to load for your site. This includes restricting loading of external scripts, images and any other files that might want to load on top of your page.

Implementing this is quite easy in Laravel:

1. composer require spatie/laravel-csp
2. php artisan vendor:publish --provider="Spatie\Csp\CspServiceProvider" --tag="config"
3. Then, add it to your middleware in app/Http/Kernel.php:

protected $middlewareGroups = [
        'web' => [
             \Spatie\Csp\AddCspHeaders::class,
             // other middlewares
        ],
    ];

Your CSP is set up! You can view the directives in vendor/spatie/laravel-csp/src/Policies/Basic.php . This is a bit restrictive though, so you might want to publish your own policy instead. Here’s one I used recently:

<?php

namespace App\Services\Csp\Policies;

use Spatie\Csp\Policies\Policy;
use Spatie\Csp\Directive;
use Spatie\Csp\Keyword;

class MyPolicies extends Policy
{
    public function configure()
    {
        $this
            ->addDirective(Directive::BASE, Keyword::SELF)
            ->addDirective(Directive::CONNECT, Keyword::SELF)
            ->addDirective(Directive::FORM_ACTION, Keyword::SELF)
            ->addDirective(Directive::IMG, [
                Keyword::SELF,
                'data:',
                'blob:'
            ])
            ->addDirective(Directive::MEDIA, Keyword::SELF)
            ->addDirective(Directive::SCRIPT, [
                Keyword::SELF,
                'www.google.com',
                'www.gstatic.com'
            ])
            ->addDirective(Directive::OBJECT, Keyword::NONE);
    }
}

You can learn about what the different policy directives mean in the Content Security Policy Quick Reference Guide. In my own policy above, I allowed image blobs and base 64 image data, as well as letting Google in because of Recaptcha and Analytics.

1. Create your new policy. I saved mine in app/Services/Csp/Policies/MyPolicies.php. Feel free to use my own policy above as a starting point for your own.
2. Go to config/csp.php
3. Replace the content so that it will use your new policy instead

<?php

use App\Services\Csp\Policies\MyPolicies;

return [

    /*
     * A policy will determine which CSP headers will be set. A valid CSP policy is
     * any class that extends `Spatie\Csp\Policies\Policy`
     */
    // replace the default policy
    //'policy' => Spatie\Csp\Policies\Basic::class,
    'policy' => MyPolicies::class,

    /*
     * This policy which will be put in report only mode. This is great for testing out
     * a new policy or changes to existing csp policy without breaking anything.
     */
    'report_only_policy' => '',

    /*
     * All violations against the policy will be reported to this url.
     * A great service you could use for this is https://report-uri.com/
     *
     * You can override this setting by calling `reportTo` on your policy.
     */
    'report_uri' => env('CSP_REPORT_URI', ''),

    /*
     * Headers will only be added if this setting is set to true.
     */
    'enabled' => env('CSP_ENABLED', true),

    /*
     * The class responsible for generating the nonces used in inline tags and headers.
     */
    'nonce_generator' => Spatie\Csp\Nonce\RandomString::class,
];

Now that you have your CSP set up, you can check it by entering your site in Google’s CSP Evaluator. Mine showed this:

Of course, this is just a guide, no need to be alarmed if it says high severity. For me, the script-src finding was okay because I needed to allow Google scripts to run on the site. So evaluate your results based on how your webapp works and don’t force your site to get all green checks in this test.

Hope to see more people securing their site via CSP!

Source: Christoph Rumpel

Ah, the pitfalls of a popular framework. Everyone uses it therefore it’s easy to get coding help but everyone also abuses it so any and all exploits will be sussed out.

One of these is such a basic feature that I think everyone should turn off: XML-RPC. I won’t go into all the details but suffice it to say that it’s bad. And if you do want to access your WordPress site remotely, say like a headless CMS, then use REST instead of XML. It’s much better for your health, trust me.

Here’s how to disable it:

1. Go to your site root’s .htaccess file
2. Insert this snippet at the top:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

You should be good. Double check if it worked by testing it here: https://xmlrpc.eritreo.it/ You should see that comforting red X in the next screen.

Source: WordPress StackExchange

Here’s my big list of remote dev jobs. Made this as part of my research for a future app idea. Also includes sites where you can get full-time local dev jobs.

TIP: First, check if the job fits you by checking the job responsibilities. Then, check the job qualifications to see if you fit the job.

{{remote_dev_ job_boards}}

{{remote_friendly_companies}}

{{fulltime_local_dev_jobs}}

{{local_tech_companies}}