Posts on Joel Garcia

Water Rocket

Mon, 01 Jun 2026 00:00:00 +0000

TODO

Edventures 2026

Sun, 01 Feb 2026 00:00:00 +0000

The MIT&CIC&UPC Hackathon is an annual event organized by the MIT Edgerton Center in collaboration with UPC, where +240 HS students across three faculties ideate, design, and then build a project. In this blog post, I’ll go over the entire organization of a hackathon from the ground up—from documents used by the Edgerton Center to conduct design reviews to scheduling and ideating.

This is the ideal case scenario, and there are many things I outline in this document that we currently do not do. Part of my reason for writing this post is to create a better organizational structure for the future.

Additionally, I want to highlight Christian Cardozo and Aleksandra Kaminska for their amazing job during this last hackathon. As I’ll discuss below, this was a complicated hackathon in terms of experience and time, and I believe they were able to pull off the impossible.

Structure of a hackathon

The hackathon has five main parts:

Icebreakers

During Icebreakers, the goal is for students to break the dynamic of school and try to get them out of their comfort zone. We have done several activities in the past, including building tetrahedrons, bingo, rapid ideation, etc. However, I will go more in-depth into this topic in another post, as there are many lessons to be learned in this section alone. TL;DR: you need to break the kids’ expectations and make them talk to people outside their school. Activities within this section should encourage the sharing of ideas and experiences. In the past, we have used Bingo, the Marshmallow challenge, the telegraph, tetrahedrons, etc.

Ideation

In this section, students must come up with ideas and discuss them with their peers. It is critically important that they do not join based on friendships or schools in this part, as we want to avoid groups being formed by friends rather than by the idea. During this part, we want students to see all ideas and learn about what is being thought of across the room. We usually start by asking groups to form ideas with people around them. Then, we form categories based on their ideas, and they go to discuss these ideas within those categories. After this, we ask them to visit a different category to see other ideas.

Project Selection

After Ideation, students must join together into groups of 4 to 6 people, which cannot be formed by schools or friendships. Teachers are critical in this step as they know the students and we don’t. They have to upload a form containing the name of the group, their names, and a brief explanation and sketch of their project. This helps mentors organize them into common topics and assign them a mentor.

Project Building

This is the longest section of the hackathon by far, letting students build their projects. However, this section is actually divided into three parts:

Cardboard Prototype

First, we give students cardboard and ask them to build a prototype that either looks like or works like their project. This is to ensure: 1. The viability of the project; 2. The dimensions and inner workings of the project; 3. That the group actually cares about the project itself. 99% of teams fail because they don’t feel passionate about their project, and this can be seen early on.

Design Reviews

After the cardboard prototype, groups undergo a design review by an experienced mentor. This serves the purpose of better understanding the project, making sure students know what their project is and will look like, and ensuring that materials make sense and the approach could work. One of my favorite questions to ask here is: “As a user of your product, how does it feel to use it? Or what would it look like to use it?” This question makes them think about all the details they want their project to incorporate.

Minimum Viable Product (MVP)

After design reviews, we give groups a materials sheet and ask them to build a Minimum Viable Product or MVP. This serves to set a goal and some limits on what will and won’t happen at the end of the hackathon. Some projects may have a huge cardboard car while others may only have some electronics, but setting these boundaries is helpful, as students stop thinking about every single detail and just work towards a working prototype.

Presentations and Closure

By the end of day three, we have a project fair where parents come to see their kids’ projects. Students prepare slides and show their project working (or not) to their peers, teachers, and family members. After the fair, everyone goes to the auditorium where we have a roundtable with some students, teachers, and mentors, and we distribute diplomas to the students.

The 2026 Hackathon

This year’s hackathon was not the best we have ever done. I see several failures in both organization and execution that made the hackathon worse for everyone. Students do not realize these things because they are hidden, but we have observed several details that show a less-than-ideal hackathon.

