HN user

gindely

114 karma
Posts0
Comments101
View on HN
No posts found.

> Imagine being able to unzip a build of your software to a blank windows/linux server and expect that it work flawlessly 100% of the time, regardless of any prior/lack of configuration or other supporting dependencies on that machine

I mean, that's basically _why_ Docker exists.

It is, but Docker isn't it. At the least, Docker won't run side-by-side with Virtual Box on Windows, so "regardless of prior configuration" is not met. In general, Docker adds an extra dependency on top of a blank system: Now you need to get Docker set up and running first, and then you can deploy your app. The alternative in question is about controlling the build to such an extent that you can reliably deploy the artefacts onto any system without having some runtime environment prepared.

One big argument for Docker is no dependencies, but Go and C# already can create fat native binaries that have no dependency on anything else (no .net framework or even VM, all native, same thing in Go). I believe Rust too offers the same thing. There is no excuse with all those different languages all supporting that.

Using Nix, you can build a self-contained deployment for just about any language/rutime you can imagine, and the target machine doesn't need to run Nix.

Well, the conveniently indicated grams on the packet are not units of weight - they're units of volume. So you've got two kinds of units of volume in your recipes: milli/centi/decilitres, and grams of butter. But it's fairer than the grams of flour I've been ranting about elsewhere here because at least the manufacturer can have some responsibility for fine tuning it to their product!

Well, tell that to Europeans, who don't use millilitres to measure their flour or sugar by volume - they use bizarre units of volume called "grams of flour" or "grams of sugar". Check their cup measures! It's crazy.

Apparently it works perfectly fine for household cooking to use units of volume for flour and sugar. Close enough is good enough!

Australians, Indonesians, Germans all measure recipes with two kinds of spoons (!). Australians also use cups (that are 10-12 mL bigger than American ones); other countries may too.

I wonder if the ideal country where no-one uses units of volume other than litres and millilitres actually exists.

The really bizarre units of volume are certainly the ones I've seen in Europe - where you get measures marked in "grams of flour" and "grams of sugar". I suppose no-one has ever asked for a hundred grams of sugar of flour, but I'm tempted to every time I see one of them.

Oh, another of Apple's hidden features. Once upon a time, one button mice were a feature so that features weren't hidden and even beginner users could quickly become power users.

In the days when computers were places you stored your data, ROX was great. It was the first GUI that made me manage my files using a mouse. Nowadays, computers are mostly glorified web browser containers. And the way Gnome is so integrated into itself now means you can kinda either use a good window/session manager and Nautilus (with a good file manager on the side), or a crappy window manager, no session manager, and a good filemanager.

(In the olden days I had Sawfish set up so that it had a button that would take a look at the path it displayed or interact with the app via whatever scripting it provided, and show the active document in the ROX. Ah, so great. Sawfish is, nowadays, too primitive for me - I want an expose style feature to find my window.)

I still like to switch to ROX to rename or move files in my codebase rather than do it in IntelliJ. I had a plugin for that for a while but I never quite got around to setting it up again on some migration or upgrade or something. Nowadays it's only VIM/gVim that responds to F12 and shows the document location.

I have given some thought to porting it to Gtk3 and Gtk4. I guess getting an infrastructure around it isn't going to happen - but the Filer was the centre.

Well for many programs there isn't really any separate designer, particularly for line of business apps. That was really where I was coming from - the person who designs the app is simply someone who was trained in coding.

In any case, as I said, you get a problem if the person who designs the app is simply someone who was trained in coding, and you get a problem if they're simply someone who was trained in art.

Yep okay, so I guess that's not inline by my definition (since it overlays the text). I have definitely seen webpages that change the size of the containing box to add in the confirmation message and buttons.

I guess it's an between case I didn't consider - it's maybe not modal with respect to the whole app, but it seems to be modal with respect to that one comment (you can ignore it and do something else with the rest of the program, but with that comment, you can't even read it).

You're radically misunderstanding that definition.

It has to do with the notions that are expressed by "can, should, might, must, has to" etc. These words (most of them are called "modal verbs" in English) modify a proposition in such a way that they do not mean it happened/happens/whatever, but qualify it, or indicate its possibility etc. So "he's going out now" is a proposition. "He can go out now" modifies that proposition - no longer are we affirming it, but merely affirming the possibility or permissability of it.

Nothing about "are you sure" is modal. A modal dialog is called modal because the mode of the program has changed - no longer can it accept requests to delete articles or add text or modify an avatar, but it is now in a mode when you can either say "delete this" or "don't delete this".

In particular, if you showed an inline prompt that says "are you sure? delete/cancel" but still allows you to interact with the rest of the system, it's not modal.

Yes but have you seen software - almost anything that's been developed since the growth of mobile platforms has basically done the exact opposite of what that field of science teaches.

