Monthly Archives: 2011-3

Mobile browser cache sizes

Posted on by
Reply

iPhone can only hold 15 x 25 kb objects in cache is not true. At least anymore, I wonder if it ever was.

Android and iOS boast 2 MB – 4 MB cache for a session. This should easily include your Javascripts, no matter what kind of monster sizes you are serving. So the cache exhaustion should not be a problem in everyday usage.

This also means that mobilize.js should not, if using the cloud version which properly set expire headers, cause extra traffic after initial load.

Enable PHP log output (error_log) on XAMPP on OSX

Posted on by
1

If you are using XAMPP to develop PHP software (WordPress, Joomla!) on OSX you might want to get some advanced logging output from your code. PHP provides nice error_log() function, but it is silent by default. Here are short instructions how to enable it and follow the log.

Use your favorite editor to edit php.ini file in /Applications/XAMPP/etc/php.ini – sudo priviledges needed, Smultron does it out of the box.

Change lines:

log_errors = Off
;error_log = filename

To:

log_errors = on
error_log = /tmp/php.log

Restart Apache using XAMPP controller in Finder -> Applications.

Now use the following UNIX command to see continuous log flow in your terminal:

tail -f /tmp/php.log

See also the earlier article about XAMPP and file permissions.

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Everyone loves and hates console.log()

Posted on by
3

2012-02: Updated for JSLint compatibility

console.log()  is the best friend of every Javascript junkie. However, the lack of it isn’t. console.log() function is only available in Webkit based browsers and with Firebug in Firefox. It’s the infamous situation that someone leaves console.log() to Javascript code, doesn’t notice its presence, commits the file and suddenly all Javascript on the production server stops working for Internet Explorer users….

To tackle the lack of console.log() problem there are several approaches.

1. Use dummy placeholder if console is missing

This snippet wraps console.log (need to repeat for console.error etc.):

    // http://opensourcehacker.com/2011/03/15/everyone-loves-and-hates-console-log/
    // Ignore console on platforms where it is not available
    if (typeof(window.console) == "undefined") { console = {}; console.log = console.warn = console.error = function(a) {}; }

Pros

  • Easy

Cons

  • Need to add to every Javascript file
  • Messes with global namespace

2. Use module specific log function

This makes your code little bit ugly, more Java like. Each Javascript module declares their own log() function which checks the existence of console.log() and outputs there if it’s present.

mfabrik.log =function(x) {
 if(console.log) {
 console.log(x);
 }
}

mfabrik.log("My log messages")

Pros

  • Easy to hook other logg
  • You can disable all logging output with one if

Cons

  • Not as natural to write as console.log()
  • Need to add to every Javascript module

3. Preprocess Javascript files

Plone (Kukit / KSS) uses this approach. All debug Javascript is hidden behind conditional comments and it is filtered out when JS files are bundled for the production deployment. (The preprocessing code is here in Python for those who are interested in it).

if (_USE_BASE2) {
 // Base2 legacy version: matchAll has to be used
 // Base2 recent version: querySelectorAll has to be used
 var _USE_BASE2_LEGACY = (typeof(base2.DOM.Document.querySelectorAll) == 'undefined');
 if (! _USE_BASE2_LEGACY) {
 ;;;     kukit.log('Using cssQuery from base2.');

Pros

  • Makes production Javascript files lighter
  • Make production Javascript files more professional – you do not deliver logging statements indented for internal purposes for your site visitors

Cons

  • Complex – preprocessing is required

4. Commit hooks

You can use Subversion and Git commit hooks to check that committed JS files do not contain console.log. For example, Plone repositories do this for the Python statement  import pdb ; pdb.set_trace() (enforce pdb breakpoint).

Pros

  • Very robust approach – you cannot create code with console.log()

Cons

  • Prevents also legitimate use of console.log()
  • Github, for example, lacks possibility to push client-side commit hooks to the repository cloners. This means that every developer must manually install commit hooks themselves. Everything manual you need to do makes the process error prone.

5. Other approaches?

Please tell us!

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+

Mirroring App Engine production data to development server using appcfg.py

Posted on by
7

Google App Engine provides some remote API functionality out of the box. One of the remote API features  is to download data from the development server. After downloading, then you can upload the downloaded data to your development server, effectively mirroring the content of the production server to your local development server. This is very useful if you are working CMS, sites, etc. where you want to test new layout or views locally against the old data before putting them to the production.

First enable remote API in app.yaml:

- url: /remote_api
  script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.py
  login: admin

Note: Using builtins app.yaml directive didn’t work for me some reason, so I had to specify remote API URI manually.

After this you should be able to download data. Here I am using appcfg.py global installation on OSX. Below is the command and sample output.

appcfg.py -e yourgoogleaccount@gmail.com download_data --url=http://yourappid.appspot.com/remote_api --filename=data.sqlite3
...
Downloading data records.
[INFO    ] Logging to bulkloader-log-20110313.222523
[INFO    ] Throttling transfers:
[INFO    ] Bandwidth: 250000 bytes/second
[INFO    ] HTTP connections: 8/second
[INFO    ] Entities inserted/fetched/modified: 20/second
[INFO    ] Batch Size: 10
...
[INFO    ] Have 1803 entities, 0 previously transferred
[INFO    ] 1803 entities (972883 bytes) transferred in 91.0 seconds

data.sqlite3 is your production database dump in SQLite 3 binary format (used internally by the development server).

If you have sqlite command line tool installed you can explore around the data dump there:

sqlite3 data.sqlite
SQLite version 3.7.5
Enter ".help" for instructions
Enter SQL statements terminated with a ";"

sqlite> .tables
Apps                                   your-app!Model1!Entities
IdSeq                                  your-app!Model1!EntitiesByProperty
Namespaces                             your-app!Model2!Entities
bulkloader_database_signature          your-app!Model2!EntitiesByProperty
your-app!!Entities                     result
your-app!!EntitiesByProperty

Now you can upload data.

Note: Even though there exists option –use_sqlite for dev_appserver.py looks like it cannot directly use the database file produced by download_data. You cannot just swap database files, you need upload the downloaded data to the development server.

Start your development server:

dev_appserver.py .

In another terminal, go to downloaded data.sqlite folder and give the command:

appcfg.py upload_data --url http://localhost:8080/remote_api --file=data.sqlite --application=yourappid

It will ask you for credentials, but it seems that any username and password is accepted for the local development server.

Now you can login to your local development server to explore the data:

http://localhost:8080/_ah/admin

Ensure your data got copied over using Data Viewer:

http://localhost:8080/_ah/admin

\"\" Subscribe to RSS feed Follow me on Twitter Follow me on Facebook Follow me Google+