A Developer's Life

For the first time I had the honor to be part of a SugarCRM’s Code Sprint (this time in SugarCRM Munich HQ)… It was an amazing experience, that I definitely want to live again.

For those wondering what a SugarCRM Code Sprint is, I’m going to explain it with the following (personal) interpretation:

Take a Community Manager, a bunch of Sugar’s Engineers and a reasonable number of developers from almost everywhere in Europe. Put them all in a room, feed them with good (not exactly healthy) food (from Mars and Sneakers to meat and pizza) and beverages (from water to beer, through RedBull), make them feel like home and let them have fun at night. All the rest is automatic: new friendships and good code.

 Don’t know if I contributed with some actually “great” piece of code; I just know I did my best, having lot of real and sane fun (just like when I was young, and software was fun, not work !).

Code Sprint is not a race, you don’t need to be the fastest or the best or the first. You just need to cooperate with others, giving what you can to help building a better SugarCRM. The guys I had the pleasure to meet (and to work with) in those days are all brilliant developers and amazing code contributors (actually they are also younger than me, but that’s another story), perfectly integrated in SugarCRM’s world. Going over those geeks stuff, I firmly believe that this CodeSprint has been a great starting point for new friendships.

[Personal Note]

In the last four days I feel I dramatically improved my (poor) English, especially my (very limited) listening capabilities. I think that the biggest problem I had was the “tuning” of my ears, to understand so many different ways to same the same things (with speakers from Belarus, Belgium, France, Germany, Portugal, Russia, Spain, UK, USA): unfortunately I not always succeeded in that, sometimes looking a bit dumb. But I’m keep on improving…

When I first started working on SugarCRM I spent a lot of time digging the code, trying to understand how Sugar’s guys coded their standard stuffs and how I could insert my custom code, to satisfy my Customer’s requirements.

I discovered a lot of entry-points for custom code, that would let me create almost any kind of custom procedure without changing the core code : amazing ! Doing customizations without modifications at the core means don’t have to worry about core upgrades… I had just discovered the Upgrade-Safe way to do customizations.

For my personal use I’ve coined the acronym TUSW (The Upgrade Safe Way) to always remember (to myself and to my colleagues) the Rule #1 that all of us should (must) apply to SugarCRM customizations. Think of it like a stamp we put on our analysis.

Since then, I always worked in that way (TUSW) avoiding any (unnecessary) change to the core. But what when there’s no way to do customizations in this way ?!?!?!

Core changes are definitely a bad habit that throw developers in the “patches hell” (definition stolen from MS world, when we were dealing with the sadly well known “DLL Hell”) : whenever SugarCRM publish a new patch/upgrade, developers must check it for changes possibly involving the same (core) files they modified. No way, it’s too BAD !.

So I started opening bugs and feature requests  (at SugarCRM’s Bug Tracker), suggesting SugarCRM people new ways to open up their procedures to customization. At the beginning I was only “suggesting”, while today I’m actively cooperating in development (through the gitHub repository open to all the Community Members or the gitHub repository open to Partners).

Knowing that in a future patch I’ll get the desired functionality, I can implement it immediately (even in a previous release, if the fix is not too heavy), quickly solving the customer’s need, with no risk for my customization.

Excited. Thrilled. I guess my (English) vocabulary is not rich enough to define the amazing experience I’m going to live: the SugarCRM’s Code Sprint, that will be held in Munich during the first week of October.

I don’t have yet detailed knowledge of what will happen during those days. I just know that I’ll be working on SugarCRM’s source code with a selected group of developers coming from USA and Europe, both from SugarCRM and Partners.

During these four days I will meet again (almost) all the people I first met in San Francisco (during SugarCon 2011) and I’ll also meet “live” the people that, today, I know only “virtually” (meaning by eMail or Skype). In both cases it will be a great pleasure !

Now, I have to say two big “Thank You”. The first one goes straight to SugarCRM’s guys, for the event’s invitation they sent me.

The second one (it’s actually a very big “Thank You”) goes to my Bosses at Poker S.p.A., for financing my transfer (even if, in Italy, it’s a bad time for economy in general) letting me take part on this amazing meeting.

I just hope to be a good contributor, to save Poker’s honor (and also mine…).

I will post about SugarCRM’s Code Sprint, so…. Stay Tuned !!!!

One of the first SugarCRM’s capabilities I’ve learned was the Logging Engine. It helped me understanding the flow of procedures and it could be powerful as debugging, when you are dealing with  function calls and parameters value.

The logging engine offers several levels of detail:

• Debug
• Info
• Warning
• Deprecated
• Error
• Fatal
• Security
• Off

While in a production environment you would set it at higher levels, such as fatal or error, during development you would obtain detailed informations putting it at debug level.

Don’t forget to remove useless (for production scopes) debug informations, or you’ll run into serious performance issues.

First of all let’s see how you can put informations into the logger (it will write them in a file named sugarcrm.log*). The syntax of the call depends on the weight you wanna give to the information:

$GLOBALS['log']->info(“My Debug Info”);

In this example I’m writing into the log file the string “My Debug Info” whenever the PHP interpreter reaches this line of code, and if SugarCRM is configured to track logging at info level or above (meaning info, warning, deprecated, error… But not debug).

Writing a static string would help us understanding the flow of the procedure, but usually we need more:

$GLOBALS['log']->info(“MyVar value : ” . $myVar);

In this example we accomplish two tasks: we track the procedure flow and, at the same time, we get the $myVar value. But what if the $myVar is an array (or an object) ? Here’s the solution:

$GLOBALS['log']->info(“MyVar value : ” . print_r($myVar, true));

Hey, pay attention ! Since print_r function contribute to build the string parameter, it’s actually evaluated before the logging engine knows whether or not to write it on the log file. So you are asking the PHP interpreter to do a hard work (consider that logging a SugarBean object, such as Accounts, can easily write 100 Kb of data in your log file !). Do you think this kind of logging would be useful at production time ? I guess no….

To avoid performance issues and useless wasting of logging time, before going production remember to:

1. Remove deeply technical log calls (unless useful also in production environment).
2. Remove long text (such as the one generated by print_r) log calls (unless really useful also in production environment).

* – The standard name is sugarcrm.log, but administrators can opt for a different name through the System Settings link in Administration Menu.