[SciPy-dev] ANN: Job Openings at Enthought
eric at enthought.com
Sun May 16 23:34:59 CDT 2004
This is a bit of a status report I guess for SciPy (www.scipy.org) and
Enthought (www.enthought.com), but, really, it is a long winded job
Among other things, Enthought develops scientific software
for clients. Python is central to to our strategy in this arena. We have
long supported SciPy and believe strongly in Open Source Software.
The purpose is to give people a feeling about what we do, the technical
challenges we face, and the skills needed to meet them.
There has been a lot of work on SciPy lately by the Travis Oliphant, Travis
Vaught, Pearu Peterson, Joe Cooper, and on the website by Jon-Eric
and Janet Swisher. The site is now upgraded to Plone and we have a
package out. If you're interested in seeing the activity level at
It looks like we're averaging about a 100 downloads a day if you add up all
source and binary distributions. When SciPy 0.1 was released a couple a
ago, I think we averaged about 10. Its extremely difficult to
extrapolate a user
base from such information, the obvious growth is good news.
In addition to SciPy we have multiple projects going on right now that
already plug into or will be plugins to a Python-based scientific
framework called Envisage (sorta like an IDE for science apps) that we're
working on. The idea is:
(1) To lower the bar as far as work required to get a GUI put
on the front end of a scientific algorithm.
(2) Develop scientific plugins that can play well together so
that, for instance, an electromagnetics simulator built by one
person can be used in conjunction with an optimization plugin
built by another person and results can be visualized with a
This is a hard, long path that requires much work and though. We have
started the process and actually have built an app on a very early
the Envisage framework. The app works great, but it's usage of the
framework is a
little mixed at this point. There were a lot of compromises we ended up
on the framework side in order to ship on time.
Also, I am not sure whether "easy-to-program" and "flexible architecture for
compatible plugins" are not mutually exclusive. I always have in my
mind that I
want a smart scientist to be able to build the GUI in a short amount of time
after the algorithm (which is the "hard part") is finished. I still
wish, but the lessons I've had over the last couple of years suggest
that the GUI is
actually the most expensive part of development for large apps. This is
due to the fact that commercial apps are rarely built around "research"
-- meaning that the algorithm code usually already exists in some form.
UIs take tons of time. Testing them is hard. Flexibility requires more
complexity (factories, adapters, etc.) than seems necessary at first.
building *good* UI's is really hard. Scientist rarely have the patience or
perspective for it -- and yet it is very often difficult to build a good
science apps without a scientist's understanding of the underlying problem.
We have a number of tools along with SciPy that we're building that are
of this puzzle.
1. Traits -- They at the heart of everything we do. They provide
some explicit typing, default GUI's, an observer event model for
anything that uses them. They can also require some getting used
2. Kiva/Enable -- This is the generic drawing system for Python.
3. Chaco -- Interactive 2D Plotting
4. PyFace -- MVC layer on top of wxPython. Supports trees, menus,
and a few other things right now. This will grow.
5. Envisage -- Plugin based GUI framework for scientific applications.
Beyond the basic GUI that comes from Envisage, we already have a couple
plugins for profiling code using hotshot and also searching for memory
leaks. David Morrill wrote these and they are called gotcha and
Martin Chilvers wrote a simple scintilla based plugin for editing
and a PyCrust shell is available by default in the app (not
a plugin at the moment).
We would love to see a number of other plugins:
b. IPython-like PyCrust going.
c. A more full featured script editing plugin.
(there is a huge list of features here).
These are all used actively in commercial products that we deliver.
they are also in various stages of development and will continue to evolve
and grow. Some are still pretty green. Portions of these are openly
now. All five of the listed tool sets will be open at some point this
when they are cleaned up a bit.
All of this leads to the fact that we are hiring and looking for smart,
pleasant, communicative people with integrity that are excited about
this sort of stuff. There is a lot of software architecture to be done that
needs talented designers. There is UI design/development that needs
that care about UIs or UI developers/designers that are really quick at
scientific problems. We also need really strong scientists/scientific
developers to do some of the backend coding for commercial products and also
SciPy development. If you have a background in geophysics, electromagnetics
(especially multi-pole methods) that is a big plus. For this, a PhD is
not required. Parallel computing skills wouldn't hurt. 3D
visualization a la
VTK/Python is a major need. So is knowledge about 2D rendering to help
out Kiva and the Enable toolset. Strong Python skills, Python extension
knowledge and strong C/C++ skills are a big benefit. Design/development
of Java NetBeans or Eclipse-like architecture is great -- or any other
architecture. Dedication to writing clean/clear code meant for other
to read is a requirement.
We have 3 or 4 scientific/python positions to fill over the coming
we're looking for candidates that have the best mix of the above
join our existing team of scientist/engineers, computer scientists,
writers, and an HCI specialist. We like this mix and feel it is the
best way to
build this sort of software. If you are interested in working at Enthought,
please send us your resume at jobs at enthought.com. If not, please send this
posting to the smartest people you know that fit some part of the above
(Python experience not explicitly required). Salaries are competitive.
be willing to relocate to Austin, Tx.
PS: There are additional positions listed at
for those interested in business application development (not
necessarily with Python).
More information about the Scipy-dev