Selling yourself as a Cybersecurity dev from Iraq will probably be harder than selling yourself as a frontend engineer. So I would focus on improving frontend skills and marketing.
You didn't mention it as an option, but if you are tiring of frontend, I would consider pivoting to doing backend/fullstack/data engineering. Boost your database/analytics skills. Your front-end experience can help you have a nice niche in that backend space once you master backend work.
But this is just a guess on my part from an American developer/architect/hiring manager in both startups and large companies whose frontend skills plateaued 20 years ago at the expense of backend skills but who lightly follows frontend technologies.
What I noticed missing in this analysis of distributed systems programming was a recognition/discussion of how distributed databases (or datalakes) decoupling storage from compute have changed the art of the possible.
In the old days of databases, if you put all your data in one place, you could scale up (SMP) but scaling out (MPP) really was challenging. Nowdays, you (iceberg), or a DB vendor (Snowflake, Databricks, BigQuery, even BigTable, etc), put all your data on S3/GCS/ADLS and you can scale out compute to read traffic as much as you want (as long as you accept something like a snapshot isolation read level and traffic is largely read-only or writes are distributed across your tables and not all to one big table.)
You can now share data across your different compute nodes or applications/systems by managing permissions pointers managed via a cloud metadata/catalog service. You can get microservice databases without each having completely separate datastores in a way.
I spent years thinking about this at the time, and wrote up a crystalized super-long "why?" in an SGI retrospective comment on an earlier thread, https://news.ycombinator.com/item?id=39960660 which you might find of interest.
Feedback from SGI insiders or pointers to HBR case studies welcome.
I completely agree with you that (unlike/despite the Supreme Court ruling), database table/column schema design (and other system designs) should fall under the Illinois statute as "documentation pertaining to all logical and physical design of computerized systems". It's interesting that the law did pick up on that distinction between logical and physical design but none of the parties described in this article did. Logical/physical designs are not just about servers and integrations, they are also about data.
I'm not sure why that wasn't argued by the state and the state argued the database schema was a "file format". Per my reasoning, the state still would have won, but for different reasons.
I disagree with you slightly however and would say that the schema table/column names should be considered not logical but "physical design" while the business naming/meaning of tables would be a "logical design" (or conceptual design). See Wikipedia: https://en.wikipedia.org/wiki/Logical_schema
SQL injection is really about physical schema designs, not logical ones (I do get that every bit of information including business naming of tables/columns helps in an attack, but it does change the degree of threat and thus the balancing tests of the risk which are relevant per the definitions and case law described in the original article.)
So in terms of what the law /SHOULD/ be, the law should not include logical design as a security exception, only physical design. It /SHOULD/ be possible for citizens to do FOIA requests and get a logical understanding of all the database fields without giving them the SQL names that can accelerate SQL injection attacks. In that way citizens could ask for the data by a logical/business-named handle rather than a physical one.
And the state should create logical models or provide data dictionaries with business (not technical terms) on request as part of their FOIAable obligations to their citizens for the data they are maintaining.
My 2 cents as someone designing database schemas for 25+ years.
I seem to remember in the ?late 90s? Intel execs talking about how their market's growth opportunity was all about capturing eyeballs (attention). Eyeballs, eyeballs, eyeballs. At the time I thought it was a weird way of talking about internet media growth at the expense of TV, but it seems more revealingly predatory (of not just Intel but the entire industry) in hindsight.
I've tried to find old videos of execs talking on stages about this to fit my memories but I can't seem to find them. Does anyone else remember what I'm talking about?
The language of "war for eyeballs" in the wake of social media's success at weaponized attention/floe is revealing and distasteful in the same way as Coke's internal discussions of trying to maximize "stomach share".
That said, the addictive nature of the web was there early on even before it was commercialized. I distinctly remember a CS grad student warning me in 1993 that there was this new graphical web thing, but it was pretty addictive... So I ignored it for an additional semester before I got sucked in...
I'm not yet sure whether they are even doing data science.
Anecdote time (pinch of salt required):
A relative of mine studying accounting went to the Doge site to see the "audit" and "analytics" records that some acquaintance arguing with her said "see the doge site!" for the proof.
What she found when visiting the site was no "audit" at all, but instead a word count of how often objectional terms appear in legislation or government sites. (DEI? Trans? LGBTQ?).
Being in the analytics/data engineering space myself, I was pretty amused to hear that was the quality of "analytics" being done.
Wasn't "word count" the "hello world" example for Hadoop big data back in 2013?
The core counts shown seemed grossly wrong (low) to me in all respects, from desktops to laptops to high end datacenter CPUs, so I looked into the assumptions.
The chart is from the perpective of CPUs going into HPC clusters, not high end SMP database servers in more commercial datacenters. The industry did have more than one core before 2004. The dataset author's 2016 blog explains "Similarly, I only consider CPUs for dual socket machines" [like Xeon Phi].
I'm not sure, given the HPC orientation why the dataset author didn't show specFP rather than specInt... but if I had to pick one, I'd also pick SpecInt.
You didn't mention it as an option, but if you are tiring of frontend, I would consider pivoting to doing backend/fullstack/data engineering. Boost your database/analytics skills. Your front-end experience can help you have a nice niche in that backend space once you master backend work.
But this is just a guess on my part from an American developer/architect/hiring manager in both startups and large companies whose frontend skills plateaued 20 years ago at the expense of backend skills but who lightly follows frontend technologies.
reply