Making graphs for your scientific paper

I am writing a paper that compares a couple of algorithms. My prof told me to write a simulation and to make some graphs. As this is not the first time I am doing that, I wanted to describe the process. The first was painful. This time I almost enjoyed it.

The first time went like this. 

1. Implement a simulation. There is a main class that drives the simulation and then there are specific algorithms. So, the main class calls each algorithm and the algorithm prints out the results.
2. Redirect the results into a file. 
3. Open the file in your editor of choice, which is clearly VIM. Manually combine columns into a single file that gnuplot can understand.
4. Open gnuplot and draw a graph. Save the graph in PNG and embed in a paper.

Now, I send the paper to my supervisor and gets a lot of rejects. Dataset should be larger, samples should be smaller, parameters should be different, etc. So, it is back to the same 4 easy steps.Rinse and repeat. And repeat, and repeat...

The process should be automatic. This is how I did it this time.

Gnuplot should get data files that have columns. 




 

To eliminate step #3, this file should be output by simulation directly. The problem is that each column is generated by a different algorithm, which are called sequentially by the code. The way to do that is counter intuitive in a way, the results have to be gathered by the main class, which will then output them all together. 

 This is a code snippet. Gathering of results are highlighted in yellow. Notice that not only results are gathered but also the titles of the columns are fed from the specific algorithms to the main. This is absolutely required, as each line in gnuplot should be labeled and I don't want to add those labels afterwards.

The next step is to automate graph generation. This is done by outputting a gnuplot script (outlined in blue). So, now simulation runs, outputs data into file of all algorithms, outputs gnuplot script. Gnuplot then generates graph automatically.

The best part is that the code generates two graphs in a single run (two calls to "OutputGnuplot"). I can easily generate another one, as all the data is in one place.

As I said. Almost enjoyed it.

"Agile is fun, waterfall is not fun" ? Meh...

I've got this comment for one of my posts: "Agile is fun, Waterfall is not fun". This was such as terrific comment that I just had to respond with a post! It is terrific because: it is so wrong and so common at the same time!! It is marvelous!!!

Many people think that agile is fun, while waterfall has a reputation of previous century technology. All the cool kids are doing agile. Old timers are doing waterfall. Boooooring. 

What do you want to be? Don't answer, this is not a real question. The real question though: Is Agile really more fun than Waterfall? 

All things can be proved with fabricated example, so bare with me.  

You are looking for a job and have two options. "CoolGuys" company is developing messenger application for mobile. They have no customers, the idea is rather stupid in 2014, but they are working in Scrum. They have a certified Scrum master, stand-up daily meetings, estimation poker and all the Scrum stuff. Your second option is with "JustHereToWork" company. Most of the development team is over 35 (read old timers). Most of them are smart, apart from a few guys who are extremely smart. I mean Turing award or world-wide name smart. They have a great idea for a product, that is already becoming a major hit and they have the ability to make it happen. They also work in waterfall. Which company is more fun to work at? I would say the second. 

Let's say that the product is important and is a large part of a "fun" at work. What else?

Continuing with the example, you find a couple of friends that have worked at each of those companies and call them. Bill, the guy that worked at "CoolGuys", says that behind the "we are cool guys having fun" facade, the interpersonal relationships are very bad there. People don't help one to another and most of them don't really like one another. Even though the company organizes pizza evenings and game nights, the guys still hate one another guts and fighting over everything. Then you call the second friend, Joe, that worked in "JustHereToWork" company. The guy moved to another city and thus, had to leave the work place. For more than an hour he talked about the great guys at his previous company and how they have met at bar or on a weekend. They are still friends and even some folks has come to visit him in his new home. Hmmmmm. 

So, "fun" is more related to people than to development method. What else?

