Organizational change initiatives, whether in the form of an office move, the roll-out of a new health insurance plan, or a company-wide restructuring, are inherently difficult. They are so difficult, in fact, that a staggering 70% of all change initiatives fail.
One of the 12 principals within the Agile Manifesto for an Agile/Scrum environment is that the team needs to be co-located, the interaction has to happen in person because there is value in that personal interaction. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” So what happens when the team cannot be together? It’s a question many people have asked when attempting to work in scrums when geographic boundaries are yet another obstacle to overcome.
Word on the street has it that Developer Center functionality in Sitecore 7+ is deprecated and will eventually become obsolete. A Visual Studio Add-on called Sitecore Rocks will replace this functionality. This add-on brings most of the Content Management Developer functionality directly into Visual Studio. If you haven’t used Sitecore Rocks before, now is the time to start.
This is the first of a series of posts focused on utilizing Sitecore Rocks within your Sitecore development efforts.
In Part 1 of this series, we created our Portable Class Library (PCL) project that allows us to access SQLite from different platforms. In Part 2 we added our Windows Store App to the solution. In this post, we will add our Windows Phone App to the Solution.
If you aren’t using Rendering Parameters with your Presentation Components you’re missing out on a fundamental aspect of Sitecore that will truly allow you to separate code from content and change the way your Page Designers interact with your presentation components.
I have worked at multiple companies where the implementation of Cassandra resulted in an inability to query the operational data. In each of these cases, they had to build a parallel Extract, Transformation and Load (ETL) process that “replicated” the data to an RDBMS to support ad-hoc queries. This is one of the biggest pitfalls of implementing NoSQL tools and it can be avoided with a little pre-implementation planning.
In Part 1 of this series, we created our Portable Class Library (PCL) project that allows us to access SQLite from different platforms. In this post, we will add our Windows Store App to the Solution. Part 3 will cover adding the Windows Phone App to the solution. If you want to skip ahead and get the source code, it can be found here.
Last week, CapTech hosted an hour-long webinar entitled, “iBeacon Demystified.” With this event, we intended to help our clients and partners see through the hype baked into much of the reporting around Apple’s newest location-based service. We see the potential and the promise in the technology too, but we have no illusions about what’s needed to deliver meaningful user experiences with iBeacon.
In this 3 part series, I’m going to walk through creating a very simple ToDo project that will target Windows Phone and Windows Store to illustrate how to build a PCL for storing SQLite data that both platforms will use.