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.
You’re absolutely right—EnkiTask isn’t a full project management tool, it's more of a Task Management tool, and in the first version of the landing page, I positioned it that way. However, some friends in marketing suggested that if EnkiTask evolves into a more comprehensive project management system in the future, it would be tough and costly to change the positioning later. So, I decided to position it as a project management tool from the start, even though I know it’s not there yet.
Regarding Gantt charts and budgeting, I intentionally chose not to integrate those features because I wanted to keep things simple and affordable. There are already plenty of great tools for managing budgets and finances. Instead of building those features from scratch, I’d rather focus on creating a lot of integrations with existing tools to provide users with flexibility. That said, I’m planning to launch a Feature Suggestion page soon where users can propose and vote on features they’d like to see added. If those features gain enough support, we’ll definitely consider adding them! :)
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.
It's not analogous. The person was being charged of a crime that happened in the UK and fled to the US, then was extradited back to the UK to be tried. In other words how extraditions usually work.
An applicable case would be someone being extradited from the US to the UK to be tried for a crime that happened while they were in a different country.
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).
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.
Last time I know during node 16, npm install updates your package-lock.json, but for patch version number (unsure about minor version) only and if the package.json is using relative version number. Definitely use npm ci or yarn if you want to adhere to lock files.
> if the package.json is using relative version number
What do you mean by this? You can specify dependency versions using "^" which means "I accept new minor and patch versions" or "~" which says "I accept new patch versions", or a bare version to say I want an exact version; but none of those have anything to do with a bare "npm install" command. They are relevant when you install a new package, with "npm install <package>". That is a totally different operation, and it absolutely can update versions when needed.
However, when you just do "npm install" it does not update your package-lock.json to the latest version that matches your semver requirements in package.json. That will only happen if you install a new package that needs it or you use `npm update` or some other command.
This is easy to test but it's also intuitively correct- you don't expect to run `npm install` and have an uncommitted change to `package-lock.json` appear, and that does not happen in normal usage.
It is kind of unfortunate that "npm install" and "npm install <package>" use the same verb of "install" for two different things- other package managers don't make this mistake and it avoids the sort of misconception we're running into here.
Exactly what I said, I have experience with ~ but not with ^ and have never used it. Let's say that you have a package version ~1.2.11 and have 1.2.11 as installed version in package lock. Then if let's say 1.2.13 is out there, npm install will update package lock to that one. npm ci won't change that. package.json file will kept unchanged though.
No, "npm install" doesn't actually do that. In the situation you are talking about, "npm install" and "npm ci" behave the same.
It makes sense that they behave the same here right? What is the point of a package lock if just installing packages on a new copy of a codebase updates the dependencies?
Package locks aren't just about deploying: As a developer, I need to be assured that the code I'm running is the same as my coworker.
Yes I think you are right when NPM first introduced it, which was in NPM 5 [1]. At that time package locks were new.
Node 16 shipped with NPM 8, and by then this was not the behavior any more. I don't remember exactly when, but I believe it might've been in NPM 7 when this changed. Node 15 would have been the first release to ship with at least NPM 7 [2]
Honestly no guarantees it worked as intended right at that release, but the intention is clear.
EDIT 4: I realize that the following may present retort but it matches my mental model perfectly:
> If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above.
This is what I've mentioned elsewhere: You should not update package.json's versions and deploy it and expect that versions won't change when NPM install runs. In fact, npm ci will just fail in this situation, which is a Good Thing (TM), and is documented as such.
LAST EDIT SRSLY:
It is conceivable, especially given OPs other red flags, that perhaps they were on an older Node/NPM like Node 14.
That's another practice that I regularly do, pin NPM itself in deploy scripts. While I was using Node 14, I was using NPM 8, because you can just "npm i npm@8 -g" to upgrade your NPM regardless of Node version.
> 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.
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?
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?
I think it’s the class pick two conundrum. Want it quickly and high quality? It’s going to take a lot of money. Want cheap and high quality? It’s going to take a lot of time. Want it fast and cheap? Quality will suffer.
If something takes a lot of time (= work?), how can it be done cheaply? Or is that in the sense of waiting for a long time for the right inspiration to hit you for how it can be done cheaply?
I have a couple of minor carpentry projects going on. I could finish them quickly if I bought or rented great power tools. I don't want to spend the money though, so I'm using mostly hand tools and manual labor.
My point is that I wouldn’t say that that labor comes for free. In any case, that triangle would then not apply in a commercial setting, where you have to pay those doing the labor, in addition to it taking time.
It still applies in a lot of circumstances. For example when to buy off the shelf (for $$$$) vs rolling your own solution (which will take longer but could be less money in the long run).
