Seriously, give it a go and you'd probably have the same experience!
290 karma · joined September 18, 2017
Seriously, give it a go and you'd probably have the same experience!
Arduino did a lot to reduce barrier to entry to the uC world - but even that requires you to understand a little of how C++ works once you move beyond blinky.
These (micropython, this project, Lua ) etc lower the barrier to entry even further. The trade off of course is how well they run and how much of the hardware is exposed (register manipulation etc) if you want to get to it...
I saw a few demos d went through their sdk samples a year and a half ago but those were pretty raw then
Another interesting fact, some of the ejecta from that impact went as far as the moon!
https://www.preposterousuniverse.com/podcast/2020/08/03/108-...
I'm shifting uncomfortably in my chair just reading that
I mostly work on the backend.. However, I've done a decent amount of JS too. In fact, back in 2015, even built a lot of the core parts of an SPA using a mix of knockout & requirejs with minified bundles and dynamic loading and so on. Given that it stuff put together from scratch, I though picking things up after a couple of years away from js would be easy. Oh how wrong I was...
In 2017/18 sought to write a starter boilerplate with vue 2, Typescript and .NET Core. I would have probably spent an order of magnitude effort more fixing build issues and warnings than on the project. Once you hit bugs/issues with 3rd party webpack modules (which is almost a given), it is not fun at all.
I recently had to put up a one page visualization and was not looking forward to it. Surprisingly, create-react-app just worked out of the box. Not much of a data point - but still a pleasant experience.
I've almost exclusively worked on the usual procedural /OO languages professionally (java /c#)..I like to experiment and I've picked up a bunch of languages along the way (perl, python, coffeescript, f#, nim etc).. And its usually because I want to see what's different and spend enough time to do something useful (but not large) with it. Also, it helps you become a better programmer IMO. otoh, if I'm hired for my skills but then have to work on js( don't actually like the js eco system) or haskell (I gave up after trying and I doubt I'd become very good at it anytime soon if I were forced into it) I'd be not happy either (and IMO, with valid cause that doesn't reflect on me or my abilities)
Gitlab pages with custom domain. Ssl from lets encrypt. Domain managed by cloudflare.
Static site with Hugo and I use asciidoctor for authoring entries
Let's encrypt cert renewal is via a cron job running on rpi in my home network
https://github.com/asciidoctor/asciidoctor-vscode/blob/maste...
I'm with you on the feeling that modern stack is bloated and heavy... However, this is exactly the scenario where the compiler bug is isolated quickly because you're not chasing dependency differences between boxes
Something from dev.visualweboptimizer.com! Had to make an exception
This is the hardest part.. I'd argue that this is almost impossible to do correctly without significant domain modeling experience.. also microservices by nature make this hard to refactor these boundaries (compared to monoliths where you'd get compile time feedback)
I prefer to make a structured monolith first (basically multiple services with isolated data that are squished together into a single deployable) and pull them out only if I really need to... Also helps with keeping ms sprawl under control
Since the current govt has come in, pseudo science has flourished and been tacitly encouraged and scientific temper in general has been thrown out of the window. All this to prop up ultra-nationalistic narratives..
A sampling: 1. https://www.bbc.com/news/world-asia-india-46778879
2. https://www.ndtv.com/india-news/on-economy-piyush-goyal-says...
There's many more... it's depressing.
Also, infra like email service, payments etc can probably fit into a 2 week rewrite.. but core domain is usually more complicated (since it's less well understood)
I've generally had more success with few, chunky services... The few times I've worked with teams that had a large number of small services, it never ended well (in one case, a 40 member Dev team - groups of 8... Ended up with each team maintaining about 3- 5 services)..
To me, micro services is more about scaling teams... Other than that, They seem to cause more tech problems than they solve.
Otoh, what do I know... There was some Uber talk where they had thousands of services...