What medications are you on?
207 karma · joined June 17, 2010
Edit: To answer your two questions:
1) No, it's not stateless.
2) Depending on the implementation of the function, yes, it may be a valid state machine. Or, it may not be. Depends on the implementation of the state machine within the function.
https://github.com/Homebrew/discussions/discussions/225
https://stackoverflow.com/questions/6941889/is-it-safe-to-sh...
https://stackoverflow.com/questions/6900103/why-cant-i-push-...
Modern git appears to have implemented solutions to these limitations, but old habits die hard.
I live in New Jersey. NJ and NY has a considerable amount of COBOL deployed, in banking, insurance, payroll, etc., and especially by government organizations.
Compensation is still on the lower end, like $90k-120k/year, vs. $160k-200k for more modern tech jobs, but the competition for those jobs is almost certainly to be lower/less competitive, you're less likely to be laid off if you're even remotely competent and don't do something stupid like break the law.
To OP's original point, if you're looking for a non-management role and want to maximize your earning potential while simultaneously minimizing your employment churn risk, being a competent COBOL programmer earning $90-120k/year comfortably definitely fits the bill.
Of course, if OP's statement that they are "sick [...] of doing the same CRUD apps over and over again" then COBOL may not be a good fit: you certainly aren't going to be doing much in the way of innovating when supporting a legacy COBOL application, but you should be able to carve out a very consistent work schedule, find some decent work-life balance, and enjoy perpetual employment as long as you desire it.
https://www.cnn.com/2020/04/08/business/coronavirus-cobol-pr...
"Despite a dwindling number of COBOL programmers, a 2017 report by Reuters found that there are still 220 billion lines of COBOL in use today. 43% of banking systems are built on COBOL and 95% percent of ATM swipes rely on COBOL code."
How does one show proficiency? As much as I dislike certifications, I think this is one place where earning a certification that demonstrates competency from a reputable certifying body, in lieu of verifiable employment history demonstrating experience, would be worthwhile.
I would look to see what certifications IBM offers, for example.
https://www.ibm.com/blogs/ibm-training/free-course-announcin...
"Your scientists were so preoccupied with whether they could, they didn’t stop to think if they should." -- Jeff Goldblum
You will always be able to find paying work until you die, and it will only pay more over time as supply decreases (programmers die) but demand doesn't decrease at the same rate.
It's not sexy, but if you're looking to maximize earnings with the least amount of risk that the effort expended developing the skill loses its value over time, this is the way.
If you aren't touch-typing and are looking down at the keyboard, or even just having to spend mental cycles thinking about typing, it's taking away from your capacity to think about the problem you're solving.
Can you write programs without being able to type? Sure, of course. But, you asked for basic skills that will improve your programming, so I say: typing.
60 WPM is a minimum. 80-90 WPM is a reasonable low goal. 100-120 WPM is probably an upper bound limit on QWERTY; if you're very serious, you may want to consider learning Dvorak or Colemak layouts, where you might be able to hit top speeds of 150-200 WPM.
If you want to get users to pay for the service, then you have to improve the product for the users, not for the advertisers.
And, to that end, the question of whether the service is being ruined by an abundance of bots and spam, regardless of whether it's negatively impacting _advertisers_, is a real issue if you're looking to acquire the business.
That is some real BS gerrymandering on the part of Twitter.
Accounts that are not "monetizable daily active users" who spam and harass users on the service don't count?
Of course they count.
Just generate random numbers from 1 to 2^64 and use the "/users/show" API by user_id until you've got 100 successful hits that match a valid user, then once you have 100, score the users.
Do you get fewer than 5 out of 100 spam bots? That should be the test.
Why would you not just take a random sample, instead of cherry-picking scenarios that are guaranteed to be affected by selection bias?
So unfortunate.
All of the ones that are of sufficiently high quality that they're worth using (new URLs reported quickly enough to block active senders in progress, not filled with false positives, etc.) are all paid subscription services.
$ jq -n -r '[{"a": "b", "foo": "bar"}, {"c": "d", "baz": "quux"}] | .[] | [ keys_unsorted[] as $k | .[$k] ] | @csv'
"b","bar"
"d","quux"
$ jq -n -r '[{"a": "b", "foo": "bar"}, {"c": "d", "baz": "quux"}] | .[] | to_entries | map(.value) | @csv'
"b","bar"
"d","quux"
https://en.wikipedia.org/wiki/Web_of_trust
And you can implement it without silly proof-of-work nonsense.
Perhaps you've heard of https://www.nomorobo.com/ ?
"It all works out in the end, and in the end, we're all dead."
Also: https://hn.algolia.com/
However, there are many teams who either don't have the knowledge/expertise, or the available time, to do the testing themselves. This is where "buying it off the shelf" can come in handy.
Then, there are teams that are completely clueless when it comes to application security, and even the most basic scan by any of these pen testing vendors will find very obvious security defects, which is absolutely valuable for them to learn about. This is the minimum bar that we should hold software application developers to, and there are many who don't even meet this without the assistance of reports from pen testing vendors. Scary, but true.
So, YMMV.
It's not an insult, let alone a needless one: it is a statement of fact.
The reasons OP cites for criticizing CSV are creations of OP's imagination, their subjective beliefs, and not based in objective truth.
For example:
> "CSV is a mess."
Actually, CSV is quite orderly and predictable. OP only imagines it's a mess because of some skewed experience they've personally had.
> "One quote in the wrong place and the file is invalid."
Any file format that is encoded improperly renders it invalid. Imagining that this is strictly limited to CSV, is just that: a creation of OP's imagination.
> "It is difficult to parse efficiently using multiple cores, due to the quoting (you can’t start parsing from part way through a file)."
This is absolutely untrue. Anyone who's written a high-volume streaming CSV parser that is multi-process and multi-threaded should be giving OP the side-eye here.
Yes, you can absolutely start parsing from any arbitrary point in the file, and yes, in the degenerate worst-case scenario, you may need to rewind back to the beginning of the file if the data exists in such a way that your arbitrary starting point requires it, but that is true of ANY file format: it is possible to craft a worst-case scenario and specific starting position within that data that would require this. CSV is no exception.
Hope this helps you better understand what I had written.
I'm not one of those people.
Tried therapy. Working with coaches. Experimented with drugs, both prescribed by psychopharmacologists, and ... the other kind.
Don't let this discourage you: most people don't seem to have this problem, finding their purpose.
If you truly and actually want a job solving problems and making an impact of some kind, as you say you do, then start with yourself: how could you solve this problem? What experiments might you design and execute? What questions would you seek answers to? What are your success criteria? Are there experts you could seek out for assistance?
Ultimately, you might find that you're only fooling yourself, saying you want a purpose because you've formed that opinion through life experience or some other influence, either internal or external.
It's also perfectly okay to just "be" and not have a purpose: this is probably the hardest thing for me, personally, to recognize as true and fully accept, too. But, it is.
In the end, my personal advice would be to spend some time, whether it's minutes, hours, or days, and write down a list of every single thing you like to do, no matter how trivial or whether you think it's "wrong" for you to like doing it or not. Don't focus on all the things you don't like doing, don't create a "cons" list of those things. Only focus on the "pros" and write them ALL down.
Then, once you've got a fairly extensive list, start creating groups or clusters (permutations, with reuse) of the things on the list, and look for patterns that emerge that suggest possible professions or at least things you could develop and get good at.
Then, start doing those things. The things you truly, genuinely like doing. Then, eventually, you can figure out how to monetize those activities. Almost everything in life is monetizable if you're willing to.
The challenge is finding the things you truly like doing and going out and doing them.
Easy peasy.
Follow me for more tips on how to live your best life.
Once upon a time, when I was doing a lot of data interchange between a wide variety of systems (OS'es, applications, etc.) I considered proposing an "enhanced CSV" (ECSV) where the values did not start on the second row in the file, but instead the second row would be regular expressions that could be used to validate the contents of the columns that followed, and data would start on row 3.
In other words, you might have:
``` ID,NAME,DATE
"/^\d+$/","//","/^\d{4}-\d{2}-\d{2}$/"
867,Alice,1984-01-09
5309,Bob,1981-11-16(Newlines added because HN doesn't speak Markdown, sigh.)
In the end, I think the solution was far simpler: we just exchanged a separate descriptor file that had column names and their corresponding regexp patterns for validation as a separate (versioned) file, in order to save a few bytes inside each file transmission, which was a real savings when you paid per-byte over an EDI network.
Or, how about columns separated by \u002C, and rows separated by \u000A. And, for bonus points, we can even define unambiguous ways of escaping those two characters so that they CAN appear within column values, if we wanted to, and not tell people that our encoding format is totally stupid and that they need to use a different format.
OP's proposal is equally "highly sub-optimal for the job" for exactly the same imaginary reasons they dislike the currently available encoding formats, but they don't seem to realize it.