Truth!

Man in the event of some newcomers to the development game, those that will mostly work in the web domain or sys admins that are in training I want to offer some small advice:

Do not neglect vim

I know it might be a bitch to use at first. And I will never use it as a replacement to vs code. But fuuuuuck me I cannot count the number of times that vim wizardry has helped me when dealing with servers when dealing on a machine with windows and nothing but putty.

The thing is a lifesaver yo, and it makes for an impressive show when doing something in front of senior executives.

Learn it, love it, live by it

And exit is :q, save is :w, to copy and paste is :v then surround the text and then y to yank it and p to paste it.
:vsplit and :split are your friends and to move around splits is ctrl w and direction.

Good luck my friends. Stay classy.

Random thoughts on more out of the box tools/environments.

Subject: Pharo

Some time ago I had shown one of my coworkers about Pharo and he quickly got the main idea behind it but mentioned how he didn't like the idea of leaving behind his text editor to deal with source code.

Some time last week I showed the dude some cool 3d animations you can do with Pharo while simultaneously manipulating the code to change them in real time. Now that caught his attention particularly and he decided he wanted to know more about the language but in particular the benefits of fucking around with an image based environment rather than a file based.

Both of us reached the conclusion that image based makes file based dev enviroments seem quaint in comparison, but estimated that it was nothing more than a sentiment rather than a fact.

We then considered what could be the advantage/disadvantages of such environments but I couldn't come up with anything other than the system not having something like Vim or VS Code or whatever which people love, but that it makes up for it with some of the craziest IDE tools I had ever seen. Plugins in this case act like source code repos that you can download and activate into your workflow in what feels something similar to VS Code being extended via plugins written in JS, and since the GUI is maleable as it is(because everything is basically just subsets of morp h windows) then extending functionality becomes so intuitive that its funny

Whereas with Emacs(for example) you have to really grind your gears with Elisp or Vimscript in Vim etc etc, with Pharo your plugin system is basicall you just adding classes that will convert your OS looking IDE into something else.

Because of how light the vm machine is, portability is a non issue, and passing pharo programs arround is not like installing Java in which you need the JVM.

Source code versioning, very important, already integrated into every live environment and can be extended to do pushes through simple key bindings with no hassle.

I dunno, I just feel that the tool is too good to be true. I keep trying to push limits into it but thus far I have found: data visualization and image modeling to work fine, web development with Teapot to be a cakewalk and work fine, therr are even packages for Arduino development.

I think its biggest con would be the image based system, but would really need to look into how this is bad by any reason other than "aww man I want vim!" since apparently some psychos already made Emacs and VS code packages for interfacing with Pharo source trees.

Embedded is certainly out of the question for any real project since its garbage collected and not the most performant cookie in the jar.

For Data science I can see some future, seems just as intuitive and interesting as a Jupyter Notebook actually, but the process can't and will not be the same since I still don't know of a way to save playground snippets unless you literally create classes for it, in which case every model you build gets saved inside of an object, sounds possible but, strange since it is not a the most common workflow in jupyter.

Some of the environment is sometimes glitchy, but it does have continuos development and have not found many hassles.

There is a biased factor from my side: I seem to be wired to understand the syntax and simple object model better than in other languages. To me this feels natural as if I was just writing ideas rather than code, mostly because I feel that there really ain't much in terms of syntax, the language gets out of my way and the IDE feels like the most intuitive environment in the world to me. I can see why some people would find it REALLY weird of counterintuitive tho.

Guess I really am a simple dude.

🚀 “I Wanted GitHub Copilot in My Pocket — So I Built It Myself”

For years, I’ve had this weird habit of coding from random places — cafés, buses, hospital waiting rooms, you name it. But every time inspiration hit, I found myself thinking the same thing:

“Man, I wish I could just use Copilot on my phone.”

It’s 2025. We’ve got AI writing novels, generating music, and summarizing 500-page research papers in 2 seconds — yet somehow, GitHub Copilot still refuses to leave the comfort of VS Code on desktop.

So I decided to fix that.

💡 The Idea

It started as frustration — a “wouldn’t it be cool if” moment. I was halfway through an idea for a small project on a train, and my brain screamed:

“Why can’t I just ask Copilot to finish this function right now?”

VS Code was sitting at home, my laptop was dead, and all I had was my phone.

That night, I scribbled this into my notes app:

“Bridge Copilot from VS Code → phone → secure channel → no cloud.”

At the time, it sounded insane. Who even wants to make their life harder by reverse-engineering Copilot responses and piping them into React Native?
Apparently — me.

🧩 The Architecture (aka “How to Lose Sleep in 4 Easy Steps”)

The system ended up like this:

VS Code Extension <-> WebSocket <-> Discovery API (Go + Redis) <-> React Native App

Here’s how it works:

The VS Code extension runs locally, listening to Copilot’s output stream.

A Go backend acts as a matchmaker — helping my phone and PC find each other securely.

The mobile app connects via WebSocket and authenticates with a 6-digit pairing code.

Once paired, they talk directly. No repo data leaves your machine.

It’s like a tiny encrypted tunnel between your phone and VS Code — only it’s not VPN magic, just some careful WebSocket dancing and token rotation.

🛠️ The Stack

Frontend (Mobile): React Native (Expo)

Backend: Go + Redis for connection brokering

VS Code Extension: TypeScript

Security: JWT + rotating session keys

AI Layer: GitHub Copilot (local interface)

🧠 The Challenges

There’s a difference between an “idea” and a “12-hour debugging nightmare that makes you question your life choices.”

Cross-Network Discovery:
How to connect phone and desktop on different networks?
→ A lightweight Redis broker that just handles handshakes.

Security:
I wasn’t making a mini TeamViewer for hackers.
→ Added expiring pairing codes, user-approval dialogs, and local-only token storage.

Copilot Response Streaming:
Copilot doesn’t have a nice public API.
→ Hooked into VS Code’s Copilot output and streamed it over WebSocket.
(Yes, 2% genius and 98% madness.)

UX:
The first version had a 10-second delay.
After optimizing WebSocket batching and Redis latency, it’s now near-instant.

🤯 The “Holy Sh*t, It Works” Moment

The first time my phone sent a prompt — and my VS Code actually answered with Copilot’s suggestion — I legit screamed.

Like, full-on victory dance in the middle of the night.
There’s something surreal about watching your phone chat with your desktop like they’re old coding buddies.

Now I can literally say:

“Copilot, write me a REST API,”
and my phone responds with fully generated code pulled from my local VS Code instance.

No VPN. No cloud syncing. Just pure, geeky magic.

⚡ The Lessons

The hardest problems aren’t technical — they’re psychological.
Fighting “this is impossible” is the real challenge.

Speed matters more than perfection.
Devs don’t want beauty; they want responsiveness. Anything over 1s feels broken.

Security must never be an afterthought.
I treated this like a bank tunnel between devices, not a toy.

Build for yourself first.
I didn’t make this for investors or glory — I made it because I wanted it.
That’s the best reason to build anything.

🧭 The Future

Now that it’s working, I’m turning this experiment into something shareable.
The dream: an app that lets every developer carry Copilot wherever they go — safely and instantly.

Imagine debugging on your couch, or editing code in bed, or just whispering to your AI assistant while waiting for coffee.

Phones today are more powerful than early NASA computers.
Why shouldn’t they also be your code editor sidekick?

So yeah, that’s my story.
I built VSCoder Copilot — because I wanted to code from anywhere, and I refused to wait for permission.

If you’ve ever built something just to scratch your own itch, you already know this feeling.
That mix of frustration, caffeine, and late-night triumph that reminds you why you fell in love with coding in the first place.

Because at the end of the day, that’s what we do:
We make ideas real — one ridiculous hack at a time. 💻🔥