Also, I must remind the reader that this article is intended to further improve the hackathon. Everything I discuss here should not be taken as criticism, but as a list of possible improvements.

Groups by Coalitions

One of the main problems encountered during the hackathon was that sixteen out of eighteen groups (16/18) were formed by coalitions of schools (i.e., 3 students from school A and 3 students from school B). We made it clear during ideation that they couldn’t form groups by schools—that they had to mix—but students resisted being alone. This created coalitions of schools, as most groups were formed mainly by the joining of two schools. This may look “good enough,” but it shows that students were not joining by ideas, but were simply evading the “no single-school team” rule. This could be due to an issue during icebreakers and ideation, where students did not mix properly and tended to stay close to their friends.

Lack of Communication

The main issue encountered during the 2026 Hackathon was communication, or the lack thereof. Schools, mentors, teachers, and students had complaints about a lack of a clear messaging and communication system, resulting in conflicting information that complicated the execution of the hackathon. For future years, a clear communication system must be created, including documents outlining everything that a school, mentor, teacher, and student should know before, during, and after the hackathon. The most critical part of organization and team management is communication—not only from top to bottom but horizontally within the organizational structure.

Mentor Inexperience

In Terrassa, out of 16 mentors, only four, including myself, had taken part in a hackathon before. This ratio is not ideal. Most mentors had very little knowledge of how to do their job or what to expect, making this hackathon feel a lot more like an actual school than it should have been. A ratio of 1:1 should be the minimum for a hackathon; last year we had seven new mentors with 11 experienced mentors, a ratio of 2:3, which is fairly balanced.

Hackathon	MIT Instructors	Experienced Mentors	New Mentors	Ratio (new:exp)	Number Of Students	Ratio Student to Mentor	Ratio Student to Exp. Mentor
2023	3	11	3	1:5	-	-	-
2024	4	7	2	1:5	125	1:10	1:11.4
2025	4	7	7	2:3	114	1:6	1:10.4
2026T	1	5	11	2:1	108	1:6.5	1:18
2026E	1	8	4	1:2	80	1:6.1	1:8.9
2026F	3	9	4	1:3	90	1:5.6	1:7.5

The table above shows an organizational issue with the distribution of mentors across hackathons. If someone had computed these numbers before the hackathon, we would have seen issues in 2026T before they happened.

Domains and websites - The creation of this portfolio

Mon, 19 Jan 2026 00:00:00 +0000

Over the last two weeks, I have started setting up my own domain and websites/urls for different projects and uses. Here is everything I discovered.

Buying a domain

There are hundreds if not thousands for offers for domains out there. Some of them include email, hosting of the website using something like wordpress, and others include fees for random stuff. I have come to realize that most of these are targeted to people that do not have the technical expertise to set up things themselves. Plans may be as high as hundreds of dollars per month or as cheap as five dollars. But all of these are still absurdly expensive in my opinion.

Of course, if you do not have the technical expertise, you have no option. But if you do, this is how I setup things myself.

First, I bought my domain from cloudflare for $10/year. It includes the domain plus every feature that cloudflare offers with their extremelly generous free plan.

What I have built

Only with the domain, you instantly get access to setting up DNS Records (using your domain to point to things). This includes anything that is before your domain as a prefix (sth.joelgarciamartin.com) or after (joelgarciamartin.com/sth). With this in mind, this is my current setup:

