Re: Upgrade from 5.6 => 5.7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Wed, 2011-09-14 at 19:17 -0700, Craig White wrote:

... snip interesting posting ....

> WebApps are clearly the future - it's hard to justify specialized
> server/client applications (installation, limited choice of clients,
> maintenance, licensing) and it seems that the future will offer 2
> choices... SAAS or run your own.

That is the way I see things. Web runs anywhere. Otherwise specific
application software (usually costing money), licensing involvement,
software dependency etc. Grab a reasonable browser and start using the
application!


> My own take on it... 'plain html' accounting is just fine.

Mine are a bit more than 'plain'. I use CSS. However accounting is
basically entering or capturing the data; then doing basic tasks like
orders, invoices, statements etc. Add some complicated things like
credit control and specific discount structures for individual
customers. Branch-out in to name, address and other contract details,
add the mailing list facility. Add stock control, automatic re-ordering
etc.

The best bits that make the directors happy is when they can sit in
front of the screen and see the sales figures and trends. Everything
summarised on a single page with more detailed analyse with a simple
click. Think Gmagic, or perhaps Imagic, may be able to plot on a HTML
screen.

Have headings in a language file, so international customisation becomes
easier. Add an access control system allowing users to access different
modules and menus.

OK one can't (yet?) plug-in a bar code reader to a web application but
an interface box can transmit the data using TCP.

> To keep the PHP reasonably secure, it requires HTTPS and
> access authorization is done by LDAP authz so if you don't have a
> username and password on his system, you can't get the login screen. Of
> course the server is kept up to date.

Agreed. Security with HTTPS and non-standard ports not 443, 8000, 8080
etc. Currently use static IPs to prevent unauthorised access.

> As for Paul's expressed notions... It would take a fairly massive amount
> of man hours to produce a fully functional dual entry accounting package
> for widespread business use.

I think the essential thing is sheer inspirational brain work carefully
thinking about everything before stating to code. Get the structure and
the objectives correct and the rest is a piece of cake.  And be prepared
to modify.

>  Before you decide on an environment, you
> would probably want to commit to test driven development and MVC which
> almost invites the use of a framework (Cake/Django/RoR). Personally I am
> biased towards RoR but starting a large scale project in ruby, php or
> python without using one of the frameworks at this point would be a
> really poor choice. There are a number of PHP based accounting systems
> out there which you could probably fork but why? They all missed the
> boat somewhere, somehow.

Unsure what you mean by 'framework'.

Simple to write, harder to ensure everything integrates well. Probably 3
to 4 months part-time. Easy and intuitive to use and delivering what the
users want plus scope for customisation.


-- 
With best regards,

Paul.
England,
EU.


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux