ammmir

I'm working on ExecAPI - https://execapi.com - a code execution as a service platform, starting with WebAssembly nanoservices, deployed a bit like CGI scripts, but running on the edge, so comparable latency to Cloudflare Workers and Lambda@Edge. Currently thinking about ideas around HTTP-triggered workers, long-running services, web hook handlers, etc. and how we can bring cloud costs down to the bare minimum.

It's more of a fun project right now, but hoping to unearth some marketable use cases and ideas as I go along. I'll do a proper launch in a month or two.

Manually replicating writes to all nodes seems pretty fragile. At some point you're going to run into classic distributed systems issues, like netsplits, and reconciling the latest count. Maybe a CRDT implementation would avoid these issues alltogether?

But it sounds like LiteFS (with a single writer?) might be a pretty nice setup if it handles replication for you, as you probably don't want to build a Raft or Paxos system yourself.

Yeah, I just woke up to some alerts, too. Sometimes I get the feeling people don't take IPv6 seriously!

I remember building an XULRunner-based OpenVPN client GUI for a customer, before there were sane web-like cross-platform UI toolkits.

Yeah, I remember having to call out to XPCOM to do stuff like HTTP requests or TCP socket communication IIRC.

It was the Electron of its time. RIP.

While this is a good overview of the options for primary key generation, there's no silver bullet here. Most projects that are using SQL should just use the gold standard: an auto-incrementing integer for an internal primary key. And then decouple the public-facing primary key from it into a separate column, whether it be ULID, UUID, or a random-project-slug-123.

Also, during debugging, it's a lot nicer to look at short primary keys than to have UUIDs flooding the screen.

Anyone in Bangkok? Would love to do an IRL meetup.

The one thing from the Stripe docs I like is the embedded API key in all the code snippets, but this seems difficult to accomplish with Markdoc, especially if you're rendering the whole site to static HTML.

For example:

  ```bash
  curl https://api.example.com/stuff \
    -u {% apiKey /%}: \
    -d "foo=bar"
  ```

If the user is logged in, I want the {% apiKey /%} to be replaced with something. Do I use a transform, node, or tag to accomplish it? It seems easier to write:

  ```bash
  curl https://api.example.com/stuff \
    -u MY_API_KEY: \
    -d "foo=bar"
  ```

And then have custom JavaScript that runs on the page that does a search-and-replace for the string MY_API_KEY with the user's API key (obtained async with API, etc.). The documentation on Markdoc needs work.

Kind of related, but what I'd love is a way to share part of my local file system with the remote host without using FUSE or requiring root access on the remote system. Something like:

    local $ echo world > ~/src/hello
    local $ sharewith-ssh --dir ~/src:/src code.example.com
    Last login: Wed Aug 16 09:33:55 2022 from 1.2.3.4
    code ~ $ cd /src
    code /src $ cat hello
    world
    code /src $

I think it could be built with a local agent, a binary that you download on the remote host to intercept file system calls for a path (run it and it execs your shell with LD_PRELOAD to the library), and then forwards file system and I/O requests back to the the agent over SSH to get at those files. You could even have a permission prompt UI on the local agent to permit/deny individual reads/writes.

Does anything like this exist?

How does it compare to ObjectiveFS (a commercial offering) and S3QL (now abandoned)?

Would JuiceFS be suitable for a handful of servers (and mobile laptops) with connection latencies anywhere from 5-150ms accessing the same file system? Workload is basic home directory stuff (lots of tiny files, few large ones, read-heavy, write-rarely). I wonder about the operational complexity in running the metadata server (yet another thing to manage unless outsourced); if it goes down, do all fs operations block/fail until it's back up?

I'm looking for something like the now-abandoned s3ql file system but one that allows multiple hosts to mount the same volume and have reads/writes "just work" without conflicts.

Location: Bangkok (UTC+7)

Remote: Yes

Willing to relocate: Maybe

Technologies: Go, TypeScript, node.js, Deno, Next.js, React, Svelte, Elixir, C, eBPF, Swift, Win32, VPN, GraphQL, SQLite, WebAssembly, SSO, WebAuthn, web3, crypto, browser extension, ...

Résumé/CV: https://amirmalik.net/resume

Email: amir@amirmalik.net

I have 10+ years experience implementing software systems. I'm a full-stack engineer and have experience in everything from low-level network protocol design to frontend UX/UI implementation. I highly value teams that are remote-first and operate in an asynchronous working style. I'm currently based in East Asia (but happy to travel anywhere on Earth to meet you) and prefer to work non-nocturnal working hours. If the team is based in the West, that means you get me as an on-call person during U.S. night time for free :)

Latest few projects:

* I worked with the folks at Uno https://uno.app on a few different cool things on automating browser and WebView logins using custom automations, React, and browser extensions.

* "Web3" side project: https://loginwith.xyz built in PHP (nostalgia ftw!), SQLite and Dockerized into a beautiful small container setup. Given time, I'll add WebAuthn support and deemphasize web3 wallet logins. It has a pretty neat Amazon-style email magic link login that's easy to integrate into your website. Just open-sourced it on GitHub.

* Main side business: https://kvdb.io built in Go. In-progress work includes replacing the Lua scripting engine with a JavaScript engine or possibly WebAssembly or a pool of sandboxed Deno worker processes. I think the app server paradigm of the 2000s will be back with a vengeance. Running for 4+ years and I intend to keep it running forever.

The way I've implemented in one of my own projects [1] but that I'm not fully happy with (and the way that Amazon.com does it) is to do what you suggest: create a record on the backend when the login attempt begins and have your frontend keep checking that record until there is a result like email verified/not-verified/timed-out. When the user clicks the magic link in the email, update that record with their choice to approve or reject the login, or ultimately time out and invalidate the login attempt. This avoids the separate cookie jar problem.

The phishing scenario is a real one, though. People have been conditioned to click Yes on everything. Coinbase's magic links implementation, for example, requires you to click the magic link in the same browser session that initiated the login. This is a bit more secure, although annoying from a UX perspective if you're in an embedded WebView like you mentioned.

The middle ground is something like instead of sending a link, send a code via email that you enter on the website, but that just removes the magic of magic links and is no different than what it was before!

[1] https://loginwith.xyz

Location: Bangkok/Seoul (UTC+7/UTC+9)

Remote: Yes

Willing to relocate: No

Technologies: Go, golang, node.js, Next.js, TypeScript, React, Elixir, Erlang, C, eBPF, Swift, Win32, VPN, API, GraphQL, SQLite, Tailwind, REST, SSO, WebAuthn, web3, crypto, browser extension, ...

Email: amir@amirmalik.net

Résumé/CV: https://amirmalik.net/resume

I have 10+ years experience implementing software systems. I'm reaching out beyond my usual network to try to find interesting and unique opportunities. I'm a full-stack engineer and have experience in everything from low-level network protocol design to frontend UX/UI implementation. I'm open to both part-time and full-time work. I highly value teams that are remote-first and operate in an asynchronous working style. I'm currently based in East Asia (but happy to travel anywhere on Earth to meet you) and prefer to work non-nocturnal working hours. If the team is based in the West, that means you get me as an on-call person during U.S. night time for free :)

Latest few projects:

* I worked with the folks at Uno https://uno.app on a few different cool things on automating browser and WebView logins using custom automations, React, and browser extensions.

* "Web3" side project: https://loginwith.xyz built in PHP (nostalgia ftw!), SQLite and Dockerized into a beautiful small container setup. Given time, I'll add WebAuthn support and deemphasize web3 wallet logins. It has a pretty neat Amazon-style email magic link login that's easy to integrate into your website. Just open-sourced it on GitHub!

* Main side business: https://kvdb.io built in Go. In-progress work includes replacing the Lua scripting engine with a JavaScript engine. I think the app server paradigm of the 2000s will be back with a vengeance. Running for 4+ years and I intend to keep it running forever.

SEEKING WORK | Worldwide | REMOTE

I have 10+ years experience implementing software systems. I'm in the process of exploring full-time opportunities, but in the meantime, I'm open to some contract work for the next month or two. I'm specifically looking to get my hands dirty on a Go project or something other than the usual React/node.js/TypeScript :)

Keyword soup: Go, golang, Elixir, Erlang, C, Swift, Win32, VPN, API, GraphQL, SQLite, Tailwind, REST, SSO, WebAuthn, web3, crypto, browser extension, ...

Fun facts: Last public side project I built was https://loginwith.xyz but https://kvdb.io is still going strong albeit growth has stagnated.

Email: amir@amirmalik.net

Resume: https://amirmalik.net/resume

GitHub: https://github.com/ammmir

LinkedIn: https://www.linkedin.com/in/amirmalik/

An interesting question on many levels.

Is a notebook and pen the only conveyance of information or will you have your memories retained on the return to the present day? Do you devise an encoding scheme prior to departure to maximize the bits of information that can be written in the notebook?

How will you act on the information when you return? Will people believe you? Do you want to come back with some verifiable information so people will believe you? Before leaving, announce that you will visit the future, and ask everyone with a private key to sign a message to their respective future selves, so that their messages from the future can be verified by the present self?

What is the goal of this endeavor, to personally profit or for all of humanity to profit for mistakes that will be made between now and 2050?

You could spend the entire 24 hours teleporting to various places on Earth (and possibly Mars and the Moon), talking to random people in all socioeconomic strata of society, all the while taking copious notes and have them write signed messages in your notebook. Kind of like a yearbook from the future.

Or do you ask specific questions about science, medicine, advances in technology, materials, so you accelerate humanity's progress forward?

When you return, do you decide to mint your notebook as an NFT collection? Auction it off? Go on Joe Rogan to talk about it? Keep stock, crypto, market prices to yourself so only you can benefit? Become a philanthropist with the profits?

So many questions.

default SSH key is the same one for GitHub (since they leak users’ pubkeys anyway), and private repos (eg. hosted GitLab instances) get their own keys. not really sure if it buys any privacy though.

I love Go.

It's the new Java, but fewer batteries included, and very easy to learn. I spent a day going over https://gobyexample.com/ and became productive the next day. I tried to do the same with Rust, but I failed. Nobody was able to succinctly explain all the things you have to learn to become productive with Rust, let alone understand anyone else's code, since there are too many different ways of doing the same shit.

I fear generics will make Go go in a worse direction, but I'm not losing sleep over it.

I would even go as far as to say Go is the fastest way to land a $100K/yr job with zero knowledge about programming and still be able to live with yourself (unlike with the JavaScript/npm oligopoly).

Solid Go'ers eschew huge dependencies and prefer classic Unix KISS philosophies. It's a breath of fresh air. And like the performance figures show, your apps magically get slightly faster over the years!

Life is short, use Go.

He made it free for a few days, go have a read!

I can’t. I think the eye is oblong shaped for myopes, and correction worsens this oblongity. By training your eye like a muscle, you’re decreasing it, hence the focus improves. I’m sure someone can explain it better. Don’t trust me, try it! And eat carrots and look at long distances in the daytime when taking breaks from work. Some old wives’ tapes have some truth to them.

I thought it may be helpful for others, it’s a consolidation of knowledge and anecdotes, you can find the same info for free on forums and by reading research papers :)

Say what you will about not being able to reverse myopia, but I didn't really believe it. My brother recently wrote a book about his experience of going from -4 to 0 diopter over the course of less than a year without surgery: https://www.discoveryournaturalvision.com/

I tried the same technique. I went from wearing -3.5 contacts to -1.5 in about 3 months. The basic concept is forcing your eyes to read any text closeup (computer screen, books) at the edge of blur instead of it being in focus. That's basically all there is to it. People prefer laser surgery because it's less work than putting in the effort 8 hours a day for 3+ months at a time. I admit, I've given up after reaching -1.5, since it's good enough, but I'd like to rid myself of contacts entirely. The last 20% is 80% of the work, same principle applies :)

studying too much at close distance, and not spending enough time outside

Sounds like you already know the solution: treat your phone number as disposable. Get a new eSIM anytime you feel you want a refresher. It costs nothing, a dollar or two a month for prepaid. Turn it on only when you need to verify.

Although I'm not a peak rush hour user, I love Seoul's Line 9. It has the best logo, the best station arrival jingle, and the stations are generally clean and sparkling new. Sinnonhyeon station, right in the middle of Gangnam, curiously has an entire unusable mezzanine/cavern level that you pass every time you take the escalators down to the tracks. Seems the station was overbuilt for capacity, but the line itself can't support more passengers.

A public/private partnership seems more the way to go: municipality funds development of the line but lets private sector entities operate it according to agreed-upon standards and performance objectives. That's the way it works in Stockholm, Hong Kong, and many other cities. On the other hand, if it's all publicly operated, then what's the incentive to keep improving things since your only stakeholder is the public and you're a monopoly anyway.

Most arguments against PHP miss the point. You know why you should use PHP? Because it's fun and you can get something running much quicker than figuring out the Elixir, Ruby, Rust, whatever ecosystem and paradigm. Maybe PHP is not so good at WebSockets or async worker threads, but most projects don't need that. There's no shame in doing long polling, users can't tell the difference anyway!

PHP shines when you're trying to get a server-rendered web app off the ground. It's the VB6 of the web. Nothing else matches its development velocity, from keyboard to working code.

What wonderful pictures! I just realized I rarely see people smiling or looking happy in photos taken in the 19th century. I wonder why?

Maybe cameras of the time were too big and serious looking, and everyone ended up posing.

It's not the software availability, it just looks ugly.

There was a short period in the mid-2000's where there was a lot of desktop eye candy (sup KDE) and accelerated window managers like Beryl, but it regressed from there.

Look, nobody wants to be diffing config files when they upgrade random software packages. The lack of UI polish, multiple UI toolkits, questionable UX choices, and user ergonomics are poor. Give me a Linux desktop with a beautiful and consistent UI like we had with Windows 2000 and I'll be the first to use it.

Let's face it. MacOS is the real successor to the UNIX throne, most of the middle class uses it, and everyone else is on Windows.

the wireguardification of the kernel! just kidding, I applaud this welcome performance boost, it's always been tricky to extract the most performance out of Samba, especially over high-latency links, although that's more of an SMB protocol issue than anything else, but hopefully ksmbd helps in that regard.

I also live in Korea, but the only places I could imagine being able to survive for $600/mo would be outside major cities and eating kimbap and ramyeon for your takeout meals and living in a goshitel... no offense! Of course, if you're putting down a large deposit, then your rent could even be free.

Personally, I wouldn't bother with jeonsae unless somebody else is paying for it (parents, employer, bank), keep your money in your favorite speculative investment instead.

the generics mafia has ruined rust and looks like go is next.

I've mostly consulted and worked with companies based outside of Korea, so I can't speak to onsite experience personally.

If you're wondering about work-life balance, in which Korea has a poor track record in general, it's going to vary wildly based on the team. The best is to try to get recruited from outside of Korea if you're looking to join a larger company. The startup scene is vibrant, too.

It's hard to give general advice without knowing your motivations, but feel free to drop me an email and I'll be happy to offer any advice :)