DEV Community: Ayane Satomi

Writing UI in .NET sucks

Ayane Satomi — Tue, 10 Jan 2023 00:27:37 +0000

.NET is amazing. It allows me to write code for everything in one tooling, with minimal handholding, everything is (almost) self-contained, and most importantly, I can even code my own website using nothing but .NET if I wanted to...

...But I wouldn't wish anyone to code UI in .NET.

The UI tooling is bad... very bad

Before you cranky bunch of people decide to pull out your recently polished mechanical keyboards and clack at the speed of sound stating about UI Frameworks like Avalonia, Uno Platform, MAUI, etc. Please hear me out:

.NET never really had a good cross-platform GUI solution that allowed us to work to our full potential. Most, if not all, UI tooling is Windows-specific (looking at you Blend), we don't have good WYSWYG editors, and it took as long as .NET 6 until it became competitive enough to be used as a framework for writing applications like Flutter.

And we didn't have proper UIs for embedding them inside applications too!

Sure, we have the imgui framework and tons of other niche UI frameworks, but really, that's all we have. - and even then, they were cumbersome to integrate, usually taking more time to implement them in .NET than natively

Did I mention even the most popular CEF bindings are also Windows-only? This is sloppy on our part because we might have a fancy new framework, but we never evolved beyond .NET Framework-isms.

And to put the icing on this dysfunctional cake, Microsoft's own WebView2 library lacks some of the core facilities such as off-screen rendering, and still had some problems here and there by its own standards too, not a good look for a framework being championed by a company who is touting it as their own modern solution for writing things everywhere.

Oh, did I mention the only working embeddable UI right now I can find is also proprietary and requires a license?

Our attitude with UI development needs to change

While I love the new innovations coming to .NET, most of them do not relate to what I need, and it feels like every second the community has neglected this side of development of .NET. This toolkit is more than just for ASP.NET, or for writing servers, or just for Windows-related stuff.

Where and what else does .NET's ecosystem or feature set do you find extremely lacking? Let's discuss in the comments.

Mapping out Gacha Pull Probabilities using Python and Google Colaboratory

Ayane Satomi — Sun, 11 Oct 2020 15:15:39 +0000

COVID-19 brought us some good stuff because of boredom, some of you may have worked on your applications that you abandoned because you have no time, some of you are probably giving your cats a good well-earned petting, I spent one day of my quarantine doing what most otakus with computer science degrees do best: using our knowledge with programming and technology to our advantage to "cheat" Gacha pulls.

First of all, I do not condone cheating, however, the idea around here is that a group of people were working on mapping a statistical model of Gacha probabilities which tends to have a very predictable RNG. Let's just say I got interested so I decided to hop in on the fun.

Background

Gacha originates from Gacha vending machines which usually you drop a hundred yen to get a capsule that gives you a cute thing, but one out of a thousand of those is an exceedingly rare item out of the pile of gacha capsules inside that vending machine.

Fast forward to modern gaming, the gacha mechanic is used by a lot of games - especially anime-themed ones like Arknights.

Gacha games usually employ an index of items to check, and a Pseudo-Random Number Generator, with either your User ID as the seed or in more extreme cases, the server time as the seed. However, Gacha RNG has a "drop rate" or a probability that you would get your preferred item in a N number of drops. And of course, that involves a lot of money to thoroughly test this, so why not use our knowledge of data science to figure out that instead of wasting buckets of money just to figure out the distribution by hand?

Starting out

The entire project was started by an acquaintance I met who goes by KaidenFrizu with one simple goal: they wanted to figure out how much rolls it would require getting the desired results in a N number of times.

This has been going on for a while now, I only joined to the party since I believed that the RNG algorithm also has an effect of the outcome of a roll (considering not all RNGs are created equal: some of them uses bitshift and some of them uses cryptographically secure algorithms).

After a while, my involvement became more hands-on as I started to port a Python code by another member of the discussion who goes by the name "Eyenine". Together with the resident statistician of the group, SurfChu85, we went ahead and implemented a Jupyter notebook that maps out the probability of a rolls in a specific number of iterations.

// Detect dark theme var iframe = document.getElementById('tweet-1315129367006076931-772'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1315129367006076931&theme=dark" }

The implementation

The implementation focused on using the Subtractive PRNG - the same PRNG used by C# for its Random API, and the use of a Numba-optimized loop function that does the following:

for a specific rate and N number of iterations with the drop rate of X with a sample size of Y:
- iterate until N is reached as...
- ...another iterator iterates until sample size Y is achieved...
- keep iterating on attempts and find a good hit from a RNG vs the rate. If a hit is found, increment the rate, and start all over for until the maximum increment range is achieved.
- After one iteration for N is achieved, save output to an iterable and repeat the loop until N is achieved.

The following algorithm was designed to match the Arknights RNG system that also included a "pity" system that increases the rate should the RNG fail to get the target drop rate on a specified number of failed rolls.

You can view the entire implementation in GitHub:

sr229 / gacha-prng

A Jupyter Notebook that maps the probability distribution of the Arknights RNG for Gacha rolls.

gacha-prng

A Jupyter Notebook that maps the probability distribution of the Arknights RNG for Gacha rolls.

Running

You can run this on Google Colaboratory!.

Copyright

View on GitHub

Which you can open in Google Colaboratory. It should work with Binder as well if you're not into using Google services.

The results

From what we can gather on the output of the Jupyter notebook, we have concluded the following:

Fixed UID as seeds

There is a much steeper curve in fixed seeds (aka seeds that use UIDs).

Therefore, from what I have analyzed fixed UIDs will require more pulls to get a desired drop, and only at the 51st pull will you see the probability increase.

Time as seed

One of the most interesting simulations we did was a theory that a variable seed would have yield a much wider graph which means on a ever increasing seed would also imply that the distribution will be higher as time goes on.

Again, due to how Arknight's pity system modifies the Gacha algorithm, the pity system would be overkill to the point the probability would increase with the lesser number of rolls and uniformly the higher number of rolls as well. This gives an insight into why time-based seeds are not so oftenly used in Gacha games.

Conclusion

Based on our discovery, I can only produce one TL; DR - prepare to simp even harder because you'll need to roll even more.

However, from an experience standpoint, it really shows what we can do with simple statistics and data science to solve a literal "million-dollar question". Such methods have been used to solve more practical problems, but I can now rest well knowing we just helped an entire Gacha community to plan properly when doing the money drain, we call Gacha rolls.

Credits

Of course, this entire knack of a project won't be possible without this bunch of people:

We made this project for a greater community, and I hope you like what we did in it!💖💖💖

From Express to Serverless: How we wrote a legacy Express Server to a Serverless API with the help of Next.js

Ayane Satomi — Mon, 05 Oct 2020 01:27:07 +0000

Serverless one of the new trends everyone has been looking forward to. The concept is quite simple: instead of coding it as a stateful server that we have to monitor it's state everytime, the API would be split into the most basic primitives called a "function" - and these functions execute once and then turn themselves off immediately after the request has been fulfilled.

The problem is I haven't seen anyone done a writeup on how Serverless weighs against stateful APIs in production-scale like setting, so I decided to help out one of my friends in the most daring projects I've ever helped with creating.

The Beginning

Back in a year ago or so, My friend who goes by the name Nathan built an API with a simple goal: to act as a data source to allow third party integrations from a game called Azur Lane. The idea is simple but we have to pull from a JSON dataset to be able to do so. The API was written in Express, and the bottlenecks were this:

It cannot handle large concurrent requests due to how the endpoints requiring humongous amounts of resources due to the need to pull the source once, deserialize it, and filter it according to the user's filters.
The backend's components are composed of a Resolver, a GitHub puller and a primitive form of cache. the problem is that pulling files once and putting it on cache inside the backend's working set was a memory issue since it's shared with the main loop.
Response times were horrendously slow. To fulfill a request, you have to wait for 5000ms to actually get a request.
If we're ever going to add a new feature, you have to code a new DI for it. This was rather unacceptable.

Seeing how the code done was pretty much good but with the response time of a hot pile of garbage, I decided to give Nathan a call and said: "Hey, I think we can fix this, we might need to do this in serverless"

Why Serverless?

Based on my analysis of the stack, it boils down to this:

Debuggability can be narrowed down to one components and one lambda. In stateful applications you have this other noise from the framework because they call each other and send a state from each other.
Endpoint's caches can be isolated to one function instead of sharing the same working set. You can argue you can do the same for stateful servers but they simply don't have the resources.
It allows a much more cleaner code. The DI was performing in such a inefficient manner that it costs time for the DI to accomplish and return data that the bottleneck were around 500ms.
We wanted to keep costs low. That was the entire point as well. We wanted to scale without needing to commit a large sum of money to run an API mainly built by broke college students on their free time.
We wanted to make the API easy to extend. The previous backend was not very flexible with scaling itself that the dev itself was admitting that they basically built a server they couldn't maintain properly anymore.

And so, my goal was set: redo the entire f***ing thing from scratch in Next.js and code it in TypeScript - a industry-tested, type-safe, scalable JavaScript superset.

The journey

The work began by porting the rest of the stuff to Next.js and TypeScript. I began to redo the Mixin models we use then ported a few of my own handlers. Keep in mind this time, Nathan, the original author wasn't into it yet and it's only a week later he decided to join in after some convincing.

PS: to give you perspective: he argued that Next.js wasn't scalable in a way but I argued that if it wasn't scalable, Netflix and GitHub won't be using it. Let's just say that alone was also the reason I picked Next as well.

Of course porting what is known to be a monolithic express application is very daunting - not all of the express stuff applied: we had to code our own middlewares and other equivalents of the backend. Next was a very minimal framework at it's best - it's there to get rid of the routing and some of the React stuff you have but you still have to code a lot of your components by your own, which is a good thing since too much abstraction just leads to unused code.

2 weeks passed by and the API was already feature parity. DI is no longer performed by abusing require(), we were using actual Mixin patterns using ECMAScript decorators - and boy that experience made Nathan like the new rewrite. Eventually we got a third guy on board and they helped us write tests for it.

Another week passed by: we weren't focusing on parity anymore: we were just adding features. After a while, we decided to add MongoDB support and local function caching using a Map, and finally, in a historic moment, we merged everything to master.

And the API was never the same again.

Key Takeaways

The API is more dynamic and thanks to Vercel, making an API made by 3 volunteers global scale without any effort from our end.

One of the things we also improved is how we did Mixins and DI, and believe me, considering how it looked like before:

The new Next.js and TypeScript code was much more better. While Next.js is hard to adapt properly in first, but once you finally finish, adding features and maintaining it will be easier than before.

What's next

Of course we're not stopping there. Now we have the API done, Nathan decided we should make a viewer, and here's a sneak peek on how it looks like:

Interested on helping us out? Our repository is here:

nimiiiii / nimi-api

The unofficial API for Azur Lane

Nimi

