Welcome Guest, Not a member yet? Register   Sign In
Work Faster?

What do you do to make your work faster?

Thanks in advance.

I use a computer  Big Grin

Not funny.
The question is about, how to make your CodeIgniter related work faster?

- What should the app do?
- How many page impressions?
- possible feature request
- make Mock-ups for the customer
- etc

- using default template for model, controller and views
- do not reinvent the wheel
- etc


(08-30-2015, 01:52 AM)solidcodes Wrote: @PaulD
Not funny.
The question is about, how to make your CodeIgniter related work faster?


It seemed funny at the time. :-(

Don't worry It's fine.

@PaulD You made me laugh :-)

To increase my workflow I use tons of keyboard shortcuts in my editor. My editors of choice (sublime text and phpstorm) let me create shortcuts for everything you van think of. Switching back to your mouse to open up another file for example is just wasting so much time, through out the day this realy adds up and it is worth investing some time to memorize those shortcuts.

Another part is making a plan upfront about your approach to the project and write it down and make sure your client gets to read it and sign of on it. This will save you alot of trouble later on if the client is unhappy about the result because he excepted it to do X and you coded it Y. Assumptions and logic within us programmers is not the same than the logic a client might have. Basicly if you leave room for interpretation in your quote you could get either unhappy customers or do alot more work then you anticipated to keep the customer happy.

I try to limit my e-mail moments to the start of the day, right after my lunch break and at the end of the day. I turn off my e-mailclient when coding, just put away the temptation of reading an email straight away and perhaps act on it to help out a client. It really breaks my concentration when I need to go back to my main task of the day and pick up where I got interrupted.

One last advice is to think ahead, if you need to make something for client always ask yourself if this would be usefull for another client. If it is you could keep that in mind and design your library (for example) with a few more parameters/config options or something to make it easily adjustable for those potentially other clients in stead of just hard-coding specific wishes for this client into your library.

(08-30-2015, 01:52 AM)solidcodes Wrote: @PaulD
Not funny.
The question is about, how to make your CodeIgniter related work faster?

Aw, don't get mad. It's a good question but it was a little too general and open. Smile

I still don't know exactly what you mean. Do you mean how do you make your CodeIgniter applications run faster? Or how to finish coding faster?

If you mean how to finish coding faster, preparing and planning with pen and paper can save a lot of coding time because you're not deciding things as you go. When you work in a team in a corporation, discipline like this can be imposed on you, but if you're working on your own, you have to discipline yourself.

On the computer itself, no question, the number one thing for me is a debugger that can execute the code line by line. To be able to slow execution down to where you can watch it take place in freeze-frame is worth all the var_dumps in the world.

A good database admin interface where you can quickly experiment with SQL statements is helpful too.
Hey, don't work without a PHP debugger. Several free IDEs have this features built in. Two are NetBeans and CodeLobster. Without a debugger, it's like you're driving with a blindfold on -- you are going to crash!

I think that Codeigniter is very faster than other frameworks.If any body want to work faster,so you have to create estimate time  ,estimate design,estimate database design and easy coding,avoiding  bad and complex code from Codeigniter.In this way ,you can create fastly  any app.

Thanks everybody.
Engr. Md. Abul Fazal
Researcher and Computer Scientist

A lot of the things I do to work faster are things to do before you start coding:
  • Setup version control for your source code, both remote and local, so you can quickly revert mistakes or commit and push through to the remote for backup and eventual migration to the site. If you can afford a private repo on GitHub, it's a good choice combined with a local git repo cloned from GitHub.
  • Setup a ticket system so you can track requests and their progress (GitHub is also good for this).
  • Use ticket numbers in your commit messages to simplify cross-referencing tickets and changes.
  • Configure your site so you can migrate code via your remote version control. There are many different ways to do this, but generally you're going to want to work in a "develop" branch and use a "master" branch to migrate changes to the site. You can use a very basic setup by cloning and pulling from the server or use any number of tools to make the process as complex as you feel is necessary to cover your migration needs.
  • Setup your local and remote databases, including test data on your local (if you're at a point where you can do that), and setup your client application with the ability to connect to both databases (i.e. MySQL Workbench if you're using MySQL, generally I configure it to prompt for the password when it connects and use different passwords for each server, so I always have that reinforcement when I'm connecting to a server other than my local dev server).
  • Setup your development server with virtual hosts, in case you need to test different configurations or work on multiple sites.
  • Configure your editor however you want it for the way you work.
  • Setup VMs to test your site in whatever versions of IE you need to support (modern.ie is a site run by Microsoft which supplies pre-built VMs for this purpose).
  • Once you have everything setup the way you like it, create an image of your development environment and each server, and put them somewhere safe. Create new images each time you make major configuration changes or major changes to the software on any environment.
On the development machine, I also recommend using as many cross-platform tools as possible. You don't want to change your tools just because you have to change your OS.

During development, set aside some time for periodic code reviews and refactoring. Sometimes you don't realize you're writing the same code over and over again until you come back and look at it without looking for something specific that needs to be fixed/worked on.

If you're going to refactor some code, create tests (if you didn't before), or, at the very least, write up the expected behavior so you can manually test the code. Benchmark the code using a debugger (like XDebug's profiler) so you have some performance statistics to check against when you've finished refactoring (and run the benchmarks multiple times so you can get a range of numbers, rather than a single value which may be exceptionally good or bad). Then you can refactor, compare the performance, and test the code to make sure you didn't break something. If there's a degradation in performance, you're going to have to determine whether that's worth any extra time you would spend writing the same code over and over again (or the maintenance headache if you have to change something in code that's duplicated all over the place). If there's an improvement in performance, you'll be glad you made the change, and probably a little worried that you missed something in your testing that required the extra time.

Some people feel the code reviews and refactoring are themselves a waste of time, or maintaining tickets is a waste of time. In the long term, they're adding some overhead to the process, but they ultimately save time if you use them as tools and part of your process, rather than tacking them on as an afterthought. When someone asks why a change was made, I can find the change in version control and look up the ticket. When someone asks me to do something, I open a ticket, even (or especially) if it's something I don't plan to do right away, so it's there as a reminder. If I move a method into MY_Controller and don't have to re-create that method in 5 controllers, I've saved some time. If I then have to modify that method, I don't have to remember which 5 controllers implemented it and modify all 5 of them (or track down the same bug 5 times), and I've saved more time.

Theme © iAndrew 2016 - Forum software by © MyBB