This seems to confirm the op's point.

Come on, we're all adults here. We can take a few 90 degree angles.

I know that 90 degree angles on webpages are not more dangerous for children, parents, adults, or any other known subcategory of humans than for any other known subcategory of humans, but ... lots of people who use webpages and dev tools are actually children.

Didn't a lot of us get started as kids?

Have we collectively forgotten the olden days, when to print something, the solution was to ask the neighbor's next door kid? (who was probably you). Printers aren't any easier to use today than they were back then, but I guess that practice is over nowadays.

Yeah I think nowadays a lot of people think "modal" means "a dom element positioned with respect to the viewport that prevents interaction with the rest of the webpage".

The classical sense of "a collection of related controls that prevents interaction with the rest of the application (however the collection, controls and application are implemented)" is surprisingly rare now, particularly since the older sense were often called "dialogs" (and indeed, "modal" was short for "modal dialog") - intended to emphasise that this was communication between the user of the application and the developer of the application to decide how the application should behave.

Therefore, a modal dialog should be used when the communcation couldn't have happened before and cannot happen later, and the developer of the application cannot do something intelligent and allow the user to correct it later on. (For instance, just delete the thing and let them undo it - no interaction between the developer and the user actually needs to transpire.)

That isn't actually true. I think I have UI experience, but I would actually have preferred some mockup examples instead of 1 bit bmp pseudo-thumbnails to represent his ideas. Surely it would be better to show some good user interfaces.

Since you deny a weird context switch for your eyes, are these actually inline elements? That would imply the size of the containers is changing. Which would surely be a weird context switch. But at least I can have no doubt what my action is about to affect - I get frustrated on sites when it says "you're about to delete these items" and i have no idea whether it agrees with me about which items I'm about to delete or not.

But if they're overlaid elements, like a context sensitive menu that contains two options - delete, cancel - is there any substantive difference between a menu and a modal? The main advantage of a classic menu over a modal seems to be that it has a implicit cancel option that is uniformally implemented. But nowadays, menus are implemented without toolkit support - yay dom, yay - so even that is not consistent.

Well yeah, but if the person who is in charge of the modal is the implementer, not the designer, then they may not have the expertise to design a good ui.

And many designers are artists ("designers") not ux engineers, so their main goal is to make something that shows their artistic skill - they're going to be trained in design packages, not designing a good ui.

(I mean, when was the last time you saw a clickable button on a modern user interface? nowadays it's just "guess what this shade of grey means")

I also didn't use RISC OS - I came close in school, but the ancient machines always got replaced the year before me.

However, I have use ROX for a long time - called RISC OS on X - it is/was basically a file manager based around RISC OS, as well as some associated desktop technologies (like app directories). I think it's fair to describe it as a dead as a doornail (I just upgraded to Ubuntu 20.04, and since it no longer comes with pygtk2, various tools are dead). Some of its innovations found their way into other Linux desktop technologies, such as shared-mime-info.

But if you want to see what once was, it's a place to begin.

(ROX was actually a lot nicer than RISC OS, when I finally installed it on my RPi.)

What's the advantage of this? Surely they're better off pricing it at 2x the expected ad revenue, since then they can expect to get twice as much now as they otherwise would get eventually? Indeed, even if it were 1.01x the expected ad revenue they've won with this upsell.

Vulnerabilities are a massive trade off. I want my devices to be open to me, not to anyone. Seems like it should be straight forward to give you access to the device (like "scan this qrcode on the inside of this panel" and you get the private key). One can dream...

Hm, as a vi user i have escape there. so if i want to delete something without stretching too much, it's left thumb stretch back one left index stretch down out one (i'm on dvorak too). But since i'm also a kinesis user, i have backspace under my (right) thumb.

I switched to Dvorak before I started uni. I have been typing dvorak the majority of my typing.

Still discovered the hard way that I needed an ergonomic keyboard. I use a kinesis advantage, but frankly a Microsoft one will do. It just needs to be enough.

Also major factor: Switching away from a mouse. Every time I've done full time work at a computer (i.e. when I'm not studying), I got wrist pain.

Switching to a touchpad is tiring for the fingertip, since it's not designed to drag on a surface all day.

But switching to a trackball has been a fantastic choice (six or seven years ago by now - some kind of red Kensington ball). I think there's so much more choice in using a trackball than a mouse or a touchpad, since it can be operated with the fingertip or the hand, and it's trivial to operate it without bending the wrist badly.

I got the ergonomic keyboard before the trackball; but the trackball made an almost instantaneous difference, whereas the keyboard only makes a cumulative difference - nowadays I can use a straight keyboard temporarily (e.g. if I want to go somewhere and use a laptop, I can, even for weeks at a time) but I wouldn't want it fulltime.