Recently we had to optimize a set of slow queries in our website and I took advantage of this to write a brief article with some optimization tips.
When system performance is slow, before spending a lot of money in hardware, it's a good idea to review your mysql queries, and the best tool to use is called 'EXPLAIN'.
Let's see a example:
A year and a half ago we went agile here at careesma. Sort of. We changed our processes as much as we could at the time and since then we have continued making incremental changes. This went hand in hand with en effort to change the architecture of the code and clean it up. (By the way, we used this book by Mike Cohn almost exclusively to guide us in our process changes.) The entire company began using redmine to track everything (which will be explained in more detail in another post). Now our technology has almost made it to the current decade as we transition to Zend framework, and even though the architecture of our code will never really be designed to accommodate test-driven development, we only lack one more process change to really consider ourselves agile. That change is to integrate QA into the development process.
But how? After reading a lot of information on the topic, it seems that there is little concrete information on the subject because the actual process....well, it depends on your situation. So the authors of books and articles have to remain abstract. But I was looking for a concrete example of a transition from traditional testing to agile testing and concrete examples of particular practices. I wanted an example of a team that had been using a process where developers "threw code over the wall" to QA and had made the change to agile development that included testers.
When we commit changes that affect a lot of pages that are already indexed by google (results pages for instance), google will detect those changes and it will take a long time to re-index them again.
During this process we can watch google de-indexing our site's pages to subsequently re-index them . Making continuous changes in the site can cause the crawler to reduce its crawling speed and so it will take a lot longer to for our changes to take effect.
To avoid this, one solution is to try to make batch changes, and then try not to make new ones until google re-indexes all the pages that were already indexed before the changes took place. Then we can study the results and queue future changes into a new batch.
New mobile phones (like iphone or android ones) have come out with some wonderful GPS features! And thanks to the W3C guys and their Geolocation API Specification, we can find the location of our web users (always to give them new features and services of course).
Mobile browsers offer us some DOM objects to control and find the user's location. As you know, I don't wanna fill this blog with empty words so let's see an example of that. I think it's the best way to learn!
When I learned PHP, I always did think that sessions are great stuff that the PHP guys have given to us developers. But, playing with huge traffic websites (mainly when we have to handle multiple front ends), I always perceived it as huge limitation.
What do I mean? Simply put, sessions by default are saved on the machine that serves php. This means that we need to ensure that our incoming users always go to the same web server. We solved that problem (previously) using the expertise of our Systems team; they would 'stick' our sessions to one server. Great solution but with great problems. If a server fails (and we know that never happens, heheheh), every single user 'stuck' to that server gets thrown off with it.