In-memory caching is enabled using memcache/memcached (my current preference) depending on the linux flavour used
Some time ago, I was analysing the performance of the Team Security query. The slowest part of the query seems to be caused by the subquery with joins between the tables team_sets_teams and team_memberships within listview queries.
Then I thought: Sugar caches most of the semi-static data (vardefs, language files, etc) into whatever caching mechanism is used by the system, why don’t we run an IN() condition using the cached list of ids per user, instead of a subquery on every listview load?
This post is supposed to guide through the setup of a VirtualBox virtual machine for local development of Sugar 7.5.x. The OS of choice is Debian 7.8 as it is my personal preference for server setups and it currently fits all the software requirements of Sugar without much additional manual work.
For one of my projects I needed to drive a small motor at different speeds, so I gave this a go by reading and learning more about what is required.
We can achieve that with an Arduino microcontroller by using PWM signals. For this project I am using an Arduino Mini clone, and decided to drive the motor with a N-Channel MOSFET (voltage controlled transistors), activated by a PWM signal.
Keeping the frequency of the signal constant, and varying the width of the “on” time vs the width of the “off” time (changing the duty cycle), will make the motor spin at different speeds.
The signal values that Arduino expects for the duty cycle is from 0 to 255 and it can be set by using the function analogWrite(pin, value). By providing a different duty cycle value to our Arduino pin (in my case PWM pin number 5), the motor will spin at different speed.
Different application’s approach: Sugar 7 framework
For whoever is reading this article and is not familiar with Sugar on the most recent version 7.x of the product, it is important to note that the application’s core is now a RESTful based API.
The presentation layer is based on SugarCRM’s framework “Sidecar”, that uses quite a few Open Source libraries (including Bootstrap, jQuery, Handlebar and Backbone.js).
The framework’s MVC layer is cached/stored within the browser at the first application’s load and interacts with the REST API on every subsequent call, creating a more powerful experience as a Single Page Application.
The great concept around the newer application’s framework is that everything can now be achieved interacting with the application via API calls, if it can be done in the application by using the interface (except BWC functionality).
By doing so, the framework provides extreme flexibility and huge integration capabilities, and therefore it allows customers to build any business process around the application.
Creating Support Tickets from Emails is one of the core functionalities of a ticketing system and it can hugely benefit any organisation if the ticketing system is directly part of the global CRM implementation.
SugarCRM since the early days has included on any version of its CRM product a great functionality that is commonly used between my customers: the Inbound Email to Case creation (as in Email to Support Ticket creation).
To know more about how to set-up the functionality out of the box, for a Sugar v126.96.36.199 (latest Sugar version while writing this article), please refer to this section of the manual.
The objective is to connect via the REST API to SugarCRM and give an immediate feedback to the team using an Arduino. The output can be anything; from an awesome smoke machine, to a rotating light, a small set of LEDs, a LCD display, an audio alarm, whatever really. In this specific case it will be a set of 5 LED’s and a buzzer.
This practical example shows how to bring together Arduino micro-controllers, basic electronic skills and software web technologies. The result creates a physical device that gives real time feedback for software users about something that needs immediate attention.