DEV Community: _juliettech

nerd_splash: a newsletter for nerds 👩🏻‍💻

_juliettech — Sun, 18 Apr 2021 18:48:29 +0000

Hey dev community! 👋🏼

I'm starting a newsletter on technology trends, the future of education, and people's strange, yet insightful behaviors.

I'm specifically tailoring it to the most curious, nerdy people out there - those who happily indulge in a good rabbit hole and a concisely written idea splash.

3 intellectual goodies, 2 brain farts, 1 funky audio.

Join the cyber community here!

How to write clean code

_juliettech — Mon, 25 Jan 2021 00:19:35 +0000

Writing clean code is like writing poetry. Poetry that is easily understood, has transformational power, and is written in a concise manner.

Clean code means a scalable organization. It's the difference between a junior dev and a senior engineer. It means being able to pivot plans without much chaos.

It took me several recommendations to actually gain up the courage and read Clean Code. It's one of those books you can't help but judge by its cover. I'll admit though - lives up to the hype. Insights are clear, specific, practical, and with a spark of nerdy humor that gets to my heart. Today, I share with you my top take-aways.

1. Your code being readable is as important as it being executable

The majority of the cost of a software project is in long-term maintenance. Therefore, the code you write should clearly express your intent so that new developers can easily hop in and understand what is going on and why. The clearer the author can make the code, the less time others will have to spend understanding it. This reduces defects and shrink the cost of maintenance.

How to do this: good naming practices + single responsibility classes and functions + writing tests

2. Later equals never

Let's be honest. We've all said we'd go back and clean it up later and then forgot about it. Don't leave scraps of useless code that no longer serve a purpose. They confuse other devs and provide no value. When changing a feature, always make sure to delete the old code. Tests should notify you if you're breaking stuff elsewhere anyways.

How to do this: Deleting code can be scary, especially in a big architecture. That's why tests are key to keeping your code clean so you can delete with confidence.

3. Functions should be small

The first rule of functions is that they should be small - hardly 20 lines long. This is because the smaller and more focused the function is, the easier it is to choose a highly descriptive name.

When it comes to a function's arguments: the ideal number is 0. Then goes 1, then 2, but more than 3 should be avoided where possible.

How to do this: Functions should follow the Single Responsibility Principle and the Open Closed Principle.

4. Duplication is the evil of all code

Duplication is the enemy of a well-designed system. It represents additional work, additional risk, and additional unnecessary complexity.

How to do this: Avoid it at all times by keeping your code DRY (Don't Repeat Yourself), isolated, and modular.

5. The only good comment is the one you found a way not to write

"Nothing can be quite so helpful as a well-placed comment. But comments are, at best, a necessary evil."

The proper use of comments is to compensate for our failure to express our self in code. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not cause for celebration.

Thing is, comments often lie. Not always, and not intentionally, but too often. The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong.

The reason is simple: programmers can't realistically maintain all of them so all too often they become separated from the code they describe and become orphaned blurbs of ever decreasing accuracy. Usually comments are crutches or excuses for poor code or justifications for insufficient decisions, amounting to little more than the programmer talking to him/herself.

How to do this: descriptive naming practices that allow devs to know what the variables represent + provide tests so other devs can see what the main functionalities are.

6. An object exposes behavior but not data

A module should not know about the innards of the objects it manipulates. Objects hide their data and expose operations. This means that an object should not expose its internal structure through accessors because to do so is to expose, rather than to hide, its internal structure. There's no need for everyone to see you naked.

How to do this: The scope of variables should be as local as possible, without exposing more than is necessary.

7. On testing

Test code is just as important as production code and as such, it must change and grow as the production code evolves. Keeping tests clean is so important because without them, you lose the very thing that keeps your production code flexible, maintainable, and reusable. If you have tests you do not fear making changes to the code and without tests, every change is a possible bug. Tests eliminates the fear that cleaning code will break it.

Readability keeps tests clean because they are an opportunity to explain to other devs the intent of the original author in plain English. This is why we want to test only a single concept in each test function so that the test is descriptive, reads easier, and is easier to track when it fails. Clear separation and good test writing help define expectations and keeps the scopes clear.

How to do this: Follow the FIRST Principles:

Fast: tests should be ran quickly. If you have to wait too long for each test you're less likely to run them often.
Independent/isolated: tests should not depend on each other or build from each other. They should be as isolated as possible.
Repeatable: tests should be repeatable in any environment - development, staging or production.
Self-validating: tests should have a boolean output. They either pass or fail.
Thorough: tests should aim to cover all edge cases, all security issues, every use case and happy path.

8. On error handling and exceptions

Each exception that you throw should provide enough context to determine the source and location of the error. Although you usually get a stack trace from any exception, a stack trace can't tell you the intent of the operation that failed.

You should avoid passing null in the code whenever possible. And if you are tempted to return null from a method, consider throwing an exception. Set error handling as a separate concern, something that is viewable independently of our main logic.

How to do this: Create informative error messages and pass them along with your exceptions. Mention the operation that failed and the type of failure. Our most important concern should be how they are caught.

9. On classes

Classes should be small, but rather than counting lines, we should count responsibilities. The names of classes are key to describe which responsibilities it fulfills. Our systems should be composed of many small classes, instead of a few large ones, where each small class encapsulates a single responsibility. Each class has a single reason to exist and collaborates with a few others to achieve the desired system behaviors.

There is seldom a good reason to have a public variable. Loosening encapsulation is always a last resort and there should be a small number of instance variables at all. Good software designs accommodate change without huge investments and rework. Narrowing the scopes of variables allows us to do this more easily.

How to do this: Separation of concerns is one of the oldest and most important design techniques in our craft. This is for a reason. Trust it. Classes should be open for extensions, but closed for modification. In an ideal system, we incorporate new features by extending the system, not by making modifications to existing code.

10. On format

Each blank line is a visual cue that identifies a new and separate concept.

Local variables should appear at the top of the function.

Instance variables should be declared at the top of the class.

Short lines are preferred to long ones — usually around 45 characters - 100-120 characters. After that, it's probably just careless.

How to do this: Most of these options can be passed to a linter in your CI or text editor. Take advantage of these tools to keep you code as clean as possible.

Principles of software development

In summary, follow these practices and your code will be clean:

a) Naming variables: Implicitly knowing where things are - and using approaches such as suitable naming — is crucial to keep the code readable and hence, maintainable.

"You should name a variable using the same care with which you name a first-born child."

The hardest thing about choosing good names is that it requires good descriptive skills and a shared cultural background. Clean code is read and enhanced by any developer.

The name of a variable, function, or class, should answer all the big questions: why it exists, what it does, and how it is used. If a name requires a comment, then the name does not reveal its intent as it should. Programmers must avoid leaving false clues that obscure the true meaning of the code.

Longer names trumps shorter names, and any searchable name is better than a constant in the code base. Single-letter names can only be used as local variables inside short methods: the length of a name should correspond to the size of its scope. Methods should be verbs or verb phrases; a class name should not be a verb.

b) Minimal dependencies: We should avoid letting too much of our code know about the third-party particulars. It's better to depend on something you control than on something you can't control. If you do, it ends up controlling you.

c) Tidiness: A piece of code should be where you expect to find it. Code bases should be intuitive to navigate through; developer's intentions feel clear.

d) Cleaning: Don't litter your code with useless code scraps or lines of code that capture history or wishes of the future. Reduced duplication, high expressiveness and early building of simple abstractions.

e) Standardization: Your code should keep a consistent coding style and set of practices across repositories.

f) Self-discipline: you frequently reflect on one's work and are willing to change and improve. However, you don't fall into the hype too fast. Study new stacks with depth and purpose.

Truth is, keeping your code clean is key to maintaining innovation and organizations alive. As systems scale and grow, it is inevitable that old technology practices and hacks get left behind in the code. Keeping your code base clean is more than a nice gesture for other devs. It's a necessity for long-term survival. The cleaner your code, the happier the devs, the better the product, the longer it lasts.

Best Firefox plugins for developers

_juliettech — Tue, 08 Sep 2020 14:38:14 +0000

Let's face it. As a dev, we spend more time on the browser than we do pretty much anywhere else. Whether we're designing, building, or going deep into the research rabbit-hole, the browser is the home and breeding ground for most of our ideas and tools.

That's why collecting a good repertoir of plugins is so crucial to surfing smoothly and optimizing our workflow. What you'll see below is a curated list of the best ones I've gathered throughout the years using Firefox.

"Why Firefox?", you may ask. Few reasons.
1) Is open-source,
2) MDN documentation has saved my life multiple times,
3) I have some respect for the last shreds of privacy I have left from Google,
4) Awesome dev tools.

Need I say more. Let's begin.

Wappalyzer

#stack #research

Wappalyzer shows you which frameworks and technologies were used to build a specific site. This is very useful when you want to make an estimate to start working on an existing project, or simply get some insights on the stack someone else used for their great designs.

Ideal target: freelance developer working on pre-built projects who needs to know more about the platform at a fast glance. Also helpful if you're a curious human wondering how other people have built their platforms and designs.

Open Pesticide

#front-end #css #layout

