Lotushints

To be honest, I have been meaning to write this post for years now, but never got around doing it. It took a recent incident (yes, let’s call it that) to remind me of this topic.

You know, priorities are funny. We are taught about priorities since our birth, yet, when we reach adult age, there are still people who seem totally incapable of understanding and handling priorities. The problem is that priorities are highly subjective and totally dependent on a person owning a task. That is why, you never ever let customers set priorities when reporting issues. For them, every issue is uber-important and thus has high priority. In reality, fixing a typo on an internal web page that only 1 person visits once per month can hardly be as important as let’s say, public application crashing, but that won’t stop people calling you up every 2 minutes and asking why the typo still remains.

But I understand all that. It is the same problem when you call admins that one of your specialized test servers is not working correctly and they don’t focus every inch of their attention to it. Understandable, they have more important work. What I don’t get is developers refusing to assign priorities to tasks assigned to them. There are so many benefits related to priorities. You get a better overview of which tasks need to be solved now and which can wait (and which can be thrown out and buried in the yard). You get better chance of hitting the deadline by not doing the tasks that are simply not important. You get more precise deadline. And you get to see if you have been “taking one for the team” a bit more than others and then complain to your boss.

But no, developers and project managers tend to leave priorities to default and then pretend that everything is equally important. And then you get developers painting a background of a textbox pink instead of churning away on important feature that will bring you profit and reputation. But hey, pink textboxes are important as well.

Sooner or later, your .NET web application project will gather helping hands and it is at that point that you will realize that deployment from Visual Studio is just not good enough. Yes, I know Microsoft did a grand job with their deployment scheme in Visual Studio, but let’s be honest. That only works if you are a single developer working on a single environment. As soon as you have to do regular integration, testing and production deployment, Visual Studio fails. More hands on a project only makes things worse. This is not a critique. Visual Studio is development tool, not a continuous integration tool.

So, to positively answer Joel’s second question, you will need some sort of build and deployment automation. Sure, you can use TFS, but that costs money and a supercomputer and let’s be frank, most small shops cannot afford it. So, what you will end up is either some open source CI tool like *cough*CruiseControl.Net*cough* or write your own scripts. Whatever you use, you will find yourself in a peril building and deploying .NET web application. Why? To publish .NET web application building it and copying it to server just won’t work. The easiest way to do it is to create a package and deploy it to your IIS using MSDeploy extension. So, how do you go about that?

To create a package execute following command line expression:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe MyWebApplication.csproj  /T:Package /P:Configuration=Release;PackageLocation="D:\path_to_my_project\bin\MyWebApplication.zip"

Obviously this is for 64-bit systems using .NET 4.0 and 4.5.x. You can package your app for 32-bit systems using same expression by just removing 64 from Framework64 part of MSBuild.exe path.

Now that you have your deployment project ready, check MyWebApplication.SetParameters.xml file located at D:\path_to_my_project\bin\ folder and change IIS web site and name, if needed. Also, connection strings used are in that file, so you need to pay attention, if everything is set accordingly. Finally, you are ready to deploy:

D:\path_to_my_application\bin\MyWebApplication.deploy.cmd /Y /m:http://myserver.mydomain.msft/MSDeployAgentService /u:MYSERVER\Administrator /p:supersecretpwd

There are ways to run deploy command file with another user, but that will take some server tweaking on your side. Anyway, after the command completes, you have a running application.

For a side project, I am working on in my spare time since college, I needed to create a splash screen. Finally. Eleven years after version 1.0 and we are thinking splash screen. Anyway, the splash screen must contain a custom image as a background, a progress bar to display how the initialization is progressing and something that will show every step of execution. Steps completed must be stacked on top of current step. Needless to say, application is written entirely in C++ using MFC framework and said splash screen, naturally, must be part of the application and not a separate project.

[Read the rest of this entry…]

When I started to learn how to develop web pages, CSS was in it’s beginnings. It was in state that CSS3 was two years ago where each browser interpreted it in it’s own way and half of the stuff didn’t work in one of available browsers. This meant that unless you had a huge desire to limit users to certain browsers, you ended up with a web page that looked something like this:

Anyway, as years progressed and we got better and better browsers and newer CSS standard, styling became easy to do. Suddenly you were not supposed to use tables for positioning or frames for layout any more and anyone still doing it was quickly out of business. Instead we started doing things with CSS.

Positioning in CSS is still a bit tricky and you have to learn about stuff like box model and why it didn’t work the same in all browsers. This is when two techniques developed. Either you positioned elements in-flow (from left to right and top to bottom) or you did it with absolute positioning.

Now, absolute positioning is not all that bad, provided it is used wisely. However, and this is my opinion, you should only absolutely position elements relatively on it’s container. Using absolute positioning to position everything breaks the flow of the document and can lead to lots more work once changes need to be applied to the layout.

I think user Bryan M. of StackOverflow sums it up nicely:

Software development is somewhat specific field. All you need to create an application is a computer, text editor, a compiler and some spare time and you are ready to go. And if you are developing in script language, you don’t even need a compiler. Hence, anybody with some spare time on their hands and an internet connection can learn how to code. Due to this, people get a false perception that creating good, working software is an easy thing to do. And this lead to the situation we have now, where numerous companies employ just about anyone that can copy & paste Hello World example from Wikipedia.

[Read the rest of this entry…]

When I was in high school, I preferred spending time programming than studying oh, let’s say geography. Even if I wasn’t programming or (let’s be frank) playing games, I still found numerous things I could do that were not studying. I even washed dishes after lunch. This of course resulted in not so stellar grades and lots of not so nice looks from my parents. Specially, since my sister was a total opposite. Always ready to study which of course resulted in good grades. However, the thing was, that when I got a B+, parents were pleased, whereas when my sister got a B+, they were nearly disappointed. A B+ for me was considered success (even though, I really needed a kick in my lazy behind) and for my sister, getting better grades, that was considered a failure. Unfair? Maybe. But that is what happens when you build up expectations.

Ever seen a movie that everybody highly recommended and was later disappointed? Or seen a movie that people said it was crap, but you still managed to enjoy it? Yeah, that’s what building up high expectations does. Same thing happens in every profession you can think of. And specially in software development. Ever seen a great developer not getting praised for a monstrous feature he implemented superbly and fast? Then on the other hand, you have seen a person that works way below standard getting the praise for job done? And I am not talking about good done. Yeah, that’s what I am talking about.

The thing is, there is no way to avoid this. People don’t do that on purpose. You see, once you set up high standards, sticking to those standards becomes a regular thing. This leads people to believe you are just doing your job. On the other hand, not doing work properly lowers expectations and any positive deviation will make people happy. You don’t want to be in that situation. Neither as manager nor a developer. If you work in any normal company, your boss still prefers developer that did great work from the one he just complimented. You see, what he did is called positive reinforcement. And he did it in hope of getting better results from developer that failed to do so in the past. This might work on good developers that got lost in the process. Good developers know that the praise was unjust and that they need to step up. Complimenting poor developers for poor job done just makes them believe they can get by with mediocre product.

And the same thing happens with customers and your products. Constantly delivering great product will spoil your customers which in turn will make them expecting great stuff from you at all times. Now, I am not saying you should deliver mediocre products as customers know good from bad and they really don’t like spending bucks on mediocre. What I am saying is that delivering great product must be your imperative at all times. There is nothing worse for your company’s reputation and wallet than releasing not so great version and hence, disappointing customers.

I started working at age of 19. At that point, my solution to a given task was to jump and code. Mostly because that was all I knew how to do. Partly, because I never had problems with writing loads of code fast. However, whenever I seemed to be near the solution of a given task, I noticed that my code is getting more and more complicated. Mostly to the point where I wasn’t able to actually solve the task in the way I thought I would. Or sometimes I was in the middle of the code, when someone decided to change the functionality to the point my code was useless. So I started over. And over. And over. Until I figured out the “correct” way.

Lately, I noticed, jumping straight into the code is still a common problem with young, enthusiastic developers. It is understandable. First impression counts the most, and show me a young developer that doesn’t want to impress his peers. Unfortunately, what young-lings don’t get is that writing poor code will do the exact opposite.

It took me a while and loads of hit and miss attempts to finally figure out, that the best thing you can do as developer when facing a new task is to take a deep breath and think hard about the solution prior to writing a single line of code. When you start coding without thinking, you risk missing an important part of the task or worse, you risk misunderstanding the task completely. In the best case, you will implement something that no one, not even you, will be able to maintain. You see, considering the assignment will make you think hard about all needed components. And when something is not clear to you, you can research it or just go and ask a person that knows more about the subject than you do. Then, you can write a functional spec, which will help you plan and execute the solution.

You know why people are so keen on MVC frameworks? Because it forces developers to separate UI, data model and business logic. Sure, I have seen people still mixing responsibilities in MVC, but I have never seen such gigantic f**kups as with ASP.NET Web Forms. I am willing to bet that if you assign random developers to Web Forms project, you will start seeing business logic, UI code and data logic all tied up in one event handler. I’ve done it for sure. I don’t have the data to prove it, but I think any developer who had something to do with Web Forms did it at least once. But why is that?

[Read the rest of this entry…]

I am sure there are plenty of reasons to use CDNs while developing public internet application, but when you are developing intranet applications, it is better to stay off CDNs and use local resources. Specially for young developers, who have grown up with them, it is difficult to see why. Here are my four reasons as to why you should not use CDN in intranet applications:

1. In high speed gigabit ethernet environment, there is a high chance a CDN resource will take longer to load than local resource or entire page for that matter.
2. Even though the company uses high-speed ethernet, CDN can become slow or unresponsive due to internet provider issues. In that case, the application will most certainly break.
3. While it is tempting to use latest and greatest resources CDN offers, it can happen that new version of CDN resource breaks your application.
4. In extreme cases it can happen that CDN resource gets compromised and turned into super evil script. The affect that has on you and your users should be self-evident.

There is this application I wrote several years ago that is in use for planning and reporting absences and vacation (also discussed here and most likely in some other article as well). Lately, I noticed the very same application working slower and slower to the point of users complaining. I decided to investigate.

[Read the rest of this entry…]