mdtusz

I've found Microsoft documentation (Azure services specifically) to be a weird mix of marketing and semi-technical walkthroughs that seem targeted to point-and-click users following their happy path. As soon as you get to the technical reference (if you can find it) it seems to all be auto-generated and fairly poor quality, or handwritten and either out of date or just not very clear.

The more "core" Azure services are a bit better, but it seems to always be a struggle and searching for answers is always difficult because you have to scroll through a full page or more of Microsoft marketing pages before you reach either Reddit or stack exchange results with the answers you're looking for.

Weird example: recently I discovered Azure redis instances will drop idle connections after 10 minutes, but the network connection still stays open and your commands/queries will fail.

I'll echo the sentiment that helix is great, but I still think the default behaviour of selecting words as you navigate with w,e,b to be strange and a bit counterproductive in most text editing (at least for me).

There's a few other small things missing still - specifically marks and a git gutter - but once those are improved upon it very likely will become my daily editor!

I've gotten into the habit of adding comments for what the code _should_ do in high level terms, as abstracted from the implementation as makes sense, so that the implementation can change to fit whatever may be needed by a neighbouring piece of code. When reading through, I'm more often that not concerned with what the code is trying to do than how it does it, and having the former makes understanding the latter much more clear. Technical prose that describes functions, arguments, and return values rather than variables and the operations done with them is best IMO.

I'm a bit surprised and amused by the comments here. It seems like suddenly everyone is an expert in industrial design, mechanical engineering, and product development while simultaneously missing the entire point of the product and being unable to see past the LTT brand.

I for one applaud them for pushing through to release this, and while I probably won't buy one, they certainly look well made and thought through. Obviously a ratcheting multi-bit driver won't be as robust as your Klein Phillips driver that you use while working on transformers in your day job, but that's not what it's intended for - it's for the average person who needs a handy screwdriver to keep in their car or kitchen junk drawer to pull out quickly when you need to twist some screws.

Something I've noticed in this space is that there exist "standards" which are intended to make systems compatible and useful and modern, but all of these standards are extremely poorly written and cling to outdated paradigms and weird non-standard protocols that aren't used anywhere except small subsets of the manufacturing world. Often you'll have to implement interfaces yourself because there's only one reference C library available that hasn't had any maintenance for years and won't even compile.

At risk of someone posting the xkcd on standards, I would love to see an full industry wide consortium to establish _modern and well designed_ standards, led by people with experience making modern networked services and systems. Specifically around industrial machine controls and data/telemetry collection. A few standards exist that are roughly xml-rpc-ish, but they don't even follow that much as a standard. OPC-UA is the latest "standard" to be making the rounds and is (IMO) doomed to fail due to its layers of complexity and unclear specifications.

It makes a big difference. Imagine watering your favourite plant once per month with 4 litres of water, vs watering weekly with 1 litre of water. The snowpack melt cycle allows for gradual watering of the surrounding areas. Not directly answering the question for reservoirs, but the rapid loss of snowpack and glaciers has a massive impact on the environment.

I've always just dreamed of an entirely accessibility focused API that doesn't rely on the DOM and html elements. Most accessibility concerns are for visual impairment, so why do we still base it on what in practice is a visual model?

Do screen readers use a different user agent? Seems like a11y would be simpler in many cases by just delivering a text based result that's tailored to screen readers. Most of the issues seem to arise from the structure chosen in order to style things rather than the content itself.

Let's not make ham radio operation out to be some complex Voodoo that requires months of training. You tune your radio to a given frequency and press the ptt button.

Yes sure, there's repeaters, and other details to know about, but tx/rx on a single frequency isn't exactly the rocket science that sad hams make it out to be.

I'd also argue that adding MFA with TOTP really isn't _that_ hard either. There's a bit of setup work to be sure, but it's a feature just like any other that has a pretty easy to grasp flow once you do a bit of reading.

Don't do your own cryptography (just use bcrypt or if you're confident you won't mess it up, libsodium), but authN/Z is entirely within the realm of "roll-your-own" and should be table stakes for most businesses these days.

Even adding SAML or OIDC support really isn't that hard.

I think it's a silent market at this point. The company I'm at is using it, and anecdotally, many other companies are as well in small greenfield projects, so I anticipate there will be growing demand for developers that know rust in coming years. The downside of this is that there will be a massive influx of people learning rust, similar to "the python problem". At the moment, most people that know rust are for the most part competent with it, but I fear that may change as the supply side increases.

This is true in a local context, but entirely breaks down when a codebase becomes larger than a single person can fit into their brain-RAM. Not arguing or saying you're wrong - just presenting the very quickly reached boundary where the argument breaks down.

While balena is great for getting up and running quick, you'll quickly run into issues when more specific application requirements arise, or you need to tighten down security.

It's fantastic for small-scale IoT deployments, but you very much need to play nice in their ecosystem, and there's many features missing for deployment and version management still, and balenaOS and the balena supervisor can often introduce breaking quirks, and managing networking is a nightmare. We're very happy with how it allowed us to get off the ground and running quickly, but are moving to a more "traditional" build using yocto on its own moving forwards.

Next time you need to map out roads like that, try Caltopo. For any _map_ use cases, things like Caltopo and Gaia are miles better. Google Maps is great for following directions they give you, or finding businesses and well known places, but it's a horrible map in any other context.

AON3D - YC W17 (https://www.aon3d.com) | Software and Design | Full-time | Montreal or Remote NA

At AON3D, we make industrial 3D Printers that work with high grade engineering polymers, and are working hard to solve the problems that still exist in the additive manufacturing world beyond just making better hardware - there's still plenty of room for innovation and growth on the software side, and the surface has barely been scratched!

We're hiring for our newest team to build a software platform which innovative tools and functionalities will be built upon, so we're looking for people that can really take ownership of projects and help grow the team over time.

Current positions we're looking to fill:

* Senior Frontend Engineer - https://jobs.lever.co/aon3d/b2d68e5e-509f-4619-8886-d5a6a540...

* Senior UI/UX Product Designer - https://jobs.lever.co/aon3d/5c52bb46-63ea-47f0-98db-03fcf713...

Feel free to apply via the lever links, or email me directly at <my_first_name>@aon3d.com.

- Miklos

It's an extremely common and useful way to use git if you are making small and directed commits. This allows you to write code for some feature which includes multiple changes to a file, then make a few different commits with useful commit messages which describe and explain the changes - e.g. the first to include the definition of a new function and why/how it works, a second to modify some constant variable, and a final one to add calls to your new function at some callsite.

Working in this way creates more commits, but with them comes the context of the change, written in the commit message body as prose. This sadly isn't a common way to use git at lots of companies unfortunately, but it unlocks a ton of gits power and makes the commit log and tools like `git blame` and `git bisect` actually useful.

If you're making single commits that affect lots of files and descriptions like "Updated foo.py", you're missing out on a lot of the benefits that git provides.

Language is only one of the issues. The Quebecois see themselves as fundamentally different and _not Canadian_ - they don't celebrate Canada Day for instance (at least not in a significant capacity).

Even if the RoC made French a mandatory part of their education systems, Quebec would remain "different" and generally bitter towards the rest of the country (and vice versa). It has an entirely different culture from the rest of the country and will always have a chip on its shoulder unless French language (specifically _Quebecois French) and culture spread throughout the rest of the country, which will obviously never happen. While it's a difficult problem to solve, I don't think that the forced language laws are the right approach - they just create more discontentment and resentment.

Ideally, they would apply these rulings to the province as they see fit, but leave Montreal as an independent district of sorts which operates more similarly to the rest of Canada. This has been proposed many times, but unfortunately never happened.

I'm curious where 128bit floats become a significant concern? My understanding is that any critical numerical things would be done using integer arithmetic to eliminate any imprecision errors, and anything else likely is fine using doubles.

As a counter argument, it's much easier for a developer to write code that does the right thing when that code is readable.

Too often I see code that is _maybe_ correct, but the reviewer can't actually be sure of it without manually testing it, and the chances that a future reader in 4 months will have any idea what it does or why are extremely low. Good variable and function names get you 90% of the way there yet for some reason cryptic code is still all too common in the world.

To me, reviewing for readability isn't nitpicking - it's equivalent to a mechanical engineering design review pointing out that design for maintenance or design for assembly has been entirely ignored.

This may seem somewhat silly to most people but if it isn't vaporware and can actually meet demand and fulfill procurement needs, could be a solid choice. Choosing and sourcing SBC's for hardware is an absolute nightmare these days because of the thousands of options, horrible supply chains, and essentially nonexistent documentation or BSP's for the vast majority of them.

Raspberry Pi's are undeniably the easiest SBC to work with, and for a huge portion of industrial, defense, and aerospace products and devices are a near ideal choice except for their "hobbyist" level attributes.

A robust Pi4 clone that supports nvme drives, has no Bluetooth or Wifi by default, and has something like ISO9001 certification to check the boxes for big enterprise contracts would sell like hotcakes. It's somewhat surprising to me that the Pi foundation hasn't made something to this tune yet (the Pi CM4 may as well be vaporware - they're basically impossible to find anywhere even in single-digit quantities).

This is still visible on a fair bit of beer - Sleemans sticks out in memory the most as always having wear rings on their clear bottles.

What are the steps to agile?

If you read the agile manifesto, there are no specifically prescribed steps or rituals, and in my experience, most teams implementation of scrum is entirely counterproductive to actually being agile. The core tenet of being agile is essentially people over process, and things like daily stand-ups, extremely formulaic retrospectives and backlog grooming meetings do nothing to empower the people and allow them to be truly agile.

Reading code in one language in one codebase often doesn't even necessarily transfer to other codebases in the same language.

I find this particularly true in academic python codebases and C++ for some reason where single letter variables and cryptic contractions in identifiers is the norm. It's truly a shame that overly verbose java-isms spawned widespread disdain for descriptive variable names - I think one of the easiest low-hanging-fruit to most codebases is just using proper descriptive names for variables and functions, and other updating them accordingly when their meaning or purpose changes.

I completely agree!

What I intended with my comment was to point out that the idea of new frameworks being created every week is a bit of an exaggeration and that it being the reason frontend development is fragmented is just totally incorrect.

React or Vue on their own with a sprinkling of helpful utility libraries will get most projects 99% of the way there though, and often times that _is_ simpler than trying to put together your own system for server side rendered pages and template composition.

Of course, if you're making a blog, you don't need any of this, but for _web applications_, I don't think I'd reach for SSR anymore.

I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times just curiosity).

Considering you have so few language options for frontend webapp development (excluding wasm and other such options), this really isn't a surprise to have a handful of options either. I can name more python server frameworks that are used in earnest than I can name frontend frameworks.

Part of the difference for frontend frameworks is that there's so much variety possible. Nearly every server framework has the same general design and API - some kind of routing, route handler definitions, and some additional niceties like with, db connection handling, sessions etc. I can't conceive of any other design that would work better or even be sensible.

While components have become the norm in front-end, there's still plenty of room for different architecture and actual API to use and define components, and manage state. That's where the fun of writing them comes in, and where there is still likely a better react or vue lurking in the shadows or yet to be created.

The quick and dirty solution to this is to have a client response handler that checks for a header set on responses to ensure its a compatible version, then prompt a page refresh if not.

I think we're well past the period of a new framework every week - at least in a "real world" sense. Nearly all companies will settle on react or vue these days with a long tail choosing others, but this is no different than any other part of software development - lots of different databases, web frameworks, auth libraries etc all exist as well and are used.

Most of these "new" frameworks are more because someone wanted to scratch an itch or solve a specific problem they had, and frontend code simply lends itself well to being open sourced. If you don't like the new js tools that are made, just ignore them.

This is a fairly significant issue for mysql, but does the same issue exist when using postgres with a UUID pk type?

At my last job, this was managed by using two ID's on each row - a serial one that was basically only used for database optimization purposes, and the "real" UUIDv4 ID. It felt gross then, and it feels gross now, but it seemed to do the trick for our needs.

What do you think enabled these things?

This is extremely difficult to convey to non-developers though because they often look at software as a house and think "there's tons of houses (ecommerce sites) built every day and it's down to a science - how hard can a house (ecommerce site) really be", but miss out on the fact that all houses have pretty much the same structure of a foundation, framing, wiring and plumbing, and a covering of paint and a roof - this is largely kept consistent and we'll implemented by building codes.

I can only speak from my own experience, but every single web application I've worked on has had a wildly different structure than the others and the only consistent thing between them has been endpoint routing mechanisms.

Another benefit (imo one of the biggest ones) is not having to constantly create releases across all your repos and manage their states when jumping around during development.

My previous job used a collection of about 6 repos for different services and such, and it was a constant struggle to ensure the correct versions were used in development - especially if you were working on a bigger feature that wasn't yet released but required "future" versions from other repositories.