zaSmilingIdiot

I'd be interested in purchasing a copy when its done.

Weirdly, just a couple of hours ago I was trying to find this as an alternative "recommendation" for a buddy whom is digging around in this space. Couldnt remember the name of it, except that I had used it a while back for some simple lottie related work (and a couple of other simple tasks)... After trying various iterations of search terms that included the word "lottie" (and spending much longer searching than what I expected to) I eventually clicked through some link and landed on the Synfig site. And now, coincidently, this post shows up :)

Nonetheless... I have no idea of how this really compares to other tools, but when I have had a need, Synfig was a breeze to use for what I needed it for. Importantly, it was quick to get started with, and without needing to spend hours in tutorials trying to figure out how to do things. So happy user and all that :)

While I can agree that starting as a new hire can be daunting, there should not (theoretically) be a case where a single colleague stonewalling a new hire is a problem. At least in an org set up correctly for remote work. Smaller teams (or those with a single decision maker) are more susceptible to failing this, but thats a management problem that needs to br highlighted and addressed. And requires management to be actual people and process managers, and not psuedo manage by following some random guides and ticking off items on a checklist and "managing" by graph/stat outputs and only attempting to make some dashboard green, lines moving in the direction etc.

As for allowance of some slack, yeah, theres possibility for that to happen. But management doesnt need to be intrusive: what does anyone care if some employee is working a 2nd job for example? Does anyone care how their colleagues or staff spend their time away from work as it is? As long as their work is done within acceptable timeframes (or there is reasonable limiting factors preventing it) , its of sufficient quality to meet expectations, and they meet expectations of availability, what they do in their spare time is none of anyones business. In other words, so long as someone is not breaking company requirements/policy (which would include working on competing products, etc), whether they hack away on side projects, volunteer their time somewhere, work a 2nd job, do nothing... it doesn't particularly matter. Management only needs to measure performance relative to the org's expectations of performance for that position, and timeously address any concerns if need be. Theres no need for the org to reach beyond whatever is agreed to for that role.

Not to take anything away from the launch of this offering, but I tend to find that project management for freelance work and any self managed project (whether as a solo dev or within a small group) that is intended to generate income requires a little more than just managing tasks/activities. Managing costs, availability, etc tend to be important as well.

For freelance and small contracting work, and then lately for my own side projects and such, I've been running a self hosted instance of OpenProject. It has 2 features that I find are extremely valuable: 1. resource and materials costs 2. Gantt charts

Having costing available is extremely useful for paid gigs: not only for budgeting purposes, but also indirectly in keeping scope creep to a minimum (or alternatively, being able to indicate how much the additional effort is actually going to cost based on task estimates, and having informed conversations with the client if needed).

And gantt charts seem to not be used as much these days, but its really helpful in getting a quick overview of how changes to a projects tasks (new tasks added, delays, resource planning constraints, etc) affect the project timeline.

For the most part, I tend to find that increasingly, "project management" tools are more actually "task management" tools. Which have their uses. But for project management, there's more to a project than just its tasks.

NZ is a member of 5 eyes IIRC, and so likely have various relations/cooperative agreements in place that make it easy(-ier) for justifying the handing of citizens over to another state.

For personal use, and on the topic of Obsidian, I rolled my own form of this... Its quick and dirty, but generally works for my usecase. I tend to push a page through turndown [0] to generate the markdown, then write this into obsidian (also storing things link a copy of the rendered page, link to the source, etc).

[0] https://github.com/mixmark-io/turndown

I agree with this. But dont just use `npm ci`on prod builds since that would typically include all the dev dependencies as well in your production builds, which is not usually desirable. It might be possible to add the `--only=production` flag to npm ci? But otherwise, as pointed out, pinned versions are needed for all dependencies.

Is Flutter as ubiquitous as html/css/js? Is it similarly cross platform?

I responded to the suggestion that every company was choosing electron (html/css/js) because it was the best and easiest, by pointing out that the reason it might be picked may not have anything to do with simplicity or being the best choice, but rather based on other factors (like financial motivations). Flutter is a different toolkit, and isnt the typical "web page" type building of application UI, and so was outside of the scope of my original response.

I've never used Titanium, but have used similar types of toolkits... all of them, regardless of whether they compile to native apps or not, are (very broadly) generally selected based on the criteria mentioned in my previous comment: why build out different platform native apps when you can largely get by with a web dev(s) building a single app that compiles to the native system? Theres tradeoffs involved, and the typical optimisation in an org is to favour lower cost and/or quicker market time. Theres the "we can do it better later when we have the money to" mentality, except once a system gains enough traction, that perspective changes to "why spend time and budget on changing something thats working". The term "working" though, is subjective... its "working" for the org, but is it truly "working" for the user that is interacting with it?

> There's a reason every single company wants to just build web apps and electron apps, because it's actually the best and simplest platform for delivering a cross platform UI [...]

Maybe, but consider that possibly the reason why many companies go that route is more to do with financial incentives: it provides for the cheapest option (both in terms of resource costs and time), while still retaining complete control over the use of the software (and consequently their revenue generation). Even ignoring the latter aspect of that, its cheaper to have 1 team build out a single interface than multiple teams each working on platform specific interfaces. Then theres a follow-on reduction in support (and troubleshooting) costs in dealing with platform specific updates, less coordination/communication needed and thus reduced need for management level resources, etc etc. Theres also lower costs in terms of skills the company is hiring.

I'd also extend that to the possibility that the prevalance of tooling such as electron and its kin is a response to a demand for it, rather than arising out of being "best in class".

So best and/or simplest platform... well that depends on whats being measured. From a financial perspective, sure, why not. Other measures though... Im not so sure.

To answer the question of "why", I'm reminded of this post I saw a short while back: https://old.reddit.com/r/funny/comments/mce3j0/why_do_you_wa...

Im not particularly fond of these types of lists, but given the author and the material posted, this is definitely an exception.

One thing I didnt quite get:

> Every project is a triangle made of time, money, and quality; shortening the length of one side necessarily lengthens one or—more often—both of the other sides.

If I'm assuming the longer a side is, the "more" of it that is required, then the way I understand it is that the "quality" side might need to rather be "inverse quality", such that shortening the quality side length increases quality. As per the original statement, a reduction in quality (shortening the quality length) increases time and/or money, whereas IME when building something out, quality results come at a (time/money) cost. I guess it half makes sense if the perspective is that defering on quality (shortening the line) costs more in the long run (increasing length of the other 2 lines). But then taken from the perspective of the other 2 sides of the triangle: reducing money or time doesnt result in an increase (longer side) of quality... typically the opposite.

So genuine question: did I misunderstand the point?

Personally, I have a strong preference for not combining my password manager with my 2fa totp code generator though. Compromise of one meaning compromise of the other, and all that.

Offtopic: For interest, there seems to be an issue clearing/deleting values from inputs. Ar least on mobile anyway. The last digit is never visibly removed and appears to still be considered a part of thr input value.

Also, decimal input fields(such as TER) do not seem to accept any decimal character input

> After reading that, I would not use it without completely understanding the code as if I had written it myself (and maybe that's what you should do for every dependency anyway).

Isnt that the point? As in, it allows for the use of some (context-appropriate) open source upstream software to quickly flesh out some idea into an implementation, rather than expending time and effort writing certain code oneself (the user of the open source software). This doesn't absolve the user from the responsibility of eventually writing their own implementation, or alternatively, maintaining, that open source code/library/framework as a part of their overall codebase.

And so I seriously miss the point of where the managing or maintaining of some open source code, to satisfy some other downstream project's requirements, is the responsibility of upstream... again, when downstream uses it they do so to benefit themselves by not having to write or maintain that piece of software, but that comes with risks along with the relevant benefits. As in, its a "dependency" (in the name) for a reason.

I almost see it as bordering on a concept of entitlement to think that someone else (eg the original creator of some software) should spend time and effort fixing issues or adding functionality that benefits some user. Basically, one should always be considering that dependencies at the time of pulling them in are static and provided as is with no contract of maintenance, and that it might provide benefit currently but that there is a very real potential cost to using it in the future.

I understand the point being made, but this is solved trivially by including a published date, eg: Best $product - published $exact_date

(or alternatively, instead of "published" use "updated").

This has the added benefit that those searching for $product towards the end of a year can decide whether such lists published/updated near the beginning of the year are relevant or not.

Looks interesting enough... But how does one solve the issue of security level updates for some dependency language? Or when a particular version of some application reaches EOL and is no longer maintained, or theres some functionality in a newer version of Nodejs|Ruby|etc thats needed?

From what I understand this would require an update to the Nix version that supports it... but that also potentially means bumping other environmental versions as well, which might not be desired. But I suppose this would amount to the user arranging the structure of their filesystem correctly so its one "system" per dir/folder... Or is there a better way to cater to this? And I suppose this still means that the node modules, gems, etc that are being used then anyway also need to be updated after this accordingly.

From my limited understanding of Nix, it seems interesting, and the article was actually useful to me. But I cant seem to shake the feeling that this is another packaging abstraction like others before it, and while it seems like a better variant, its not much different to having X, Y and Z listed as requirements and then letting the dev go off and install such dependencies on their system, in the way that they best know how. Juniors or those new to a specific environment might not know the ecosystem so well so as to know to use rbenv or nvm or whatever, but I'm not sure how Nix solves this issue differently than one of the specific tools its replacing.

Theres clearly more to Nix than just setting up language environments, which I'm guessing is where its usefuleness really kicks in. But purely for lang env set up, I'm not sure I see a point over other tooling...