DEV Community: Albert Mulia Shintra

What is your thought process to develop the extendable application?

Albert Mulia Shintra — Tue, 02 Nov 2021 05:55:55 +0000

Hi devs!

I have a project that requires collaborative effort to build the application. The project codebase foundation should allow external developer to develop features without having to modify the foundation codebase.

A reference for similar application that provide such extension is like VSCode Editor, Canva, Figma, or even Browser Extension. Please kindly share other apps that you think is similar as well.

I appreciate any sharing or advice from your thought process to build this kind of application properly. Please leave me any feedback or questions if you need more detail. Thank you!

The Pragmatic Programmer highlighted points: Ch7. While We're Coding

Albert Mulia Shintra — Mon, 04 Jan 2021 17:55:56 +0000

Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

1. Listen to Your Lizard Brain

Our instincts, aka the lizard brain, are simply a response to patterns packed into our nonconscious brain. Whatever their source, instincts share one thing: they have no words.

The trick is first to notice it is happening, and then to work out why.

When you are coding, the code is trying to tell you something. It's saying that this is harder than it should be. Whatever the reason, your lizard brain is sensing feedback from the code, and it's desperately trying to get you to listen.

Listen to Your Inner Lizard

First, stop what you're doing. Give yourself a little time and space to let your brain organize itself. Eventually, they may bubble up to the conscious level, and you have one of those a ha! moments.

If that's not working, try to externalizing the issue by writing a doodle of your code, or talking to your coworker or the rubber duck. You may have moments when you're explaining the problem and suddenly realized something.

If it's still not coming, then it's time for action by creating a prototype. If you're working on existing code and it's pushing back, then stash it away somewhere and prototype up something similar instead. While prototyping, if that nagging doubt suddenly crystallizes into a solid concern, then address it.

Not just our code, but we also deal with existing code, often written by other people. If you can see what drove them to write code that way, you may find the job of understanding it becomes a lot easier.

2. Programming by Coincidence

We should avoid programming by coincidence, relying on luck and accidental successes, in favor of programming deliberately.

If we don't know why the code is failing because we didn't know why it worked in the first place.

If it worked, why should we take the risk of messing with something that's working? We can think of several reasons:

It may not be really working, it might just look like it is
The boundary condition you rely on maybe just an accident, as it might behave differently in different circumstances
Undocumented behavior may change with the next release
Additional and unnecessary calls make your code slower
Additional calls increase the risk of introducing new bugs

Human beings are designed to see patterns and causes, even when it's just a coincidence. Don't assume it, prove it.

Finding an answer that happens to fit is not the same as the right answer. Assumptions that aren't based on well-established facts are the bane of all projects.

3. Algorithm Speed

Pragmatic Programmers estimate their resources that algorithms use such as time, processor, memory, and so on.

Normally, the size of the input will affect the algorithm: the larger the input, the longer the running time or the more memory used.

We find that whenever we write anything containing loops or recursive calls, we subconsciously check the runtime and memory requirements.

The Big-O notation, written O(), is a mathematical way of dealing with approximations.

Big-O is never going to give you actual numbers for time or memory or whatever: it simply tells you how these values will change as the input changes.

Address the potential problems and try to find a better approach to improve the algorithm speed. Then, test your estimates to see if it improve.

You also need to be pragmatic about choosing appropriate algorithms, the fastest one is not always the best for the job. It's always a good idea to make sure an algorithm really is a bottleneck before investing your precious time trying to improve it.

4. Refactoring

Code needs to evolve; it's not a static thing. Rather than construction, the software is more like gardening, it is more organic than concrete.

Refactoring is defined by Martin Fowler as a:

disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior

The critical part of this definition is:

The activity is disciplined, not a free-for-all
External behavior doesn't change

In order to guarantee that the external behavior hasn't changed, you need good, automated unit testing that validates the behavior of the code.

You refactor when you've learned something when you understand something better than you did last year, yesterday, or even just ten minutes ago.

Refactor early, refactor often

Refactoring, as with most things, is easier to do while the issues are small, as an ongoing activity while coding. It shouldn't take a week to refactor, that's a full-on rewrite.

Martin Fowler offers simple tips to refactor without doing more harm than good:

Don't try to refactor and add functionality at the same time
Make sure you have good tests before you begin refactoring
Take short, deliberate steps, and test after each step to avoid prolonged debugging

5. Test to Code

Testing is Not About Finding Bugs

We believe that the major benefits of testing happens when you think about and write the tests, not when you run them.

Thinking about testing made us reduce coupling in our code and increase flexibility. Thinking about writing a test for our method made us look at it from the outside as if we're a client of the code, not the author.

We think this is probably the biggest benefit offered by testing: testing is vital feedback that guides your coding.

The basic cycle of TDD (Test Driven Development) is:

Decide on a small piece of functionality you want to add
Write a test that will pass once that functionality is implemented
Run all tests. Verify that the only failure is the one you just wrote
Write the smallest amount of code needed to get the test to pass, and verify it
Refactor your code: see if there's a way to improve on what you just wrote, and make sure the test is still passed when you're done

If you follow the TDD workflow, you'll guarantee that you always have tests for your code.

We like to think of unit testing as testing against contract. We want to avoid creating a "time bomb", something that sits around unnoticed and blows up at an awkward moment later in the project. By emphasizing testing against contract, we can try to avoid as many of those downstream disasters as possible.

Even the best sets of tests are unlikely to find all the bugs. This means you'll often need to test a piece of software once it has been deployed, with real-world data flowing through its veins.

Log files containing trace messages are one such mechanism. Another mechanism for getting inside running code is the "hot-key" sequence or magic URL, to show a debugging message on the fly. This isn't something you normally would reveal to end-users, but it can be very handy for the help desk.

Treat test code with the same care as any production code. Keep it decoupled, clean, and robust.

Testing, design, coding - it's all programming

6. Property-Based Testing

There could be incorrect assumptions while writing unit tests. The code passes the tests because it does what it is supposed to do, based on your understanding.

Once we work out our contracts and invariants, we can use them to automate our testing.

Use Property-Based Testing to Validate Your Assumptions

At this point, the book gives more concrete examples that a test may only cover commonly known scenarios and doesn't cater to bad assumptions. Thus we can improve the test by adding more property to test those assumptions.

One suggestion is that when a property-based test fails, find out what parameters it was passing to the test function, and then use those values to create a separate, regular, unit test.

We believe that property-based testing is complementary to unit testing: they address different concerns, and each brings its own benefits.

7. Stay Safe Out There

As a matter of fact, you do need to be paranoid as spies or dissidents, every day.

There are cases where hundreds of records stolen at once, billions of dollars in losses. It's not because the attackers were terribly clever or competent, it's because the developers were careless.

The next thing you have to do is analyze the code for ways it can go wrong and add those to your test suite.

The survival time of an unpatched, outdated system on the open net is measured in minutes, or even less.

Pragmatic Programmers have a healthy amount of paranoia. There are a handful of basic principles that you should always bear in mind:

a. Minimize Attack Surface Area

Simple, smaller code is better. Less code means fewer bugs, fewer opportunities for a crippling security hole.

Never trust data from an external entity, always sanitize it before passing it on to a database, view rendering, or other processing.

By nature, any user anywhere in the world can call unauthenticated services, so limit the opportunity for a DoS (Denial of Service) attack at the very least.

If an account with deployment credentials is compromised, your entire product is compromised.

Don't give away information that may reveal credential knowledge, for example: "Password is used by another user".

Make sure any testing window and runtime exception reporting is protected from spying eyes.

b. Principle of Least Privilege

Don't automatically grab the highest permission level, such as root or Administrator. If needed, then take it, do the minimum amount of work, and relinquish your permission quickly to reduce the risk.

c. Secure Defaults

The default settings on your app, or for your users on your site, should be the most secure values.

d. Encrypt Sensitive Data

Don't leave personally identifiable information, financial data, passwords, or other credentials in plain text.

e. Maintain Security Updates

You need that security patch, but as a side effect, it breaks some portion of your application. Don't decide to wait, apply security patches quickly.

8. Naming Things

Your brain treats written words as something to be respected. We need to make sure the names we use to live up to this.

There are only two hard things in computer science: cache invalidation and naming things.

It's important the everyone on the team knows what the common names are being used and that they use them consistently.

When you see a name that no longer expresses the intent, or is misleading or confusing, then fix it.

If for some reason you can't change the now-wrong name, then you've got a bigger problem: an ETC (Easy to Change) violation. Fix that first, then change the offending name.

Make renaming easy, and do it often.

This chapter is quite long but they are very insightful for us to be aware of while we're coding. What's the struggle you face while coding? Please share it in the comment section and I'll be happy to learn from you!

The Pragmatic Programmer highlighted points: Ch6. Concurrency

Albert Mulia Shintra — Sat, 12 Dec 2020 16:33:51 +0000

Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

Concurrency is when the execution of the two pieces of code act as if they run at the same time.

Breaking Temporal Coupling

Temporal Coupling happens when your code imposes a sequence of things that are not required to solve the problem at hand.

For example: Tick doesn't need to come before the tock if you want to stay flexible.

We need to allow for concurrency and to think about decoupling any time or order dependencies.

To find out what can happen at the same time, and what must happen in a strict order, we can use a notation such as the activity diagram.

The book gives a great example of the activity diagram by simulating the steps of preparing a Piña colada. Instead of running the step one by one, it can run some activities in parallel, like running the blender while preparing the glasses and the pink umbrellas.

source

When we're designing for concurrency, we're hoping to find activities that take time, but not time in our code.

2. Shared State Is Incorrect State

Imagine two customers looking at the last pie on the display case and both are calling the server at the same time. One of them is going to be ~~error~~ disappointed.

This could happen when the process of reading the state and retrieving the value is asynchronous. The problem here is that neither process can guarantee that its view of that memory is consistent.

This is all because fetching and then updating the pie count is not an atomic operation: the underlying value can change in the middle.

To make it atomic, we can consider using semaphore. A semaphore is simply a thing that only one person can own at a time. When both processes run at the same time, one of them will proceed while the other will be suspended until the semaphore becomes available again.

Not only shared state, but problems can also pop up anywhere where your code shares mutable resources: files, databases, external services, and so on. Whenever two or more instances of your code can access some resource at the same time, you're looking at a potential problem.

Random Failures are often Concurrency Issues

Most languages have library support for some kind of exclusive access to shared resources. You could also argue that functional languages, with their tendency to make data immutable, make concurrency simpler. However, they still face the same challenges, because at some point they are forced to step into the real, mutable world.

3. Actors and Processes

Actors and processes offer interesting ways of implementing concurrency without the burden of synchronizing access to shared memory.

An actor is an independent virtual processor with its own local (and private) state.

A process is typically a more general-purpose virtual processor, often implemented by the operating system to facilitate concurrency.

There are a few things that you won't find in the definition of actors:

There's no single thing that's in control
The only state in the system is held in messages and in the local state of each actor
All messages are one way, there's no concept of replying
An actor processes each message to completion, and only processes one message at a time

Use Actors For Concurrency Without Shared State

IN the actor model, there's no need to write any code to handle concurrency, as there is no shared state.

4. Blackboards

Imagine a murder case, and detectives are investigating the case by combining all the facts, statements, and clues in a single blackboard. As the data accumulate, a detective might notice a connection and post that observation as well. This process keeps going on until the case is closed.

Some key features of the blackboard approach are:

None of the detectives needs to know of the existence of any other detective
The detectives may be trained in a different background, but they're all towards the same goal to solve the case
Different detectives can come and go during the process
There is no restriction on what may be placed on the blackboard

Computer-based blackboard systems were originally used in AI applications where the problems to be solved were late and complex, such as speech recognition, knowledge-based reasoning system, and so on.

Use Blackboards to Coordinate Workflow

The actor and/or blackboard and/or microservice approach to architecture removes a whole class of potential concurrency problems from your applications, but that benefit comes at a cost. These approaches are harder to reason about because a lot of the action is indirect.

You'll find it helpful to keep a central repository of message formats and/or APIs, particularly if the repository can generate the code and documentation for you. You'll also need good tooling to be able to trace messages and facts as they progress through the system.

Did you face a conflict state problem in your application before? Any bugs you traced are hard to reproduce or randomly occurred? Hopefully, the concept of Concurrency helps to address the issue better. Please leave your comment if you experienced one, I would be happy to learn as well!

The Pragmatic Programmer highlighted points: Ch5. Bend or Break

Albert Mulia Shintra — Mon, 07 Dec 2020 18:26:04 +0000

Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

1. Decoupling

Coupling is the enemy of change because it links together things that must change in parallel.

Decoupled Code is Easier To Change

Here are some symptoms of coupling:

Wacky dependencies between unrelated modules or libraries
"Simple" change to one module break stuff elsewhere in the system
Developers are afraid to change code because they aren't sure what might be affected
Meetings where everyone has to attend because no one is sure who will be affected by a change

One way to look at this is to think about responsibilities. The fix for that is to apply something we call:

Tell, don't Ask

The principle says that you shouldn't make decisions based on the internal state of an object and then update the object.

The book also recommends us to not chain method calls, unless the things you're chaining are really unlikely to change. But in practice, anything in your application should be considered likely to change.

Another coupling issue is also due to globalization, as globally accessible data is an insidious source of coupling between application components. When you make code reusable, you give it clean interfaces, decoupling it from the rest of your code.

If you have a singleton with a bunch of exported instance variables, it's still just global data, with a longer name. You can still make a singleton by hiding all the data behind methods. For example, instead of Config.log_level, it could be Config.getLogLevel()

2. Juggling the Real World

We'll start off with the concept of an event.

Whatever the source, if we write applications that respond to events, and adjust what they do based on those events, those applications will work better in the real world.

These are the recommended four strategies:

a. Finite State Machine (FSM)

A state machine is basically just a specification of how to handle events. The neat thing about FSM is that we can express them purely as data.

State machines are underused by developers, and we'd like to encourage you to look for opportunities to apply them.

If you're familiar with Javascript, my personal recommendation will be to go through this workshop.

b. The Observer Pattern

In the observer pattern, we have a source of events, called the observable and a list of clients, the observers. who are interested in those events.

The observer/observable pattern has been used for decades, and it has served us well. But the observer pattern has a problem: because each of the observers has to register with the observable, it introduces coupling. This is solved by the next strategy, Publish/Subscribe

c. Publish/Subscribe (Pubsub)

Pubsub generalizes the observer pattern, at the same time solving the problems of coupling and performance.

The downside is that it can be hard to see what is going on in a system that uses pubsub heavily since you can't look at a publisher and immediately see which subscribers are involved with a particular message.

d. Reactive Programming, Streams, and Events

It's clear that events can also be used to trigger reactions in code, but it isn't necessarily easy to plumb them in. That's where streams come in.

The current de facto baseline for reactive event handling is defined on the site http://reactivex.io, which defines a language-agnostic set of principles and documents some common implementations. In Javascript, we can use RxJs library.

Event streams unify synchronous and asynchronous processing behind a common, convenient API.

3. Transforming Programming

We need to get back to thinking of programs as being something that transforms inputs into outputs.

Programming is about code, but Programs are about Data

Sometimes the easiest way to find the transformations is to start with the requirement and determine its inputs and outputs.

If you're familiar with |> operator which sometimes called a forward pipe or just a pipe, then using it means that you're automatically thinking in terms of transforming data.

If your background is OOP, then your reflexes demand that you hide data, encapsulating it inside objects. This introduces a lot of coupling, and it's a big reason that OO systems can be hard to change.

Don't Hoard State; Pass It Around

To manage Error Handling during the state transformations, there are two basic ways of writing the code: you can handle checking for errors inside your transformations or outside them.

Thinking of code as a series of (nested) transformations can be a liberating approach to programming.

4. Inheritance Tax

If you use inheritance, stop! It probably isn't what you want to do.

Inheritance is coupling. Not only the child class coupled to the parent, the parent's parent, and so on, but the code that uses the child is also coupled to all the ancestors.

Here are the suggestions that can help you to never need to use inheritance again:

a. Interfaces and Protocols

Using interfaces create no code since it simply says that any class that implements the interface must implement the methods defined, but doesn't dictate how the code should be written.

Interfaces and protocols give us polymorphism without inheritance.

b. Delegation

By using delegation, we can split the class methods to not rely on the parent class API. We can either write the method directly in the class or take a step further to create another class that delegates the method that is related to the class.

c. Mixins, Traits, Categories, Protocol Extensions

The basic idea of mixins is simple: we want to be able to extend classes and objects with new functionality without using inheritance.

The implementation of mixins can vary between languages. The important thing is the capability that all these implementations have: merging functionality between existing things and new things.

5. Configuration

When code relies on values that may change after the application has gone live, keep those values external to the app.

Parameterize Your App using External Configuration

Some things you will probably want to put in configuration data:

Credentials for external services
Port, IP address, machine, cluster names
Environment specific validation parameters
License keys

To access the configuration, the book suggests wrapping the configuration information behind a (thin) API. This decouples your code from the details of the representation of the configuration.

The benefits of storing configuration behind a service API:

Multiple applications can share configuration information
Configuration changes can be made globally
Configuration data can be maintained via a specialized UI
Configuration data becomes dynamic

That last point is critical as we move toward highly available applications. The idea that we should have to stop and restart an application to change a single parameter is hopelessly out of touch with modern realities. When configuration values change, there's no need to rebuild the code.

What's your experience to keep your code easy to change, and configurable? Please share your journey and I'll be happy to respond. Thank you!

The Pragmatic Programmer highlighted points: Ch4. Pragmatic Paranoia

Albert Mulia Shintra — Mon, 30 Nov 2020 16:31:22 +0000

Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

Intro

Before moving to the section, this is the first tip to be given:

You Can't Write Perfect Software

Knowing that no one writes perfect code, including themselves, Pragmatic Programmers build in defenses against their own mistakes.

1. Design By Contract (DBC)

What is the correct program? One that does no more and no less than it claims to be.

The function shall have the expectation, as described by Meyer:

Preconditions: The routine requirements.
Postconditions: The guaranteed statement when the routine is done.
Class invariants: The condition is always true from the perspective of a caller.

The contract between a routine and any potential caller can be read as:

If all the routine's preconditions are met by the caller, the routine shall guarantee that all postconditions and invariants will be true when it completes.

Note: I still don't really get the meaning of the class invariants. I assume it was about the variable we passed on to the function, should not be mutated to a different type or interface. CMIIW

In any programming language, whether it's functional, object-oriented, or procedural, DBC forces you to think.

By not implementing DBC in your function, you are back to programming by coincidence which is where many projects start, finish, and fail.

You can implement the contract in your code by writing an Assertion. By having it, you can crash early and report more accurate information about the problem.

You can use semantic invariants to express inviolate requirements, a kind of "philosophical contract*.

The example given is about validating the same payment transaction should not happened twice. The contract would be, no matter what failure it might happen, the error should be on the side of not processing a transaction, rather than processing a duplicate transaction.

2. Dead Program Tell No Lies

It's easy to fall into the "it can't happen" mentality. When that really happens, Pragmatic Programmers tell themselves that something very, very bad has happened.

That's one reason why each and every case/switch statement needs to have a default clause, to detect when the "impossible" has happened.

When it happens, Read the Damn Error Message.

If you try to use a lot of try...catch to run a function, the Pragmatic Programmer would prefer to just run it directly. Two reasons:

The application code isn't eclipsed by the error handling
The code is less coupled

One of the benefits of detecting problems as soon s you can is that you can crash earlier, and crashing is often the best thing you can do.

When your code discovers that something that was supposed to be impossible just happened, your program is no longer viable.

3. Assertive Programming

"The count can't be negative"
"Logging can't fail"
"This can never happen...*

Let's not practice this kind of self-deception, particularly when coding. Instead, add code to check it. The easiest way to do this is with assertions.

The assertion is to check a condition that should never happen. Make sure the assertion method itself doesn't do any side effects that might create new errors.

A common misconception about assertions:

Assertions add some overhead to the code. If the code has been tested and shipped, the assertion shouldn't be needed because they check for things that should never happen.

The assumption above is wrong because.

Testing might not find all the bugs.
The production environment could be different from the testing environment

If you do have performance issues from your assertion, turn off only those assertions that really hit you.

4. How to Balance Resources

Finish What You Start

It simply means that the function or object that allocates a resource should be responsible for deallocating it.

An example of this case could be: When you run a function that uses and rewrite a global variable, make sure that you are aware of it and update or reset the value back to what it supposed to be.

The more surefire way to handle it is to avoid global or shared variable across functions, and "Act Locally" by scoping the variable and pass it around as a function parameter.

Because Pragmatic Programmers trust no one including themselves, it is always a good idea to build code that actually checks that resources are indeed freed appropriately.

5. Don't Outrun Your Headlights

We can't see too far ahead into the future, and the further off-axis you look, the darker it gets. So Pragmatic Programmers have a firm rule:

Take Small Steps. Always

What is a task that's too big? Any task that requires "fortune-telling". An example of fortune-telling:

Estimate completion dates months in the future
Plan a design for future maintenance or extendability
Guess the user's future needs
Guess future tech availability

When we're supposed to design for future maintenance, only to the point as far ahead as you can see.

The more you have to predict the future, the more risk that you'll be wrong. Instead, make it easy to throw out your code and replace it with something better suited.

What are your paranoia during development? Have you been in a situation where your code breaks unexpectedly? Have you been trying to predict the future of your software and how far it can go? Please share your experience and feedback, and I would like to learn from you as well. Thanks for reading!

The Pragmatic Programmer highlighted points: Ch 3, The Basic Tools

Albert Mulia Shintra — Sun, 22 Nov 2020 17:23:17 +0000

Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

1. The Power of Plain Text

As Pragmatic Programmers, our base material is knowledge. The best format to store knowledge persistently is plain text, so that we can manipulate it with different tools. Example of plain text: "milk" (my favourite drink 😉).

Plain text doesn't mean it's unstructured: HTML, JSON, YAML and so are all plain text.

Human-readable forms of data, and self-describing data, will outlive all other forms of data and the applications that created them.

2. Shell Games

For a programmer manipulating files of text, that workbench is the command shell. Yes, it's the tool that you see a lot in the blockbuster movies when someone's hacking the enemy base.

For programmers raised on GUI interfaces and IDEs (like me!), this might seem an extreme move. After all, can't you do everything equally well by pointing and clicking?

The simple answer is "no". A benefit of GUI is "What You See Is What You Get", and the disadvantage is "What You See Is All You Get".

Gain familiarity with the command shell, and you'll find your productivity soaring. Once you do, you should customize your shell to suit your needs. Some common customization:

Setting color themes
Configuring a prompt
Aliases and shell functions
Command completion

3. Power Editing

Choose and use as many editors as you want, and Achieve Editor Fluency. You may gain more time to spend if you improve your code editing process.

What does "Fluent" mean? Find your way if you can code without using a mouse/trackpad because you can keep your hands on the keyboard with all the shortcuts you know to navigate around.

To move towards fluency, check if you are doing something repetitive, get into the habit of thinking "there must be a better way". Then find it, and practice it to become your muscle memory.

Grow your editor by digging into the extension that may help you. If not, try to write it yourself.

4. Version Control

Version control systems keep track of every change you make in your source code and documentation.

It does far more than undoing mistakes. It can also track changes in detail, such as the code author, the time, the files, the lines of code. They are invaluable for bug-tracking, audit, performance, and quality purposes.

One of the most powerful and useful features is the branch, to isolates your work until it's ready to be merged into the main code.

With version control, you can always roll it back if something happens. Learn them now, not when the disaster strikes and you are under pressure.

5. Debugging

No one writes perfect software, so it's a given that debugging will take up a major portion of your day.

Embrace the fact that debugging is just problem solving, and attack it as such. It doesn't really matter whether the bug is your fault or someone else's. Fix the Problem, Not the Blame.

The first rule of debugging: Don't Panic.

Always try to discover the root cause of a problem, not just the particular appearance of it.

To improve the accuracy of the bug report, you may actually need to watch the user who reported the bug in action to get more detail.

To discover the bug better, you must brutally test your application with a realistic end-user usage pattern. The best way to start fixing bugs is to make it reproducible.

The most important rule of debugging: Have the failing test before fixing code.

To isolate the bug, look at the problem. Read the Damn Error Message (yes, the book highlights it clearly).

You can eliminate the culprit faster by doing the "binary chop". Choose a stack frame somewhere in the middle and see if the error is manifest there.

(personal tips: With git, you can use bisect to do the "binary chop")

Diagnosis your code with Logging and/or Tracing, by adding custom messages around the suspected codebase to print the valuable information in your screen or development console.

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. By explaining, you need to think step by step and you may gain new insights into the problem. If you're alone, use the rubber duck.

When faced with a "surprising" failure, you must accept that one or more of your assumptions is wrong. Don't just assume the cause, but prove it.

6. Text Manipulation

Learn a Text Manipulation Language. These languages are important enabling technologies.

Using them, you can quickly hack up utilities and prototype ideas, which may take five or ten times longer with conventional languages.

Some examples of Text Manipulation Language are Perl, Python, and Ruby.

One of the challenges: Write a program that converts YAML to JSON format.

7. Engineering Daybooks

Pragmatic Programmers use daybooks to take notes in meetings, to jot down what we're working on, note debugging process, leave reminders, wild ideas, or just doodle.

Three main benefits:

It is more reliable than memory.
Store ideas that may not immediately relevant.
It acts as a kind of rubber duck.

Use paper, not a file or a wiki. There's something special about the act of writing compared to typing. Try a month and see if you're getting any benefits.

What do you think of your current programming tools? Please share your thoughts in the comment and I'll be happy to respond!

The Pragmatic Programmer highlighted points: Ch 2, A Pragmatic Approach

Albert Mulia Shintra — Sun, 15 Nov 2020 18:06:56 +0000

Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

1. The Essence of Good Design

Good Design is easier to change than Bad Design. Thus, we believe in the ETC principle: "Easier To Change".

ETC is a Value, not a Rule. It is a guide to help you make decisions. It requires some initial conscious reinforcement, by keep asking yourself during development, "Is it easier or harder to change?"

Two way to validate if your code is ETC:

Try to make what you write replaceable, to make sure it won't become a roadblock in the future
Note the situation and choice you made, to reflect back on when you need to revisit the code

2. DRY - The Evils of Duplication

Programmers are constantly in maintenance mode. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process.

To develop reliable software, easier to understand and maintain, is to follow the DRY principle:

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

These are the problems of duplication along with the general suggestion:

DRY is More Than Code

DRY is not just to avoid copy-pasting code, but it is about the duplication of knowledge or intent. When a part of the code logic needs to change, and the changes apply to different places, it means your code is not DRY.

Duplication in Code

Not all code duplication is knowledge duplication. If there are two functions that do similar things but each has a different intent or purpose, then they are still DRY.

Duplication in Documentation

When you comment on a function with the details of how the function works, then the comment is a duplication of the code. The name of the function should already say what it does, and the details are laid out in the source code.

DRY Violations in Data

A data structure represents knowledge and it may have duplicated data. Where possible, always use accessor functions to read/write the attributes of objects to decouple the data structure from the implementation module.

Representational Duplication

Your code interfaces to the outside world. If the interface change, the other code that uses it may break. This duplication is inevitable but can be mitigated. Find tools that help you standardize and document your API to be shared across teams.

Interdeveloper Duplication

Perhaps the hardest type of duplication to detect and handle. We feel that the best way is to encourage active and frequent communication between developers. Make the code easy to reuse. If it isn't, people won't do it, thus risk duplicating knowledge.

3. Orthogonality

In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others.

These are the benefits of Orthonogality:
- Gain Productivity: Reduce development and testing time since changes are localized, promote reusability, and composable.
- Reduce Risk: The code is isolated. Make any changes and it only affects that area if there is a bug.

Several techniques to maintain orthogonality:

Keep your code decoupled
Avoid global data
Avoid similar functions

An orthogonally designed and implemented system is easier to test. Writing unit test is itself an interesting test of orthogonality, to validate what does it takes to build and run the module.

3. Reversibility

We don't always make the best decisions the first time around. The mistake lies in assuming that any decision is final, and not preparing the uncertainties that might arise.

Make your code easy to change. Build abstraction layers. Break your code into components.

4. Tracer Bullets

The principle applies to projects when you're building something that hasn't been built before, to build a software that can be tested for immediate feedback while moving towards a goal.

