So a few days ago I felt pretty h*ckin professional.

I'm an intern and my job was to get the last 2003 server off the racks (It's a government job, so it's a wonder we only have one 2003 server left). The problem being that the service running on that server cannot just be placed on a new OS. It's some custom engineering document server that was built in 2003 on a 1995 tech stack and it had been abandoned for so long that it was apparently lost to time with no hope of recovery.

"Please redesign the system. Use a modern tech stack. Have at it, she's your project, do as you wish."

Music to my ears.

First challenge is getting the data off the old server. It's a 1995 .mdb file, so the most recent version of Access that would be able to open it is 2010.

Option two: There's an "export" button that literally just vomits all 16,644 records into a tab-delimited text file. Since this option didn't require scavenging up an old version of Access, I wrote a Python script to just read the export file.

And something like 30% of the records were invalid. Why? Well, one of the fields allowed for newline characters. This was an issue because records were separated by newline. So any record with a field containing newline became invalid.

Although, this did not stop me. Not even close. I figured it out and fixed it in about 10 minutes. All records read into the program without issue.

Next for designing the database. My stack is MySQL and NodeJS, which my supervisors approved of. There was a lot of data that looked like it would fit into an integer, but one or two odd records would have something like "1050b" which mean that just a few items prevented me from having as slick of a database design as I wanted. I designed the tables, about 18 columns per record, mostly varchar(64).

Next challenge was putting the exported data into the database. At first I thought of doing it record by record from my python script. Connect to the MySQL server and just iterate over all the data I had. But what I ended up actually doing was generating a .sql file and running that on the server. This took a few tries thanks to a lot of inconsistencies in the data, but eventually, I got all 16k records in the new database and I had never been so happy.

The next two hours were very productive, designing a front end which was very clean. I had just enough time to design a rough prototype that works totally off ajax requests. I want to keep it that way so that other services can contact this data, as it may be useful to have an engineering data API.

Anyways, that was my win story of the week. I was handed a challenge; an old, decaying server full of important data, and despite the hitches one might expect from archaic data, I was able to rescue every byte. I will probably be presenting my prototype to the higher ups in Engineering sometime this week.

Happy Algo!

Long story short, I'm unofficially the hacker at our office... Story time!

So I was hired three months ago to work for my current company, and after the three weeks of training I got assigned a project with an architect (who only works on the project very occasionally). I was tasked with revamping and implementing new features for an existing API, some of the code dated back to 2013. (important, keep this in mind)

So at one point I was testing the existing endpoints, because part of the project was automating tests using postman, and I saw something sketchy. So very sketchy. The method I was looking at took a POJO as an argument, extracted the ID of the user from it, looked the user up, and then updated the info of the looked up user with the POJO. So I tried sending a JSON with the info of my user, but the ID of another user. And voila, I overwrote his data.

Once I reported this (which took a while to be taken seriously because I was so new) I found out that this might be useful for sysadmins to have, so it wasn't completely horrible. However, the endpoint required no Auth to use. An anonymous curl request could overwrite any users data.

As this mess unfolded and we notified the higher ups, another architect jumped in to fix the mess and we found that you could also fetch the data of any user by knowing his ID, and overwrite his credit/debit cards. And well, the ID of the users were alphanumerical strings, which I thought would make it harder to abuse, but then realized all the IDs were sequentially generated... Again, these endpoints required no authentication.

So anyways. Panic ensued, systems people at HQ had to work that weekend, two hot fixes had to be delivered, and now they think I'm a hacker... I did go on to discover some other vulnerabilities, but nothing major.

It still amsues me they think I'm a hacker 😂😂 when I know about as much about hacking as the next guy at the office, but anyways, makes for a good story and I laugh every time I hear them call me a hacker. The whole thing was pretty amusing, they supposedly have security audits and QA, but for five years, these massive security holes went undetected... And our client is a massive company in my country... So, let's hope no one found it before I did.

Admin work, because its all manual:

- Each new project has to fill out an Excel tab in a workbook, with a list of all the major tasks and who is responsible. This then needs to be used to create a Gantt chart, manually, in the same tab, showing in what month a task starts and ends.

- Every month we have to manually enter status updates into a powerpoint slide on a shared deck. Which has a collision at least once per month.

- Once a quarter we need to do something similar as the powerpoint slides, but into a word doc instead.

- Once a week we need to track our time on projects in a tool that can't be integrated with (no API or anything). Meaning we can't link up a ticket tracking system to it, so again, all manual.

- Once every 6 months a new round of research funding opens up and we write proposals. The status for which are tracked in another Excel spreadsheet, manually, once a week until the deadline.

- The instructions for what to do with the proposals are so vague and badly documented that there is an unwritten rule, that for the first time you will have to ask a bunch of questions to the project manager. This is accepted by everyone and its just the done thing.

- Everything is stored in a dropbox style system, which has become so cluttered I can only find resources by saving the links sent out previously.

- Some of these updates / reports also get a 1 hour meeting for everyone to stand up and read out what they've entered.

- From time to time random things will need to be reported on to the higher ups (how many publications, research papers, patents, times and dates etc.). Again rather than a tool, a new Excel spreadsheet is whipped up and emailed to everyone on the team. Whoever sent it out, then has to merge the 20+ copies into 1 doc.

- Some of the staff (mostly the devs), use a ticket tracking system to keep track of everything. Management refuse to use it to track the things they need. Instead we have to copy paste from it into the word docs, powerpoint, excel etc.

- By far the most annoying. Management force all the above as they need the info for finance, accounting, legal etc etc. So we have to do it, but whenever there is a question from legal, management send the question to us. So despite having documented every facet of everything imaginable, it all gets ignored in favour of endless emails.

I once tried to to put an end to all of this madness by proposing the use of a ticket tracking system, and then building reporting tools on top of it.

... I was told that it "wasn't appropriate". Still don't know what that means.

We got DDoS attacked by some spam bot crawler thing.

Higher ups called a meeting so that one of our seniors could present ways to mitigate these attacks.

- If a custom, "obscure" header is missing (from api endpoints), send back a basic HTTP challenge. Deny all credentials.

- Some basic implementation of rate limiting on the web server

We can't implement DDoS protection at the network level because "we don't even have the new load balancer yet and we've been waiting on that for what... Two years now?" (See: spineless managers don't make the lazy network guys do anything)

So now we implement security through obscurity and DDoS protection... Using the very same machines that are supposed to be protected from DDoS attacks.

Gave the marketing team access to JIRA and gave them permissions to create tickets. Don’t know if that was a management’s design or what. Tickets were poorly written and I had to make frequent follow ups to figure out what the heck was actually being requested. I did get accused of “questioning the request” at least once. It was a big WTF because I think marketing thought they managed dev team but they didn’t.

Marketing also didn’t give a damn about agile processes despite being told some simple rules, such as don’t change your ticket details after a dev has already begun work on it. I would pick up a ticket thinking it’s just html and css updates, then it would change to include an api update. No no no. You’ve just turned a 1 day ticket into a 1 week ticket. I don’t have time for these shenanigans.

I would also submit tickets for code review and marketing would say it’s not ready for review. Then why was that ticket in the to do column for the past two days?! They couldn’t make a decision and would submit revisions every single day.

And they would think devs could do everything. No, never assume the front end dev can pick up back end tasks.

No one on dev team really cared because we were all looking for new jobs anyway. The company was planning to lay us off in a year. Every month a dev gave notice and left.

This is a short tale that can be summed up as "oh fuck meee".

After finishing an API the night before I settled in for a day of bug fixes and tidy ups. Until slack went off.

The front end dev was getting an error, a code breaking error. After doing the standard process of request checking i went okay must be me. I find the script that is has the error and the line that it is failing at.

Que 2 hours of the full cycle of anger, sadness, pleading, and finally acepting that it had finally happened I had gone insane. The code was to documentation best practise correct and it still had the same error.

