Did you know your iOS device can extend the keyboard you use to type just about everything? Installing Google from the Apple play store allows you to activate Maps, Drive, and search from Google. What most people don’t realize is that it also allows you to activate the Gboard as another , and in my opinion better keyboard. For all the cool stuff Apple has done with iOS , the default keyboard is not on that list.
Install the Google app, go to general settings as Nd switch to the Google keyboard now you’ll be happy you did. Add emoji, use a Swype keyboard, add images, and yes search Google from a simple keyboard. Sweet!
Yes you can even add gifs with a simple key press…
Ok, that may be overboard! Maybe.
Google’s great iOS keyboard is now on AndroiD
by Adi Robertson@thedextriarchy Dec 12, 2016, 1:11pm EST
Androidwear has long been a second class citizen , especially when living on an iPhone. Hopefully this open source attempt at a watch OS can help Android watches regain lost functionality and compete with the Apple Watch.
With Android Wear critical, open source AsteroidOS offers smartwatches a life line
Kris Carlon20 hours ago
Android Wear has been on life support for a while. We’re still waiting for the miracle cure of Android Wear 2.0, but the clock is ticking, the doctors seem pre-occupied and various relatives have already given up hope as smartwatches limp ever closer to the precipice. But smartwatches may just have a new hope: a new open-source wearable platform called AsteroidOS.
This is how I went about building a version of nginx that supports RTMP media streaming on an Ubuntu 16.04 VirtualBox. It is not a simple plug-and-play exercise but anyone with basic Linux system admin skills can get this going.
More than 5 years after I first started delving into the PHP world thanks to client demands and our first foray into WordPress programming, one universal truth remains the same. PHP is still one of the worst programming languages I’ve worked with when it comes to both object and memory management. Yes, it has gotten a LOT better. PHP7 is much faster and generally a superior code and object wrangler than many of its predecessors.
But, 5 years later, even with PHP7 at work, it can be absolutely horrid with memory management. Case in point: today I wrapped up nearly TWO DAYS of debugging and profiling a WordPress plugin that has been running on tens-of-thousands of websites without any complaints of memory consumption for 4 years. But today, on my PHP7 development box, I re-discovered those old lingering issues with PHP. The culprit? Trying to access an array index for a named array that did not exist.
This is something I often come across in code. Just came across it in our MySLP project today , in fact.
SELECT count(id) FROM my_table
While the performance impact of that statement in itself is negligible, it does add up. For most database engines that statement incurs additional overhead as it processes logic related to a specific column containing a specific data type. Some database engines check if the column is null for EVERY RECORD, for example. Not a big deal if you have an index on the column but even with an index there is overhead.
The better option is to use count(*)
SELECT count(*) FROM my_table
COUNT(*) is a semantic placeholder, NOT an operation directive in-and-of-itself. Most database engines, MySQL included, recognize this construct and employ “shortcuts”.
Performing this operation on a moderate-sized table, for example will show a slight difference in the speed of getting the count of records in the table with count(*) almost-always pulling the desired count of records in ZERO seconds and other variants taking a second or more.
Not much, granted, but it IS a big deal with you are working in large volume instances where you are processing billions of records not thousands. Same thing if you have thousands of tables not dozens. A site with hundreds-of-thousands of visitors not hundreds.
The performance differential is even more pronounced when using joins in your count.
Don’t be fooled into thinking count(id) only reads one column from your database while count(*) reads ALL of them and therefore count(id) MUST be faster. That is not how it works. Not for most database engines.
Here is an article by Percona on the same subject you may be interested in: