Racing simulator experts know that the computer always uses the ideal trajectory, and it does not make any mistakes, but this is only in the game. What about the real life?
A couple years ago, I worked together with Ken Thompson on the interactive graphics language that was developed by Gerard Holzman in Bell Labs. I was typing quicker, therefore, I sat at the keypad, and Ken stood behind me. We worked quickly and when the compiler gave out an error, I started reflexively digging in a problem, studying the call stack, program output and launching a debugger, and so on. But Ken simply was standing nearby and thinking, ignoring me and a code, which we just wrote. Soon I noticed regularity that Ken often understood the problem faster than me and was saying, “I know, what is going on”. Usually, he was right. I understood that Ken built the mental model of a code, and when something was broken, it was the error in this model. He was thinking of how this problem could arise, so he explained what was wrong with model, or where our code could mirror this model incorrectly.
After I had worked for years in small web agencies, I decided to try something new and got a job in a rather big (3500 employees) IT-company 5 months ago. What I have seen at my new working place, turned out to be far from my expectations. At numerous requests of my friends, I want to share some observations about the differences between big and small IT-companies. As it is known, tastes differ. This article is not the ultimate truth; this is what I have faced and what was important for me.
It is easy to imagine the spheres in which one can use the knowledge of how to implicitly share some kind of information brought into the artifacts of mass culture. Today, there is no any practical need in hiding messages in the music. These are only pleasant bonuses for the particularly ardent fans of bands. Interlacing of messages into the songs’ words and changing colors in the design drawings of music albums are not taken into consideration here.
Many people believe that software testing is the search for the bugs. Sometimes, I say to testers, "Do not try to find as many errors as possible, try to miss as less as possible!” and they do not understand me. What's the difference?
There is a huge difference! In this article I want to tell you about that difference, and what tools you need to use for a useful troubleshooting.
What is troubleshooting?
Most people know about the difference between Firefox and Internet Explorer in the Internet industry. We also know what FTW is and what the difference is between ASP, PHP and RoR. At least we know what the difference is.
If you meet a businessman who has not ever heard about Digg, Google Apps or the Freemium, you'll be very surprised. Is not it right?
Now a lot of people write about what would happen if a web-developer decides to become a freelancer. Also, they write about some challenges that the freelancer may encounter, namely, they are hunting for new orders at first, then dealing with the influx of work, and finally overcoming own laziness. However, I still have not seen any article about what would happen if the freelancer decides to stop freelancing work that consists of the orders, prepayments, hunt for new customers, and so on.
Do I have the right to write such an article, perhaps you will decide, but I have an excuse to say that after about a year or more working as the web-developer, I started working as the freelancer on the vast web-market and was working there nearly two and a half years.
I am sick of these topical articles on how to improve performance, motivation, and other nonsense. Why do people write them? To help those who are confused about yourself or for those who cannot concentrate. I do not think so.
The modern life dictates that everything should be done quickly, in order to achieve maximum efficiency. Certainly, you need to be very successful. You need to move to the goal every day, every hour, and every minute. Leaving all the unnecessary things behind and throwing all efforts to achieve a result. Otherwise there is no point in living.
Life is a piece of crap. At least, most people think in that way with whom I had an occasion to talk. They constantly have been complaining about their work, broken relationships, and children who do not want to become as their parents want to see them. The life for these people is an endless carousel of frustrations, anxieties and unfulfilled hopes. They get up early in the morning with a headache, and then they have a couple of cups of coffee and go to work in the zombie mood. They hate their jobs and feel that their wok is meaningless and useless. But, despite this, they continue with the tenacity of lemmings do their job, day after day, year after year. They have their own way through life, hoping that they will have a good life after they retire. Well, it's all garbage. When you are fifty, you are so tired of this life that your only wish will be to lie down and die. Also, your health will not be that good anymore, because you have spent it, doing nonsense. So, when you retire, you do not go to Africa to hunt lions, because the sun is bad for your pressure. You also do not go to the North Pole, because you have arthritis and cold will not be the best cure for it. South Pole will not be good either, because you dislike penguins, which is not surprising, as you worked for 30 years as a system administrator. So what do you do? You get a nice trip to the country house and have the cozy TV company in the evening, that's what you get. After living 30 years in a constant battle with yourself, you simply will not have extra energy to get your ass off the couch.
Today, I am going to talk about how you can hide the “spare" assembler commands in the regular code. This method is useful for complexity of disassembling the code, especially if the generation of "hidden" commands to automate. Tools: debugger - OllyDbg.