1. Open source
2. Free
3. Not software
4. On the cloud
5. Many hosting options
6. Cheap
7. Secure
8. Fast
9. Stable
10. Long track record of success.

Nuff said!

This module is a simple module that adds reseller functionality to reports. It is a bare-bone module that does very little. However, additions can be made to it. Also, custom fields can be added to this module.

Attached is the file for the module. Just download the zip and import it into the module manager. If you have any problems or errors, comment or call.

File: Reseller.zip

Vtiger is a CRM (Content Resource Management) software on the cloud. It is open source and works using popular, free web technologies (MySQL, PHP, Apache, and JavaScript).

Vtiger is installed on an Apache/PHP server. A MySQL database is setup for Vtiger (often on the same server that Vtiger is installed on). On installation, Vtiger populates the MySQL database with the proper tables. Vtiger uses the database to store most settings and contact data.

Once Vtiger is installed, it handles web requests in the following manner. A client requests a page from vtiger using a url (http://www.vtigerexampleurl.com/index.html). Apache receives the request and executes the Vtiger php code on the server referencing the request. The Vtiger code fills the request and constructs the page on the fly. To construct the page, the Vtiger code will query the MySQL database and get the information needed to construct the page. Once the page is constructed, it will send the page up to apache which is sent to the client. Usually each request is filled within a second.

This is a greatly simplified view of how Vtiger works, but it does show some of the basic ideas of Vtiger.

In business, it is always good practice to minimize expenses. The lower the expenses, the higher the profit margins.

However, too many times I have encountered businesses that over reducing expenses now for higher expenses later. An example of this happening is not getting an oil change in a car. At first it’s great to save $40 every 3000 miles. However, after 15000 miles, the engine blows. Saved $200, but now the cheap car owner has to buy a new car (~$15k).

It sounds stupid when describing a car and oil changes, however, it still surprises me how often I see this happen in business.

A company decides to reduce technical support to save money now. However, in the long term it erodes customer satisfaction and ultimate income.

A company decides to stop marketing because it is an expense and business is good. Studies show, companies that continue to market when business is good do much better when business is slow.

I consider over reducing expenses a bad business decision.

Most people consider themselves very honest. For the most part, they are correct.

However, there are some blurry areas of truth. One example I think of is the common job interview.

A future interviewee goes into the interviewers office with the biggest BS grin on their face. Both try to sell themselves and the position. They are both a little nervous and trying to make a good impression.

The most gaudy thing of all is the interviewees ‘interview suit.’

Many interviewees do it simply to impress the interviewer. “This is how I dress, very very fancy. Please like me.”

Unless the interviewee wears that suit to work on a regular basis, it’s not entirely honest. The interviewee still has to wonder what the interviewee will dress like if hired.

I tell all the people I interview for a job the same thing. Dress like you will every day you come to work.

Here is an excellent post from reaclimate.org. He talks about the issues with documenting scientific projects. A very interesting read as it pertains to climate change.

Climate code archiving: an open and shut case?
Filed under:

* Climate Science

— eric @ 26 October 2010

Gavin Schmidt and Eric Steig

The last couple of weeks saw a number of interesting articles about archiving code – particularly for climate science applications. The Zeeya Merali news piece in Nature set the stage, and the commentary from Nick Barnes (of ClearClimateCode fame), proposed an ‘everything and the kitchen sink’ approach. Responses from Anthony Vejes and Stoat also made useful points concerning the need for better documentation and proper archiving. However, while everyone is in favor of openness, transparency, motherhood and apple pie, there are some serious issues that need consideration before the open code revolution is going to really get going.

It would help to start by being clear about what is meant by ‘code’. Punditry about the need for release of ‘all supporting data, codes and programmes’ is not very helpful because it wraps very simple things, like a few lines of Matlab script used to do simple linear regressions, along with very complex things, like climate model code, which is far more sophisticated. The issues involved in each are quite different, for reasons both scientific and professional, as well as organizational.

First, the practical scientific issues. Consider, for example, the production of key observational climate data sets. While replicability is a vital component of the enterprise, this is not the same thing as simply repetition. It is independent replication that counts far more towards acceptance of a result than merely demonstrating that given the same assumptions, the same input, and the same code, somebody can get the same result. It is far better to have two independent ice core isotope records from Summit in Greenland than it is to see the code used in the mass spectrometer in one of them. Similarly, it is better to have two (or three or four) independent analyses of the surface temperature station data showing essentially the same global trends than it is to see the code for one of them. Better that an ocean sediment core corroborates a cave record than looking at the code that produced the age model. Our point is not that the code is not useful, but that this level of replication is not particularly relevant to the observational sciences. In general, it is the observations themselves – not the particular manner in which they are processed – that is the source of the greatest uncertainty. Given that fundamental outlook, arguments for completely open code are not going to be seen as priorities in this area.

By contrast, when it comes to developers of climate models, the code is the number one issue, and debugging, testing and applying it to interesting problems is what they spend all their time on. Yet even there, it is very rare that the code itself (many of which have been freely available for some time) is an issue for replication — it is much more important whether multiple independent models show the same result (and even then, you still don’t know for sure that it necessarily applies to the real world).

The second set of issues are professional. Different scientists, and different sciences, have very different paths to career success. Mathematicians progress through providing step by step, line by line documentation of every proof. But data-gathering paleo-climatologists thrive based on their skill in finding interesting locations for records and applying careful, highly technical analyses to the samples. In neither case is ‘code’ a particularly important piece of their science.

However, there are many scientists who work on analysis or synthesis that make heavy use of increasingly complex code, applied to increasingly complex data, and this is (rightly) where most of the ‘action’ has been in the open code debate so far. But this is where the conflicts between scientific productivity at the individual level and at the community level are most stark. Much of the raw input data for climate analysis is freely available (reanalysis output, GCM output, paleo-records, weather stations, ocean records, satellite retrievals etc), and so the skill of the analyst is related to how they choose to analyse that data and the conclusions they are able to draw. Very often, novel methodologies applied to one set of data to gain insight can be applied to others as well. And so an individual scientist with such a methodology might understandably feel that providing all the details to make duplication of their type of analysis ‘too simple’ (that is, providing the code rather carefully describing the mathematical algorithm) will undercut their own ability to get future funding to do similar work. There are certainly no shortage of people happy to use someone else’s ideas to analyse data or model output (and in truth, there is no shortage of analyses that need to be done). But to assume there is no perception of conflict between open code and what may be thought necessary for career success – and the advancement of science that benefits from a bit a competition for ideas — would be naïve.

The process of making code available is clearly made easier if it is established at the start of a project that any code developed will be open source, but taking an existing non-trivial code base and turning into open source is not simple, even if all participants are willing. In a recent climate model source code discussion for instance, lawyers for the various institutions involved were very concerned that code that had been historically incorporated into the project might have come from outside parties who would assert copyright infringement related to their bits of code if it were now to be freely redistributed (which is what the developers wanted). Given that a climate model project might have been in existence 30 years or more, and involved hundreds of scientists and programmers, from government, universities and the private sector, even sorting out who would need to be asked was unclear. And that didn’t even get into what happens if some code that was innocently used for a standard mathematical function (say a matrix inversion) came from a commercial copyrighted source (see here for why that’s a problem).

Yet the need for more code archiving is clear. Analyses of the AR4 climate models done by hundreds of scientists not affiliated with the climate model groups are almost impossible to replicate on a routine and scalable basis by the groups developing the next generation of models, and so improvements in those metrics will not be priorities. When it comes to AR5 (for which model simulations are currently underway), archiving of code will certainly make replication of the analyses across all the models, and all the model configurations much less hit or miss. Yet recently, it was only recommended, not mandated, that the code be archived, and no mechanisms (AFAIK) have been set up yet to make even that easy. In these cases, it makes far more sense to argue for better code archiving on the basis of operational need, than it does on the basis of science replication.

This brings us to the third, and most important issue, which is organizational. The currently emerging system of archiving by ‘paper’ does not serve the operational needs of ongoing research very well at all (and see here for related problems in other fields). Most papers for which code is archived demonstrate the application of a particular method (or methods) to a particular data set. This can be broken down into generic code that applies the method (the function), and paper-specific code that applies that method to the data set at hand (the application). Many papers use a similar method but in varied applications, and with the current system of archiving by ‘paper’, the code that gets archived conflates the two aspects, making it harder than necessary to disentangle the functionality when it is needed in a new application. This leads to the archiving of multiple versions of essentially the same functional code causing unnecessary confusion and poor version control.

It would be much better if there existed a stable master archive of code, organised ‘by function’ (not ‘by paper’), that was referenced by specific applications in individual papers. Any new method would first be uploaded to the master archive, and then only the meta script for the application referencing the specific code version used would need to be archived with an individual paper. It would then be much easier to build on a previous set of studies, it would be clear where further development (either by the original authors or others) could be archived, and it would be easy to test whether the results of older papers were robust to methodological improvements. Forward citation (keeping track of links to papers that used any particular function) could be used to gauge impact and apportion necessary credit.

One could envision this system being used profitably for climate model/reanalysis output analysis, paleo-reconstructions, model-data comparisons, surface station analyses, and even for age-model construction for paleo-climate records, but of course this is not specific to climate science. Perhaps Nick Barnes’ Open Climate Code project has this in mind, in which case, good luck to them. Either way, the time is clearly ripe for a meta-project for code archiving by function.

I have worked on a few projects in my lifetime. Many of them were not very useful. Sometimes I tried to use someone else’s code, but after a few hours of headaches I abandoned their code. There was a simple cause of the problem, documentation.

Too many times documentation is overlooked on software projects. Especially projects that are designed to be used by many programmers. They need to have good documentation because the ‘other programmer’ trying to implement the software may have slow or no access to the developer.

It really is difficult to be stuck on a programming project where I am stuck using a language (or some code) that is not documented. There are no tutorials and few implementation docs. It decreases productivity and costs the customer money.

Projects with great documentation: MySQL, Java, and libc. All of these projects have been successful.

Java is probably the best language to write simple applications. Before the C and C++ crowd goes crazy and says “Java is slow.” Simply put, nobody will notice the speed difference. Tests have shown that Java is only slightly slower than C or C++ (lower than the threshold or perception). The advantage of a program written in Java is the program does not need to be rewritten for Linux or Mac. In the future, a Java program will also run on smart phones (a quickly growing market).

MySQL is a sweet database program. It’s free, feature full, and simple to setup. Most web-servers have it available.

The connection between Java and MySQL is done using drivers such as JDBC. It’s simple to use and you can download it here. Well, it is easy is considering the programmer knows a little bit about copying code from say this website.

There you are, connected to MySQL from Java. Easy Peasy! Now Java applications can handle all the power of MySQL. That’s one sweet deal!

I’m thinking about our program and how it relates to the world. The real goal of our program (in my opinion) is two fold. First, it really helps me (and my group members) learn databases. Second, it might be a platform to start designing our own database software. If we can keep the program general and adaptable, we may be able to adapt it to many different applications. Then we can sell our services for real dough. That’s what really gets me excited…

Project management involves keeping track of various tasks in a project. To complete a project, all tasks must be completed. Programming takes a lot from this field and is all about task management.

In the engineering world, usually the management or team leads take care of project management. In construction, it is even higher up, it is the general contractor. With programming, the project management is usually all the way down at the lowest level. Programmers need to manage their programs. That is the essence of programming.