Hacker Newsnew | past | comments | ask | show | jobs | submit | craig0990's commentslogin

Location: Kuala Lumpur, Malaysia (UTC+8; Singapore/Hong Kong/Perth timezone)

  Remote: Yes, especially APAC/Australia/Singapore/Hong Kong or async-friendly global teams
  
  Willing to relocate: No
  
  Work authorization: Full right to live/work in Malaysia. EoR preferred for overseas companies; contractor possible.
  
  Technologies: TypeScript/Node.js backend services; Kafka/event-driven microservices; PostgreSQL/Redis; Linux/Docker; PHP/Laravel monoliths; React/React Native; SAML/auth; ERP/SaaS integrations.
  
  Résumé/CV: https://www.linkedin.com/in/craig0990/
  
  Email: [email protected]
Staff+ backend/platform engineer with 12+ years across web systems, event-driven backends, edtech platforms, and enterprise integrations. I work best where systems already have history: business workflows, data movement, auth edges, production behavior, and people depending on all of it staying boring.

Right now I am the senior IC across four engineering pods at an auction platform. The work is mostly TypeScript services around Kafka/Avro, ERP integrations, and operational workflows. I still write and review code, but a lot of my day to day is in production triage, architecture review, and helping teams keep shared systems understandable.

A concrete example: I led the replacement of a Boomi iPaaS layer with an in-house microservice between operational systems and Dynamics 365 ERP. Migrated flow by flow over 12 months with a team of four, using feature switches and rollback plans. Integration errors dropped by about 85%.

Earlier, an application architect on a multi-tenant edtech SaaS used by thousands of schools, working across PHP/Laravel monoliths, React/React Native, OpenShift/Kubernetes adoption, SAML IdP maintenance, and legacy password migrations to bcrypt.

Looking for senior/staff backend or platform roles involving mature systems, integrations, event flows, auth edges, operational workflows, or production problems worth thinking about.


I'm always curious to see these projects, because I've been experimenting with a React renderer for the GJS bindings for a while. It's frustrating because GTK "feels like" it's so close to being able to support a vdom/declarative paradigm, but the devil is in the details.

The simple use-cases like "Window > Box > Label" are easy to get going. The more complex widgets like Stack/Grid/TreeView ... aren't.

This project seems to have the same issue: https://github.com/bodil/vgtk/issues/40

This is made more difficult now GTK4 has removed the Container base class, so there's no longer a unified interface for adding children (although it had caveats in the first place).

I totally get the GTK view that (presumably) specific widgets are more intuitive with specific add/remove APIs (like the grid - one doesn't really "appendChild" to a grid).

It just feels like: if there was a consistent container API comparable to the web's appendChild approach, a vdom/declarative approach would require only a very light wrapper. Without it, I keep coming back to the idea of implementing wrapper widgets that expose that consistent API instead. And that's just not something I want to maintain - effectively duplicating each GTK widget for the purpose of making it fit into a tree model.

It's also a problem of trying to wrap richer functionality (pack_start and pack_end) into a simpler set (append only) of course.

So I don't know exactly what my point is :) Perhaps cautioning the reader that the simplicity of the approach comes with a catch.


It's pleasing to see this kind of...is arcana the right kind of word?

We once visited an SMK Agama school because they were having trouble explaining their issue to the support desk. They were creating Word documents with a custom Jawi TTF that was...weird (sometimes it was one-to-one with sensible ASCII equivalents, but ligatures seemed to be implemented in completely random parts of the Unicode space). Nobody really seemed to know where the TTF came from either, it just sort of bounced around the aether via email, Dropbox, and ancient Google results.

They were naturally confused that copying and pasting perfectly "legible" Jawi script from Word into our <textarea> was rendering it into gibberish.

But half of us had never even heard of Jawi, we just assumed it was Arabic (but it isn't, apparently, it's more subtle than that).

We didn't quite want to commit to supporting the font directly, because it opens all sorts of questions about what to do if the receiving user doesn't have that font installed, how many fonts do we support, what if there's another font that uses different mappings (which there was)?

We did, however, produce a document that pointed to https://www.pendidik2u.my/cara-betul-install-jawi-di-kompute... with some custom explanatory text and steps, to support users who wanted to write Jawi directly in a more Unicode-friendly way (we didn't call it that, we just explained that other users "wouldn't need the font", which they approved of).

I'm not sure how many users this ultimately helped, or if they just gave up and embedded Word docs instead of using native platform text, and it's unfortunate that there isn't a more formal, one-click-install keyboard for this on the Microsoft Store.

(I also seem to remember a Tamil user who said that there might be a section of Unicode called "Tamil", but it's missing a tonne of characters they would like to use, so Unicode still has some way to go I guess)

But it is one of my favourite bug reports :)


Thanks @criag0990 for sharing your problems with the Jawi Keyboard. Didn't know about Microsoft Store.

I'm using a macOS so i didn't notice - also macOS already has their own "Malay Arabic - Jawi" Keyboard built in so thankfully i didn't need to make one for macOS.

But i'll try to upload my version up to Microsoft Store (which is not SIRIM but based on phonetics from latin alphabets to make typing more natural as you don't need arabic stickers or arabic keyboard - You can use your normal QWERTY keyboard.

you can download it from here: https://jawikey.com but i will try to get it in Microsoft Store. :-)

I am not sure about the font because we use Ubuntu fonts and it works perfectly fine. (maybe missing for "va" character)

As for the font is that as long the font supports those jawi-specific unicode characters everything should be fine. For now, things have gotten a lot better with Jawi as compared 6-7 years ago.

The version from your URL is actually the official Malaysian SIRIM Standard which is based on the Arabic keyboard.


Ah, I see, so yours is using a different key mapping, but still outputs the correct Unicode characters? I remember the stickers on the keyboards :)

By "weird TTF font" earlier, I meant they had a Jawi font that basically worked like Wingdings - they were typing a genuine ASCII "A" (0x41/0x61), but the font was "rendering" an aleph (I think). So it looked OK with the font. But it wasn't "proper" Unicode.

I'll keep https://jawikey.com in mind for the future though :)


> (I also seem to remember a Tamil user who said that there might be a section of Unicode called "Tamil", but it's missing a tonne of characters they would like to use, so Unicode still has some way to go I guess)

Tamil Unicode is perfectly usable; this sounds like someone who didn't understand the encoding model, and expected to see a separate Unicode character for each consonant/vowel combination.


That is entirely possible. As somebody who doesn't read/write anything beyond English, I didn't want to disagree.

The "virtual keyboards" I've seen in use for non-Latin writing systems seem cumbersome to me as an outsider, so perhaps they found it difficult to produce the right combinations to achieve what they wanted.

I'm always a bit disappointed that my response to the issue of trying to digitise someone's culture is to kinda shrug and say "that's the best we've got".


Jawi is basically Arabic script it just has a few extra glyphs to handle phonemes that don't exist in standard Arabic. For example /p/ or /ng/ (velar nasal).

Anybody who can read the Quran and speak Malay can also read Jawi with minimal effort, which is most of population of the Malay archipelago.

A similar but distinct script was used for languages of Indonesia, e.g. Javanese and Sundanese.


That would be Pegon, https://en.wikipedia.org/wiki/Pegon_script.

However, both Javanese and Sundanese also have their own distinct writing systems that are not based on Arabic (https://en.wikipedia.org/wiki/Javanese_script, https://en.wikipedia.org/wiki/Sundanese_script) and would not be at all readable to an Arabic reader.


I've actually just tried something similar for work (we'll see how it goes).

Take Material for MkDocs with the "mermaid2" and "plantuml-markdown" plugins, a custom plugin to inline SVG diagrams [1], and "mike" for versioning.

This gets us a Git repo where anyone can draw and contribute diagrams with either Mermaid, PlantUML, or Draw.io diagrams embedded in SVG. Hosted in GitLab Pages for access control.

All three diagram formats support hyperlinks in their outputs, so we're aiming for a clickable, "zoom-able" adaptation of the C4 Model [2].

It's a bit fiddly to get going, but quite nice and easy to work with afterwards, provided individuals can commit time to updating the diagrams.

In principle, GitLab supports PlantUML with extra config, and SVG embeds, but in practice we can't yet commit to updating our self-hosted GitLab, and the SVG embed is aggressively filtered - so Draw.io embeds often show up blank. MkDocs solves the "make it pretty, browseable, and searchable" aspect. Git and "mike" solve the "what was the original design again?" aspect.

I'm tempted to write the approach up, but I broke my blog - perhaps I should rebuild it with Material for MkDocs :)

The Material for MkDocs Insiders program gets you nice extras (mermaid support built-in, stay-on-same-page across "mike" versions, and more) [3]

[1] https://pypi.org/project/mkdocs-plugin-inline-svg/

[2] https://c4model.com/

[3] https://squidfunk.github.io/mkdocs-material/insiders/

(edit: typos)


Thanks. This is an alternative vision compared with what I am doing, but it seems better. Especially the C4 model as basic philosophy, and then the supporting technology.

Pleas blog about this, it is very interesting to me.

Just to be sure: this is what you mean with Mike?

https://github.com/jimporter/mike


Yep, that's the one - the versioning was more important to me than it might be to others (even internally). mike was a bit confusing to set up in CI since it re-commits the build back to a branch (imagine the loops you could get yourself into) but the output is nice.

We're not strict about C4 (we actually created an alternative-but-similar flow incidentally) - but C4 to me is a nice diagrammatic principle of "Don't Repeat Yourself" - draw a box, label it, and link to that system's diagram instead.

I could go on for pages / hours :D I'm a bit over-passionate about documentation. Email's in my profile, FWIW.


Thanks, this is similar to what I have started to work on. Note GitLab supports a Kroki integration, which is a powerful way to enable "all the things" wrt diagramming libs.


Reference [21] is written by the same author and is a much more detailed thesis about the theory of "Reconciling Perspectives".

I haven't read all of it, but it's available on the University of British Columbia website:

https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/...


I remember feeling the same thing - I could just "build a website" but I wanted to prove that I had actually learned something over the last three years.

So what did I do? I re-implemented Git in PHP (read-only). It was, to put it mildly, difficult, and stressful, but I actually managed to pull it off (mostly).

I didn't just choose at random, obviously. I wanted to add file version support to an open-source project, and after some basic research, settled on Git. The catch was that the open-source project ran in a pure-PHP environment (no modules beyond those commonly found on shared hosting). So I had to find a way of reading Git repositories in PHP without resorting to exec() etc. Hence, read-only Git in pure PHP. Throw in WebDAV or SSH and you can actually push / pull to those repositories with front-end clients like SparkleShare, which was a good candidate for future work.

I nearly went crazy, of course. I had little-to-no understanding of DVCS concepts, graphs, and so on (big O analysis is still difficult to be honest). However, by writing the project, I got much more direct experience of graph theory than I ever would studying a text book. This has turned out to be incredibly useful in my day-job as a developer.

The take-away I'm trying to get to is: pick something completely (or slightly) unrelated to computer science concepts like big data, AI, etc. and find something you're interested in. Then ask the question "How do I apply X to this?".

(These examples are purely off the top of my head, and may actually be ridiculous in practice. YMMV)

"How can I use big data techniques to analyse my web server's access logs?" "How can I use AI/Machine Learning to detect shellshock attacks on my server?" "How can I use computer vision techniques to render a map of the local area using drones?" "How can I use big data, AI, machine learning, and computer vision techniques to analyse the proportion of cat pictures and videos posted to social media?"

What I want to re-iterate though is that I started with "I want to add file versioning support to this software" and ended up discussing graph theory, diffs, patches, open-source etiquette posts by ESR, big-endian and little-endian integers (Git uses both in it's file formats), binary fanout tables, the SHA-1 algorithm, content-addressable filesystems, and all sorts of other crazy stuff I hadn't even anticipated when I started.

My supervisor liked it - I wanted to sleep for a month straight.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: