DEV Community: Bert Heyman

How to translate the Laravel password reset email

Bert Heyman — Fri, 15 Mar 2024 13:42:42 +0000

Laravel offers a very convenient default email to reset your password (via Laravel Breeze).
If you're building an application targetted at another language than English, you'll need to customize it.
I'm sharing an example, since the way to do this isn't always obvious.

Preparation

If you didn't do this yet, change the locale setting in config > app.php.
This will affect what translations Laravel looks for.

How to

In resources > lang, create a new file like nl.json (change nl by your language).
In that json, you can map the text from the password reset email to a translated version.

Dutch translation

To get you started, here is a Dutch example:

{
    "Hello!": "Hallo",
    "Reset Password Notification": "Wachtwoord reset",
    "You are receiving this email because we received a password reset request for your account.": "Je krijgt deze email na een verzoek om je wachtwoord opnieuw in te stellen.",
    "Reset Password": "Reset wachtwoord",
    "This password reset link will expire in :count minutes.": "De link blijft :count minuten geldig.",
    "Regards": "Groeten",
    "If you did not request a password reset, no further action is required.": "Als je deze aanvraag niet zelf hebt gedaan, mag je deze mail negeren.",
    "If you're having trouble clicking the \":actionText\" button, copy and paste the URL below\ninto your web browser:": "Als de \":actionText\" knop niet werkt, kan je ook deze link copy-pasten: ",
    "All rights reserved.": "Alle rechten voorbehouden."
}

Hope this saves you some time!

Turning your Github profile into a portfolio that works for you

Bert Heyman — Fri, 14 Oct 2022 08:46:14 +0000

Git is a wonderful tool, right?
Many use Github as their Git platform.
It does, of course, provide a valuable interface for history, pull requests, and much more - but did you know it has a huge impact in how companies see you as a developer?

If you want to leverage your Github profile more, these tips might help:

Time is valuable: have a clear focus 🎯

You start multiple projects enthusiastically, only to your Github become a big mess or repositories in all sorts of languages. If you want to apply for jobs in the JavaScript sphere, make sure your Github shows this:

Pin relevant projects for JavaScript
Set old or irrelevant projects to private
If a visitor only views one project, which one should it be? If you pin 1-4 projects, the chances of getting it right are big. If you focus on 10+ projects at once, that chance is a lot smaller.

Everybody hates absent docs: leverage README's 📖

A good readme allows you to inform your visitor so much better. Ideally, you mention:

Your role in the project (solo or part of a team?)
Scope and languages of the project
How to install, test or use (getting started)
Bonus: screenshots of how it works

Do you need a manual: do you have a personal readme? ✍️

Github offers a great option to add a small description to your profile. Create yours using their guide.

Don't be a stranger ✋

Lots of users never change the default picture. How personal you prefer your profile picture to be is your own choice, but I'd advise to at least change the default. It's often associated with newly created repositories having little content and purely tutorial-based code.

Don't stop at Github 🛑

Profile all brushed up? Great!
If you mention your Twitter, LinkedIn, ... give those some love too. Not sure what to link?

There's no single right answer here, but a good UX-focus always helps: what is most interesting to the people visiting your profile? Someone looking for a job might prefer to add LinkedIn, while an open source maintainer could opt for a Twitter account to have active discussions about the framework.

What do you think?
Hope you'll have a profile as cool as Mona Lisa Octocat now!
What makes a Github profile stand out for you? Curious to know, feel free to discuss in the comments.

The hidden cost of packages and how to avoid it

Bert Heyman — Wed, 06 Jul 2022 10:25:10 +0000

Packages bring a lot of value: they're reusable components, ready to be downloaded and just work! Magic, right? Needles to say, when I discovered them, I felt like a kid in a candy store. The more the better! Right? right?

For experimenting: yes! Of production-ready things: not so much...

The hidden cost

Packages bring a hidden, but often use cost with them. Your project becomes dependent on code from someone else. What if you need an update for the new PHP version a year down the line? What if you discover a security risk that needs urgent fixing? These are serious downsides to consider that might not come up immediately.

Being dependent on a stale external package can tank your development speed and even whole project!

On the other hand, avoiding packages all together means you'll miss out on a lot of useful stuff! If your production is shipping to production at some point, you'll want to get the perks and limit the risk of downsides by focussing on high quality, living packages.

A checklist to minimise the risk

I have a mental checklist to decide on a package and hope to help others by sharing it. Here we go:

⭐️ Github stars

The more stars, the more users. Read: a higher amount of people potentially contributing to the project, or taking over when the maintainer lacks time.

🕙 Time of the last update in the code

This could tell you a lot about the current state of the project. Is it actively updated? Only bug fixes? Or abandoned (not always mentioned in the readme)?

✏️ Documentation

The presence and quality of the documentation will have a huge impact on your development speed.

🚩 Issues & pull requests

Are these actively maintained? Do they show known bugs? Is the author open to pull requests for features you want but might not be there yet?

Lastly: A lot of open source maintainers do this entirely voluntary. This comes with a very different set of expectations than when you make use of a paid service. Be kind! And should you wish to do so, they're often happy to receive help on the project. It's a very rare industry where so many people share for free, let's celebrate that!

Happy packaging!

How to prevent local composer upgrades from breaking your live environment

Bert Heyman — Sun, 02 Aug 2020 14:38:25 +0000

For the scope of this article, I'll assume you have (basic) experience with composer and are familiar with the way dependencies are defined.

When you want to upgrade your dependencies, composer is smart enough to take your PHP version into account: it'll only upgrade every package to compatible versions. Let's say your local environment uses PHP 7.4, but the live environment is still on 7.2. Any upgrade will work with your local 7.4 but might break on 7.2 when being pushed to live.

Telling composer about the PHP version of your live environment

{
    // requires (...)
    "config": {
        "platform": {
            "php": "8.0" // Version from the live environment
        }
    }
}

Composer will now know about this version, and never upgrade a package to an incompatible version. So any local upgrades can be safely executed!

If your live PHP version is outdated, also consider upgrading! This will bring both performance and security improvements.

Often running into problems with different environment settings? Options exist that will create a complete container to run your application in, that will replicate the live environment - they need some setup though. (e.g. Docker)

Have you got other composer tips to share? Eager to hear about them!

Lessons learned from my mentees

Bert Heyman — Tue, 09 Jun 2020 18:20:28 +0000

Over the recent years, I got the chance to mentor some aspiring interns. Not only did I find great pleasure in mentoring others, it provided me with valuable insights as well. So, what did I learn?

Spot onboarding hiccups

If you're getting familiar with how things work, things seem a lot more obvious than when you're new to them. If an intern is having trouble understanding a topic, have a look if it can be refactored or simplified. These small hiccups were often starting points for improvements in the codebase.

Listen to their approach first

Interns don't have a lot of knowledge about the day-to-day workflow in the company yet. Listening to their thoughts and reasoning for a problem will leave them with more self confidence than directly providing them with a path to a solution. Even coming up with a terrible solution helps in finding a better one the next time!

Perhaps they thought of a technique you're not familiar with? Or maybe they spot restraints in the regular workflow? It's also a chance to look at things from a different perspective.

Provide context

Giving them a chance to analyse a problem themselves first, doesn't mean sending them in blind. When starting out, you're mostly training your analytical skills: how can I get from A to B as efficiently as possible? Finding the best approach balancing technical requirements with different types of customers' (and businesses') needs requires a lot of experience. Thinking together about who the most important stakeholders are will help them a great deal choosing the right solution.

What have you learned from your mentee or mentor?
Tips to share on how to improve yourself as a mentor?
I'd like to hear about them!

Domain records for dummies

Bert Heyman — Thu, 23 Jan 2020 19:50:07 +0000

If you own a domain name, you get to choose what site is displayed on it. But there's more to that: it's also possible to determine who can use the domain to send emails or you can verify your ownership. How does this work?

First things first: nameservers

By setting the nameservers, you basically tell the domain what rules to listen to. By default, these will probably be the servers from the provider you bought the domain from. However, you can pick any nameservers you want.

Getting your settings right: DNS records

These nameservers can set DNS records to specify all sorts of stuff.

A record

Tell the domain what server (by IP) to use for the website. Most of the time, this one will be the most important.

AAAA record

Using an IPv6 for your server? Then you'd need to use an AAAA record instead of a regular A record.

CNAME record

Defines an "alias" and thus points to another domain that, in turn, might have an A record.

MX record

A Mail Exchange record will make sure the correct mail server is used.

TXT record

A TXT record can basically be anything. They are often used to confirm ownership of the domain, which is useful for some Google services.

SRV record

Used to connect to other services. Might be used for email of other software. These aren't used too much, in my experience.

Help! I set some records but they won't work

Using the right nameservers?

It's possible to have records on other nameservers than the active one.
Domain name >> nameservers (service B) >> records (service B)
If you are editing records on service A, they won't take into effect until the nameservers point to service A.

Account for DNS caching

DNS settings are cached on several levels, so it might take a while before you see a difference. In general, it's best to account for 24h when changing nameservers and up to 4h for changes in the records.

Tip: if you know a change is coming, lower the Time To Live (TTL) setting beforehand. The default of 3600 seconds means a record will be updated once every hour.

Check the active settings with tools like Google dig. Waited long enough and still not updated? Check on a different network of with 4G. If it's allright there, the settings might be cached on your local network.

Anything to add? Don't hesitate to leave a comment, would love to learn from you!

