E
eric jones
Hello,
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
posting.
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.
SciPy
-----
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
Steinbomer
and Janet Swisher. The site is now upgraded to Plone and we have a
SciPy 0.3
package out. If you're interested in seeing the activity level at
scipy.org,
please visit.
http://www.scipy.org/map?rmurl=http://scipy.net/scipyusage/
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
years
ago, I think we averaged about 10. Its extremely difficult to
extrapolate a user
base from such information, the obvious growth is good news.
Other Stuff
-----------
In addition to SciPy we have multiple projects going on right now that
either
already plug into or will be plugins to a Python-based scientific
application
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
3D plugin.
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
version of
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
making
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
harbor this
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
partially
due to the fact that commercial apps are rarely built around "research"
algorithms
-- meaning that the algorithm code usually already exists in some form.
Still,
UIs take tons of time. Testing them is hard. Flexibility requires more
complexity (factories, adapters, etc.) than seems necessary at first.
Further,
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
UI for
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
pieces
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
to.
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
enroll.
Martin Chilvers wrote a simple scintilla based plugin for editing
scripts,
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:
a. Debugger.
b. IPython-like PyCrust going.
c. A more full featured script editing plugin.
(there is a huge list of features here).
d. Mayavi
e. etc.
These are all used actively in commercial products that we deliver.
However,
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
available
now. All five of the listed tool sets will be open at some point this
summer
when they are cleaned up a bit.
Jobs
----
All of this leads to the fact that we are hiring and looking for smart,
pleasant, communicative people with integrity that are excited about
building
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
scientists
that care about UIs or UI developers/designers that are really quick at
grasping
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
helpful, but
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
finish
out Kiva and the Enable toolset. Strong Python skills, Python extension
writing
knowledge and strong C/C++ skills are a big benefit. Design/development
with or
of Java NetBeans or Eclipse-like architecture is great -- or any other
solid GUI
architecture. Dedication to writing clean/clear code meant for other
humans
to read is a requirement.
We have 3 or 4 scientific/python positions to fill over the coming
months, and
we're looking for candidates that have the best mix of the above
skills. You'll
join our existing team of scientist/engineers, computer scientists,
technical
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 (e-mail address removed). If not, please send this
posting to the smartest people you know that fit some part of the above
description
(Python experience not explicitly required). Salaries are competitive.
Candidates must
be willing to relocate to Austin, Tx.
thanks,
eric jones
PS: There are additional positions listed at
http://www.enthought.com/careers.htm
for those interested in business application development (not
necessarily with Python).
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
posting.
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.
SciPy
-----
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
Steinbomer
and Janet Swisher. The site is now upgraded to Plone and we have a
SciPy 0.3
package out. If you're interested in seeing the activity level at
scipy.org,
please visit.
http://www.scipy.org/map?rmurl=http://scipy.net/scipyusage/
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
years
ago, I think we averaged about 10. Its extremely difficult to
extrapolate a user
base from such information, the obvious growth is good news.
Other Stuff
-----------
In addition to SciPy we have multiple projects going on right now that
either
already plug into or will be plugins to a Python-based scientific
application
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
3D plugin.
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
version of
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
making
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
harbor this
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
partially
due to the fact that commercial apps are rarely built around "research"
algorithms
-- meaning that the algorithm code usually already exists in some form.
Still,
UIs take tons of time. Testing them is hard. Flexibility requires more
complexity (factories, adapters, etc.) than seems necessary at first.
Further,
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
UI for
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
pieces
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
to.
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
enroll.
Martin Chilvers wrote a simple scintilla based plugin for editing
scripts,
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:
a. Debugger.
b. IPython-like PyCrust going.
c. A more full featured script editing plugin.
(there is a huge list of features here).
d. Mayavi
e. etc.
These are all used actively in commercial products that we deliver.
However,
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
available
now. All five of the listed tool sets will be open at some point this
summer
when they are cleaned up a bit.
Jobs
----
All of this leads to the fact that we are hiring and looking for smart,
pleasant, communicative people with integrity that are excited about
building
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
scientists
that care about UIs or UI developers/designers that are really quick at
grasping
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
helpful, but
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
finish
out Kiva and the Enable toolset. Strong Python skills, Python extension
writing
knowledge and strong C/C++ skills are a big benefit. Design/development
with or
of Java NetBeans or Eclipse-like architecture is great -- or any other
solid GUI
architecture. Dedication to writing clean/clear code meant for other
humans
to read is a requirement.
We have 3 or 4 scientific/python positions to fill over the coming
months, and
we're looking for candidates that have the best mix of the above
skills. You'll
join our existing team of scientist/engineers, computer scientists,
technical
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 (e-mail address removed). If not, please send this
posting to the smartest people you know that fit some part of the above
description
(Python experience not explicitly required). Salaries are competitive.
Candidates must
be willing to relocate to Austin, Tx.
thanks,
eric jones
PS: There are additional positions listed at
http://www.enthought.com/careers.htm
for those interested in business application development (not
necessarily with Python).