For a fresh of taste I've installed Mac OS X El Captain(10.11) beta on my Macbook. Everything is fine until I want to upgrade my PHP installation via homebrew.

The result is:

> brew install php56
Warning: You are using OS X 10.11.
We do not provide support for this pre-release version.
You may encounter build failures or other breakage.
==> Installing php56 from homebrew/homebrew-php
==> Downloading https://php.net/get/php-5.6.11.tar.bz2/from/this/mirror
Already downloaded: /Library/Caches/Homebrew/php56-5.6.11
==> ./configure --prefix=/usr/local/Cellar/php56/5.6.11_2 --localstatedir=/usr/local/var --sysconfdir=/usr/local/etc
==> make
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [sapi/cgi/php-cgi] Error 1
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libs/libphp5.bundle] Error 1

READ THIS: https://git.io/brew-troubleshooting
If reporting this issue please do so at (not Homebrew/homebrew):
  https://github.com/homebrew/homebrew-php/issues

Warning: You are using OS X 10.11.
We do not provide support for this pre-release version.
You may encounter build failures or other breakage.

According to the warning, that is not avoidable with build failure. ;-)

BUT, the problem can be solved with the power of google. :)

---

Open the File /usr/local/Library/Taps/homebrew/homebrew-php/Abstract/abstract-php.rb line 362, replace:
s.change_make_var! "EXTRA_LIBS", "\\1 -lstdc++"
to
s.change_make_var! "EXTRA_LIBS", "\\1 -lstdc++ /usr/local/opt/openssl/lib/libssl.dylib /usr/local/opt/openssl/lib/libcrypto.dylib"

then try to install the php via homebrew again.

via: https://github.com/Homebrew/homebrew-php/issues/1941

GSON makes the conversion JSON to POJO very easily

As a java developer one should know JSONObject very well. On the other hand, if one depends so heavily on JSONObject, the conversion from JSON to POJO becomes sometimes a burden if the structure of JSON string is very complex. One has to write so many codes to call JSONObject.getString("") and so on. Thanks GSON, there is a better way to convert JSON to java object.

 Define a java class to be an exact model of the JSON string like: 

{"book":{"translations":[{"translatedText":"Bonjour tout le monde"}]}} 

The java class:

class BookWrapper {
    public Book book;

    public static BookWrapper fromJson(String s) {
        return new Gson().fromJson(s, DataWrapper.class);
    }
    public String toString() {
        return new Gson().toJson(this);
    }
}
class Book {
    public List<Translation> translations;
}
class Translation { 
    public String translatedText;
}

As you can see, it's very convenient and elegant to use BookWrapper.fromJson(JsonString) to convert a JSON string to the java object.

Furthermore, GSON supports the versioning of a java object. It's helpful when the JSON structure has been changed with some versions.

Usage taken from the GSON user guide:

Versioning Support

Multiple versions of the same object can be maintained by using @Since annotation. This annotation can be used on Classes, Fields and, in a future release, Methods.  In order to leverage this feature, you must configure your Gson instance to ignore any field/object that is greater than some version number.  If no version is set on the Gson instance then it will serialize and deserialize all fields and classes regardless of the version.

public class VersionedClass {
  @Since(1.1) private final String newerField;
  @Since(1.0) private final String newField;
  private final String field;

  public VersionedClass() {
    this.newerField = "newer";
    this.newField = "new";
    this.field = "old";
  }
}

VersionedClass versionedObject = new VersionedClass();
Gson gson = new GsonBuilder().setVersion(1.0).create();
String jsonOutput = gson.toJson(someObject);
System.out.println(jsonOutput);System.out.println();gson = new Gson();
jsonOutput = gson.toJson(someObject);
System.out.println(jsonOutput);

======== OUTPUT ========
{"newField":"new","field":"old"}
{"newerField":"newer","newField":"new","field":"old"}

FIX: Drush can't update Drupal to 7.28

Recently Drupal 7.28 is released. Since I've setup the update notification on some sites, then I've got so many emails from my drupal sites. As usual, I go to the web server, run the command "drush up" to upgrade the core and the modules. Everything looks fine as following:

 Name    Installed Version  Proposed version  Message  

 Drupal  7.27               7.28              Updates available

Update information last refreshed: Thursday, 05/15/2014 - 09:30

Code updates will be made to drupal core.

WARNING:  Updating core will discard any modifications made to Drupal core files, most noteworthy among these are .htaccess and robots.txt.  If you have made any modifications to these files, please back them up before updating so that you can re-create your modifications in the updated version of the file.

Note: Updating core can potentially break your site. It is NOT recommended to update production sites without prior testing.

Do you really want to continue? (y/n): y

Project drupal was updated successfully. Installed version is now 7.28.

Backups were saved into the directory /home/ubuntu/drush-backups/drupal/20140515073230/drupal.                                                                                                                                                                       [ok]

No database updates required                                                                                                                                                                                                                                         [success]

'all' cache was cleared.                                                                                                                                                                                                                                             [success]

Finished performing updates.                                                                                                                                                                                                                                         [ok]

So I supposed the core is updated to 7.28. BUT, the update notification emails come again and again. Then I ran "crush st" to check the status of the drupal installation, it showed:

$ drush st

 Drupal version                  :  7.27

Unbelievable, right? Drush cheats me on that ;)

So it seems a manual update is unavoidable, but I want to give Drush a second chance. So here are the command set to update drupal core to 7.28.

cd /tmp

drush dl

sudo rsync -rltD --delete --exclude 'sites' /tmp//drupal-7.28/ .

cd /path/to/web/root

drush updatedb

drush pm-update

Now I get a right upgraded Drual with 7.28.

$ drush st

 Drupal version                  :  7.28

HOWTO: Make Google Charts SVG responsible and printable with full page width

Google Charts is widely used for a while. It's no doubt that it is easy to use and have great documentation. But, it has also many limitations. One problem I recently discovered is printing. Since the SVG that is generated by Google Charts is NOT responsible. If the user wants to print the page, the result only shows part of the charts since the Google Charts adds a CSS style like "overflow:hidden" to the SVG.

What I want is very simple, the user gets a printed result like WYSIWYG. After different approaches, I came to the idea of Image Replacement. 

The idea: since the generated SVG doesn't response to width changes, we have to use a responsive image instead of the SVG to get the perfect print result.

So here is the implementation. :)

HTML:

<div id='timeline'></div>

<div id='timeline_print'></div>

CSS:

@media print {

    #timeline_print {

        width: 100%;

    }

}

JavaScript(assumed that jQuery is loaded, this.chart refers to the Google Charts object):

var beforePrint = function() {
    $("#timeline_print").html('<img src="' + this.chart.getImageURI() + '">');
    $("#timeline").addClass('hidden');
};
var afterPrint = function() {
    $("#timeline_print").empty();
    $("#timeline").removeClass('hidden');
};
if (window.matchMedia) {
    var mediaQueryList = window.matchMedia('print');
    mediaQueryList.addListener(function(mql) {
        if (mql.matches) {
            beforePrint();
        } else {
            afterPrint();
        }
    });
}

window.onbeforeprint = beforePrint;
window.onafterprint = afterPrint;

FIX: Unable to download data from https://rubygems.org/ - certificate verify failed

I've used rvm for a while to manage my ruby installations and it works great. Today I've tried updating my gems with gem update and it tells me "nothing is to be updated". Eh? At least I know cocoapods is updated from my installed 0.24 to 0.26. What happened?

Then I tried to update gems manually. Firstly:

> gem install cocoapods
ERROR:  Could not find a valid gem 'cocoapods' (>= 0), here is why:
          Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz)

 Great! That's the reason. There is a long long list of the issue under https://github.com/rubygems/rubygems/issues/515

The solution suggested are:
1. use an insecure connection to rubygems.org with:

> gem update  --source http://rubygems.org

It works. But it doesn't solve the problem

2. RVM should update its certificates:


> rvm osx-ssl-certs status all
Certificates for /etc/openssl/cert.pem: Old.


> rvm osx-ssl-certs update all
Updating certificates for /etc/openssl/cert.pem: Updating certificates in '/etc/openssl/cert.pem'.
mkdir: /etc/openssl: Permission denied
Admin password required for 'mkdir -p /etc/openssl':
Updated.

Then everything should be fine now.

A detailed information can be found at http://railsapps.github.io/openssl-certificate-verify-failed.html

For non-RVM and non-MAC users, here is the answer: http://stackoverflow.com/questions/19150017/ssl-error-when-installing-rubygems-unable-to-pull-data-from-https-rubygems-o

FIX: A blank view appears after QLPreviewController dismissed in iOS 7

Recently when I am working with iOS 7, I encounter the following problem: If the modalPresentationStyle of an view controller is set as UIModalPresentationFormSheet or UIModalPresentationPageSheet and after one uses the QLPreviewController once in the view controller and dismisses the Quick Look, a blank / gray view will appear on the screen instead of the presented view controller. This blank view cannot be dismissed or interacted.

