25 January Friday ´13
@shayhowe sum up HTML & CSS for beginners: "A Beginner's Guide to HTML & CSS"http://learn.shayhowe.com/html-css/

A nice presentation in 10 topics showing techniques that's not outdated. Most of the resources you search on web about html and css, are from 90s showing very old outdated methods.

Shay Howe also started to work on "Advanced Guide to HTML & CSS". It's still in progress but it's accessible as it's availablehttp://learn.shayhowe.com/advanced-html-css/
Economy models in iOS apps uses In-App purchases become very popular. Lots of developers pick iOS environment because of the flawless payments through iTunes.

If you're planning to have a monetization model in your app, it has to go through Apple system and you have to use in-app purchases. There is no other way to accept payments from your iOS apps. There are pros and cons of using Apple in-app purchases. I'll try to explain some of them.

Biggest con is Apple takes 30% of your sale. And other con is, there are difficulties and grayed areas in integration of in-app purchases to your app and back-end. But the pros makes all even. Because delegating whole payments to Apple is gonna affect your sales because Apple makes it so seamless that it reduces all money related steps to only one confirmation box. So it changes the purchase experience and makes it what it supposed to be. Most of the checkout or payment experiences on web, faces lots of drops because of unnecessary and boring steps like putting your credit card info, trying to give the trust to user that you're a legitimate company, and have legitimate payment system that you will not sell their info out or you won't let hackers to pick your customer info up. All those buying experience changed in iTunes payments. So this is why you shuould want to integrate in-app purchases.

Let's dive in to the integration. You have to use StoreKit which is an interface in iOS that handles all iTunes and payments. I won't talk about objective-c integration of StoreKit, I will just explain what's to do there.

After integration of StoreKit, when user triggers a payment (with tapping a button or something like that) you call StoreKit and iOS shows a confirmation box of your product, price and after that user confirms their iTunes password and StoreKit gives you a "receipt-data" object which is an encoded string holds the receipt details. You don't need to worry about what's in it or how to decode it, because you won't need. You just need that receipt-data to verify and get the all details from Apple. At this point, you need to verify this receipt-data with using their HTTP method.

Some amateur developers doesn't feel the necessity of verifying the receipts they received from StoreKit. But the problem is, there are lot's of easy ways to hack this and jailbroken devices can create fake receipts. So if you don't validate and if you assume you received your payment with whenever you receive a receipt from StoreKit, you may see misuses of your paid content. One other reason to validate is, you might want to (and you should) keep record of your purchases and their statuses (valid or invalid). So I highly recommend you to do a back-end integration to keep track of records and also verification.

Read more →
If you're developing php based facebook application, you might want to use (or already using) Facebook integration little more than just authentication and identification of your user. Even if you have the simplest facebook app and using php sdk, you probably have regulary done api calls.

You write your app and you start to see performance issues. You start to optimize your database interactions, php code optimization, after you done with your application optimization, if you still have performance problems it's possibly from facebook calls. Since you use sdk, you might not know what's happening with facebook communication. So you want to do profiling between your app and facebook api servers.

You can add a basic timing profiling to your api calls to see how many calls you do, what kind of calls they are and how long they take to run.

Let's dive in sdk, modify it a bit and start getting profiling information. Here is the actual method you need to modify in base_facebook.php file:
public function api(/* polymorphic */) {
	$args = func_get_args();
	if (is_array($args[0])) {
		return $this->_restserver($args[0]);
	} else {
		return call_user_func_array(array($this, '_graph'), $args);
and we're modifying it like this:
$facebookApiCalls = array();
public function api( /* polymorphic */)
	$args = func_get_args();

	$time_start = microtime(true);

	if (is_array($args[0])) {
		$result = $this->_restserver($args[0]);
	} else {
		$result = call_user_func_array(array($this, '_graph'), $args);

	$time_end = microtime(true);
	$time_elapsed = $time_end - $time_start;
	$time_elapsed *= 1000; //convert to millisecs

	if (isset($GLOBALS['facebookApiCalls'])) $GLOBALS['facebookApiCalls'][] = array(
		'duration' => $time_elapsed,
		'args'     => $args,
	return $result;
It simply appends a global array named "facebookApiCalls" and adds the api call details as "args" and timing as "duration". So at the end of your page logic code, you can print this information after sorting it by duration and you can also filter to show only slow ones (for instance, the ones took over 200 miliseconds).

Aftr this profiling you can start to identify the slow calls, also if you do same calls multiple times because of recursing, recalls etc..., you can see and optimize, combine them.

This optimization is not only a performance tweak for user, also it will decrease number of calls made between your server and facebook servers.

mfyz v0.8 is still beta feel free to contact me for any bugs and problems

100% Handcoded!