Bagus Merta

Translating Style Guides into Code

Thu, 26 Sep 2024 00:00:00 GMT

As I began my software engineering career, I was captivated by the visual aspects of applications—whether it was a web applications, or mobile apps. Throughout my journey, I’ve recently realized that as applications scale and grow, building user interfaces becomes more challenging, especially when more developers are involved. This led me to dive deeper into studying reusable components, including design system and style guides, which form the foundation of our UI.

In this post, I’ll share my learning experience from implementing a design system in my personal website. The reason behind this post is I’ve developed and iterated on it numerous times, but I often found myself changing the entire theme and components, which led to inconsistency and a lack of cohesion across the site.

P.S. This is also my first experience with web development, so there are probably quite a few mistakes along the way—feel free to point them out, I’d really appreciate it!

Three things you need

There are three key elements needed to develop a UI for an app, based on Leerob post.

Style guides : A set of rules that we follow, including constants like hex colors, padding sizes, fonts, and typefaces that represent the brand. This ensures components are built consistently. If we make changes, they stay within these guidelines, reducing the risk of breaking the design.
Design system : The implementation of the style guides. For example, when creating a button, it must adhere to the style guide’s rules (e.g., correct fonts and colors). This approach makes components more robust and easier to maintain, even with multiple developers working on them. It also encourages building reusable, less duplicated code
Component library : It combines everything mentioned above—style guides and component libraries—into one complete system, along with detailed documentation and principles to ensure everything stays consistent. It’s like a blueprint that guides the design and development of your app.

Define design principles and our design token as a style guides

To begin, we need to define design principles and a style guide. This time, I’ve adopted principles inspired by Material Design and Apple HIG, with a bit of my own twist. The focus is on Scalability, Clarity, Efficiency, and Simplicity.

Scalability

Purpose : Design systems should be able to grow as the product or team evolves.
How : Create flexible components that can handle multiple use cases (e.g., button variations, responsive grids). Ensure new elements can be added without breaking existing styles.
Example : A grid system that adapts to different screen sizes, or a button that supports various sizes and states (hover, disabled, etc.).

Clarity

Purpose : Prioritize readability and ease of understanding for users.
How : Use clear visual hierarchy (through typography, color, and spacing), legible fonts, and high-contrast color schemes to make important elements stand out.
Example : Clear headings, consistent icon usage, and defined spacing between sections to guide users through the content.

Efficiency

Purpose : Reduce complexity for both users and developers.
How : Create a streamlined workflow for the design and development process. Make sure that components are easy to use and adapt to various situations without too much customization.
Example : Predefined color and spacing tokens that developers can easily apply without guessing or writing extra CSS.

Simplicity

Purpose : Keep designs straightforward to minimize cognitive load on users.
How : Avoid unnecessary elements, reduce visual clutter, and use intuitive patterns.
Example : Minimalistic interface with clear call-to-action buttons, rather than overly decorative styles.

Creating design tokens

Design tokens represent a shared language for design attributes, allowing them to be written in code. Typically, we convert designs created by the design team into hardcoded values to maintain consistent and scalable UI components

This includes things like: Colors (text, backgrounds, borders), Fonts, Typography sizes, Spacing values, Shadows

For example, here are the hardcoded values for colors used in my components:

@layer base {
    :root {
        --background: 222.2 84% 4.9%;
        --foreground: 210 40% 98%;
        --popover: 222.2 84% 4.9%;
        --popover-foreground: 210 40% 98%;
        --primary: 210 40% 98%;
        --primary-foreground: 222.2 47.4% 11.2%;
        --secondary: 217 91% 59%;
        --destructive: 0 62.8% 30.6%;
        --destructive-foreground: 210 40% 98%;
        --border: 217.2 32.6% 17.5%;
        --radius: 0.5rem;
        --card: rgba(255, 255, 255, 0.05);
        --card-hover: rgba(255, 255, 255, 0.1);
        --card-hover-border: rgba(255, 255, 255, 0.26);
      }
      ...
  }

Next, in my tailwind.config.mjs, I define these tokens so we can use them in Tailwind classes:

export default {
	...
	theme: {
		extend: {
			fontFamily: {
				primary: ['AlbertSans', ...fontFamily.sans],
				display: ['PlayfairBold', ...fontFamily.sans],
				code: ['DMMono', ...fontFamily.sans],
			  },
			  borderRadius: {
				lg: 'var(--radius)',
				md: 'calc(var(--radius) - 2px)',
				sm: 'calc(var(--radius) - 4px)',
			  },
			  colors: {
				background: 'hsl(var(--background))',
        		foreground: 'hsl(var(--foreground))',
				primary: {
					DEFAULT: 'hsl(var(--primary))',
					foreground: 'hsl(var(--primary-foreground))',
				},
				secondary: {
					DEFAULT: 'hsl(var(--secondary))',
					foreground: 'hsl(var(--secondary-foreground))',
				},
				destructive: {
					DEFAULT: 'hsl(var(--destructive))',
					foreground: 'hsl(var(--destructive-foreground))',
				},
				border: 'hsl(var(--border))',
			  },
			  ...
		},
	},
    ...
}

We also need to define the icon set we're using. For this website, I’m using open-source icons like simple-icons. Here's how I include them using Icon tag in Astro

---
const icon = 'simple-icons:github';
---
<Icon class='text-2xl text-gray-400' name={icon} />

Make sure to consistently utilize icons from the same set to maintain visual uniformity throughout the app. I use Iconify to find the exact icons that fit my needs.

Creating component library

After defining our style guides, it’s time to translate those guides into code. Based on the design tokens we've already created, we'll now build components according to the design principles we agreed upon.

For the button component, I decided to create two separate variations, with the primary button also having its own glowing variant.

<PrimaryButton href="" text="Glowing" glowing={true} />
<PrimaryButton href="" text="Primary" />
<SecondaryButton href="" text="Secondary" />

Here’s how they look.

Another example is the card component. I decided to create separate components for different types of cards since they serve different purposes. However, they all follow the same design principles we agreed upon. Below is my blog card, which emphasizes the importance of visual hierarchy.

---
import type { BlogEntry } from "utils/content";
import { formatDate } from "utils/time";
import { getBlogPathName } from "utils/url";
import { Icon } from "astro-icon/components"
import { Image } from "astro:assets";
export type Props = BlogEntry;

const props = Astro.props;
---
<li class:list={[
  'p-2 w-full rounded-lg border border-gray-900',
  'bg-gradient-to-br from-[var(--card)]',
  'scale-500 hover:scale-[1.02] active:scale-[0.97] motion-safe:transform-gpu',
  'transition duration-500',
  'motion-reduce:hover:scale-500',
  'animate-shadow',
  'hover:border-[var(--card-hover-border)] hover:shadow-[0_0_12px_var(--card-hover)]',
]}>
 ...
</li>

As you can see, I used our --card value and its hover state, ensuring that each card is displayed consistently.

Here's how it looks.

Conclusion

That’s it! Now I have a solid foundation for my website. In the future, if we make changes or add new features, we’ll follow these style guides to ensure everything stays consistent with the theme. Thanks for reading! I hope you found this helpful.

References.

Leerob blog posts on design systems

Basic UI fundamental

Apple HIG

Material UI

Well, you're just a man

Tue, 11 Jun 2024 00:00:00 GMT

Marcus Aurelius was the last of the Five Good Emperors who ruled the Roman Empire during a period known as the Pax Romana, or Roman Peace.

I've been a fan of Stoicism for years. Recently, I've been listening to the audiobook of Marcus Aurelius' Meditations. (Imagine listening to the diary of one of the most successful rulers in this modern age 🤣)

Lately, life has been playing tricks on me, making me question the meaning of it all.

Then I remembered a story about Marcus Aurelius.

He was always respected by Roman citizens, with many even kneeling before him.

And behind him, there was a slave who always stayed close.

This slave only had one job — to remind him, whenever he felt on top of the world, whenever citizens worshipped him and knelt before him.

The slave would whisper.

You're just a man

It humbles me.

Often, when I achieve something significant, I feel like I'm the best or better than others.

Then life reminds me that anything can be taken away as quickly as you can flip your hand.

Life always rotates.

There are times when we are up and times when we are down. We can't control the flow of the wind

Yeah, you're just a man.

Better way to write Commit Messages

Thu, 30 May 2024 00:00:00 GMT

When working with a team, or even if you expect others to read your code, it's important to ensure that what you deliver is easy to understand. Often, when working alone on our repository, we might commit messages that seem appropriate at the moment. And that's fine. However, imagine needing to revisit a specific commit to find the exact cause of a bug or other important issues. If your commit message is clear, you won't need to spend so much time searching for it, right?

This way of communicating through commit messages helps convey the intention behind the code changes. Everyone has their own style of writing commit messages; there's no one-size-fits-all solution. However, understanding what makes a good commit message can make you a better developer in the future.

Conventional Commit

The solution is to follow Conventional Commits. Conventional Commits provide a set of rules or guidelines to help us write semantic messages better. Based on Conventional Commits, your message should be structured as follows:

<type>[optional-scope]: <description>

# `type` is the type of change you made in your commit.
# `optional-scope` is the scope that your changes affect.
# `description` describes what was done.

If you have more to say:

<type>[optional-scope]: <description>
[optional-body]
[optional-footer]

For example:

feat(shop): add product card

A longer example:

feat(payment): notify user upon successful purchase
Implement functionality to send a push notification to users when a product is successfully purchased. 
Refs: #123

Types

There are various types to differentiate the changes you make in your code:

- feat → Changes related to adding or removing a feature.

- fix → Bug fixes (state the issue that you solved).

- docs → Documentation updates (e.g., README.md).

- style → Code style updates that don't change logic (e.g., optimizing imports, fixing whitespace).

- chore → Dependency management (e.g., installing or updating dependencies).

- refactor → Code changes that don't alter the external behavior but improve the internal structure.

- ci → Changes to CI configuration or scripts.

- test → Adding or updating tests.

- revert → Reverting a previous commit.

# Codemagic is an example of a CI/CD tool; you could replace it with your preferred tool.
- codemagic → Blank commit to trigger deployment (e.g., `codemagic: trigger deployment`).

Closing

What's important here is how you write the description. Make sure you fully explain what is being done. Use imperative and present tense. Also, don't use capitals at the beginning of the sentence and don't add a full stop (.) at the end.

References. Conventional Commit Message

Flutter pre-commit linter hooks

Tue, 12 Mar 2024 00:00:00 GMT

working in a team can be quite challenging, especially when you're part of a startup engaged in fast-paced development, where there's a good chance of writing not-so-great code in such a rush. But if we ignore it, we're just storing up problems for later. It will become a technical debt that going to slow down the development of our team, and might even cause bugs and other headaches.

One way to tackle this problem is to set a pre-commit hooks on our Repository. Luckily Flutter.dev comes up with the official flutter_lints package that contains a recommended set of lints for Flutter apps to leverage good coding practices. This package is actually built on top of the Dart analyzer, which statically checks Dart code. So alternatively, we can analyze our code manually using the flutter analyze command. But that means we have to manually write the command every time we make changes, right? Rest assured, in this blog, I will show you a way to make it easier.

Pre-requisites

You'll need a Flutter project with the latest versions of Flutter and Dart
Make sure you have pip installed if you're using windows otherwise you can use brew

Installation

If you haven't already installed pre-commit, you can do so by following the instructions on the Pre-commit website. For most users, installing via Homebrew or pip is recommended.

brew install pre-commit  # For macOS
# or
pip install pre-commit  # For other platforms

After that, you can initialize the pre-commit hooks inside your repository by creating .pre-commit-config.yaml at the root of your project. This file specifies the hooks that should be run and any additional parameters needed for the linting process. This will enforce code quality standards before each commit is made to our repository. Below is an example of my pre-commit config file, which will handle formatting and analyzing in our code.

repos:
  - repo: local   # Specifies that the repository is local (not remote).
    hooks:
      - id: flutter-format
        name: Flutter Format
        entry: dart format .   # Command to execute for formatting Dart files.
        language: system     # Specifies the language environment for executing the hook.
        types: [dart]       # Specifies the file types to which this hook applies.
        pass_filenames: false   # Indicates whether filenames should be passed to the hook
      - id: flutter-analyze
        name: Flutter Analyze
        entry: flutter analyze  # Command to execute for analyzing Flutter code.
        language: system  
        types: [dart]
        pass_filenames: false

Then, add the analysis_options.yaml to your root project and customize it for your own benefit. This file is used to configure static analysis settings for Dart code, allowing you to specify various rules and settings that the Dart analyzer should follow when analyzing your codebase.

include: package:flutter_lints/flutter.yaml

# This section specifies the linting rules 
linter:
  rules:
    # Define your custom rules here
    avoid_empty_else: true
    avoid_print: true
    avoid_relative_lib_imports: true
    avoid_returning_null_for_void: true
    avoid_unused_constructor_parameters: true
    avoid_void_async: true
    await_only_futures: true
    camel_case_types: true
    constant_identifier_names: true
    curly_braces_in_flow_control_structures: true
    file_names: true
    no_logic_in_create_state: true
    non_constant_identifier_names: false
    prefer_const_constructors: true
    prefer_const_literals_to_create_immutables: true
    prefer_final_fields: true
    unnecessary_null_checks: true
    unnecessary_this: true
    use_key_in_widget_constructors: true

# This section specifies the analyzer settings
analyzer:
  exclude: # Exclude certain files and directories from analysis.
    - lib/generated/**  
    - test/**           
    - "**/*.g.dart"     
    - "**/*.freezed.dart" 
  errors: # Specify how to handle certain types of analyzer errors.
    annotate_overrides: ignore
    avoid_print: ignore
    avoid_unnecessary_containers: ignore
    avoid_void_async: ignore
    camel_case_types: ignore
    constant_identifier_names: ignore
    dead_null_aware_expression: ignore

You can see the whole example of analysis_options.yaml from the official Flutter project repository itself.

Trigger the pre-commit linter hooks

Now that everything is set up, try making changes to your Flutter project, especially inside the lib directory, and then commit your changes.

  git add .
  git commit -m "test precommit linter"

Then, let the pre-commit linter work. It will give a green label if our commit is successful, as shown in the picture below. If not, the linter will show you the code that needs to be changed based on the rules set in the analysis_options.yaml file. After that, we need to re-commit our changes.

Conclusion

Setting up pre-commit hooks can be a real game-changer for your team. It's like having a helpful assistant that keeps your code clean and your development process smooth, even in the midst of fast-paced development. Thanks for reading, happy coding :)

Optimize Your Mobile Development Workflow with CodeMagic's

Sat, 13 Jan 2024 00:00:00 GMT

Building mobile apps is super exciting, but it can also can be a challenge. Have you ever experienced the frustration of building a mobile app on your machine, only to face roadblocks when collaborating with team members? In this blog, I'll introduce a solution which automating your mobile app builds with CodeMagic.

With CodeMagic, you can streamline your development workflow and ensure consistent and reliable builds, regardless of your team's diverse environments. By automating the build process, you can avoid compatibility issues and focus on developing features that matter.

Additionally, I'll show you how to integrate your workflow into Slack or Discord so that you can receive notifications every time a build is completed.

CodeMagic offers a lot of features to make your CI/CD process easier, especially for mobile development. Initially, it only supported Flutter, but now you can add Android, iOS, and React Native, with many advanced configurations and APIs. It also provides a free tier, so you should give it a try.

while CodeMagic provides a lot of options, the free tier offers 500 minutes every month for using their M1 machine. So, use it wisely.

Setting up a CodeMagic account & Github repository

The first step is to sign up for a CodeMagic account using your preferred repository host. In this blog, I'll be using Github since it's commonly used. After signing up, head to the CodeMagic dashboard. Click on "Add Application" to create a new app. Choose the individual plan, then paste the link of your Github repository where you want to connect it with CodeMagic. Finally, click "Finish: Add Application" to complete the process.

There are two options to enable the workflow, using a .yaml file and using the workflow editor on the CodeMagic dashboard. I personally prefer using the yaml approach because it helps me learn scripting as well.

This is basically what your dashboard looks like after completing the repository addition.

Before we dive into creating your codemagic.yaml to initiate the workflow, we need to manually add the webhook URL of our CodeMagic app to our GitHub repository. Go to your application dashboard, and copy the webhook URL for your CodeMagic application.

And then go to your GitHub repository > Settings > Webhooks and paste the CodeMagic webhook URL into your repository.

And voila! your CodeMagic and Github are connected now.

Creating your `codemagic.yaml`

Alright, let's start the coding session. To really get how things work, we'll begin with the simplest setup. Also, it's good to understand the basics before moving on to more advanced configurations.

First you need to define your workflow ID (with '-' to separate each word) and also the name and maximum build duration of your app.

workflows:
  android-workflow-id:                    # your workflow ID
    name: "Android ToDo's App Workflow" 
    max_build_duration: 120               # max duration of your build
    instance_type: mac_mini_m1            # remote machine to run your workflow

Next, we have the environment property, which is commonly used to specify your project's settings for building. For example, you can specify the versions of Flutter or Java used in your project.

workflows:
  android-workflow-id:
    ...
        environment:  # env scope for your build
            flutter: 3.0.5
            java: 17

This one is really important - triggering is the property that makes your build run based on actions or events in your GitHub repository.

