MAMP + Pecl + PEAR
Awesome tutorial no how to get the above running smoothly.
Fighting with MySQL to correctly isolate transaction has never been trickier since the release of MySQL 5.5.
Older versions of MySQL treated the following SQL statement as a setting for the current session:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
However, MySQL 5.5 silently ignores this SQL statement and defaults to the global setting. You shall not lose faith, my young padawan. All you need to do is tell MySQL to set transaction isolation levels for the current open session explicitly by adding one small word:
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
And you should have immediate joy.
There is a lot of confusion around the configuration of the old Airpot Express devices from Mountain Lion. Frankly speaking there is no way to configure them, as the new Airport Utility fails to recognize older devices. Yet, ze Russians know their ways ;-) Just follow the howto below to get an older version of Airport Utility up and running and you are good to go:
1. Download the disk image (you can find it here: http://support.apple.com/kb/DL1536).
2. Mount the disk image and drag the install package (AirPortUtility.pkg) to your desktop.
3. Fire up Terminal and prepare to show off…
4. Make a temporary directory and cd into it: mkdir tmp ; cd tmp
5. Extract the Payload file from the install package with xar, here’s the command: xar -x -f ~/Desktop/AirPortUtility.pkg Payload
6. The result will be a directory named AirPortUtility.pkg (just like the file, but now you can move into it to get the files you want). Inside will be a file called Payload that is a compressed archive of AirPort Utility.app.
7. So our next move is to extract the app. Here’s the command: gzcat AirPortUtility.pkg/Payload | tar -xf -
8. When it finished there will be three new folders Applications, Library, and System. Your nice new copy of AirPort Utility 5.6.1 will be in the Utilities folder inside of the Applications folder. Use Finder to rename it (assuming you want to keep version 6 as well) then drag it to your Applications/Utilities folder.
9. The other two folders hold the AirPort Base Station Agent and its supporting files. I’m not sure if you need/want these or not. As best I can figure the agent does two things: it checks for updates for AirPort Utility and it monitors AirPort base stations for problems. You probably already have a version running as it comes with the system and it seems to know how to talk to both versions of AirPort Utility (I got nagged about updating).
10. The final step is to launch AirPort Utility and confirm that it works. You’ll probably want to go into preferences and turn off the option to check for updates. If all is good you can remove the temporary directory: cd .. ; rm -rf tmp (or drag it into the trash with Finder).
What may sound like a no-brainer is actually a point of failure for apple’s UI team. Almost everyone who tries to extend an existing wireless network with the aid of a time capsule fail badly, since the UI is really misleading.
The main problem is — one does NOT have to choose the option “Extend existing wireless network”, — as the option literally disables the TC to work in bridge mode.
So how does one go about this problem? Easy! Setup your TC to create a new wireless network, but use the same SSID, security settings and password as the root device. This will create a roaming network, where all your devices will automatically connect to the spot with the strongest signal.
Double win!
After upgrading to Mountain Lion (and later to 10.8.1) MAMP decided that it did not like the built in Apache and failed to start. This is easy to fix, one has to follow three easy steps:
Steps one and three are really no-brainers, however step 2 may be hard to accomplish to the unix noob master. Here is the sacred command that will do just what needs to be done:
sudo ipfw add 100 fwd 127.0.0.1,8080 tcp from any to any 80 in
I was faced with a recent challenge to maintain a legacy MySQL table with some 20 000 000 (twenty million) records having the following structure:
However simple the table looks, there failed a unique key over the field combination (submission_id, field_id) which resulted every once in a while in duplicate values. All of this is usually no problem, yet updating the table to support partitioning required to have a primary key over the two columns, and creating such needed to get rid of the duplicates first.
Not being a fan of heavy patches, temp-table generation and other resource-hungry procedures I started digging through the MySQL documentation in hopes to find some sacred SQL command to do a mongodb-like drop-dups query while creating a key.
Now guess what, there is a quirky for that in MySQL too, it sounds like this:
ALTER IGNORE TABLE table_name ADD UNIQUE (submission_id, field_id)
How cool could that be?
For the openminded I have put together a small PostgreSQL Database of countries with their dialing codes. Feel free to use and re-distribute without any copyright whatsoever.
Now that is honestly an AWESOME project. Get the power of almighty query-like DOM selectors when parsing html/xml files with php. This is really and honestly a fresh breath of awesomeness!
When it comes to MySQL then Google does not hide many mysteries on how to optimize your queries to make them as efficient as possible. The usual advice boils down to rather simple things such as: index all columns used for filtering/sorting/joining, avoid having lots of outer joins, limit selection sizes et cetera. There are some revelations, however, one may come about when analyzing the way MySQL stores data on disk for really large datasets, and I would like to share a small tip with you :)
In case you are using an InnoDB Table in MySQL (and you most probably are using one) with a reasonably large dataset then you should do your homework on Clustered Indexes and how they can be cooked. The official documentation boils down to the following:
Being equipped with that knowledge one can optimize otherwise slow queries with little change to the source code.
It is common knowledge that the MongoDB Primary Key referenced to as “_id” contains quite a bit of valuable information. Here is a quote from the official documentation that references the info byte-by-byte:
The format:
01234567891011timemachinepidinc
Whereas I personally see little use for the machine code, pid or the increment when developing high-load applications, there is certainly a lot of potential in getting the created timestamp from the ID for various usable operations.
The PHP Drivers returns a MongoID object associated with the array key “_id” for almost every MongoDB Operation. Getting the timestamp from that object is dead-trivial, just use the following syntax:
$mongoDBDocument['_id']->getTimestamp();
And voila, you have a unix timestamp of when the document was inserted into the database.