I the cheaked the DB on a whim and I found that my code was not wrong and it was doing exactly what I wanted the data however had a single record that was old and the schema had change juuussstt enoigh to break everything at that record. One 3 secound deletion later code ran perfectly.

Last year I changed jobs from a large multi-national to a small local agency (which happens to be run by friends of mine).

One of the reasons for doing this was that my work involved more office politics than *actual* software development, and had just plain stopped being fun.

Now, I am having fun again! An example?

For one of our clients we have to connect to (a lot) of third-party APIs. Often even SOAP APIs!

Now I hear you protest "But that is no fun at all! SOAP APIS SUCK!" Which is true, more often than not. 😔

BUT! My friend started an internal API-SNAFU Trello board. Every time you get bitten in the ass by some ill conceived fuck-up of an API, you get to add your complaint to the board.

Beside giving as something to reciprocally rant about, the board also serves a serious function: depending on the amount of fuck-ups an API has been known to make, the price for working with that API will go up.

Who said it doesn't pay to complain? 😀

In a meeting yesterday working through our WebAPI coding standards, starting from File -> New project..etc..etc.. and ironing out some of the left-or-right decisions so we can have a consistent coding style, working in a meeting room with an overhead projector and sharing keyboard around with one another.

Then we hit the routing 'rules' in the WebApiConfig, "api/{controller}/{id}"…

DevMgr: "Do we need the 'api' prefix? It seems redundant."
Ralph: "Yes it's needed. Prefixing the controllers with 'api' is industry best practice. Otherwise, how is anyone to know it's a web api"
Prancer: "Yea, it's part of the REST standard."
Me: "I don't think so. That is only part of the Asp.Net routing rule. We can put anything we want or take anything out."
DevMgr: "Yea, it looks silly. All the new services are going to be business process specific."
Ralph: "That's how everyone does it. It's kind of the point of why REST services are called WebApi"
Prancer: "What's the point of doing any of this work if we're not going to follow industry standards."
Me: "I understand if the service is part of larger web site, but we're developing standalone services. Prefixing routes with 'api' is redundant. I mean who are these 'everyone' you're talking about?"
<ralph rolls his eyes>
Ralph: "Lets see …uhhh… Netflix?. They're kinda a big deal."
Me: "Like I said, it's an integral part of their site and the services they provide. That's fine. I'm talking about the 12 other 3rd party services we integrate with. None of them have 'api' on any of their routes."
Prancer: "We're talking about serious web services."
Me: "Last time I checked, UPS is a big and serious service."
Ralph: "Their services are a fracking joke" – he didn't say fracking.
Me: "Our payroll system, our billing system, billion dollar companies, didn't have '/api' prefix anywhere. Heck, even that free faxing service we used for a while was a dead-simple routing path."
<I take the keyboard away from Ralph, remove the 'api' from the route.>
Me: "There. Done. Now, lets talk about error handling.."

Rest of the meeting Ralph and Prancer don't say much of anything, arms crossed…I swear Ralph looked like he was going to cry.
This morning I catch my boss…
Me: "What did you think of the meeting? I thought Ralph was going to take a swing at me when I took the keyboard away from him."
DevMgr: "Oh yes…I almost laughed out loud….blows my freaking mind how worked up people get about crap that doesn't matter. Api..or not…who the frack cares. Just make it consistent"
Me: "Exactly…I didn't care either way, but I enjoyed calling out that nonsense."
DevMgr: "Yes..waaay too much."

If I didn't call them on their BS and the 'standard' allowed to continue, I can bet my paycheck when the subject comes up in a few months (another mgr asks 'isn't this api prefix redundant?') Ralph and Prancer will be the first to say "Yea, its stupid. We fought really hard to remove it from the standard...its not our fault...its <insert scapegoat> fault."

FUCK UPS. Fucking dickheads killed our XML api a month ahead of schedule, and now I'm having to quickly implement stuff for their new api, and their docs are fucking dogshit. Seriously, the united parcel service can burn to death in a god damn fire.

