Friday, 29 June 2012

Reminder of my netbeans.conf file

This post is just meant to be an online reminder of my current OS X Netbeans 7.1 configuration so I can remember when I switch machines or upgrade my Netbeans version. It probably won't be too useful to others out there, but you're welcome to take a look at it nonetheless.

Also note that tuning JVM flags to work well on one machine or system configuration does not necessarily mean that it will work well on another. In fact, in some cases it can even make things worse when compared to the default settings. So if you decide to use some of the configuration below, you'll definitely want to tweak it to work well for your own machine.

Current netbeans.conf setup:

netbeans_default_options="-J-client -J-Xss2m -J-Xms1280m -J-Xmx1280m
-J-XX:PermSize=32m -J-XX:MaxPermSize=160m
-J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true -J-XX:+UseParNewGC
-J-XX:+UseConcMarkSweepGC -J-XX:+CMSParallelRemarkEnabled
-J-XX:ParallelGCThreads=3 -J-XX:+CMSClassUnloadingEnabled
-J-XX:+CMSPermGenSweepingEnabled -J-Xverify:none

(For 7.1.2, using 768m instead seems to work better as the major garbage collection cycles are much faster, and there seems to be a severe memory leak with larger amounts on the rig I'm using; the heap fills up significantly faster forcing more frequent major garbage collection cycles.)

What this is trying to do:

  • Provide enough memory to the JVM so Java doesn't frequently 'stop the world' in order to allocate more memory
  • Provide enough memory at the beginning so things don't grind to a halt in order to change the VM size early on
  • Use parallel garbage collection so Netbeans doesn't freeze for a long time when doing a major garbage collection cycle
  • Use several (but not all) cores for more efficient garbage collection
  • Make Netbeans more responsive at a slight cost of startup time
  • Provide a large enough amount of heap in order to delay time between major garbage collection cycles, also making Netbeans more responsive on average in the long run

Also note that some of the (default) flags in the configuration are there to make sure that Netbeans actually works in OS X.

Problems this is trying to solve:

The current system Netbeans is running on has ample physical memory available so a GB+ memory footprint is not an issue. However, other large programs are often used at the same time to create other resources for the same projects being developed using Netbeans. Garbage collection and memory allocations plague the system with a small VM size since opened projects can sometimes take up hundreds of MB. This creates the need to often wait for Netbeans to become responsive again after having it pause for a bit. In addition, when the system is idle for long enough, Netbeans is often paged to disk by OS X to make other programs more responsive (the current JVM flags will not be able to fix this, only more RAM will). Netbeans is often left running without restarting for weeks on end to work on parts of projects every day. The system is currently running OS X 10.7 Lion.

How well has this worked compared to the default:

The default configuration would often cause Netbeans to frequently halt when working on projects. The current configuration appears to be significantly better, without too much pausing. However, notable pauses do occur when forcing garbage collection (which doesn't appear to be necessary with the current configuration, but is still possible to do), and when loading paged memory back into RAM.


Tuesday, 26 June 2012

Navigate or redirect to a url using javascript


How do I use javascript to navigate to another url?


The follow are two ways that can redirect a user to another page:

// redirect without updating browser history

In the above and below example "my-next-page.html" should be replaced with your own URL. The above example shouldn't update the change of pages in the browser history, whereas the next example will.

// redirect and update in browser history
window.location.href = "my-next-page.html";


This was tested on the iOS 5.1 browser, Firefox 12, and with PhoneGap 1.5.0 on iOS 5.1. This should also work with most other browsers.

Saturday, 16 June 2012

Get the current route and url in a Symfony 2 controller


How do I get the current page's URL and current route in a Symfony 2 controller?


There are several ways to get the current page's route and url. One way is demonstrated here.

Current route

public function someAction(Request $request){
  // ... some code here

  $currentRoute = $request->attributes->get('_route');

  // more code ...
Current URL

public function someAction(Request $request){
  // ... some code here
  $currentRoute = $request->attributes->get('_route');
  $currentUrl = $this->get('router')
                     ->generate($currentRoute, array(), true);
  // more code ...

Alternatively, you can also generate the current URL directly without using the current route (thanks COil for the comment!)

$currentUrl = $this->getRequest()->getUri();

$currentUrl = $request->getUri();
//(see comments below, thanks Marcos for the comment!)


This was tested to work using Symfony2 version 2.0.4.


Include custom PHP-generated html code using Twig and Symfony 2


How do I embed custom HTML code (or scripts, etc.) into a page generated from a Twig template?

This is useful because:

For instance, if a page controller in Symfony 2 is used to generate a fancy widget, such as a calendar, you may want to have a way for the twig template to render this custom server-side generated code.


Pass the customized html string into a parameter in the twig template (customcodeparam, in the example below), and use the raw filter when rendering, e.g.

{{ customcodeparam | raw }}

Detailed example:

This example is not 100% complete, but it should include enough code to convey the idea of how to embed custom code into a twig template. This example assumes that you're already familiar with PHP and Symfony 2, and are learning Twig.

Imagine that you have a twig template named 'something.twig':

{# MyBundle:Page:something.twig #}
{% extends 'MyBundle:Page:index.html.twig' %}

{% block body %}
<h1>My awesome custom server-side-generated widget</h1>
{{ customcodeparam | raw }}
{% endblock %}

And also imagine that there was a page controller that rendered the template:

public function renderSomethingAction(){

  // replace the code below with your own
  $widgetcode = "<a href=''>Go Google!</a>";

  try {
         return $this->render('MyBundle:Page:something.html.twig',
                        'customcodeparam' => $widgetcode
  } catch (\Doctrine\ORM\NoResultException $e) {
         return null;

The resulting rendered html in the body block would look similar to the following:

<h1>My awesome custom server-side-generated widget</h1>
<a href=''>Go Google!</a>

(Note that the above code snippet does not include the html generated by MyBundle:Page:index.html.twig)


This probably goes without saying, but just a reminder that when including un-sanitized code that is generated by your server-side script on your web app, you should ensure that this code is safe. This is especially important to consider if the inserted code includes user-generated content (in case a user decides to sneak in a script, etc.). In other words, when using the trick in this post, the sanitization of the page is now up to you and not up to Twig. Pretty basic, I know, but I thought I should mention it anyway.

Saturday, 2 June 2012

Stop and complete all jQuery animations immediately


I'd like to stop and complete all jQuery animations immediately. At one point my web app needs to progress to another stage and the smooth completion of several pending, long animations isn't needed.


Edit: have a look at the comment below by Navigator regarding .finish() (see jQuery doc for the .finish() function). It's valid for jQuery 1.9 and above =) The points written in this post were tested for the jQuery version that was used when this post was originally written June 2012.

There are several ways to immediately stop and complete all animations that are currently running or pending in jQuery. Two of those methods will be outlined here.

One way to do this is by setting the parameter to true, e.g. = true;

This will cause all queued animations to skip immediately to the final frame and complete. Note that while this parameter is set to true all animations will skip to their final states. To allow jQuery animations later on, set this parameter back to false.

The second way is more of a shotgun approach and probably isn't a good way to skip over animations in the general case. However, if you haven't been keeping track of all the selected elements that have a pending animation and thereby can't use the stop() method on them individually, you can try selecting all elements and calling the stop() function, e.g.

$("*").stop(true, true);

Note that the latter is extremely inefficient since it selects all elements on the page!


These methods were tested on jQuery version 1.7.2 on Firefox 12.0 and the iOS 5.1 browser.

It isn't quite clear whether the method will skip currently running animations to the final frame.