Look for the areas where you have doubts and the biggest risk, and prioritize it during development.

Tracer code is not disposable, you write it for anticipating the production code.

Advantages of the tracer code:

Users get to see something working early
Developers build a structure to work in
You have an integration platform
You have something to demonstrate
You have a better feel for progress

Tracer code may not always hit their target. Make sure your tracer code is easy to change, to be validated based on feedback, and keep improving to generate a more accurate version of the code quickly.

Tracer code is not Prototyping. Prototyping generates disposable code. Tracer code is lean but complete and forms part of the skeleton of the final system.

5. Prototypes and Post-It Notes

Prototyping is much cheaper than full-scale production. It is meant to analyze and expose risk, and make corrections at a greatly reduced cost.

We tend to think of prototypes as code-based, but it does not always have to be.

Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned.

Details to ignore in the prototyping:

Correctness
Completeness
Robustness
Style

You must make it very clear that the prototype code is disposable, incomplete, and unable to be completed. This avoid the stakeholder to think that the prototype is ready for production use.

6. Domain Languages

In some cases, Pragmatic Programmers can go to the next level and actually program using the vocabulary, syntax, and semantics of the domain.

7. Estimating

Estimate to avoid surprises. By learning to estimate, you will be able to show a magical ability to determine the feasibility of the task/project.

All estimates are based on models of the problem. A basic estimating tricks that always gives good answers: ask someone who's already done it.

You may able to give estimation in two way:

Give the optimistic, most likely, and the pessimistic estimate
Give initial estimated time, and update the schedule on every development iteration

When asked, you don't have to give your estimation directly. Spend some time going through the mental model for better accuracy.

I would love to read your sharing of your approach as well. Please leave a comment and I'll be happy to respond. Thank you!

The Pragmatic Programmer highlighted points: Ch 1, A Pragmatic Philosophy

Albert Mulia Shintra — Sun, 08 Nov 2020 15:47:05 +0000

Disclaimer

This article is just highlighting the tip of the iceberg from the original book. Please read the book for better detail and examples given by the author.

1. It's Your Life

Software development appears close to the top list of careers where you have control. If you're frustrated with your current environment, try to fix it.

This industry gives you a remarkable set of opportunities. Be proactive, and take them.

2. The Cat Ate My Source Code

Pragmatic Programmers take charge of their own careers and aren't afraid to admit ignorance or error. We can be proud of our abilities, but we must own up to our shortcomings as well.

Team Trust

Trust in a team is absolutely essential for creativity and collaboration.

Take Responsibility

When you accept the responsibility for an outcome, expect to be held accountable for it. When you make a mistake, admit it honestly. Provide options, instead of blaming or making excuses.

3. Software Entropy

Entropy is a term from physics that refers to the amount of "disorder" in a system. Disorder in software is usually caused by "technical debt". Don't leave them unrepaired.

If you find yourself on a project where the code is cleanly written and well-designed, you'll likely take extra care to not mess it up.

4. Stone Soup and Boiled Frogs

If you are in a situation where you know what needs to be done and how to do it, you may get "start-up fatigue" when you need to wait for permission, budget, or resources to do it.

Instead, start with what you can already do and develop it. Once you've got it, show it to others and let them be excited and foster the idea further.

On the other side, keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.

5. Good Enough Software

As Ed Yourdon described in an article in IEEE Software, "When good enough software is the best, you can discipline yourself to write software that's good enough. Good enough for your users, future maintainers, and your own peace of mind".

Involve Your Users in the Trade-Off

Understand the requirement from different constraints. Marketing deadlines, delivery schedule, key features should be discussed as part of the development process, among the software quality to ensure everyone's expectations are met.

Often times, trade-offs are involved. Focus on the minimum deliverables that your user can play with to get their early feedback.

Know When To Stop

Don't spoil your good program by overengineering and overrefinement.

6. Your Knowledge Portofolio

Investment in knowledge always pays the best interest, but they're expiring assets, as it may be out of date.

Build your portfolio by these guidelines:

Invest Regularly: You must invest your knowledge portfolio regularly, even if it's just a small amount.
Diversify: The more different things you know, the more valuable you are.
Manage Risk: Don't put all your technical eggs in one basket.
Buy Low, Sell High: Learn an emerging technology before it becomes popular.
Review and Rebalance: You may revisit the technology you investigated before.

Here is the suggestion for you to build your portfolio:

Read a technical book each month
Read non-technical books, too
Take classes
Participate in the community around you
Experiment with different environment
Stay up to date with the current trend

Opportunities for Learning

If you're asked a question that you don't know the answer to, don't stop there. Take it as a personal challenge to find the answer. Search the answer, or ask someone who can help you.

Critical Thinking

The last important point is to think critically about what you read and hear. Few question you can ask and think about:

Why, why, why, why, and why? (The Five Whys)
Who does this benefit?
What's the context?
When or Where would this work?
Why is this a problem?

7. Communicate!

As a developer, we have to communicate on many levels. Here is a list of ideas for useful communication:

Know Your Audience: Understand the needs, interests, and capabilities of your audience. Gather their feedback as well.
Know What You Want To Say: Plan what you want to say. Plan an outline, review it yourself, and refine it until you believe it fits your audience.
Choose Your Moment: Sometimes all it takes is the simple question, "Is this a good time to talk about ...?"
Choose A Style: Adjust your style to suit your audience, be it formal, just the facts, or long discussion.
Make It Look Good: Use styles, visual, and spelling-check to convey your audience better.
Involve Your Audience: If possible, give your drafts to your audience and get their feedback. Build a relationship with them.
Be a Listener: If you want people to listen to you, listen to them.
Get Back to People: Keep your audience informed makes them feel that you haven't forgotten them.
Documentation: Pragmatic Programmers embrace documentation as an integral part of the overall development process.

Do you find this article helpful for you? Any feedback to make it better? Please leave a comment and I'll be happy to respond. Thank you!

The Pragmatic Programmer highlighted points: Intro and Preface

Albert Mulia Shintra — Sun, 08 Nov 2020 15:46:44 +0000

Intro

Heya!

I have been wanting to do this for quite some time and I finally take the courage to start typing this. It begins when my current company, Piktochart bought The Pragmatic Programmer 20th Edition for the developers. I am not a reader by nature, but this book has been recommended and stays relevant to the developer community for 20 years, so I'm tempted to read it myself.

While reading, I found there are a lot of points that I find very true and useful. Thus, I believe that highlighting those points may help me to remember more!

And this is the reason behind me for writing this post, to share the highlighted points and hopefully, it's useful for you. (And thanks for reading my intro in the first place!)

ps: The post will be separated by the chapters, from 1 to 9. I will post a new chapter every week, so stay tuned!

Disclaimer

The highlighted points that I wrote here are based on "The Pragmatic Programmer 20th Anniversary Edition" Version: P1.0, September 13, 2019. The points that I picked are based on my subjectivity and experiences.

Some people also have written the summary as well out there, for example: https://github.com/HugoMatilla/The-Pragmatic-Programmer

The summary here is just the tip of the iceberg from the original book as there are more details and examples not mentioned. Please support and buy the original book for the full overview.

If the publisher finds this inappropriate, please email me at chenxeed@gmail.com and I will unpublish this article at will.

