Jose M.

I created the first iteration of my new portfolio page. I have made a few portfolios before, but none were ever to my liking so I decided to try again and I really like this one! I decided to use vanilla HTML/CSS/JS because using something like Next.js or React would be overkill and I'd like my portfolio to be lightweight. I also spent a few hours making a nice little HTML canvas animation that performs well even on high-frequency monitors. While I'm sure my portfolio could use some work in some places, I think it's a great start!

In this update, I made the program much more stable and reliable by making it spawn its own wpa_supplicant process when necessary rather than depending on the system. Also, I'm using Linux's 'rfkill' utility to block the wifi card when not in use to keep power usage minimal.

For some reason, though, my program stops sending updates when there's no hotspot available but does not re-detect them when nearby.

In the next devlog, I hope to have fixed any issues and maybe remove the dependence on wpa_supplicant altogether.

In the future, I plan to integrate GoogleFindMyTools and OpenHaystack into my project to leverage Google's Find Hub and Apple's Find My for much better tracking when there's no nearby open networks. These tools work by relying on nearby iOS and Android devices for location updates, so they'll likely be more reliable and use less power.

I figured out that the Raspberry Pi Zero W 2 doesn't support 5Ghz Wi-Fi which means it can't connect to Xfinity and many other hotspots at all. However, thanks to the Hackmate YSWS, I was able to buy a Raspberry Pi 3 A+ which is cheaper than a Pi Zero W 2 + USB-A to microUSB + a 5Ghz Wi-Fi dongle. It's also pretty nice as it has full-size HDMI and USB ports which are great for debugging, especially when having to turn Wi-Fi on and off. Though, I'm unsure if the power consumption is low enough to last a good while on a power bank. I'll have to try disabling services, disabling the ports when unused, only turning on Wi-Fi and Bluetooth periodically for short durations, etc. Optimization is really important as a power hungry device would mean having to charge the power bank multiple times a day which is infeasible. I'm thinking maybe charging the power bank in the car or at home once a day would be a bit annoying but doable.

Anyways, I've been making the project connect to hotspots in a more stable way and I've switched to using Docker to emulate aarch64 rather than cross-compiling as it's much easier but a bit slower. Also, I've added a feature so the program caches previous locations when unable to connect to the server which will ensure that I get a continuous, complete location history.

While doing some testing, I noticed that the Google Geolocation API can get as accurate as 10 meters with nothing but a list of nearby Wi-Fi networks which is very impressive and honestly insane. I'm thinking of potentially logging nearby Bluetooth devices which would give me an idea of how many devices are nearby and how close they are which could potentially help in a theft situation, though this is just speculation. Same could be done for logging Wi-Fi clients such as mobile phones. Modern phones often use active Wi-Fi scanning rather than passive scanning, so it would be possible to detect when phones with Wi-Fi enabled are in the vicinity. There's certainly a lot of work to do going forward!

I've also done a bit of work on the web frontend and I'm learning how to use OpenStreetMap and Leaflet to display a nice map in a web UI. I'm also thinking of creating a mobile app later to receive notifications and even potentially send messages to the raspberry pi for administrative purposes. Though for now, I'm only receiving data over HTTPS from the pi.

Sorry for the rambling and I'm glad that I was able to get past the Wi-Fi issue and make some great progress so far!

I completely revamped the UI and fixed some bugs to make the user experience better. Also, I completely rewrote the scraper to be more reliable and scrape more data such as user bios and profile pictures. Finally, I changed the font from Roboto to Montserrat, which made the UI look much more appealing.

My windows XP VM broke out of nowhere, so it took me a while to fix before I could update my code and make this devlog.

In this update, I made the chat client much more reliable. When a chat server closes, the client returns to the home page. Also, the servers page refreshes every few seconds and closed servers are removed from the page to make user experience much better.

