Overview: Join the Nuehealth team to be part of a silicon-valley start-up that is transforming the future of global health care. Nuehealth powers medical travel through cloud-based solutions and patient management services, allowing more patients to access health care anywhere in the world. Nuehealth is implementing the ‘next generation’ PRM (patient relationship management) solution to assist hospitals, doctors and international patient departments.
Developer will join a dynamic, international team of experienced technology and business personnel---all working in a fast-paced, fun environment.
Responsibilities
• Communicate and collaborate effectively with analysts to design solutions delivered using Force.com technology
• Implement Force.com solutions with Apex, VisualForce, Workflows and other Force.com technologies as well as appropriate client-side technologies such as dhtml/JQuery/javascript/remoting
• Integrate with 3rd-party cloud applications securely via sso/REST apis
• Develop unit-tests and Force.com coverage test classes as required for managed packages
• Debug and resolve Salesforce.com system-related issues
• Stay current on Force.com technology changes and collaborate with other developers on best practices
• Oversee change management processes, bug reports and enhancement requests
Requirements
• 2-3 years experience with, and expert knowledge of, Force.com Apex, SOQL, VisualForce, Workflow programming including best practices for end-user customizations (field sets, etc.), bulkification, triggers, web services, etc. working on a Sales-Force based product (managed package offered on the AppExchange)
• Great understanding of and experience working with Roles, Permission sets, profiles and sharing rules including apex sharing.
• 3-5+ years’ work experience as a software developer on cloud-based platforms
• Working knowledge of web services, cloud-based APIs and protocols (SOAP, REST, JSON, XML)
• Solid understanding of web client technologies such as dhtml, jQuery and ajax
• Proficiency in relational database concepts and SQL
• Excellent analytical and problem solving skills
• Excellent oral and written communications skills
Recommended Qualifications
• SalesForce developer or administrator certification
• Implementation of a development project for a commercially successful SalesForce-based product
Bonus Qualifications
• Knowledge of SalesForce managed packages including end-user customization considerations
System.schedule('test', '0 0 0 * * ?', new SchedulableClass());
The CronTrigger job doesn't have a "Name" field, so I can't query for the Job I just created. This means I can't check to see if my job already exists calling System.schedule(); instead I just have to call "schedule()" and silently eat the exception it throws if the job already exists.
The only way you can figure out which CronTrigger is yours is to cache the return value of System.schedule(), which (it so happens) is the ID of the CronTrigger that is created. However, you can't delete them from Apex:
Id jobid = System.schedule('test', '0 0 0 * * ?', new SchedulableClass()); delete new CronTrigger(Id = jobid);
// 'delete' throws 'DML not allowed on CronTrigger'
So the current state of Scheduled Jobs is:
You can create them from Apex Code, but not from the UI
You can delete them from the UI, but not from Apex Code
I guess that just seems odd to me. Why did Salesforce create this whole new API (System.schedule()), with a seemingly random assortment of ways to manipulate it, instead of just exposing the CronTrigger table directly to the full range of DML operations?
Placing new functionality into new core objects, rather than new APIs, seems easier on everyone (the whole describe/global describe suite of API calls are an example of something that seems a natural fit for a set of read-only custom objects).
