Python for Asset Management!

[Mike]

Hi!

Im working on some research for a asset management system. We will use
python as our primary platform. As a opensource programmer the obvious
question is; are there any opensource systems available?

I found an article about ilm's system (story from python.org), sounds
very interesting. Im looking for more information about similar
systems (of course python based!), all feedback is welcome!

I hope there's someone outthere who knows some more about this!

Thanks!

-- Mike

 

[Harald Massa]

Im working on some research for a asset management system. We will use

python as our primary platform. As a opensource programmer the obvious
question is; are there any opensource systems available?

if you start with Python, please immediately go to
fixedpoint.sourceforge.net and load that module down!

it is ABSOLUTELY great, and it really is a must in developing financial
applications


Harald


*ceterum censeo, fixedpoint should be added to the standard library*

 

[Peter Hansen]

if you start with Python, please immediately go to
fixedpoint.sourceforge.net and load that module down!

it is ABSOLUTELY great, and it really is a must in developing financial
applications

Asset management doesn't _necessarily_ have anything to do with
financial applications. Depending on their needs, they may want
nothing more than to track serial numbers, locations, warranty
remaining, item history, and such things. What little financial
data I'd want in an asset management tool could be represented
as strings...

-Peter

 

[achrist]

There is a fairly lame asset management demo that comes or came with
MS Office, written in Access, IIRC. You might start with that and
convert it to python.

Having written a fairly big asset-management package myself, IDK why
anyone would really want to do this. You can find various shareware
packages starting about $15 and up. Good commercial packages, like
mine, can be had for around $1,000 and up. (My product is targeted
at a specific niche, so I am not in any way suggesting that it is
what you need.)

Meanwhile, MS has acquired some companies that do accounting packages
and offers some complete accounting packages that include fixed assets
for around $5,000 IIRC. They have been trying to offer some nearly-
complete packages for around $1,500 that have not included fixed
assets, but that might change at their whim, depending. It's very
hard to compete with MS when the user has MS all over their desktop,
and that's almost everyone for such markets. All of these numbers I
throw about casually are trivial compared to the costs of writing
anything good.

The accounting aspects can be the most interesting to program and there
are some complexities that might make good use of the highly-dynamic
nature of python. For example, most of the full-featured systems
facilitate setting up multiple sets of books covering the same
set of assets (for example, depreciation is different on the tax
return from depreciation reported to shareholders). With multiple
sets of books, multiple accounting rules, schedules, rates, and
policies, something like AOP might be a way to keep all the different
considerations from tangling things up beyond belief.

It's the old software designer problem of how to do something
without doing anything, no matter how dumb.

My goal in developing my fixed assets software was to be able to give
the user a program with a desktop look-and-feel that would be able to
do batch processing of up to 50,000 asseets without more than a minute
or two wait, and thus we didn't use Python. However, I have found
python to be very useful for helping convert customer data from other
systems into mine.

(e-mail address removed)

 

[Emile van Sebille]

[snip interesting status review of fixed asset software]

My goal in developing my fixed assets software was to be able to give
the user a program with a desktop look-and-feel that would be able to
do batch processing of up to 50,000 asseets without more than a minute
or two wait, and thus we didn't use Python.

I don't agree with your "... and thus..." conclusion. Python with Numeric
and the gui kit that matches your taste is easily up to this task.

For comparison, I've written a python+zope based application that juggles
sales data and provides sub-15 second response time recapping 1M+ records of
~180cols. Sub-selections from any combination of 20 parameters speed things
up further.

With that in mind, doing month-end fixed-asset depreciation schedule
calculations on three sets of books using any of a half dozen or so selected
depreciation methods for a department, division, or company should _always_
be sub-minute.

Emile van Sebille
(e-mail address removed)

 

[achrist]

I don't agree with your "... and thus..." conclusion. Python with Numeric
and the gui kit that matches your taste is easily up to this task.

For comparison, I've written a python+zope based application that juggles
sales data and provides sub-15 second response time recapping 1M+ records of
~180cols. Sub-selections from any combination of 20 parameters speed things
up further.

I didn't say it couldn't be done, but I sure didn't want to lose any
sleep figuring out how to do it. This project was done 3 years ago,
we were selling into a market with many slow and old computers about,
and we were dealing with people who like paper, so we wanted to create
pretty reports way up around 1000 pages without any major delay.

Maybe next time we'll do something like this in Python.


Al

 

[Mike]

thank you all for the replies, very useful!

Our system will primary handle file assets and disk tracking...it will
all be command line at first, then different UI's will be designed...

We already have most of the system written in c/c++, this is okey but
I want to add platform independance and I like the way python handles
different libraries, and its opensource!

So why dont we buy some commercial software? well, we want 100% access
to the source, and we also want to add modules to the system for each
new project.

I will take a look at links and information you all provided, really
useful! Advice on how to setup a system like this is also welcome,
should I use a server/client solution, or just clients accessing the
backbone(db) directly? all of your feedback is interesting, user
experience is unvaluable!

thanks!

-- Mike

 

[Mike]

thank you all for the replies, very useful!

Our system will primary handle file assets and disk tracking...it will
all be command line at first, then different UI's will be designed...

We already have most of the system written in c/c++, this is okey but
I want to add platform independance and I like the way python handles
different libraries, and its opensource!

So why dont we buy some commercial software? well, we want 100% access
to the source, and we also want to add modules to the system for each
new project.

I will take a look at links and information you all provided, really
useful! Advice on how to setup a system like this is also welcome,
should I use a server/client solution, or just clients accessing the
backbone(db) directly? all of your feedback is interesting, user
experience is unvaluable!

thanks!

-- Mike

 

[Alex Martelli]

thank you all for the replies, very useful!

Our system will primary handle file assets and disk tracking...it will
all be command line at first, then different UI's will be designed...

OK, so make sure to build a separate "engine" process (I would suggest
running it as a daemon serving xml-rpc) and "UI" processes (so the GUI,
commandline, web, ..., will all be different programs which access the
same daemon server and ONLY provide user interfacing).

We already have most of the system written in c/c++, this is okey but
I want to add platform independance and I like the way python handles
different libraries, and its opensource!

Sure. you can access your existing C-coded functionality via SWIG, or
C++ coded functionality with Boost (or vice versa, but I find Boost
easiest for C++ interfacing, SWIG for C interfacing, personally).

So why dont we buy some commercial software? well, we want 100% access
to the source, and we also want to add modules to the system for each
new project.

Sure, why go closed source if you can avoid it. Note that you can
also get open source software commercially if you need support &c (as
to whether you prefer to SAVE those $$$, that's a different issue).

I will take a look at links and information you all provided, really
useful! Advice on how to setup a system like this is also welcome,
should I use a server/client solution, or just clients accessing the
backbone(db) directly? all of your feedback is interesting, user
experience is unvaluable!

I would write the central engine as an xml-rpc server and give it
exclusive access to "the backbone db" (except for such "offline"
bulk operations as db dumps/restores, to be presumably performed
by different administrative access). This way you can alter the
central DB without recoding all clients, etc -- the clients will
just be xml-rpc clients and you need only maintain that interface
to leave old clients unaltered. Should the central engine ever
become a bottleneck, running it on (e.g.) a 3GHz / gargantuan
caching / multiGB fast DDR dedicated AMD-64bit box, with the DB
on a nearby similarly overblown puppy with the fastest SCSI disks,
and a gigabit Ethernet in between, will provide you quite a bit of
headroom -- you may never feel a need to spread it over multiple
boxes with the attendand cache-consistency headaches (perhaps some
particularly nasty and strictly computational bottleneck might be
hied off, but from your description of your system you're unlikely
to ever get any). If you DO think in terms of scalability to
thousands or tens of thousands of concurrent accesses then some
even-more-multilayered architecture may be worth considering from
the start, but I would advise against getting too ambitious in
these terms for a budding system -- there is a real risk that by
not wanting to build anything unless it can scale up by hundreds
of times you may end up not building anything useful at all...;-).


Alex