Joe Maller.com

About that tablet…

Posting this before the big announcement tomorrow.

It feels somewhat obvious at this point, but I feel certain Apple with continue the iPhone’s conceptual move towards subordinate computing devices. The original iPod was a deliberate appliance, the iPhone is a computer limited by design. The biggest conceptual leap of the iPhone was that it couldn’t be used to create another iPhone. Even a years-old, bottom-end Mac or PC can still run software capable of designing microchips, programming an OS or running the CNC machines which fabricate the computer’s physical components. The iPhone and forthcoming tablet are more like electronic familiars. Without their master device, they’re forever limited in what they can do and become.

Jason Snell feels right on about resurrecting the iBook name and brand. “Canvas” sounds more like an app.

The price will either be $799 or $1199. $899 psychologically goes right to $1000 and if you’re over $1000, might as well go a little higher.

Hardware

There are several obvious components which will be present. GPS, accelerometer and vibration. I still don’t understand why my laptop doesn’t know where it is. It’s 2010, every moderately connected electronic device should have basic location awareness.

Size-wise, I’ll be surprised if the screen is much larger than 9 inches diagonal. I base that figure on an expectation that the short dimension of the tablet will not be much wider than an iPhone is tall, so overall dimensions around 4.25 x 7.5 inches. However, all size-predictions go out the window if Apple introduces some radical new input method.

The idea that it might not have a text-input interface is just dumb, it has to have some means of text input. The bigger question is what that interface will look or feel like. Simplest answer is the iPhone’s horizontal keyboard.

I don’t expect a user-facing camera, no one looks good photographed looking up from their own lap.

Dock connecter and headphone jack will the the only ports. Power, home button and volume will be the only physical interfaces.

Mostly though, I really hope Apple does something completely shoot-the-moon crazy. Word-keyboards instead of letters, or no keyboard at all. Make it round. Linked physical-virtual application rotation, screens with holes in them. Just something completely wild and new.

Connectivity:

Apple has no reason to abandon AT&T, they’re the perfect scapegoat. Should AT&T botch this too, then Apple opens up to other carriers. Should AT&T admit their networks are overwhelmed, then Apple opens up to other carriers. Either way, Apple puts the final nail in AT&T’s coffin. That’s good chess.

Apps and OS

iTunes App store only. All iPhone apps will work. There will be no windowing model like OS X, everything will be iPhone-style full screen apps. There won’t be a separate OS or SDK. iPhone OS 4 will be announced, but tablet development will be a checkbox in Xcode. Apple won’t have an SDK available on day one. As long as iPhone apps display well on the tablet, we’ll probably have to wait for WWDC to get the updated SDK. There’s no way developers are going to get a software tablet simulator before Apple ships the product. One other loosely connected thought; WWDC will see a unified SDK for iPhone, tablet and OS X. “All for one and one for all.”

No new iPhone will be announced, as that would detract from the main focus of the event. Whenever the new iPhone does appear, which I’m confident will be sometime before Summer, it will have a higher resolution display. The Android phones raised the bar on screen quality, Apple will match or beat them. There’s an outside chance for new iLife/iWork suites, but unless they’re somehow integrated with the new device, those aren’t happening either.

Flash

No chance in hell.

Post-mortem

Apple has posted the full announcement video.(Tech Specs)

Initially I was somewhat disappointed, but that’s starting to wear off as the reality sets in. Not just the reality of what the iPad is, but the universe it will live in.

Apple’s new A4 CPU is a very big deal, but the price was a biggest surprise. And it wasn’t just me, look at what Steve Jobs did to the S&P today:

S&P reversal after iPad price announced

The red line is the price trend before Apple’s price announcement, the green line is the trend after the announcement. Moments before the price was revealed, something caused the market to start tanking, that was stopped cold as soon as the numbers hit the screen.

Predicton-wise, I think I did fairly well. I was right about Apps, but not SDK availability. Very happily wrong about price but right about AT&T. Right about the camera and inputs, but wrong about the dimensions. I am really surprised it’s 4:3, that ratio feels so quaint.

There are some radical changes to the Cocoa Touch Human Interface Guidelines. I’m very curious to see how these changes transition to iPhone, and whether or not those changes will only possible on an iPhone screen with an increased pixel density.

One nice little thing I noticed at around 17 minutes into the video was a two-word contextual correction — haven’t seen that mentioned.

I really hope some of the UI stuff happening with Calendar and Mail find their way into 10.7.

I think my mom might be ditching her Kindle.


Faster and easier Gitweb installation

The idea of using make to build Gitweb isn’t just excessively complex, it’s also mostly unnecessary. Building gitweb.cgi from gitweb.perl only changes 19 of the source file’s 6734 lines (0.2%).

Fact is, to get Gitweb working only one line needs changing. After the following edit, all local configuration values can be loaded from a simple config file.

On line 546, insert the name of your config file:

-our $GITWEB_CONFIG = $ENV{'GITWEB_CONFIG'} || "++GITWEB_CONFIG++";
+our $GITWEB_CONFIG = $ENV{'GITWEB_CONFIG'} || "gitweb_config.perl";

A set of fully-documented configuration files is available in the Simple Gitweb Config project on Github, to help get things up and running quickly.

(more…)

Leave a comment
link: Jan 03, 2010 5:47 pm
posted in: misc.
Tags: , ,

Fixing a quarter million misnested HTML tags

These things just seem to find me, this time it was a very large database dump for a media site which was plagued with misnested HTML tags. Seriously. Just shy of 250,000 misnested pairs.

Here’s the pattern I came up with to fix it:

Find:
<(([^ >]+)(?:[^>]*))>(.*)<(([^ >]+)(?:[^>]*))>(.*)</\2>(.*)</\5>

Replace with:
<$1>$3<$4>$6</$5>$7</$2>
or, depending on your regex engine, your replace string might look like this:
<\1>\3<\4>\6</\5>\7</\2>

That handles all of the following cases:

<b><i>text</b></i>
<b>text<i>text</b>text</i>
<b><a href="#" target="_new">link</b>text</a>
<a href="#"><h2>text</a></h2>

Running the final substitution was ridiculously fast, Regular Expressions are magic.


How to spell Hanukkah 2009

How to spell Hanukkah 2009

Here are the 21 spellings in order of usage this year: Hanukkah, Chanukah, Hannukah, Hanukah, Chanukkah, Hanuka, Chanuka, Channukah, Hanukka, Chanukka, Hannuka, Hannukkah, Channuka, Channukkah, Hannukka, Xanuka, Channukka, Janukah, Janukkah, Janukkah and Chanuqa.

Previous years: 2004, 2005, 2006, 2007, 2008.


Convert Git branches to remote tracking branches

There are two ways to convert an existing branch to a remote tracking branch, using git config or directly editing the .git/config file.

In both of these examples, the local and remote branches are named “master”. The remote repository is “hub”.

git config commands

git config branch.master.remote hub
git config branch.master.merge refs/heads/master

editing .git/config

All the git config commands do is add the following to .git/config, editing the file manually has the same result.

[branch "master"]
	remote = hub
	merge = refs/heads/master

What would be nice is an additional config command, branch.<name>.track, which would split a full refspec, sending the relevant parts to the remote and merge commands.

Leave a comment
link: Dec 10, 2009 1:19 pm
posted in: misc.
Tags:

Django via CGI on shared hosting

Django just isn’t designed to run under CGI.
It won’t run under OS/2, either.*

Well ok, but running Django under CGI is not impossible. It just kind of really sucks. But anyway, here’s how I got it running on two standard cPanel shared hosts using plain old slow and clunky CGI.

virtualenv

First, install virtualenv. This makes locally managing modules fantastically easy by creating self-contained Python virtual environments. Installing couldn’t be simpler: Get the script, run the script, source your environment.

$ curl -LO http://bitbucket.org/ianb/virtualenv/get/tip.gz
$ tar -xvzf tip.gz
$ python src/virtualenv/virtualenv.py ~/python_virtualenv
New python executable in /home/joe/python_virtualenv/bin/python
Installing setuptools.............done.
$ source ~/virtual_python_env/bin/activate 

Now, install Django using pip, which was automatically installed by virtualenv. After sourcing the virtual environment, this works from anywhere.

$ pip install Django
Downloading/unpacking Django
  Downloading Django-1.1.1.tar.gz (5.6Mb): 5.6Mb downloaded
  Running setup.py egg_info for package Django
Installing collected packages: Django
  Running setup.py install for Django
    changing mode of build/scripts-2.4/django-admin.py from 664 to 775
    changing mode of /home/joe/python_virtualenv/bin/django-admin.py to 775
Successfully installed Django

If your host doesn’t block GCC, use pip to be sure your MySQL interface (MySQLdb) is up to date:

$ pip install -U MySQL-python
...
Successfully installed MySQL-python

Django requires MySQLdb version 1.2.1p2 or higher.

Yolk prints a nice, clean list of everything installed in your Python environment, install and run:

$ pip install yolk
$ yolk -l

Django          - 1.1.1        - active
MySQL-python    - 1.2.3c1      - active
pip             - 0.6.1        - active
setuptools      - 0.6c11       - active
yolk            - 0.4.1        - active

At this point, I started a new Django project, assigned a database and filled in the necessary values in settings.py. I put the Django project files into the virtual environment to keep everything in the same place. This might not be the best practice, but it makes sense to me.

$ cd ~/python_virtualenv/
$ django-admin.py startproject testproject

The sane part is finished, now onto the kludgery.

Django.cgi

All the CGI shim solutions I found pointed back to a script Paul Sargent uploaded to ticket 2407 back in summer of 2006. It still works: django.cgi

Three lines need editing:

Line 1: Point the CGI’s shebang to the virtualenv Python binary.

#!/home/joe/python_virtualenv/bin/python

Line 95: Add the directory above the Django project directory to Python’s sys.path.

sys.path.append("/home/joe/python_virtualenv")

Line 97: Add the project’s settings to os.environ.

os.environ['DJANGO_SETTINGS_MODULE'] = 'testproject.settings'

htaccess

For Django to respond to URL requests, those urls need to be fed into the django.cgi script. For testing I routed everything from /django to the cgi script by adding the following lines to my top-level htaccess file:

RewriteEngine on
RewriteRule ^cgi-bin/ - [L]
RewriteRule ^django/(.*)$ /cgi-bin/django.cgi/$1 [QSA,L]

The second line isn’t necessary unless pulling Django urls from the webroot, without it, the redirects would loop.

At this point, the Django site should load from /django/… urls.

Finally, as a quick fix for admin media files, I symlinked Django’s admin media directory from my web root:

ln -s ~/python_virtualenv/lib/python2.4/site-packages/django/contrib/admin/media ~/www/media

Conclusion

I spent quite a few hours spread across a couple days researching and figuring out how to get the first install working. The second installation only took about 5 minutes from start until editing Django’s admin pages.

Running Django through CGI is possible, but it is dog slow. There appears to be some caching after the first request, but that first page load often takes an excruciatingly long time.

Further reading, possible improvements

The servers I was working with are both running the almost six year old Python 2.4.3. The wsigref module was introduced with Python 2.5. My goal was to get Django running without compiling anything since some hosts deny access to GCC.

References

These sites were helpful in figuring this out.

The two hosts I tested on were LiquidWeb and A2Hosting. Both have been excellent, dependable hosts. Neither has any Python support to speak of on their shared plans. A2 blocks access to GCC.


At some point, I need to stop writing drafts and actually publish something here.



Next Page »

random

14th St webcam