DEV Community: Jedric Tuquero

Iskor Devlog #1 - Learning a Little Bit of Everything

Jedric Tuquero — Sun, 23 Aug 2026 08:04:18 +0000

Welcome to the first (and hopefully not the last) devlog of Iskor! I started this blog mainly to prevent the degradation of my writing skills caused by excessive LLM use. The sharing of my app's progression is just a nice byproduct of it xD.

Introduction

Like virtually all applications, Iskor started as an idea. I observed tens of thousands of students apply for both the DOST-SEI Undergraduate and JLSS Exam, and they are even willing to pay for review centers. My market research revealed that only a couple of exam/review SaaS are dedicated to these types of exam. Hence, this signaled a large and underserved market with a lot of potential. So as a DOST Scholar myself and someone who knew full-stack development, I took it upon myself to build Iskor.

I started this project at the beginning of August, and plan to deploy it as a full-fledged product on the first week of November with beta-testing and question-bank filling at least a month before the undergraduate exam, scheduled Nov. 14-15. 2 months.

In the past few weeks, I focused on implementing features on the components that I am familiar with.

Stuff I Know

Frontend

I decided to go with Next.js for my frontend because it pre-renders your website, allowing webcrawlers to access my site and do SEO magic. In addition, it also has essential features such as file-based routing, server-side rendering (SSR), and is also relatively easy to understand thanks to my past React experience.

I also utilized TypeScript since it is essentially a strongly-typed JavaScript. It checks types and detects errors at compile time, adds more complex data types such as interfaces, and works well with Next.js.

As for the website itself, I have created the landing page, a resource page to view all covered topics with externals study site recommendations, the sign-in/sign-up page, and the exam page itself which emulates a real test paper. It supports SVGs, excerpts, images, LaTeX equations, and shared-media questions.

Finally, I have also dabbled on AI-assisted coding, where I studied proper prompt engineering and utilized Antigravity CLI to create reusable components. I make sure to review its proposed changes before approving them, since I don't want this app to be a black box of vibe-coded slop.

Now, since Next.js has built-in API routes that essentially serve as the backend, it would be obvious to use that, right?

Backend

I have no problem diving into complex things, as long as it helps me move forward with my goals. One of them is someday working in FinTech. In order for me to land a dev role in that industry, I must be able to utilize the technologies they use.

Enter Spring Boot. Spring Boot is Java's modern framework for building enterprise web apps. It massively reduces the initial boilerplate code Java has been associated with using auto-configuration and is, at its core, a batteries-included framework.

Aside from the listed pros, Spring Boot has also benefited my development process in more ways than one. For instance, its embedded Tomcat servers allowed me to run the application in a .jar file, making it easy to build and containerize. Moreover, its strict enforcement of SOLID allowed me to ingrain these development principles into my thinking. Here is how:

Single-Responsibility Principle (S) - each class is a layer that handles a different function (controller classes for endpoints, service classes for business logic etc.)
Open-Closed Principle (O) - each function can be added a feature through annotations
Liskov Substitution Principle (L) - not implemented that much yet, but the backend does not use a deep inheritance hierarchy that causes LSP problems.
Interface Segregation Principle (I) - functions to be used in the service layer are the ones explicitly defined in the repository layer.
Dependency Inversion Principle (D) - utilizes constructor injection to create the dependency first before providing them to the services and controllers.

Even after realizing how verbose still this framework is, I do not regret choosing Spring Boot as this app's backend. Next layer: the database.

Database

Fortunately, this is one of the components of the app where I do not need to learn anything particularly new. I chose to use PostgreSQL because of its high data integrity (ACID compliance) and its extensive support of both relational and semi-structured data like JSON, which would become essential for future features.

I have created the schema for the website, applying normalization and indexes to reduce data redundancy and improve read speed since the app would be read-heavy.

For hosting, I opted to use Supabase for prototyping and initial development. Its wide range of tools has made making database edits seamless. Although helpful at the start, Supabase does get expensive as I start to hit the free plan limits. Hence, I plan on migrating to Amazon RDS once this app is complete in order to support more users and get a glimpse on how RDBMS works on production.

Getting my Feet Wet

Aside from those three foundational layers, I have also started getting my feet wet on the other important parts of software engineering.

Authentication/Authorization

Security is one of the most essential features of an application, especially in this new age of unsecure, vibe-coded app fever. While Spring Security exists, I ultimately decided on using Clerk to handle user authentication/authorization because I believe it is much better for a reputable third-party to handle real user data instead of an amateur rolling his own auth.

With that being said, I have implemented a functional sign-in and sign-up feature using Clerk's built-in components. However, I have yet to secure my API endpoints using JWT and implement other security features such as RBAC and rate limiting.

