Seek Nuance

After some job market feedback and chin-scratching, I’ve changed our Senior Developer opening’s job description. Now it’s less about Python or Django, and more about search technologies, specifically full-text and LSI search.

We hope candidates will have some experience with Python or Django, but search technology experience (e.g., tuning, tokenizers, parsers, relevancy rank tweaking, aggregates and pivots) in now more important, and emphasized, in the the job.

Here’s the new description:

———

Founded in 2009, IP Street develops and markets software to help corporations, law firms, financial research firms, and government agencies better analyze patent information.  Our goal is to make IP data easy to get, use, and understand, so everyone can have access to high quality and transparent information.

A significant facet of our application’s capabilities are derived from Solr and other search technologies. We’re seeking a great full-text Search developer with experience in:

• Solr, Lucene, or other search engines
• Full-text search schemas, tokenizers, parsers, and rules for returning statistics and meaningful analytics
• Automated workflows that process millions of objects
• Data quality metrics and repairs

You’ll be joining us at a great time! Revenue is coming in, and we’ve done two Angel funding rounds at increasing valuations.

Key Responsibilities.

• Enhance our Solr engine to provide more statistics and meaningful analytics to the product
• Enhance or tune our use of other search technologies, e.g., LSI
• Enhance and extend the existing code base to add new product features. Our application is written in Django and Python, with an almost all open-source technology stack
• Occasionally wear testing or devops “hats,” as the needs arise
• Write unit tests for your code, and do performance analysis
• Demonstrate technical leadership within the team
• Communicate well with the team, in writing and orally

Qualifications.

• Significant experience using and tuning Solr, Lucene, or other search engines with similar capabilities
• 3+ years related experience in Python development
• 1+ years experience in Django development, or a strong interest in learning
• Experience using one or more of: MongoDB, CouchDB, or another NoSQL database; Celery; Redis; PostgreSQL or another SQL database
• Experience using latent semantic indexing search technologies would be a plus
• Experience integrating with open-source 3rd-party libraries
• Experience creating customer-focused software to process data and generate statistics and analytics
• Solid troubleshooting abilities, self-directed, and proactive
• Enjoy all aspects of software product creation — design, implementation, and debugging
• Familiarity with using OS X as a development environment, and Linux as a production environment
• Bachelors Degree or equivalent in Computer Science or Software Engineering
• Excellent communication skills

Salary is DOE.

Please send resume to johnd@ipstreet.com.

We’re looking to hire two lucky people who desire fame and fortune. Here’s the Senior Developer opening:

Founded in 2009, IP Street develops and markets software to help corporations, law firms, financial research firms, and government agencies better analyze patent-related information.  Our goal is to make IP data easy to get, use, and understand, so everyone can have access to high quality and transparent information.

We’re seeking a great Python developer with experience in: Automated workflows that process millions of objects; data quality metrics and repairs; search, particularly with Solr or Lucene; and/or general data mining. Our stack, and development & production environments, are almost all open-source. The key technologies are Python, Django, Celery, Solr, and PostgreSQL.

Read more…

Pro tip: When you rely on Fabric to provision your servers, and your fabfile installs packages from the Cheeseshop, and package D (which you specify) depends on package C, and the Cheeseshop’s dependency rule is wrong, and it causes the wrong version of package C to be downloaded and installed, and the version number it should be is visually similar to the one it installed (say, 2.3.1 vs. 2.4.1), and it quickly scrolls up your terminal window, and package C version 2.4.1 is in fact incompatible with package D, and you’re tired, you can waste a lot of time chasing your tail.

Apple’s OS X Lion is a great product. I’m glad I upgraded. But it’s got some annoyances.

My first Mac was a version 1, back in 1985. After that, I used DEC operating systems for a few years, and then used Microsoft Windows exclusively throughout the 1990s and most of the 2000s. I switched back to Macs in 2008, when I bought a MacBook Pro with OS X Leopard.

OS X Leopard and Snow Leopard were fine, quintessential Apple products.

I’ve now upgraded to OS X Lion. Nothing in the earlier two versions made me clench my teeth, but some of Lion’s changes bother me. Someone surely had a good reason for each one, yet all but one are backward steps in usability. (I’m fence-sitting about one of them.)

I won’t prattle about why my opinion matters, but I’ll remind you that I’m really smart and what I say is always right.

Here’s my list of top OS X Lion annoyances.

Read more…

I bought “Python Testing Cookbook” by Greg L. Turnquist, published by Packt.

The good. I liked the cookbook recipe approach. Each recipe has the same headers: Its name, “How to do it,” “How it works,” and “There’s more.” This may not sound fancy, and it isn’t, but it works.

The writing’s good (albeit sometimes elementary — see below) and the example code is well laid out (except when it isn’t — see below). The book starts with the simplest form of unit testing, and goes all the way to measuring test coverage, and load testing. That’s a lot for one book to cover, which is both good and bad. Your first line of defense can be one book, but unless the book is very well written, it may leave every reader scratching their head over one section or another.

I learned a couple of new tricks.

Read more…

John Anderson has documented some nice Python interpreter tricks on his blog. Including a .pythonrc.py file hack for Djangonauts:

For Django developers when you load up the ./manage.py shell it is nice to have access to all your models and settings for testing:

# If we're working with a Django project, set up the environment
if 'DJANGO_SETTINGS_MODULE' in os.environ:
    from django.db.models.loading import get_models
    from django.test.client import Client
    from django.test.utils import setup_test_environment, teardown_test_environment
    from django.conf import settings as S

    class DjangoModels(object):
        """Loop through all the models in INSTALLED_APPS and import them."""
        def __init__(self):
            for m in get_models():
                setattr(self, m.__name__, m)

    A = DjangoModels()
    C = Client()

See his post for more interesting Python tips. Me, I’m enabling autocomplete and automatic pretty-printing right now.

I recently discovered two useful modules in Python’s library.

At work, a process needed to input and parse .csv files. Csv files are challenging because no specification exists, although there are de facto rules — which .csv-generating applications sometimes violate. I proceeded to write a specialized parser. It handled only our .csv files (which are used by a system configuration process), but still, its regular expressions were things of beauty. I felt pretty good about it when I was done.

And then…I discovered that Python comes with a csv module! Who knew? Amazing! I ripped out my custom code (including my beautiful Regex strings, sigh) and replaced it with code using csv. It works great, and now there’s fewer lines of code to support!

Another discovery was about temporary files. Some back-end tasks needed temporary files, and so I dutifully defined TEMPORARY_FILE objects and implemented the algorithms around them.

And then, my colleague, Ryan Roemer, mentioned the tempfile module. Sweetness! No more defining “task_foo.txt” filenames. Very nice!

I have a “Zen of Python” T-shirt, which I bought at a PyCon conference. Black design and yellow lettering on red fabric. Its back displays the first seven lines of the Zen:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea — let’s do more of those!

Read more…

Today, I’ll liveblog and tweet from Northwest Python Day 2010. I’ll update this article as the day progresses.

—————

1734: The day’s over!

1717: More lightning talks. (I’m fading. Lots of great info and discussion today, it takes energy to stay focused!) A Google Maps – Twitter mashup. WebHelpers. IronPython. (Bleh.)

1647: Python vs. Ruby, Gary Bernhardt. Ruby fails to live up to the Zen of Python. (E.g., Calling functions with or without parens, gah! Rails has junk drawer of monkey patches.) Good aspects: Ruby core types have composability; Ruby has “the full Lisp chainsaw.” RSpec. “Ruby is ugly, Python is beautiful. But…” Compared syntactic expressiveness and semantic flexibility. Wants to see blocks added to Python.

1603: Python & GIS, Dane Springmeyer. Unofficial Python GIS SIG. Gentle guide to GIS. Where am I? Python and OO GIS. GeoDjango, GeoAlchemy / Shapely, GeoHASH for AppEngine, and Mapnik. TileMill is a tile rendering engine using Amazon’s cloud.

1513: Justin Cappos, a platform for developing and deploying networked applications. Clouds are great for scalable computation, no hardware purchases, minimizing IT overhead, and providing fault tolerance. But cloud providers need to make money somehow, sometimes including advertisements; there’s loss of privacy; censorship; and vendor API lock-in. Cloud computing erodes software freedom. P2P is an alternative, but problems with heterogeneity, short use patterns, fault tolerance, and distributed state management. His solution (Seattle) uses a safe virtual machine environment, and is run like a potluck. It executes a Python subset, which is implemented in Python.

Read more…

Yesterday was Northwest Python Day. All of the talks were great, and the day was immensely rewarding and enjoyable.

Andrew introduced me to Andy McKay, with whom I’ve traded a bit of e-mail but never met. It’s an oddity of today’s world that you can do business, or strike up a friendship via a few e-mail exchanges, with someone, without ever having actually met them.

Most of the attendees brought some food, and most of them brought breakfast food, and most of the breakfast food were doughnuts. We were swimming in doughnuts! Boy oh boy, there were a lot of doughnuts.

Read more…

My reflections on my first Plone conference…

Things that were great

The conference, in whole. The organizers did a great job, and we should all contribute to pay off their mortgages. 

I’m sometimes a bit jaundiced about the overused word, “community,” but the Plone/Zope community is aces.

Things that weren’t great

The Ronald Reagan Building and International Trade Center sucked. It’s cold, bland, and too big.

The Reagan building’s Wi-Fi sucked, sucked, sucked. It’s beyond me how the largest building in Washington, D.C, with 3.1MM square feet, could be overwhelmed by the network activity of a 310 person conference.

I would have paid $40 more in registration fees for slightly more interesting lunches. Read more…