Welcome aboard! Nimi is the unofficial API that returns JSON data from Azur Lane and is always updated to the latest game version. Unlike most projects of the same mission, we're using a serverless approach for providing you these data, however, since we're iterating rapidly, there might be some bugs and of course, we change some stuff really fast so beware of maelstroms and icebergs, Captain!

Compared to previous version

Due to the stateless architecture of the new API, we are able to reach more audiences much more better than before. And thanks to the new API's architecture and Vercel, the service is now accessible anywhere in the world, we're no longer isolated in one region! You're always 80ms or 160ms away from the service.

What's next?

We're just getting started. We have a viewer coming up (and it's fully automated unlike the Azur Lane Wiki), and…

View on GitHub

Conclusion

It really shows that Serverless when done right can be a replacement for a regular stateful server in such cases, however, before you do jump on a stack, make sure you do a stack analysis and see which works for your team and for your client.

When do you actually use Cloud IDEs?

Ayane Satomi — Sat, 12 Sep 2020 15:13:55 +0000

With the resurgence of Cloud IDEs as part of the development workflow, and unusually, as part of the Cloud Native movement as well, most developers ask: "Do I really need to use a Cloud IDE?"

I, myself, have experienced both experiences, as some developers has did as well. I came from an era where Visual Studio Code was still in it's infancy, and we had to use something like Komodo IDE if we wanted top notch IntelliSense and code linting.

But nowadays, with the emergence of GitHub Codespaces, Gitpod, and Eclipse Che, it's almost that we have too many options for tooling nowadays - and all of them are much more richer and extensible than the previous generation of editors.

However, with so much options, when does the choice between a browser-based IDE and an IDE you can execute within your start menu or launchpad matter?

What made Cloud IDEs successful?

The idea behind Cloud IDEs are the concept of "portable workspaces" - that is, for every machine you own, you have the same set of tools, you just need to open it from a workstation with only a browser and that was it. You just need to open a link from another machine and you're back to where you've started.

What also garnered the attention of the many was Cloud IDEs allows customizable, reproducible stacks that you can write once and it works for all machines, no more case of "it works on my machine" if they all rely on the same configuration. It also allows the code to stay only on the servers they belong to as well, increasing security for code developed in air-gapped environments.

But it can't replace localhost, and never will.

Cloud IDEs may have won over the masses for their flexibility and reproducibility, however, Cloud IDEs can never replace traditional localhost development. Why? Because of these primary reasons:

Most of the development going on in Cloud IDEs are focused on online distributed systems. GUI programming is sparse because of their container-focused nature.
Cloud IDEs usually do not support HPC (High Performance Computing) programming like GPU compute unless you rely on a large provider like Azure or AWS which allows such. But for most cases, generally available Cloud IDEs only expects you do regular programs like CLI programs or CPU-bound ones.
The cloud has latency. No matter how much you try, the latency of Remote Procedure Call Protocols is always higher than wired ones. While we had services like game streaming invest of trying to lower this latency, the cloud itself is in no way a good development environment if you want to program for least-latency.

Most evangelists also preach that in a few years we can switch everything to the cloud. I can bet you a thousand dollars right now, that it's technically infeasible to have everything moved to the cloud, even if we look forward to 5 or 10 years in the future.

But they do have a place and purpose

Cloud IDEs and Desktop IDEs are tools to help you write code more efficiently. We shouldn't argue which is better since every option has its own Achilles' heel. Cloud IDEs are good for programs that are usually on command line or requires a web interface, and desktop IDEs are good for what the Cloud IDEs can do as well but they can do more like programming for native GUI.

It's either preference or the security requirements that decide which tools you should use. But for personal preference, you should learn to experiment and decide which works best for you.

Conclusion

While Cloud IDEs has recieved major attention due to the cloud trend, it certainly isn't a one-size-fits-all solution. It's always the requirements of the application will decide if you should use it, or your personal preference.

My (infuriating) experience with GitHub Codespaces

Ayane Satomi — Fri, 11 Sep 2020 13:48:41 +0000

UPDATE: The show stopper issues mentioned here have been fixed already. However, I'm still leaving this up for everyone.

Yes, this cover image is a call for help because GitHub hasn't answered me for two straight days on stuck developer containers that I can't delete. And yes, I broke the entire Cloud IDE by trying to edit a Pull Request. Joy!

Let's wind back a little

Around 2-5 days ago, I got the most rarest thing to ever happen in my entire life.

A literal early access at GitHub Codespaces. Wow! The GitHub Gods has blessed this good-for-nothing can't-code-for-shit college student early access for their upcoming Cloud IDE!

And of course, as part of my ever-unwielding excitement, I immediately went to one of my projects, and tried it out for a few hours... Until it broke down.

Before I tell you how I broke one GitHub's killer features arriving later this year (if we're lucky enough), I want to share my key takeaways and what I hate on the service at the moment.

What I enjoyed so far

If you followed my old blog post before, the entire point of GitHub Codespaces is a easily-accessible way to contribute to a project, all without leaving GitHub itself.

GitHub launched their own Web IDE - does that mean Atom is dead?

Ayane Satomi ・ May 7 '20

#atom #vscode #github

Sure enough, this comes neatly as a option in the "Code" Button.

This opens a empty dialogue with a "New Codespace" button. Once you click on "New Codespace", GitHub does what most Cloud IDEs does, but it does it automatically, setting up the stack for you.

The entire stack setup does take a good amount of time (3-5 minutes on my benchmark), but it does make up for what it is advertised, a full Visual Studio Code experience right in the browser, already set up with your own credentials. Most execs would die for this kind of integration (which other cloud IDEs like Gitpod already does as well).