DevOps and CI/CD

For the past few months, I have been learning Docker on the side in order to make sure that my applications run on any server. I have learned how to build an image from a Dockerfile, spin up containers using docker compose, and learned the best practices on creating and managing these containers.

This week, I also learned how to use GitHub Actions to setup a workflow that automatically builds the backend image and upload it to DockerHub. Although, I plan on refactoring the pipeline to build the .jar file on the runner itself before inserting it into the image to save build time.

Plans for Next Week
I probably would be a lot more time-constrained next week due to classes starting again, so I decided to put my focus on one thing at a time. Hence, I plan on implementing RBAC and securing my API endpoints first using Clerk's JWT and Spring security, along with finalizing the infrastructure Iskor would utilize in production.

A 30-Day Sprint to Build 2 Full-Stack Apps for UP Faculty

Jedric Tuquero — Wed, 29 Jul 2026 13:47:31 +0000

Building a full-stack web application is one thing. Building two apps...for real users...with frameworks you have never used before...in less than a month...is another story.

Last summer break, our university (UP Baguio) offered CMSC 198: Practicum, a course that requires us to complete an internship and apply computer science theories we have learned so far to real-world applications. Me and other third year students were put together into a team and were given a task: build two full-stack web apps to be utilized by 30+ faculty members, one to manage class sections and another to track students' taken/required subjects.

During the initial planning phase, we were given the opportunity to decide the tech stack that we would be using. After careful consideration, we chose the following:

Frontend: React. Chosen over NextJS because the app would only be used within the school system, so SEO is irrelevant.
Backend: FastAPI. Selected for its simplicity, familiarity with Python among the developers, and its automatic API documentation: essential for collaboration and rapid development.
Database: PostgreSQL via Supabase. Considering that the app usage would only peak during enrollment times, the generous free tier of Supabase would be enough.
Hosting: Render. Same as the reason above.

In the end, it was completely worth it. The department was genuinely satisfied with the apps, and we walked away with a 1.00 for the course.

Looking back, mastering the fundamentals all those years turned out to be the biggest game changer because it made learning an entirely new stack feel way less intimidating.

Top K frequent elements - My Solution

Jedric Tuquero — Wed, 22 Jul 2026 15:09:00 +0000

The Top K frequent elements is one of the many problems in Leetcode that involve hashing, and is also one of the first Medium challenge found in Neetcode, specifically when you start at the Arrays & Hashing section in the roadmap.

It states that given an array of integers and an integer k, create a function that returns the k most frequent integers.

It sounds easy enough, but the Dunning-Kruger effect got me once again. So, I opened the Hints section. It told me that the ideal solution must be O(n), and an algorithm that involves sorting based on frequency is applied to it. Google then led me to the Bucket Sort Algorithm.

From my understanding, the Bucket Sort Algorithm is well, an algorithm that is used to partition an input array into smaller arrays, assigning an element into an element array (or in this case, buckets).

After lots of syntax error and wrong outputs, here is what I came up with.

First, I initialized the needed data structures, namely the map dictionary, the bucket array which is just an array of arrays, and the result array.

def topKFrequent(self, nums: List[int], k: int) -> List[int]:
    map:dict[int,int] = {}
    bucket:list[list[int]] = []
    result:list[int] = []

Then, I used a for loop to populate the empty array into well, more empty arrays, specifically len(nums) + 1 of them in order to handle the edge case of the array going out of bounds when the frequency of an element is equal to the length of the array.

#Initialize bucket
for i in range(0, len(nums) + 1):
    bucket.append([])

Next, in order to count the frequency of each integer,I utilized the map hashmap, where the integer serves as the key and its frequency as the value.

#Map the numbers to their frequency
for num in nums:
    if num in map:
        map[num] = map.get(num) + 1
    else:
        map[num] = 1

After that, this is where the bucket sort algorithm is implemented. The frequency of the integer serves as the index to which bucket will the integer be appended. The more frequent an integer appears, the higher the index it will be assigned to.

#Use frequency as index when appending to an inner array
for num,freq in map.items():
    bucket[freq].append(num)

Finally, I stored the most frequent integers into the result array, checking until a length of k is reached. Since the most frequent integers were indexed at the near-ends of the array, we must iterate backwards in order to access them first.

#Iterate backwards, insert numbers to result array until k length is reached
for arr in reversed(bucket):
    if arr == []:
        continue
    for nums in arr:
        result.append(nums)
        if len(result) == k:
            return result
return []

And that's it. Overall, it took me around 30 minutes to solve the problem. I'm also still trying to study the behavior of Python data structures since I come from Java, so syntax errors at the very first press of Run will be inevitable xD.