That seems a serious bug in iOS 7. :(

After some days trying errors, I've found the following workaround:

in the presenting ViewController:

if ([self DeviceSystemMajorVersion] >= 7) {

modalVC.transitioningDelegate = self;

modalVC.modalPresentationStyle = UIModalPresentationCustom;

} else {

modalVC.modalPresentationStyle = UIModalPresentationFormSheet;

}

The function to detect iOS 7:

- (NSUInteger) DeviceSystemMajorVersion {

    static NSUInteger _deviceSystemMajorVersion = -1;

    static dispatch_once_t onceToken;

dispatch_once(&onceToken, ^{

  _deviceSystemMajorVersion = [[[[[UIDevice currentDevice] systemVersion] componentsSeparatedByString:@"."] objectAtIndex:0] intValue];

 });

return _deviceSystemMajorVersion;

}

The presenting view controller should conform to the protocol UIViewControllerAnimatedTransitioning and UIViewControllerTransitioningDelegate, in order to use the custom transaction style that indroduced in iOS 7. Continue to add these methods:

- (id<UIViewControllerAnimatedTransitioning>)animationControllerForPresentedController:(UIViewController *)presented

                                                                  presentingController:(UIViewController *)presenting

                                                                      sourceController:(UIViewController *)source {

return self;

}

- (void)animateTransition:(id <UIViewControllerContextTransitioning>)transitionContext {

UIView *inView = [transitionContext containerView];

    UIView *toView = [transitionContext viewControllerForKey:UITransitionContextToViewControllerKey].view;

    UIView *fromView = [transitionContext viewControllerForKey:UITransitionContextFromViewControllerKey].view;

 

 UIView *preferenceOverlay = [[UIView alloc] initWithFrame:inView.frame];

 preferenceOverlay.backgroundColor = [UIColor blackColor];

 preferenceOverlay.alpha = 0;

 [inView addSubview:preferenceOverlay];



 toView.frame = CGRectMake(0, 0, 540, 540);

 toView.center = CGPointMake(CGRectGetMidX(inView.frame), CGRectGetMidY(inView.frame));



 [inView addSubview:toView];

 

    [UIView animateKeyframesWithDuration:(1.0) delay:0 options:0 animations:^{

  preferenceOverlay.alpha = 0.4;

    } completion:^(BOOL finished) {

        [transitionContext completeTransition:finished];

    }];

}

Then in the presented view controller:

-(void)viewWillLayoutSubviews {

 [super viewWillLayoutSubviews];



if ([self DeviceSystemMajorVersion] >= 7) {

if (QLOpened) {

self.view.frame = CGRectMake(0, 0, 540, 540);

CGFloat xCenter = CGRectGetMidX(self.view.superview.frame) + 125;

CGFloat yCenter = CGRectGetMidY(self.view.superview.frame) - 125;

self.view.center = CGPointMake(xCenter, yCenter);

   NSLog(@"Center X:%f Y:%f",xCenter,yCenter);

  }

 }

}

Then let the view controller to conform the protocol QLPreviewControllerDelegate and add the following method:

- (void)previewControllerWillDismiss:(QLPreviewController *)controller {

NSLog(@"QLView dismissed");

 [self.view setNeedsLayout];

}

DONE!

If you have the centering problem of the modal view controller, try fine-tuning the center point of the method viewWillLayoutSubviews

HOWTO: Compile Sigil under Mac OS X from source codes

Sigil is a very powerful ePub file publisher, which can be used to create, modify and edit ebooks. Since the source codes of Sigil is put on GitHub(https://github.com/user-none/Sigil/), I have to compile Sigil directly from source codes. Now here is the HOWTO。 :)

Firstly, you need brew(http://brew.sh) to let it install different packages for compiling.

Once brew is installed, you should install the following packages using terminal:

> brew install cmake
> brew install qt5

> export Qt5_DIR=/usr/local/opt/qt5

Check out the source codes from GitHub or download the ZIP . Go to the directory in Terminal and execute the following commands:

> mkdir build

> cd build

> cmake -DFORCE_BUNDLED_COPIES=1 -DCMAKE_BUILD_TYPE=Release ..

> make

At the end in the folder "bin" is the compiled Sigil.app, which can be dragged into Application folder.

DONE!

FIX: Running PEAR, PECL & Co. under Mac OS X Mavericks DP6

When I tried to use pear under Mac OS X Mavericks DP6, I got a very unhelpful error message:

$ pecl

Could not open input file: /usr/lib/php/peclcmd.php

It seems that pear & pecl are not preinstalled! No problem, at least Mavericks provides an install package.

sudo php -d detect_unicode=0 /usr/lib/php/install-pear-nozlib.phar

Then the nightmare began:

$ sudo pecl install uploadprogress

downloading uploadprogress-1.0.3.1.tgz ...

Starting to download uploadprogress-1.0.3.1.tgz (9,040 bytes)

.....done: 9,040 bytes

4 source files, building

running: phpize

grep: /usr/include/php/main/php.h: No such file or directory

grep: /usr/include/php/Zend/zend_modules.h: No such file or directory

grep: /usr/include/php/Zend/zend_extensions.h: No such file or directory

Configuring for:

PHP Api Version:

Zend Module Api No:

Zend Extension Api No:

building in /private/tmp/pear/temp/pear-build-rootTuNmJz/uploadprogress-1.0.3.1

running: /private/tmp/pear/temp/uploadprogress/configure

checking for grep that handles long lines and -e... /usr/bin/grep

checking for egrep... /usr/bin/grep -E

checking for a sed that does not truncate output... /usr/bin/sed

checking for cc... cc

checking whether the C compiler works... yes

checking for C compiler default output file name... a.out

checking for suffix of executables...

checking whether we are cross compiling... no

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether cc accepts -g... yes

checking for cc option to accept ISO C89... none needed

checking how to run the C preprocessor... cc -E

checking for icc... no

checking for suncc... no

checking whether cc understands -c and -o together... yes

checking for system library directory... lib

checking if compiler supports -R... no

checking if compiler supports -Wl,-rpath,... yes

checking build system type... i386-apple-darwin13.0.0

checking host system type... i386-apple-darwin13.0.0

checking target system type... i386-apple-darwin13.0.0

checking for PHP prefix... /usr

checking for PHP includes... -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib

checking for PHP extension directory... /usr/lib/php/extensions/no-debug-non-zts-20100525

checking for PHP installed headers prefix... /usr/include/php

checking if debug is enabled... no

checking if zts is enabled... no

checking for re2c... no

configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers.

checking for gawk... no

checking for nawk... no

checking for awk... awk

checking if awk is broken... no

checking whether to enable uploadprogress functions... yes, shared

checking for ld used by cc... /Applications/Xcode5-DP6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld

checking if the linker (/Applications/Xcode5-DP6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no

checking for /Applications/Xcode5-DP6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r

checking for BSD-compatible nm... /usr/bin/nm

checking whether ln -s works... yes

checking how to recognize dependent libraries... pass_all

checking for ANSI C header files... yes

checking for sys/types.h... yes

checking for sys/stat.h... yes

checking for stdlib.h... yes

checking for string.h... yes

checking for memory.h... yes

checking for strings.h... yes

checking for inttypes.h... yes

checking for stdint.h... yes

checking for unistd.h... yes

checking dlfcn.h usability... yes

checking dlfcn.h presence... yes

checking for dlfcn.h... yes

checking the maximum length of command line arguments... 196608

checking command to parse /usr/bin/nm output from cc object... ok

checking for objdir... .libs

checking for ar... ar

checking for ranlib... ranlib

checking for strip... strip

checking for dsymutil... dsymutil

checking for nmedit... nmedit

checking for -single_module linker flag... yes

checking for -exported_symbols_list linker flag... yes

checking if cc supports -fno-rtti -fno-exceptions... yes

checking for cc option to produce PIC... -fno-common

checking if cc PIC flag -fno-common works... yes

checking if cc static flag -static works... no

checking if cc supports -c -o file.o... yes

checking whether the cc linker (/Applications/Xcode5-DP6.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes

checking dynamic linker characteristics... darwin13.0.0 dyld

checking how to hardcode library paths into programs... immediate

checking whether stripping libraries is possible... yes

checking if libtool supports shared libraries... yes

checking whether to build shared libraries... yes

checking whether to build static libraries... no

creating libtool

appending configuration tag "CXX" to libtool

configure: creating ./config.status

config.status: creating config.h

running: make

/bin/sh /private/tmp/pear/temp/pear-build-rootTuNmJz/uploadprogress-1.0.3.1/libtool --mode=compile cc  -I. -I/private/tmp/pear/temp/uploadprogress -DPHP_ATOM_INC -I/private/tmp/pear/temp/pear-build-rootTuNmJz/uploadprogress-1.0.3.1/include -I/private/tmp/pear/temp/pear-build-rootTuNmJz/uploadprogress-1.0.3.1/main -I/private/tmp/pear/temp/uploadprogress -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib  -DHAVE_CONFIG_H  -g -O2   -c /private/tmp/pear/temp/uploadprogress/uploadprogress.c -o uploadprogress.lo

mkdir .libs

 cc -I. -I/private/tmp/pear/temp/uploadprogress -DPHP_ATOM_INC -I/private/tmp/pear/temp/pear-build-rootTuNmJz/uploadprogress-1.0.3.1/include -I/private/tmp/pear/temp/pear-build-rootTuNmJz/uploadprogress-1.0.3.1/main -I/private/tmp/pear/temp/uploadprogress -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext -I/usr/include/php/ext/date/lib -DHAVE_CONFIG_H -g -O2 -c /private/tmp/pear/temp/uploadprogress/uploadprogress.c  -fno-common -DPIC -o .libs/uploadprogress.o

In file included from /private/tmp/pear/temp/uploadprogress/uploadprogress.c:23:

/private/tmp/pear/temp/uploadprogress/php_uploadprogress.h:34:10: fatal error: 'php.h' file not found

#include <php.h>

         ^

1 error generated.

make: *** [uploadprogress.lo] Error 1

ERROR: `make' failed

No way! The /usr/include doesn't exist for phpize....Hours of trying error and searching... Thanks a post from Homebrew community, I got that problem fixed through:

sudo ln -s /Applications/Xcode5-DP6.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/ /usr/include