There are 4 build triggers, but I'll write just 3 most important (at least for me) :

push : starts every time you commit code to any of the tracked branches.
pull_request : starts when a pull request is opened or updated to verify the resulting merge commit.
tag : automatically builds the tagged commit whenever you create a tag for this app.

workflows: 
  ...
    triggering:
          events:
            - push  # trigger on push events
          branch_patterns:
            - pattern: "*" # * indicates any branch pattern (main, dev etc)
              include: true
              source: true

When setting up triggers for pull requests, you can choose whether each branch pattern matches the source or target branch of the pull request.

you can read more about the triggering property on their docs

Next up is the scripts property, where you put the scripts needed to run your build. Make sure the order of your scripts is correct because they are executed from top to bottom.

Also, it's helpful to have a basic understanding of how to use Linux commands. This knowledge will allow you to make the most of its features, especially for debugging purposes.

workflows:
  ...
    scripts:
    - name: Set up local.properties     
      script: |
        echo "flutter.sdk=$HOME/programs/flutter" > "$CM_BUILD_DIR/android/local.properties"
    - name: Get Flutter packages
      script: |
        flutter packages pub get
    - name: Build Debug App with Flutter
      script: |
        flutter build apk --debug
    - name: Show Build apk Folder  # tips. add this command to see the content of your artifact
      script: |
        ls build/app/outputs/flutter-apk

Lastly, we can specify the artifact, which stores our build results, and the publishing property, which contains options for where you want to publish your artifact.

workflows: 
  ...
    scripts:
      ...
      ...
    artifacts:                       
      - build/app/outputs/flutter-apk/*.apk  # specify path to store your artifact 
    publishing:
      email:
        recipients:
          - example@gmail.com  # email recipient in case you want to see the reports

This is the full code of your codemagic.yaml to start the workflow.

workflows:
  android-workflow-id:
    name: "Android ToDo's App Workflow"
    max_build_duration: 120
    instance_type: mac_mini_m1
    environment:
      flutter: stable
    cache: # tips. add cache mechanism to fasten your build process
      cache_paths:
        - ~/.pub-cache
    triggering:
      events:
        - push
      branch_patterns:
        - pattern: "*"
          include: true
          source: true
    scripts:
      - name: Set up local.properties
        script: |
          echo "flutter.sdk=$HOME/programs/flutter" > "$CM_BUILD_DIR/android/local.properties"
      - name: Get Flutter packages
        script: |
          flutter packages pub get
      - name: Build Debug App with Flutter
        script: |
          flutter build apk --debug
      - name: Show Build apk Folder
        script: |
          ls build/app/outputs/flutter-apk
    artifacts:
      - build/app/outputs/flutter-apk/*.apk
    publishing:
      email:
        recipients:
          - example@gmail.com

Start the builds

To kick off your CodeMagic workflow, you have two options. You can either use the CodeMagic dashboard to manually start your build, or you can set up triggering events based on your codemagic.yaml file. For instance, you might want to start the build every time you push new changes to your repository.

If everything goes smoothly, you'll be able to see the artifact in the build overview of your app.

You can also debug your build process using SSH or VNC access. This can be very helpful if you need to troubleshoot any issues on your remote machine.

Integration with Discord

Lets start diving into the fun part. First, you need to obtain your Discord webhooks from your channel where you want to receive notifications. Then, add the webhook URL to the environment section in your CodeMagic app.

You can access your variables in your workflow code using the $ symbol in front of them (like $DISCORD_WEBHOOK_URL). Also, you need to specify the variable group that you created inside the environment property.

To connect with Discord, you can include this command within the publishing section.

workflows:
  ...
    environment:
      groups:
        - discord_credentials # variable group that stores discord webhook
    ...
  
    publishing:
      ...

      scripts:
        - name: Discord notification # use the webhook URL at the end of the scripts
          script: |
            set -ex

            # Extract the App Link from CM_ARTIFACT_LINKS
            APP_LINK=$(echo "$CM_ARTIFACT_LINKS" | jq -r '.[] | select(.name == "app-debug.apk") | .url')

            # Get the first 7 digits of the commit number
            COMMIT=$(echo "${CM_COMMIT}" | sed 's/^\(........\).*/\1/;q')

            # Get the commit message
            COMMIT_MESSAGE=$(git log --format=%B -n 1 $CM_COMMIT)

            # Get the commit author
            AUTHOR=$(git show -s --format='%ae' $CM_COMMIT)

            # Publish the notification
            curl -H "Content-Type: multipart/form-data" \
              -F "payload_json={
                \"username\": \"codemagic-bot\",
                \"content\": 
                \"**Commit:**   \`$COMMIT\`\\n**Commit message:** $COMMIT_MESSAGE\\n\\n**Branch:** $CM_BRANCH\\n
                **Author:** $AUTHOR\\n\\n**Artifacts:**\\n\\n**App Links:** $APP_LINK\\n\\n\"}" \
              $DISCORD_WEBHOOK_URL

Make changes and try pushing them to your remote repository. If the build is successful, you'll receive a notification.

Conclusion

This tool comes with many benefits for your development – it speeds up development and resolves your build problems. It can also automate your testing, deployment, or publishing your app to PlayStore or AppStore, among many other features.

Well, that's all for this blog. Pretty cool, right? Give it a try, and your future self and teammates will thank you.

References. Codemagic Official Docs

Unpacking 2023

Sun, 31 Dec 2023 00:00:00 GMT

2023 has been quite a journey, filled with ups and downs. I'm putting together this blog to help me look back on what I've been through, what I've learned, and my hopes for the next year.

It's like a friendly chat with myself, a little snapshot of lessons and dreams for the next 23 years.

Lets Roll.

1. Take the initiative, don’t hesitate

If I've learned anything impactful this year, it's the importance of taking initiative in almost every situation. I can provide a few examples:

When I entered my final year and had to write a thesis, many college students faced challenges, especially when dealing with professors, whether it was finding a suitable time for discussions or getting their thesis drafts corrected. One thing that made it much easier for me was taking the initiative. I personally reached out to the professor, kept him informed about my progress, suggested meeting at his coffee shop for discussions, and took the lead in creating a group chat specifically for our professor. This initiative made it simpler for my friends to access information related to our professor's schedule. The key point is that it made me stand out more in front of my professor.

I got multiple opportunities by reaching out first. I asked a senior engineer I know if there was a position that would be a good fit for me and requested a referral. I even reached out to the CEO of the company. Nowadays, you have various tools to make reaching out easier, such as LinkedIn, Twitter (X), email, etc. Of course, you also need to build trust and improve your online presence by creating projects or enhancing your profiles.

I used to be afraid to reach out to someone, always fearing that the person I contacted would somehow be annoyed. But honestly, after all of this, it doesn't really matter as long as you maintain good etiquette and attitude. The worst thing you can receive is a rejection, so go get it!.

2. Always follow-up

I lost many opportunities because I hesitated to follow up. Whether applying for a job or acquiring a client, The mindset we should be focused on is What exactly I can provide to them, addressing the challenges they're facing, without expecting an immediate reward.

The person you're dealing with should discover that you excel in areas where they may struggle. How? By consistently following up. Send emails or messages with attachments of your work, do it at least once a day. Let them see your persistence and genuine interest in seizing opportunities. Along the way, you may encounter cold emails and rejections, but over time, you'll get used to it and develop a mindset of saying, "Okay, good, let's move on to the next.”

3. Handling rejections

It's almost similar to the two points I mentioned above, but this one has a slightly different perspective. Rejections suck—everyone hates them.

Throughout my life, I've faced numerous rejections, to the extent that I started questioning my self-worth. Each rejection felt like a direct hit to my self-esteem, making me believe I was never good enough for anything. It was incredibly challenging to pick myself up and move forward.

Now, instead of viewing rejections as attacks on my self-esteem, I prefer to see them as life lessons that help build my resilience. Often, the reasons behind rejection stem from external factors beyond our control, rather than our personal weaknesses.

Most importantly, it teaches me to remain humble and be grateful for what I already have and have learned. It motivates me to deal with and overcome the difficulties that life brings.

I plan to create an article about this specific topic, maybe next month—stay tuned! haha.

4. Say goodbye to Your Routine

No lie, I'm obsessed with self-development. So much so that I've built a routine, like waking up in the morning, grabbing a coffee, working out, and so on. Let me give you a clearer example. I need that cup of coffee to kickstart my day, and if I skip it, I won't be productive, and my day feels suck. This goes for other things too, not sticking to these routines affects my ability to fully tap into my potential for the day.

After enduring many bad days and battling procrastination, I realized that relying too heavily on routines can actually make us weaker. Insisting on having a coffee to get the job done is like making a statement about how the world should be when you have no control over it.