You call Bill once more, as you think that maybe the interpersonal problems were caused by Bill's personality. After all, you are such a great girl/guy, for sure you will get along with all the folks there. Bill explains to you that even though he had 10 years of experience working at ICQ/MSN messenger/Yahoo messenger and bunch of other programs, still his responsibility at the company was very limited. This is not only him, as all other guys had to go through loops to get any code into a product. This is even before the company have customers. Now, this is a bummer, as you like having a lot of stuff to work on. You call Joe to check the situation at "JustHereToWork" company. For sure, with all the smart guys there Joe was in charge of a single class method. Surprisingly, Joe tells you that he was a master of his domain. He has a lot of responsibilities there and was the final authority in a number of things. 

OK. Responsibility is another "fun" thing at work. Is there anything else?

When you go to sleep, you suddenly remember how Bill complained about being stuck at the same place and nowhere to advance. Apparently his boss didn't trust anyone and the company executives didn't think that that employees development is a good thing. Actually, they didn't think about it at all. Next day you call Joe and ask him about development path in his previous company. What a mistake that was... Joe talked for half an hour without stopping about different options, mentioned discussions with his manager and company policy. His final words were: "you only have to choose what you want to do!" 

This is not a fun thing to be stuck at one place, so lets add development plan to something that is fun at work. Anything else?

Is it fun to work on "yet another messenger"? Is it fun to work on a product that will be forgotten sooner than the company ships third version? Isn't it more fun to work on something that changes the world? If it changes the world for a better, this is even more fun! 

Impact is (yet) another item on my list of fun things. I don't know about you, but I want to change the world with my work. This is what I call fun. 

Is there anything else? Yep. Is development process part of the list? Nope.

The race is over! The fastest development process is ... not Agile!

If I had a dollar for every time somebody says: "We have to deliver fast, lets go Agile", I would have about 20$ already. This does not sound like much, but this is the REAL number of times I have heard it. Moreover, nobody has ever said: "We have to deliver fast! Lets do good old waterfall !!!"

Well, are all those people wrong? YES! 

The results just came in. Agile process is not the fastest development process. Who come in first you ask? Waterfall.

How come? It is actually simple. Lets say that you have 100 boxes that you have to move to another place. You have a team of 10 completely identical people at your disposal. They are identical just to make the calculations easier, not because they are cloned or something like that. Every person can move one box in one minute.

How agile development, sorry, box moving looks like. 

• Short sync and planning (1 minute): you take this box, you take this box and etc. 
• Move the box - 1 minute.
• Retrospect (1 minute): how was your moving? Any insights?
• Repeat until all boxes moved. 

There will be 10 such iterations, 3 minutes each. In total this will make 30 minutes. 

Now, lets do waterfall. 

• Long planning (10 minutes): you take those 10 boxes, you take those 10 boxes and etc. 
• Move the boxes - 10 minutes.
• Retrospect - 1 minute.

Total time: 21 minutes. 

Now, if you think that this example is not fair, then you are right. 

Usually, agile will spend much more time shuffling already moved boxes as they are not in the right place. Yep, agile processes excel at re-work. Since the goal is to make the minimal working version at each iteration, many times it is not the optimal one. Then it has to be re-structured and re-done. This will add more time, but the process is enjoyable and team is having a great time at all those stand-up meetings. 

Why do agile then? 

The answer is simple: because you want to be agile (this is me trying to be funny). Notice: not fast, agile. Lets say that 12 minutes after the start product manager decided that boxes have to be moved to a different location. 

• Agile process can adjust on the very next iteration, i.e. every 3 minutes. Total time will be: 12 minutes (before the change) + 30 minutes (to move the remaining boxes and those that were already moved) = 42 minutes
• With waterfall you will have to re-start the entire process when it ends. This is basically because there is no process to stop the waterfall. Total time will be: 21 minutes (to complete the first iteration) + 20 minutes (retrospect and blaming one another) + 21 minutes (move the boxes to a new location) = 62 minutes.

Sometimes, being agile actually gets you faster to the ending point. This happens when requirements keep on changing or when you are running in zig-zags under fire. 

Developers Guide: Why do we need Product Manager?

If you are a developer, I know what you are thinking: "We don't need them! They only make noise, create meetings and do no work!"

Well, you are wrong. They do make a lot of noise, create meetings and do not code. BUT, we do need them. 