Fuck UPS and their API Documentation. Has anyone here ever integrated their API ?
Their API documentation doesn't mention any sandbox or testing accounts.
If I click on their create access key button, it takes me to a form which requires a real payment method and address which seems like it's meant for real stuff not testing.

I think UPS' Api documentation and service must be the worst documented and build API I have ever seen from a corporate.

1. The developer website is a mess. A total mess. You can barely find the API type you are looking for.

2. When you get the API and download the documentation, the files, .pdf etc is still a mess. Pages long that most are craps.

3. Each request returns Status Code 200. Even if it is an error. This blew my mind.

4. Each request, based on error type or based on tracking activity returns different JSON schema.

For example, the JSON Schema for a shipment in transit is different from JSON schema for a shipment that has been delivered. A shipment that has been returned, a shipment that required signature etc. They are different from each other.

5. And the worst. They do not provide with test tracking codes. I have found some on internet, but they do not work in development and production environment.

rant/!rant

So I just started working at the beginning of January and I have no fucking clue about anything especially Web development.
But now I have a week to figure out how in the world I am going set up a workflow for some secretaries so that the higher ups get a printed coupon with a password on it, so they can log into our WLAN via a captive portal that I also need to set up.
I am thinking about a website that takes a list of names and settings (probably excel or smt) passes them to the WiFi management softwares API and then generates some PDF file for download that just needs to get printed.
Did I mention that I have no Dev tools (I have notepad, yeah the one without ++), no test environment, no prior experience and no clue how to do it?
But somehow I love this challenge and am glad that my colleagues don't send me to get coffee but let me work.
Am I insane?

Over the last few weeks, I've containerised the last of our "legacy" stacks, put together a working proof of concept in a mixture of DynamoDB and K8s (i.e. no servers to maintain directly), passing all our integration tests for said stack, and performed a full cost analysis with current & predicted traffic to demonstrate long term server costs can be less than half of what they are now on standard pricing (even less with reserved pricing). Documented all the above, pulled in the relevant higher ups to discuss further resources moving forward, etc. That as well as dealing with the normal day to day crud of batting the support department out the way (no, the reason Bob's API call isn't working is because he's using his password as the API key, that's not a bug, etc. etc.) and telling the sales department that no, we can't bolt a feature on by tomorrow that lets users log in via facial recognition, and that'd be a stupid idea anyway. Oh, and tracking down / fixing a particularly nasty but weird occasional bug we were getting (race hazards, gotta love 'em.)

Pretty pleased with that work, but hey, that's just my normal job - I enjoy it, and I like to think I do good work.

In the same timeframe, the other senior dev & de-facto lead when I'm not around, has... "researched" a single other authentication API we were considering using, and come to the conclusion that he doesn't want to use it, as it's a bit tricky. Meanwhile passed all the support stuff and dev stuff onto others, as he's been very busy with the above.

His full research amounts to a paragraph which, in summary, says "I'm not sure about this OAuth thing they mention."

Ok, fine, he works slowly, but whatever, not my problem. Recently however, I learn that he's paid *more than I am*. I mean... I'm not paid poorly, if anything rather above market rate for the area, so it's not like I could easily find more money elsewhere - but damn, that's galling all the same.

>new feature in application uses external API
>external API has unreliable response times, requires polling to get results, no way to set up webhooks or whatever
>tech lead proposes asynchronous system which will queue up user requests for processing and use websockets to warn frontend clients of finished query results
>higher ups say it will take too much time, make tech lead cut back in scale and treat external API like a regular synchronous REST API
>team dutifully implements feature within the constraints of the new smaller scope
>higher ups try out the feature, find the usage experience is extremely shitty, but don't back down, they only let tech lead scale back to original scope in small increments that still allow new problems to show up
>feature takes up same time or longer, but with more damage to the mental health of developers

At least I'm not in that team

Remember when that fuckin api *cough*hankerrank api*cough* you REALLY REALLY need(ed) just ups and stops working...