Think about it. Initially, you need that morning coffee to feel better and get things done, but over time, you end up needing it just to feel normal. Eventually, the benefits that coffee once provided are gone.

Believe it or not, there were humans, maybe a hundred years ago, who had none of these things and still got things done. It weakens me and makes me less resilient.

The solution is to have no routine at all and just do things that need to get done, regardless of how you feel. I know, It's easier said than done, but I believe it makes me more resilient.

5. You’ll never be ready

This idea applies to anything in life. While it's good to have some basic knowledge before starting, it doesn't have to be perfect. Waiting is always tempting and often leads to procrastination. Whether it's starting something new or sharing your work, the urge to wait until you have more skills or feel completely ready is common. But when will that be?

It's tricky, The real truth is, you'll never feel completely ready.

After reading and watching a bunch of stuff, the best time to start is when you're unsure, especially when the path ahead isn't clear.

6. Less social media, more peace of minds

I've cut down on social media almost every day. I only open it for important events that my close friends or my girlfriend are involved in, where I post or send messages to make myself and them feel acknowledged. It might sound strange, but I think it's almost impossible not to have social media in this modern age since everything is happening online. However, I believe it's crucial to set limits so that we don't become overly dependent or obsessed with it.

Having face-to-face conversations with people has always been my preference over chatting on social media. Sometimes, I mindlessly scroll too, especially on tough days. However, I've realized what happens and decided to log out or hide the apps on days when I need zero distractions.

7. A few good friend is enough

Well, I think I've lost touch with many friends along the way, not because of any disagreement, but I've realized everyone has their own stuff and needs to go in different directions. Sometimes, I discover I don't click with certain people, maybe because of their attitude, behavior, the environment, or it's just me. But I've learned to be okay with it, even though it was tough.

I have a group of friends and close pals who empower me to keep going. They inspire me, surpass me in certain aspects, and provide support. I believe that's sufficient.

8. Relationship, love

I've learned a bunch about relationships this year, especially the ones with loved ones. I now get why looks don't matter much when you have someone who supports you, no matter what situation you're in, and I'm really thankful for that. The important thing is talking openly. No matter what comes up, we need to trust each other, not set strict rules in the relationship, and support one another. I give advice when she needs it and agree with her perspective when it just feels right, even if it's actually wrong—haha.

Just like any other connection and relationship, people need to be valued and respected. That's the fundamental thing I've learned.

9. Health is your super-power

This year, I got sick too often, and it reached the worst stage – I had GERD from consistently delaying meals, and it felt terrible. I don't know why, but it always happened when there was an important event, be it a family reunion or just meeting friends at a coffee shop. I realized that if I want to stay on track, I need to maintain my health by leading a healthy life. I've witnessed quite a lot – relatives with lots of money, yet every month they're dealing with health issues and hospital check-ups.

Life is like a marathon, and at the end of the day, I simply want an okay life. I want my parents to retire, to assist friends and people dear to me, pay off bills, and handle other essential aspects of living. But if I'm not in good health, how am I supposed to achieve that? Even if it takes 10 years, at least with good health, I can keep pursuing my dreams.

10. Learn, Practice, Repeat

Never stop learning. In the past, the fast-paced trends in Software Engineering made me feel burnout, but now I've learned that, with technology growing rapidly, what you need are fundamental knowledge, patience, and a strong work ethic. I believe tools or frameworks are essentially the same, and you can leverage your understanding to learn other things. What I've learned is to pick one thing (like learning React for web development), but ensure you understand JavaScript and HTML/CSS as well. Try to build a project—it doesn't need to be fancy, just enough to make the knowledge stick in your brain.

If you're able to maintain a steady learning pace and be patient, when opportunities come, I believe we can at least handle the basics and work ourselves to the next step. I often feel the pressure to master something in one go, which is impossible (at least for me).

In today's world, instant gratification affects us in almost every aspect. That's why learning to learn, being patient, and staying resilient is rare, even for myself. So, I'm gonna keep on learning until it becomes a natural part of who I am.

Well, that's it! It encompasses everything I've learned. Of course, I could go on with a much longer list, but I believe that's all the things that have stuck in my brain.

Eight Things I'm Going to Do

Now. lets write a list of things I’m going to do next year, The 2024. Lets get into it.

1. Hit the gym, regularly

It brings you good health and a bonus of looking good, so you won't have to worry about choosing clothes that suit you. I've noticed many influencers with great bodies who just rock simple outfits. I aspire to be like that—haha.