First some (mucho little) background knowledge about Product Manager job, whom I will call PM in this piece. There are two kinds and two types. 

type \ kind	Good	Bad
Inbound
Outbound

While everybody can tell Good from Bad, Inbound and Outbound require explanation. 

Inbound PM usually comes from development. He is a technical guy and feels at home with the architecture. Thus, the prefers to define to engineering how the product looks, behaves, what it does, how the features work and how many concurrent users it should support. Such PM works closely with the engineering and writes detailed specs from which architecture and test strategy/plans are derived. Writing those specs is a LOT of work! Microsoft has come with some magic number of 1 PM per 3 Developers. However, their PM's are also program managers, so you could get by with 1 PM per 5-6 developers. 

Outbound PM can be recognized by the spec he provides. If the spec is an Excel file with one-liner per feature, then this is an outbound PM. Such PMs work with marketing, sales, professional services and customers. They concentrate all the input coming from the outside, analyze it and digest in PRD. Clearly one person writing such specs can provide a work for gazillion of engineers. Just write: time machine and teleportation. Done. BUT, gathering all this input, analyzing and deciding what is important and what is just a junk also a LOT of work. Still there is no need for 1:5 ratio, it easily can be 1:20 (depending on the project). 

Clearly, this is a simplification, as just like people are not pure optimists and pessimists, PMs cannot be clearly cut into inbound vs. outbound categories. Most of the PMs are somewhere in between with some strong tendency towards one of the categories. This tendency defines the focus, effort, amount of invested time and consequently, deliverable content. In that order. Here actually lies a problem with PMs and this is the main distinction from optimist vs. pessimist separation. Wake up, this is the important part: 

I (just like 99.999% of the people) don't need to decide whether I am an optimist of a pessimist. It does not matter to me and I don't care. PM, on the other hand, has to decide what type of PM he/she wants to be: inbound or outbound. He cannot be both and he cannot move from one side to another. Just like I cannot be both optimist and pessimist. 

The problem is that some PMs do not decide, so they belong to the new category: "Not decided yet". 

This leads to the following table and I will fill it in as well. There are no "pros" in "Bad" column for obvious reasons. 

type \ kind	Good	Bad
Inbound	Pro: the product advances really good and fast, and the product is very consistent to the users. Cons: the users might not buy the product as it does not solve their needs	Developers ignore those PMs, but they keep on trying to define low-level things, there are constant clashes between PM and Dev.
Not decided yet	PM is able to pull a little bit of everything. If Dev Manager is good and can do Inbound work (or at least part of it), then things will work out. If Dev Manager is not good, then PM will quit and the fate of the project will depend on the next PM.	There is no direction and no customers. PM and developers  both clash one with another on daily basis (when PM decides to be inbound) and blame one another.
Outbound	Pro: the product does what customers want and solves real problems. Cons: The product looks like a patch-work. There are no conventions in UI, names or behavior. Each developer decides on something else and it shows.	Nobody wants the product and it also does not look good. PM and developers blame one another.

To summarize this already long post: you have to decide whether to go with an affair or a spouse, and then do your best there. The indecision period is very risky.  

Career Advice: Stop Whining and Do Your Drill

"I feel stuck man. Not sure what potential I have at my current job. I just not happy here. People are great, but something is missing..." 

This is not the first I hear that, so I know exactly what to do. Usually I slap the guy, but this one looks like he could slap be back, so I smoothly move to the verbal part:

"Stop Whining and do your drill"

We, read as "software engineers", were trained to build products. Why your career is different? Do you know how to build a product? If yes, then you know how to build a career. Before I give you a recipe there is one catch. 

Career is not only climbing a corporate ladder. I have decided a long time ago that I want to work only on interesting stuff and made it a goal. Lately, I have noticed that I am good at building a new stuff, so I want to concentrate on that. One of my ex-co-workers decided that he wants to be happy and be home at 17:00. It can be anything really, not only "become a VP".

Now the plan:

1. Define where you want to be in 15-20 years. 
2. Divide it into 3 year chunks. 
3. Think how you get to the first milestone.
4. Get to work.

Oh, you don't know where you want to be in 15-20 years? Well, there is a different method then. Designed especially for guys that don't know what they want in a long-run: Agile Development. How does it look in Agile? Simple.

1. Define your goals for the coming 3 months. This should be easy as the goals are simple. They don't even have to be career/development goals. You can say: "I want to learn something new", "I want to feel that I've done something" or "I want to start some new project". It can be anything that you can somehow know whether it happened or not. I suggest to record your current state when you do that for comparison. You should also think about the goals and how to achieve them.
2. After 3 months check where you are. If you have achieved your goals, then return to step #1.
3. If after 6-9 months you are still unhappy, then you have to seriously re-evaluate your goals. There is something wrong with them or with how you achieve them. 
4. If after 9-12 months you are still unhappy despite all the above. Start looking for new options. It is not worth it. 
5. If after 2 years you are still unhappy and at the same place, come to me and I will slap you. 

Good Luck!

As a side note, the company I work for (EMC) has a quarterly goals system. It is mandatory, like in many other places. This system actually can be used for the agile method. It also will give you a feeling of purpose doing it.

Wasted Time

Today I have defined a gated check-in build in TFS.

In other words, when a developer check-ins his code, the code is built and if it passes correctly the code is checked into repository. We thought about doing something like that in my previous gig, but it was estimated as a couple of months work and was dropped. 

We did not have time to sharpen the saw. We were busy fixing broken builds.

Today I did it in TFS. I had TFS server running with source control. I had a sample code in C#. I had a build agent installed on another machine and file share server running. Nothing was installed on file server, it was plain Windows 2012 server.

• Hmm, lets define a build for the path in version control. 
• Pick "gated check-in" build option.
• Few more options, like retention policy.
• There is an option of where to put build artifacts. I need a new share on the file server.
• Go to the file server. Define a new share. 
• Back to the build configuration and put the new share. 
• Save. 
• Change a code and commit. 
• Open a panel and see the build progress. 
• Hmm, progress is printed...
• Looking good...
• There are 3 warnings...
• Need to fix them later...
• Done.

Look at the clock. 10 minutes passed.

I will say that again: the entire process took 10 minutes.

God Damn!!!!

Why your VP is just like a Godfather

Anything."

Tempting. Very tempting. It is like having a school bully to owe you a favor. Who would say "no" to you now? You have the biggest stick now! "You don't cooperate with me? I will talk to my VP!"

What people do not understand is that asking VP to solve your problems is like asking Godfather for a help. There are strings attached. More often in the end, you will wish to rewind the time to stay with your original problem.
You have found an unbelievable deal on iPad in your local store! You run there and buy one. You run home, unpack it and it does not work! The iPad does not work. Naturally, you want your money back. Do you go to the local "Godfather"?

I know what you are thinking: "But, my VP is such a nice guy".Well...

1. When you present your case to the VP, do you know what he will say? The response might surprise you and not necessary for the good. What if he listens to you and to the other side, and decides that you are the one who is wrong? What if the Godfather decides that you don't get your money back? Are you prepared for this? What if the shop owner is his brother-in-law and you will have to pay him even more for the trouble?
   This leads to the second point:
2. What do you do if you do not like the answer: "You don't get your money back!"
   What now? Do you go to police or a bigger boss (Senior VP)? Do you want to go to SVP with this problem? CAN you go to police with this problem?
3. If you ask for decision, you comply with the decision. Today you went to VP and it worked. You have got what you've asked for. Next week, somebody else will ask VP to get something from you, instead of talking to you. Do you want this to happen? 
4. You have asked him for a favor and now you owe him a favor. So, you have got your money back. All is good, until he asks you for a little favor: "You work in downtown, right? Please take this package to my friend there". Do you say no now? 
5. Every ask for VP's help, it drains your power both in VP eyes and in eyes of others. Going "up" for a help, means that you cannot solve this issue alone.
   You draw a limit of your abilities by yourself!
   Next time, you will get less responsibilities, as everyone knows that you cannot solve such problems alone.
