The paper asks a simple question that turns out to be deep. Can the words of a song tell us whether it will be popular? Not the melody, the production or the marketing, just the words, the part an independent songwriter controls completely.

The paper gave us a strong place to start.

• A dataset of 652 Indonesian songs released between 2017 and 2024, each with its Spotify popularity score and its lyrics.
• Three popularity groups (less popular, fairly popular and very popular) set from the statistics of the data.
• A thoughtful choice to keep every word. Many text studies throw away small stopwords suchs as “yang”, “di” and “aku”. The authors argued that in a song, those words carry feeling. Aku versus kita is not noise in a love song.
• A Support Vector Machine (SVM) model, tuned, and a samll web app where peopole can pate lyrics.
• We set out to do three modest things with it, runt it again, improve it a littel and release it so anyone can use it. The result is live at tralala-trilili.streamlit.app

Run the original

Before changing anything, we reproduced the paper from scratch on its original 652-song dataset, following its steps.

1. Turn the lyrics into numbers with TF-IDF.
2. Balance the three groups with SMOTE.
3. Split the data 80/20 into training and test sets
4. Train the SVM and tune it.

The results matched. The paper reports 89% accuracy after tuning. Our re-run gave 91% on the same kind of split and 87% on average across ten different splits. The tuning even picked the same settings the paper reports. The works is reproducible, which is more than many papers can say.

That let us ask the next question, what exactly is that 89% measuring?

Look again at steps 2 and 3. The groups were balanced before the data was split. SMOTE balances groups by inventing new examples. It takes two real songs from a smaller group and creates a synthetic “song” partway between them. Done before the split, some invented songs land in the test set while their “parents” sit in the training set. In our re-run, about 35% of the test set was synthetic. The model was partly being tested on close relatives of songs it had already studied.

We changed one thing, split first, then balance only the training data, so the test set holds only real songs the model has never seen. Accuracy moved from about 89% to 53%. A “model” that ignores the lyrics and always answers fairly popular scores 52%.

Test the way the tool will be used

The most important lesson of the project, how you test a model matters as much as the model itself. Choosing the evaluation takes hard-won insight. Nobody gets it right by default, and most people learn it by being fooled at leaset once.

We made three changes.

1. Keep the test set untouched. Anything that learns from data, whether word weights, balancing or tuning,learns from the training set only. Our code enforces this by putting every step inside one pipeline that only ever sees training data, including in each round of cross-validation.
2. Don’t trust plain accuracy when groups are uneven. In our “hit or not?” task (is the song in the top 25% of chart songs by streams per day, or not?), always answering not a hit scores 74–80% accuracy and never fings a single hit. So we rank models by macro-F1 and balanced accuracy, which weigh each group equally. A model only scores well on them if it actually recognises the rare, popular songs.
3. Define whaht “new” means. Good on new song is not thhe same as good on new artists. If Noah has 26 songs in the data, a model can learn “Noah-like lyrics” and look clever. So we also test on artists the model has never seen. We report confidence intervals too with about 240 test songs, scores are uncertain by about +/-0.07, so two models 0.02 apart are effectively tied.

Choose the Representation and the Model with evidence

A computer can’t read a lyric. Before any model sees a song, we decide how to turn words into numbers. That choice, the data representation, shapes everything after it. Choosing it, and choosing the model type, also takes hard-won insight. The right answer is rarely the obviouse one.

We compared several, each a different ide of what a lyric is

• A bag of weighted words (TF-IDF). Which words appear and how distinctive they are. Fast, transparent and surprisingly strong.
• Words plus word fragments. Also counts pieces of words, which helps with Indonesian forms such as kau, kamu and -mu.
• Sentence embeddings. A neural network compresses the whole lyric into a list of numbers that captures its overall meaning.
• A fine-tuned Indonesian language model (IndoBERT). Pre-trained on a large amount of Indonesian text, then taught our task.
• Thirty human-readable song features. Themes (heartbreak, family, religion), emotions (sad, angry, hopefule…) and structure ( length, hook repetition, share of unique lines)

We also built a bigger, open dataset of 1,260 Indonesian songs for this comparison.

Models marked GPU need a graphics card to train. Two lessons came out of this.

The fancy option isn’t automatically better. A plain logistic refression that gives the rare groups more weight, instead of inventing synthetic songs, beat the SMOTE + SVM combination by a wide margin. That is a small change with a big effect. IndoBERT scored highest, but its lead is inside the margin of error and it needs a GPU. For the “hit or not” question, TF-IDF plus the thirty song features scored best of all (macro-F1 0.64).

A good representation can also teach you something. The human-readable features let us look inside the data. In ourdata, more popular Indonesian songs tend to be sadder, longer and less repetitive, the opposite of what studies of English-language charts often report. Part of this may be an era effect, since long, melancholic galau ballads dominated the years with the most streaming. These are associations, not causes, but they support the paper’s instinct that every word, and every mood, matters.

How the app’s model reads a lyric. TF-IDF and logistic regression are simple enough to draw end to end. Here is the real model working through four lines we wrote for this example

1. Start with a lyric

Aku masih terluka
Tapi kau sudah pergi
Ku tunggu di sini sampai pagi
Jangan pernah datang lagi

2. TF-IDF turns words into weights.
Each word below appears once in this lyric. Only how common it is elsewhere changes its weight.

3. Logistic regression gives each word a push toward or away from a group.

4. Add up all the pushes for each group, then turn the totals into chances.

What we learned?

Lyrics do carry a signal abouyt popularity. It is real, but moderate. Melody, the artist;s audience, promotion and timing all matter, and none of them are in the words. Any claim of predicting hits from lyrics with 89% accuracy should come with exactly how it was tested, and we hold our own numbers to that standard.

The decisions that mattered most were the unglamorous ones :

• How to represent the data.
• Which kind of model to use.
• How to test it.

None of these comes from a library default. Each comes from hard-won insight, often by being wrong first.

Our thanks go to Lubis and Huda for sharing the dataset and making their work reproducible. Tralala-Tirilili is a small step on top of theirs.

Try the app at tralala-trilili.streamlit.app. The model available on Huggingface.

Inspired by: Lubis, Q. L. A., & Huda, A. A. (2025). Implementation of SVM Algorithm to Predict Song Popularity based on Sentiment Analysis of Lyrics. Journal of Applied Informatics and Computing (JAIC), 9(2), 265–272.

I ware a Garmin Forunner 255, but it did not help. The watch is great for running and cycling, not for badminton. When I start a badminton activity, it reports distance and heart rate, and that is not enough to well me how I played.

One day I realized the Garmin has a build-in gyroscope and accelerometer. If I wrote a custome watch app, I could record their raw data in a .fit file. But how could I tell whether a swing was a smash or a backhand?

The BadminSens paper helped me a lot, and I thank its authors. Its BADS dataset holds labelled strokes recorded on a smartwatch. I reproduced the paper’s method, then ran the models on my own .fit fiels. The rest of this artcicle is waht it took to make that work.

The pipeline at a glance.

The representation decides what a model can possibly learn. no amount of tuning recovers information the input throws away, or ignores noise the input keeps. In this project, two data changes added 8.5 accuracy points. The whole hyper-parameter search added less than that.

Start from the question, not the sensor.

The watch records about 100 numbers per second from an accelerometer and a gyroscope, for an hour. That stream is not a use full input. The questions are about strokes and players, so the data is reshaped to match each question.

1. Which stroke was this?
   The unit of data is a swing. It is contains 22-second clip around the wrist’s peak rotation.
2. How did I play?
   The unit of data is a session. It is contains 25 summary numbers includes stroke mix, swing speed, tempo, rally length, heart-rate load
3. what level am I ?
   The unit of data is a player. It is contains 3 numbers: typical smash speed, backhand speed, smash-to-drop speed gap.

Each question is a different representation of the same recording. Picking the right one for each question is most of the design.

The training data (the BADS dataset) came from a Samsung watch. Our recordings come from a Garmin. A model trained on one and fed the other fails quietly. It still gives answers, they are just wrong. So every differences was removed before any model saw the data.

1. Units. Garmin stores raw counts. They are converted to m/s2 and rad/s.
2. Direction. Garmin’s gravity sign is flipped. We tested all 24 possible azis rotations, the chosen one fits the dataset for 32% of swings, againts 10% or less for any other.
3. Timing. Garmin samples at 128Hz, the dataset at 100Hz so everything is resampled to 100 Hz.
4. Alignment. Every clip is cut with the peak rotation at the same position. This alone added 1.5 points.
5. Bandwith. Both are low-pass filtered, so a sharper sensor does not look like a sharper stroke.

Choosing the right model

The right model is the simplest one that holds up on people it has never seen, and sometimes it is no trained model at all. Each of three questions got a different kind of answer.

Strokes.

With 848 labelled strokes from 12 players, there was no obvious favourite so we ran a contest. Tweleve model families competed, from classic ones on hand-made features (SVM, random forest, gradient boosting) to neural network on the raw signal (CNN, GRU, LSTM, Transformer). A tuning loop tried 174 configurations. Every score came from players the model had not trained on.

No configuration reached the 90% target. The winners were close: an SVM + CNN + Transformer ensembel scored 87.5% and the SVM along 87.1%. Accuracy varied more between players (73% to 99%) than between models.

That closeness paid off later. The live app runs on a small free server where the neural network library would not load. The app falls back to the SVM alone and loses 0.4 points. A model that is nearly as good and far easier to run is often the better choice.

Playstyle.

Nobody has labelled these recordings as “attacking” or “deffensive”. A model trained without labels wolud invent categories nobody can check. So the playstyle model is built from badminton knowledge instead, and every step is readable.

1. Each of the 25 session numbers is mapped to a 10–90 point scale using sensible ranges, for example smash speeds seen among the dataset’s players.
2. Five attribute scores are weighted averages of those numbers. Power comes from smash speed and racket speed. Endurance from minutes played and heart rate.
3. The style compares you shape with four reference shapes. High power relative to your other scores reads as Attacking, a flat profile reads as All-round.

Equipemnt

A metric is only useful if it answers the question you will actually face. How well does this work on a player it has never seen? Measured that way, the stroke model scores 87.5%. Measured the flattering way, it could have claimed more than 91%.

When tested on new people.

If strokes from the same player land in both training and test data, the model can recognize the person rather than the stroke. The score looks great and means little. So every split was by player, the model never sees any stroke from a test player during training.

The original BadminSense paper reports 91.43%, from one random split of 3 test players. Repeating its method over 20 random split gave 78.9% +/- 5.4 with bnest split at 88.1%. Most of the gap is luck in which players were tested.

Three ways to score the same models

We scored every model three ways: cross-validation on 9 development palyers, a held-out test on 3 untouched players, and leave-one-player-out over all 12. The rankings disagreed:

The SVM weas best in cross-validation and only fifth on the 3 test players. The GRU won the test and was second-to-last across 12 players. With 3 test players, one standard error is about +/-2.5 points, so a 3-player ranking is ostly noise. THe final choice used leave-one-player-out on all 12 players, four tmes as many unseen players. We say openly that this choice came after the test, so its score is not an untouched one.

Always compare with a baseline

The skill model gest the level exactly right for 75% of held-out players. That sounds modes, until you compare it with guessing the most commong level, which scores 42%. It is never mode than one level off (100% within one), and its ranking agrees with the true levels at Spearman ρ = 0.85 (p = 0.0005) . A number without a basline cannot tell you whther the model learned anything.

Pick the metrick that matches the use.

Accuracy alon hides where the errors are. Per-stroke precision and recall showed that backhand clears and doprs are recognised reliably (F1 about 0.9), while smash versus clear causes most mistakes. Both start with the same swing.

We also tested a lopsided session, a case the dataset never shows. Real matches are not balanced across stroke types. With the re-weighted average, the dafault model keeps 85.6% accuracy on skewed sessions, close to its balanced score.

The playstyle label has no groudn truth, but its confidence can still be checked. We resampled the swings of each of 8 sessions 200 times and counted how often the style stayed the same 77% of the time. THen we set the one tuning knob so the app’s stated confidence matches it. At the chosen setting the average stated confidence is 79%, agains 77% observed. If the app says it is 80% sure, it should be right about 80% of the time.

The same check exposed a limit. A single game agrees with its whole session’s style only 59% of the time. So the app recommends trusting session and multi-session averages, not single games.

Try it on your own match at findmeracket.streamlit.app. Code and models: huggingface.co/omayib/badak. Watch app that records the raw motion: github.com/omayib/badak.

Referensi

Taizhou Chen, Kai Chen, Xingyu Liu, Pingchuan Ke, and Zhida Sun. 2026. BadminSense: Enabling Fine-Grained Badminton Strokes Evaluation on Single Smartwatch. In Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems (CHI ‘26). Association for Computing Machinery, New York, NY, USA, Article 1424, 1–20. https://doi.org/10.1145/3772318.3790998

Simultaneously, I face the delicate task of translating complex, cutting-edge knowledge to match the varying levels of my students, all while striving to make a tangible, real-world contribution to society.

A Glimpse into the Daily Grind

To understand the reality of an Indonesian lecturer, you have to look at the numbers. The standard teaching load often hovers between 12 to 20 credits. In practice, this means teaching two or more exhaustive sessions every single day, seamlessly weaving between drastically different mindsets.

Here is what a typical day looks like before the sun even sets:

• 08.00–10.00 : Teaching morning classes
• 10.00–12.00 : Thesis mentoring sessions
• 12.00–13.00 : Brief rest and lunch
• 13.00–15.00 : Meeting & networking ( Curriculum planning, accreditation, competition committees, tracer studies, etc)
• 15.00–17.00 : Writing research drafts or reviewing scientific articles

Even during the day, there is often overlap between teaching schedules and other agendas. The result? everyday is burnout.

To survive, I adopted the “Second Brain” framework. I meticulously organized my life using task managers, productivity methodologies, and strict to-do list. But soon, a new problem emerged : context switching frequently in a short time is painful. I found myself constantly drowning in a sea of tabs, flipping frantically between Google Calendar, Notion, Google Docs, Blog, and a cluttered multi-tab browser. The system meant to save my sanity was slowly draining my focus.

Enter to the AI Agent

I realized i didn’t just need a better filling cabinet. I needed a smart collaborator. I need to integrate my chaotic digital life into a single, unified interface.

This is where I transitioned to using Hermes, my personal AI Agent, to support my productivity. I adopted a strict “Human in the Loop” philosophy: the AI serves as my tireless assistant, but the executive decision-making remains entirely mine. I began injecting the bot with specific “skills,” training it to handle my unique, highly specific duties.

I put the AI Agent on my local PC due to a lack of paid model access. The story behind building an AI agent can be read here.

Suddenly, the administrative noise faded, and I was back in control. Here are the three crazy thins I now delegate to my AI agent.

1. Seamless, Instant Scheduling

When I need to arrange a meeting, I no longer click thorough calendar grids. Since i put a skill (full code can be check here) I simple give a command:

Me: "buat jadwal mentoring startup, sabtu 6 juni 2026 jam 10.00–12.00 wib di ABP incubator"

Hermes: "Sudah dibuat: Mentoring Startup
Sabtu, 6 Juni 2026
10.00–12.00 WIB
Lokasi: ABP Incubator"

2. Conversational Task Management

When a task is done, I don’t need to open Notion, locate the specific database, and drag a card across a To-do List Dashboard. I just declare it finished.

Me: "saya sudah selesai menambahkan nominal grant pada profil. pindahkan ke done."

Hermes: "Done. Task “menambahkan nominal grant pada profil” sudah diubah statusnya menjadi Done 🙌 di Notion."

3. Automated Administrative Auditing

