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.
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 the problem is that absolute positioning is easy to abuse. A coordinate system is much easier for lay people to understand than the box model. Also, programs like Dreamweaver make it trivially simple to layout a page using absolute positioning (and people don’t realize what they’re doing).
However, for typical page layout, the default static positioning should be adequate and get the job done 90% of the time. It’s very flexible, and by keeping everything in normal flow, elements are aware of the other elements around them, and will act according when things change. This is really good when dealing with dynamic content (which most pages are these days).
Using absolute positioning is far more rigid and makes it difficult to write layouts that respond well to changing content. They’re simply too explicit. However, it is perfect if you’re in need of freely moving elements around a page (drag/drop), need to overlay elements on top of each other, or other layout techniques that would benefit from working on a coordinate system. Frankly, a chessboard sounds like a fine reason to use it.
So is absolute positioning evil? Yes, but not in every case. Positioning something absolute relatively to it’s container is fine, if there is absolutely no way to position element using regular in-flow positioning (close x icon for modal dialog pops to mind). However, if you are learning CSS, I would definitely advise you to learn the box model first.
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.
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?
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:
- 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.
- 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.
- While it is tempting to use latest and greatest resources CDN offers, it can happen that new version of CDN resource breaks your application.
- 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.
The most difficult thing in any company is to change it’s culture. You see, companies are used to operate in certain frames of mind and they do not accept change lightly. Also, people have the tendency of sticking in comfort zone. Working in standard and set ways is nice and comfy. Why on earth would I leave this place for something big and scary? Well, for starters to improve yourself. And improvement is always good. Stagnation, bad. Improvement, good. OK?
In my 15 year career, I have yet to encounter a software company in Slovenia, where code review would be a part of work process. It is surprising how many companies just don’t care what kind of code they produce. And this is exactly the reason why most software originating from Slovenia, well, sucks.