Preface

This book will help you to become a better programmer. It isn't theoretical, but more on practical topics. This book is about doing.

Programming is a craft. There is no best solution. Don't just stick to any particular technology but have a broad enough background and experience base to allow you to have more options in particular situations.

Who should read this book?

This book is aimed at those who want to become more effective and productive programmers.

What makes a pragmatic programmer?

These are the characteristics:

Early Adopter: You love trying things out, and able to grasp it quickly.
Inquisitive: You tend to ask questions to clarify the facts
Critical Thinker: You rarely take things without first getting the facts and challenges it
Realistic: You understand the nature of the problem and how much effort it will take
Jack of all trades: You're familiar with a broad range of technologies and environments

Apart from the characteristic above, these are the most basic:

Care about your craft: Make sure you are doing it well
Think! About your work: Always think what you are doing

Individual Pragmatists, Large Teams

Within the overall structure of a project, there is always room for individuality and craftsmanship.

It's a Continuous Process

Every day, work to refine the skills you have and to add new tools to your projects.

Thanks for reading, I would like to know your feedback if you find this post interesting, or if you have any suggestion to make it better. See you in the next post!

Consider Vue Composition API to improve the code quality

Albert Mulia Shintra — Mon, 27 Jul 2020 14:58:31 +0000

Heya!

I have been working and prototyping with Vue Composition API for a while since the Vue 3 beta released on March. I would like to share some good experience I have while using it, for your reference if you're planning to use the new Vue 3, or migrate from Vue 2. Here we go!

note: the code example are based on the new Vue 3 convention

1. No more `this` instance

As a Javascript Developer, we may have to deal with this variable for quite some scenario due to the JS common behavior of inheriting the object or class instance. One of the common quirks you will face is:

"In most cases, the value of this is determined by how a function is called (runtime binding). It can't be set by assignment during execution, and it may be different each time the function is called." - MDN

You may face the similar situation while writing Vue with the object based properties, since the this instance is very tight to the concept of Vue inheriting its object properties, and the root prototypes. This is the example of a component called my-counter, that should increment the count value by clicking the "Add" button, or press the key + from your keyboard.

<template>
  <div>Count: {{ count }}
    <button @click="incrementCount">Add</button>
  </div>
</template>
<script>
export default {
  name: 'my-counter',
  data () {
    return {
      count: 0
    }
  },
  mounted () {
    // register keyboard event to listen to the `+` key press
    document.addEventListener('keydown', function(e) {
      if (e.keyCode === 187) { // 187 is keyCode for `+`
        this.incrementCount()
      }
    })
  },
  methods: {
    incrementCount () {
      this.count += 1
    }
  }
}
</script>

It looks fine and simple. Notice that the this in the method, it contains the .count value from the data we defined before. But also, this contains more than that. It also contains the Vue root instance, the plugin installed (vuex, router, etc), $attrs, slots, and more.

Did you see there's a bug in the code above? If yes, good eye! There is an error on pressing the + key from your keyboard, saying that:

Uncaught TypeError: this.incrementCount is not a function

This is because the callback function of the event listener is bound to the instance of the document, not the Vue component. This can be easily solved by changing the function method to arrow based function, but beginner developer may not realize it earlier, and they have to understand the inheritance concept of JS to get used to this.

Okay, sorry for the long post 🥔 to explain the basic quirk of this, now let's jump into Composition API!

In the Composition API, it has no reliance to the this instance. Everything is done in the setup phase, which consist of creating the data and methods of your component. Here's the example of Composition API based on the my-counter component above:

<template>
  <div>Count: {{ count }}
    <button @click="incrementCount">Add</button>
  </div>
</template>
<script>
import { reactive, toRefs, onMounted } from 'vue'

export default {
  name: 'my-counter',
  setup () {
    const data = reactive({
      count: 0
    })

    const incrementCount = () => data.count++

    onMounted(function () {
      document.addEventListener('keydown', function(e) {
        if (e.keyCode === 187) { // 187 is keyCode for '+'
          incrementCount()
        }
      })
    })

    return {
      ...toRefs(data),
      incrementCount
    }
  }
}
</script>

Let's compare the difference. Before, you rely on the object property data to register the state count, and methods to register the function to increment the count. The methods rely on this instance to access the count value.

After refactored into the Composition API, the functionality are all wrapped under setup to initiate the data, create a function to mutate the count, and also attach keyboard event listener. No more quirks on this value, so either normal or arrow function is not a problem anymore!

2. Better code splitting management

With the Composition API example above, we can see that now we don't have to follow the Vue convention to write the component functionality to separated properties (lifecycle hooks, data, methods, computed, watch), as everything can be composed as one function in the setup.

It opens the chance for us to split our code if we want to organize the code better, especially when the component functionality is complicated. We can write all the functionality under the setup, or we can also create a JS file to scope specific functionality to other file.

Let's take the example from the my-counter component. What if we want to split the functionality to attach the keyboard event separately?

// keyboard-event.js
import { onMounted } from 'vue'

export function usePlusKey (callbackFn) {
  onMounted(function () {
    document.addEventListener('keydown', function(e) {
      if (e.keyCode === 187) { // 187 is keyCode for '+'
        callbackFn()
      }
    })
  })
}

Now, we can import and use this function to the setup:

import { reactive, toRefs } from 'vue'
import { usePlusKey } from './keyboard-event' 

export default {
  name: 'my-counter',
  setup () {
    const data = reactive({
      count: 0
    })

    const incrementCount = () => data.count++

    usePlusKey(incrementCount)

    return {
      ...toRefs(data),
      incrementCount
    }
  }
}

You may argue if it's important or not to split the keyboard listener function above, but I hope you get the idea that it's up to you to manage your code and the Composition API give you easier way to handle it. Another advantage that you see above, is that the lifecycle hook of the component can be defined separately!

If you need to handle multiple scenario on mounted, now you can split them. For example:

// my-component.vue
mounted () {
  this.initPayment()
  this.initTracking()
},
methods: {
  initPayment () { /* init payment */ },
  initTracking () { /* init tracking */ }
}

With the Composition API:

// my-component/payment.js
export function initPayment () {
  onMounted(() => { /* init payment */ })
}

// my-component/tracking.js
export function initTracking () {
  onMounted(() => { /* init tracking */ })
}

// my-component.vue
import { initPayment } from './payment'
import { initTracking } from './tracking' 

setup () {
  initPayment()
  initTracking()
}

3. Function Reusability

With the example above, we can see the potential that the function is not only meant for one component only, but can also be used for others!

The reusability concept is similar to mixins. However there's a drawback of mixins, which is explained here. In short, naming collision and implicit dependencies are a "hidden bug" that can bite you when you're using it carelessly.

With the Composition API, these two concern are ~~gone~~ less likely to happen since the composition API function need to explicitly define the value it needs as a function parameter, and the variable name of the return value.

Let's see the example of a mixin of counter functionality:

// mixin/counter.js
const mixinCounter = {
  data () {
    return {
      counter: 0
    }
  },
  methods: {
    increment () {
      this.counter++
    }
  }
}

Using this mixin, we have to be considerate that it may overwrite the existing counter data and increment methods in the component it installed. This is what it means by "implicit dependencies".

If we convert it to the Composition API:

