Rolling my own ICMP client - I searched around on the Internet for a program named Loki. It was supposed to send traffic using ICMP. The idea is to hide stuff in there that firewalls ...
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?
We had a meeting scheduled this morning. The new guy was not at work when it started, so we had to reschedule. When the meeting did get under way, we were not sure how to get this guy's script running. So we phoned an expert. Actually it was just some other guy on our team who has experience with it.
So we got through most of the questions. I thought we had a plan. The team lead said another new guy would help out the guy writing the script. Script writer got real salty with that setup. At first he said the newer guy could just take over the job. Then he complained loudly that he had done a lot of work, and just needed some info to get his scripts to run.
Later my team lead and I wondered what the heck went on? We usually work as a team and pair up on tasks all the time. Personally I like it when someone else can take a piece of the pie and lighten my load. There is definitely something wrong going down. Might be that the guy is insecure. I think he has some reason to be. Obviously he needs assistance a lot of the time. We will see how this plays out.
Next there was a session scheduled to fix some data issues with our latest releases. It was a conference call with a lot of my teammates on it. So I tried to work on my stuff while the call was going on. Of courses a number of issues came up during the call where I was the only guy who knew how some data was being set. So I could only half-multitask. The call went on all morning.
In the afternoon I decided to cut lunch short to try to make my deadline. Things were going well. Then I realized the work I tried to squeeze in the morning was done wrong. Had to go back and fix that stuff. Deadline approaching. As I am getting near the home stretch of my task, my network connection goes down. Darn.
I reconnect but my database tool aborts. Luckily I always save all my work to a daily log. I just restarted my database tool, loaded up my log with all my commands, and picked right back up where I left off. What is the moral of this story? I think I had better pad my estimates to factor all these interruptions in there.
Thought I would actually have some fun with this task. Then I got the catch. I had to split up the work and assign some of it to another developer on the team. This other guy has hours to work on our project. And he needs some work. The reason I figured this was a setup was because I have worked with the guy before. He needs a lot of hand holding.
Now I don't mind helping out a junior developer or even a new developer. But the guy I needed to work with is supposed to be a senior guy. And he is not new any more. So the management folks figure with his help, we should be able to get things done more quickly. On paper that is fine. In reality, not so good.
So I carved out a little over 25% of the work to give to the other guy. He had some questions early on. I tried to explain the answers to him. The he went loose. When he got to the one piece that was a bit more complicated, he was lost. I had to spend a bunch of time going over it with him in detail. It
took a few sessions. But I think it got through.
The last part of the task was to roll up both our work into one package. It all needs to go out into one release. So I did what I would do if I were developing the work myself. I slowly added the other guy's stuff into mine one small piece at a time. And let's just say there was pain as I debugged the errors and got the stuff to work. How can I get out of this type of setup? Maybe that is the point. I got to figure out how to work in this challenging situation.
Now we have a new security policy at work. No home USB drives work in my computer. Damn. I requested a secure USB drive. My boss had to approve the purchase. I selected one with minimal capacity, so the cost would not be too high. The boss was apprehensive. He figured we have some backup systems available online to do the job.
Our company seems to have an enterprise version of Druva inSync available. It seems to back up your data to the cloud. The only experience I have with the product are the emails I get when the software has troubles with a backup. I tested the latest automated backup the software did. Was able to restore a file to my disk. Guess it works.
I played with the Druva client and added some more folders to get backed up every time it kicks off. It is around 2GB worth of data. Hopefully it works. I will have to make sure that I periodically check and test the backups. Cannot go along thinking everything is fine, only to discover that the thing is broke when I need to do a restore.
I got handed a bunch of database functions a while back by my customer. He told me to get them to work and deploy them. It was a rush job. I fixed some bugs and got the things to compile. Then I did a few tests and fixed some functional problems. Then I pushed them out.
Ever since then, problems have been coming up with the functions and I get pulled in to resolve them. The goal was to hand these functions over to another team to maintain. But the other team is busy and says they know nothing about the business behind the functions. Well neither did I…
This past Friday, somebody discovered that one of the output tables from the function was empty. The team who was supposed to assume control of the functions was called in to investigate. They had no clue what the problem was. So I got brought in to make sense of the discrepancy.
At first I just came up with the direct cause of the situation. The records in one source for the function did not match the records they are supposed to be lined up with. Therefore, nothing was output. That was not a sufficient answer.
Of course this was some type of emergency. The valid output was due to some testers a while back. As a work around, I pumped some test data into the output table to give the testers something to look at. Then I dug in to find what was wrong.
The source table with unmatched records was quite small, thousands of records instead of millions. So I tracked down what was the problem. Apparently it was loaded with some test data instead of the real deal. There you go. Problem solved. Now there was a reason that the real data could not be loaded in, but that is a whole other story for another day.
LinkedIn showed me the notification for the invite. I somehow got to the same profile again. The strange thing different was that the connections were up to 50. It took me a few weeks to get in touch with my network to get 50 connections. Hmm. Very strange. The real kicker was when I checked a week later. This recruiter had 500+ connections.
What was the reason? I thought maybe because it was a female that posted her picture. Because the sloppy profile did not warrant a connection. They also seemed to be shooting in the dark with the invites. Maybe they spammed 10k people, and got a quite 500 accepting in no time. What was the purpose? All I know is that I am not accepting the invite. Why would I want to be connected with this stranger? No apparent benefit to me. Still an interesting rising star phenomenon at LinkedIn.