And after the long wait, you are greeted with Visual Studio Code, which you can choose between Insiders and Stable within the platform as well.

The default experience is a special light theme for Visual Studio Code which uses GitHub's color palette. I would like to express that this light theme isn't painful in the eyes (that's a major undertaking considering I am a avid Dark Theme user).

Hey Microsoft, release this as a proper theme, please!

There is also a GitHub Dark VS Code theme as well but I didn't bother to take a screenshot sadly, but it looks very pretty.

Of course Codespaces also checks if you have a devcontainer.json and a custom stack already for VS Code Remote, which GitHub Codespaces will happily use instead of automatically determining your stack. Unfortunately, I haven't tested it since I had no use for it since the default Codespaces stack already does for me.

Now sh*t gets ugly

Of course, it's not always sunshine and rainbows for such a early product. Once I started opening a Codespace based on a PR, it started to return 404s. And if I try to make another, this happened.

Apparently, Codespaces breaks if you try to edit someone's PR which you don't have write access to, and now I have two dangling codespaces that I can't delete.

And to make matters worse, I called on GitHub Support to clear out the non-existent codespaces that are linked to my account, and oh joy!

I haven't recieved a reply from Support 2 days ago! Shocking!

After that, I just gave up.

Conclusion

Codespaces has a lot of ways to go, with that kind of breaking bugs, I won't touch it with a ten-foot pole, but that VS Code experience is a bit alluring. But still, you get my point.

While they're fixing that, I'll stick to one of my favorite Cloud IDEs of all time, Gitpod, or the always 99.9% available localhost.

Isolate Your Games, Seriously

Ayane Satomi — Sun, 14 Jun 2020 12:14:11 +0000

Games were created for one purpose, to push the technical boundaries of computer graphics and altogether, deliver a compelling and entertaining experience. However, with the rise of online connectivity and online multiplayer, its normal for companies to come up with anticheat systems to make sure the player plays fair when they play a game.

However, some of these anticheat programs takes the anti-cheat way too far - as they even end up restricting programs to work, and may even send data about your computer and use it for targeted ads (or even worse, sell it), the phrase "enough is enough" would resort to most people - especially for those who care about their privacy.

CPU Rings - understanding the concept of privilege escalation

If you have studied computer architecture, a PC's privilege is seperated in "Rings of Privilege" - with 3 being least and 0 being the highest privilege.

Information Security 101 always tells us that running anything in Ring 0 is very concerning since this is where the kernel, and even the hypervisor, resides. However, given that you trust the drivers that run in Ring 0 (but it should be running on Ring 1 or 2 anyways), Ring 0 gives you the highest access possible for the system.

Ring 0 Anti-cheat - is it safe?

Now this is where the question resides, if Ring 0 is where the kernel resides, why does a anti-cheat, out of all the programs, needs the same access as the kernel?

The reason is very fair and reasonable as well - this allows the program to listen to the memory for known cheat signatures in the memory, and also does a integrity check on the game files. It's essentially a stop-gap to prevent a user with cheats that can't be detected server-side to connect to protected servers. Our friends from Secret Club provides more context about why such a Anti-cheat is necessary.

But Anti-cheat is a proper backdoor

Believe it or not, with that kind of access, your system is basically backdoored to the company with the semblance of legitimacy of your intent to play. But keep in mind, anti-cheats are client-server applications, and a simple breach in the server can modify the anti-cheat to perform arbitrary code execution, and keep in mind, Anti-cheat is only as trustworthy as the company that runs it.

Riot Games recently got cirticism for restricting background programs to run and has been messing with the system with Vanguard, Valorant's purpose-built anti-cheat. And its even more questionable because Riot Games has a partnership with Tencent (keep in mind Tencent is known to give access to the Chinese government access to their programs, if you remember the WeChat fiasco).

Should I give my games native access?

No one can tell what is in a game's stack. Games used to be programs meant to entertain people, but it then became hubs for targeted ads with intrusive analytics, and now, anti-cheat. There's no telling even a single-player game can have a secret remote procedure call to a web server telling about your hardware ID, then using it for targeted ads.

The answer for this is no. Never give your games access to native hardware, ever. In fact, games nowadays are glorified legalized trojan horses.

Playing the Game without worrying about Privacy

If you still want to experience the game, but worry about the implications of the anti-cheat, then you must prepare to use isolation via virtualization (or just isolation).

We used to mock about consoles with how they're so locked down, but it seems they've been teaching us how to run games in a secure fashion this time. Xbox One has been very stringent with security in their console - both hardware and software. The console is known to use NanoVisor - a customized version of Hyper-V that runs two VMs, one for the games and one for the UI, which is a tailored version of Windows.

NanoVisor ensures that even if one of the VMs get compromised, it would never have complete hardware access, which makes it a prolific example for this article - if Xbox One can play games in such complete isolation, why can't we in the PC?

Conclusion

The gaming industry must understand boundaries when it comes to data collection, and must be acquainted to the concept of privacy more than often. But then again, when you play a game, you understand the risk of using a program. But to save yourself the trouble of being that guy who will complain about on Reddit when there's a data breach in a anti-cheat server, run your games in isolation.

How to use NGINX ingress controller in K3s

Ayane Satomi — Tue, 26 May 2020 10:08:02 +0000

The NGINX Ingress Controller is one of the most used ingresses in the Kubernetes ecosystem, being more or less the best ingress controllers out there along with Traefik, which is the default load balancer and ingress in K3s.

So let's say you don't want Traefik, and you want the NGINX Ingress, the answer is: that's possible! And its very easy to get a K3s cluster to use a NGINX Ingress Controller.

Getting your cluster ready

First order of business is that you need to get your cluster have no other ingress controllers as this would conflict with your current ingress controllers. This is because NGINX and Traefik both listens to 80 and 443, which causes conflicts with each other, so make sure your K3s cluster only has one kind of the other.

For the best results, your K3s cluster must be installed with the --no-deploy-traefik argument, which will cause the K3s cluster to deploy only with the bare container orchestrator without the default HTTP backend, which is Traefik.

to make sure you don't have a Traefik controller installed, run kubectl get deployments -n kube-system to see if Traefik is gone.

If you have verified Traefik is not there, then you may proceed with the next part.

Installing NGINX

There's two ways to install NGINX, either from a Helm chart or a direct kubectl apply -f <file>

Using a Helm chart

The NGINX ingress is available in the Helm Stable Charts, and if you have the stable registry already installed in your Helm CLI, simply run helm install stable/nginx-ingress.

You may also modify the installation using the following configurations stated here.

Using the regular `kubectl`

If you don't want to use Helm, then you can use kubectl apply.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-0.32.0/deploy/static/provider/cloud/deploy.yaml

This will launch a very basic configuration of the ingress controller, with still having the option to configure it using the configmap.

Verify if it works

Browse on your cluster's address and the all-familiar default NGINX 404 screen should greet you that it works.

How does it compare to Traefik?

In my perspective, not having the UI to monitor the traffic (a Traefik feature) is the only thing I missed, however, I also noticed at one point that the browser returns a HTTP_TOO_MANY_REDIRECTS error if you try to point it in a TLD/subdomain, which I am not yet sure why it doesn't work.

Keep in mind this was tested in Civo so the usual YMMV (Your Mileage May Vary) applies here.

Conclusion

Overall, there's nothing much change for the layman's perspective and nothing's better than the other since Traefik and NGINX are equally good ingress controllers. It depends on preference on which do you like to use for your cluster and which you believe is good for your use case.

This entire guide was tested on the Civo Cloud Platform as part of their #Kube100 initiative. If you're interested to help them test the K3s platform, click on the link to apply!

My Experience with Civo Cloud - The first-ever K3s platform

Ayane Satomi — Sat, 16 May 2020 02:36:44 +0000

We all know K3s. It's a slimmed down version of Kubernetes. It only contains mostly v1 resources and is considered the most lightweight Kubernetes distro to exist (and the easiest to onboard to, even easier with k3sup). However, I haven't seen K3s get public cloud adoption from some vendors, because you have to manually install it in your IaaS or your local cloud if you're ever going to try it out.

However, a new cloud hosting company, Civo decided that: "Hey, if K3s is this popular, why not we build our platform on top of it?" And that's what they exactly did.

Of course, knowing such a service exists now, I decided to give it a spin by joining their #Kube100 beta. And this is my insight on the platform and K3s being used in a large production setting.

First impressions

Civo itself is a rather new player in the Kubernetes hosting club, but its certainly the first to offer K3s as its Kubernetes distribution of choice.

Now this may not sound like amazing but its certainly an eye-opener since most of the vendors have their own distributions of the infamous container orchestration software, and they're certainly not lighweight most of the time (most vendor Kubernetes distributions eats almost an average 10% of the RAM and the CPU cycle of the instances it runs in).

However, the platform itself is not just a Kubernetes PaaS, its also an IaaS, which means you can spin your own VMs to use for varying workloads, along with other services it offers such as an authoritative DNS, Load Balancers, Firewalls, to name a few.

The UI of the platform is rather easy to navigate as well, all of the information laid out in a non-obtrusive and straightforward manner.

The Kubernetes Platform

Of course, we didn't come here to review the IaaS, we're here to test the waters of their Kubernetes platform. Being based on the K3s distribution, you may think your K8s knowledge would be the same for this? Not really. K3s removes most of the non-stable APIs, so that means if you use a non-stable API in your workload there's no way you can run K3s unless you have to relearn everything.

Now, you may also ask, what about Ingresses? Keeping in mind that K3s removes most of the non-v1 APIs, so does that mean we have to use services in LoadBalancer? Not precisely.

If you've done K3s before we all know that the Ingress class in K3s is provided by Traefik. And it resides in extensions/v1beta1, and to use the Ingress class, it works like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cattle-ingress
  namespace: cattle-system
  annotations:
    kubernetes.io/ingress.class: traefik
spec:
  rules:
  - host: suzuhara.kiana.cloud
    http:
       paths:
         - path: /
           backend:
             serviceName: cattle-service
             servicePort: http

It's not that much relearning, but if you use anymore than just the ingresses that is non-v1, then you're out of luck.

Now with the preliminary out of the way, the Kubernetes platform is neatly tucked in just second of the instances tab, and its very straightforward to use.

The cluster creation screen is also quite straightforward and simple, you can pick how many nodes you want plus the size of the instances. And what I found interesting is the marketplace section because you can install these addons for your cluster during build time, a welcome change since you want your cluster to be pre-done with all the bells and whistles you need.

I already made a cluster to shave off some time writing this article. I decided to install the Longhorn Storage Block addon, Metrics Server, Linkerd and Rancher (Rancher fully supports K3s since the start).

So, now that you caught a glimpse of the platform, you may ask what's good and what's bad in it?

The Pros

Of course because this is a K3s platform, you benefit on a platform that uses less resources than your traditional Kubernetes solution, making it a go-to if you want a lightweight solution. It's relatively simple as well, and you can even spin up Kubernetes clusters from Civo's CLI.

And as I mentioned before, unlike most Kube distributions, the addons are installed on build time, shaving off time from setting up your instances, this is a must if you want to just go around and start using the platform.

The Cons

Because this is a rather new platform, expect some bugs. I had a bug where the instance of a cluster I'm creating that had the same name as the one I've deleted would get stuck in finalizing the cluster. And the marketplace is rather limited, but it gets the job done.

As for the distro itself, of course, you will need to relearn some parts if you use beta/alpha resources, and ingresses are not on networking.k8s.io but on extensions/v1beta1 with the traefik class (if you have traefik installed).

Some addons require additional setup as well (such as Rancher, because the ingress for it is not exposed by default for security reasons), but that's understandable. There's no control plane within the cloud console itself so you have to rely on a external control plane for this (such as Rancher) - but that's a good thing, since it gives the users choice.

Another thing to note that Civo is UK-based so their datacenters are in Europe, so if you're aiming for cross-region, that's not possible at the moment.

Conclusion

K3s has seen a lot of limelight from people, especially from the Raspberry Pi community, and its amazing to see that K3s would get its own hosted solution so that means anyone can try out K3s in the safe confines of a hosted provider, and this would spark even more interest on using K3s on hosted platforms now that someone has done it.

As for Civo, their platform is stable and this hosted Kubernetes is certainly production ready. Though I may wonder when are they going to get Kubernetes-certified? Maybe in release? Time will tell.

Civo may be late to the Kubernetes race, but its the first to introduce a wanted change - a simple Kubernetes solution hosted in a public cloud.

If you decided to want to try it, the #Kube100 Beta program is open, and you can join here.

GitHub launched their own Web IDE - does that mean Atom is dead?

Ayane Satomi — Thu, 07 May 2020 10:45:22 +0000

GitHub just announced Codespaces, their own hosted Cloud IDE based on the venerable Visual Studio Code, and frankly is also their version of Visual Studio Codespaces. Codespaces is basically a one-click IDE that contains your dependencies and just gets you started.

But there's an issue, remember Atom? Yes, that was GitHub's baby and the reason why Electron existed, the reason why Visual Studio Code was possible. And they were competitors once. But with GitHub embracing Visual Studio Code instead, does that mean its putting its own editor in the past?

Let's go further back

Cloud IDEs were the hype for a while now, and of course a lot of IDEs cashed in, such as Gitpod, CodeAnywhere, AWS Cloud 9, to name a few. Of course, VSCode was the most flexible editor that existed, and no one in the market has ever reached the flexibility of Visual Studio Code until today.

But let's go to where Atom started. At that time it was GitHub's very own extensible editor, it had its own extension gallery based on npm, but it suffered on a lot of issues, most notably startup issues. At that time Visual Studio Code also came along, and they were fierce competitors.

In my perspective, every release of Atom added new features, but didn't bother to fix any of its issues that plagued its release. Visual Studio Code, however, had focused so much in listening to its community that it began to thrive and saw adoption, and of course, Visual Studio Code became the editor of choice of many, and Atom fell into obscurity, being only known as the project that started the Electron desktop shell.

Does it mean GitHub gave up on Atom?

Most probably. I haven't heard about Atom from GitHub for a while now, and it seems to have gone silent, and with Microsoft's acquisition, it became very clear Atom was not worth the investment to GitHub, in my perspective, it looks like Atom didn't have that much adoption, so it just went silent and pushed its own updates, but the rage is all about Visual Studio Code.

Now that Codespaces is out, and its very clear it used Visual Studio Code as its base, not Atom, and the reasoning is very simple and clear - more people use Visual Studio Code and expect this kind of flexibility if they ever want to use such a Cloud IDE. Atom, unfortunately, fell out of favor for that parameter.

The way I see it, is GitHub is offering familiarity, since people know more about VS Code than Atom, it makes sense to launch a product with a feature set that people are familiar with. Our intrepid editor however, was not even flexible or even ready to be packaged as a Cloud IDE.

Visual Studio Remote and Online - The Final Nail in the Coffin for Atom

So how did it really fell out of favor? Well, people are becoming interested in coding remotely, and Microsoft saw an opportunity, so it launched Visual Studio Remote, a set of extensions that allows you to run a minimal Visual Studio Server that interacts with your VS Code instance from the cloud. And it was good at it.

You can achieve the same from Atom, but not as an optimal experience from Visual Studio Code. And of course, as time progressed, VS Remote was a success that it was possible to launch Visual Studio Online, Microsoft's Cloud IDE based on Visual Studio Code and Visual Studio Remote. And Atom was never able to catch up with the trend.

The Future of Atom looks bleak in GitHub

The future of Atom in the new GitHub's stewardship looks very bleak, now that Codespaces is out, and it favor VS Code instead of their own homebrewn editor, it seems that GitHub no longer cares for Atom. It's more on the "grandfathered" stage. They simply don't care about the editor anymore, I've never seen any more blogs that point to Atom from GitHub, and its very likely, Atom is going to be shut down now that there's no point for them to maintain it.

But Atom is open source, so even if the developers gave up on it, someone out there can restart Atom, but as more and more editors pattern themselves to function similarly to VS Code, heck, even use a lot of standards VS Code uses to make up for what lacks from them, I don't think Atom would ever keep up.

But let's support GitHub's endeavors even if it means to kill one editor because no one is using it anymore - they are doing it for us after all, inasmuch we want them to maintain both, reality is harsh, and resources is finite. Atom will get to the chopping block inevitably so GitHub can focus on what matters most.

So KubeSail added BYOC in their platform...

Ayane Satomi — Thu, 07 May 2020 03:26:56 +0000

And I didn't expect it as well. Back then KubeSail was this little PaaS for people to play with Kubernetes, now its grown up, let's see what the new hosted and now, BYOC (Bring Your Own Cluster) service has to offer.

Why BYOC is a good thing

Well if you run your own nodes and wants a single pane of glass to use everything, this is certainly one of the ways to get your Kubernetes managed easily.

A lot of people (especially enterprises) use Kubernetes across multiple providers, and having a single admin dashboard helps a lot. There's alot of this kind of services, so this isn't so new, but for a Kubernetes PaaS that started out for people to play with Kubernetes to offer BYOC, now that's a surprise to be sure, but a welcome one.

Wait, what the heck is KubeSail?

As far as my memory goes when I found it last year, it was pitched more as a playground for Kubernetes, giving you access to one shared cluster with 1vCPU and 512MB memory to play with - and that's quite generous.

Wait... What does this platfrom had to do with BYOC even?

Good question. Because they seem to switched priorities, with that still the same free experiment cluster access (I haven't used it for a year, sorry KubeSail guys >_<).

And if you don't want to do BYOC, they have a very generous pricing, I recommend anyone to check it out.

Okay, fine, now how do I onboard my cluster to KubeSail then?

Well it seems to be easy, just go to the cluster page and click on "Add Cluster"

It should take you to this page, which includes a nifty kubectl apply -f command, and also includes a overview of the files that will be deployed to the cluster.

Now to show you that it works, I'm going to use IBM Cloud with a demo cluster as a sample:

The process is rather straightforward, and unlike most Kubernetes managers, KubeSail does not require an Ingress, which makes it compatible for k3s (though they probably don't support k3s that well).

And after a horrendously 30 long freaking minutes of provisioning, and blasting the national anthem of open source, here it is as it appears in the KubeSail dashboard.

It's still in Beta, Beware of Bugs!

Inasmuch BYOC is a good addition in KubeSail, keep in mind this is a rather new addition, and probably isn't production ready. But if you want to give this for a spin, head over to KubeSail and add your own!

And no, at the time of writing, it doesn't cost anything to do BYOC, so go add away!

WebAssembly and Node.js - No, they won't compete with each other, they'll coexist

Ayane Satomi — Wed, 06 May 2020 12:06:41 +0000

I'm sure you've heard all the hot stuff with WebAssembly. WebAssembly is so flexible that people start making standalone runtimes from the WASI standard. But let me tell you one thing, Node.js and WebAssembly is not slated to compete with each other, and never will.

A quick overview

If you give WebAssembly a look in W3C's site it seems very flexible and more powerful than JavaScript would ever be. It presents benefits such as:

More integer precision - We've been limited to 56-bit integers with JavaScript, and even if we have 64-bit precision, BigInt can't be used with normal arithmetic or math operations compared to contemporaries.
If it compiles in LLVM, it can compile to WebAssembly - One of the promising features of WebAssembly is anything that LLVM supports can be compiled to the Stack-based VM of WebAssembly's (in standard) bytecode. You get the benefit of using whatever language you want, and it'll work on the browser. Using OpenGL for this project? Don't worry, because WebGL is based on OpenGL ES 2.0/3.0, and it'll surely run!
More control on the memory - I'm pretty sure since we're dealing with a runtime that gives support to language that has inherent control on memory, it would give you manual memory management, right? Well, you're not wrong, because that's one of its main benefits. So you can optimize your memory usage.
And much much more - WebAssembly is now working on threading and SIMD, things in the runtime side that would WebAssembly much more capable. Can't wait? They're already in your browsers, just enable the feature flag.

Much more importantly, WebAssembly started out from asm.js which had similar aims, but suffered on some performance issues. It was intended to help developers to port existing applications to the web, and sure enough, it was good enough that games started to get ported in it.

Well what about Node.js

With this benefits, you may think Node.js will get superseded? And you may think this two worlds would clash despite sharing the ecosystem? No.

In fact, Node.js actually added support to WASI, which made WebAssembly application development possible even in the runtime, but even then, WebAssembly is not even slated to replace JavaScript, but to complement it.

If the two doesn't clash, then how would they help each other?

Good question! Node.js has been real finicky with Native Node modules, don't get me started on how many native modules has failed to compile on my environment despite having the adequate tools. And that's an area WebAssembly can help.

The main applications of using Native Node Modules is basically for modules that requires more precision, say like bcrypt, or WebP image conversion. You think they'll need something like C++ to work? Then you're not wrong, but instead of targeting native modules, why not try targeting WASI? Sounds impractical you may say, but the future isn't so far off, because someone did it already and its amazing. We leave the work that requires more precision to WebAssembly, and the JavaScript side would just output it - and you won't need to compile the module, because its done at the publishing side.

This opens for a lot of possibilities, and I think we should adapt this kind of approach.

WebAssembly on the NPM ecosystem - a world without Native Node Modules

Okay hear me out, I know WebAssembly is quite in its early days, but WebAssembly has been doing some major strides when it comes to improving its runtime capabilities that we may not even need native node modules at all.

We leave the compilation problems from the package user and instead let them focus on what matters most, building the next hit application.

Instead the compilation is done from the publisher's side. And it reduces the friction for modules that requires such native capabilities, without needing to rely on the package user's environment to compile it for their Node.js runtime.

Maybe I'm day-dreaming but the future is so bright for such a complementary runtime for JavaScript that I kept wondering - When's WebAssembly 2.0 coming out!?

Raison D'etere

Of course the most important reason of why WebAssembly exists is opening a future of a much more powerful and feature-rich modern web. Soon, services by services that would otherwise require a serverside equivalent would be moved over to WebAssembly, and it would complement on current trends like Serverless. It's a future we should openly embrace, and a future that sounds too good to be true, but it's just around the corner.

WebAssembly may not be the runtime we asked for but its the one Node.js deserved, and probably the one we desperately needed.

Don't Make NPM Packages Unless You Need To

Ayane Satomi — Tue, 05 May 2020 01:26:28 +0000

We reached the 1 million packages mark in NPM - the de facto package manager in Node.js. And trust me about 30% or so of those are doing the same thing. So the question now stands - when is enough, enough?

Going back

Back in its early days, Node.js was rather a simple runtime that was limited by the lack of libraries, as time went on however, more and more people went on to make tools, libraries and even Cloud IDEs. Node.js started a revolution where JavaScript was no longer confined in the browser, and it was good at it.

But as time went on, Node.js became more robust and it started to be ahead of the curve of the browsers - it was the new JavaScript ecosystem, where its not constrained of the vendor's lackluster ECMAScript support. And some of the ancient libraries became more obsolete as time goes on.

But what does this have to do with NPM packages?

The thing is, during those early days, also came with package pollution (and its still an issue today) where there's more useless packages than something that has purpose. Some of them even reinventing the wheel only to be abandoned for almost 6 years in some packages.

In this example, we have different packages for Redis, which hasn't been maintained for quite a while now (however its still understandable for grunt packages to be unmaintained since they've been superseded already), and most of them is something you can do in a app-level implementation, which you clearly don't need a package is for.

So stop reinventing the wheel - unless you need to

Let's say you invented a logger, cool! You want people to use it, even cooler! But let me remind you there's always tons of libraries that does the same thing, so if your logger is domain-specific, don't even try making it a NPM package and just keep it inside the project you intend to use it.

There are only instances of when you need to really invent the wheel for everyone's benefit - because the current public library was underperforming or just plain bad.

Let's take a little practical example, two SauceNAO API wrappers, I'll let you be the judge.

(Spoiler: Exhibit B is objectively biased as it is my own project - but you can see the point I was trying to get across).

And stop making packages with no useful purpose at all

Seriously, stop. You're ruining the point of a package repository, which is a repository for reusable modules to be used by a project. I don't care if its a joke package, you're wasting object storage where it could've been taken by a more useful module.

We have sane package repositories like Maven and PackageCloud, so why can't we have the same professionalism and sanity as they do? We're not so different from them at all.

Conclusion

NPM and the JavaScript community is the driving force of what we are now calling the "modern web". But if we keep doing useless stuff and keep misunderstanding the concept of having package managers in a runtime, then we can become an example of what a package manager shouldn't be.

So let's try to change the mindset with library authoring - only make something when there's no other way or when the current implementation is very underwhelming for a vast demographic. If you're making something for a domain-specific project, just don't bother at all.

DEV Community: Ayane Satomi

Writing UI in .NET sucks

The UI tooling is bad... very bad

And we didn't have proper UIs for embedding them inside applications too!

Our attitude with UI development needs to change

Mapping out Gacha Pull Probabilities using Python and Google Colaboratory

Background

Starting out

The implementation

sr229 / gacha-prng

A Jupyter Notebook that maps the probability distribution of the Arknights RNG for Gacha rolls.

gacha-prng

Running

Copyright

The results

Fixed UID as seeds

Time as seed

Conclusion

Credits

From Express to Serverless: How we wrote a legacy Express Server to a Serverless API with the help of Next.js

The Beginning

Why Serverless?

The journey

Key Takeaways

What's next

nimiiiii / nimi-api

The unofficial API for Azur Lane

Nimi

Compared to previous version

What's next?

Conclusion

When do you actually use Cloud IDEs?

What made Cloud IDEs successful?

But it can't replace localhost, and never will.

But they do have a place and purpose

Conclusion

My (infuriating) experience with GitHub Codespaces

Let's wind back a little

What I enjoyed so far

GitHub launched their own Web IDE - does that mean Atom is dead?

Ayane Satomi ・ May 7 '20

Now sh*t gets ugly

Conclusion

Isolate Your Games, Seriously

CPU Rings - understanding the concept of privilege escalation

Ring 0 Anti-cheat - is it safe?

But Anti-cheat is a proper backdoor

Should I give my games native access?

Playing the Game without worrying about Privacy

Conclusion

How to use NGINX ingress controller in K3s

Getting your cluster ready

Installing NGINX

Using a Helm chart

Using the regular kubectl

Verify if it works

How does it compare to Traefik?

Conclusion

My Experience with Civo Cloud - The first-ever K3s platform

First impressions

The Kubernetes Platform

The Pros

The Cons

Conclusion

GitHub launched their own Web IDE - does that mean Atom is dead?

Let's go further back

Does it mean GitHub gave up on Atom?

Visual Studio Remote and Online - The Final Nail in the Coffin for Atom

The Future of Atom looks bleak in GitHub

So KubeSail added BYOC in their platform...

Why BYOC is a good thing

Wait, what the heck is KubeSail?

Okay, fine, now how do I onboard my cluster to KubeSail then?

It's still in Beta, Beware of Bugs!

WebAssembly and Node.js - No, they won't compete with each other, they'll coexist

A quick overview

Well what about Node.js

If the two doesn't clash, then how would they help each other?

WebAssembly on the NPM ecosystem - a world without Native Node Modules

Raison D'etere

Using the regular `kubectl`