// compose/counter.js
import { ref } from 'vue'
export function useCounter () {
  const counter = ref(0)
  const increment = () => counter.value++
  return {
    counter,
    increment
  }
}

Using this function, it explicitly return counter and increment and let the component setup to decide what to do with it. If by chance the name counter/increment is already used or you need to use it multiple times, then we can still fix it by rename the variable like this:

// use default counter and increment name
const { counter, increment } = useCounter()

// since counter and increment already exist,
// rename it to countQty and incrementQty
const { counter: countQty, increment: incrementQty } = useCounter()

Cool! Perhaps one consideration here is, you need some extra time to bike shedding on deciding the new name of the variable 😅.

4. More control of the Typescript interface

Are you using typescript to type your component interface properly? If yes, great!

From the official docs, Vue has provided basic typescript support with Vue.extend, or using vue-class-component to write the Vue component as a class, leveraging the this instance to type the data and methods properly.

Refer back to the 1st point if we want to escape the this quirks and still have strong typing interface, then the Composition API is a good choice.

First, setup is a pure function that takes the input parameter to replace the needs of using this to access the component props and the context attrs, slots, and emit.

Then, all the data and function you wrote in the setup, is up to you to type it 😍! You can write and type your code without having to abide to the Vue way of defining things like data, methods, refs, computed and watch.

Here's the example of a typed Vue component:

// we use Vue.extend in vue v2.x
export default Vue.extend({
  data () {
    return {
      count: 0
    }
  },
  computed: {
    multiplyCount () {
      return this.count * 2
    }
  },
  methods: {
    increment () {
      this.count++
    }
  },
  watch: {
    count (val) { // `val` type is `any` :(
      console.log(val) 
    }
  }
})

In this example, we rely on the Vue.extend to automatically type the component interface. The this.count on the computed multiplyCount and method increment will have the proper typing from the data, but the watcher count will not be typed 😕.

Let's see how it's written in the Composition API:

// in vue 3.x, we use defineComponent
export default defineComponent({
  setup () {
    const count = ref(0) // typed to number
    const multiplyCount = computed(() => count.value * 2 )
    const increment = () => count.value++
    watch(count, val => console.log(val)) // `val` is typed to number
    return {
      count,
      multiplyCount,
      increment
    }
  }
})

The typing here is more explicit and predictable. You can customize the typing too if you need too, means that you are in control over the interface!

Conclusion

And that's all of my insight for you to consider using the Vue Composition API!

I believe there's a lot more potential in the Composition API, so please share your feedback about your experience or what do you think about it! Any tips to improve will be appreciated too 😍

I would like to highlight as well that the Composition API is not a silver bullet and you don't have to refactor your component to the Composition API if you don't see a benefit of it, or your component is pretty simple.

Thank you and have a great day!

Be prepared to migrate your Vue app to Vue 3

Albert Mulia Shintra — Sun, 12 Jul 2020 16:04:48 +0000

Heya!

In this post, I would like to share my recent experience of trying out Vue 3 beta version, specifically regarding some caveats you might want to note if you are planning to migrate your existing Vue 2 application to the upgraded version, Vue 3!

The list below are going to help you to move towards Vue 3 best practices, and also to avoid some use-case in Vue 2 that you might going to have trouble with, if you're migrating to Vue 3.

Let's get it on!

Avoid using Vue Event Bus

Short summary: Don't use $on / $once / $off API since it'll be deprecated in Vue 3.

If you have heard of Event Bus, it's a common term used in the Vue development whenever you're facing a situation where you need to make a shortcut to emit event from a child to parent, or vice versa. You can simply search "vue event bus" in your browser, and you'll find a lot of article explaining it.

One thing to note is that, it's not the official method recommended by Vue 🤯. Why I'm saying this, it's because you'll likely never see Event Bus mentioned in the official Vue docs. The closest reference is from the migration guide from Vue 1.x, in which it's called "eventHub" there, and it recommends you to use Vuex instead.

This pattern can serve as a replacement for $dispatch and $broadcast in simple scenarios, but for more complex cases, it’s recommended to use a dedicated state management layer such as Vuex.

You can check the RFC docs as well to see why they don't recommend it.

Since Event Bus concept is practically a Publish-Subscribe pattern which is a common method in programming, you can actually still use the concept, but with different libraries like mitt. 😉

This is the example of Event Bus, and how to refactor it:

// Vue 2 example of event bus
import Vue from 'vue';
const eventBus = new Vue();

// subscribe
eventBus.$on('sandwich-made', () => console.log('sandwich made!'));

// publish
eventBus.$emit('sandwich-made');

// Refactor to use 3rd party library like mitt
import mitt from 'mitt';
const eventBus = mitt();

// subscribe
eventBus.on('sandwich-made', () => console.log('sandwich made!'));

// publish
eventBus.emit('sandwich-made');

Refactor your Filter functions to Method

Based on the RFC docs, filter are going to be removed.

Filter was there to help you "format" your value, for ex: to uppercase, add currency, short url, etc. Perhaps it's also inspired by Angular Filter. It looks nice since you can implement it in your template syntax. For example, here's a filter toCurrency to add currency format to the price integer value:

<div class="currency">{{ price | toCurrency }}</div>

note: price value is 25, then filtered by toCurrency to $25.00

Although it looks nice, keep in mind that it's practically a "syntax sugar" since in the runtime, it will always run toCurrency to format the price whenever it's updated.

If you refactor toCurrency as a method instead, it'll be written like this:

<div class="currency">{{ toCurrency(price) }}</div>

The refactor in your Vue script is simply to move the function from filter to method:

// before
{
  filter: {
    toCurrency (value) {
      return `$${value.toFixed(2)}`
    }
  }
}

// after
{
  methods: {
    toCurrency (value) {
      return `$${value.toFixed(2)}`
    }
  }
}

Cool! But, what if the filter is registered as a global filter?

Vue.filter('toCurrency', function (value) {
  return `$${value.toFixed(2)}`
})

In this case, I will recommend you to delete the global filter code above, and move your filter function to become a pure helper function first that can be shared. For example:

// helper/filter.js

export function toCurrency (value) {
  return `$${value.toFixed(2)}`
}

And then, you can import the helper function to whenever component that needs to use it. For example:

// price-component.vue
import { toCurrency } from './helper/filter'

// your vue object
{
  methods: {
    toCurrency 
  }
}

note: just toCurrency will work ;) thanks to ES6 object property shorthand

Refactor your component `model` into `.sync`

Based on the RFC docs, Vue 3 will deprecate the model option in the Vue component, and it will replace sync to become multiple model.

If you have used model option in your component to set two-way data binding, you can refactor it to become .sync instead. Here's the example:

// BEFORE

// parent component
<child-component v-model="visible"/>

// the model option in the child component's Vue object
<script>
{
  model: {
    prop: 'visible',
    event: 'change'
  }
}
</script>

Refactor it to use .sync:

// AFTER

// parent component
<child-component v-bind:visible.sync="visible"/>

// delete the model option in the child component's Vue object

When the time comes for you to upgrade to Vue 3, you can simply rename the .sync to v-model instead:

// Vue 3

// parent component
<child-component v-model:visible="visible"/>

Easy peasy lemon squeezy! 😋

Be wary of using 3rd party plugins

