"[Apex Code] is not a niche tool for a proprietary platform -- rather, it's a Java-like language with an Eclipse-based tool ecosystem and excellent facilities for unleashing immense gains in developer productivity and enterprise project success."
"For those who pooh-pooh Microsoft's success as "mere marketing" I have a suggestion: You need to get into this "mere marketing" business. It has a way of driving adoption. It matters."
"Lots and lots of people have opinions about platforms, but the people whose opinions matter are programmers, and people who can make decisions about what programmers program."
If Analytic Snapshots supported Summary Reports, I could avoid exporting to Excel, replacing a bunch of text and pasting in a bunch of formulas in order to perform the calculations that I need.
I'm not the only one either - vote up the idea: Summary Fields in Analytic Snapshots.
I've written before about how programming in Apex allows developers to be much more productive. Visualforce similarly helps developers avoid writing a lot of boring code.
If Visualforce and Apex were a typical development platform, the canonical way of populating a data bound picklist would be something like this:
Visualforce markup:
<apex:pageBlockSectionItem> | ||
<apex:outputLabel value="Category" for="expenseCategory"/> | ||
<apex:selectList multiselect="false" id="expenseCategory" required="true" size="1" value="{!expense.Category__c}"> | ||
<apex:selectOptions value="{!ExpenseCategories}"/> | ||
</apex:selectList> | ||
</apex:pageBlockSectionItem> | ||
public List getExpenseCategories() | ||
{ | ||
Map allObjectTypesMap = Schema.getGlobalDescribe(); | ||
Schema.DescribeFieldResult f = Schema.sObjectType.Expense__c.fields.Category__c; | ||
List options = new List(); | ||
options.add(new SelectOption('--None--', '--None--')); | ||
for(Schema.PicklistEntry ple : f.getPicklistValues()) | ||
{ | ||
options.add(new SelectOption(ple.getValue(), ple.getLabel())); | ||
} | ||
| ||
} | ||
<apex:inputField id="expenseCategory" required="true" value="{!expense.Category__c}"/>I've received two letters in the past year from former employers alerting me that they had lost a computer that contained some of my confidential information. Apparently, I'm not alone - according to a Dell survey, 12,000 laptops are lost at airports alone every week. Over 50% of those laptops are purported to have sensitive corporate data on them. The vast majority of these lost laptops are never reunited with their owners.
I'm surprised that so many corporate Information Security teams place so much faith in the ability of their users to safeguard important corporate information. Individual employees shouldn't be solely responsible for guarding important information. The bulk of that burden should be left to security professionals.
Corporate InfoSec teams should be using SaaS applications to house a lot more of their sensitive data than they are currently. The InfoSec professionals employed by SaaS vendors are much more skilled at protecting data than the average employee is and by using SaaS applications, confidential data isn't stored on individual employee computers and therefore can't be lost. Don't worry about losing your laptop - use SaaS applications instead.
I've pointed out previously how Salesforce2Salesforce is functionality that an on-premise software vendor could never deliver. Google Docs Live Forms is another great example of simple, elegant functionality that can only be delivered by Software as a Service.
I've been enjoying the CODA 2go blog. It's been interesting to see some of the process of developing the first large-scale enterprise application on the Force.com platform. It was especially exciting to see CODA 2go launch last week at Dreamforce Europe. Check out their demo here:
http://video.coda.com/CODA2go-sneakPeak.htm
CODA's efforts are clearly pushing the Force.com platform in new directions and I hope that other Force.com developers will also blog about their development experiences as well. I can't wait to test-drive CODA 2go.
Writing unit tests may be a bit of an acquired taste, but I don't think that the value of writing them can be overstated for any moderately complex software project.
Having a full suites of well-written unit tests gives developers the peace of mind to confidently refactor code that isn't their own, or to refactor code that they have written but are no longer happy with.
Writing unit tests before writing the actual code has an added benefit as well. It provides a developer with an extra opportunity to think about how clients of the code are going to use it. This in turn helps identify potential bugs much earlier in the development cycle.
Add it all up, and the end result is that the act of writing unit tests results in higher quality code. The popularity of NUnit helped Microsoft realize this, which is why Visual Studio 2005 Team System delivered integrated unit testing tools.
salesforce.com came to the same conclusion about the importance of unit testing and made it a fundamental component of Apex, their on demand programming language. Writing unit tests for Apex is a remarkably simple task, which is good, because Apex is the first programming language to require developers to write unit tests for their code - a minimum of 75% code coverage is required for all production Apex code. I anticipate that more languages will begin to follow suit, especially those designed to run in multi-tenant environments.
Having seen the value of unit testing personally and having seen the industry's acceptance of the value of unit testing, it's a bit surprising that more university computer science curriculums don't emphasize writing unit tests. Maybe it's because the teaching assistants like keeping their unit testing harnesses a secret...
