This can really eat into your memory, especially if you are running a large script via CodeIgniter CLI, processing a large amount of data.
Thankfully this is faily easy to stop. Just set the flag below to FALSE. It's in the DB_driver.php file, same as above.
/** * Save queries flag * * Whether to keep an in-memory history of queries for debugging purposes. * * @var bool */ public $save_queries = TRUE;
I haven't found a way to dynamically turn this on/off (at least through officially supported means), but ideally I think this should be able to be set on/off depending on your environment. In a production environment where you rarely would be using the CodeIgniter profiler, this will just be a waste of memory, and can be very harmful to your application.
Until that dynamic configuration is possible, I suggest just turning it off everywhere, and turning it on only when you need it.
As many people are already aware from various news outlets, Android has a nasty vulnerability that allows remote code execution by simply receiving a MMS.
The other day, this video has been finally released - it's the Black Hat presentation of the actual guy who discovered the vulnerability. He goes into great detail of how he found the vulnerability and how he discovered various attack vectors by tracking where StageFright is being called.
It's a very interesting video so please watch (Black Hat videos are always really insightful).
Now, this issue really troubles me. Not the vulnerability itself - of course it's bad, but hey let's face the truth, all OS (all software even) has some sort of vulnerability, and that's why there are updates and patches. Nobody is to blame for the bug itself.
What's the Problem?
The problem is that the patch for this vulnerability has not reached enough people, and will never reach enough people who are affected.
The reason is simple - It's because there are too many layers in between Google, and the end user.
So there is
1. Google (OS developer)
2. Samsung (manufacturer)
3. Verizon (phone carrier)
So first, even if Google fixes its bug and releases a patch, the manufacturer has to incorporate it into their version of the OS.
Since Android is an open-sourced OS, the manufacturer can fiddle with its code all they want, and therefore these types of fixes have to be done by the manufacturer, not Google.
And the manufacturers have different flavors of the OS depending on the phone carrier too. Samsung has to release an updated OS for Verizon's Samsung S4, as well as T-Mobile's Samsung S4. And if you know anything about releasing OS, you would know that it's no easy task testing and releasing an update for an OS.
So this model of distribution is TOO long for a critical security update. As you can see in the articles above, the Verizon Samsung patch took roughly 2 weeks since the discovery of the bug, and the T-mobile Samsung took almost a month. And obviously these are not the only devices existing in the world, so there are A LOT more devices affected, where either the manufacturer or the phone carrier has not done its job and release the patch yet.
As of today, in Japan, I am not able to find even one phone carrier that has released a patch for this. It is terribly unfortunate, and it's a pretty good deal for any malicious hackers who want to take root of your phone.
What Can They Do?
Frankly, I don't know. I understand Google's philosophy of open-sourcing Android, and I'm sure there has been a lot of benefits to that decision (especially in competing with iOS). But there has to be a realization that this model is fundamentally broken, and it will be detrimental to all stakeholders in that chain. There will be more vulnerabilities like this in the future, and that's a fact as long as Android keeps on evolving. And when this kind of negligence against security is left, it will cost Android(Google) their brand image and customer loyalty.
I like the Windows model where they don't let manufacturers touch the OS itself, and only allow applications to sit on top of it just like any other third party. I was entertaining myself with the idea of Android not open-sourcing their AOSP, and distributing their OS as a freeware instead of an open-source, but I'm sure that's not the best idea.
I just believe that the first step is acknowledging that this is a broken model, and SOMETHING has to be done.
Both articles talk not about how "Agile software development is dead" or "wrong" or "no longer hip" or any of that. It talks about the community misinterpreting and abusing the concepts of Agile (and Scrum).
Some stuff on what I feel is going on.
Absence of Method
The notion of "Agile = no planning". I'm sure it has gone away quite a bit now, but I still hear about it. Agile doesn't mean that you can just develop without any planning. In fact, I even believe that Agile requires a larger devotion to the process, more than traditional waterfall development.
Method Before Philosophy
I personally am also guilty of this - We hear sprints, iterations, daily stand-ups, retrospectives, and we decide to use them. But we forget WHY they exist.
Agile is philosophy of iterative/incremental development and frequent delivery. All other rituals, like those of Scrum, are just formats of how to execute on that philosophy.
If you can't show your customer/stakeholer a (potentially) shippable product by the end of the iteration, something isn't right. If majority of the duration of the project is being spent on planning rather than developing, something isn't right.
Scrum master certificate
I believe that the Scrum Master certification is a good idea for people who already have had enough in-field experience with scrum, to get a deeper understanding. But I don't think it works the other way around - If you haven't had in-field experience, there is no way you will become a functional scrum master just with the few days of training.
Scrum is learned in field with the different problems that come with different sizes/types of projects.
I believe there is a lot more commercial interest behind the Scrum Master certification.
My mission lately is to learn and enlighten my team on a more efficient and motivating software development. The answer surely isn't blindly following Scrum methodologies, but it certainly is a start, so I want to do it right.