The beauty of Vue framework like other framework is, it provides API for community to create their own plugin.

But in Vue 3, there will be a breaking changes that will make some plugins not compatible anymore. One major change is, the Plugin installation and app initialization will be immutable from the original Vue instance. For example:

// BEFORE, in Vue 2
Vue.use(myPlugin);
new Vue({/* your vue initialization */});

// AFTER, in Vue 3
const app = createApp(); // new method to initialize Vue
app.use(myPlugin);

It's most likely that you will not able to refactor your code to use the plugins in the Vue 3, until the author of the plugin upgrades it. So this means, you should be considerate of using the 3rd party plugins if you're planning to migrate, as this will be the blocker.

Check the issue or roadmap of the plugins you're using, to see if they're planning to upgrade to support Vue 3. This is the example of the plugins that'll support Vue 3:

If your used plugins doesn't have the plan yet to upgrade to Vue 3, you can help to contribute by asking the author in the issue to support Vue 3, or even take part to help them upgrade. 🤗

Use `@vue/composition-api` to write your component

I really appreciate the Vue community for providing the @vue/composition-api 🥰. Not only it can be used for the developer to hands-on using the Composition API, but it also provide API that'll become the core method in Vue 3.

Take for example, defineComponent. It will become the new standard of writing a Vue component in Vue 3, and you can already use it in your Vue 2 app!

To use it, install @vue/composition-api and replace your Vue object component initiation. For example:

// BEFORE
import Vue from 'vue';

export default Vue.extend({
  name: 'my-component',
  /* your component props, data, methods, etc. */
});

Simply replace it to use defineComponent:

// AFTER
import { defineComponent } from '@vue/composition-api';

export default defineComponent({
  name: 'my-component',
  /* your component props, data, methods, etc. */
});

What's the difference, you ask? Practically no difference, and that's the beauty of it! Your component shall work the same as usual, and added with "bonus" that now you can already refactor your component to use Composition API if you want to:

// Refactor to use setup()
import { defineComponent } from '@vue/composition-api';

export default defineComponent({
  name: 'my-component',
  setup (props) {
    /* your component props, data, methods, etc. */
  }
});

note: if you love Typescript, I'm pretty sure you will love the composition API because it'll help to improve your component typing. ;)

What's More

There will be another breaking changes such as:

But if you're not using it much, and you believe it can be refactored easily, then it's up to you to decide if it shall be changed soon or later.

Summary

Phew! I hope this article helps you to be prepared when the time comes to upgrade to the Vue 3. As a Vue developer, I know that I am excited to see it coming, since it uses better API to handle reactivity, more Typescript support, and better practices in the development.

If I missed any API or notes to be defined, please let me know and I appreciate your feedback. Thank you and have a great day!

Use a Mediator in your Javascript Project to improve productivity

Albert Mulia Shintra — Wed, 24 Jun 2020 14:18:28 +0000

Heya! 👋

In this post, I would like to share a design pattern to help organize your application code structure, especially when you are working as a team and the code needs to be developed collectively.

Let's imagine a real use case to help us go through the tips.

Use Case Example

You need to build a payment form and a module to handle the payment. Let's say there's two developer to work on it, you and Albert. (Yes you, let's work together! 😘) On the discussion, you discussed with Albert that you're going to split the task: Albert will be working on the payment form, and you'll handle the payment module.

The scope is quite specific, since Albert is mostly only working on the client side interface while you will be working on the API. It usually means, Albert should be working on the HTML code and the form submission, while you are working on the method to send the payment data to the API and check the response.

If this app is handled in a single file, it might look like this:

<form onsubmit="return submitForm(event)">
  <div>Credit Card: <input type="text" name="credit-card"/></div>
  <div>CVV: <input type="text" name="cvv"/></div>
  <div><input type="submit" value="Submit"/></div>
</form>

// pagePayment.js

async function submitForm(e) {
  const creditCard = e.target[0].value;
  const cvv = e.target[1].value;
  const success = await sendPayment({
    creditCard,
    cvv
  });
  if (success) {
    alert('payment success!');
  }
}

async function sendPayment(data) {
  // let's just pretend this API exist ;)
  return fetch('/pay', {
    method: 'POST',
    body: JSON.stringify(data)
  });
}

Looking at the basic payment code above to receive credit card information and submit it to the API, it can (and definitely) still be improved based on the app specification. But in the current situation, you and Albert will have to modify the same file, which likely raise conflict on merging the code. 😰

Imagine these use cases to add:

Add validation to the form input
Add multiple payment services
Create different payment form for different payment services

To avoid the conflict, the code should be separated by concern. We can simply modularize the payment module, but if the form submission code directly call the payment module, it creates "dependency" with the form and thus making the payment module hard to change.

One solution to decouple the user interface code and the module code is, by having a "Mediator".

Mediator Pattern

Let's see what it means:

"Mediator is a behavioral design pattern that lets you reduce chaotic dependencies between objects. The pattern restricts direct communications between the objects and forces them to collaborate only via a mediator object." - refactoring.guru

With this concept, now you and Albert can modify and improve your own codebase without having too worried about breaking each other. Let's see what kind of "Mediator" will serve them:

// payment-mediator.js

const paymentMethod = {};

export function registerPaymentMethod(method, module) {
  if (paymentMethod[method]) {
    throw new Error(`Payment Method ${method} is already exist!`);
  }
  paymentMethod[method] = module;
}

export function sendPayment(method, data) {
  if (!paymentMethod[method]) {
    throw new Error(`Payment Method ${method} is not exist!`);
  }
  return paymentMethod[method].send(data);
}

Just like a traffic control, the mediator will keep the registered payment method and use it when someone needs to send the payment.

Pro tips: if you're a fan of Typescript, you can define the interface of payment module to make sure that the registered module have the expected interface.

Now let's get back to our dear developers, you and Albert 😄

For Albert, he can focus on improving his form submission script:

// pagePayment.js
import { sendPayment } from './payment-mediator.js';

async function submitForm(e) {
  const creditCard = e.target[0].value;
  const cvv = e.target[1].value;
  const success = await sendPayment('default', {
    creditCard,
    cvv
  });
  if (success) {
    alert('payment success!');
  }
}

As for you, you can improve and add more payment method independently as well:

// payment-module.js
import { registerPaymentMethod } from './payment-mediator.js';

function payDefault(data) {
  // let's just pretend this API exist ;)
  return fetch('/pay', {
    method: 'POST',
    body: JSON.stringify(data)
  });
}

registerPaymentMethod('default', payDefault);

And that's it for the basic mediator! Hopefully this makes you and Albert stay productive, able to work independently, and cheers for the collaboration 🍻

Consideration

The question may raise here, who will develop and maintain the Mediator then? I believe that an intermediary module like mediator shall be develop and maintained by anyone in the team, to keep it running and updated based on the new requirement.

Also, having a mediator is simply another module to maintain in the codebase, so it shall be a pattern that's agreed and embraced by your developer team to ensure certain concern are considered:

Is it overengineering?
Is it too much abstraction?
Is the codebase going to be improved for a long term?
Is the team fine with the mediator abstraction?

Let me know what do you think of the pattern and your concern as well.

Thanks a lot for reading my post, hope it helps and have an awesome day!