Archive

Tag Archives: Django


Overview

Founded in 2010, IP Street has built the world’s preeminent Intellectual Property(IP) analytics and visualization engine, in conjunction with a nationally recognized IP law firm. Our SaaS product helps corporations and financial analysts quickly and efficiently analyze IP information.  We make IP data easy to get, use, and understand!

As with any organization, we’ve continued to evaluate new ways to provide value to our clients. We’re evolving into a “SaaS+” model, which pairs our service with expert consultation to assist our clients in assessment and evaluation.  Our focus remains on the financial and technology markets.

Our technology stack is almost all open-source, with some nifty esoteric search technologies. Most of your work will be in Python and Django, in a Mac-based development environment, deploying to Linux. Other technologies include Postgres, Redis, and Solr. Our client-side code relies on Highcharts and Backbone.

This is a “small b” big data firm. But since we’re a scrappy start-up, we don’t have a big firm’s resources. We compensate by hiring senior people who are self-directed, appreciate real-world development trade-offs, and have a can-do attitude. It’s OK to not know something if you’re eager and willing to learn it. We know that bad code always haunts, so if you enjoy writing good code using a language’s standards and idioms, you’ve come to the right place!

This position is in a small engineering team. Its focus is on server-side work, which includes poking fingers into PostgreSQL, Solr, and other technologies. So, it’s not just coding. We do feature design, development, testing, DevOps, some customer support, and work closely with product management. Did I say that we wear multiple hats every day?

On to the details…

Responsibilities

  • Collaborate with others in product direction, priorities, and feature design
  • Design, implement, and test new product features and bugfixes
  • Make the user experience of our products as powerful, simple, and manifest as possible
  • Do what’s needed to move the company forward!

Qualifications

  • Significant server-side development experience. We’re not hung up on a number, because one year for you could equal five years for someone else. We’re looking for the confidence and awareness that comes from working with server-side web code. Here are some keywords: Subtasks, sentinels and software locks, software farms, scaling, and schema migration.  If you’re a smart person who enjoys working on software systems running on servers, you can check this box.
  • Significant experience developing in Python or a Python-based framework. We’re a Python and Django shop, and there’s no PHP, Ruby, or Perl within 2000’ of our codebase.  This must be serious development, and not, “I occasionally write 20-line scripts.”
  • If you’re very experienced in another language and are eager to learn Python, that could be OK. Can you convince us that you’re looking for a great opportunity to learn?
  • If you don’t know Django, that’s fine — it’s easy to learn.
  • Abilities that are nice to have: Significant interaction with PostgreSQL, Solr, or another type of db/search engine.
  • Some experience in JavaScript would be another plus. This won’t be your focus, though.
  • You’re enthusiastic about modern software development, distributed version control, coding, documentation, testing, and teamwork.
  • You have excellent judgement in attacking complex tasks, and in balancing “good enough, now” vs. “much better, later”
  • You’re self-sufficient, and confident in setting standards
  • Good communication skills

To apply

Salary depends upon experience. Please send your resume to johnd@ipstreet.com.


IP Street’s application runs on Python 2.7. Earlier this week, I evaluated all our Python packages for Python 3 support, as the first step in deciding when to migrate our codebase.

Although this was the time I’ve checked our packages for Python 3 support, I expected Django to be the only one that didn’t officially support it. (Production support is slated for version 1.6, which is now in release-candidate.) But Django is the only project whose development roadmap I closely follow! D’oh! Talk about a blind spot!!

This is why it’s good to sit down and formally check each package. Make a list of every package and check each one…

Read More


If you know someone who fits the bill, send them this post!

————————————

Title: Senior Developer

Reports to: VP Engineering

About IP Street

Founded in 2009, IP Street develops and markets software to help corporations, law firms, and financial analysts better analyze patent-related information. We make IP data easy to get, use, and understand!

Summary

We’re a start-up that’s developed a new way to visualize and data-mine intellectual property. We’re small and scrappy, have an innovative engineering team, and have built the business on awesome products that companies buy!

Our technology stack is almost all open-source, with some nifty esoteric search technologies. Most of your work will be in Python and Django, in a Mac-based development environment, deploying to Linux. Other technologies include Celery, Postgres, Redis, and Solr. Our client-side code relies on Highcharts and Backbone, and supports desktop and mobile users.

This is “small b” big data, with lots of interesting challenges!

Responsibilities

  • Collaborate with others in product direction, priorities, and features
  • Design, implement, and test new product (primarily but not exclusively server-side) features
  • Some front-end coding and debugging, as needed
  • Make the user experience as powerful, simple, and manifest as possible
  • Be positive, flexible, and do what’s needed to move the company forward

Qualifications

  • 10+ years experience in server-side development. Web development would be ideal, but it can be any kind of server-side code. We’re looking for expertise in processing pipelines or workflows, software farms, scaling, schema migration, etc. Or you’re a really smart person who loves complex software systems running on servers!
  • Significant experience developing in Python or Python-based frameworks, on the order of at least 5 years or so. This must be serious development, not, “I write a 20-line script now and then.”
  • Substantial experience in, and understanding of, a web framework such as Django. We’re looking for at least 3 years’ experience. Or if you don’t know Django, you’re eager to learn!
  • Pluses: Significant coding experience interacting with (or experience in configuring) PostgreSQL, Solr, or another SQL or full-text search engine.
  • Other pluses: Experience in or familiarity with jQuery, Backbone or equivalent technology, or client-side graphing packages. (These won’t be your focus, but the knowledge could come in handy.)
  • Enthusiasm about modern approaches to software development, distributed version control, good coding and documentation practices, etc.
  • You have excellent judgement in attacking complex tasks, and in balancing “good enough, now” vs. “much better, later”
  • You’re self-sufficient when possible, and confident in setting standards
  • You’re eager to build a small company into something insanely great!
  • Excellent team and communication skills
  • Bachelors Degree or equivalent in Computer Science or Software Engineering

Salary is DOE. Please send resume to john @ this-site’s-domain.


I’ve found some candidates for replacing Celery in my company’s product. (My reasons for replacing it are elucidated here, here, and here.)

I got these from web trawling, blog comments, and some e-mail. At first blush, none of the candidates have any disqualifying attributes, except for lacking subtasks. Celery is the only Python-friendly asynchronous task technology with subtask support, so I’ll need to bend on that if I want any alternatives to consider. (If I’m wrong on this point, please let me know in the comments!)

I’m not saying that these candidates will definitely satisfy all (sans subtasks) of my requirements. Right now they’ve just passed my initial sniff test. The next step will be to read documentation in detail, assess the health/activity of its community and developers, and try some sample code.

Read More


I’m ready to start looking at candidates to replace Celery in my company’s product. (The reasons are elucidated here, here, and here.)

Our SaaS product provides data mining and visualization for intellectual property. A 10-second elevator pitch is, it’s as though we attached Microsoft Excel’s chart wizard to US and international patent offices. (“As though” = “We didn’t do that, and in fact we go way beyond that, but I’m giving you a simple description.”) Our code is 100% Django and Python.

I looked at how we use Celery in our codebase. The reality of how we use it is much simpler than our ideas when we started two years ago. Combining our existing features with our product roadmap, I know with high confidence what features we need for our asynchronous tasks. And which ones are nice to have but not required, and which ones we’ll probably never need.

Read More


Commenting on my update to my Celery rant, @asksol asked me to post the Pylint results that made me question the claim of backwards compatibility.

(“@Asksol asked” — See what I did there? That’s alliteration. It’s a sign of a quality blog post. Ask for it by name.)

Again for the record, @asksol is a smart and friendly person. I know I wouldn’t last a day supporting a project the way he has supported Celery over multiple years. I’ve calmed down since yesterday, and I hope that something good results from my rant — if not for me, then for a future Celery user needing upgrade help. In his reply to my rant, @asksol describes some history and rationale for how he manages code change, and I encourage you to read it.

Here we go:

Read More


An update to my rant on Celery’s frequently-changing API: I’ve decided to stay with Django-celery 2.5.5 and Celery 2.5.3.

When I tried using Celery 3.0.4 with my existing code, Pylint threw about 60 warnings, many of which look real and all of which weren’t there when I used Celery 2.5.3.

“Backwards-compatible” my ass!

I shouldn’t have to chase my tail like this. Celery, you lost me. I’m now looking to replace you.


This is a rant.

My company’s code base is over 65K lines of Python and JavaScript code. We use Celery, Django-Celery, and RabbitMQ for our background asynchronous tasks. Ten different tasks.py files contain 30 task classes, split roughly 50-50 between periodic and on-demand. We use subtasks.

Today, I dug into updating from Celery 2.5.3 to 3.0.4, and I popped my cork.

I am aggravated by the frequency and extent of Celery API changes. It’s easily changed more often than any other five technologies in our stack combined. I’ve been upgrading Celery and Django-celery every six months or so, which corresponds to upgrading every few minor versions. And the changes are similar in scope to what I see when upgrading any other technology across one or two major versions.

Read More


tl;dr

When writing tests, mock out a subsystem if and only if it’s prohibitive to test against the real thing.

!tl;dr

Our product uses Redis. It’s an awesome technology.

We’ve avoided needing Redis in our unit tests. But when I added a product feature that made deep use of Redis, I wrote its unit tests to use it, and changed our development fabfile to instantiate a test Redis server when running the unit tests locally.

(A QA purest might argue that unit tests should never touch major system components outside of the unit under test. I prefer to do as much testing as possible in unit tests, provided they don’t take too long to run, and setup and teardown aren’t too much of a PITA.)

This was a contributory reason for our builds now failing on our Hudson CI server. Redis wasn’t installed on it!

Why didn’t I immediately install Redis on our CI server?

  1. Our CI server had other problems
  2. I intended to nuke it and re-create it with the latest version of Jenkins. I just needed to first clear some things off my plate
  3. Our dev team had shrunk down to just two people
  4. We were both strict about running unit tests before checking code into the pool
  5. We were up to our necks in other alligators

From a test-quality perspective, if code uses X in production, it’s better for tests to run with X than with a simulation of X.

One of the many joys of working with Ryan is that he challenges my assumptions and makes me consider alternatives. Because of a perceived lack of elegance in needing Redis on our CI server, and because his work had been temporarily blocked by my code changes, he challenged me to replace my unit tests’ use of Redis with a mock.

I walked into work yesterday and it was quiet. All our critical bugs blocking Saturday’s release were closed. I thought, why not? I’ll give it a go. Today’s a good day to see what’s involved with replacing Redis with a mock!

Read More


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.

Follow

Get every new post delivered to your Inbox.

Join 9,488 other followers