Pesticide is a front-end must-have for everyone who has spent time struggling to find that one closing <div> breaking my entire screen, aka every one who's ever done front-end. Open Pesticide visibly lays out where a container starts and ends by drawing borders around <div>s. This clearly point out which <div> is causing havoc and save us hours of emotional pain. Pesticide is a gift from the front-end Gods.

Ideal target: front-end devs struggling to find broken <div>s or enlarged paddings.

OLI Grid CSS

#front-end #css #grid

Whether you're using CSS or Bootstrap grid, OLI Grid CSS comes in really handy to help visualize your layout throughout a page by showing you exactly where and how big your columns are.

Ideal target: front-end web devs dealing with grids and Bootstrap often.

Daily 2.0

#news #browser-experience

Daily 2.0 turns your browser's New Tab screen onto a tailored dev news feed filled with all your favorite resources about the topics you care about. If you like being up to date with the latest technologies, tech articles, events, and tutorials, Daily 2.0 will save you hours of browsing brought directly at your doorstep. And no, it's not another newsletter to jampack your inbox.

Ideal target: you endulge in reading tech articles, but don't have time to scroll through HackerNews or dev.to for hours.

Dark Reader

#browser-experience

As devs, we spend most of our days in front of a computer, which means our eyes will eventually start to hurt from so much UV light. In order to help, Dark Reader transforms every website into Dark Mode.

That's right, you're welcome.

Ideal target: if you're a Dark Mode fan, which is everyone, or if you're having some problems with your eyes after being in the computer for so long.

Adblock Plus

#browser-experience #privacy

There is nothing worse than having spammy ads chase you all around the web. Adblock Plus allows you to have an add-free, zen experience while browsing online by eliminating all targeted ads.

Ideal target: you have way too information about you on the internet already and ads are getting annoying and scarily specific.

Facebook container

#privacy #tracking

Built by Mozilla itself, Facebook Container plugin stops any page from giving your information to Facebook so can track your movements and habits. It's honestly scary the amount of sites where this actually shows up as being automatically enabled. The things you don't know 'til you know.

Ideal target: you worry about privacy and want to keep your browsing habits away from Facebook.

HTTPS Everywhere

#privacy #encryption

HTTPS protects your communications by enabling SSL encryption automatically on sites that are known to support it, even when you type URLs or follow links that omit the https:// prefix. HTTPS Everywhere adds a layer of protection to your browsing experience, which is especially useful if you often use public wi-fis and fear people will intercept your transactions.

Ideal target: digital nomads who move from café to bar to airports with their computers. You probably also care about privacy issues while you do important transactions online.

Liner

#note-taking #productivity

Liner is a greeeat tool if you're someone who's reading way too many articles and wants to keep track of good quotes or explanations you find online. It allows you to save quotes, paragraphs, and images and categorize them onto folders for easier retrieval when you need them. It's like having a highlighter online.

Ideal target: researchers, documentation hoarders, deep readers.

Side View

#productivity #browser-experience

You know that moment when you're doing a tutorial and wish you could see the video on one end of the screen and have your note-taking web app on the other? Or when you're reading notes and want to edit your presentation slides at the same time, all in your browser?

Mozilla's Side View enables you to split your browser window in two so you can see both sites at the same time. If you thought native screen splitting was cool, you're not gonna regret getting Side View.

Ideal target: you don't often use native apps, but rather do most things on the browser. Probably because you use a public/office computer or don't have much space locally. Or maybe you just prefer browser apps to native ones.

Notion Clipper

#note-taking #productivity

For you Notion heavy-users, this baby seduced me the moment I found out it existed. With Notion Web Clipper you can automatically save an article directly onto a page in your Notion workspace straight from the browser.

Ideal target: You take most of your notes in Notion and want to keep information centralized in that space. You're probably also too lazy to just copy paste the link and add it yourself.

Git merge, git rebase, and crawling out of the git hole

_juliettech — Tue, 28 Jan 2020 03:09:42 +0000

To master git is like being a time wizard ✨. You can move across points in time, flying like a bird from one commit to the next, always having a stepping point to go back to when you fuck up. Because let’s be honest, at one point or another, we will.

And that's how we get into the git hole. For those of you lucky enough to have never experienced it, the git hole is that dark place in a developer’s life when your timeline becomes a blur and you’re not sure what happened or where you lost your perfectly-working code.

So what's this big fuss between git merge and git rebase?

The most important thing to understand is that when we’re talking about merging and rebasing, it’s all about how your branch ends where it ends.

What do I mean by this?

What they have in common

git merge and git rebase both join your code with another branch, usually your remote’s master branch.

Where they differ

git merge

When you’re doing a merge, your git tree is coming full circle and you can see this graphically if you download a visual tool like Sourcetree. This means that:

The branch you’re currently working on, with all your commits and lines of code, will be joined back into master, leaving a trail of where it first left and when you came back into the code.
Once the conflicts are fixed, if any, it will generate an additional merge commit to keep track of where you were when your code joined master’s.

git rebase

When you rebase, you’re basically playing with time. The result is as if you were coding from and into masters the whole time, except you were really coding off of your own branch. If you look at your tree after a git rebase, it doesn’t have any branches connected back into master because git rebase pretends as if you were "always" coding in master.

This means that when fixing conflicts, rebasing chooses your remote master version as the Queen of All Truth 👸🏻. It’s as if you’re changing the base of your code to be the base of the code found in your masters branch and it does not leave a merging commit because it acts as if it had been “there the whole time”.

Going deeper

Now, to my understanding, git’s superpower is keeping track of where we are at any given point thanks to us writing commits that mark specific moments to go back to if needed.

So, in my brain, I’ve never really understood why people would want to rebase and play git kong-fu rather than just merge and be on the safe of history. Playing with time like this had to be either contradictory or brilliant.

Indeed, what I hadn’t understood was that the reason why people use rebase instead of merging. Rebasing allows your codebase to be slimmer and have a cleaner overall history without any branches coming off of your linear tree.

With both git rebase and git merge, you can squash all your commits into one so that your codebase has only one commit per feature, but git merge will always produce that final merge commit that only fattens your code and provides no additional value.

And it makes sense. If you have 30+ developers working on the same code, and each is committing every step of their process, you will quickly have a fat and dirty codebase filled with random commits like 'fixed typo'. If you rebase and squash all your commits together, however, the result is a linear tree detailing every feature built and their code.

In practice

Setup

I’ll first create a random index.rb file and make sure git is initiated. This assumes you already have git in your computer connected to a remote repository somewhere. I’ll also create a branch for my first feature.

# Create file
mkdir music-app && touch index.rb    
# Initiate git   
cd music-app && git init    
# Creates github repo with the name of the folder (I’m in using the [hub gem](https://hub.github.com/)) 
hub create    
# Checkout of master and create a branch called bands4tonight    
git checkout -b bands4tonight

What we'll build?

I will create a small Ruby app that iterates over an array of my favorite bands and throws at me one by random.

bands = ['Incubus', 'Arctic Monkeys', 'Papooz', 'L’imperatrice', 'Poolside']    
puts bands.sample

I then go to the terminal to save up my progress. God forbid I lose my beautiful work.

# Check everything is as I expect    
git status    
# Adds everything to the bucket    
git add .    
# Commit my changes    
git commit -m 'program returns a sample band'    
# Push my code to bands4tonight branch    
git push origin bands4tonight

git kong-fu

At this point my code is found remotely in my branch. Great.

Meanwhile, let's say other developers are coding away features on different parts of the app, adding their favorite bands to the mix or just building new functionalities. I need to make sure I have the latest updated version of the code.

# Move to master branch
git checkout master
# Pull in locally the work the other devs have been doing
git pull 
# Move into my working branch
git checkout bands4tonight
# Make sure the code I just pulled in is now the base for my working code in my branch
git rebase master

Up until here, my working branch has the latest code from master and acts as if I was always there. Yes, that's exactly what we wanted!

The real trick happens as I keep on adding more code to my feature.

Let's say this week I’m obsessed with a new band (which I'd recommend checking out btw 😉). So I go back into index.rb and add it to my list.

bands = ['Incubus', 'Arctic Monkeys', 'Papooz', 'L’imperatrice', 'Poolside', 'Señor Loop']

Back in terminal, it's time to push my code to my remote branch to make the Pull Request.

git status
git add .
git commit --amend -m 'program returns a sample band'
git push -force

By writing git commit --amend -m ‘..’, I’m adding my new work on top of my latest commit and just moving it forward in the timeline.

This is great because:

1) It conveniently preserves the older versions inside my commit so I can go back in time if I need it.
2) It creates one commit per feature so that someone checking out the code base later on can easily see all the code where one feature is built.
3) It doesn't fatten the codebase with lots of commits, but rather only shows up the one where all code is seen together
4) It doesn't generate an extra merging commit it actually doesn't need.

Also important to note is that because I updated the commit, I am playing wizard with git's regular timeline. This means I have to force the push otherwise git won't allow it.

(Disclaimer here: I was afraid of forcing the push the first time I did it too. But a smart dev told me that at the end of the day, I was only working in my own local branch anyways so allll shall be fine under the Tuscan sun.)

And just like that, once our Pull Request is merged into master, you can run git log and see the clean, elegant timeline we've just created without any unnecessary merge commits.

Because at the end, your git tree is the only tree that is better off without leaves or branches. 🌳

Hope this was helpful :) spare some love if it was 💙