Share your favourite PHP trick!

Bert Heyman — Sun, 20 Oct 2019 08:39:28 +0000

What simple trick or feature do you really like to use?

What is the most overlooked Laravel feature?

Bert Heyman — Thu, 05 Sep 2019 11:45:38 +0000

Tell us about hidden gems and useful -but often overlooked- features!

What do you like about it?
Why might it not be used as much as it should?

Bonus points if you include an article with an introduction for others to learn.

You get stuck with a package - what do you do?

Bert Heyman — Sat, 06 Jul 2019 06:38:24 +0000

So, you're wrestling with a complex problem and found the perfect package for it. Until you find a sudden hiccup or bug.

What's the root problem?

Try to find the underlying problem you need to solve. Perhaps the package isn't perfect for your use case or your approach need some tweaking.

Is there a simple workaround? Often, lots of routes will get you to Rome.
Is this package really the tailored solution you need? Or just a 90% there and will you end up hacking the last bits?
Is the package well maintained and documented or abandoned? A well used package will likely cover a lot more situations and language versions than one which lacks activity.

Check the known issues of the package

If the package is right for your use case but you still encounter problems, chances are other people are on the same boat. Search the Github or Gitlab issues to look for answers.

Tip: when searching issues also include closed ones, as these often contain answered questions.

Nothing yet? Consider opening a new issue.
Add as much context as possible (current language version, what did you try before, ...), this will help getting a quick answer.

Go for it & fix it / pull request

For smaller bugs, you could try and edit the package directly in your vendor folder - apply the changes afterwards with a pull request.
For more complex situations, pull down an own fork (see this this excellent guide by Matt Stauffer by Matt Stauffer) of the package and link composer to your local version. Not sure how to do this? Have a read here.

A pull request is actually a request to the package maintainers to pull your changes into the project - not to be confused with you pulling the code from the remote.

Again, add as much context as possible: what are you doing exactly with this pull request? Why did you solve it in a certain way? The maintainers have to handle lots of pull requests, so this information will be a great help to process them.

Don't be put off thinking your fix is not good enough. The maintainers will provide you with clear feedback and can request changes whenever needed. Actually, my first pull request got rejected because it caused another problem I hadn't thought of - I got some good feedback and learned a lot from it.

Remember: 99,9% of the time package owners are volunteers, so give them some time to review your changes.

Accepted? Congratulations, you just finished your first open source contribution! Depending on the package, a handful of / thousands of people will benefit from your work. Awesome, right?

How to get the most out of Stackoverflow

Bert Heyman — Wed, 03 Jul 2019 06:44:47 +0000

Simple question, simple answer:

Create an account

Believe me, it will make a difference!

Stackoverflow can be a life-saver when a complex problem pops up. However, starting to share your answers yourself or ask good quality questions can be a bit intimidating at first.

Lower the barrier

Once you have an account, there are various ways to help others even if you're not sure about writing answers yet.

Vote on questions & answers (or star them). This helps finding them again later and motivates others spending time to help.
Edit outdated answers, and update them with new information.
Comment (min 10 reputation, quite frustrating if this is blocked for your) to engage in answers/questions. Will really help you if want to dig deeper is someone else's question.
Finally: start asking your own well documented questions and answers. By voting up or down, you'll have learned what makes a question easy to answer or rather hard to understand.

Stackoverflow is one of my favourite ways to find answers and give back to the community by posting some answers myself.

What are your experiences with it? Interested to hear the story!

What challenges for development do you face in your region?

Bert Heyman — Mon, 03 Jun 2019 12:10:59 +0000

I recently read an article about the challenges developers face in India.

Which made me wonder about the different conditions and difficulties (or positive conditions) all around the world.

Limited access to learning opportunities or hard to come by tutorials in your native language? Lack of companies where you can learn? I'd like to hear about it!

What's development like in your region?

Need a cmd + Z in your database? Transactions to the rescue!

Bert Heyman — Wed, 29 May 2019 19:58:35 +0000

Let's say you're opening a new chocolate bar shop.
You're a bit of a Willy Wonka, so every week you upload newly invented products into your database:

Create new product categories
Insert new products and link to categories
Add related prices

If the creation of new product categories fails, the product might miss a category. Vice versa, a price for a non existing product has little use to the world. Determined to enrich the world with new ideas every week, you start looking for a solution: database transactions.

In short: your import will be all or nothing.

If anythings fails, nothing is changed in the database. Your data will only be updated if everything is working fine.

This feature is often overlooked, but isn't too hard in Laravel:

DB::transaction(function () {
    // An exception will rollback evertything in the database transaction
    DB::table('product_categories')->insert($productCategories);
    DB::table('products')->insert($products);
    DB::table('prices')->insert($prices);
});

And that's it - you're done!