joelgarciamartin.com -> Main website. Hosted in GitHub Pages.
beta.joelgarciamartin.com -> Development website. Hosted in Cloudflare Pages.
joelgarciamartin.com/blog -> Blog, hosted in Cloudflare Pages.
link.joelgarciamartin.com -> Simple redirect links. Hosted in Cloudlfare Pages.
go.joelgarciamartin.com / rsvp.joelgarciamartin.com -> Redirect page with tracking. Hosted using dub.co.
local.joelgarciamartin.com -> Tunnel to my computer for local development. Requires authentication using Cloudflare Auth.
My own email addresses: me@joelgarciamartin.com & help@joelgarciamartin.com -> Using iCloud as the inbox with their custom domain feature.
cal.joelgarciamartin.com -> Access to my calendar for scheduling. Used Notion Calendar and a redirect rule.
hack.joelgarciamartin.com -> Access to an app we plan to use for a hackathon. Requires username and password and the website is hosted using Google Cloud.
files.joelgarciamartin.com -> Access to a cloud file server hosted using Cloudflare’s R2 Object Storage. Requires authentication using Cloudflare Auth.

In the next sections, I’ll discuss the setting up of these URLs and what I used.

DNS Records

Probably the most annoying/dauting feature in hosting your own domain is using DNS. Yes, it is incredibly powerful, but at the same time, it sucks.

DNS (Domain Name System) is what the internet is based on to know where each website is. If you are trying to access “google.com”, your computer does not know where it is, so it asks your router. If your router doesn’t know either, then it asks your ISP, if your ISP doesn’t know, then it asks the Root DNS Servers.

What these will do first, is check the termination of the domain. So they will say: “I don’t know where google.com is, but I do know that this server handles .com”. Basically it will tell you to go knock another door. That other server will say “oh yeah, google.com is this server”.

Finally, you will have an IP right? Well, not quite yet, you have now hit Google’s DNS Servers. Google wants to distribute traffic equally along it’s network. So if you are in the UK, it will tell you to use a specific server close to you, plus it will tell different computers to use different servers to distribute the load.

A DNS request looks like this:

Here I asked my local ISP for where joelgarciamartin.com is located. My ISP handled the interaction with other servers to figure out the IP. In this case, 185.199.109.153. If we look closely at the answer section, we can see it “cached” the answer for 300 seconds (300 before the “IN”). So it does not have to ask every time to the DNS servers what IP to use. Basically, your computer, router and ISP will use that IP for the next 300 seconds.

This is why sometimes something stops working for 5 minutes, if 185.199.109.153 stops working, your computer will still try and access that IP for the next 5 minutes. But once that time expires, your computer will ask again for the IP and will get a different one which works, solving the issue.

Setting up a DNS Record

Having said this, DNS servers need to know where to point (i.e. when a request comes for joelgarciamartin.com, it needs to know what to say). We do this by using DNS Records. These have multiple propieties:

Type: What type of Record we will use. This is because you could point at a specific house (an IP) or at another URL (something like dns.example.com) or others. Types of DNS
Name: What prefix you want to use for this record. For example, test.joelgarciamartin.com . That “test” is defined here.
Target: Where to point. This could be an IPv4 if we used type A or another domain if used CNAME.
TTL: For how long should websites “cache” your target. If you set this to 24h and the server goes down or the target changes, you may have to wait up to 24h for your domain to work again. Usual times differ, you could set this to as low as 1min and up to 24h.
Proxy Status: A Cloudflare Only setting. This can be used to “protect” the real target. When someone tries to reach the URL, cloudflare will stand in the middle and act as a middleman, protecting the user of seeing the actual IP of the target. Useful for security reasons.

An example of a DNS Record, is the one I use for my GitHub Pages hosting (joelgarciamartin.com):

I am basically redirecting people to “newtoniano20.github.io”. The URL will always show as joelgarciamartin.com, but the underlying IP for the URL is the same as newtoniano20.github.io . Basically, when your computer asks for the IP, clouflare will say “Go ask newtoniano20.github.io”, and will use the IP for that URL for mine. I disabled Proxy as for HTTPS and GitHub Pages, the Proxy messes up the connection.

Hosting

GitHub Pages

Probably the easiest to setup, the only thing you need is a github account, a static webserver and redirecting traffic to Github Pages.

I know it might be dauting if you have never done anything before in HTML/CSS. But GitHub does have a fairly simple tutorial for setting this up: Tutorial

Next, going to Settings > Pages > Custom Domain. You can use your custom URL to access that site. You will need to setup the DNS Records to point to that website though.

New Blog!

Sun, 11 Jan 2026 00:00:00 +0000

Hello!

I have created this blog for publishing what I am doing or working on. Not sure how I will use this or how often I will, but the purpose right now is to create the platform and figure out it’s usage after that.

Cardboard Airplane

Fri, 01 Dec 2023 00:00:00 +0000

TODO

The Blue Man Group (Foot Piano)

Thu, 04 Aug 2022 00:00:00 +0000

TODO

Shanking Hands Overseas

Sat, 19 Feb 2022 00:00:00 +0000

A message from the future

Hi there! This is Joel Garcia from 2026, I wrote this back in 2022, so there are things that might be a bit confusing. So, two things:

If you have any questions, please feel free to contact me via email (joel.garcia1202@hotmail.com). I completely understand if this is too vague or confusing. I wrote this a long time ago.
If you want the prototype I used, I don’t have it! But you can request it to Alicia Lopez, who currently has it (aljornet@mit.edu).

Introduction

In this project, we recreated a human hand which can be moved using a sensor glove, which sends information to our hand from the other side of the world. This project was done with help of the MIT Edgerton Center and we would like to thank the help of the people listed bellow:

Jordi Vidal ( Work experience at ESA )
Lucas de Bonet ( MIT freshman 2021 )
Edward Moriarty ( MIT Edgerton Center )
Arnau Ortega ( CIC Student 2021 )
Gerard Solanes & Bernat Gascón ( Thau SC )

This is a summary of the project, any questions feel free to ask :)

Supplies

Materials Used

180 degrees servos Recommended Link
Arduino power supply / 12V to 5V converter + 12V battery
3D printed hand Recommended Link
Arduino Uno or ESP32
Potentiometers Recommended Link
Badge Reels Recommended Link
WD40
Nylon Gloves or similar Recommended Link
JST connectors Recommended Link
Fishing string

Building

Step 1: Download All Files & 3D Print Them

Download all necessary stl files from Inmoov (Link) and from LucasVR glove (Link)

Then Proceed to build them following their steps.

For our last prototype, we only used the hand from Inmoov and the servo holder, we then sticked them into a piece of PLA and used them that way, which is a much simpler way.

If prefered, you could use a smaller version with a potentiometer and a single finger (Link)

Step 2: Setting Up the Envoirement

To set everything up, we need 3 things:

A server / API , this can be hosted locally for debugging, but it is crucial to have one outside your local wifi for overseas testing. Code
A Data Sender or glove
And a Data receiver or hand
(Optional) A Frontend to send debugging data to the API or using a tool like Postman

For the everything, you will need to use my driver, firmware & API cos, which usage are explained in the README file of each part. GitHub Link

Step 3: Connecting All Cables

The hand should be set up following this diagram and the Glove following lucas instructions ( Link)

You must bridge the power supply ground with the arduino one, if not, it will not work.

Step 4: Todo List Before Shaking Hands

Once you have a running server, proceed to connect the arduino to your computer and start the driver.

If you run ./run.ps1 or ./start.sh, all dependencies will install and start the program

Once that is done, you will see a selection between Receiver or Sender. In the case you are acting as a hand, type 1 and otherwise type 0.

Then select serial port and it will start sending or receiving data. If your serial port is not present, type 9

You must upload the firmware before selecting serial port.

If you start seeing data coming in, you are ok, if not, check connections.

If your server requests fail, check if the API URL is ok and that you are connected to the internet

Step 5: Done

If all of the above are done, it should work. If you encounter any issue, please contact me.

Enjoy shaking hands overseas!

Airplane Launcher

Wed, 01 Dec 2021 00:00:00 +0000

TODO

ROV

Thu, 30 Jan 2020 00:00:00 +0000

TODO