6 years ago a guy looked at me face to face, and boldly told me; "I don't like you!" I immediately fired a response, I asked him that day; "Thank you for the honest feedback, but those that you like, how has it made their life better? How does your liking people pay their bills or take a bank loan? My brother keep your like, I need God's like And that's what guarantees my future. Today I joined a CEO friend of mine in an interview Panel to recruit some new staff, it was a long session, as we returned from a coffee break to continue the hectic interview session, here was this same guy walked in with his grey jacket and CV coming for the interview. Our eyes kissed by fluke, we immediately recognised each other; "the world is indeed spherical", I soliloquized. He felt very uncomfortable through out the interview, one could clearly see the volcanic eruption ongoing in his whole nervous system, he even mistook his date of birth for his last date of empl
Good Code
Been long since I wrote about good practices. Good development practices. If you aint doing what I'll mention here,
you need to evaluate how you do stuff. I'm not the best adviser out there, but I know what I did and turned around my productivity. The things I'll advice you to do here, are the things I used not to do, inturn spending the whole night doing almost nothing.
I mean, spending the whole night for a bug not worth it.
Will expound on each.
1. Always have a local copy
Basically, have a copy of your project in your machine. The best way to have this is to clone it in your machine if you're developing from online.
I use lamp stack, so, I have a copy at www directory, which serves as a go-to for references incase of anything, and also for adding new stuff to the project.
2. Test Environment
This is an online copy just for tests. This is important for examining how the system behaves while hosted. This copy is located at the production environment or a system with production environment settings.
Remember, set it as a sub-domain. You don't want a client's project out there before launch.
I usually push my projects to heroku, or my domain.
3. Live Environment
This is now the live copy of the system. This is where the system sits after development. This is where it's gonna be. This needs to be guarded well, secured, tested well, no downtimes and all that.
This is usually vetoed by the client. S/he is the one to say where the system is going to sit.
Your work as a developer in this phase is just to deploy the system, and/or advice the client on the best hosting environment.
4. Daemon
This is run as a background process, rather than being under the direct control of an interactive user. At this point, have all logs up and running. Have a way of troubleshooting and/or backtracking errors that may arise while the system is running.
Did I say I was stuck with an issue and the person to assist me always asked me of logs? I didn't. I didn't have them. I hadn't setup any daemon service, logging and all that.
It was hard for him to help me out. I set up all this and called him. After seeing I've done that, he proposed a face-to-face meeting instead of skype calls. (guess he saw I was ready to learn)
It worked readers.
Some errors are generated from some upgrades which aren't compatible, or modules which have redundant functionalities.
With these kept in mind, you'll be a better person than you were yesterday.
Been long since I wrote about good practices. Good development practices. If you aint doing what I'll mention here,
you need to evaluate how you do stuff. I'm not the best adviser out there, but I know what I did and turned around my productivity. The things I'll advice you to do here, are the things I used not to do, inturn spending the whole night doing almost nothing.
I mean, spending the whole night for a bug not worth it.
Will expound on each.
1. Always have a local copy
Basically, have a copy of your project in your machine. The best way to have this is to clone it in your machine if you're developing from online.
I use lamp stack, so, I have a copy at www directory, which serves as a go-to for references incase of anything, and also for adding new stuff to the project.
2. Test Environment
This is an online copy just for tests. This is important for examining how the system behaves while hosted. This copy is located at the production environment or a system with production environment settings.
Remember, set it as a sub-domain. You don't want a client's project out there before launch.
I usually push my projects to heroku, or my domain.
3. Live Environment
This is now the live copy of the system. This is where the system sits after development. This is where it's gonna be. This needs to be guarded well, secured, tested well, no downtimes and all that.
This is usually vetoed by the client. S/he is the one to say where the system is going to sit.
Your work as a developer in this phase is just to deploy the system, and/or advice the client on the best hosting environment.
4. Daemon
This is run as a background process, rather than being under the direct control of an interactive user. At this point, have all logs up and running. Have a way of troubleshooting and/or backtracking errors that may arise while the system is running.
Did I say I was stuck with an issue and the person to assist me always asked me of logs? I didn't. I didn't have them. I hadn't setup any daemon service, logging and all that.
It was hard for him to help me out. I set up all this and called him. After seeing I've done that, he proposed a face-to-face meeting instead of skype calls. (guess he saw I was ready to learn)
It worked readers.
Some errors are generated from some upgrades which aren't compatible, or modules which have redundant functionalities.
With these kept in mind, you'll be a better person than you were yesterday.
Comments
Post a Comment
Your say...