For some reason, windows uses UTF-16 under the hood while I like using UTF-8, so I had to fix conversion as any non-ASCII characters such as emojis and Greek or other language characters (e.g., lambda) were previously broken.

At this point, I have a fully functional chat client and server code that seems to be ready to deploy! I'll also think about making a web client so non-XP users can chat with windows XP users through their browsers!

I have now made the chat gui. It has been very difficult working with multithreading and asynchronous programming. There were many deadlocks, but it's finally stable.

I built this project using C++ and the Win32 API. The current architecture includes a central server which tells the program what servers are available. The client can then choose a server, and the server does all of the chat handling stuff. I am using TCP sockets and a custom protocol for communication between the central server, servers, and clients.

So far, the central server is about ready and is built to run on Linux. Currently, the chat server is WIP but it's coming along well.

Working with Windows' Win32 API is difficult but rewarding!

I have finished writing this MCP server and have uploaded it to npm.

This project can be used with Claude Desktop or other AI tools to give the LLM the ability to search for Summer of Making projects and users. It can search by name and slack id and also sort by minutes logged, number of devlogs created, etc.

I refactored the backend to make the API much easier to consume. Rather than sending the entire 2.5MB database, clients can search for certain data and can receive up to 200 results. Also, the project now also leverages the Summer of Hacking API to allow searching by Slack user URLs.

I spent a lot of time tinkering with raw SQL to get it to work just right. I learned that when developing a moderate sized project, you should probably try to do things right from the start or you'll spend lots of hours cleaning up.

This project uses Node.js, Express, and Prisma ORM for the backend and plain HTML/JS/CSS for the frontend.

I created and deployed the web app after almost 6 hours of straight development time. Most of the time was spent developing the frontend UI and the scraper itself. Currently, the following features are supported:

• Request an update (re-scrape for available projects)
• Search for projects. Sort by minutes, devlog count, or random. Filter by author name or title
• Search for users. Sort by minutes, devlog count, or random. Filter by name

Scrapes are infrequent and the app does not scrape a page twice to avoid causing unnecessary load to the HackClub servers. For this reason, users, projects, and thumbnails are cached locally on the server.

Currently, all filtering and sorting is done on the frontend, so the entire ~3 MB scraped data collection is sent to the browser. I will fix this in a later update to increase the efficiency of the frontend.

AI was only used for problem-solving. All code and assets were created by me.

I have made significant progress on my project. So far, I created a simple backend and a C++ daemon that runs on the raspberry pi. The daemon communicates with wpa_supplicant to scan for networks, connect to public Xfinity hotspots when possible, and sends a list of nearby networks to the backend whenever possible.

The backend itself uses Google's Geolocation API to resolve a location from a list of nearby networks. So far, this has been pretty accurate but may not work well in rural areas.

A problem I faced is that the Pi Zero 2 W does not support 5Ghz out of the box, so I'll need to purchase a 5Ghz-capable Wi-Fi adapter and a microUSB to USB-A adapter and temporarily put a hold on the project.

I'm not sure how well this is going to fare in terms of power consumption and power bank battery life. I'm hoping I can have the power consumption below 500 mA which gives 20 hours of charge on a 10,000 mAh power bank. I'm thinking I may be able to power on and off the Wi-Fi adapter in intervals to reduce the average power consumption to 250 mA for around 40 hours of battery life.

Currently, I'm slightly unhappy with the costs but I can try and compile a cheaper list of components later. Other than these issues, development has been going great!

I created pastie from the ground up using fastify for the backend and vanilla HTML/JS/CSS for the frontend.

Some features I implemented are:
- End-to-End encryption and decryption in the browser using AES-256-GCM and PBKDF2 (w/ SHA256)
- A sleek dark UI
- Raw paste access
- Once a paste is created, the decryption key is included in URL for easy decryption

• Added freelook by creating a temporary pitch/yaw variable and modifying rendering logic to use the temporary values when enabled
• Added ESP using OpenGL's glDepthRange function
• Refactored some code