{ "componentChunkName": "component---src-pages-blog-index-js", "path": "/blog/", "result": {"data":{"allMarkdownRemark":{"edges":[{"node":{"frontmatter":{"title":"When Agentic Coding Meets Startup Reality","description":"A founder story that showed me what AI can accelerate and what it cannot replace","slug":"/blog/agentic-coding-meets-startup-reality","date":"2026-07-01T00:00:00.000Z","tags":["AI","Startup","Culture","Engineering"],"draft":false},"html":"

I recently interviewed with a founder who had a big business idea and a very small budget.

\n

At first, it sounded like most of the work was already done.\nHe told me the product was basically built, and he just needed a technical partner to help with the backend.

\n

He shared an AI-generated document with me.\nIt had a lot of technical concepts in it.\nTo be honest, even for me as a software architect, it was not easy to understand right away.

\n

My first reaction was something like:

\n

Wow.\nThis guy may have built a whole system without a technical background.\nAgentic coding is really changing the game.\nMaybe Claude is coming for my job soon.

\n

That was honestly my feeling in the moment.\nI was kind of impressed, kind of confused, and kind of thinking, \"okay, what is really going on here?\"\nHonestly, I had that tiny little fear in my chest like, \"great, maybe I really am about to be replaced by a guy with a laptop and Claude.\"

\n

But then I took a deeper look.

\n
\n

The deeper look

\n

Once I started digging in, the picture changed very quickly.

\n

What looked like a finished system was really more like a rough setup made to look finished:

\n\n

It was not a disaster.\nBut it was also not a finished product.

\n

And that is the part I think a lot of people miss right now.

\n

AI can make something look much more complete than it really is.\nIt can generate the shape of a product before the product is actually ready.

\n

That can be useful.\nIt can also be very misleading.\nIt can even make a messy idea feel like a polished startup if you do not look too closely.

\n
\n

What the founder really needed

\n

At first, he said he needed a technical partner who could help with some tech.

\n

But after we talked more, it became clear that what he really needed was not just technical execution.\nHe needed reality, gently but clearly.

\n

He needed:

\n\n

That is where I had to slow things down.

\n

I had to explain some basic technical concepts.\nI had to point out blockers.\nI had to show him why the current setup would not scale the way he thought it would.

\n

Honestly, it was not easy.\nIt took patience.\nIt took honesty.\nAnd it took a lot of back-and-forth.\nThere were moments where I wanted to say, \"bro, this is not a backend, this is a dressed-up demo.\"\nBut I also knew that would not help.

\n

But I think that conversation mattered.\nSometimes the most helpful thing is not saying yes.\nIt is helping someone see the whole picture.\nEven if the picture is a little ugly at first.

\n
\n

Why this experience stayed with me

\n

What stayed with me was not the AI-generated document.\nIt was the gap between appearance and reality.

\n

Agentic coding is awesome.\nIt really is.\nIt lets non-technical founders move faster, prototype earlier, and think more concretely.

\n

That is a huge win.\nI am not even being sarcastic here.\nThat part is genuinely exciting.

\n

But there is a difference between:

\n\n

That difference shows up in production.\nIt shows up in deployment.\nIt shows up in how systems behave when real users hit them.\nIt shows up in the boring details:

\n\n

That is where the real work lives.\nThat is also the part nobody can fake for very long.\nThe internet is full of people faking it for a while.\nProduction has a funny way of exposing everybody.

\n
\n

The honest conversation

\n

Eventually, I gave him a more transparent view of the project and the idea.

\n

That conversation changed things.

\n

The good news is that he did not abandon the idea.\nHe did not throw everything away and start another fuzzy concept built on another one-page HTML repo.\nWhich, honestly, would have been the most startup thing ever.

\n

Instead, he started to understand the difference between:

\n\n

That is a healthy shift.

\n

Because once a founder sees the gap clearly, they can make better decisions.

\n

They can ask better questions.\nThey can build with more intention.\nThey can stop confusing momentum with product maturity.

\n
\n

What I learned from this

\n

This experience reminded me of a few things.

\n

First, agentic coding is not fake.\nIt is very real, and it is already changing how people build.\nAnd yes, it is a little scary sometimes.

\n

Second, technical clarity still matters a lot.\nEven if an idea is born in AI, the system still has to survive real users, real deadlines, and real infrastructure.

\n

Third, founders do not always need someone to say yes.\nSometimes they need someone who can make the truth easier to understand.

\n

That is a big part of being a good technical partner.

\n

You are not just building software.\nYou are helping someone understand what software can and cannot do.

\n
\n

My takeaway

\n

I was actually happy to help.\nNot because I enjoy cleaning up chaos.\nWell, maybe a little.

\n

Not because the project was perfect.\nNot because everything was clean.\nBut because it gave me a chance to stand close to a founder who was trying to build something real, even if the starting point was messy.\nThat part felt meaningful.\nI like helping people get from \"vibes\" to something real.\nEspecially when they are trying hard and honestly do not fully know what they are doing yet.

\n

That is part of startup life too.

\n

The best ideas often begin with confusion.\nThe job is to turn that confusion into structure.

\n

And if agentic coding helps more people start the journey, that is a good thing.

\n

But it still takes humans to turn the first draft into a real business.

"}},{"node":{"frontmatter":{"title":"TDD In The Age Of AI Agents","description":"Why tests matter even more when code is generated faster than ever","slug":"/blog/tdd-in-the-age-of-ai-agents","date":"2026-06-29T00:00:00.000Z","tags":["AI","Engineering","Culture","Product"],"draft":false},"html":"

I have been thinking a lot about how software development is changing.

\n

Not because writing code is going away.\nBut because the way we get to working code is changing very fast.

\n

AI agents can now draft features, refactor files, create tests, and even fix bugs in a way that would have felt impossible a few years ago.\nThat is exciting.\nIt is also dangerous if we stop paying attention to discipline.

\n

For me, that is where TDD becomes more important, not less.

\n
\n

The new reality

\n

Agentic development changes the shape of the work.

\n

Instead of spending all your energy on typing every line yourself, you spend more time:

\n\n

That is a different job.\nAnd it requires a different kind of focus.

\n

The biggest shift is not technical.\nIt is psychological.

\n

When code comes back quickly, it becomes very easy to mistake speed for correctness.\nThat is exactly where TDD helps.

\n
\n

Why TDD still matters

\n

TDD gives you a small but powerful loop:

\n\n

That loop is valuable in normal development.\nIt becomes even more valuable when an agent is involved.

\n

Why?

\n

Because tests are a form of truth.\nThey help you separate:

\n\n

That separation matters.\nAgents are good at producing options.\nThey are not always good at understanding the shape of the problem the way a human does.

\n

If the test is weak, the agent can still look productive while drifting away from the real goal.\nIf the test is strong, the agent has a better boundary to work inside.

\n
\n

What agents change

\n

Kent Beck’s broader point, as I read it, is not that agents make engineering obsolete.\nIt is that they push the important skills upward.

\n

That matches what I am seeing too.

\n

The valuable part is becoming:

\n\n

Those are not glamorous tasks, but they are the ones that keep projects from turning into chaos.

\n

The old habit was to focus on syntax, implementation details, and manual repetition.\nThe new habit is to focus on direction, quality, and verification.

\n

That is why I do not see AI agents as a replacement for engineering discipline.\nI see them as a stress test for it.

\n
\n

The failure modes are real

\n

AI agents can be incredibly useful.\nThey can also surprise you in very annoying ways.

\n

Sometimes they:

\n\n

That is why I do not trust speed on its own.

\n

Speed without validation is just a faster way to make mistakes.

\n

And when you are working in a product environment, mistakes are not abstract.\nThey affect users, teams, timelines, and trust.

\n
\n

The workflow I like

\n

If I were building with agents today, I would keep the process simple.

\n
    \n
  1. \n

    Start with behavior.\nDefine what the feature should do in plain language.

    \n
    2. \n
  2. \n

    Write the test or acceptance check first.\nMake the expectation visible before the implementation exists.

    \n
    3. \n
  3. \n

    Let the agent draft the code.\nUse it as leverage, not as authority.

    \n
    4. \n
  4. \n

    Verify the result against the test and the design intent.\nAsk whether the solution is correct, not just whether it is complete.

    \n
    5. \n
  5. \n

    Refactor with human judgment.\nClean up the shape of the code so the next change is easier.

    \n
    6. \n
\n

That flow keeps the human in charge of meaning while letting the agent handle more of the repetitive work.

\n

That feels like the right balance to me.

\n
\n

Why this matters for teams

\n

This is not only a developer workflow issue.\nIt affects how teams operate.

\n

When agents become part of the development process, teams need stronger habits around:

\n\n

The best teams will not be the ones who use the most AI.\nThey will be the ones who use it with the clearest standards.

\n

That is especially important for startups.\nStartups move fast already.\nIf you add AI into the mix without strong feedback loops, you can scale confusion just as easily as you scale output.

\n

So the goal is not to chase more code.\nThe goal is to build better systems with less waste.

\n
\n

My takeaway

\n

I do not think TDD is becoming outdated.\nI think it is becoming more useful in an environment where generation is cheap and correctness is still expensive.

\n

Agentic development gives us leverage.\nTDD gives us confidence.

\n

Together, they create a workflow where we can move quickly without losing our sense of direction.

\n

And that feels like the real opportunity.

\n

Not to write more code for the sake of it.\nBut to build software with more clarity, more control, and more intention.

"}},{"node":{"frontmatter":{"title":"SaaS Is Not Dead. But the Easy Version Might Be.","description":"AI is changing software, but it is not killing production-grade SaaS","slug":"/blog/saas-is-not-dead","date":"2026-06-11T00:00:00.000Z","tags":["AI","SaaS","Product","Startup"],"draft":false},"html":"

Everyone keeps saying SaaS is dead.

\n

The argument goes like this:

\n

AI can build software now.\r\nSo why pay for Salesforce when you can ask Claude to build a CRM?\r\nWhy keep subscribing when a prompt can generate the thing?

\n

It sounds dramatic.

\n

It also misses the point.

\n

AI is changing software, but it is not deleting the need for real products.

\n

Vibe coding works really well for tools used by a small number of people.\r\nIt works for internal tools.\r\nIt works for prototypes.\r\nIt works for narrow workflows where the stakes are low and the users know exactly what they want.

\n

It does not replace the software that entire companies rely on every day.

\n

Workday, Salesforce, Gmail, and the rest of the enterprise stack are not just apps.

\n

They are years of edge cases.\r\nYears of permissions.\r\nYears of integrations.\r\nYears of compliance, uptime, support, reporting, security, and boring reliability.

\n

You do not reproduce that in a weekend with Claude Code.

\n

That is the part the \"SaaS is dead\" crowd keeps skipping.

\n

Production software is not just code.

\n

It is maintenance.\r\nIt is trust.\r\nIt is uptime.\r\nIt is knowing what happens when something breaks at 2 a.m.\r\nIt is handling the weird customer who uses the product in a way nobody predicted.\r\nIt is surviving the thousand tiny failures that never show up in a demo.

\n

Most companies would rather pay for that than own it themselves.

\n
\n

But the doomsday version is not totally wrong

\n

Some SaaS will die.

\n

Not because software becomes useless.\r\nNot because every company will suddenly become a software company.\r\nBut because the business model changes underneath it.

\n

AI lowers the cost of building.\r\nThat means more products can be made faster, by fewer people, with less capital.

\n

It also means customers will have higher expectations.\r\nMore alternatives.\r\nLess patience for bloated tools that solve a problem only slightly better than a script, a prompt, or a lightweight workflow.

\n

The old SaaS playbook was simple:

\n\n

That playbook still works for some products.

\n

But it gets weaker when the software is generic, replaceable, or only marginally better than what a smart team can assemble themselves.

\n
\n

We have seen this movie before

\n

A good analogy is television.

\n

Cinema did not die when TV arrived.\r\nBut it changed.

\n

People no longer needed to leave the house to watch moving pictures.\r\nThat shifted the whole category.

\n

Theaters had to adapt.\r\nSome formats faded.\r\nSome became more premium.\r\nSome became cultural events.\r\nMovies survived, but they reshaped around a world where entertainment could happen at home.

\n

AI may do the same thing to SaaS.

\n

Not all software disappears.

\n

But the center of gravity moves.

\n

Some products will get commoditized.\r\nSome will become more niche.\r\nSome will need to become deeply embedded in a workflow to survive.\r\nSome will need to become meaningfully better, not just a little better.

\n

The companies that adapt will thrive.

\n

The ones that assume customers will keep paying just because they always have will be in trouble.

\n
\n

I have seen enough to take this seriously

\n

My last company, Crossfill, shut down.

\n

That makes this whole conversation feel less abstract.

\n

It is easy to talk about market shifts like they are strategy deck slides.\r\nIt is different when you have lived through a product, a team, and a business reaching the point where they no longer work.

\n

Shutdowns have a way of clarifying things.

\n

They show you what actually mattered.\r\nThey show you what was fragile.\r\nThey show you how fast a market can move on from a product that once felt necessary.

\n

That experience makes me skeptical of any argument that says a category is permanently safe.

\n

It also makes me skeptical of the opposite extreme.

\n

Nothing is guaranteed.\r\nNot even the tools everyone assumes are untouchable.

\n
\n

So what survives?

\n

I think the winners will be the software that becomes harder to replace, not easier.

\n

The products that survive will be the ones that are:

\n\n

The future is not no SaaS.

\n

The future is probably less generic SaaS and more software that earns its place.

\n

That means fewer companies winning by being the default.\r\nMore companies winning by being indispensable.

\n

It also means some products will need to stop thinking like software vendors and start thinking like workflow owners.

\n

Not just \"how do we add AI?\"\r\nBut \"what are we actually irreplaceable for?\"

\n

That is a much harder question.\r\nBut it is the right one.

\n
\n

AI is not an asteroid

\n

That is the biggest mistake people make.

\n

AI is not an asteroid that wipes out software.

\n

It is a force multiplier.

\n

It lowers the cost of creation.\r\nIt increases the speed of iteration.\r\nIt makes it easier to build alternatives.\r\nIt raises the bar for what customers expect.

\n

That is not the end of SaaS.

\n

It is a pressure test.

\n

Some companies will thrive.\r\nSome will get squeezed.\r\nSome really are dinosaurs.

\n

The ones that survive will not be the ones with the loudest AI marketing.

\n

They will be the ones that are actually useful, deeply embedded, and hard to replace.

\n

SaaS is not dead.

\n

But the easy version of SaaS might be.

"}},{"node":{"frontmatter":{"title":"WATERFALL -> AGILE -> AGENTIC","description":"What I learned running multi-agent coding workflows at Crossfill","slug":"/blog/waterfall-agile-agentic","date":"2026-04-28T00:00:00.000Z","tags":["AI","Engineering","Product","Culture"],"draft":false},"html":"

At Crossfill, I started running multiple AI coding agents at the same time.

\n

Not one chat.\r\nNot one tool.\r\nA real multi-agent workflow.

\n

I used multiple Codex, Claude, and Gemini accounts in parallel,\r\ngiving each agent a clear responsibility based on the task at hand.

\n

Then I mentored the team to work the same way.\r\nDesigners, PMs, engineers.\r\nDifferent backgrounds, same goal:\r\nShip faster without losing product thinking.

\n

That experience changed how I see software development.

\n
\n

I believe we are moving through a clear evolution:

\n

WATERFALL -> AGILE -> AGENTIC.

\n\n

This is not just a tooling trend.\r\nIt is an operating model shift.

\n
\n

A lot of people still treat agentic coding (or vibe coding) like a side quest.

\n

Non-technical people building random demos.\r\nFun, but not serious.

\n

That is part of the picture.\r\nBut it is not the full story.

\n

What we are seeing is a new software culture forming in real time.

\n\n

It looks chaotic because it is chaotic.\r\nBut early paradigm shifts usually look like this.

\n
\n

The slop phase is real

\n

Yes, there is code slop.\r\nApp slop.\r\nSlop slop slop.

\n

And honestly, this is expected.

\n

When creation gets much cheaper, output volume explodes first.\r\nSignal systems come later.

\n

The internet went through this.\r\nSoftware will too.

\n\n

In this environment, maintenance becomes strategy.\r\nRefactoring becomes governance.\r\nPruning becomes product leadership.

\n
\n

Org design is next

\n

This shift does not stop at developer workflow.\r\nIt reshapes teams.

\n

We will reorganize around:

\n\n

The old boundaries between Engineering, Product, and Design will collide first.\r\nThen settle into a new model.

\n
\n

This is the same movie we saw with Agile

\n

Agile had a similar arc:

\n\n

Agentic development will likely follow a similar path.\r\nRight now, we are still early.\r\nThat is why it feels unserious to some people.

\n
\n

The uncomfortable prediction

\n

Just like people eventually talked trash about waterfall,\r\none day people may talk trash about agile too.

\n

Not because agile was useless.\r\nBecause agile was built for a different constraint:\r\nhuman-only iteration.

\n

Agentic changes that constraint.

\n

When iteration approaches zero cost,\r\neverything upstream and downstream has to be redesigned.

\n

Not just coding.\r\nProduct.\r\nTeams.\r\nCompanies.

\n

Maybe even what a company is.

"}},{"node":{"frontmatter":{"title":"How I Taught Vibe Coding To Non-Technical Designers","description":"What worked when I taught vibe coding at Crossfill","slug":"/blog/teaching-vibe-coding-to-designers","date":"2026-01-18T00:00:00.000Z","tags":["Culture","Product","AI"],"draft":false},"html":"

At Crossfill, I taught vibe coding to UI/UX designers who didn’t come from engineering backgrounds.

\n

At first, they were nervous.\r\nNot because they weren’t smart.\r\nBecause they assumed code was a locked door and they didn’t have the key.

\n

That was the first thing I tried to change.

\n

I told them:

\n

You don’t need to become an engineer to use code as a design tool.

\n

The goal was never “turn designers into developers.”\r\nThe goal was to help them prototype ideas faster, communicate better with engineers, and feel more ownership from idea to implementation.

\n
\n

What I mean by vibe coding

\n

To me, vibe coding is:

\n\n

It is not about writing “perfect architecture” on day one.\r\nIt is about creating momentum.

\n
\n

How I taught it

\n

I kept the process simple and practical.

\n

1. Start from behavior, not syntax

\n

I asked designers to describe:

\n\n

Once that was clear, code became a translation layer, not a scary mystery.

\n

2. Build tiny, visible wins

\n

Instead of “build a whole app,” we did:

\n\n

Small wins built confidence quickly.

\n

3. Use prompts like product specs

\n

I encouraged prompts that included:

\n\n

Better prompt quality gave better outputs and better learning.

\n

4. Review together like a product critique

\n

We didn’t review only visuals.\r\nWe reviewed:

\n\n

That made the collaboration with engineering much smoother later.

\n
\n

What changed

\n

After a few weeks, the difference was obvious.

\n\n

The biggest shift was not technical.\r\nIt was psychological.

\n

They stopped saying:\r\n“I can’t do this because I’m not technical.”

\n

And started saying:\r\n“Let me prototype this first, then we can refine it together.”

\n
\n

Lessons for teams

\n

If you want non-technical teammates to learn vibe coding:

\n\n

Most people can learn way more than they think when the environment feels safe.

\n

And that was the real win at Crossfill.

\n

It wasn’t just about shipping faster.\r\nIt was about building a team where more people felt empowered to create.

"}},{"node":{"frontmatter":{"title":"My First Hiring Experience - Learning That Hiring Is Human","description":"I got asked to do something I had never done","slug":"/blog/hiring-is-human","date":"2025-04-30T00:00:00.000Z","tags":["HR","Culture"],"draft":false},"html":"

At my recent company, I got asked to do something I had never done before:\r\nHire a UX designer.

\n

It might sound simple for someone else, but for me, it felt huge.\r\nI wasn’t some polished recruiter in a fancy suit.\r\nI was a senior engineer with a thick Asian accent, no HR experience, and definitely not a model-looking face to “represent the company.”

\n

Honestly, when the task landed on me, I didn’t know whether to laugh, cry, or just hide under my desk.\r\nMe, being the face of the company during an interview?\r\nI half-joked to myself that this company might go bankrupt if the candidate judged us based on my interview skills.

\n

Even though I was the one hiring, I prepared for about a full day😅.\r\nI reviewed UX designer resume, thought about possible questions, tried to predict what the candidate might ask about the company, the product, the team — everything.\r\nIt almost felt like I was the one being interviewed.

\n

The day of the interview, my stomach was twisting a little.\r\nI thought it would be a short, robotic checklist:

\n

\"Hello, can you use Figma? Great. Welcome aboard.\"

\n

But that’s not what happened.

\n

The conversation flowed.\r\nOne hour went by — without me even noticing.\r\nWe didn’t just talk about technical skills; we talked about ideas.\r\nHow they see UX, how we think about product.\r\nWe talked about culture, work philosophy, and the kinds of values we wanted to protect as the team grew.\r\nWe even laughed about random startup chaos stories (because who hasn’t experienced that?).

\n

By the end of it, I realized something important:

\n\n

I’m not even sure if the candidate ended up getting the offer.\r\nBut for me, the experience itself was already a win.\r\nI had stepped way outside my comfort zone.\r\nI had grown.\r\nAnd I had learned that even if you feel nervous, imperfect, or unqualified,\r\nyou can still create a real, human connection — and that’s what matters most.

\n

This experience taught me:

\n\n

And for a guy who never thought he’d survive an English interview as “the face of the company,”\r\nThat felt like a pretty good first step.

"}},{"node":{"frontmatter":{"title":"What \"Customer-Facing\" Really Means To Me","description":"A lot of people think \"custoner-facing\" just","slug":"/blog/into-their-world","date":"2025-03-17T00:00:00.000Z","tags":["Culture","Startup","Customer"],"draft":false},"html":"

A lot of people think \"customer-facing\" just means respond quickly, stay polite, get the job done.

\n

But in my mind, that's missing the whole point.

\n

Being customer-facing means diving headfirst into the customer's world.\r\nIt is about seeing through their eyes, thinking their thoughts, feeling their frustrations and dreams.\r\nYou have to live in their world first - really live there - before you can ever expect them to step into yours.

\n

It's not just about solving problems.\r\nIt's about showing up with genuine interest, sharing their excitement, building trust, makeing them feel seen.\r\nIf you do it right, you don't just earn a customer - you make a real connection.\r\nThey love working with you, because they feel like you're on their team.

\n

And from there?

\n\n

At the end of the day, real business isn't cold - it's emotional.\r\nIf you can make people feel energized, hopeful, proud to work with you...\r\nYou're not just closing deals.\r\nYou're building something that lasts.

\n

That's the kind of customer-facing mindset I bring.\r\nThat's how I want to build, every day.

"}},{"node":{"frontmatter":{"title":"Thomas And The Startup Culture","description":"I worked for 3 startups, as a full-time employee","slug":"/blog/thomas-and-startup-culture","date":"2022-11-30T00:00:00.000Z","tags":["Culture","Startup"],"draft":false},"html":"

I worked for 5 startups, as a full-time employee for 2 of them, and a contractor for the other.

\n

During the process, I taught myself to be creative, innovative and entrepreneurial while delivering what is expected from me - the high-quality software.

\n

Some of my significant contributions are:

\n\n

I engage in my daily endeavors with passion and share the ambition of the team making an impact on people’s lives. This makes me a self-initiator.

\n

_ People who are passionate can be trained in everything. But we don’t know how to train in attitude. _

\n

I strongly believe in the above quote, and I personally experienced it while working at startups.\r\nI work hard, be part of the team, and am willing to take challenges as the founders do.

\n

Fully understanding the startup life, I am ready to jump in and make things right, and very accustomed to wearing many hats whenever needed.

\n

Things that I take seriously while working at startups are:

\n

sticking to and living by the company value\r\ngetting to know the team culture and being a happy part of it\r\nopen communication and welcoming constructive criticism\r\nThe strongest personal trait of mine is self-discipline. It breeds many of my positive work ethics.\r\nEveryday is my struggle to build world-class self-discipline. You can try 30 days of discipline too.

\n

I want to see myself join you in your startup journey and make difference.\r\nUntil then, take care.

\n

Email me at tms.doan@gmail.com.

"}},{"node":{"frontmatter":{"title":"A Journey into Mental Healthcare Innovation","description":"In August 2022, I embarked on a new adventure","slug":"/blog/thomas-and-therify","date":"2022-03-11T00:00:00.000Z","tags":["Culture","Startup","Healthcare"],"draft":false},"html":"

In August 2022, I embarked on a new adventure by joining Therify, a mental healthcare startup with a powerful vision: to make culturally responsive mental health care accessible to individuals and organizations alike. As someone who thrives on building meaningful products and has a deep interest in startups, this opportunity felt like the perfect alignment of my skills, values, and passions.

\n

Why Therify’s Mission Resonated with Me

\n

Mental health is a topic close to my heart.\r\nWhen I learned about Therify’s mission—to connect people with therapists who understand their cultural, personal, and professional challenges—I knew this was more than just another tech project. It was a chance to make a real impact.

\n

As a product-minded engineer, I’m not just about writing code.\r\nI’m about solving problems, creating intuitive user experiences, and contributing to business goals.\r\nTherify’s business idea—leveraging technology to empower diverse communities through personalized mental health support—immediately sparked my curiosity.\r\nIt wasn’t just a service; it was a movement to address a critical gap in healthcare.

\n

Building with Purpose

\n

From the moment I joined, I dove into projects that pushed me to think beyond the technical.\r\nWorking on features like AI-powered therapist matching, secure teletherapy, and analytics for employer insights, I found myself at the intersection of tech innovation and human connection.

\n

I approached each task with a product-first mindset, always asking:

\n\n

Joining a startup like Therify meant stepping into a dynamic, fast-paced environment.\r\nEvery decision felt pivotal, every line of code impactful.\r\nI loved collaborating with a passionate team who shared a common goal: to redefine how mental health care is delivered.

\n

For me, startups are all about building from the ground up, taking calculated risks, and driving innovation.\r\nTherify was no exception.\r\nIt offered me the chance to combine my technical expertise with my passion for solving meaningful problems, all while contributing to a business idea that truly mattered.

\n

Looking Ahead

\n

My journey with Therify has reaffirmed my belief in the power of technology to create positive change.\r\nIt’s a reminder that the work we do as engineers isn’t just about software; it’s about people—their needs, their struggles, and their growth.

\n

Looking back, I’m grateful for the opportunity to join a company that values both innovation and impact.\r\nAnd as we continue to build and grow, I’m excited to see how we can further push the boundaries of what mental health care can achieve.

"}},{"node":{"frontmatter":{"title":"Dark Mode Toggle","description":"Dark mode without the flash of default theme","slug":"/blog/dark-mode-toggle","date":"2021-04-21T00:00:00.000Z","tags":["Theming","Dark Mode"],"draft":false},"html":"

Dark mode toggle without the flash of default theme. Important bits:

\n\n

HTML

\n
<!DOCTYPE html>\r\n<html lang=\"en\" data-theme=\"light\">\r\n  <head>\r\n    <meta charset=\"utf-8\" />\r\n    <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\" />\r\n    ...\r\n    <script>\r\n      // If there's a theme stored in localStorage, use it on the <html>\r\n      const localStorageTheme = localStorage.getItem('theme');\r\n      if (localStorageTheme) {\r\n        document.documentElement.setAttribute('data-theme', localStorageTheme);\r\n      }\r\n    </script>\r\n  </head>\r\n  <body>\r\n    <div class=\"theme-toggle\">\r\n      <button\r\n        class=\"theme-toggle-btn js-theme-toggle\"\r\n        aria-label=\"Activate dark mode\"\r\n        title=\"Activate dark mode\"\r\n      >\r\n        <!--\r\n        <svg class=\"light-mode\">\r\n          <use xlink:href=\"#sun\"></use>\r\n        </svg>\r\n        <svg class=\"dark-mode\">\r\n          <use xlink:href=\"#moon\"></use>\r\n        </svg>\r\n        -->\r\n      </button>\r\n    </div>\r\n\r\n    <script src=\"app.js\"></script>\r\n  </body>\r\n</html>
\n

CSS Variables

\n
:root {\r\n  --bg: #ffffff;\r\n  --text: #000000;\r\n}\r\n\r\n[data-theme='dark'] {\r\n  --bg: #000000;\r\n  --text: #ffffff;\r\n}
\n

JavaScript

\n
app.js
\n
const themeToggleBtn = document.querySelector('.js-theme-toggle');\r\n\r\nthemeToggleBtn.addEventListener('click', () => onToggleClick());\r\n\r\nconst onToggleClick = () => {\r\n  const { theme } = document.documentElement.dataset;\r\n  const themeTo = theme && theme === 'light' ? 'dark' : 'light';\r\n  const label = `Activate ${theme} mode`;\r\n\r\n  document.documentElement.setAttribute('data-theme', themeTo);\r\n  localStorage.setItem('theme', themeTo);\r\n\r\n  themeToggleBtn.setAttribute('aria-label', label);\r\n  themeToggleBtn.setAttribute('title', label);\r\n};
\n

Resources

\n"}},{"node":{"frontmatter":{"title":"Accessible Clickable Cards","description":"Clickable cards with multiple child links","slug":"/blog/clickable-cards","date":"2021-04-21T00:00:00.000Z","tags":["Accessibility","CSS"],"draft":false},"html":"

Codepen Demo

\n

Card layout where the card itself isn't an anchor link, but the whole card is clickable (with a :before pseudo element on the main <a>). Links inside of the card are still clickable.

\n

CSS

\n
.grid__item {\r\n  &:hover,\r\n  &:focus-within {\r\n    background-color: #eee;\r\n  }\r\n\r\n  a {\r\n    position: relative;\r\n    z-index: 1;\r\n  }\r\n\r\n  h2 {\r\n    a {\r\n      position: static;\r\n\r\n      &:hover,\r\n      &:focus {\r\n        color: blue;\r\n      }\r\n\r\n      &:before {\r\n        content: '';\r\n        display: block;\r\n        position: absolute;\r\n        z-index: 0;\r\n        width: 100%;\r\n        height: 100%;\r\n        top: 0;\r\n        left: 0;\r\n        transition: background-color 0.1s ease-out;\r\n        background-color: transparent;\r\n      }\r\n    }\r\n  }\r\n}
"}},{"node":{"frontmatter":{"title":"Writing Is Hard","description":"I have the hardest time with creative writing","slug":"/blog/writing-is-hard","date":"2021-04-21T00:00:00.000Z","tags":["Blogging","Culture"],"draft":false},"html":"

I have the hardest time with creative writing. Producing a continuous flow of words should be easier than this.

\n

Even now, I’m tempted to spin that previous sentence around in my head over and over, thinking about how I could word it better, or how I could make the point more creatively.

\n

But you know what? I won’t! Because it states exactly my point, and it’s fine the way it is.

\n

I feel like I have tons of ideas, bouncing from one thought to another, making intuitive leaps, and it is just a challenge to get it written down. By the time I’m half way through a sentence, I’ve already made several parallel branches in my head of new possibilities I want to go to.

\n

And by the time I finally get something together, I run it through the ol’ meat grinder over and over again, before scrapping it. What a chore!

\n

It almost feels like being lost in the woods, constantly backtracking, doubting where I am going.

\n

There is nothing to writing. All you do is sit down at a typewriter and bleed. * Ernest Hemmingway *

\n

Thinking, on the other hand, comes naturally. I can get lost in thought for great gulfs of time. But putting those thoughts into concise sentences in writing is always a challenge. For some reason, it’s much easier to do it in real time whilst babbling out words to a person directly with my mouth.

\n

The only writing I am used to is technical writing, where specificity and clarity is key. Creative writing is much more challenging. And to a logic-worshiping creature such as myself that always sees the world through a lens of rationality, it is fairly easy to visualize what I am trying to accomplish with technical writing. This is not so with creative writing.

\n

With technical writing, the outline, structure, and details sort of just materialize on their own. I guess this is because is all makes perfectly logic sense up front in the first place, and my job at that point is to communicate it clearly.

\n

This is very different than communicating creatively.

\n

With creative writing, I find myself endlessly polishing, rewording, and tweaking what I write, which turns writing into an ordeal for me. I end up with a jumbled mess of ideas scattered around, before thinking up more topics of blog posts I suddenly become passionate about and move onto.

\n

Seriously, I must have like a dozen unfinished posts now.

\n

So instead of applying my tried-and-true technical writing approach to creative writing, I’m trying something new. I’m writing in near stream-of-conscious. And I’m not going to go back and doubt every little word in every sentence.

\n

I’m currently reading the diary of Anne Frank. For a young teenager scribbling away in a diary that she probably thought nobody would ever read, she sure is an excellent writer. And a creative one at that.

\n

In fact, she writes better than most blog I’ve seen. I’m not sure if it’s because she wasn’t overthinking it, of if she just had a unique combination of maturity, individuality, and intelligence for her age, or if she was a natural-born writer who would’ve blossomed into a successful writing career had she survived into adulthood..

\n

[…]

\n

.. ok, back. From a sudden Anne Frank Wikipedia spiral. Anyways, I wish I could write as easily as Anne Frank.

\n

Moving along though, I have a great interest in writing. Not my writing, gods no. But in the writing of others. Introspective perception is what it’s all about for me.

\n

Reading is one of my favorite pastimes, and one thing I really appreciate is all the little nuances authors go through in their writing; the way they spin words and play with them, the sort of imagery they invoke, and the chain reaction of thought they’re able to trigger with the shortest of sentences.

\n

Underground and 90’s gangster rappers excel in this regard, exceptionally so.

\n

So let’s see here. I’ve managed to jump topics from writing perfectionism, to technical writing and thinking, to all my unfinished posts, to Anne Frank, to books, and then to rappers.

\n

And I’m ok with that. Perhaps it’s better this way.

\n

And hey, that was actually pretty fun that time.

"}},{"node":{"frontmatter":{"title":"SOLID Principles Checklist (in Python)","description":"With so many soliloquies of SOLID Principles online","slug":"/blog/solid-principles-checklist","date":"2020-09-20T00:00:00.000Z","tags":["Blogging","Tech"],"draft":false},"html":"

With so many soliloquies of SOLID Principles online, ripe with the same old definitions, theoretical verbosity, and yet, the most basic of examples, I’ve always found it difficult to digest and keep it all in mind while developing.

\n

So I wanted to create a condensed checklist that is wall hang-worthy.

\n

SOLID Principles Checklist

\n\n

Single Responsibility Principle

\n\n

Open Closed Principle

\n

When adding a new functionality

\n\n

Liskov Substitution Principle

\n

In class inheritance

\n\n

Interface Segregation Principle

\n\n

Dependency Inversion Principle

\n\n

Further Readings

\n

Following is a famous visualisation of the SOLID principles by a Medium author.\r\nThe S.O.L.I.D Principles in Pictures by Ugonna Thelma

\n

It is common that we go adrift in the profoundness of the principles and concepts, but they could be readily mastered through constant reminders and learning the perspectives of other great minds.

"}},{"node":{"frontmatter":{"title":"Documenting Database Design","description":"Documenting database design just seems to be one of","slug":"/blog/documentating-database-design","date":"2020-07-30T00:00:00.000Z","tags":["Culture","Tech"],"draft":false},"html":"

Documenting database design just seems to be one of those things that web developers tend to suck at.

\n

I have some theories as to why:

\n\n

If done before coding, it becomes quickly out of date. If done after coding, it probably never gets done at all.

\n

The odds are further stacked against web developers since conventions and techniques for documenting databases rarely gets brought up, ever.

\n

All the focus goes into the relationships, modeling, and queries.

\n

Garbage In, Garbage Out

\n

The first step to having good documentation is having good database design in the first place.

\n

If there is a convoluted design, expect convoluted documentation. In fact, expect convoluted data models and business logic in the application itself, too.

\n

Be ruthless about:

\n\n

Where the Pristine Runs Afoul

\n

The design always seems to start off solid, but as development progresses, corners get cut, and before you know it, those pristine tables are full of little hacks that were thrown in last minute.

\n

Sometimes it’s the removal of no-longer-needed columns, rendering a once-useful table into something no longer needed itself.

\n

You then end up with this leftover.. thing, that keeps getting populated by the application. It gets even worse when its sole purpose in life becomes holding up foreign key constraints between other tables.

\n

Other times, ultra-specific, awkwardly-named columns get added to an existing table due to convenience, which often turns into an eyebrow raiser for the next developer that has to figure out what the column does, and why it’s in that table.

\n

In worst cases, flag or enum-type columns get added to allow rows to have their own state, effectively denormalizing the table.

\n

And somewhere in the spacetime continuum, or perhaps outside of it, the gods weep.

\n

It’s these sort of last minute, weird, stupid things that fouls up pristine database design, and makes documentation that more difficult and verbose. To this, I say: always refactor, no matter the risk.

\n

What to Document

\n

Moving along, I find those following the most important to document:

\n\n

Sometimes you will be stuck with weird columns or tables that are not self-evident as to what they are for. This is what should be documented.

\n

Redundantly documenting anything that is already self-evident adds noise and buries the tasty morsels that readers should be drooling over.

\n

This applies to code, for that matter.

\n

Table Descriptions

\n

Expanding on the table descriptions part, provide a summary for each table:

\n\n

Shut up About the Application

\n

I don’t believe in going into detail about how the data may power things on the user interface, or what controllers use the data models, and so forth.

\n

The database design should stand on its own, regardless of what application, services, or views are using it.

\n

Diagrams

\n

ER diagrams really helps one to see how everything fits together at a glance.

\n

If there are a lot of tables, I find that it helps to break up the tables into clusters which share foreign key relationships, rather than provide a single overview that is not even readable.

\n

Always generate ER diagrams, don’t even consider making one by hand for a second. For MySQL, there is the free MySQL Workbench.

"}},{"node":{"frontmatter":{"title":"BEM and SASS in ReactJS Applications","description":"Unless you are using Styled-components for","slug":"/blog/bem-sass-react","date":"2020-05-19T00:00:00.000Z","tags":["Blogging","Tech"],"draft":false},"html":"

Unless you are using Styled-components for styling ReactJS components, the choice of class naming convention directly affects the productivity and more.

\n

There’s no argue why we should be using some CSS preprocessors instead of plain CSS. Read through 7 benefits of using SASS over conventional CSS to remind yourself of why.\r\nSASS provides 2 different syntaxes - SASS and SCSS. I prefer SCSS as it is CSS-compatible, meaning that when you rename your CSS file from XYZ.css to XYZ.scss, it immediately becomes a valid SCSS file.

\n

Now, what is BEM?\r\nBEM, which stands for Block-Element-Modifier, is one of the most well-accepted CSS naming conventions.\r\nTo give you a quick & easy overview of what BEM looks like:

\n

Block (B)

\n
<div class=\"book\">...</div>\r\n.book {\r\n  color: #EFEFEF;\r\n}
\n

Element (E)

\n
<div class=\"book\">\r\n  ...\r\n  <span class=\"book__author\"></span>\r\n</div>\r\n.book__author {\r\n  color: #004345;\r\n}
\n

Modifier (M)

\n
<div class=\"book book--sold\">...</div>\r\n.book--sold {\r\n  text-decoration: stroke;\r\n}
\n

(reference: BEM — Block Element Modifier)

\n

Besides enabling a global naming rule for your project and the team, BEM provides several other advantages.

\n\n

(reference: To BEM or not to BEM? That is the question.)\r\nBEM couples well with SCSS syntax. Imagine you write CSS rules for a book element.

\n
<div class=\"book\">\r\n  <span class=\"book__author\">Napoleon Hill</span>\r\n  <span class=\"book__title\">Think and Grow Rich</span>\r\n</div>\r\n<div class=\"book book--sold\">\r\n  <span class=\"book__author\">David Schwartz</span>\r\n  <span class=\"book__title\">The Magic of Thinking Big</span>\r\n</div>
\n
.book { background-color: black; }\r\n.book__author { color: white; }\r\n.book__title { font-weight: bold; color: white; }\r\n.book--sold { text-decoration: stroke; }
\n

Let’s rewrite this rule in SCSS.

\n
.book {\r\n  background-color: black;\r\n  \r\n  &__author {\r\n    color: white;\r\n  }\r\n  &__title {\r\n    font-weight: bold;\r\n    color: white;\r\n  }\r\n  \r\n  &--sold {\r\n    text-decoration: stroke;\r\n  }\r\n}
\n

The nested syntax of SCSS plays a major role in the beauty of BEM blended in SCSS.

\n

With the basic knowledge of SCSS and BEM so far, let’s explore my self-found best practice for writing component styles using them.\r\nLet us assume that we are working on a project structure like the following:

\n
project\r\n - src\r\n   - components\r\n     - Book.jsx\r\n     - Book.style.scss\r\n     - Article.jsx\r\n     - Article.style.scss\r\n     - ...\r\n   - containers\r\n     - Archive.container.jsx\r\n     - Archive.style.scss\r\n     - ...\r\n   - styles\r\n   - utils\r\n - node_modules\r\n - ...
\n

One of the common misconceptions when writing a component style is ignoring the name conflicts.\r\nImagine we write styles for Book component and Article component separately.

\n
highlight.js
\n
...\r\nimport './Book.style.scss';\r\n...\r\nexport default ({ author, title }) => (\r\n  <div className=\"book\">\r\n    <span className=\"author\">{author}</span>\r\n    <span className=\"title\">{title}</span>\r\n    ...\r\n  </div>\r\n);
\n
Book.style.scss
\n
.author { color: white; }\r\n.title { font-weight: bold; color: white; }
\n
Article.jsx
\n
...\r\nimport './Article.style.scss';\r\n...\r\nexport default ({ author, title }) => (\r\n  <div className=\"article\">\r\n    <span className=\"author\">{author}</span>\r\n    <span className=\"title\">{title}</span>\r\n    ...\r\n  </div>\r\n);
\n
Article.style.scss
\n
.author { color: blue; }\r\n.title { text-decoration: underline; color: blue; }
\n

One could falsely assume that these two styles are kept local to the respective components, but they are not. As and when these two components render on the same page, the unwanted conflicts of CSS rules occur.\r\nNote the resulting HTML page source:

\n
<body>\r\n  ...\r\n  <div class=\"book\">\r\n    <span class=\"author\">Napoleon Hill</span>\r\n    <span class=\"title\">Think and Grow Rich</span>\r\n  </div>\r\n  ...\r\n  <div class=\"article\">\r\n    <span class=\"author\">danny liu</span>\r\n    <span class=\"title\">BEM and SCSS in ReactJS applications</span>\r\n  </div>\r\n  ...\r\n</body>\r\n<style>\r\n  ...\r\n  .author { color: white; }\r\n  .title { font-weight: bold; color: white; }\r\n  ...\r\n  .author { color: blue; }\r\n  .title { text-decoration: underline; color: blue; }\r\n  ...\r\n</style>
\n

The prettiest solution to the above issue is applying scopes, the unique namespaces, for each component style definitions.

\n
Book.style.scss
\n
.book {\r\n  .author {\r\n    color: white;\r\n  }\r\n  .title {\r\n    font-weight: bold;\r\n    color: white;\r\n  }\r\n}
\n
Article.style.scss
\n
.article {\r\n  .author {\r\n    color: blue;\r\n  }\r\n  .title {\r\n    text-decoration: underline;\r\n    color: blue;\r\n  }\r\n}
\n

If you chose to use BEM, the namespacing of component styles would come naturally, and you don’t need to stress about remembering it every time. Meanwhile, your application benefits from the aforementioned BEM advantages as well.

\n
Book.style.scss
\n
.book {\r\n  &__author {\r\n    color: white;\r\n  }\r\n  &__title {\r\n    font-weight: bold;\r\n    color: white;\r\n  }\r\n}
\n
Article.style.scss
\n
.article {\r\n  &__author {\r\n    color: blue;\r\n  }\r\n  &__title {\r\n    text-decoration: underline;\r\n    color: blue;\r\n  }\r\n}
\n

Caution: Stick to the habit of assigning UNIQUE class names to the root DOM elements of your components. Otherwise, the conflicts of CSS rules will happen.

"}},{"node":{"frontmatter":{"title":"Developer's Dilemma - Folder Structure and Component Naming","description":"I bet, for many developers or for me at least, there’s","slug":"/blog/folder-structure-n-component-naming","date":"2020-05-14T00:00:00.000Z","tags":["Blogging","Tech"],"draft":false},"html":"

I bet, for many developers or for me at least, there’s often a dilemma in the initial phase of a development project.\r\nThat is …

\n

_ How to set up the folder structure and file naming conventions, a.k.a the project structure? _

\n

Project structure plays a critical role in the long-term productivity, maintainability and architectural excellency of any development project.\r\nHaving laid it out myself as well as worked on someone else’s setup, I learned it the hard way.

\n

As ReactJS is my primary FE library of choice, this article will depict a sample ReactJS project and its structure.

\n

Precaution: Nothing here is written in rocks, the methodology I am describing here is just one of many approaches 😏

\n

Folder Structure

\n

One of the questions I often face is regarding to how structure files and folders. In this post, I am starting off with a minimum structure, the one created with create-react-app.\r\nThe create-react-app generates a basic project for us, containing in its root, the files: .gitignore, package.json, README.md, yarn.lock

\n

\n \n \n \n \n

\n

It also generates the folders: public and src. The last one is where we keep our source code.

\n

Containers and Components

\n

I tried the separation between Containers and Presentation Components in the project’s root folder. I mean, inside src, I had a folder named components and another folder named containers:

\n

\n \n \n \n \n

\n

However, this kind of approach introduced some issues like:

\n\n

You don’t have clear rules about what is a Container and what is a Presentational Component. The difference between each other can be subjective and when you are in a team, it will be hard to have all the developers agreeing and judging equally this matter.\r\n\n \n \n \n \n

\n\n

Even when you decide a component fits in one of the specific types, it’s easy to get it changed along the project lifetime, and forcing you to move it from components to containers folder and vice-versa.

\n\n

Components should have declarative and unique names in the application, to avoid confusion about the responsibility of each one. However, the above approach opens a breach to having two components with the same name, one being a container and other being a presentational.

\n\n

You have to constantly navigate between containers and components folders, even when working in a single feature. Because it’s common that a single feature has components of the two types.

\n

For those reasons, I realized that when organizing folders and files, it’s irrelevant to split the components by the concept of presentational vs container.

\n

Separating and grouping the code

\n

Inside the components folder, I would group the files by module/feature.

\n

For example, for a CRUD of user, the structure would be as the following:

\n

\n \n \n \n \n

\n

The test files stay with the file that is being tested. In the above case, the test for Form.jsx would stay in its same folder and would be named as Form.spec.jsx

\n

UI Components

\n

Beyond separating the components by modules, I’d also include a UI folder inside src/components, to keep all the generic components in it.\r\nUI components are components generic enough not to belong to a module and likely to be reused. I could go with Common instead of UI, but the name UI represents the difference well with logic.\r\nExamples of these components are: Buttons, Inputs, Checkboxes, Selects, Modals, Data display elements, etc…

\n

Naming components

\n

The name we give to the components, should be clear and unique in the application, in order to make them easier to find and to avoid possible confusions.\r\nA component’s name is very handy when we need to debug using tools as React Dev Tools, and when run time errors happen in the application. The error always come with the component name where it happened.\r\nBasically, a component that is located at: components/User/List.jsx would be named as UserList.\r\nWhen the file is inside a folder with same name, we don’t need to repeat the name. That said, components/User/Form/Form.jsx, would be named as UserForm and not as UserFormForm.

\n\n

I use sublime or VSCode as the IDE for the web development, and they support the fuzzy search.\r\nTherefore, file name not being identical to the component name doesn’t pose any difficulty in search.\r\n\n \n \n \n \n

\n

Screens

\n

Screens, as the name already suggests, would be the screens that we have in the application.\r\nFor users scope, we would have a screen for the user list, a screen for creating a user and a screen for editing a user.\r\nA screen is where I use components to compose a page. Most of the time, the screen would’t contain any logic and would be a functional component.

\n
import React from 'react';\r\nimport UserForm from '../../components/User/Form/Form';\r\n\r\nconst ScreensUserForm = ({ match: { params } }) => (\r\n  <div>\r\n    <h1>\r\n      {`${!params.id ? 'Create' : 'Update'}`} User\r\n    </h1>\r\n    <UserForm id={params.id} />\r\n  </div>\r\n);\r\n\r\nexport default ScreensUserForm;
\n

And the folder structure and component naming within the screens folder should follow the same convention as the components folder, except that we conveniently add a prefix to descriminate the screen components, i.e. ScreensUserForm\r\nThe final structure of this example project would look like:

\n

\n \n \n \n \n

\n

Note that Root.jsx is the component where routing is defined

\n

Additional thoughts

\n

Personally, I would put some non-component files in the relevantly named folders directly under src folder.\r\nFor example, utils for the helper functions, hooks for custom hooks, and services for API handlers.

\n

Conclusion

\n

This approach is definitely a work in progress as I’d constantly seek for a better alternative, be it an enhanced version of this one or a completely different one.\r\nThe foremost question is if I really need Screens folder, but it seems convenient at the moment.

\n

To be continued …

"}},{"node":{"frontmatter":{"title":"React Native - Native or Hybrid?","description":"React Native is dominating the mobile app development","slug":"/blog/react-native-not-hybrid","date":"2020-04-12T00:00:00.000Z","tags":["Culture","Tech"],"draft":false},"html":"

React Native is dominating the mobile app development landscape.\r\nI tried to come up with a justification of why based on my experience.

\n

What’s React Native?

\n\n

Cross Platform

\n\n

Lifecycle of new component

\n\n

Lifecycle of updating component

\n\n

How it does compare with other solutions?

\n\n

The good parts (the final WHY)

\n\n

The bad parts

\n\n

React Native provides an interface (bridge) between the Native language and Javascript code. There are heated debates on whether React Native is a native or a hybrid solution.\r\nPersonally, I consider React Native closer to native side, as Facebook officially claims.

\n

_ We designed React Native such that it is possible for you to write real native code and have access to the full power of the platform._

\n

You can side with or against me, but React Native still rocks, so does React.

"}},{"node":{"frontmatter":{"title":"Challenge & Solution (Highcharts)","description":"While working at Sigsense Technologies, I was","slug":"/blog/challenge-and-solution","date":"2020-04-09T00:00:00.000Z","tags":["Blogging","Tech"],"draft":false},"html":"

While working at Sigsense Technologies, I was badly stuck with unseen customization of Highcharts graph.

\n

\n \n \n \n \n

\n

Highcharts graph needed to be made bi-directional, which meant end-users being able to draw different types of plots using their mouse.\r\nIn addition, already-drawn plots were to be resized by the end-users’ dragging of the plot edges. (you could notice the colorful pillars from the above figure)\r\nGiven the primary purpose of Highcharts, it implied heavy customization and an elaborate manipulation of the available interfaces to the graph.

\n

Google it! That was my first response to this challenge.\r\nIt was not very successful, as there were no such use cases discussed or answered publicly.\r\nSo there came the realization -

\n

_ I need the top-down approach_

\n

Here’s how I broke the issue down to smaller pieces.

\n

\n \n \n \n \n

\n

At the end of the day, the challenge boiled down to resolving 3 leaf issues(the green ones on the above) :

\n\n

Then, with the issue broken down to tangible, atomic and easy-to-solve pieces, I did the dreaded and contributed to the original value of the product.

"}},{"node":{"frontmatter":{"title":"Docker Compose Error","description":"docker-compose version discrepancies","slug":"/blog/docker-error","date":"2019-12-13","tags":["WordPress","Docker"],"draft":false},"html":"

Problem

\n

Recently while updating with Skela with webpack, I encountered a weird error where I wasn't able to run a simple script:

\n
bin/composer
\n
#!/bin/bash\r\ndocker-compose exec -w /var/www/html/wp-content/themes/skela wordpress composer \"$@\"
\n

When trying to run this script via ./bin/composer install, I got this error in my terminal:

\n
ERROR: Setting workdir for exec is not supported in API < 1.35 (1.30)
\n

The error was coming from the -w flag in the docker-compose exec command in the composer script.

\n

Solution

\n

Turns The fix was to update the version in my docker-compose.yml file to from version 3.5 to 3.6. It's strange because 3.5 isn't anywhere close to the API version 1.35 from the error message 🤷‍♀️

\n
docker-compose.yml
\n
version: '3.6'\rservices:\r\n  wordpress:\r\n    build:
"}},{"node":{"frontmatter":{"title":"WordPress Publishing Error","description":"Trying to create a simple post in WordPress","slug":"/blog/wordpress-publish-error","date":"2019-12-03T00:00:00.000Z","tags":["WordPress"],"draft":false},"html":"

Problem

\n

Recently while working on a WordPress project with Ups Dock, I encountered a weird error where I wasn't able to update or publish a simple post in my local WP admin.

\n

It looked something like this:

\n

\n \n \n \n \n

\n

Solution

\n

Since the error message had to do with a JSON response, I initially thought it was a Gutenberg or ACF issue. But it turned out this was happening because I was on the https WP admin (i.e. https://project.ups.dock/wp-admin), not the unsecure WP admin (http://project.ups.dock/wp-admin).

\n

It was a CORS error!! I was trying to modify a non-https domain from a https domain. Switching to a non-https WP admin allowed me to publish posts with no problem.

"}}]}},"pageContext":{}}, "staticQueryHashes": ["2009693873","2077189868","3303540520","3505212370","3825832676"]}