Sadly I can't find any pics of the basic table we made, but that was actually an easy thing to make once I thought it through.
I basically got a 2 sheets of MDF to the size I wanted (roughly the size of a baking tray for the oven, as I had to heat the plastic in my home oven) then drilled a hole every couple of cm in one of them, then made them into a shallow box - sealing all the places the wood connected with bathroom sealant on the inside and duct tape on the outside. I made a hole in one of the 'side' pieces that would fit my vacuum cleaner hose, and then added more duct tape to seal.
Then I made two wooden frames as big as the largest baking tray for my oven, then cut some heatable plastic to size, and clamped them in the two frames and put them in the oven.
This part had loads of trial and error - ie how long the plastic needed heating, how long to run the vacuum cleaner, how to make sure the plastic didn't end up behind the thing you were forming, how to make sure the think you were forming didn't deform while under pressure.
Glue gun. I've made probably a dozen paper masks in this style, patterns purchased from Etsy shops and printed on heavy bonded paper.
I like hot glue for this type of work because it gives you a _little_ bit of leeway to make mistakes while it's still warm, so you can slide the pieces around to get them just so. Then it cools and hardens quickly so you don't have to wait a long time before moving on to the next piece.
Early in my career I spent some years working at the biggest bank in Canada, they were (and still are) an enormous IBM customer. Hardware, software, consulting, and probably lots of other things I had no visibility into.
Beneath the countless layers of VMs and copious weird purpose built gear like Tandem and Base24 for the ATMs was a whole bunch of true blue z/OS powered IBM mainframes chugging through thousands and thousands of interlocking COBOL programs that do everything from moving files between partner banks all over the world, moving money between accounts, compounding interest, and extracting a metric shitton of every type of fee imaginable.
If you know z/OS there's work available until your retirement. Miserable, pointless, banal, and archaic legacy as fuck mainframe work.
I don't how exaggerated this story is, but one of my buddies did his internship at TD. One of his skip managers told him if you know COBOL there are departments that will give you a blank cheque during salary ngotiation.
Yeah it's hard to say but I believe there's at least some truth to that. I took COBOL off my resume over a decade ago just to combat the volume of recruiters trying to drag me away from the cloud back to on-prem land.
A good friend of mine who worked on a CICS based credit card processing application at that bank doubled his salary twice inside of 4 yrs. First by quitting the bank and going to a boutique consultancy to build competing software (which they sold to other banks) and then by quitting that job and coming back to the bank to takeover the abysmal state the CICS app had lapsed into in his absence.
And that was circa 2010.
One thing that was true of the bank then and I'm sure is true now is that when they see a nail they truly have just the one hammer. When a problem comes along, hit it with a huge sack of cash until it goes away.
I don't think "know COBOL" is enough. I'm pretty sure I can learn COBOL in a week. It's more about "know COBOL and know all this old stuff like CLIs, etc, and know all these old approaches".
Typically it's not just about knowing COBOL as a language, the bottleneck is having real expertise wrt. highly specific, fiddly proprietary frameworks that are implemented on top of COBOL.
Tandem! Now there's a name i haven't heard in a long time. A college friend of mine worked with some of their stuff right out of college and I still remember him telling me about it. It seemed like magic, we were both floored with the capabilities.
/we were in our early 20s and the inet was just taking off so there were lots of "magic" everywhere
Man ... this question hits me really hard. I was absolutely miserable by the end of my years at the bank, and the part that really fucked me up was that (at the time) I could not understand why all my colleagues weren't.
Huge generalizations incoming, there are exceptions to every rule, but in my experience there are no nerds who love tech for tech's sake in the banking world. It's entirely staffed by the "C's get degrees" crowd who just want to clock in, clock out, keep their head down, and retire with a nice pension.
I wanted to work on sexy technology, wrangle clouds, contribute to open source, and hack in modern languages.
I have many friends who are still at that bank 20 yrs later. They're all directors of this that or the other thing, still just grinding out some midlevel whatever career and cruising comfortably. If that ticks all your boxes then by all means go hit up a bank job.
By the time I left I couldn't drink enough liquor in a day to rinse the stench of that job off me. If I hadn't managed to slip that place I'd be dead of liver failure by now.
It's the secret for a long life for some folks, but it ain't for everybody.
Fresh out of college, I had an interview for a job working with COBOL. There were classes being held to teach people development, as well as how to maintain existing COBOL software. It was between myself and another recruit, and that other recruit already had COBOL experience. Naturally, I was not chosen, over someone who already have knowledge of the working language being used.
Although I probably don't make nearly as much as that COBOL developer over 20 years later, I would be willing to bet that I am happier and haven't locked myself into a specific technology the way that developer probably has. Money is great, but if you actually care about what you do, I expect that being stuck on the same codebase for years isn't too satisfying (at least on code you didn't have a hand in creating from the very start). Too many people translate money into happiness, and I guess there is a balance there, but usually it's not possible to maintain happiness based off money when you do the same thing day in and day out.
You don't want to work for IBM unless your life is already over. Been there, done that, never again. It's depressing as hell. Your manager doesn't understand what you do, and they think that once your contract expires you'll be sitting around for weeks waiting for them to renew it.
> If any maintainers stop by this comment section, I suggest offering some explanation about what this project _does_.
This. It's a pretty awful way to present anything. The reader is still clueless and unsure about what they are reading even after navigating through 3 or so links. At each click I was hoping to read anything related to APIs but all I was reading is bureaucrat noise.
Perhaps it's a good idea. I can't tell. I wonder if anyone can.
Seconded. And even browsing the actual AEPs, they are presented so confusingly, it's hard to say how it actually works. There's lots of prose, when the first thing I would want to see of a concept is a plain-text HTTP request and response, not a clever Protobuf definition and colored words all over the place.
Any project where all of the links on the first page are “meta” such as “project governance” is my little red flag that tells me there is zero value to be found here.
https://ibb.co/BHcG4BkB
reply