I'm actually decide to get real serious about learning Design Patterns at work.. Well, let's say, I'm learning it more on my own than my work is making me learn it, because there Design Patterns in the source code which I debug in. I mean I had been debugging in the code and been exposed to DP for a while, but I never really delve deeper into it, even though I know what this are. But knowing what they are and then try to code it out from scratch are 2 separate things. If you can code it out from scratch, and better yet, apply it to real programs, you know DP.
So I'm taking this chance to explain as much DP as possible on this blog so that I can share what I think I learn to reinforce the knowledge and also hopefully knowledge readers can provide feedback with more examples or even correct me if I'm wrong.
Obviously, the software I debug it does not use all 23 plus DP that are known out there by the Gang of Four. But I will try and publish on the blog the ones which I think I truly know and seen it in action. If I never seen it in real application actions, I will mention it.
Also each DP I mention will be backed by examples, diagram and source code in C++. (too many out there use java). I will also probably do only one at a time, so I don't overwhelm anyone. I will try to make it as nice and clean and simple as possible so people will come back and ask for more. So until next time... which I will start off with the most basic and common DP of all - Singleton.
Error Checking Does Take Time
It's been a few days since I blogged anything on this site. I had been busy and a bit upset at certain things. I'm not completely over it, but life is like that. You have to move on and also there is no 100% happiness or perfectness in life all the time.
Anyways, I have some comments regarding the time it takes to code any task assignment. If you have to code a very simple task such as find the average of five numbers that was entered and then find the maximum and minimum of those numbers, it should take no more than five minutes for a proficient programmer in their preferred, proficient language.
But if I added that it much make sure the user enters in a valid data and make sure it met its boundary conditions, it will take a little bit more time.
Error checking is what will turn this 5 minutes of work into maybe 15 to 30 minutes. The reason is that you might not do what an insane user will do when they input the data or you might just miss some loopholes. Then you have to test it in any insane way possible to make sure it is 'water proof' so to speak. This means it took 10-25 minutes of your time to code and test your program to be error proof.
For example, for the above mentioned task, you immediately will think only numerial values are allowed. More experience coders will also take into consideration that they will not enter in a number that has 100 digits. Now what about if the user enters in a number,space and then a number, or a number with commas like 1,000. Also, the user can press space 10 times before entering in a number. Still moreover, what if the person decide to user 1E6 for 1 million.
You get the point. Thinking about all the loopholes will take up your time.
This is what happened at work today. I wrote a script which if I careless about other user using it, it will be done in 10 minutes. But because I intend to let other programmer use it, I have to think of all possible ways that they might misunderstood and input in the wrong stuff. Overall it took like 1 or 2 hours because I want to make sure they will enter in with the correct prefix and suffix word for the commandline argument and also don't enter in numbers, etc.
Now I can say this bash script is error proof in a way. Of course, if I want it to make it complete automatic as in run anywhere and set back to where they are, that will take a more time since I have to consider where and how and what they will be doing before running this script.
Also I have to mention that even though there seems to be error proof to a few people, only time will tell if it really is that error proof since more people will use it and therefore come across different scenarios. So you see, a simple thing will still take time if you error checking comes to play.
Anyways, I have some comments regarding the time it takes to code any task assignment. If you have to code a very simple task such as find the average of five numbers that was entered and then find the maximum and minimum of those numbers, it should take no more than five minutes for a proficient programmer in their preferred, proficient language.
But if I added that it much make sure the user enters in a valid data and make sure it met its boundary conditions, it will take a little bit more time.
Error checking is what will turn this 5 minutes of work into maybe 15 to 30 minutes. The reason is that you might not do what an insane user will do when they input the data or you might just miss some loopholes. Then you have to test it in any insane way possible to make sure it is 'water proof' so to speak. This means it took 10-25 minutes of your time to code and test your program to be error proof.
For example, for the above mentioned task, you immediately will think only numerial values are allowed. More experience coders will also take into consideration that they will not enter in a number that has 100 digits. Now what about if the user enters in a number,space and then a number, or a number with commas like 1,000. Also, the user can press space 10 times before entering in a number. Still moreover, what if the person decide to user 1E6 for 1 million.
You get the point. Thinking about all the loopholes will take up your time.
This is what happened at work today. I wrote a script which if I careless about other user using it, it will be done in 10 minutes. But because I intend to let other programmer use it, I have to think of all possible ways that they might misunderstood and input in the wrong stuff. Overall it took like 1 or 2 hours because I want to make sure they will enter in with the correct prefix and suffix word for the commandline argument and also don't enter in numbers, etc.
Now I can say this bash script is error proof in a way. Of course, if I want it to make it complete automatic as in run anywhere and set back to where they are, that will take a more time since I have to consider where and how and what they will be doing before running this script.
Also I have to mention that even though there seems to be error proof to a few people, only time will tell if it really is that error proof since more people will use it and therefore come across different scenarios. So you see, a simple thing will still take time if you error checking comes to play.
No up-casting During Array Initialization
Interesting. Today our QA guy came to me and told me that SunOS, and HP machines were not compiling due to a section of my code. I took a look and low and behold it is my code (variables names changed)
ParentBar* (*PtrFunc[])( ) =
{
ChildABar::instance,
ChildBBar::instance,
ChildCBar::instance
};
The problem was that ChildABar::instance is a Singleton which returns only ChildABar*. Now it is perfectly fine to upcast it so that ChildABar* passes to ParentBar* which is the pointer to parent class of ChildABar, ChildBBar and ChildCBar. But for this case it is not because the array is in declaration/initialization phase and not assignment phase.
It's fine to assign child/derived class pointer to parent/base class pointer ( called upcasting ), but it cannot be done during initialization. So to fix this problem, I just when into ChildABar, ChildBBar and ChildCBar classes and created another static member function call getParentBar() that returns the pointer to parent class ParentBar* ,
ParentBar* ChildABar::getParentBar( )
{
return _instance;
}
where _instance is of type "static ChildABar*".
So I get
ParentBar* (*PtrFunc[])( ) =
{
ChildABar::getParentBar,
ChildBBar::getParentBar,
ChildCBar::getParentBar
};
This then fixed the Sun and Hp compiler problems which are much more picky and strict than Linux, which only gave me warnings during compilation. This is just something I learned today.
ParentBar* (*PtrFunc[])( ) =
{
ChildABar::instance,
ChildBBar::instance,
ChildCBar::instance
};
The problem was that ChildABar::instance is a Singleton which returns only ChildABar*. Now it is perfectly fine to upcast it so that ChildABar* passes to ParentBar* which is the pointer to parent class of ChildABar, ChildBBar and ChildCBar. But for this case it is not because the array is in declaration/initialization phase and not assignment phase.
It's fine to assign child/derived class pointer to parent/base class pointer ( called upcasting ), but it cannot be done during initialization. So to fix this problem, I just when into ChildABar, ChildBBar and ChildCBar classes and created another static member function call getParentBar() that returns the pointer to parent class ParentBar* ,
ParentBar* ChildABar::getParentBar( )
{
return _instance;
}
where _instance is of type "static ChildABar*".
So I get
ParentBar* (*PtrFunc[])( ) =
{
ChildABar::getParentBar,
ChildBBar::getParentBar,
ChildCBar::getParentBar
};
This then fixed the Sun and Hp compiler problems which are much more picky and strict than Linux, which only gave me warnings during compilation. This is just something I learned today.
Brief Thoughts about GUI Coding and Design
As I have been working on my projects in the past and present most of which focuses on GUI coding and design, I have some rule of thumbs which I have in my mind. See, people think GUI coding and design is easy. That's true, only if you are the only user in the world or maybe less than 5 people who are using the application with the GUI as the front end.
But if you got at least hundreds of people using your GUI that you designed, that's another story. Couple that with your business managers and a bit of office politics, things then gets complicated.
You can say client-server programming is like that too. But client-server coding is mostly technical. It does not have the soft side such as human interaction, like GUI, because client-server is behind the scenes. As long as it works, the user doesn't give a damn how it works or whether the code is sloppy.
But GUI is front-end and visible to humans, which themselves are complex animals with complex opinions. When it comes to visual things for humans, satisfying one might not satisfy another.
Developers see thing differently than end users and what one group care the most about is what the other group careless about. There will also be a new user who will criticize the tiniest thing that is unknown to 99% of the people whom had been using the application for years. Then there are the infamous impossible requests by clients such as shoving everything into one panel or window while the fonts are very visible to an old lady all without compromising the look and balance of the application. Then some others will even complain that everything is all customizable to a point that it's too confusing.
Then there is the development side of things. Business Managers constantly request to change the look because after a while they realize their prior request was wrong and therefore gives new specs, which can also be "wrong" later. Then once everything is believed to be confirmed and then release out, you have the end users who will request for new modifications. The only thing you have to do is to make sure your code can adapt to change immediately because god knows when they will come back and say "actually, make it this way", which was the original way you had suggested it in the first place.
There's more to what I'm saying here about GUI, but I'll stop here for the time being. Basically GUI programming and design is both an art and science. Anyways, here are the rule of thumbs I found to be useful if I'm the sole person in charge (a.k.a the manager, the coder and the designer)
1) Be consistent on the look and feel and widgets everywhere
2) Make sure GUI design have a 'stress-less process flow' feel
3) Make sure it's pleasant to the eye
4) Make it intuitive. (activate and deactivate widgets, etc.)
5) Don't overdo
6) Be efficient; trim the fat, and be simple but not too simple
7) Balancing look is the key
8) Make sure your code is extremely easy to maintain
9) Think ahead and leave yourself open when coding and designing the Interface for possible future changes
But if you got at least hundreds of people using your GUI that you designed, that's another story. Couple that with your business managers and a bit of office politics, things then gets complicated.
You can say client-server programming is like that too. But client-server coding is mostly technical. It does not have the soft side such as human interaction, like GUI, because client-server is behind the scenes. As long as it works, the user doesn't give a damn how it works or whether the code is sloppy.
But GUI is front-end and visible to humans, which themselves are complex animals with complex opinions. When it comes to visual things for humans, satisfying one might not satisfy another.
Developers see thing differently than end users and what one group care the most about is what the other group careless about. There will also be a new user who will criticize the tiniest thing that is unknown to 99% of the people whom had been using the application for years. Then there are the infamous impossible requests by clients such as shoving everything into one panel or window while the fonts are very visible to an old lady all without compromising the look and balance of the application. Then some others will even complain that everything is all customizable to a point that it's too confusing.
Then there is the development side of things. Business Managers constantly request to change the look because after a while they realize their prior request was wrong and therefore gives new specs, which can also be "wrong" later. Then once everything is believed to be confirmed and then release out, you have the end users who will request for new modifications. The only thing you have to do is to make sure your code can adapt to change immediately because god knows when they will come back and say "actually, make it this way", which was the original way you had suggested it in the first place.
There's more to what I'm saying here about GUI, but I'll stop here for the time being. Basically GUI programming and design is both an art and science. Anyways, here are the rule of thumbs I found to be useful if I'm the sole person in charge (a.k.a the manager, the coder and the designer)
1) Be consistent on the look and feel and widgets everywhere
2) Make sure GUI design have a 'stress-less process flow' feel
3) Make sure it's pleasant to the eye
4) Make it intuitive. (activate and deactivate widgets, etc.)
5) Don't overdo
6) Be efficient; trim the fat, and be simple but not too simple
7) Balancing look is the key
8) Make sure your code is extremely easy to maintain
9) Think ahead and leave yourself open when coding and designing the Interface for possible future changes
maintainability over coding speed is priority for large scale applications
There's something I actually learned and know first-hand a while back, but I never talked about it really, since I wasn't as into development as I am now. That is, coding something to work gets down in a matter of minutes, whereas coding it to make it so that other future coders will ONLY have to change in one file despite the fact that multiple files will have to change due to the coupling of the components takes much more than a few minutes. I'm talking about ease of maintenability. I wish I can show the code so you know what I"m talking about but I cannot due to the following reasons: 1 ) it's prioprietary in a way and 2 ) there is multiple files that coupled the feature I was working on in a way so there is no way I'm going to post them all.
But main thing is that once any coder makes this change in this file, they will have to go to another file to do something to it.. now whether they even know if that other files need to be change is up in the air and that is the problem. I am trying to avoid that so that they only have to change it in 1 place and that is the challenge.. and it's not as simple as declaring globals or just const number. The feature has to do with Toolbars and enhance it so it can lock and unlock down it so it can be moved around is easy because the QT documentation is very clear and made easy. But it is making it all change in one file that is the goal. But right now due to the framework it is in, the toolbar stuff is actually in 2 or 3 files and changing one without changing the other can easily 'break' the system... although it will not core-dump which is the good thing. Now add elegance look to the code so that there is no redundancy adds another layer to it.
So the maintenance utopia is when a coder only needs to change one small thing in one file and every other files will get update automatically. But reaching this utopia is nearly impossible. That's why it's call utopia!
Another thing I noticed is that I tend to use Singleton all over the place. I guess it is the easily route since it's similar to having globals.. But it is also not the best route since all other files will then have to be touched upon because of inserting the Singleton. This was my initial approach. But I changed it later. To make a long boring story short, I made it so that any maintainer can just change 2 lines of code in a single file without referring to another one. Furthermore, I made it so that if there is a new toolbar to add and want it to have the same features of lock down, then can just create the file and then cut and paste my section of the code to the new file, then change just 2 lines again. So my code in this function is like a template for other future ones.
The thing is that to make it work without caring who is going to read it/maintain took me 10 minutes. I know because I want to make sure the feature works before I work on upgrading the code into a maintainable animal. But it took me 4 hours to code it up into the maintainable animal that it is now. Although to any novice, it looks like a complicated piece of work. But once they use it, it's simple as 1,2,3. For the 10 minutes one, a novice will be able to detect it easily, but it will be a maintenance nightmare in the future if the code and GUI grows larger and features changes keep happening, which is inevitable in the software development world.
But main thing is that once any coder makes this change in this file, they will have to go to another file to do something to it.. now whether they even know if that other files need to be change is up in the air and that is the problem. I am trying to avoid that so that they only have to change it in 1 place and that is the challenge.. and it's not as simple as declaring globals or just const number. The feature has to do with Toolbars and enhance it so it can lock and unlock down it so it can be moved around is easy because the QT documentation is very clear and made easy. But it is making it all change in one file that is the goal. But right now due to the framework it is in, the toolbar stuff is actually in 2 or 3 files and changing one without changing the other can easily 'break' the system... although it will not core-dump which is the good thing. Now add elegance look to the code so that there is no redundancy adds another layer to it.
So the maintenance utopia is when a coder only needs to change one small thing in one file and every other files will get update automatically. But reaching this utopia is nearly impossible. That's why it's call utopia!
Another thing I noticed is that I tend to use Singleton all over the place. I guess it is the easily route since it's similar to having globals.. But it is also not the best route since all other files will then have to be touched upon because of inserting the Singleton. This was my initial approach. But I changed it later. To make a long boring story short, I made it so that any maintainer can just change 2 lines of code in a single file without referring to another one. Furthermore, I made it so that if there is a new toolbar to add and want it to have the same features of lock down, then can just create the file and then cut and paste my section of the code to the new file, then change just 2 lines again. So my code in this function is like a template for other future ones.
The thing is that to make it work without caring who is going to read it/maintain took me 10 minutes. I know because I want to make sure the feature works before I work on upgrading the code into a maintainable animal. But it took me 4 hours to code it up into the maintainable animal that it is now. Although to any novice, it looks like a complicated piece of work. But once they use it, it's simple as 1,2,3. For the 10 minutes one, a novice will be able to detect it easily, but it will be a maintenance nightmare in the future if the code and GUI grows larger and features changes keep happening, which is inevitable in the software development world.
Hmmm... Let's See..
I recently realized that I had been doing a lot of thinking and reflecting on programming, software development in general and things I learned from work regarding coding that I decided to maybe try starting a blog on it. After all, I had been putting my thoughts on electronic paper (wordpad..haha) so to speak that I might as well log them as blogs. So yes, I had been typing away at my thoughts about this programming/sd/coding topic before I even started this blog. I think I will post a few of them on here after this post sometime later and hopefully the bloggie will grow. I had been typing my thoughts but not posting them on blogs nor talk about them for a few reasons:
1) I can type quite fast, like over 50 wpm last time I checked a few years ago..and I feel my speed stay at least the same , if not faster.
2) Although creating a blog is easy as 1,2,3.. maintaining it, and maybe it grow is the more time consuming and tougher part. Just think of the analogy of creating a baby (so exciting and satisfying..esp for the guy...) is easy, but raising a baby and make it grow the way you want it is HARD. For fathers out there who had raised kids, you get the point. I am married and I have a kid ..so you get the point there too!
3) I had been thinking about software development and stuff in general and realized that I learned to like it!.. I will talk about it more later on.. I'll just post my previous private statements I had written in the past.
4) There is no one to really talk to all the time about it. Come on, face it.. how many find software development, programming an interesting? They have reality TV shows and regular TV shows about lawyers, business people ( apprentice ), detective (CSI,etc), cops (24..), medical people ( ER, House, Scrub..haha).. BUT NO TECHNICAL COMPUTER PROGRAMMING PEOPLE. They have "this old house" technical people who show you have to do wood making and building a house.. but programming/software dev? hahahhaha. Why, because the general public don't understand the difference between a byte and bit.. most of them anyways. Talking to my wife about it is even worst because she doesn't even know simple things such as searching for an email via subject in yahoo.
5) Speaking about talking about technical topic.. just conversing about it to most people is difficult ..but conversing it with technical people in general can be just as horrible... especially the ones who think they know a lot versus the ones who knows a lot. I for one doesn't claim to know a ton about programming because it's such a wide scope now (you have .NET, C/C++, ASP, Ada, Fortran, Perl, builts, and other non langugage related stuff). But I do claim to know more about it than someone who have only a 1 or 2 years of experience in actuall software creation commercially and therefore can speak my thoughts. Others who have a few years will think they know it all, and thinks that programming is software development..which is SO WRONG, in my opinion anyways. And notice I say in my opinion because this brings up aonther point that every technical/software/computer 'guru' seem to have their own opinion of things and for these people, being right is crucial. But for subjective topics, it's not easy as a quantitative topic like saying 1+1 = 2 is right and 1+1 = 3 is wrong. So you might have debates, ego, and condescending tones if you don't know a topic in which they think it is a basic concept. Humility is not existence for most technical people. So whatever I post later on, people might or might not agree, but that is okay since if someone disagrees and they gave a reason why, it gives a whole new perspective and then you get to learn from it..which is the point of all endeavor (leave ego out the door and you will learn, because even some little kids can have a new creative perspective from a full grow adult ).
Now if you are still reading this.. thank you because at least it means I either did not bored you or you might find that my post might be interesting. It might also mean that you are also in this industry.. or trying to gain entrance to it or just so bored that you are reading my blog..hahaha. So I'll see how this blog will work out and whether I will continue to make it grow.
But Anyways.. til next time... as my 2 year old daughter is bothering the heck out of me and thus seems like I am rambling on without checking for grammatical error.. which is better than run-time errors..hahaha.
1) I can type quite fast, like over 50 wpm last time I checked a few years ago..and I feel my speed stay at least the same , if not faster.
2) Although creating a blog is easy as 1,2,3.. maintaining it, and maybe it grow is the more time consuming and tougher part. Just think of the analogy of creating a baby (so exciting and satisfying..esp for the guy...) is easy, but raising a baby and make it grow the way you want it is HARD. For fathers out there who had raised kids, you get the point. I am married and I have a kid ..so you get the point there too!
3) I had been thinking about software development and stuff in general and realized that I learned to like it!.. I will talk about it more later on.. I'll just post my previous private statements I had written in the past.
4) There is no one to really talk to all the time about it. Come on, face it.. how many find software development, programming an interesting? They have reality TV shows and regular TV shows about lawyers, business people ( apprentice ), detective (CSI,etc), cops (24..), medical people ( ER, House, Scrub..haha).. BUT NO TECHNICAL COMPUTER PROGRAMMING PEOPLE. They have "this old house" technical people who show you have to do wood making and building a house.. but programming/software dev? hahahhaha. Why, because the general public don't understand the difference between a byte and bit.. most of them anyways. Talking to my wife about it is even worst because she doesn't even know simple things such as searching for an email via subject in yahoo.
5) Speaking about talking about technical topic.. just conversing about it to most people is difficult ..but conversing it with technical people in general can be just as horrible... especially the ones who think they know a lot versus the ones who knows a lot. I for one doesn't claim to know a ton about programming because it's such a wide scope now (you have .NET, C/C++, ASP, Ada, Fortran, Perl, builts, and other non langugage related stuff). But I do claim to know more about it than someone who have only a 1 or 2 years of experience in actuall software creation commercially and therefore can speak my thoughts. Others who have a few years will think they know it all, and thinks that programming is software development..which is SO WRONG, in my opinion anyways. And notice I say in my opinion because this brings up aonther point that every technical/software/computer 'guru' seem to have their own opinion of things and for these people, being right is crucial. But for subjective topics, it's not easy as a quantitative topic like saying 1+1 = 2 is right and 1+1 = 3 is wrong. So you might have debates, ego, and condescending tones if you don't know a topic in which they think it is a basic concept. Humility is not existence for most technical people. So whatever I post later on, people might or might not agree, but that is okay since if someone disagrees and they gave a reason why, it gives a whole new perspective and then you get to learn from it..which is the point of all endeavor (leave ego out the door and you will learn, because even some little kids can have a new creative perspective from a full grow adult ).
Now if you are still reading this.. thank you because at least it means I either did not bored you or you might find that my post might be interesting. It might also mean that you are also in this industry.. or trying to gain entrance to it or just so bored that you are reading my blog..hahaha. So I'll see how this blog will work out and whether I will continue to make it grow.
But Anyways.. til next time... as my 2 year old daughter is bothering the heck out of me and thus seems like I am rambling on without checking for grammatical error.. which is better than run-time errors..hahaha.
Subscribe to:
Posts (Atom)