Hacker Newsnew | past | comments | ask | show | jobs | submit | foopod's commentslogin

It really bothers me that people refer to open weight models as being open source. They fundamentally aren't and are more akin to freeware than anything else.

Not in Chrome or iOS probably. But Firefox for Android supports extensions.

Safari on iOS supports extensions

As a (unfortunately) wordpress dev this seems to solve my single biggest painpoint with WP. Which isn't plugin security, but the overall plugin architecture.

WP treats plugins as content, literally in the same top level `wp-content` directory as uploaded images. This makes CI/CD among other things, a nightmare. But EmDash plugins are just TS modules, which has got to make things easier even if plugin configuration does end up in the db somewhere.


Wordpress has no concept of a "staging site" and no way to make changed and then "export" them from dev to production; you basically have to either restore it as a backup or just replay the changes by hand.

Huh? That’s not how i think you should be approaching that. I always run local, staging, and production sites. It’s easy to setup and deploy across.

How do you deploy menu changes from staging to production?

Ah. I understand your circumstances better. Short answer - I wouldn’t deploy menu changes. That’s usually low-lift that I would do it manually.

If I was doing it in a recurring basis I would investigate creating a process to export the menu data and import directly using a custom plugin. Or create (via plugin) and endpoint to sync both environments (a bit more work).

I did this one time before for a subset of pages and admin users. There are likely plugins that do this already but you could likely roll your own just for menus in an hour imho.


I’m not the one you asked, but when I did WP work a few years ago I would solve it via a hook that was triggered on Jenkins deploy. The hook would always fire and listeners to that hook would execute migration scripts and similar callbacks. For example used it to migrate some tags to categories and vice versa.

https://developer.wordpress.org/plugins/hooks/custom-hooks/


I remember when I looked at Wordpress for the first time, like 15 years ago, and was baffled that a dev/test/prod workflow involved copying filesystem content, database content, and changing URLs that got saved in the database. I couldn't believe what a steaming pile of garbage architecture it was.

Fast-forward to last year and I'm asked to look at it again. Surely, I think, in the ensuing time somebody would have rectified the architectural stupidity. It's a wildly popular platform, I thought. Surely it can't still be so terrible...

Fool me twice, I guess. >sigh<


> a dev/test/prod workflow involved copying filesystem content, database content, and changing URLs that got saved in the database.

This just sounds like deploying web software. You always have static assets that need to be deployed, the code/binary itself, and database migrations.


The "copying filesystem content, database content" part of that is perfectly sane. I should have phrased that better.

The insane part is the search-and-replace on the database backup to find hard-coded URLs referencing the environment's hostname. That's ridiculous. It speaks to the lack of serious operational experience that went into building the software.


Ah. That’s like a 15-line rite-of-passage plugin you write once and never have to worry about it again. Filter content going into the database and use relative uri for the same site. Configure everything else via environment variables.

I moved away from Wordpress altogether earlier this year because I got tired of babysitting MySQL.


Why would you expect it to? It probably predates these concepts. /s

This explains all the crypto shilling.


Your point of view assumes the best of people, which is naive. It may not force you to skip understanding, however it makes it much easier to than ever before.

People tend to take the path of least resistance, maybe not everyone, maybe not right away, but if you create opportunities to write poor code then people will take them - more than ever it becomes important to have strong CI, review and testing practices.

Edit: okay, maybe I am feeling a little pessimistic this morning :)


IMO not significantly. Prior to AI the bulk were tutorial based to-do apps or simple crud things anyway, its still easy to tell the difference between those and something more complex (where AI is less useful - or at least requires more skill to use successfully).

But I don't think the projects themselves really mattered all that much anyway - its the conversations you can have about them. Understanding the driving factors, whether it was solving a problem they have or just working on something they are passionate about, the challenges they overcame in the development process and the considerations/decisions they made along the way.


Yes, I agree totally. But portfolios served a great purpose to expose what you can and what you know to the world and recruiters. Which would then lead to a opportunity to talk about the projects.

We might be going back to a more oldschool approach where talking directly and presenting themselves would be more of a value again. It have always been an higher value, but now it will be kinda more forced I believe.

Another route would be that portfolios become more blog-based, talking about different solutions and problems for each project, as you are saying.


I was curious, so I checked, it is raw html. And yes it is beautiful.

https://github.com/juecd/juecd.github.io


Talking out of my ass, but since epubs often target mobile devices (kindle, kobo, etc - with limited storage) - publishers probably find that their books do better if they tend to be smaller in size. And images take up far more diskspace than text does in a digital copy.

Then when a user needs to delete books from a device they will start with the largest files. The longer the book is on the device the more likely they are to engage with it, etc.


Sorry, but this is nonsense. I'm not talking about photos, but about graphs, line art, tables. Using PNG you can create real small (in filesize) images, like 10-30 kilobytes. The size of the image (dimension) often doesn't matter that much. You can create the same image (black on white or line art with three or four colors) and resizing (less pixels) it won't make much of a difference in file size, nothing significant.

I cannot believe that publishers create small pictures because bigger pictures means that their book will be deleted later on. That argument seems far fetched.


I did provide a warning of my nonsense. As you say though 10-30kb per image, in a 350+ page text book is already likely 7mb+ (assuming 1+ images pp). And that is absolute best case if the original images and optimization are working together. I would guess without any optimization for digital publication you could be starting from 100-200mb easily.


I see two possibilities (not mutually exclusive)

1. Art is art because it draws meaning from human existence - AI can't and can never exhibit this. Furthermore, pumping out thousands of "creations" a minute will never compare to a single work from a human.

2. People are dumb and will fawn over just about anything, the origin of a piece of art created today is less relevant than ever.


I agree both can happen at the same time but what does that mean for a human artist?


  Location: Hamilton, New Zealand (NZ)
  Remote: Yes
  Willing to relocate: No
  Technologies: Javascript/Typescript, React, Express, Postgres, MongoDB, Python
  Résumé/CV: https://drive.google.com/file/d/1M3Ep8f_pmsabJA2dMyjphYsEnikMoVPd/view?usp=sharing
  Email: jonathonshields@gmail.com
My most recent job was teaching/mentoring web development at a tertiary education provider. But now I'm looking to get more hands on again as I have missed coding. Nearly 10 years experience in the industry across a number of fields. I'm enthusiastic and always looking to learn. Let's grab a coffee!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: