Thread Details
  • Replies 2 replies
  • Subscribers 353 subscribers
  • Views 909 views
  • Users 0 members are here
Forum Actions
Related

SugarCRM dev pains - what's yours?

Gabriel Shanahan

Hey everyone,

had a beer with fellow Sugar devs the other day and (as you do) we got to talking about various pains we deal with as Sugar devs. I was thinking that we're probably not the only ones discussing this over beers, and thought it would be interesting to start a conversation with the community and just see which things come up, which things come up repeatedly, etc.

So, here are the rules:

  • List any dev pain, small or large, that you have to deal with in Sugar. Keep it short & sweet or delve into an explanation, it's up to you.
  • Limit yourself to developer-specific topics, e.g. not "I wish I could edit word documents directly in sugar", and sugar-specific topics, e.g. not "I wish javascript had types"
  • If you want, mention if/how you solved them internally
  • Keep the number of items reasonable - ideally around 3-5
  • Don't hate

I'll start:

Studio (and administration in general) - Don't get me wrong, it's a great tool for non-coders and makes lots of things possible, but as a developer I would really prefer to be able to do these things (new fields, layouts, etc. and other "mouse-based' customizations) from code directly. Not only is it much faster and more comfortable for me, but it opens the door to a lot of automation that can then be done - e.g. importing new fields, relationships etc. from a spreadsheet, which is often the format we get from a customer in the first place.

Also, Studio isn't easily extensible, which fundamentally limits the amount of things admins/presales/support etc. roles can do.

Reliable transfer between environments, e.g. dev to prod - An oldie but goodie. I'm sure everyone has solved this in some fashion, but getting customizations from env A to env B, reliably, repeatably, and quickly, is something that took a lot of "sweat and tears". This is compounded by the previous point, where Studio/ML customizations make this task a whole lot more difficult. It also needs to work both ways, because some customers use Studio to do their own simple customizations, which then need to be synced back to dev/stage environments. All this is doubly painful when SugarCloud gets involved.

(Pre)sales, initial implementations & admin handover - this one will be a little longer, and is related to the previous two points. (Pre)sales meetings always go better when you show up with a tailored demo. This usually involves "visual" customizations, things like creating fields, editing layouts, creating modules etc., which are done in Studio, usually by a team of admins, because developer time is "too precious" (the official way of saying "I don't want to", hehe). This often continues after winning the deal, during the analysis/initial implementation phase.

However, once developers become involved, we have two choices: either throw away all the work the admins did and start from scratch, or use what the admins did and spend lots of time tweaking the things that need to be tweaked. The key problem is that, because there is no easy developer interface to things done in Studio, I can't easily pick and chose - it's either all or nothing, and both approaches mean I have to spend time clicking in Administration.

Also, it's not uncommon for one of the sales guys to swing by before a meeting asking "for just this one programming customization" that's a slight variation on what's needed in every other demo, e.g. displaying a button on a subpanel (without it doing anything). But, because Studio isn't extensible, there's no easy way of enabling the admins to do that.

And finally, if, for whatever reason, it's decided that this particular demo is worth investing developer effort, we're faced with problem #2 above - demos are usually in the cloud.

IDE integration - this is probably one that's very specific to me personally, but I've always wished for my IDE to be Sugar-aware - things like hinting link/relationship names, field names, allowing me to search sugar metadata using "double-shift" (if you're using PHP Storm), things like that.

What about you?

Parents

  •  please subscribe to my blog. I discuss many of these topics. 

    Studio (and administration in general)

    You can program the layouts, views, vardefs, relationships, etc., via code and deploy via Module Loadable Packages. We do this every day.

    Reliable transfer between environments, e.g. dev to prod

    There used to be a tool available either on SugarOutfitters or on Sugar's GitHub page that simplifies this process. We have a defined process that we follow to make this simpler. If you have a process, it will make it much easier for you.

    (Pre)sales, initial implementations & admin handover

    Again, we have a defined process that makes this simpler. Of course, the process is not 100% perfect but 95% is better than doing it differently every time.

    It would be helpful if you can provide more detail about your struggles? I have personally been involved with more than 1,000 Sugar implementations. I/We do not have these struggles. It used to be that as a developer we had to perform 80% of all work as Logic Hooks, customizations, etc. Now, it's more like 10%, only the difficult items require developers. Everything else is done inside of Sugar utilizing Studio, SugarBPM, SugarLogic, CalculatedFields, ReadOnly Formulas, etc.

    IDE integration

    For example. Did you know that in PHPStorm? You can add hints which let the IDE know what Object you are using?

    For example:

    $current_user = BeanFactory::newBean('Users');

    Doesn't give you any information when trying to use the $current_user variable. But if you change it to be 

    /** @var $current_user User */
$current_user = BeanFactory::newBean('Users');

    You get more information

    There is also an older blog post from which might provide some other IDE ideas

  • in reply to Jeff Bickart

    Hey Jeff, thanks for the response! There's a lot of context that I purposefully left out of my answer, because I wanted to keep it as short as possible. I'll try to add some:

    1) I agree. We developed a framework that does it for us, which I'm in the process of productizing and might post here in a couple of days to let people beta test it. My point was more the fact that this isn't something that's done easily with vanilla Sugar and "vanilla knowledge" - you need to go and discover for yourself which things you need to create and which attributes need to be filled out. For example, here's the full list of attributes Studio sets on a text field:

     

    Each of those have "semantic" rules - what values are allowed and the relationships that need to be observed between them. For instance, Studio uses 1' or '0' for full_text_search['enabled'], true/false (bools) for full_text_search['searchable'], and 'true'/'false' (strings) for 'importable'. It's not always obvious what the values are or should be, e.g. in a relate field, the 'rname' attribute is always "name", except for Documents, where it's document_name (see TemplateRelatedTextField::get_field_def()).

    And then you actually need to go and create the files + contents, which means that, if you're looking to automate the process (e.g. the spreadsheet importer I was talking about), you're opening a can of worms called "code generation", and that's not an easy thing to do if you're looking to cover all the different dev scenarios in Sugar.

    What I was getting at is that I wish Sugar would, by default, have something where you could go "FieldFactory::text($module)->setImportable(true) and that's it. Studio would then just call these things from the frontend, and you could use them on the backend as well.

    2) We automated this, in two different ways actually. My views on this have changed, but it used to be that I was opposed to having the entire Sugar directory in a git repo, and we only tracked the custom folder. We then had a pretty complex script that would cherry-pick all the important files from custom/, copy them over to a folder outside Sugar (that was tracked by git), connect to the DB, export fields_meta_data, and some other things to the same folder, and this would all get added to the repo. Whenever a branch was changed/you manually ran 'deploy', all the things would get "imported" back, with checks and backups being made if any of the changes were destructive (e.g. a column was removed), rebuild got run, etc. So the deploy process was "export-commit-push-pull-deploy", and could be used in any direction between any environments (except the cloud). As I remember (it's been about 6 years) there were a lot of challenges on that road, and I'm not a 100% sure we solved all of them.

    The framework I mentioned above generates ML packages as it's output, and can handle the majority of customizations that are usually done (Sidecar, logic hooks, API's, etc.), and is easily extensible to cover the situations that aren't implemented yet, so that helps with cloud a lot.

    3) Yes, this is fundamentally a process issue, no question about it. My point was that the "interface" between devs and admins would be a lot smoother if Studio (and the various other tools that admins use) had a unified and easy to use backend API. That would a) ostensibly give me greater control once a block of work was handed over, because I could just open up a file and switch up the things that need to be switched up, as opposed to a) doing that in Studio or b) ping-ponging all around the code base, deleting labels/vardefs/db columns and then recreating them whenever I need to e.g. replace a field by two other fields, or something similar.

    If 90% of customization work revolves around admin tools, then this probably isn't much of a problem. I've been out of the implementation game for a number of years now, so the specifics are blurry and more importantly out-dated. SugarBPM was relatively new back then, but I remembered I was a little skeptical about replacing simple logic hooks/schedulers with a a super-complicated blackbox solution that I felt could break down in any number of mysterious ways. That might have been a misguided assessment, or it might have been true then, but isn't anymore. That might be an interesting question for the rest of the SugarDev community - I would be curious to find out if doing 90% of the work through these tools is typical.

    4) I was thinking more about $bean->load_relationship(<hmm, was it accounts_calls_1, or calls_accounts_1?>), or 

    $dictionary['Account']['fields'][<I'm gonna say num_pings_c? Or was that ping_num_c?>]['required'] = true. We solved this by periodically generating a bunch of class constants from Sugar metadata. The IDE indexes them, et voila:
    A nice benefit is that you can actually browse the metadata right there in your IDE, without having to go hunting among base files and extensions to find the value Sugar is actually loading during runtime.
    In conclusion, I was talking more about things that I wish were solved by Sugar without us devs having to do the work. Everything is easy in retrospective, but I remember starting out when Sugar7 was a new thing, and boy, was there a lot of trial and error in store for me before I figured all these things out, and that might still be the case for people who are new. A lot of it might have been avoided if these things worked OOTB.
Reply
  • in reply to Jeff Bickart

    Hey Jeff, thanks for the response! There's a lot of context that I purposefully left out of my answer, because I wanted to keep it as short as possible. I'll try to add some:

    1) I agree. We developed a framework that does it for us, which I'm in the process of productizing and might post here in a couple of days to let people beta test it. My point was more the fact that this isn't something that's done easily with vanilla Sugar and "vanilla knowledge" - you need to go and discover for yourself which things you need to create and which attributes need to be filled out. For example, here's the full list of attributes Studio sets on a text field:

     

    Each of those have "semantic" rules - what values are allowed and the relationships that need to be observed between them. For instance, Studio uses 1' or '0' for full_text_search['enabled'], true/false (bools) for full_text_search['searchable'], and 'true'/'false' (strings) for 'importable'. It's not always obvious what the values are or should be, e.g. in a relate field, the 'rname' attribute is always "name", except for Documents, where it's document_name (see TemplateRelatedTextField::get_field_def()).

    And then you actually need to go and create the files + contents, which means that, if you're looking to automate the process (e.g. the spreadsheet importer I was talking about), you're opening a can of worms called "code generation", and that's not an easy thing to do if you're looking to cover all the different dev scenarios in Sugar.

    What I was getting at is that I wish Sugar would, by default, have something where you could go "FieldFactory::text($module)->setImportable(true) and that's it. Studio would then just call these things from the frontend, and you could use them on the backend as well.

    2) We automated this, in two different ways actually. My views on this have changed, but it used to be that I was opposed to having the entire Sugar directory in a git repo, and we only tracked the custom folder. We then had a pretty complex script that would cherry-pick all the important files from custom/, copy them over to a folder outside Sugar (that was tracked by git), connect to the DB, export fields_meta_data, and some other things to the same folder, and this would all get added to the repo. Whenever a branch was changed/you manually ran 'deploy', all the things would get "imported" back, with checks and backups being made if any of the changes were destructive (e.g. a column was removed), rebuild got run, etc. So the deploy process was "export-commit-push-pull-deploy", and could be used in any direction between any environments (except the cloud). As I remember (it's been about 6 years) there were a lot of challenges on that road, and I'm not a 100% sure we solved all of them.

    The framework I mentioned above generates ML packages as it's output, and can handle the majority of customizations that are usually done (Sidecar, logic hooks, API's, etc.), and is easily extensible to cover the situations that aren't implemented yet, so that helps with cloud a lot.

    3) Yes, this is fundamentally a process issue, no question about it. My point was that the "interface" between devs and admins would be a lot smoother if Studio (and the various other tools that admins use) had a unified and easy to use backend API. That would a) ostensibly give me greater control once a block of work was handed over, because I could just open up a file and switch up the things that need to be switched up, as opposed to a) doing that in Studio or b) ping-ponging all around the code base, deleting labels/vardefs/db columns and then recreating them whenever I need to e.g. replace a field by two other fields, or something similar.

    If 90% of customization work revolves around admin tools, then this probably isn't much of a problem. I've been out of the implementation game for a number of years now, so the specifics are blurry and more importantly out-dated. SugarBPM was relatively new back then, but I remembered I was a little skeptical about replacing simple logic hooks/schedulers with a a super-complicated blackbox solution that I felt could break down in any number of mysterious ways. That might have been a misguided assessment, or it might have been true then, but isn't anymore. That might be an interesting question for the rest of the SugarDev community - I would be curious to find out if doing 90% of the work through these tools is typical.

    4) I was thinking more about $bean->load_relationship(<hmm, was it accounts_calls_1, or calls_accounts_1?>), or 

    $dictionary['Account']['fields'][<I'm gonna say num_pings_c? Or was that ping_num_c?>]['required'] = true. We solved this by periodically generating a bunch of class constants from Sugar metadata. The IDE indexes them, et voila:
    A nice benefit is that you can actually browse the metadata right there in your IDE, without having to go hunting among base files and extensions to find the value Sugar is actually loading during runtime.
    In conclusion, I was talking more about things that I wish were solved by Sugar without us devs having to do the work. Everything is easy in retrospective, but I remember starting out when Sugar7 was a new thing, and boy, was there a lot of trial and error in store for me before I figured all these things out, and that might still be the case for people who are new. A lot of it might have been avoided if these things worked OOTB.
Children
No Data