apk zipalign

Back in mid 2005 I worked on a project for customer wherein I was generating "Froogle Feed" data for the customer's e-commerce sites. For some reason, the project never went live. Suddenly, a request shows up from the customer mentioning "Froogle Project" and asking for a couple of features.

I have no memory of how I accomplished this project in the first place. I don't know if the customer does either. I just have a couple of features in an email project and zero context. Does the customer remember the experimental work we did a couple of years ago? Does he remember the UI?

The big problem is that aside from a couple of emails and basecamp messages, and a couple of generated 'feed' files, I have nothing for this project. Looking through source code history returns nothing. Looking through the current site (an old Zope 2 based site, built out of page templates, python scripts, and SQL Methods) yields nothing either. Unfortunately, there's not a lot of history in the site. And if the feature in question never went live, there's (of course) not going to be ANY history.

I dug through a big folder of printouts and such collected over the eight-plus years of history with this customer. Nothing.

I finally turned to notepads and notebooks, and did manage to find a couple of notes in a couple of different places. And digging through some basecamp messages yielded a mention of a 'froogle.py' file in a development instance that was not put into source control (CVS at the time). That development server was killed off long ago. It may have been hobbling around, but after moving offices twice in the last year or so, the number of internal servers is nearly zero. Long unused development servers tend not to get plugged back in.

Some lessons learned:

1. Always put a date stamp on handwritten notes. This is now a habit for me, but it apparently wasn't a habit back in 2005. I did find some dates on some pages and used that to backtrack to when this work was initially done (using date stamps on Basecamp and email messages). A side lesson to this is to always include the year when date stamping.


2. Always use source control, even for unfinished projects. If this one file had been checked into CVS, I would be a bit less stressed right now. I'm far less familiar with this customer's site now than I was then and trying to remember how I built multiple Froogle files and put them into a Zip file would be great knowledge right now, even if the format has changed. Since moving to Git, it's easier to keep dead branches in the central repository. CVS made branching so painful that we never would start a 'froogle-feed' branch. Even if that branch never goes live, it's damn useful to have.


3. Don't trust development servers. They may not be around forever, and odd little unfinished files or projects can get lost very easily over time. May not seem like a big deal, but sometimes these little projects come roaring back to life after five years. We now do most of our development on our desktop machines. When we get a new machine, all of our files roll over. Central servers work if it's a central common copy (like a master account server). I've found that development servers just lose luster over time, and tend to get very far behind in terms of hardware and core OS performance. Plus they tend not to have the kind of machine/account migration tools that desktop OS's like Mac OS X have.

• Improved Customer Targeting Based on Conversion Rates


• Improved Brand Image/Awareness


• Customer Satisfaction

• Customer Stickiness / Increase of Repeat Purchase


• New Customer Acquisition


• Viral Marketing of Social Media Inside the Applications


• Product Differentiation


• Up Sale Opportunities Created


• New Services offered as a result of the Mobile Initiative

• Proximity and Non-proximity Payments


• Dynamic Location Based Messaging


• Line Busting


• Mobile Phone Based Reviews/Video


• Service and Repair Functions


• In-store Interactivity

• Age of the user


• Device that is being used


• Social economic status


• Quality of the mobile marketing campaign


• Brand affinity of the of the mobile user

• Augmented Reality


• Growth of the Mobile Web (100m new users a year)


• Fix of the GPS battery drain problem


• Custom mobile site and applications for campaigns


• Linking CRM databases into mobile marketing


• New entrants into mobile


• Coupons to incorporate time and context


• Mobile Ad networks will continue to grow in popularity


• Growth in Mobile Search


• Growth in M-Commerce


• Competition for the Mobile Wallet

• Augmented Reality


• Barcode/ Scanable Coupons through Text Messaging


• Coupons for Virtual Mobile Malls


• Dynamic Promotional Ranges that Optimize Merchandising/Promotions


• Mobile Promotional Cooperation allowing for products and complementary products

• Location based couponing


• Full screen image zoom of products with pan capabilities


• Browse functionality (tied into a company’s specific product taxonomy used by the .com)


• Videos


• Social networking


• Customized promotions for black Friday

• Mobile Workforce Management


• Inventory Management


• Demand Planning


• Business Intelligence

• Platform and Device Knowledge


• Business Requirements Gathering


• Back-end ERP Blueprinting


