I’m blogging over at http://www.mattmakai.com/ now. Tumblr’s been great over the past two years but I wanted more flexibility to revamp my web presence. My latest posts since January 1, 2012 are all over on my new site.
Link: Matt Makai’s Blog
At last, a version of Django that isn’t a maintenance release is out, albeit in alpha form (not for production use):
https://www.djangoproject.com/weblog/2011/dec/22/14-alpha-1/
I’m currently researching build tools. I need a build and configure tool for a iOS/Android/BlackBerry mobile app with a single set of core components but many configurations for different app deployments. I could hack something together with Python or Bash shell scripts, but there’s a reason why build tools exist. Options:
- Ant/Ivy - doable, but loads of XML to write
- Maven - my project structure does not lend itself to Maven’s rigid conventions
- Gradle - I’ve never used it before, so let’s take a look
Building and Testing with Gradle by Tim Berglund and Matthew McCullough is an O'Reilly book was the logical pick. I saw Matt speak on Hadoop & Git at No Fluff Just Stuff last year and really enjoyed his clear, concise explanations. This book is also clear, concise, and only took a few hours to read and work through the examples.
My notes for the book are on my programming notes Github repository. The notes won’t make as much sense without reading the book, so I suggest picking up the eBook copy over at O'Reilly.
Over the next couple of days I’ll be working through producing a Gradle build for the mobile app I’m working on for Excella. I’ll post my full impressions of Gradle after I’ve had more time with the tool.
Android and BlackBerry expect two different folder locations for resources. Android has its assets/www folder while BlackBerry expects just a www folder under the project root directory. Since the BlackBerry .cod file is opaque after compilation, it makes it difficult to understand how resources are structured in the file.
I found that putting the BlackBerry config.xml file under assets/www and referencing my HTML file within the assets/www folder worked fine as long as there is a www folder in the root of the project which contains plugins.xml, the ext folder with the phonegap.1.2.0.jar file, and a resources directory with my icons and splash screen image.
Make sure to modify the BlackBerry build.xml file to reference the config.xml file in the assets/www folder and to include both the assets/www folder as well as the www under the project’s root directory.
With this folder set up, I was able to successfully deploy to both Android and BlackBerry without duplicating any files within the project structure.
Once I integrate iOS into the project structure I’ll post the code on Github.
I spent a couple of hours yesterday evening trying to figure out why I only got a blank white screen after the app splash screen on the BlackBerry 9930 with a JQM 1.0 and PhoneGap 1.2 app that worked fine on the 9550 simulator.
Apparently this problem has been duplicated and the “recommended” fix is to use JQM Alpha 4 (not an option for me in this case). See this post on Google Groups.
I’ve opened an outstanding Github issue ticket for the problem and hopefully can extract the code for analysis.
Dear BlackBerry,
I’m going out of my way to develop a cross-platform app that will work on your devices. Don’t inconvenience me by making me download some “Akamai Net Session” software which I have no idea what it does before I can even download your simulator or SDK files.
Thanks,
Matt
I upgraded from PhoneGap (Apache Callback) 1.1 to version 1.2 today. Unfortunately, I encountered the following cryptic stacktrace:
ERROR/AndroidRuntime(9469): FATAL EXCEPTION: Thread-9
java.lang.RuntimeException: Can’t create handler inside thread that has not called Looper.prepare()
at android.os.Handler.<init>(Handler.java:121)
at android.webkit.WebView$PrivateHandler.<init>(WebView.java:7341)
at android.webkit.WebView.<init>(WebView.java:416)
at android.webkit.WebView.<init>(WebView.java:967)
at android.webkit.WebView.<init>(WebView.java:957)
at android.webkit.WebView.<init>(WebView.java:948)
at com.phonegap.DroidGap.init(DroidGap.java:268)
at com.phonegap.DroidGap.loadUrlIntoView(DroidGap.java:381)
at com.phonegap.DroidGap.access$300(DroidGap.java:159)
at com.phonegap.DroidGap$3.run(DroidGap.java:537)
at java.lang.Thread.run(Thread.java:1102)
The same stacktrace is found under issue #23 for PhoneGap.
Unfortunately PhoneGap 1.2 isn’t patched yet to accomodate the issue. So there’s 2 options if you hit this snag:
- Disable the splash screen on Android
- Download the latest nightly PhoneGap build on Github until PhoneGap 1.3 is released
Hopefully this issue will be resolved soon with a new PhoneGap release (maybe a 1.2.1 release)?
Recent college grads and young professionals, listen up: you’ve got 5-10 years. The labor market has been changing for a couple of decades and will continue in its trajectory. Today’s reality is that large companies are willing to pay you a decent wage for your first 5-10 years worth of work. After that, the gig is up.
Depending on your industry, after your first 5-10 years, you need to prove you’re worth real money. You can do that in one of two ways, depending on your personal strengths and weaknesses (be honest with yourself about them). The two choices are:
- Start your own firm
- Join an existing small firm where you can make a dramatic direct impact on the growth of the organization
There will be no other reliable options. There will always be other options, but they won’t be reliable. They are mirages held out by large companies to trick you into continuing to work for them until they lay you off. For example, you could try to get into mid-management and “climb the ladder.” Chances are high you will be laid off in that position long before you ever reach the executive ranks. There’s simply not enough “executive” positions to go around.
So knowing you have 5-10 years, you need to prepare today for that inevitable future. Whether you work for a non-profit, a law firm, a tech firm, or even in government, you need to figure out how you can successfully start your own firm or join an existing firm and be directly responsible for its growth. That’s the reality for our generation. If we embrace it, we can make it work for us.
I came across this blog post on the Python Ecosystem while reading Hacker News yesterday. What a fantastic post. Highly recommended reading for aspiring Python developers.
Link: Python Ecosystem
To understand Django, it helps to know its origins and how the framework has evolved. Django’s developers have added many features since the framework’s 1.0 release back in September 2008. Some of the major additions include aggregation support in the ORM, multi-database support, CSRF protection, a messaging framework, and many improvements to the models framework. This post outlines the major framework changes Django has gone through from 1.0 through the current stable 1.3 release. The intention for 1.x releases is that only minor code changes are necessary to transition Django projects from one version to another.
Django 1.0
(1.0 SVN Revision 8961, 1.0.4 SVN Revision 11613) [1]
Django 1.0 was released September 3, 2008 after a three year public incubation period and a total of five years of development [2]. Release 1.0 included features that are still core to the framework today, including the Model-Template-View (MTV) architecture, Object-Relational Mapper (ORM) models, explicit URL resolution with regular expression support, and a lightweight template system.
Django 1.1
(1.1 SVN Revision 11366, 1.1.4 SVN Revision 15477)
Django 1.1 was released Jul 29, 2009, just shy of 11 months after the official 1.0 release [3]. Version 1.1 included the following new features:
- Aggregate query support in the built-in object relational mapper
- Improvements to models
- Better support for unit testing through client object’s support functions
- URL namespaces
Django 1.2
(1.2 SVN Revision 13285, 1.2.5 SVN Revision 15476)
Django 1.2 was released May 17, 2010, approximately 10 months after the 1.1 release [4]. Major features added to Django in this release:
- Mandatory Cross Site Request Forgery protection for POSTs
- Support for more than one database in a single Django project
- Model validation based on the existing Forms validation mechanism
- User messages support through sessions and cookies
- Configurable email backends
Django 1.3
(1.3 SVN Revision 15906, 1.3.1 SVN Revision 16771)
Django 1.3 was released on March 23, 2011 [5]. New features in Django 1.3 included:
- Class-based views
- Support for Python’s standard logging mechanisms
- A new contrib app for serving static files
Django 1.4 and Beyond
There is currently no release date set for Django 1.4 although work continues in the public development branch. Django 1.4 will drop support for Python 2.4. The motivation behind the change is to use more context managers, a creation from Python 2.5, and make the internal Django code better. I wrote a post on Django 1.4 and how one of the Django core committers, Alex Gaynor, sees Django 1.4.
[1] Django SVN Revision 8961
[2] Django 1.0 Release Announcement
[3] Django 1.1 Release Announcement
[4] Django 1.2 Release Announcement
[5] Django 1.3 Release Announcement