Backtrack Linux - Backtrack is a Linux distribution based off Ubuntu. It is used for penetration testing and forensics. The distro was a combination of WHAX and Auditor. It...
One of the questions they asked was how old my roof was. I had no idea really. I said it was at least 13 years old. But I did not know the actual age. The rep I was talking with got snippy with me, trying to force me to answer the question. At that point I gave my best guess. But they had already lost the sale.
I did continue on just to see what their end quote was going to be. Turns out it is higher than what I am paying now. So rude customer rep plus higher prices? Nope. Lesson learned is to make sure you know who the customer is, and treat them with respect. Otherwise you are going to keep losing the sale.
I work in the back end on my current project. It is a big database reporting project. My role is to provide the structure for new tables, write code to load those tables, and sometimes write the code to create database views. You would think that would be a straight forward job. Not so.
We have a lot of environments for our system. I work in a personal schema. We have another schema that I share with other developers. I consider that an integration schema. Then there is a separate schema for our internal testers. Plus one for our customer acceptance testers. We have a performance environment with a lot of data. Then there is production.
Recently there have been numerous problems deploying changes to these environments. The process is for me to check code into Clearcase source code control. Then I submit a ticket in ClearQuest to request deployment of my changes. After me there is a long chain of people involved before my changes get deployed in the assorted environments.
The deployment problems culminated in a specific delivery we failed three times in a row. Some managers tried to understand what in the world is going on. Their conclusion was that developers such as myself need to guarantee that the deployments are done correctly.
Now my life involves emails where somebody will run a massive deployment which includes my changes, produce a huge log or logs. Then they ask me if the deployment was done correctly. LOL wut? This got old the first time I had to pour through the logs. Not only that, I got to go to the target environment and actually check if my changes are in there.
I don’t want to spend my days doing quality assurance for a bunch of people who work on the deployments and just ask me if they got it right. I want to be doing development. Perhaps the right way to look at this is as an opportunity to automate the verification of the deployments. I figured we could use some kind of embedded versioning to identify what is deployed. Or I could buld some smarts into a script that checks for the specific changes made.
Right no we are getting towards the end of the cycle for this release. Internal testers are trying to verify the work we did. One tester is sort of a programmer. She does automated testing with some Java programs she writes. Recently she sent out an email asking what she should test. LOL wut? I responded and directed her towards the requirements. Seems simple enough.
Later the test called me up. She said she wanted to send me a document. And she wanted me to mark it up and tell her what to test. Nope. First of all that's not my job. And second of all, she should not just test what I tell her to do. She should test what is required of us for this release. I had to say that a couple times. Use the requirements document. It is there for a reason.
I ended the call with the tester by telling her if she does not have the requirements document, call up our requirements analyst. She does not bite. Very simple. I worry that our testers do not know what to test. I don't want to be part of the problem by leading them astray. For developers who encounter a software problem, I say use the source. For everyone else, use the requirements.
Very odd. Called the function in the same way. The template for the function matched the others we were using. The routine even spit out some debug messages which confirmed each of the select statements found a lot of records. Me and my buddy ran this thing a total of four times.
The clue that got me on track to a solution was that a table with the same name in another database schema kept getting more records. How was that possible? We were setting up the PostgreSQL search path explicitly at the top of the function. But by the end of the function, it seemed the search path was changed.
Initially I thought maybe some weirdness was going on because the DBAs recently dropped the tables and recreated the tables in our target schema. However that DDL should have been instantaneous. It was just suspicious because they cloned the tables from a prior schema (the one now getting all the data).
Finally I had an epiphany. Maybe our big routine was calling some helper functions that were doing something naughty. I searched for the word "perform" which is how we call subroutines. Bam. There was a helper function resetting the search path to the wrong database schema. That was a very tough bug indeed.
Eventually the databases come up. I verify that there are some formatting issues with the data. And there is a vast shortage of data. Next I am told to fix all the problems I found. The formatting changes were not too hard. The code is just a view on top of a table which acts as a calendar.
Next I tackle the lack of data problem. Well the underlying table is just missing a lot of rows. Can I just generate some new rows? Not easily. There are all kinds of weird values in this table. My boss asks if the problem is fixed yet. Nope. He asks if there is anyone who can help. Yeah - the person who created the underlying data.
I call up the developer. She is out and about. But she shares with me a grand secret. The method to generate the data is a function in the database. Jackpot. Of course the thing does not work. But at least I have a starting point.
So I drill down to see the table that drives her generation function. It requires only a couple key fields to make the whole process go. Figuring out those key fields is a major undertaking. I dig up a manual I have that is 15 years old. It helps me figuring out some seed data. I eventually write my own function to populate the key fields.
Eventually I got a pretty good function to generate the very low level data. Then I make some calls to the function that takes it up one level. Then I call my function to create a view to wrap the table and expose stuff in the correct format. My counts are close but not exact. I trace it down to some duplicate records. Luckily my view can filter out this duplicate nonsense.
It is past midnight when I am done. I email out the team, letting them know that I am sticking some new data in these tables. I also share that I found some dup data down in there. Get a message from my old boss. He told me the function I found is buggy, and does not work for future dates. FML.
Let's start with the CNO Engineering position. Pay tops out at $185k per year. There is a long list of requirements that cross over to the other jobs as well. You need to know C, C++, and Python programming languages. Should know TCP/IP networking. You must have experience with hard core programming such as kernel development and/or device drivers on Windows. You should know about reverse engineering and exploitation. And of course you need a Top Secret/SCI security clearance.
Next up is the Reverse Engineering position. Pay tops out at $190k per year. You should have the CNO Engineering position requirements. Plus you also should have experience developing for the Linux operating system. Also need to know about vulnerabilities.
The last job I want to talk about is the Software Reverse Engineering position. Pay tops out at $210k per year for this one. You need the CNO and Reverse Engineering skillsets. You should also know about architecture and be able to lead teams. You should know estimation and assessments. You should be able to work on proposals. You should be a subject matter expert. You should know assembly plus disassembling. Finally you got to have experience with firmware and embedded systems.
These all sound like jobs with excellent compensation. More than your average software development position. Got to have that security clearance. Plus there seems to be a theme of cyber security style skills needed. Time to crack the books, study up, and get a promotion.
Recently the project manager has been unhappy because trouble tickets are not being updated in our trouble ticket tracking system. After a while, I told our project manager that our team is really not using the tracking system at all. The team lead is managing this stuff on his own outside of the tracking system. Thus, there is conflict.
In theory, the tracking system is the way to go. But we just need everyone on board. The main guy that needs to follow the process is our team lead. Without his buy in, none of this is going to work. It will take a time to get all the older tickets sorted out in the tracking system. Unfortunately, thing are crazy at work. So who has the time for that?