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.
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.
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.
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: [email protected]
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!
Code being open doesn't mean anything unless you can verify the code running on a machine at the time of voting (adding another layer of complexity). It's not just voting software though, the rest of the system needs to be verified too (both software and hardware).
Not sure why you compare blockchain here either, no developed countries I know of use blockchain in their monetary authority or try to obscure voting processes from the public.
Without knowing more the cheapest is free (at the cost of some time). Find a static site generator + template + host on netlify/github pages (use their subdomain, or fork our a few dollars for your own).
Yes, they have different uses cases. But one can easily see an arbitrage opportunity here for building an immortal database atop S3 (and other cloud services) for a lot less money. For $12,000 USD, I could store the same data in S3 for (at the very least) 445,217 years. (Using the example above.)
That makes the value proposition of the Ethereum blockchain as a data store a lot less attractive.
This is so theoretical, I don't think it has any value. Meanwhile, consider the effort involved in destroying all data stored in S3 vs destroying the entire ETH blockchain. One is expensive, possibly only achievable by a national superpower, the other is virtually impossible without destroying the planet.
I fully realize the theoretical advantages of blockchains. I can still store multiple copies in multiple clouds across multiple availability zones cheaper. The original question did not imply the destruction of S3.
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 :)