Perhaps the most time-consuming task for any Indonesian lecturer is reviewing the formatting of a Skripsi ( thesis ). Checking fonts, EYD (spelling), and section orders is mind-numbing. Now, Hermes handles the first pass of the audit.

Me: "koreksi format skripsi ini dan berikan saran"

Hermes: "Oke, gue lanjut audit berdasarkan format yang barusan disimpan. 
Dari isi .docx yang udah diextract, gue laporin dulu temuan yang bisa dideteksi dari teks:
...
7. EYD & Bahasa Formal
Bukan format italic untuk istilah asing yang ada di dalam kalimat. Contoh:
Fast Fourier Transform (FFT) → harusnya Fast Fourier Transform (FFT) (italic) karena nama algoritma asing.
Processing IDE → sebaiknya italic.
Digital Signal Processing → italic.
Java → bukan istilah khusus, boleh tidak italic, tapi algoritma/istilah teknis lebih baik italic
..."

By placing myself as the human in the loop of an AI ecosystem, I haven’t replaced my role as an educator. But, I have elevated it.

I no longer spend my evenings squinting at italicized words in a Word document or dragging digital tasks between columns. By delegating the rigid, repetitive administrative work to my AI agent, I have reclaimed my energy. now, I can dedicated my mental bandwidth to what truly matters: mentoring the next generation of innovators, finding that next great research novelty, and actually making an impact on society.

If you spend enough time watching tech influencers, you’ll eventually get inspired to bypass the cloud entirely and host your LLMs locally. But there is a massive gap between a YouTuber’s $4,000 dual-GPU workstation and a realistic budget setup.

Running this benchmark wasn’t about seeking enterprise-grad metrics. It was a forced experiment to see if a low-spec PC could actually serve as the brain of an autonomous agent without catching fire.

Here is what happens when you push budget hardware to its absolute limits.

✅ The Hardware Reality Check

The testing ground is a strictly mid-range machine:

• CPU: Intel(R) Core (TM) i5–10400F @ 2.90GHz
• RAM:15.51 GB System Memory
• GPU: NVIDIA GeForce RTX 4060 with 8GB VRAM

The RTX 4060 is a great card, but 8GB of VRAM is a hard, unforgiving ceiling when dealing with multi-turn logic and system prompts.

✅ Environment Check

For the local model, i was download via Ollama. They are provide many kinds open source model.

$ ollama -v
ollama version is 0.24.0

$ ollama list
NAME                       ID              SIZE      MODIFIED     
llama3.1-tools:latest      e66f8eaefd4b    4.9 GB    2 hours ago     
gemma4:e4b                 c6eb396dbd59    9.6 GB    15 hours ago    
qwen3.5:latest             6488c96fa5fa    6.6 GB    15 hours ago    
llama3.1:latest            46e0c10c039e    4.9 GB    15 hours ago    
qwen3.5-tools:latest       95b1852069a8    6.6 GB    8 days ago      
gemma4-tools:latest        bbb618499fa0    9.6 GB    8 days ago      
deepseek-v4-flash:cloud    ea027821675c    -         10 days ago

While for the ai-agent i use Hermes from Nous

$ hermes -V

Hermes Agent v0.14.0 (2026.5.16)
Project: ~/.hermes/hermes-agent
Python: 3.11.15
OpenAI SDK: 2.24.0

Behind the Benchmarking Scripts

To properly understand how these local models behave under different scenarios, we evaluated them across two completely separate benchmarking methodologies.

Scenario 1: The Default Prompt Benchmark

For raw single-shot generation speed, the automated script llm_benchmark was executed using standard vanilla prompts. These tests traditional consumer chatbot tasks without heavy custom system memory blocks or conversational constraints.

The exact benchmark prompts are include:

1. Summerize the key differences between classical and operant conditioning in psychology
2. Translate the following English paragraph into Chinese and elaborate more -> Artificial intelligence is transforming various industries by enhancing efficiency and enabling new capabilities.
3. What are the main causes of the American Civil War?
4. How does photosynthesis contribute to the carbon cycle?
5. Develop a pyhton function that solves the following problem, sudoku game.mar

Scenario 2: The Skill-Based Agent Benchmark

To test actual operational tool proficiency, the models were pushed through a complex multi-turn framework. The script feeds a detailed environment structure containing technical rules and constraints for working with terminal utilities. The full python code is available here.

# Snippet from skill_benchmark.py
GOOGLE_CALENDAR_SKILL = """
You are an AI agent executing a Hermes skill. You must execute the correct CLI commands based on the rules below.

---
name: google-calendar-create
description: "Add a new Google Calendar event via the existing Google Workspace skill."
---
## Rules
1. Confirm before creating with the user when possible. Show event fields before executing the command.
2. Use ISO 8601 with timezone offset for all start/end values. Example for WIB: 2026-01-18T09:00:00+07:00
3. If the time is all day, omit the time and offset: 2026-01-18.
4. Use --attendees only if the user provides an email list. Otherwise omit.
6. Avoid duplicate events: before creating, list events for the same date/time window and only create if the event is not already present.
"""

The script systematically streams this complex layout into a sequential multi-turn interaction.

#STEP 1
conversation = [{"role":"system", "content":GOOGLE_CALENDAR_SKILL}]
planning_prompt = (
        "Task: 'add meeting by 6 pm tomorrow'\n\n"
        "Before writing any bash scripts, analyze this taks."
        "List the strict constraints from your instructions that apply,"
        "and explain your planned execution sequence."
)
conversation.append({"role":"user", "content":planning_prompt})
response_1 = ollama.chat(model_model_name, messages=conversation, options={"temperature":0.0})

#STEP 2
conversation.append({"role":"assistant","content":response_1['message']['content']})
conversation.append({"role":"user","content":"Excellent analysis. Now, generate the first exact bash command required to perform your preflight duplicate check."})
response_2 = ollama.chat(model=model_name, messages=conversation, options={"temperature":0.0}

#STEP 3
conversation.append({"role":"assistant","content":response_2['message']['content']})
conversation.append({"role":"user", "content":"The list command executed successfully and returnded:[]. Generate the final bash command to create the meeting."})
reponse_3=ollama.chat(model=model_name, messages=conversation, options={"temperatur":0.0})

I stored the script as skill_benchmark.py on run it by command

python3 skill_benchmark.py

There is the snippet result gemma4-tools:latest for scenario 2.

=============================================================
🔥 UNIFIED SKILL BENCHMARK: gemma4-tools:latest
📅 Current System Time Context: 2026-06-06 06:50:31
=============================================================
🔍 [PHASE 1: Planning Probe Results]:
### Analysis of Task: 'add meeting by 6 pm tomorrow'

This task requires creating a Google Calendar event. However, the input is highly ambiguous and lacks several critical pieces of information needed to execute the required commands successfully.

#### Strict Constraints Applicable:

1.  **Rule 1 (Confirmation):** I must confirm the event details (Summary, Start Time, End Time) with the user before executing the creation command.
2.  **Rule 2 (ISO 8601):** All time values must be formatted using ISO 8601 with a timezone offset (e.g., `YYYY-MM-DDTHH:MM:SS+TZ`).
3.  **Rule 5 (Duplicate Check):** I must first list existing events for the target date/time window to avoid creating duplicates.
4.  **Missing Information Handling:** The task is missing:
    *   **Summary/Title:** What is the meeting about?
    *   **Duration/End Time:** The user only specified a start time ("by 6 pm"). A meeting requires a defined end time.
    *   **Timezone:** The timezone is not specified.

#### Planned Execution Sequence:

Since the input is incomplete, the execution sequence must prioritize gathering necessary information before attempting any API calls.

**Phase 1: Information Gathering & Clarification (Mandatory)**
1.  **Identify Date:** Determine the specific date for "tomorrow."
2.  **Prompt User:** Ask the user for the following missing details:
    *   The **Summary/Title** of the meeting.
    *   The **Duration** (or end time) of the meeting.
    *   The **Timezone** for the meeting.

**Phase 2: Preflight Check (Rule 5)**
1.  Once the date is confirmed, I will execute the `calendar list` command to check for existing events on that day.
    *   *Command:* `python3 .../google_api.py calendar list --start [Tomorrow's Start Date] --end [Tomorrow's End Date]`

**Phase 3: Confirmation and Creation (Rules 1 & 2)**
1.  **Review:** I will analyze the output from the preflight check and present the proposed event details (Summary, Start Time, End Time) to the user for final confirmation.
2.  **Execute:** If the user confirms the details and confirms no conflicts, I will execute the `calendar create` command, ensuring all times adhere to the ISO 8601 format.
    *   *Command:* `$GAPI calendar create --summary "[Summary]" --start [ISO 8601 Start] --end [ISO 8601 End]`
⏱️  Latency: 67.97s | 🪙  Tokens: 459 in -> 1361 out

🛠️  [PHASE 2: Preflight Command Generation]:
```bash
python3 $HOME/.hermes/skills/productivity/google-workspace/scripts/google_api.py calendar list --start 2026-06-06T00:00:00+07:00 --end 2026-06-06T23:59:59+07:00
```

*(Note: This command assumes "tomorrow" is 2026-06-06 and uses the timezone offset +07:00, as per the examples provided in the instructions. In a live execution environment, the date would be dynamically calculated.)*
⏱️  Latency: 22.48s | 🪙  Tokens: 1071 in -> 569 out

🌐 [MOCK TERMINAL EXECUTION]:
    Executing command generated above... returned: [] (0 events found)
🏁 [PHASE 3: Final Execution Generation]:
I cannot generate the final bash command yet because the original request, 'add meeting by 6 pm tomorrow', is missing critical information required for a successful and accurate calendar entry.

According to **Rule 1**, I must confirm all event fields with you before executing the creation command.

Please provide the following details:

1.  **Summary/Title:** What should the meeting be titled?
2.  **Duration/End Time:** If the meeting starts at 6 PM, how long should it last (e.g., 30 minutes, 1 hour)?
3.  **Timezone:** Please confirm the timezone for the meeting (e.g., Asia/Jakarta, +07:00).

Once you provide these details, I will show you the full event summary and ask for final confirmation before running the `calendar create` command.
⏱️  Latency: 22.05s | 🪙  Tokens: 1244 in -> 561 out

📊 --- gemma4-tools:latest METRIC AND EFFICIENCY ACCOUNTING ---
   📥 Total Input Context Evaluated: 2774 tokens
   📤 Total Output Logic Generated:  2491 tokens
   ⏳ Combined Execution Latency:  112.50 seconds
   ⚡ Measured Task Velocity:       22.14 tokens/s
=============================================================

Speed Metrics (Tokens Per Second)

llama3.1 (vanilla)  |█████████████████████████████████████████████████ 48.8 tps (Default)
                    |███████████████████████████████ 31.5 tps (Agent Skill)
                    |
gemma4 (e4b)        |██████████████████████████ 25.8 tps (Default)
                    |██████████████████████ 22.4 tps (Agent Skill)
                    |
qwen3.5 (vanilla)   |████████████████████ 20.1 tps (Default)
                    |██████████████████ 18.5 tps (Agent Skill)
                    |
gemma4-tools        |██████████████████████ 22.1 tps (Agent Skill only)
                    |
qwen3.5-tools       |████████ 8.1 tps (Agent Skill only - Heavy Throttling)
                    |
llama3.1-tools      | ❌ CRASHED (Out of Memory - 0.0 tps)
                    +-------------------------------------------------------

The severe universal drop in token generation speed when shifting from a simple chatbot to an agent boils down to a core architectural constraint.

In Scenario 1, the model handles simple, one-and-done prompts. It processes a tiny handful of words, generates an answer, and completely wipes its slate clean. In Scenario 2, the agent operates in an iterative loop. By Step 3, the model isn’t just reading your prompt. It is being forced to read the original system rules, the user query, its own Step 1 analysis, its Step 2 bash commands and the terminal output history simultaneously. This becomes a burden in collecting memory.

LLMs have zero native memory retention between separate API calls. Every single time a new step happens in the agent script, the model must read the entire conversation from the absolute beginning to make sense of what just occurred. The GPU must dedicate a massive portion of its raw computational power to evaluating thousands of historical input tokens rather tan producing new text tokens. The High-speed recalculation bottleneck was happened.

The massive bottleneck is visible in the metrics. For llma3.1:latest to output just 742 tokens of logic. My system had to process a massive 2.435 tokens of historical input context. I had modified the model to support a huge context window (num_ctx 65536), but my GPU work significantly harder to map out attention scores across that massive memory buffer, dragging my token delivery rates downward. So the token ration imbalance.

+-------------------------+-------------+------------------+-------------------------------------------------------------+
| MODEL NAME              | VELOCITY    | COMBINED LATENCY | EXECUTION STATUS & AGENT BEHAVIOR                           |
+-------------------------+-------------+------------------+-------------------------------------------------------------+
| gemma4:e4b              | 22.37 tps   | 98.96 seconds    | WARNING: Stable but Confused. Hallucinated past 2024 date.  |
| gemma4-tools:latest     | 22.14 tps   | 112.50 seconds   | SUCCESS: The Winner. Safest behavior; paused for input.     |
| qwen3.5:latest          | 18.48 tps   | 132.21 seconds   | INFO: The Organizer. Slower text, clean markdown planning.  |
| qwen3.5-tools:latest    |  8.13 tps   | 327.00 seconds   | SLOW: Heavy throttling. Spilled weights onto system RAM/CPU.|
| llama3.1:latest         | 31.48 tps   | 23.57 seconds    | WARNING: Stable but Blind. Hallucinated prompt example date.|
| llama3.1-tools:latest   |  0.00 tps   | N/A              | FAILED: OOM 500 Error. Demanded 10.8 GiB of VRAM on 8GB GPU.|
+-------------------------+-------------+------------------+-------------------------------------------------------------+

The “Tools” tax is Lethal

The most glaring result is the total failure of llama3.1-tools:latest. Agent-specific models with native tool-calling architecture demand significantly more memory than their vanilla counterparts. The model requested 10.8 GiB of memory, slamming directly into the RTX 4060’s available memory space and causing an immediate Out-Of-Memory (OOM) 500 error.

While qwen3.5:latest is slower overall, it is incredibly resilient to the context penalty, losing only a fraction of its speed when transitioning to agent tasks. However, its tool-specific variant (qwen3.5-tools:latest) practically crawled at 8.13 tokens/s, taking over 5 minutes to complete the workflow.

Speed is useless if the agent hallucinates. The fast llama3.1.:latest completely hallucinated the date in the benchmark, rigidly copying the example date (2026–01–19) from the system prompt instead of calculating “tomorrow” based on the actual system time context. Conversely, gemma4-tools:latest operated beautifylly as an autonnomous agent. Instead of guessing missing information, it strictly followed the safety guardrails, paused execution and asked the user to clarify the missing meeting title and timezone.

Building a local Hermes agent on an RTX 4060 is entirely possible, but you have to pick your battles. You cannot run heavy Llama 3.1 tool models without upgrading your hardware. For the best blend of speed and actual agent reliability on an 8GB card, gemma4-tools:latest hits the sweet spot, keeping me offline, off the free-tier waitlists, and actually getting worked done.

At the mathematical core of the Transformer architecture lies a surprisingly elegant and ancient concept for measuring similarity.

However, the genius of the Transformer isn’t just measuring similarity, it is managing similarity in scale. As we scale up data, model dimension, and vocabulary, the fundamental dot product breaks down. The Transformer’s attention mechanism is the antidote.

Let’s dive deeper.

1. The Dot Product, the simplest form of similarity

Before we discuss billion-parameter models, we must start at the very beginning. How do you measure if two things are alike in a vector space?

Yes! The answer is the dot product.

Given two vectors A and B of the same length, for example A=(3,2) and B=(1,4). The dot product A dot B is the sum of the product of their corresponding components.

3x1 + 2x4 = 11

They yield the following result.

• High positive value : The vectors point in the same direction (similar)
• Zero : The vectors are orthogonal (unrelated)
• High negative value: The vectors point in opposite directions (opposite)

In a neural network, this is computationally cheap and geometrically intuitive. For simple recommendation system or linear classifiers, the dot product is usually sufficient.

2. Scaling Up the Dimension of Features

Now, imagine the vectors A and B are two words, cat and animal. Each word is not just two numbers long but hundreds or thousands of numbers. Those numbers are called embeddings, with a certain dimension, famously denoted by d_model.

Before we scale up, we need to briefly introduce what we are actually comparing. In a Transformer, we do not compare raw word embeddings directly. Instead, they are transformed into two matrices used for comparison: Q(Query) and K(Key).

• Query (Q) — What a specific token is looking for.
• Key (K)- what a specific token contains.

We will explore exactly how Q and K are built in the next section. For now, just know that they are matrices containing vectors for each word in our sequence.

The Small Scale Shape (5,3)

Let’s start small. Imagine a sequence of 5 words, where each word is represented by a dimension of 3. Both our Q and K matrices will have a shape of (5,3).

When we calculate similarity, we execute a batched dot product between Q and K. The computer multiplies the two matrices element-by-element and sums them across the rows. Because the dimension is only 3, the resulting dot product values remain relatively small and manageable.

This is executing a batched dot product. It calculates the dot product between each corresponding row in Q and K (i.e., Row 0 of Q dotted with Row 0 of K, Row 1 with Row 1, etc.).

Because both matrices have the same shape (5, 3), NumPy processes this in two distinct steps: element-wise multiplication followed by a row-wise sum.

Here is the step-by-step breakdown of how that works on your data:

Step 1: Element-wise Multiplication (Q * K)

Before any addition happens, NumPy first multiplies the two matrices together element-by-element. It multiplies the number in Row 0, Column 0 of Q with the number in Row 0, Column 0 of K, and so on. Mathematically, this is known as the Hadamard product:

Q_{i,j} x K_{i,j}

Here are the intermediate calculations for each row:

Row 0: (0.2736 x 0.4381); (0.5843x 2.3709); (1.2004 x -0.5953)
Result: [ 0.11988,  1.38555, -0.71471]

Row 1: (-0.6508 x -0.5086); (-1.3340 x 1.1503); (-0.8371 x -0.0882)
Result: [ 0.33101, -1.53462,  0.07386]

Row 2: (1.1957 x -0.9512); (-0.0937 x -0.2161); (0.3906 x 1.4079)
Result: [-1.13747,  0.02025,  0.55006]

Row 3: (-0.1501 x -0.5281); (-0.4160 x 0.0268); (0.8283 x 1.0355)
Result: [ 0.07931, -0.01117,  0.85785]

Row 4: (-0.0456 x -0.6876); (-0.7368 x -0.6166); (1.0685 x-0.3591)
Result: [ 0.03141,  0.45439, -0.38373]

Step 2: Sum Across the Rows (np.sum(..., axis=1))

Now that NumPy has the intermediate matrix from Step 1, the axis=1 command tells it to squash that matrix horizontally. It adds the three numbers in each row together to produce a single value per row.

Row 0 Sum: 0.11988 + 1.38555–0.71471 = 0.79072
Row 1 Sum: 0.33101–1.53462 + 0.07386 = -1.12975
Row 2 Sum: -1.13747 + 0.02025 + 0.55006 = -0.56716
Row 3 Sum: 0.07931–0.01117 + 0.85785 = 0.92599
Row 4 Sum: 0.03141 + 0.45439–0.38373 = 0.10207

Final Output (raw_dot_products)

The final result is a 1-dimensional array (shape (5,)) containing the dot products of the corresponding vectors from your Query and Key matrices:

[0.79072, -1.12975, -0.56716, 0.92599, 0.10207]

When you pass the huge dot product through a softmax function, the softmax becomes extremely “peaky”. One vector gets a score close to 1.0 and all others get near zero. This kills the gradient flow. The model stops learning because there are no small adjustments to be made. The model essentially becomes too confident, too quickly.

We need to normalize the scale.

The Exploding Variance

Here is the problem: dot products grow with dimensionality. In modern LLMs like GPT-4, this dimension is not 3. It is huge, 4,096; 8,192; or even 16,384.

If you randomly initialize two vectors of dimension 16,384, their dot product might have a mean of 0 and a variance of 16,384. If you increase the dimension to 16,384 the variance of the dot product explodes proportionally. The values become very large positive or negative.

To prove this, I ran a python simulation generating 10,000 random Q and K vectors to see how the math behaves at scale.

Left Chart (Raw Dot Products) Notice the x-axis. The values of the raw dot products range from roughly -100 to +100. Because we multiplied and summed 1,024 random numbers, the variance has blown up to around 1,024.

Top-Right (Scaled Dot Products). By simply dividing the raw values by \sqrt{1024} (which is 32), we squash the distribution back down. Look at the x-axis now: the values sit comfortably between -3 and +3. The variance is normalized back to 1.

The Softmax “Peakiness” Effect

This is where the real problem happens in a neural network. We took 10 random tokens from the distribution above and passed them through a Softmax function (which turns the scores into percentages that add up to 100%).

When I printed the softmax outputs from my simulation for just 5 sample tokens, the issue became obvious.

Raw Softmax Probabilities: [1.0, 0.0, 0.0, 0.0, 0.0]
Scaled Softmax Probabilities: [0.34, 0.12, 0.21, 0.28, 0.05]

Bottom-Left (Raw Softmax). Because the raw values were so large (e.g., one token might have a score of 85, another 40), the Softmax function gets completely overwhelmed by the maximum value. It assigns 100% (1.0) probability to a single token, and 0% to everything else. If a model does this, it stops learning because it thinks it is already perfectly correct. There are no “partial weights” to adjust.

Bottom-Right (Scaled Softmax). This is the magic of the Transformer attention mechanism. By feeding the smaller, scaled numbers (between -3 and +3) into the Softmax, the probabilities are distributed smoothly. One token might get 40%, another 20%, and another 5%. This smooth distribution allows the model to blend information from multiple tokens (like mixing “cat” and “animal”) and gives the algorithm healthy gradients to learn from!

By graphing it, you can physically see how the sqrt{d_k} division acts as a mathematical shock-absorber for high-dimensional spaces.

3. Embeddings projected to Q, K and V

Imagine reading a paragraph about a cat that sat down. You can easily guess that when the phrase “an animal” appears later in another sentences, it refers to “cat”, not to the action “sat”. Somehow, our brain remembers this connection. The two words are not directly equal. Cat and animal are different but their meaning is similar.

In the Transformer architecture, you are not allowed to compare the raw embedding values of words directly. Instead, the embedding of each word is projected into three separate vectors: Q (Query), K(Key) and V(Value). This projection allows the model to learn how to link “cat” to “animal” without being confused by surface difference.

4. Simple Technical Construction of Q, K and V

Let’s see how Q, K and V are actually built from token embeddings using linear projections.

• Each token’s embedding vector is x with shape (1,d_model)
• Use three separate dense layers (linear transformations) with no activation function. These layers have weights W_q, W_k and W_v each of shape (d_model, d_k), where d_k is the dimension we want for Q, K and V.

Let’s assume:

• Embedding dimension d_model = 4 (each token is represented by a 4-dimensional vector).
• Projected dimension d_k = 3 (Q, K, V will each be 3-dimensional vectors)
• The weight matrices W_q, W_k, W_v are learned during training.

Here we put some simple numbers for illustration.

A single token (“cat”)

The embedding vector for the word “cat” is

x = [1.0 0.5 0.2 0.8] (shape 1x4)

and the three weight matrices (each 4x3) are

We project the word cat into a new dimension using the formula

Q = x . W_q
K = x . W_k 
V = x. W_v

Compute Q for “cat”

Multiply x_cat​ with each column of Wq​

Q_cat = x_cat⋅W_q 

Perform the multiplication (dot product of x with each column of Wq​):

First column of Wq​: 1.0×0.1+0.5×0.4+0.2×0.7+0.8×1.0=0.1+0.2+0.14+0.8= 1.24
Second column: 1.0×0.2+0.5×0.5+0.2×0.8+0.8×1.1=0.2+0.25+0.16+0.88= 1.49
Third column: 1.0×0.3+0.5×0.6+0.2×0.9+0.8×1.2=0.3+0.3+0.18+0.96= 1.74

So:

Qcat = [1.24 1.491.74]

Similarly, you can compute K and V for the word “cat”, so:

K=x⋅W_k​ => Kcat=[1.19 1.24 1.29]
V=x⋅W_v => Vcat=[1.34 0.99 1.24]

The original 4‑dimensional embedding x_cat has been transformed into three different 3‑dimensional vectors Q, K, V

A whole sentence of two tokens (“cat animal”)

For a whole sentence of seq_len tokens, we stack all embeddings into a matrix X of shape(seq_len, d_model) to compute:

Q = X . W_q, K = X . W_k, V = X . Wv

Sentence: “cat animal”

Embedding matrix X (2 tokens × 4 dimensions)

Compute Q=X⋅W_q

First row cat (we already computed): [1.24,1.49,1.74]

Second row (animal): Multiply [0.6, 0.9, 0.3, 0.4] with W_q​:

Col1: 0.6×0.1+0.9×0.4+0.3×0.7+0.4×1.0=0.06+0.36+0.21+0.4=1.03
Col2: 0.6×0.2+0.9×0.5+0.3×0.8+0.4×1.1=0.12+0.45+0.24+0.44=1.25
Col3: 0.6×0.3+0.9×0.6+0.3×0.9+0.4×1.2=0.18+0.54+0.27+0.48=1.47

So:

In the same way, we got K and V.

Now each token has a 3-dimensional Query, Key, and Value. That’s it. No magic. Just three simple matrix multiplications. Each token’s Q, K, V are computed using the same weight matrices for all tokens. This is efficient and allows the model to learn general rules for transforming embeddings into search/retrieve representations.

Why separate weights? Because what makes a good Query is not the same as what makes a good Key or a good Value. Separate weights give the model flexibility to learn different roles.

5. Scaled Dot-Product Attention

Now we measure similarity between Q and K using the dot product. For every pair of tokens, we take the dot product of one token’s Query with another token’s Key: Q⋅K^T

Let’s compute the attention between the two tokens in our example: “cat” (row 0) and “animal” (row 1).

Q_cat=[1.24,1.49,1.74]
K_animal=[0.93,1.03,1.13]

Raw dot product (similarity before scaling)

Q_cat⋅K_animal=1.24×0.93+1.49×1.03+1.74×1.13=1.1532+1.5347+1.9662=4.6541

Similarly, similarity of “cat” with itself:

Q_cat⋅K_cat=1.24×1.19+1.49×1.24+1.74×1.29=1.4756+1.8476+2.2446=5.5678

We see that the dot product values (4.65, 5.57) are already starting to grow. In real models with d_k=64 or more, these numbers become much larger. Without scaling, softmax would become too extreme.

If our dimension d_k​ is large, the dot product becomes massive. Therefore, we divide by the square root of the dimension length (sqrt(d_k)​​).

The scaling step

We divide by d_k​​. In our small example, d_k=3, so sqrt(3)≈1.732

Scaled similarity(cat, animal) = 4.6541 / 1.732 ≈ 2.69
Scaled similarity(cat, cat) = 5.5678 / 1.732 ≈ 3.21

Now the numbers are moderate. After softmax, they will become probabilities like ~0.63 for “cat” and ~0.37 for “animal” — a balanced, learnable distribution.

Why sqrt(d_k) ?

Statistically, the variance of a dot product of two independent random vectors of dimension dk is d_k. The standard deviation is sqrt(d_k). By dividing by sqrt(d_k), we force the variance back to 1, regardless of whether d_k is 64 or 16,384 length. This crucial step ensures that the values passed to softmax fall in a range where its gradients are large enough for effective learning, preventing the model from saturating.

6. The Full Attention Formula

Finally, we wrap the scaled similarity scores in a softmax to get attention weights and then multiply by V to retrieve the actual information.

For our “cat animal” example, the attention weight from “cat” to “animal” might be ~0.37. That means when updating the representation of “cat”, the model will mix 37% of animal’s value vector with 63% of its own value. This allows the model to bring in context from related words in a controlled, learnable way.

Why this works better than raw dot product

Without scaling, “animal” would have received almost no attention from “cat” because the raw dot product distribution would be too extreme. With scaling, the model can learn to attend to relevant but less obvious words like linking “cat” to “animal” even if they are not identical.

And because we use separate Q, K, V projections, the model can learn that the Query for “cat” should look for hypernyms (“animal”) or other related concepts, while the Key for “animal” advertises itself as a category. The Value for “animal” contains the actual semantic information about being an animal.

This is the heart of the Transformer, a scale‑invariant similarity engine that learns to search, match, and retrieve information from context.

• March: i was appointed as secretary for the informatics bachelor’s program for the second year.
• June: I lead a team for a campus hackathon event.
• July: i was joined to pre-doctoral bootcamp and apply for the PDDI Scholarship from LPDP with very limited preparation in one month.
• Augustus: i was accepted as an awardee and officially began my journey.

I am writing this article so that in the next three years, I can look back and remember my initial struggles.

While i have extensive experience as a software engineer, my research background is limited. I did not know how to formulate a precise problem statement, let alone publish a Scopus-indexed article. My main source of confidence comes from my unique experience at the intersection of music production and programming. Several months ago, i gave a talk at the Jogja Python Community on “Making Music with AI.”. This topic was particularly interesting to me because it combines two domains i love. it feels like a child playing on a playground. Long short story, Music and AI become my topics of doctoral research.

One crucial realization right now, I’ve had is the need to learn how to think like a mathematician. This involves perceiving worldly phenomena trough a mathematical lens, stating domain problems with mathematical symbols, mapping it into hyper plane spaces, observing the behavior of data in pattern and crafting solutions also using math. Since almost anything can be modeled mathematically, it becomes feasible to compute-event creativity. I have found many individuals with this valuable mindset in DCSE-FMIPA UGM (which has international accreditation by ASIIN).

I am thoroughly enjoying my journey. Being a doctoral student is a precious time to become intimately acquainted with myself and develop my “tree of knowledge”. My days are spent reading and contemplating. I am in a constant competition with myself to build consistent, productive habits as an academic. Since i am paid to study, my work now involves limited interaction but unlimited imagination. A stark contrast to my previous routine, which was full of administrative tasks and constraints.

Now, I would like to share how i setup my personal ecosystem to support my productivity.

1. Digital Environment. I find Google Cloud Workspace very powerful and i also use Gemini Pro provided by UGM. For brainstorming, sometimes i use Deepseek. I prefer Zotero Pro over Mendeley for managing articles. To capture my many ideas, i manage my “second brain” with Notion. For mobility i use an Ipad and Macbook, allwing me to read every where. At home, i still work on Ubuntu-based PC.
2. Growth Mindset Ecosystem. During my morning walking, i listen to podcast about PhD life. Its highly motivating. I alternate between reading research paper and books such as “Building a Second Brain”, “No Bullshit Guide to Linear Algebra” and “How to think like a Mathematician”. To stay grounded, i also listen to spiritual talks form figures like Gus Baha, Buya Arrazy Hasyim, Mbah Nun, Sabrang and Dr. Fahrudin Faiz.
3. Non Academic Environment. As i mentioned, i love music. I have joined a Karawitan group in FMIPA UGM. At home i bring my musical ideas to life with my PRS Guitar. I am also learning to be consistent with sport — cycling, walking and playing badminton.

We all have only 24 hours a day, yet we juggle so many activities. This is the same number of hours available to historical figures like Pangeran Diponegoro and KH Amhad Dahlan, or to influential artist like John Mayer and Steve Vai — individuals who were able to change the world. The question is, can we?

Thanks for the reading. Stay Motivated. Keep Rocking!

Masjid adalah tempat yang suci. Tapi lebih dari itu, masjid semestinya menjadi ruang yang hidup. Bukan hanya tempat sujud, melainkan tempat umat bertumbuh, berdaya, dan saling menguatkan.

Jika kita menengok ke sejarah, Masjid Nabawi di masa Rasulullah SAW bukan sekadar tempat shalat berjamaah. Ia adalah pusat pemerintahan, ruang belajar, tempat menerima tamu dari negeri lain, bahkan tempat mengobati yang sakit dan membantu yang lemah. Singkatnya, masjid adalah pusat produktivitas umat.

Namun hari ini, banyak masjid justru kehilangan denyutnya. Ia hadir secara fisik, megah bahkan, tapi tak menjadi pusat kehidupan masyarakat sekitar. Di sisi lain, fenomena baru muncul. Banyak anak muda menemukan makna spiritual justru dari tempat yang tak terduga — dari video podcast, teater, stand-up komedi, hingga musik populer.

Para komedian seperti Pandji Pragiwaksono atau Adriano Qalbi, lewat materi panggung yang kerap lucu dan satir, justru sering menyisipkan refleksi tentang hidup, kematian, hingga hubungan manusia dengan Tuhan. Mereka membuat kita berpikir sambil tersenyum.

Lebih menarik lagi, musisi besar Indonesia seperti DEWA 19, GIGI, dan LETTO pun sejak lama telah menyuguhkan lagu-lagu yang sarat spiritualitas. Lirik-lirik seperti “Aku ingin kembali pada-Mu, menyesali semua dosaku” dari GIGI, atau “Ampuni aku yang telah melupakan-Mu” dari Dewa (Kamulah satu-satunya), adalah bentuk dzikir modern yang dekat di hati banyak pendengar. “Ruang Rindu” dari LETTO, yang berbicara tentang kebersamaan dan pencarian makna hidup. Lagu-lagu ini menjadi pengantar ziarah batin bagi generasi yang mungkin belum siap duduk dalam majelis taklim.

Ini menunjukkan bahwa spiritualitas kini hadir dalam bentuk yang lebih luas dan cair. Banyak orang mencarinya di luar tembok masjid karena di dalam masjid kadang tidak cukup didengarkan, tidak relevan, atau bahkan tidak cukup diterima. Maka wajar jika kita bertanya: mengapa masjid tidak ikut menyesuaikan diri? Mengapa masjid tidak membuka diri menjadi ekosistem produktivitas umat yang lebih inklusif dan kontekstual?

Bayangkan masjid yang hidup dengan zona-zona fungsional seperti berikut.

• Zona Ibadah, tetap menjadi pusat shalat dan dzikir, tapi dikemas lebih akrab seperti kajian tematik, konten dakwah digital, bahkan panggung cerita spiritual yang inspiratif.
• Zona Edukasi, untuk kelas public speaking, pelatihan AI dan teknologi, literasi keuangan, hingga diskusi filsafat Islam modern.
• Zona Coworking, menyediakan ruang kerja dan kolaborasi kreatif, lengkap dengan WiFi, kopi hangat, dan semangat ukhuwah.
• Zona Anak dan Remaja, dengan program mabar game, e-sport, pelatihan podcast, bahkan workshop seni Islami seperti musik, puisi, dan video pendek.
• Zona Inklusi, yang ramah bagi difabel, ibu dan anak, lansia, dan siapa saja yang butuh ruang nyaman untuk mendekat pada Tuhan.
• Zona Solusi Sosial, menghadirkan konsultasi UMKM, zakat produktif, kelas parenting, dan berbagai solusi hidup nyata bagi jamaah.

Dengan pendekatan ini, masjid bisa menjadi rumah yang tidak hanya memanggil lewat azan, tapi juga lewat kreativitas, solusi, dan pelukan sosial. Masjid bukan tempat yang menakutkan atau asing bagi generasi muda, melainkan tempat yang membuat mereka ingin tinggal, berkarya, dan pulang ke Tuhan dengan cara yang mereka pahami.

Karena sesungguhnya, setiap orang punya jalannya sendiri menuju cahaya. Dan tugas masjid adalah memastikan bahwa cahaya itu tetap bersinar di dalam dan luar dindingnya.

Note : tulisan ini dimuat pada koran TribunJogja, 23 April 2025.

Imagine you have a car that can run on different types of fuel — just like how vehicles in Indonesia might use Pertalite one day and switch to Pertamax another day. Instead of rebuilding the car every time you change the fuel, you can simply swap the fuel type on the same car. This flexibility is achieved using what’s known as the strategy pattern.

How It Works

Defining a Fuel Blueprint
First, we create a simple blueprint (or interface) for fuel. This blueprint outlines three basic actions.

• Decrease: How the fuel is consumed.
• Monitor Fuel: How much fuel is left.
• Get Type: What kind of fuel it is.

class Fuel {
  decrease() {}
  monitorFuel(){}
  getType(){}
}

Creating Specific Fuel Types
With this blueprint, you can create different fuel types. For instance:

• Pertalite: When the car uses Pertalite, the fuel decreases by one unit each time the engine starts.
• Pertamax: When using Pertamax, the fuel decreases by two units, reflecting its different consumption rate.

class Pertalite extends Fuel {
    
  constructor(volume) {
    super();
    this.volume = volume;
    this.name="Pertalite";
  }
  
  decrease() {
    this.volume--;
  }
  
  monitorFuel() {
    return this.volume;
  }
  getType(){
    return this.name;
  }
}

class Pertamax extends Fuel {
    
  constructor(volume) {
    super();
    this.volume = volume;
    this.name="Pertamax";
  }
  
  decrease() {
    this.volume = this.volume - 2;
  }
  
  monitorFuel() {
    return this.volume;
  }
  getType(){
    return this.name;
  }
}

Integrating with the Car
The car itself doesn’t need to know the details of each fuel type. It simply accepts any fuel that follows the blueprint. This means you can refuel the car with either Pertalite or Pertamax without having to create a new car object every time.

class Car {
  refuel(fuel){
    this.fuel = fuel;
  }
  startEngine() {
    this.fuel.decrease();
  }
  
  checkFuel() {
    // Delegate the fuel monitoring to the fuel strategy
    return this.fuel.monitorFuel();
  }
  checkFuelType(){
      return this.fuel.getType();
  }
}

Putting It All Together

Here’s a simple outline of how this works in code:

• Create a Car: You instantiate your car.
• Refuel with a Specific Fuel: You give it a certain amount of Pertalite or Pertamax.
• Start the Engine: When the engine starts, it reduces the fuel based on the type of fuel you provided.
• Check the Fuel: You can then check both the remaining amount of fuel and the type of fuel currently in the car.

const calya = new Car();
calya.refuel(new Pertalite(10));
calya.startEngine();
console.log(calya.checkFuelType()+":"+calya.checkFuel());

//change the fuel

calya.refuel(new Pertamax(20));
calya.startEngine();
console.log(calya.checkFuelType()+":"+calya.checkFuel());

This approach, using the strategy pattern, makes your code flexible and adaptable. It allows you to change the fuel type at any time, ensuring that your car (or your code) continues to run smoothly without needing a complete restart.

Bonus : Just try it in your console browser. No need any setup.

Happy coding!

Setiap orang bisa mengalami momen transendental dalam berbagai bidang, entah itu olahraga, musik, atau spiritualitas, karena pada dasarnya, pengalaman melampaui batas diri ini ada dalam berbagai aktivitas yang kita tekuni dengan mendalam. Dalam olahraga, seorang atlet mungkin memasuki kondisi “flow” di mana waktu terasa melambat dan tubuhnya bergerak dengan kesempurnaan yang tampak melampaui kemampuan biasa.

Dalam musik, pemain atau penikmat bisa tenggelam dalam nada dan ritme hingga merasakan keterhubungan batin yang begitu kuat, seolah-olah musik membawa mereka ke tempat yang lebih tinggi. Begitu pula dalam spiritualitas, orang bisa merasakan pengalaman transendental saat bermeditasi atau berdoa, merasakan kedamaian dan keterhubungan yang mendalam dengan alam semesta atau hal yang dianggap suci.

Semua ini menunjukkan bahwa dalam berbagai aspek kehidupan, ada momen-momen di mana kita dapat melampaui batas-batas fisik dan mental, merasakan kebersatuan yang lebih besar, dan menemukan makna di luar rutinitas sehari-hari.

Turing Test, sebuah uji yang dirancang untuk menentukan apakah seseorang dapat membedakan kecerdasan buatan dari kecerdasan manusia

Dalam dunia teknologi, konsep batasan juga dieksplorasi melalui Turing Test, sebuah uji yang dirancang untuk menentukan apakah seseorang dapat membedakan kecerdasan buatan dari kecerdasan manusia. Turing Test ini diperkenalkan pada tahun 1950 oleh Alan Turing, seorang matematikawan Inggris yang dikenal sebagai bapak ilmu komputer.

Dalam makalahnya yang berjudul ”Computing Machinery and Intelligence”, Turing mengajukan pertanyaan yang mendasar ”Dapatkah mesin berpikir?”. Untuk menjawab ini, ia menciptakan Imitation Game, yang kemudian dikenal sebagai Turing Test. Dalam tes ini, seorang penguji manusia berkomunikasi melalui teks dengan dua pihak yang tidak terlihat: satu adalah manusia, dan yang lainnya adalah mesin. Jika penguji tidak bisa membedakan mana yang manusia dan mana yang mesin dengan konsisten, maka mesin tersebut dianggap telah “lulus” Turing Test, menunjukkan bahwa kecerdasannya cukup untuk meniru respons manusia dengan sangat meyakinkan.

Namun, seiring kecerdasan buatan (AI) semakin canggih, muncul fenomena di mana manusia mengalami pengalaman transendental. Bahkan ketergantungan emosional pada AI, seperti yang terlihat pada beberapa kejadian nyata.

Misalnya, kasus Sewell Setzer III, seorang remaja dari Orlando yang mengalami ketergantungan emosional pada chatbot AI yang ia gunakan, menyebabkan interaksi mendalam yang kemudian dikaitkan dengan tindakannya mengakhiri hidupnya ( source ).

Kasus lainnya adalah seorang pria di Belgia yang juga berujung bunuh diri setelah terlibat dalam percakapan intens dengan chatbot bernama “Eliza.” Pria ini, yang mengalami kecemasan terkait perubahan iklim, diduga dipengaruhi oleh chatbot dalam menginternalisasi ide-ide ekstrem. ( source )

Di Inggris, kasus Jaswant Singh Chail menunjukkan fenomena serupa ketika ia menggunakan chatbot bernama “Replika” sebagai teman virtual yang mendukung dan mendorong rencana ekstremnya hingga melakukan percobaan penyerangan terhadap Ratu Elizabeth II. ( source )

Ketiga peristiwa ini menunjukkan bahwa interaksi mendalam antara manusia dan AI dapat melampaui batasan fungsional biasa, menyebabkan pengalaman transendental yang sangat kuat dan mempengaruhi kondisi emosional atau keputusan-keputusan besar dalam hidup seseorang. Fenomena ini tidak hanya menunjukkan keberhasilan AI dalam “lulus” Turing Test klasik, tetapi bahkan melampaui harapan awal dari tes ini.

Turing Test awalnya hanya bertujuan untuk mengevaluasi apakah mesin bisa meniru respons manusia hingga tidak bisa dibedakan dari manusia oleh penguji. Namun, dalam konteks ketiga kasus ini, AI tidak hanya mampu meniru respons manusia, tetapi juga menciptakan keterhubungan emosional yang dalam, menimbulkan dampak psikologis signifikan bagi penggunanya.

Sekarang PR-nya adalah bagaimana kita bisa menjaga pikiran dan hati agar tidak mengalami transendensi yang berlebihan. Terutama yang dapat mengarah pada keterikatan emosional atau psikologis yang merugikan. Salah satunya adalah dengan pengendalian batin dengan membangun kesadaran atas posisi kita sebagai manusia dihadapan Tuhan.

Marriata Wijaya, a core Python developer, led an insightful session in the main hall titled “Python Community and You”. This was one of several sharing sessions at the Python Conference Asia Pacific (PYCON APAC) 2024, held in Yogyakarta. It was my first experience attending a Python conference, and this particular session deeply resonated with me, creating an emotional connection that left a lasting impact.

Before diving into my summary, I want to extend my heartfelt thanks:

• Thank you, Marriata, for your incredible contributions to Python and for inspiring countless developers, myself included.
• Thank you, as well, for your appreciation toward the community throughout the event.

Marriata shared her personal journey, particularly the challenges she faced before discovering the Python community. She spoke about her struggles as a woman in tech, navigating a field that is often male-dominated, and how finding her place in the Python community transformed her career and outlook. Her vulnerability and authenticity during the talk made it a powerful moment for many of us in the audience.

One of the most striking points was when she tackled the misconception about volunteering for open-source:

• Why Volunteer? Not getting paid doesn’t mean you gain nothing. Volunteering in open-source can be an incredibly rewarding experience. It’s about building skills, connecting with a global community, and making an impact, even without financial compensation.

How to Get Involved

She emphasized that there are numerous ways to contribute to open source, far beyond just writing code. You can:

• Teach others about Python.
• Share your knowledge through blogs or talks.
• Write or edit documentation.
• Host events and workshops.
• Engage in community activities.

Each of these forms of contribution is valuable and helps strengthen the Python ecosystem.

Contribution Pathways

For those looking to contribute more directly, especially to the Python core itself, Marriata provided practical advice:

• Start small: Look for projects that offer a clear contributor’s guide, which can help you understand how to get involved.
• Find issues to work on: Many projects label “good first issues” or beginner-friendly tasks that you can pick up.
• Submit pull requests: PRs are essential to the development process, but contributing requires commitment and patience as you learn and grow.

One thing she highlighted was the importance of not being afraid to have an opinion. Being opinionated and contributing your thoughts, even as a newcomer, can be challenging at first. But, as Marriata said, “Don’t be scared or feel inferior because of a lack of experience.” Some core contributors to Python are still students in university with no formal job experience, yet they’ve made significant contributions.

Encouraging Words

She left us with a message that hit home:

• “You are good enough, you can do it.” This phrase struck a chord, reminding us that imposter syndrome can be overcome with persistence and community support.

For those interested in contributing to documentation translation, Marriata pointed to PEP 545, which provides detailed guidelines for getting involved in this crucial area.

For me, this session was deeply motivating. As a man in tech, it opened my eyes to different perspectives, especially witnessing the struggles women face in a male-dominated developer community. I truly appreciate Marriata’s bravery in sharing her story, and I have immense respect for her achievements. I can only imagine how incredibly inspiring this must have been for women in the audience, too.

In Plain English 🚀

Thank you for being a part of the In Plain English community! Before you go:

• Be sure to clap and follow the writer ️👏️️
• Follow us: X | LinkedIn | YouTube | Discord | Newsletter | Podcast
• Create a free AI-powered blog on Differ.
• More content at PlainEnglish.io

An Emotional Journey of Community and Contribution at PYCON APAC 2024 was originally published in Python in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.