2. Learn more instead trying to earn more

You're still young, a lot of stuff will happen in the future. What you need is experience and if you go for earning you will stop learning. Learn every skill along the way, not only stuff related to software engineering.

3. Practice English, writing and speaking

I need to improve because, right now, I still rely on ChatGPT to write this blog, lol. I also want to speak English fluently to open up more opportunities in the future. You can start by using DuoLingo, writing and reading English blogs, and watching English videos.

4. Create a YouTube Video on Your Expertise

You know, almost everything I've learned is from video formats, mainly YouTube. So, I thought maybe I could contribute to the community by sharing something I know.

5. Write a blog post, at least once a month

I just want a space where I can chat with myself and, in the process, improve my English writing skills. Hehe.

6. Becomes better son, better brother, better partner and friends.

Literally becoming a better human. I've made a lot of mistakes, probably upset people until today. That's why I need to be better for myself and learn to respect myself.

7. Invest in stock

Learn how to make your money works for you, just make sure to use specified Investment budget and learn the stock that you want to invest with.

8. Make a proper portfolio, blog site. (Using proper tech-stack and domain)

I want others to be able to subscribe and comment on my content so that I can receive feedback about my writing.

Closing

All in all, the purpose of this article really only for me to look back and laugh. And it took longer than I thought. Thanks for reaching this page. I hope you can get something out of it.

Do it First

Sat, 07 Oct 2023 00:00:00 GMT

So I randomly stumbled upon this new podcast with Chris William and David Goggins. And guess what? It's like I've got this instant insight into his whole deal.

To simplify, If there’s something that you’d like to do or some condition you’d like to be true, let it happen.

Believe it’s going to happen.

Write it down.

Now, start chatting it up with yourself.

I’ve got this.

You can do it.

The big thing here is taking action. The brain can be a bit of a slowpoke, so just get moving, literally. Tell your body to go before your brain's even figured it out.

Want to write a book? Easy, stare at a blank page for an hour each day until words start popping out.

If you'd like to run stare at your shoes for a few minutes until you start running.

If you'd like to write code, just open your favorite Editor (IDE) for a few moment.

That's Insane 🤣

Sure, there are limits to what you know, but sometimes you've gotta trick that brain of yours into action. Take a cue from David Goggins, put yourself out there, and let the rest catch up.

Sometimes the things we tell ourselves or believe can sound a bit crazy. But if you think about it, pretty much everyone who's achieved something cool has embraced a bit of madness along the way.

The point is the same

And you know what? It goes for a simple life too. Fly under the radar, lay low for a while, lay low forever and enjoy the simplicity of existence.

To close this post, I would like to share a quote by Alex Hormozi.

The harder you work the more you realize what you used to think was hardwork, is not even close to what you're capable of.

That's it for this post. I hope it can be some kind of useful to anyone who reads it. Feel free to always reach me out.

—I'd love to receive your thoughts on this piece!

References. Chris William and David Goggins Podcast

Bagus Merta

Translating Style Guides into Code

Three things you need

Define design principles and our design token as a style guides

Scalability

Clarity

Efficiency

Simplicity

Creating design tokens

Creating component library

Conclusion

Well, you're just a man

It humbles me.

Life always rotates.

Better way to write Commit Messages

Conventional Commit

Types

Closing

Flutter pre-commit linter hooks

Pre-requisites

Installation

Trigger the pre-commit linter hooks

Conclusion

Optimize Your Mobile Development Workflow with CodeMagic's

Setting up a CodeMagic account & Github repository

Creating your codemagic.yaml

Start the builds

Integration with Discord

Conclusion

Unpacking 2023

1. Take the initiative, don’t hesitate

2. Always follow-up

3. Handling rejections

4. Say goodbye to Your Routine

5. You’ll never be ready

6. Less social media, more peace of minds

7. A few good friend is enough

8. Relationship, love

9. Health is your super-power

10. Learn, Practice, Repeat

Eight Things I'm Going to Do

1. Hit the gym, regularly

2. Learn more instead trying to earn more

3. Practice English, writing and speaking

4. Create a YouTube Video on Your Expertise

5. Write a blog post, at least once a month

6. Becomes better son, better brother, better partner and friends.

7. Invest in stock

8. Make a proper portfolio, blog site. (Using proper tech-stack and domain)

Closing

Do it First

That's Insane 🤣

The point is the same

Creating your `codemagic.yaml`