6. You grow when you overcome obstacles. It has to be hard. If there is no pain, there is no gain. Bringing help reduces the pain, but it also takes away the gain.
7. This is no fun.
   I loved playing Doom. It was so much fun. Up to a point where I've got to a level that I could not complete. I've wiped the level clean, but the boss. For some reason, I just could not kill them. Time after time, I've tried and failed. Tried and failed, tried and failed.
   Then, I've found a cheat for immortality. I have passed the level. The fun has passed as well. I don't think that I have ever completed Doom. It is no fun playing with cheats.

Not everything is bad about upper management thought. There are also good things about consulting with your VP:

• get your problems solved quick
• see higher-level view of the product
• get to know more VPs, as usually they come in packs :) 
• more exposure
• feel more important

It is up for you to decide what to chose. Me? I always ask myself: "What would Keyser Soze do?"
If you look for me, I am busy solving my problems by myself...

Why Should Customers Buy Your Product?

In my new product, we are still trying to define the killer feature of the product. We are getting closer with a lot of sweat, shouting, cookies and coffee.

The question is "why should customers buy our product and not competitors?"

The answer, is not surprisingly: it depends.
Our product manager wants the product to do stuff that competition do not do. The reason they didn't implement those features is because they are physically impossible. Let's just say that one of them is a time machine.

I don't like being just a negative guy and saying people, even product managers, that this is impossible. I want to do constructive, so I've compiled a list of things that we can do which will be our IP. Or in other words, those are the reasons customers will buy from us instead of the competition.

1. Algorithm, a.k.a. Idea. This is the most common thing people are looking for. Every geek I've talked about doing startup invariably talks about "having an idea". If there is no idea, there is no product. Google's page rank is a great example. Another great example is ...
   It talks to our engineering hearts, but even for Google it take time to come up with their second great idea. This would be, ehhh, news or maybe, glass? Why this IP type is rare? Few reasons:
   • There is only one "the best idea in the world" idea in the world. It is hard to find one. It is like winning a world championship.
   • In many cases, there is no such thing as "best idea". Is there a best software developer? Nope. Because they cannot be compared. How do you compare web developers and assembly nerd? How do you compare architect of operating system with a coder that writes optimized code (John Carmack)? You can't. There is no such things as best developer! Even though, TopCoder might disagree...
   • Most of the problems are not solved by one idea or an algorithm. Usually things are much more complex than that. Google could fail even with page rank. They had to build a huge datacenter, invent Map-Reduce, spread things around the world, build indexing engine, best crawler, hire enough good people, resist pressure from investors and etc.
   • Nobody is a world champion forever. Everyone will bite a dust in the end. The same is with (many) algorithms. There always will be a better one. If all you count on is the best algorithm, you will fail when the next "best algorithm" appears.
2. Expensive Hardware or Software. Not every company can build a satellite, a tank or a ship. Neither every company can build a cloud or operating system. This is not only an engineering undertaking, but also a huge investment that only a few companies can afford. As a big company, we can afford to target big and expensive market, this could be our salient feature.
3. Trust. Little trust is required to sell 1$ application to users, but how about 1M$ system? Will "Bank of America" even let some small company to present their product? Not very likely. I have been in storage startups before. It is damn hard to make a customer not only to trust your product with their data, but also to pay you for this. Microsoft, on the other hand, have bank's trust already. They do not have to deal with this sort of stuff.
4. Get dirty. Do a stuff that others are not willing to do or simply offload the stuff others don't want to do. There is plenty of stuff that is not sexy, but it needs to be done and people are willing to pay for it. This is why data conversion companies are huge business, why there are some many project outsourcing companies and why IT is moving to the cloud. This is "buying free time with money" for IT guys.
   
   • Convert data from one format to another.
   • Connect to some old database.
   • Upgrade existing software to the new technology.
   • Support many different types of printers or custom made hardware.
   • Run Exchange servers or a version control. 
   • Buy licenses for Word and run file servers.
5. Just works. This is nothing magical about this type of software. It just works. It has been around, probably version 7 or 11. It has all the right functionality and nice UI. It works fast, good and users love it. It is a result of years of development, feedback of many users, many versions, bug fixes and incremental development. Those years and efforts are the IP of "just works".

What is the right sort of IP for us? How will we succeed?

I don't know yet, but I do know what is success...

5 most annoying things about changing expertise field

I've moved from storage to cyber security. Quite a move. Completely different field. I've been working in storage industry for about 12 years. Eyal has come to me saying "I'm doing this startup, join me". So, I've asked what it was about and he said Storage. This was 2000 and the startup was SANRAD. iSCSI was only beginning to happen and we were to ride its wave. Well, few years later iSCSI wave did not flip over FC boat, but I was working in storage ever since with a single exception.

I've been thinking bad things about security for a longer time. I basically, find it weird that people try to break other systems and other people defend those systems, when there are so many things yet to be done. We don't even have a good AI! No augmented reality! Damn, to play a video from your iPhone on SmartTV is not a simple task! So, the time being spend on fighting one another is seems like a such a huge waste. 

Apparently, it is a big business now. I've got an offer to start a product and a group from ground up. This is not an offer I can turn down. So, here I am, working on cyber security project. In the meanwhile, I've compiled a list of 5 most annoying thing when you change an expertise:

1. It feels weird not knowing stuff. Its like you are a fresh graduate all over again. I look around me and everybody looks much more experienced and knowledgeable than me (well, I have it all the time). It is weird instead of answering questions, ask them all the time about everything. Ask and translate even the simplest things: what is APT? Everybody talks about it, I have no idea what it it. It is exciting! This feeling was already worth the change!
2. Not knowing the field. I actually not talking about the "things" of the trade, like what is maleware, how it penetrates, what are the stages of attack, what is APT and etc. Those are easy to pick up. The problem is the Industry. What is the history and what are the hot trends. What are promising products and what products are doomed because the idea is dumb. I have a good feeling and strong opinions in storage industry, but I have no idea in cyber security. This is critical and a major obstacle actually, as we are trying to decide on the killer feature of the product and all I can add to discussion is more question marks.
3. Second thoughts. What if I've made a mistake of changing a field? Why didn't I stick to what I know the best? Why not make stay in the "expert mode"? There are pros and cons of course, and the main mean to relax is the thought that I can always get back. There are still doubts.
4. Phony experts. The real problem is not the phony experts, but rather that I can't tell the phony from real ones. Both sounds the same with the same acronyms, both talk with confidence, both have years of experience. However, one is talking nonsense while other is talking wisdom. Who is who? 
5. Crawling instead of flying. Learning is hard. I am actually waxed out after 5-6 hours of learning new stuff. I look at what I have achieved last week and it seems like nothing. I've learned a couple of things. Then I've found out that I've misunderstood one thing, so I had to re-learn it. In the same time, I am working very short hours, because I can't get any more new stuff in my brain. It is annoying! 

 Overall, it is really exciting :)  And I promise to write about it! 

What's in a title?

Senior, Principle, SDE II, Consultant and etc.
Many big companies have a technical career ladder usually with something like:

1. Junior Developer
2. Developer
3. Semi-Senior Developer
4. Senior Developer
5. Principle Developer
6. Senior Principle Developer
7. Partner Developer
8. ...
9. Distinguished Engineer 
10. Technical Fellow

Some companies, like Microsoft, get obsessed with those titles. In every major project you have to have a Principle Developer. Otherwise, how those simple Senior Developers could do anything?
You want to move to the next level? You have to prove that you are worthy. This gets into a many waste days hours discussing how this guys is a Senior and that guy is Principle, while this one is better.

EMC, my current employer, has a better attitude towards levels. It basically boils down to: "its not your business!"
In other words, nobody knows and pays much attention to the title/level. Why it is better? Because titles are basically like belts in martial arts.

The belt signifies that its owner trained for at least a certain amount of time and that he knows a specific moves. It does not mean that brown belt will always kick ass of green belt!
On average, this is probably true. In other words, if you take 100 green belts and 100 brown belts, pair them one with another, then most of the matches will be won by brown belts. It is still possible that the overall winner will be a green belt! Especially if this is previous boxing champ.

The point is that having a title does not make the person into a kick-ass developer. There might be lower-titled developers who are much more capable, but simply younger and didn't advance enough yet.

Mark All As Read

I am a fan of “Zero Inbox” system. It means that my Outlook, Gmail and Hotmail (each one is used for different purposes) all stand on zero emails in Inbox.

Well, apart from Gmail which is based on search so the emails are just left there to rot.

Zero inbox means less worries for me, less things to remember, better response time for other people and less black pixels on my screen. I am a happy user.

There was something that bothered and nagged me though. Google Reader. I was struggling to get it under 100 unread messages and lost the battle most of the time. I always wondered:

What am I missing there? Maybe the next unread item is the most interesting one? Reader always dragged my attention to it, as there are always more stuff to read and (probably to learn).

Well, not anymore! I’ve seen the future and it is called” Mark All As Read” button

There is always interesting stuff to read out there. However, the good part is that really interesting pieces will be linked, commented, re-linked and flamed all over the Internet. It is REALLY hard to miss them. Should I worry then that one of the “marked as read” items is a ground-breaking, world-changing, socks-blowing one?

NOPE.

I have a zero unread items in Google Reader now and I am happy.

Taste Matters!

I was listening to the latest “This Developers Life” podcast called Taste and it stroke a chord with me.

I remember arguing whether appearance matters at work with some guy from my previous gigs. His point was that it should not matter, as the most important thing is one’s brain and ideas. Needless to say he looked like a bum.

Ultimately, he is right. Looks probably should not matter. It does not matter in two cases:

• email communication. The other guy might be flesh eating alien or even a girl. I don’t care.
• when your pal says: “This guy is genius! He sleeps in a garbage can, but he is brilliant!”

These two cases, you don’t care how the other person look like, in all other cases, however, you do care. 

While it is correct that well dressed person conveys a message, I think it is more important that sloppily dressed person not only does not transmits the same message, but he conveys a negative message. Being a bum is to tell your colleagues: “I don’t care about you. I can come with my pajamas, uncut fingernails and unwashed, but you STILL will listen to me!”

It is a very negative thing to say to your co-workers…

Civilized Programming Language

Code worked and stopped working after minor changes. All of the sudden a loop is not working anymore.

 1     while(cursor != NULL)
 2     {
 3         printk("mock_config_cache: checking %x\n", cursor);
 4         if (mock_compare_cache_devices((mock_cache_device_t*)cursor, new_cdev))
 5         {
 6             printk("mock_config_cache: Device already exists: %x\n", cursor);
 7             status = IOCMD_ERR_DEV_EXISTS;
 8             mock_free(new_cdev);
 9             break;
10         }
11 
12         cursor = cursor->next;
13 
14         if (cursor == cache_devices);
15         {
16             break;
17         }
18     }
19 

It should be easy, but this is a kernel code, so I’ve spent 1.5 hours to debug this code. Even if it weren’t a kernel code, it is not always easy to attach a debugger and step through the code. I’ve added a loop to print the linked list, which is basically the same code:

 1 /* DEB */
 2     cursor = cache_devices;
 3     while(cursor != NULL)
 4     {
 5         printk("Cursor: (%x), next: (%x), prev: (%x)\n", cursor, cursor->next, cursor->prev);
 6         cursor = cursor->next;
 7         if (cursor == cache_devices)
 8             break;
 9     }
10 

The same code, but this one is working!

Another coffee and I see the bug. Line #13 in the first code:

1        if (cursor == cache_devices);

Notice the “;” at the end of the line! DAMN! This is frustrating!

Now, the compiler should have told me something, as the IF statement does not even have a side-effects!