• Knowledge share of where technology is going (short-term and long-term)


• Custom Solution Proposals (get you what you need, not what a firm has to sell you)

This Post by Giles Bowkett goes into why the iPad is NOT where creativity goes to die. It's something I have been meaning to write up myself, but haven't gotten around to doing so just yet. I do hope to write more on the subject, but until then I will just add this: if the iPad was only about consumption, I would not have bought one. For months, dating back to when the iPad was just an ever growing rumor, I would show friends apps like Looptastic and Jasuto and say "imagine this on a bigger screen!"

I didn't even see the i-Electribe app coming. I have a real Korg Electribe as well. The iPad implementation is just stunning. (I also have both a real Korg MS-10 and a DS-10 cartridge for Nintendo DS. It's fun to have these real tools, and then have software representations of them in unusual places. A VST plug-in is just so boring compared to an iPad or DS surface, and both of those surfaces are far more fun to use on trains or patios than a laptop).

The iPhone has already proven itself as a fun and capable device for making music, visual art, and even for writing. It's like the universal pocket notebook, capable of capturing not just words and doodles and snapshots but also drum beats and synth sounds and singing and on and on and on. The quantity and quality of creative apps for the iPhone is part of what excites me about the platform. The iPad just adds to that excitement.

Apple has announced an iPad ship date of Apr 3 for the wi-fi only edition, with the 3G model slated for late April. Pre-orders start next week.

I'm hoping for good magazine content, and I would be willing to pay. The web often sucks for magazine content as obtrusive advertising, annoying pagination (often in support of more obtrusive advertising), and random encounters with pay walls get in the way. And it just sucks to read on a computer screen. It's not the LCD display, but the position and layout of the screen that is frustrating.

I've had subscriptions to The Economist, The New Yorker, and Harper's in the past, and I'm starting to miss them as I've been trying to make more time for reading. The weeklies, especially, are the ones I would like to have electronically if I could pay on a month by month basis. Sometimes it's hard to keep up when life gets busy, and those weekly magazines can pile up quickly.

Finally, I'd love for the magazines to work offline. Then I think I could totally buy into the wi-fi only iPad. I'm already sold on the iPad, just can't decide which model to get. I don't leave the house or travel too often, and the iPhone is often good enough when I am out like that. But having the 3G as a pay-as-you-go option for the iPad could be handy on those occasional small trips.

Still, I think that when I take the train from SLC to DEN later next month, I will be much happier with traditional books and cameras than with a gadget, no matter how cool the gadget is. It's nice to just turn things off for a couple of days.

I think I just talked myself into the wi-fi only iPad.

Earlier today, I saw a question on Twitter asking "is there some setuptools extensions for uploading a sdist to a server over scp?" I responded with a "yes - we use buildutils' publish command for that."

Buildutils is a collection of useful extensions to Distutils. It hasn't been touched in a while, but it mostly works. It adds some commands like "stats", "pyflakes" (useful, but does not work with recent versions of PyFlakes), and "publish", which allows you to upload a release via SCP or SFTP.

The "publish" command is an extension that must be configured explicitly, so we do it in our 'setup.cfg'. We have a setup.cfg template that we use for all of our packages that uploads releases into one big directory. It looks like this:

; Enable the buildutils publish command
[global]
command_packages = buildutils.publish_command

; Set the destination of the publish command
[publish]
dist_dest = scp://@internalserver/path/to/releases/

; In one command, generate a distribution and checksum,
; upload them, and then clean out the build-related turds.
[aliases]
mkrelease = sdist checksum publish clean --all

We also use zc.buildout in-house, and I've been using that to ensure that I have Buildutils and setuptools-git (uses what's tracked by Git to generate the Manifest of files to include in the distribution package). In our buildout configs, I usually have a 'devtools' section that looks like this:

[devtools]
recipe = zc.recipe.egg:scripts
interpreter = py
eggs =
    current.package [test]
    buildutils
    setuptools-git

With the above, I get a 'bin/pbu' script that has the Buildutils and setuptools-git extensions installed. 'pbu' is a convenience command-line tool from Buildutils that is basically shorthand for 'python setup.py'. Using Buildout like this, I just ensure that the tools I need to generate and publish a distribution are available, no matter what machine I'm using. It's not needed, but I just find it convenient, particularly when other developers in our company need to generate a release from their machines and may not have remembered to install something like setuptools-git.