The new “with Search” fields in Sitecore 7 offer a great way for users to select items from a large list of options. One problem is that these new fields have a lot of hidden potential that is not (yet) documented very well.
It seems that all of the advanced control that a developer has over these fields is hidden in the “Source” property. Rather than spew a lot of words at you, I’ll dive right in to the values and some examples.
We all seem to love WebApi. On the Microsoft technology stack, it is probably the most well-conceived method of building a REST-like web service. If you are building a Sitecore website, though, you may have a problem. Sitecore takes over most of the ASP.NET request cycle, which poses a problem for other ASP.NET technologies, including WebApi. That is not the end of the story, though!
If you would rather just skip all of the boring explanation stuff, then go install this Nuget package in your web project and get off my back!
The web conference at the University of Illinois was an excellent event! This conference was not my normal scene. Being a web conference, the sessions covered all pertinent topics from pure design and UX all the way to distributed real-time apps and TDD. Along with the heavier design focus, this conference was outside of my normal circle of friends. In fact, I didn’t know a single other speaker or attendee before the event!
This was a great growing opportunity, and I met some very engaging personalities! I highly recommend this event.
A couple of weeks ago I was at Nebraska Code Camp in Lincoln, NE. This was a very good event. All of the sessions I attended were excellent! In the hallway between sessions, and during the after-party, I met with some excellent individuals. The software development community is thriving in Nebraska!
After such a productive code camp, I thought I would post some highlights of the most useful and/or interesting things I have learned/re-learned. Unlike my last “what I learned” post, I am just going to include some of the highlights this time. This means you might have to think a little bit to digest these notes.
I’ve been writing software long enough to have developed a few opinions. Many of the practices and patterns that I have encountered have been great! Some have taken me down a dark, winding path. Here are a few that I find more bittersweet.
Test-Driven Development (TDD)
I am a huge proponent of TDD. It has saved my bacon a number of times, and has surely saved me hundreds of hours of troubleshooting and re-factoring.
What I Love About It
- My boss and team members like the higher test coverage
- Easier to communicate test cases and test plan ideas to QA
- Better idea about work remaining to complete a feature
- Greater confidence in re-factoring, since I know my tests will catch most bugs I might introduce
South Florida Code Camp 2013 is now over. This was a large event on the campus of Nova Southeastern University in Fort Lauderdale, Florida. The organizers did an excellent job, especially considering that there were about 80 speakers, over 1200 registrants, nearly 90 sessions and a blizzard in the northeast (which prevented a number of speakers from attending). A big thank you to Rainer Habermann, Dave Noderer and everyone else that was involved in making this event happen.
Since I have been attending a fair number of conferences and code camps, I have decided that it might be worthwhile for me to start sharing what I learn at these events. If this goes well, I’ll likely continue.
Here are my notes from the event. Some of these are things that I just learned. Most are things that I knew already, but enjoyed the reminder.
So here we go. What I learned (or re-learned) at South Florida Code Camp.
This next installment in my inside-jokes sequence is a very fun movie that my wife can’t stand. The only thing she likes from this movie is the logical method for determining if someone is a witch, which was screened and discussed in her college logic class.
As for me, this film is one of my favorites, and I can be caught quoting it frequently.
Monty Python and the Holy Grail
Monty Python and the Holy Grail is a movie that was made by the British comedy group that called themselves Monty Python. It follows the adventures of Sir Arthur of Camelot and his Knights of the Round Table as they quest to find the Holy Grail. Comedy ensues throughout their exploits. I won’t tell you how it ends, but it is both disappointing and humorous.
I get a surprising number of questions about when objects are disposed or collected. Usually people will have some limited logic to cleanup their objects (releasing file handles, removing references to large objects, etc.), and they don’t know when this logic will execute. Here is a little bit of insight into when objects are disposed and finalized. (If you are looking for more information about Disposable and Finalizable patterns, check this post)
When Does Dispose Execute?
The Dispose method on an object is only executed when it is called by the application. What I mean by that, is the CLR does not automatically call Dispose on your objects. If you don’t call dispose, it can result in a memory leak that does not get cleaned up until the process exits.
This doesn’t mean you necessarily have to call Dispose() explicitly. In C#, there are a number of times that Dispose() is called implicitly:
Through my discussions with various developers, I have noticed a common theme when it comes to disposing objects. Most developers are confused, or at least unclear, on why and when to use dispose and finalize.
Let me start off with this: The purpose of dispose and finalize is the same… to improve the performance of the application and the host system. You don’t need to implement either. When the GC runs, unused managed memory will be reclaimed. When your process exits, the entire process’s virtual memory will be released. When the system re-boots, any open native handles will be closed. Dispose and finalize are two patterns that make it easier for your application to be a “good citizen,” releasing memory as soon as it is no longer needed and closing handles as soon as you are done with them.
As Raymond Chen so aptly explained, the purpose of garbage collection is to simulate a computer with an infinite amount of memory. This is another piece of the puzzle that gives application developers freedom through abstraction. Freedom to focus on the logic and structure of their code without being unnecessarily concerned about the constraints of the system it is running on, including managing physical and virtual memory. Unfortunately, this seems to result in some gross misuse of system resources.
So that you do not fall into the same fallacies and abuse, let’s learn some more about memory management in .NET. This article will be a higher level overview of Garbage Collection (GC) in version 4.5 of the .NET Framework. There will be more articles to follow that will go into more depth of some of the different parts of the .NET Garbage Collector.
The Garbage Collector (GC) in .NET can be thought of as the subsystem that handles allocating and de-allocating managed memory. Ever used variables in c?
char *name = malloc(50);