These days I have read an article by Andrei Alexandrescu (C++ template guru) called: “The case for D”, where he praised D language as a better C/C++. Naturally, I wondered if D would do better in the above bug:

 1 import std.stdio;
 2 
 3 void main()
 4 {
 5     writeln("hello world");
 6 
 7     int i=3;
 8     if (i == 3);
 9     {
10         writeln("another hello");
11     }
12 }

OK. Let’s see:

C:\Users\derbep\Documents\Code\DTest>dmd if_test.d




if_test.d(8): use '{ }' for an empty statement, not a ';'

Much much better! Advance to D! It is better!

Training went bad. Or good.

This is a picture of punch-a-sand-bag training session.

It actually felt good during the training and even after, despite discomfort, it feels good to commit to training.

Problem on the horizon

Phone rings. It is my friend Mor.

- Hi. We have a new startup thing going on. You have to join!

- What are you doing?

- Can’t tell yet. It is in a stealth mode.

- I have to sign NDA to know?

- Nope. We don’t tell anyone before they start working.

- (pause)… I see. Well, anyway, I’ve got the best job now. We are changing the world.

I forgot it a minute later. Few months later, an email:

“Hi,

We went to University together and I remember you as a good guy. I am founding a storage related startup and you have tons of experience. Why don’t you join us? “

It is flattering and all, but I can’t. I am busy improving the world with DirectAccess.

Alon: “We have a chair with your name on, when are you coming to use it?”

Me: “Thanks man! Not in a near future for sure.”

Then, it is Mor again:

- Hi, we still looking for people and your skills are required. Come talk to our VP of R&D.

- I am not looking, but I can hear the guy out. Chances that I will come are zero.

Then it is a previous company:

- We are growing and you should still remember the stuff. Come, you have a potential.

- I am not looking and I am good at my current place.

Then Mor’s company bites the dust. Then one of my previous bosses leaves the company:

- (Me): where are you going now?

- (Her): I am going to start a new project from scratch.

- (Me): what people are you looking for?

BAM!

Once I said it, I understood that something is wrong. It was me asking for position in another company. The thought actually crossed my mind. It never did before despite long hours, frustrations, disappointments and job offers. Now it did.

The good thing is that I know there is a problem and problems I can fix…

Learning by example

It is time for me to learn ASP.NET and AJAX.

Why ASP.NET? Because it is C# and it works well. Because there is a huge MS behind the technology. Because it works well and it is easy to get started with it (there is a Visual Studio Express). Because it is simple.

So to start I went to http://asp.net and started looking at the tutorials. It definitely helps, but you cannot learn programming by reading a book (or a web site). So I fired up VS and created an ASP.NET project.

The first question is whether to use MVC or WebForms:

Since I do believe Scott Hanselman and I am a freak of lower-level and finer control it is MVC for me.

The first steps feel fine, the integration with VS is great: there are actually “Create a view/model/controller” there! However, the problem began when I try to play with AJAX a little bit.

I have started with this tutorial and immediately ran into a problem: what should my partial page to inherit from? No matter what I have tried to do: either “compilation error” or the page “does not implement method” error.
In better cases, I get “unhandled exception”.

In the end, it turned out that when you want to use

Html.RenderPartial("ListContentView", Model);

Your “ListContentView” should be a partial view and not a regular view:

Otherwise, life is not good

Rewrite is pending

Recent new form PDC had nearly caused me a heart attack: MS drops Silverlight for web and bets on HTML5.

Few months ago when I was choosing a platform to write my app, Silverlight looked good:

• C# and .Net
• Easy to develop and debug.
• MS is backing it up, meaning that it will be widely used.
• Can be detached from the browser and made into a standalone application.

Even worse, detachable feature pushed me to develop a thick client to save the round trips to the server and improve performance.

 

Few months later, it does not look like a great idea anymore. Not only I have to re-write the app in HTML5/JavaScript, but I also have to re-architecture it to make it more decoupled. On the bright side, I plan to make it a learning experience and also to document the process in my blog to practice a discipline of posting and writing.

Getting back

I have not worked on my project for months. :(

Now, I am back. At the high point of release frenzy, but still I have an itch to scratch.

It feels good to be back…